NIST is seeking comment on the document through September 30 of this year and it held a workshop in August for interested parties to discuss the document. In a prior post, I blogged on takeaways from that workshop. Now, it’s time to take a closer look at the NIST document itself.

Overview of the Baseline

The NIST Baseline (“NISTIR 8259” in government-speak) is subtitled “A Starting Point for IoT Device Manufacturers,” and it is intended as just that. NISTIR 8259 builds upon a base document released in final form on June 27, 2019 relating to cybersecurity and privacy risks for the Internet of Things. IoT manufacturers should review NIST’s Considerations for Managing Internet of Things (IoT) Cybersecurity and Privacy Risks before digging into the Baseline document. Considerations (also known as NISTIR 8228) identifies high-level considerations that make IoT security different than IT security and offers suggestions for mitigating cybersecurity and privacy risks. Its intended audience primarily are the users and organizations deploying IoT devices, but it has meaning for manufacturers, network operators and service providers in the space as well.

The NIST Baseline takes these considerations to the manufacturing side, offering (as NIST describes it) to help IoT device manufacturers “understand the cybersecurity risks their customers face” so IoT devices can provide the minimal features to make them securable. (For a discussion of the different meanings that “securable devices” can have in this context, see my blog post on the NIST workshop.)

Securing IoT Devices

The NIST Baseline explains that cybersecurity risks for IoT devices have two high-level risk mitigation goals: protecting device security and protecting data security. As noted in the user-focused Considerations document, the challenges in doing so stem from three features of the Internet of Things:

1. IoT devices interact with the physical world in ways conventional IT devices usually do not. (In other words, they are, by their nature, connected devices.);
2. Many IoT devices cannot be accessed, managed, or monitored in the same ways conventional IT devices can; and
3. The availability, efficiency, and effectiveness of cybersecurity features are often different for IoT devices than conventional IT devices.

For the “core,” NIST identifies six features that IoT devices should address:

1. Device Identification. How the IoT device can be uniquely identified, both logically and physically.
2. Device Configuration. How the device’s software and firmware can be changed and who is authorized to make such changes.
3. Data Protection. How the device can protect from unauthorized access and modification the data that it stores and transmits.
4. Logical Access to Interfaces. How the device can limit (logical) access to its local and network interfaces so that only authorized users may access these elements.
5. Software and Firmware Updates. How the device can be updated by authorized entities only, using a secure and configurable mechanism.
6. Cybersecurity Event Logging. How the device can log cybersecurity events and make the logs accessible to authorized entities only.

Separate from the core features, the NIST Baseline also discusses two areas relevant to securing IoT devices. First, it discusses considerations for implementation of these features in the design and manufacturing process. Second, it discusses considerations in communicating these features and the cybersecurity risks of IoT devices to the manufacturer’s customers and users of the device (users who may not necessarily have been the ones to purchase or configure the device).

Issues for Comment

Unlike FCC or FTC notices seeking comment, the NIST Baseline does not provide specific questions or issues for comment. Instead, the Baseline simply seeks feedback from all stakeholders on the draft, in order to assist NIST in refining the document.

The NIST workshop that I attended offers some insight into the comment areas that NIST would find helpful. In the discussion group sessions, NIST first asked whether the six core features were sufficient, and whether any other considerations should be added to the list. My group spent a lot of time discussing the relationship between the Baseline and efforts to create industry-specific standards or best practices. NIST seemed very interested in determining whether the Baseline would serve as a useful starting point for those efforts.

Second, the discussion group was asked whether customer communication should be a core feature or a separate consideration (as in the draft now). This seemed to focus on the role that shared responsibility among manufacturers, users, control organizations (like a corporate IT group) and/or the government played in securing devices (or making them securable).

Finally, our discussion group was asked about two potential additions to the Baseline. First, we were asked whether considerations in protecting legacy devices in an IoT network should be added. This question raised the issue of the role a single IoT device plays in a larger network, such as a smart home configuration where multiple devices (potentially from multiple manufacturers) are controlled by a central hub device. Second, we were asked whether exterior threats to the devices, such a DDoS attack or botnet attacks, should be part of the Baseline.

Any and all of the above should be fair game for comment to NIST on the Baseline. Comments on the NIST draft may be submitted through September 30. Kelley Drye is working with device manufacturers on potential comments to NIST. If you are interested in submitting comments, please feel free to contact us.

On October 22, 2013, the Consumer & Government Affairs Bureau of the FCC extended its review of the petition. It did so by granting a temporary waiver – until January 28, 2014 – for compliance with its ACS rules to a class of e-reader equipment. The waiver noted that over the next three months, the Consumer and Governmental Affairs Bureau would further evaluate the primary purpose of the e-reader equipment in question and examine the product life cycle of such e-readers to determine the appropriate duration of any further waiver, should it be granted.

The waiver applies only to e-reader devices that: (1) have no LCD screen; (2) have no camera; (3) are not offered or shipped to consumers with built-in ACS client applications, though the devices may include a browser and social media applications; and (4) are marketed to consumers as reading devices and promotional material does not advertise the capability to access ACS.