Internet of Things (IoT) devices have a different risk profile than traditional IT infrastructure and, therefore, require a different approach towards security. The AWS IoT suite of services includes solutions to monitor behavior, enforce compliance, and remediate incidents with this distinction in mind.
Let's start by analyzing the two primary tasks of IoT device applications: telemetry publishing and system actuation.
Telemetry publishing consists of reporting IoT device data, which includes sensor readings as well as any logs, errors, and events necessary for the functioning of the IoT ecosystem.
System actuation consists of any action by the device, whether it's physical such as controlling a servo for positional control or virtual such as downloading a firmware update from a private endpoint. These actions can happen in response to an internal state change or an explicit instruction from an ecosystem backend such as AWS IoT.
Figure 1: Example of telemetry publishing and system actuation.
Unlike traditional application servers, well-designed IoT devices 1 generally do not send requests to servers, query databases directly, nor have high network throughput. Instead, they typically operate in a publish-subscribe messaging pattern where the device can play either the publisher or subscriber role.
Furthermore, because IoT Devices tend to be resource-constrained, they generally hold only the amount of data necessary to publish their telemetry and to perform actuation functions. All this means that locally storing values for things such as available memory, battery levels, and sensor readings is often limited by the IoT device's capabilities. Instead, an IoT ecosystem often relies on gateway devices and its backend to preserve state information.
The following table lists some of the activities carried out by both IoT devices and traditional IT infrastructure, and it provides some examples of how each of the two could handle each activity:
| Activity | IoT Device | Traditional IT Infrastructure |
|---|---|---|
| Publish Data | Sends messages using a light-weight messaging protocol such as MQTT | Posts message using a robust application protocol such as HTTP |
| Get Application Configuration | Subscribe to configuration notifications through an MQTT topic. | Read from the file system or an external database. |
| Perform actions based on external commands | Receive commands through an MQTT topic. | Receive HTTP request with command and return a response. |
| Table 1: Example activities and how IoT Devices/Traditional IT infrastructure handle them differently. |
With this contrast in mind, we begin to sense that the threats to IoT Device Software likely have a different profile than threats to traditional IT infrastructure. Typical threats follow a pattern in which an attacker gaining access to one point in the system works his or her way into other parts of it to steal from or corrupt data stores. Although that is certainly still a risk, some of the more immediate and more likely concerns with IoT device software look like the following:
There are two critical security practices for IoT device software that address these concerns:
The first is that all devices in a given fleet must have authentication credentials that authorize them to perform only their intended actions.
The second is that mechanisms to monitor device behavior and to automatically respond to incidents should be in place.
Let's unpack those two practices and see how AWS IoT services help us fulfill them...
When a device connects to a backend, it should verify that the server is who it says that it is through the use of a server certificate. In an IoT context, it is also crucial that the server authenticates the device as one which is allowed to communicate with backend services. For these reasons, AWS IoT requires TLS mutual authentication for all communications with IoT devices.
During TLS client authentication, AWS IoT requests the IoT device's certificate and validates it against a registry for the AWS account. It then sends the client a challenge to verify that it holds the correct private key matching the public key found in the certificate. Reciprocally, the device verifies the identity of the server through its presented server certificate by referencing the CA certificate pre-loaded into the device.
Figure 2: Sequence Diagram showcasing TLS mutual authentication.
Mechanisms to monitor device operations and to respond to incidents should be in place to promptly thwart potential attackers. AWS IoT has a native risk mitigation solution known as Device Defender, which consists of device monitoring and behavior auditing to detect unusual behavior. It enables enforcement of consistent security policies across all devices and provides means to integrate solutions that quickly respond to incidents when devices are compromised.
For example, if a device sends excessive amounts of data over a given time window, a couple of automated actions could take place. First, instructions could be sent to the device to shut off. Second, AWS IoT could revoke the device's certificate to disallow it further access to AWS resources.
Additionally, AWS IoT has native support for several levels of logging. Logs are placed into CloudWatch and can be relayed to other monitoring services such as DataDog for further real-time analysis. IoT Logs, a robust mutual authentication system, least-privilege permissions, configuration auditing, and anomaly detection can all work in combination to prevent, identify, remediate, and understand all manner of IoT cyber threats.
Defining boundaries and swiftly detecting policy violations should be prioritized over more involved security practices such as constant data encryption or security patch updates.
That is because IoT device fleets have diverse computational capabilities, operating systems, geographical locations, and lifecycles, all of which make fleet setup complex and prone to errors. Moreover, IoT devices are often limited in processing power and storage, and this hinders them from performing typical IT maintenance and security tasks. These devices can also use components (e.g., cellular modems) running software with known vulnerabilities, which are difficult—and often impossible—to update.
Note that I am not suggesting we forego all other standard security practices. Instead, we should apply as many security and reliability mechanisms as the IoT device can handle. Still, we should understand that the most reliable means to secure our IoT ecosystem is to enforce tight permissions and to respond to device misbehavior in real-time.
Internet of Things devices have a different risk profile and a different set of capabilities as those of traditional IT infrastructure. The primary threats to these devices are data stream breaches and unauthorized operation of its software, sensors, and actuators. To counteract these threats, AWS provides a series of tools to enforce permissions management, behavior monitoring, compliance enforcement, and incident detection. Together, these tools allow companies to swiftly put a stop to threats by giving them a thorough understanding of their IoT ecosystems' live operations.
1 In this post, we define IoT devices as computing platforms whose hardware intended for a limited number of low-power applications. Mini-PCs and single-board computers, which could act as regular servers, are therefore excluded from this analysis.
Explore the Blues Cell + Wifi communication module on a Raspberry Pi Zero, Notehub, and thoughts on the pros and cons of utilizing Blues in your IoT project.
