AWS wellarchitected medium security documentation change
Summary
Added two new security best practices (IOTSEC11-BP01 and IOTSEC11-BP02) focused on incident response mechanisms and vulnerability notifications. Enhanced guidance on device quarantine processes, OTA update resilience, logging, and monitoring. Updated terminology and expanded security implementation details.
Security assessment
The changes explicitly address security practices for IoT devices, including incident response mechanisms, vulnerability management, device quarantine procedures, firmware signing, and monitoring for anomalies. Specific security features like AWS IoT Secure Tunneling, Code Signing for AWS IoT, and SIEM integration are highlighted. The addition of 'threat actor' terminology and emphasis on firmware tampering detection directly relate to mitigating security risks.
Diff
diff --git a/wellarchitected/latest/iot-lens/incident-response.md b/wellarchitected/latest/iot-lens/incident-response.md index 8c2f2c51b..fcf178007 100644 --- a//wellarchitected/latest/iot-lens/incident-response.md +++ b//wellarchitected/latest/iot-lens/incident-response.md @@ -3 +3,3 @@ -[Documentation](/index.html)[AWS Well-Architected](https://aws.amazon.com/architecture/well-architected/)[AWS Well-Architected Framework](abstract-and-introduction.html) +[Documentation](/index.html)[AWS Well-Architected](https://aws.amazon.com/architecture/well-architected/)[AWS Well-Architected Framework](iot-lens.html) + +IOTSEC11-BP01 Build incident response mechanisms to address security events at scaleIOTSEC11-BP02 Require timely vulnerability notifications and software updates from your providers @@ -7 +9 @@ -Being prepared for incident response in IoT requires planning on how you will deal with two types of incidents in your workload. The first incident type is an attack against an individual IoT device in an attempt to disrupt the performance or impact the device’s behavior. The second incident type is a larger scale IoT event, such as network outages and DDoS event. In both scenarios, the architecture of your IoT application plays a large role in determining how quickly you will be able to diagnose incidents, correlate the data across the incident, and then subsequently apply runbooks to the affected devices in an automated, reliable fashion. +Being prepared for incident response in IoT requires planning on how you will deal with two types of incidents in your IoT workload. The first type of incident is an attempt by a threat actor to access an individual IoT device to disrupt the performance or change the device's behavior. The second incident is a broad event, such as network outages or DDoS attacks. In both scenarios, the architecture of your IoT application and infrastructure plays a large role in determining how quickly you will be able to detect and diagnose incidents, correlate the data across the incident, and then subsequently apply runbooks to respond and recover the affected devices in an automated, reliable fashion. @@ -11 +13 @@ For IoT applications, follow the following best practices for incident responses - * IoT devices are organized in different groups based on device attributes such as location and hardware version. + * Organize sets of IoT devices into different groups based on device attributes such as location and hardware version. @@ -13 +15 @@ For IoT applications, follow the following best practices for incident responses - * IoT devices are searchable by dynamic attributes, such as connectivity status, firmware version, application status, and device health. + * Enable searching of IoT devices by dynamic attributes, such as connectivity status, firmware version, application status, and device health. @@ -15 +17 @@ For IoT applications, follow the following best practices for incident responses - * OTA updates can be staged for devices and deployed over a period of time. Deployment rollouts are monitored and can be automatically aborted if devices fail to maintain the appropriate KPIs. + * Stage OTA updates for IoT devices and deploy to devices in waves over a period of time. Deployment rollouts should be monitored and aborted if devices fail to maintain the appropriate KPIs. @@ -17 +19 @@ For IoT applications, follow the following best practices for incident responses - * Any update process is resilient to errors, and devices can recover and roll back from a failed software update. + * Test and verify that the update process is resilient to errors, and devices can recover and roll back from a failed software update. @@ -19 +21 @@ For IoT applications, follow the following best practices for incident responses - * Detailed logging, metrics, and device telemetry are available that contain contextual information about how a device is currently performing and has performed over a period of time. + * Keep detailed logs, metrics, and device telemetry for IoT devices that contain contextual information about how a device is currently performing and has performed over a period of time. @@ -21 +23 @@ For IoT applications, follow the following best practices for incident responses - * Fleet-wide metrics monitor the overall health of your fleet and alert when operational KPIs are not met for a period of time. + * Montor the overall health of your fleet using fleet-wide metrics. Alert when operational KPIs are not met for a period of time. @@ -23 +25 @@ For IoT applications, follow the following best practices for incident responses - * Any individual device that deviates from expected behavior can be quarantined, inspected, and analyzed for potential compromise of the firmware and applications. + * Quarantine IoT devices that deviate from expected behavior. Inspect and analyze the device for potential compromise of the device by hardware tampering, firmware modification or application code modification. @@ -30 +32 @@ For IoT applications, follow the following best practices for incident responses -Implement a strategy in which your InfoSec team can quickly identify the devices that need remediation. Ensure that the InfoSec team has runbooks that consider firmware versioning and patching for device updates. Create automated processes that proactively apply security patches to vulnerable devices as they come online. +Implement a strategy in which your Information Security team can quickly identify the devices that need remediation. Make sure that the Information Security team has runbooks that consider firmware versioning and patching for device updates. Create automated processes that proactively apply security patches to vulnerable devices as they come online. @@ -32 +34 @@ Implement a strategy in which your InfoSec team can quickly identify the devices -Implement a monitoring solution in the OT, IoT, and IIoT environments to create an industrial network traffic baseline and monitor anomalies and adherence to the baseline. Collect security logs and analyze them in real-time using dedicated tools, for example, security information and event management (SIEM) class solutions such as within a security operation center (SOC). AWS works with a number of OT Intrusion Detection System (IDS) and SIEM partners that can be found on AWS Marketplace. +Implement a monitoring solution in the operations technology (OT), IoT and IIoT environments to create an industrial network traffic baseline and monitor for anomalies and any deviation from the baseline. Collect security logs and analyze them in real-time using dedicated tools, for example, security information and event management (SIEM) class solutions such as within a security operation center (SOC). AWS works with a number of OT Intrusion Detection System (IDS) and SIEM partners that can be found on AWS Marketplace. @@ -34 +36 @@ Implement a monitoring solution in the OT, IoT, and IIoT environments to create -At a minimum, your security team should be able to detect an incident on a specific device based on the device logs and current device behavior. After an incident is identified, the next phase is to quarantine the device. To implement this with AWS IoT services, you can use AWS IoT thing groups with more restrictive IoT policies along with enabling custom group logging for those devices. This allows you to only enable features that relate to troubleshooting, as well as gather more data to understand root cause and remediation. Lastly, after an incident has been resolved, you must be able to deploy a firmware update to the device to return it to a known state. +At a minimum, your security team should be able to detect an incident on a specific device based on the device logs and current device behavior. After an incident is identified, the next phase is to quarantine the device. To implement this with AWS IoT services, you can use AWS IoT Thing Groups with more restrictive IoT policies along with enabling custom group logging for those devices. This allows you to only enable features that relate to troubleshooting, as well as gather more data to understand root cause and remediation. Lastly, after an incident has been resolved, you must be able to deploy a firmware and software update to the device to return it to a known good state. @@ -36 +38 @@ At a minimum, your security team should be able to detect an incident on a speci -IOTSEC 8: How do you plan the security lifecycle of your IoT devices? +IOTSEC11: How do you plan the security lifecycle of your IoT devices? @@ -41 +43 @@ The security lifecycle of your IoT devices includes everything, from how you cho -**Best practice IOTSEC_8.1 – Build incident response mechanisms to address security events at scale** +## IOTSEC11-BP01 Build incident response mechanisms to address security events at scale @@ -45 +47,3 @@ There are several formalized incident management methodologies in common use. Th -**Recommendation IOTSEC_8.1.1** – _Ensure that IoT devices are searchable by using a device management solution_ +**Level of risk exposed if this best practice is not established:** Medium + +**Prescriptive guidance IOTSEC11-BP01-01** _Make sure that IoT devices are searchable by using a device management solution._ @@ -49 +53,3 @@ Devices should be grouped by dynamic attributes, such as connectivity status, fi -**Recommendation IOTSEC_8.1.2** – _Quarantine any device that deviates from expected behavior_ +**Prescriptive guidance IOTSEC11-BP01-02** _Quarantine any device that deviates from expected behavior._ + +Inspect the device for potential issues in the configurations, firmware or applications using device logs or metrics. If a risk or anomaly is detected, the device can be diagnosed remotely provided that capability exists. For example, Configure AWS IoT Secure Tunneling to remotely diagnose a fleet of devices. @@ -51 +57 @@ Devices should be grouped by dynamic attributes, such as connectivity status, fi -Inspect the device for potential compromise of the configurations, firmware or applications using device logs or metrics. If a compromise is detected, the device can be diagnosed remotely provided that capability exists. For example, configure AWS IoT Secure Tunneling to remotely diagnose a fleet of devices. +If remote diagnosis is not sufficient or available, the other option is to push a security patch, application or firmware upgrade while the device is quarantined. When sending code to devices, the best practice is to sign the firmware or software and to verify the signature at the device prior to applying the update or code. This allows devices to detect if the code has been modified in transit. For example, With Code Signing for AWS IoT, you can sign code that you create for IoT devices supported by Amazon FreeRTOS and AWS IoT device management. In addition, the signed code can be valid for a limited amount of time to avoid further manipulation. @@ -53 +59 @@ Inspect the device for potential compromise of the configurations, firmware or a -If remote diagnosis is not sufficient or available, the other option is to push a security patch, application or firmware upgrade to quarantine the device. When sending code to devices, the best practice is to sign the code file. This allows devices to detect if the code has been modified in transit. For example, With code signing for AWS IoT, you can sign code that you create for IoT devices supported by FreeRTOS and AWS IoT device management. In addition, the signed code can be valid for a limited amount of time to avoid further manipulation. +**Prescriptive guidance IOTSEC11-BP01-03** _Over the air (OTA) update should be configured and staged for deployment activation during regular maintenance._ @@ -55 +61 @@ If remote diagnosis is not sufficient or available, the other option is to push -**Recommendation IOTSEC_8.1.3** – _Over-the-air (OTA) updates should be configured and staged for deployment activation during regular maintenance_ +Whether it's a security patch or a firmware update, an update to a config file on a device, or a factory reset, you need to know which devices in your fleet have received and processed any of your updates, either successfully or unsuccessfully. In addition, a staged rollout is recommended to reduce the scope of a bad update. Rollouts should be able to be aborted with devices returning to a failsafe condition on a failed update. For example, you can use AWS IoT Jobs to roll out OTA updates of security patches and device configurations in a staged manner with required rollout and abort configuration settings. @@ -57 +63 @@ If remote diagnosis is not sufficient or available, the other option is to push -Whether it’s a security patch or a firmware update, an update to a configuration file on a device, or a factory reset, you need to know which devices in your fleet have received and processed any of your updates, either successfully or unsuccessfully. In addition, a staged rollout is recommended to reduce the blast radius along with rollout and abort criterias for a failsafe solution. For example, you can use AWS IoT Jobs for OTA updates of security patch and device configurations in a staged manner with required rollout and abort configurations. +## IOTSEC11-BP02 Require timely vulnerability notifications and software updates from your providers @@ -59 +65 @@ Whether it’s a security patch or a firmware update, an update to a configurati -**Practice IOTSEC_8.2 – Require timely vulnerability notifications and software updates from your providers** +Components in a device bill of materials (BOM), such as secure elements (SEs) or a trusted platform module (TPM) for key or certificate storage, can make use of updatable software components. Some of this software might be contained in the Board Support Package (BSP) assembled for your device. You can help to mitigate device-side security issues quickly by knowing where the security-sensitive software components are within your device software stack, and by understanding what to expect from component suppliers with regard to security notifications and updates. @@ -61 +67 @@ Whether it’s a security patch or a firmware update, an update to a configurati -Components in a device bill of materials (BOM), such as secure elements for certificate storage or a trusted platform module (TPM), can make use of updatable software components. Some of this software might be contained in the Board Support Package (BSP) assembled for your device. You can help to mitigate device-side security issues quickly by knowing where the security-sensitive software components are within your device software stack, and by understanding what to expect from component suppliers with regard to security notifications and updates. +**Level of risk exposed if this best practice is not established:** Medium @@ -63 +69 @@ Components in a device bill of materials (BOM), such as secure elements for cert -**Recommendation IOTSEC_8.2.1** – _Ensure that your IoT device manufacturer provides security-related notifications to you, and provides software updates in a timely manner to reduce the associated risks of operating hardware or software with known security vulnerabilities_ +**Prescriptive guidance IOTSEC11-BP02-01** _Make sure that your IoT device manufacturer provides security-related notifications to you, and provides software updates in a timely manner to reduce the associated risks of operating hardware or software with known security vulnerabilities._ @@ -65 +71 @@ Components in a device bill of materials (BOM), such as secure elements for cert -Ask your suppliers about their product conformance to the Common Criteria for Information Technology Security Evaluation. In addition, consider using the AWS Partner Device Catalog where you can find devices and hardware to help you explore, build, and go to market with your IoT solutions. +Ask your suppliers about their product conformance to the [Common Criteria for Information Technology Security Evaluation](https://www.commoncriteriaportal.org/index.cfm). In addition, use AWS Partner Device Catalog where you can find devices and hardware to help you explore, build, and go to market with your IoT solutions. @@ -75 +81 @@ Data protection -Key AWS services +Application security