NISTIR 8259: Securing IoT Devices of Tomorrow

Written by Asher Andree | Aug 17, 2020, 4:00:00 AM

How IoT device manufacturers can use guidance from NISTIR 8259 to secure the IoT devices of tomorrow. The growing footprint of the Internet of Things (IoT) has already affected our world in a capacity much larger than we have ever expected. Think of home devices like Amazon’s Alexa, “smart” fridges, or even the baby monitor you use at home. The list of IoT devices is ever-growing. With a growing list of devices also comes a growing list of security weaknesses: the recently disclosed Ripple20 zero-day exploit which put millions of devices at risk, or the Mirai botnet attacks of 2016, to name a few. It’s safe to say that this will continue to be a problem for our manufacturers and end-users for years to come. So, how can manufacturers of the devices of tomorrow begin to ensure that the products they develop are secure?

Enter NISTIR 8259: A Guide to IoT Security

Recommendations from the National Institute of Standards and Technology (NIST), in the form of NISTIR 8259 “Foundational Cybersecurity Activities for IoT Device Manufacturers” aims to answer this question. At a high level, the publication’s main purpose is to give guidance on improving how securable a manufacturer’s devices are. It’s intended for a wide range of IoT devices, but only those that are newly developed. A crucial aspect of the document is that it’s not meant to be a retroactive band-aid for devices already out on the market. This will become clear as we get down in the details. Why does this matter, and why is the document necessary? Exploits harm devices. Hackers harm customers through IoT shortcomings. Businesses burn cash addressing risks from devices. This cumulation creates the desire and the need for an industry-standard framework. Also, like we mentioned earlier, the number of IoT devices is growing. You can think of it as the wild west of IoT. In short, the guidance addresses our initial question directly by providing six clear steps that manufacturers should follow: These six steps are further separated into two phases:

Pre-Market: before the device is sold
Post-Market: after the device is sold

Because over half of the recommendations are specifically for a manufacturer to perform before releasing their product, NISTIR 8529 cannot be applied to IoT devices already on the market. Let’s take a look at these steps in more detail.

Pre-Market Phase Activities Impacting the Security of IoT Devices

For the purposes of this blog post, we’ll cover the Pre-Market steps (1-4). Be on the lookout for part two of the series, where we will cover the Post-Market (5-6) recommendations.

Activity 1: Identify Expected Customers and Define Expected Use Cases

The first activity is determining the expected customers of the device. This should occur early in the development lifecycle and is crucial in understanding what kind of cybersecurity functionality should be made available to the customer. An example of this would be a company that is manufacturing baby video monitors. What type of customer is purchasing this kind of product? What are the various use cases, and what cybersecurity capabilities would these customers expect on their purchased device? Defining the customer base can be simplified into two questions:

Which types of people will be purchasing the device?
Which types of organizations will be purchasing the device?

Additionally, IoT device manufacturers can use the following questions to define the use cases for their devices. This is based on how " they anticipate the device will be reasonably deployed and used."

How will the device be used?
Where geographically will the device be used?
What physical environments will the device be used in?
What dependencies on other systems will the device likely have?
How might attackers misuse and compromise the device within the context of the use case?
What other aspects of device use might be relevant to the device's cybersecurity risk?

Manufacturers of IoT devices should use these questions as a guide for gathering expected customer types and their use cases.

Activity 2: Research Customer Cybersecurity Goals

With the client-profile and use cases defined, the manufacturers can begin to research what their cybersecurity goals might be. While every customer and IoT device encounters unique risks, manufacturers must investigate all reasonable use cases to attempt to define the core cybersecurity goals of their end-users. The overall goal for this activity is to ensure the device is developed to be “ minimally securable.” Minimally securable means that the device includes the minimal capabilities a customer may need to address cybersecurity risks. Let’s say that you get a new front door installed, but you notice after installation that there’s no lock on the door. Would this be minimally securable? Cybersecurity risks for IoT devices can be summed up into two high-level goals:

Protecting the confidentiality, integrity, and availability of the device itself

This goal includes preventing the device from impacting the customer or other organizations. Think of large botnet attacks of the past. These botnets used thousands of compromised IoT devices to perform distributed denial of service (DDoS) attacks. It’s safe to say this first goal is crucial.

Safeguarding the confidentiality, integrity, and/or availability of data (including PII) collected, stored, processed, or transmitted by the device.

This risk directly impacts every customer. A home security solution could contain multiple videos of you and your family. Would you want a hacker gaining access to this info? In 2019, a hacker successfully targeted a Nest camera to impact an end-user. This exploit allowed the adversary to talk to the user through their own camera.

To help gather information on customer goals, manufacturers should answer the following questions for each of the expected device use cases:

How will the device interact with the physical world?Anticipate the potential impact of an IoT device making changes to physical systems. In some cases, performance requirements might stand at odds with cybersecurity goals.
How will the IoT device need to be accessed, managed, and monitored by authorized people, processes, and other devices? Examining the methods used by customers to manage the device is of crucial importance. Generally, an organization will appreciate a device with multiple configurations and features more so than a home or consumer client.Consider “an IoT food vending machine in a public place, which is internet-connected so suppliers can track inventory and machine status. Vending machine users would not be required to authenticate themselves in order to insert money and purchase a snack. However, the vending machine would also be highly susceptible to physical attack."
How will the IoT device's use of device cybersecurity capabilities be affected in terms of the device's availability, efficiency, and effectiveness? Think of a device on a low bandwidth network - will it possess the ability to download large firmware updates from the supplier? Probably not.
What will the nature of the IoT's device's data be? Understanding what type of data, the IoT device will encounter will directly impact the type of cybersecurity controls a customer should rightly possess to secure the IoT device. For example, data encryption functionality should be offered for a device that stores PII but may not be necessary for a device that does not store any data.
What are the known cybersecurity requirements for the IoT device? Identify known laws and regulations (often country-specific) and be mindful of those during capability identification.
What complexities will be introduced by the IoT device interacting with other devices, systems, and environments? An example would be the complexities introduced by a smart oven or thermostat. What kinds of risks would be introduced by the ability to remotely heat your oven to 400º, or to set it for 450º indefinitely?

