Incident response - IoT Lens

Incident response

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.

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.

  • IoT devices are searchable by dynamic attributes, such as connectivity status, firmware version, application status, and device health.

  • 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.

  • Any update process is resilient to errors, and devices can recover and roll back from a failed software update.

  • 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.

  • Fleet-wide metrics monitor the overall health of your fleet and alert when operational KPIs are not met for a period of time.

  • Any individual device that deviates from expected behavior can be quarantined, inspected, and analyzed for potential compromise of the firmware and applications.

  • Test incident response procedures on a periodic basis.

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 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.

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.

IOTSEC 8: How do you plan the security lifecycle of your IoT devices?

The security lifecycle of your IoT devices includes everything, from how you choose your suppliers, contract manufacturers, and other outsourced relationships to how you manage security in your third-party firmware and manage security events over time. With visibility into the full spectrum of actors and activities in your hardware and software supply chain, you can be better prepared to respond to compliance questions, detect and mitigate events, and avoid common security risks related to third-party components.

Best practice IOTSEC_8.1 – Build incident response mechanisms to address security events at scale

There are several formalized incident management methodologies in common use. The processes involved in monitoring and managing incident response can be extended to IoT devices. For instance, AWS IoT Device Management capabilities provide fleet analysis and activity tracking to identify potential issues, in addition to mechanisms to enable an effective response.

Recommendation IOTSEC_8.1.1 – Ensure that IoT devices are searchable by using a device management solution

Devices should be grouped by dynamic attributes, such as connectivity status, firmware version, application status, and device health.

Recommendation IOTSEC_8.1.2 – Quarantine any device that deviates from expected behavior

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 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.

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 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.

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 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.

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

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.