How AWS IoT services address NIST 800-183: Networks of ‘Things’

In our previous posts about how public sector organizations can secure their Internet of Things (IoT) deployments, we introduced the AWS IoT family of services in Secure your organization’s Internet of Things devices using AWS IoT, and we dove deep into IoT communications with 4 common IoT protocols and their security considerations.

In this post, we will explore AWS IoT services in the context of NIST Special Publication 800-183: Networks of ‘Things’. NIST 800-183 presents a model for expressing IoT deployments and establishes concerns about the trustworthiness of the Internet of Things, which AWS IoT services can help public sector organizations address. We will delve into key areas such as authentication, monitoring, and secure communication.

NIST 800-183: Networks of ‘Things’

NIST 800-183 establishes a common language for IoT-based solutions, by defining five primitives:

Sensor – An electronic device that measures physical properties (temperature, acceleration)
Aggregator – A software function that transforms raw sensor data into aggregate, intermediate data, which can be run on a stand-alone device, such as a microprocessor or microcontroller, or might run on a common device such as a smartphone or vehicle’s onboard computer
Communication channel – A medium by which data is transmitted (wired, wireless)
External utility – A software or hardware product or service, intentionally defined broadly by NIST, which encompasses cloud computing and cloud services
Decision trigger – A conditional expression written as software that triggers an action

We use the example of a modern smart vehicle (car) to illustrate this mental model, using NIST’s recommended form of notation to demonstrate all of the primitives: sensors (S_n) are shown grouped into a cluster (C₁), which use communication channels depicted as solid-lined arrows to send data to aggregators (A_n), which are located on or transmit to external utilities (eU_n). We’ve pictured a scenario for fleet management where a temperature sensor is sending data to the vehicle’s onboard computer, which is aggregating and condensing the data for relevancy, then transmitting to the cloud. This allows the cloud service (AWS IoT Core) to feature a decision trigger (DT_n), which in this example is demonstrating taking two actions after detecting a high temperature: (1) notifying fleet services (2) displaying a maintenance appointment option back on the vehicle’s onboard or in-cabin display.

AWS IoT Core is the backbone of the AWS IoT family, providing a secure and scalable service for managing connected devices. This service acts as a bridge between the physical world of devices and the virtual world of cloud computing, enabling seamless data exchange and remote device management. The following diagram is the architecture for the solution.

Figure 1. Architectural diagram of the solution.

There are three areas of risk presented by NIST for the trustworthiness of a network of things:

Pedigree – For direct hardware such as sensors or underlying hardware powering aggregators, the manufacturers and their geographic locations make up their pedigree. The pedigree might be suspect. This area of risk deals with counterfeit or sabotaged hardware or software.
Reliability – The reliability of a system relies on its component parts:
- A sensor might degrade over time, providing inaccurate readings.
- An aggregator might receive unexpected data, causing processing issues.
- A communication channel might be unavailable due to overuse.
- An external utility might be offline or unavailable due to maintenance.
- Decision triggers are written in software and logic might be incorrect or untested.
Security – Likewise, the whole system is secure when each component part is secure:
- A sensor might be tampered with by an attacker loading new firmware.
- An attacker might inject unwanted data into an aggregator, which fails to validate it.
- A third party could eavesdrop on an insecure communication channel.
- An external utility without proper security hardening could be vulnerable to attack.
- Decision triggers that accept malicious input could result in unwanted actions.

AWS IoT services and specifically AWS IoT Greengrass can directly address these areas of risk raised by NIST 800-183. In the following diagram, we overlay relevant AWS IoT services to explain how HAQM Web Services (AWS) can mitigate these risks for public sector organizations with IoT deployments:

AWS IoT Greengrass – Although AWS IoT Core provides a centralized hub for managing IoT devices, many IoT applications require low-latency processing and decision-making capabilities at the edge. Greengrass consists of two main constructs, AWS IoT Greengrass Core and Greengrass client:

A Greengrass core – Device that runs the AWS IoT Greengrass Core software, which allows it to communicate directly with AWS IoT Core and the AWS IoT Greengrass service. A core has its own device certificate used for authenticating with AWS IoT Core. In the NIST model, a Greengrass core can be an aggregator on an edge device, such as a gateway, industrial controller, or even specialized in-vehicle hardware as pictured in the center of the following diagram. By bringing compute power closer to the devices, Greengrass Core enables low-latency processing of data, reducing the need for constant cloud connectivity and minimizing bandwidth consumption.
Greengrass client devices – Client devices, also called connected devices, Greengrass devices, or devices, are devices that connect to a Greengrass core over MQTT. They have their own device certificate for AWS IoT Core authentication, a device shadow, and an entry in the AWS IoT Core registry. These devices are pictured as sensors in the following diagram. Greengrass clients can be deployed on a wide range of devices, from small microcontrollers to more powerful edge devices. On the left side of the diagram, we’ve pictured next to our sensors (S_1-3) three possible options for client devices to connect to Greengrass Core: FreeRTOS, AWS IoT Device SDK, or the Greengrass discovery API.

Figure 2. Architectural diagram of the solution, including relevant AWS services.

In addition, we’ve included AWS IoT Device Defender on the right side of the diagram because it’s a security and monitoring service that allows organizations to audit the configuration of their devices, monitor their connected devices, and mitigate security risks.

Next, we dive into the specific mitigations this architecture provides by each NIST 800-183 risk area.

Pedigree risks