Activity 3: Determine How to Address Customer Goals

Manufacturers should now have a working idea of their expected customers, their use cases, and their cybersecurity goals. Now it is up to the device producer to define how those goals will be reached. For each cybersecurity goal, the manufacturer must answer this question: Which one or more of the following is a suitable means (or combination of means) to achieve the goal?

The IoT device can provide the technical means through its device cybersecurity capabilities (for example, by using device cybersecurity capabilities built into the device's operating system, or by having the device's application software provide device cybersecurity capabilities).
Another device related to the IoT device (e.g., an IoT gateway or hub also from the manufacturer, or a third-party IoT gateway or hub) can provide the technical means on behalf of the IoT device (e.g., acting as an intermediary between the IoT device and other networks while providing command-and-control functionality for the IoT device).
Other systems and services acting on behalf of the manufacturer can provide the technical means (e.g., a cloud-based service that securely stores data for each IoT device).
The customer can select and implement other technical and non-technical means for mitigating cybersecurity risk. The customer can also choose to respond to cybersecurity risk in other ways, including accepting or transferring it. For example, an IoT device may be intended for use in a customer facility with stringent physical security controls in place.

One thing to note is that there may not be a perfect one-to-one relationship between a cybersecurity goal and the technical means to reach that goal. As stated within NISTIR 8259: “it may take multiple technical means to achieve a goal, and a single technical means may help address multiple goals." In addition to identifying means, manufacturers must also answer the following question: How robustly must each of the technical means be implemented in order to achieve the cybersecurity goal? Here are some example considerations in light of the previous questions:

Does a technical mean need to be implemented in hardware or can it be implemented in software instead?
Which data needs to be protected, what types of protection does each instance of data need (e.g., confidentiality, integrity), and how strong does that protection need to be?
How securely does an entity's identity need to be authenticated before granting access (e.g., PIN, password, passphrase, two-factor authentication)?
How readily can software and firmware updates be reverted if a problem occurs (e.g., a rollback capability, an anti-rollback capability)?

Ultimately, the manufacturer must look to the following question to direct technical means identified for all the cybersecurity goals of the device: Which technical means will be provided by the IoT device itself, by other devices related to the IoT device, by other systems and services acting on behalf of the manufacturer, and by the customer, and how robust should each of those means be? At this point, the term “technical control” might still be a little unclear. Luckily, NIST provides the following table which defines technical controls as the following core capabilities:

Activity 4: Plan for Adequate Support of Customer Goals

We’re almost finished with the Pre-Market Phase. Let’s take a second to breathe and recap. We’ve identified our customers and their use cases. We’ve also taken the time to figure out what our customers’ cybersecurity goals might be, and how to address them. Now that we’ve made all this progress, how do we account for support of these goals over a period of time? It’s important for manufacturers to plan to support their customers' goals once they are identified. Often, this be can achieved by ensuring the device has adequate hardware, firmware, and software design considerations taken into account. For this topic, manufacturers should answer the following questions:

What potential future use should be taken into account? Think about the device's lifespan. For example, in a five-year period, the device's cryptographic key length may need to be updated.
Should an established IoT platform be used instead of acquiring and integrating individual hardware, firmware, and software components? Instead of designing hardware, firmware, or software, the developer may be able to use third-party pre-developed solutions.
Should any of the device cybersecurity capabilities be hardware-based? Note that sometimes including functionality in hardware reduces agility in later efforts.
Does the hardware, firmware, or software (including the operating system) include unnecessary device capabilities with cybersecurity implications? If so, can they be disabled to prevent misuse and exploitation? Open USB ports or additional networking capabilities (SSH or telnet), for example, are functionalities that introduce additional cybersecurity risk and may not be needed.

Manufacturers should also consider secure development practices that are appropriate for the customers and their goals. The following questions will help device developers approach this consideration:

How is the IoT device code protected from unauthorized access and tampering?
How can customers verify software integrity for the IoT device?
What verification is performed to confirm that the security of third-party software used within the IoT device meets the customers' needs?
What measures are taken to minimize the vulnerabilities in released IoT device software?
What measures are taken to accept reports of possible IoT device software vulnerabilities and respond to them?
What processes are in place to assess and prioritize the remediation of all vulnerabilities in IoT device software?

Wrapping Up Our Pre-Market Activities and Looking Towards the Future

And just like that, we’ve made it to the end of the pre-market cycle. You might notice that this framework ensures that we're asking the right questions (at the right times). I hope that at this point it’s easy to tell how much consideration really needs to happen before a device can hit the market. Think about the IoT devices you may already interact with. Do you think that the developers took all these questions into account? Have the technical means provided by the device met your cybersecurity goals? It’s really exciting to see frameworks like this created to address the downfalls that we’ve seen in the past. We can only hope that guidance like this will be used by device makers, and lead us to a safer tomorrow. Be on the lookout for part two, where we’ll cover what manufacturers should perform after their device hits the market.

View full post