June 3, 2020

Last Updated on January 19, 2024

I am on record as largely being a very big fan of NIST guidance. My only significant complaint being that they often produce too many forms of interrelated guidance on a single subject, often cross-referenced to dozens of other NIST documents. This can sometimes make the guidance challenging to follow and fully leverage.
So is that the case with their two forms of guidance on Internet of Things (IoT) security, NISTIR 8228 (Considerations for Managing Internet of Things (IoT) Cybersecurity and Privacy Risks) and NISTIR 8259 (Recommendations for IoT Device Manufacturers: Foundational Activities and Core Device Cybersecurity Capability Baseline (2nd Draft))? Why two documents?
If you want the quick answer, you’re welcome :>).  If you want the longer answer, continue past the table.
NIST-8228 vs NIST-8259
NIST 8228 is more educational in nature: “The purpose of this publication is to help organizations better understand and manage the cybersecurity and privacy risks associated with individual Internet of Things (IoT) devices throughout the devices’ lifecycles. This publication emphasizes what makes managing these risks different for IoT devices in general, including consumer, enterprise, and industrial IoT devices, than conventional information technology (IT) devices.”
Its primary audience is “personnel at federal agencies with responsibilities related to managing cybersecurity and privacy risks for IoT devices.” In helping to explain what makes managing the risks different, the document provides a high level overview of what makes IoT devices different (data aggregation/transmission, physical security requirements, device management, privacy issues, etc.).

From my perspective, NIST 8228 sets relatively humble goals to educate those unfamiliar with IoT security issues and does a good job of achieving them.

If you have members of your design team that are not familiar with information security, it may provide some educational value there. As far as IoT testing, we recently had a client that wanted testing to ensure that his firm’s IoT devices were “NIST SP-800 8228 compliant,” which isn’t really possible as the document doesn’t provide design or control objectives to assess against.
NIST 8259 is in its second draft and “builds upon NISTIR 8228, Considerations for Managing Internet of Things (IoT) Cybersecurity and Privacy Risks.”  Where 8228 was intended for an entity using a device, NIST 8259 is intended “IoT device manufacturers.”

The focus of NIST 8259 is the six recommendations it makes to IoT device manufacturers:

  1. Identify expected customers and define expected use cases. Identifying the expected customers and use cases for an IoT device early in its design is vital for determining which device cybersecurity capabilities the device should implement and how it should implement them.
  2. Research customer cybersecurity goals. Manufacturers cannot completely understand all of their customers’ risk because every customer faces unique risks based on many factors. However, manufacturers can make their devices at least minimally securable by expected customers who use a product consistent with its expected use cases.
  3. Determine how to address customer goals. Manufacturers can determine how to address those goals by having their IoT devices provide particular device cybersecurity capabilities in order to help customers mitigate their cybersecurity risks. To provide manufacturers a starting point for identifying the necessary device cybersecurity capabilities, NIST 8259 defines a core device cybersecurity capability baseline, which is a set of device cybersecurity capabilities that customers are likely to need. These include:
    • Device Identification: The IoT device can be uniquely identified logically and physically.
    • Device Configuration: The configuration of the IoT device’s software and firmware can be changed, and such changes can be performed by authorized entities only.
    • Data Protection: The IoT device can protect the data it stores and transmits from unauthorized access and modification.
    • Logical Access to Interfaces: The IoT device can restrict logical access to its local and network interfaces, and the protocols and services used by those interfaces, to authorized entities only.
    • Software and Firmware Update: The IoT device’s software and firmware can be updated by authorized entities only using a secure and configurable mechanism.
    • Cybersecurity State Awareness: The IoT device can report on its cybersecurity state and make that information accessible to authorized entities only.
  1. Plan for adequate support of customer goals. Manufacturers can help make their IoT devices more securable by appropriately provisioning device hardware, firmware, software, and business resources to support the desired device cybersecurity capabilities.
  2. Define approaches for communicating to customers. Many customers will benefit from manufacturers communicating to them—or to others acting on the customers’ behalf, such as internet service providers or managed security services providers—more clearly about cybersecurity risks involving the IoT devices the manufacturers are currently selling or have already sold.
  3. Decide what to communicate to customers and how to communicate it. There are many potential considerations for what information a manufacturer communicates to customers for a particular IoT product and how that information will be communicated. Examples of topics are:
    • Cybersecurity risk-related assumptions that the manufacturer made when designing and developing the device
    • Support and lifespan expectations
    • Device cybersecurity capabilities that the device provides, as well as cybersecurity functions that can be provided by a related device or a manufacturer service or system.
    • Device composition and capabilities, such as information about the device’s software, firmware, hardware, services, functions, and data types
    • Software and firmware updates
    • Device retirement options

NIST 8259 then enumerates each of the above recommendations in greater detail to make them directly actionable. As you might imagine, getting NIST 8259 into the hands of your product/design/security team as early in the process as you can is ideal. While I don’t think that NIST 8259 is as comprehensive as it could be, it’s still excellent guidance.
While NIST 8259 is not specifically targeted to testing/certification of IoT devices, it has some good guidance that can easily be converted into testing criteria.  For example, in Section 3.3 it puts a lot of the potential criteria for testing into a table, along with “Key Elements” that can directly be used for assessing whether the devices achieve its target “Cybersecurity Capability.” Even better, the table is cross-referenced to some of my other favorite forms of IoT security guidance, including CIS and ENISA.
For the record, I would like to see cross-references to the OWASP ASVS and OWASP IoT Top 10 guidance in the final document.
We are “fans” of NIST 8259 and often use it in concert with SB-327, OWASP ASVS, OWASP MASVS and CREST for our IoT testing.