To protect the veracity of IoT device hardware and firmware and make sure that your organization uses trustworthy devices from known manufacturers as sensors, AWS IoT Core provides device provisioning that allows a public sector organization to install unique client certificates on each device, depending on the following:

If your organization is directly partnered with a device manufacturer, device provisioning supports just-in-time provisioning (JITP) or just-in-time registration (JITR) during the manufacturing process. Using JITP and JITR, the certificate authority (CA) used to sign the device certificate is registered with AWS IoT and is recognized by AWS IoT when the device first connects. The device is provisioned in AWS IoT on its first connection using the details of its provisioning template. For more information, refer to our whitepaper on Device Manufacturing and Provisioning with X.509 Certificates in AWS IoT Core.
If your organization is purchasing these devices commercially, either off-the-shelf or after manufacturing, device provisioning supports your organization’s technicians registering devices and installing certificates through a fleet provisioning by trusted user. Instead of a unique client certificate, devices have a temporary certificate that enables the device to connect to AWS IoT for only 5 minutes. During that 5-minute window, the trusted user obtains a unique client certificate with a longer life and installs it on the device. The limited life of the claim certificate minimizes the risk of a compromised certificate.

The second element of pedigree risk is geographic locations of origin. AWS IoT Core Device Location is a feature you can use test the location of your IoT devices using solvers from third-party vendors that resolve measurement data (Wi-Fi, cellular, IP, GNSS) and estimate the location of your device.

Reliability risks

Because Greengrass Core provides offline operation capability through local message queuing and storage, your IoT deployments benefit from being able to reliably function without continuous connectivity to the cloud or even when available bandwidth is low. AWS can help mitigate reliability issues in these ways:

Sensor degradation – If operating in an industrial context, organizations can use a purpose-built service AWS IoT SiteWise to detect anomalous sensor readings. In a security context, administrators can use AWS IoT Device Defender to define custom metrics to monitor for anomalies.
Aggregator reliability – The Greengrass nucleus component pictured in the center of the preceding diagram manages local processes on the Greengrass core, such as aggregators, and automatically recovers from failures.
Communication channel availability – AWS IoT Core implements MQTT with Quality of Service (QoS) levels (0 = best effort, 1 = guaranteed delivery) to provide reliable message delivery even during network disruptions. For edge devices, Greengrass provides offline operation capabilities, storing messages locally until connectivity is restored using components such as the disk spooler to store messages on disk.
External utility reliability – Cloud providers are classified as external utilities. AWS Global Infrastructure delivers the highest network availability of any cloud provider and is the only cloud provider to offer three or more Availability Zones in all AWS Regions, providing more redundancy and better isolation to contain issues. Further, AWS helps customers improve their reliability for IoT workloads by providing an AWS Well-Architected Framework IoT Lens with specific guidance under our Reliability pillar.
Decision trigger testing – AWS IoT Events enables you to monitor your equipment or device fleets for failures or changes in operation, and to trigger actions when such events occur. IoT Events provides a simulator for testing trigger logic before deployment. IoT developers can test their code and logic before deploying to a production environment.

Security risks

Greengrass supports secure device authentication, encryption, and access control mechanisms so that only authorized devices and users can access and interact with the IoT network.

Device tampering – AWS IoT Device Defender can monitor and detect metric anomalies on devices in these security use cases: denial-of-service attack, lateral threat escalation, data exfiltration or surveillance, cryptocurrency mining, as well as command and control, malware, and ransomware.
Unvalidated data – AWS Greengrass supports IoT developers running local AWS Lambda functions as part of their aggregators. These Lambda functions can implement validation logic on any local data being processed, validating date format and structure, value ranges, timestamps, and sensor-specific requirements.
Insecure communication channels – AWS IoT Greengrass uses TLS to encrypt all communication over the internet, using secure MQTT or HTTPS protocols. AWS IoT Core supports TLS 1.2 and 1.3, and you can configure your TLS settings.
Unhardened external utility – AWS is architected to be the most secure global cloud infrastructure on which to build, migrate, and manage applications and workloads. This is backed by the trust of our millions of customers, including the most security sensitive organizations such as government, healthcare, and financial services.
Malicious inputs – The AWS IoT Core cloud service offers rules to support devices interacting with other AWS services. These rules are expressed in SQL-like syntax and support SELECT, FROM, and WHERE clauses for conditional logic that can be used to validate inputs.

Finally, it’s worth noting that AWS IoT Greengrass core devices use X.509 certificates and cryptographic keys for authentication with AWS IoT Core. All of these features help mitigate security risks.

Conclusion

As the IoT revolution continues to shape the way we live, work, and interact with the world around us, AWS IoT Core, AWS IoT Device Defender, and AWS Greengrass are game-changing solutions for building and managing IoT networks at scale. By combining the power of cloud computing with the agility of edge computing, these services enable organizations to unlock new levels of efficiency, responsiveness, and intelligent decision-making.

Of course, cloud services and edge runtimes are not a panacea for the NIST 800-183 risks. Your organization will still be responsible for maintaining the physical security of devices, preventing local network congestion, and implementing proper hardware authentication. Although AWS provides certificate-based authentication, hardware-level security depends on device manufacturers.

Whether you’re an enterprise seeking to optimize industrial processes, a city striving to build smarter infrastructure, or a startup pioneering innovative IoT applications, AWS offers a comprehensive and robust ecosystem for realizing the full potential of the connected world. To learn more and get started, contact your AWS account team or the AWS Public Sector team.

AWS Public Sector Blog