Background Information and FAQs on Draft NISTIR 8259: Core Cybersecurity Feature Baseline for Securable IoT Devices: A Starting Point for IoT Device Manufacturers

During the public comment period for draft NISTIR 8228, Considerations for Managing Internet of Things (IoT) Cybersecurity and Privacy Risks, we received more than 25 sets of comments from stakeholders across a number of industries, including comments on Appendix A (which was included in the draft version). While the content of draft NISTIR 8228 focused on guidance for the organizations that are using IoT in their organization, Appendix A focused on security and privacy capabilities of IoT devices. Comments indicated a demand for NIST to further elaborate on the concept of baseline security capabilities for IoT devices.

To kick off this effort, we removed Appendix A from the final version of NISTIR 8228, incorporating an edited version of the cybersecurity capabilities it originally contained into a discussion essay released in February 2019, Considerations for a Core IoT Cybersecurity Capabilities Baseline.

Over the last few months, NIST held and participated in a number of outreach events seeking feedback on the discussion essay which informed the evolution of the content of Draft NISTIR 8259. The following are answers to the questions we anticipate being most pressing to stakeholders who generously provided a wealth of valuable feedback throughout the engagement efforts that informed Draft NISTIR 8259.

What happened to NISTIR 8228 Appendix A?

The initial draft of NISTIR 8228 included an appendix (Appendix A) that contained 15 examples of security and privacy capabilities that might be suitable for inclusion in a core cybersecurity and privacy baseline. Based on feedback received during the NISTIR 8228 public comment period and other stakeholder engagement efforts, NIST identified a critical gap area in guidance on baselines for IoT device cybersecurity. This feedback also tied back to the Report to the President on Enhancing the Resilience of the Internet and Communications Ecosystem Against Botnets and Other Automated, Distributed Threats (the Botnet Report) which Department of Commerce and Department of Homeland Security delivered to the President in May 2018 in response to a May 2017 Executive Order issued by the President, Strengthening the Cybersecurity of Federal Networks and Critical Infrastructure. IoT security is identified as a key  component of the report, laying out an action plan and subsequent Roadmap to establish a robust market for trustworthy IoT devices, including tasks ranging from establishing a core baseline, exploring considerations for labeling and conformity assessment schemes, and promoting consumer awareness and international standards engagement.

Accordingly, NIST identified a critical gap area in guidance on baselines for IoT device cybersecurity, so we removed Appendix A from NISTIR 8228, incorporating an edited version of the cybersecurity capabilities it originally contained into a discussion essay released in February 2019, Considerations for a Core IoT Cybersecurity Capabilities Baseline.

How did 15 “capabilities” become six “features”?

Of the 15 capabilities from Appendix A of draft NISTIR 8228, four were related to privacy, something that subsequently shifted to being addressed in the NIST Privacy Framework that is currently under development, which left 11 cybersecurity capabilities. The next step was developing and applying a set of criteria for assessing the candidate capabilities in order to determine which candidates were appropriate to include in the core baselines. The Considerations for a Core IoT Cybersecurity Capabilities Baseline draft essay released in February 2019 defined the following criteria and used them to assess each of the candidates:

1. Utility: How critical is the capability towards improving the cybersecurity of IoT devices and data?
   1. When used alone, does the capability directly improve the cybersecurity?
   2. Do other cybersecurity capabilities rely on this capability to function?
   3. Which cybersecurity risk mitigation areas does the capability help achieve?
2. Verifiability: Can proper implementation of the capability be verified?
3. Feasibility: Are there roadblocks to implementing the capability that will make the device overly costly or complex, or less interoperable?
   1. Are the hardware, firmware, software, services, or protocols needed to implement the capability limited in availability or not industry accepted?

Based on ongoing internal research and discussions, as well as feedback from external stakeholders on the draft essay, six candidates were moved to Section 4 of draft NISTIR 8259 and a new candidate on device reset was added. Subsequent revisions caused the new device reset capability to be merged into the data protection capability. Feedback also indicated potential confusion between draft NISTIR 8259’s usage of the word “capabilities” and the usage within other NIST cybersecurity publications, such as NIST SP 800-53 Revision 4, so we decided to use the term “features” in draft NISTIR 8259 instead of “capabilities” to avoid confusion.

Why does Draft NISTIR 8259 venture into feature implementation and guidance on communicating with customers?

The draft essay published in February focused only on our initial thoughts about a core IoT cybersecurity capabilities baseline, yet Draft NISTIR 8259 ventures beyond merely identifying a core set of cybersecurity features with sections on feature implementation and cybersecurity information to provide to customers. Why?

We recognize that the ecosystem of IoT devices is diverse and will only become more so as technology continues to progress, and also that differences in devices, end users and other factors mean that one size will never fit all when it comes to which cybersecurity features manufacturers should implement. Section 5 of draft NISTIR 8259 discusses how the implementation of cybersecurity features  should take into account customer and device ecosystems.

Many customers will benefit from manufacturers communicating to them more clearly about cybersecurity risks involving their IoT devices. We included examples of the types of information that may be particularly beneficial to communicate to customers to help guide manufacturers as they present information to the various customers they serve, especially in enterprise environments. The examples are not unique to IoT, and they will not necessarily apply to all IoT devices a manufacturer produces; however, the information is supportive of and particularly applicable to IoT cybersecurity, and is likely to address cybersecurity challenges currently affecting many IoT devices and customers.

What type of feedback is NIST looking for?

NIST welcomes feedback on any part of the publication, but there is particular interest in the following:

1. Section 3 is intended to help IoT device manufacturers better identify the cybersecurity risks their expected customers (individuals and organizations) are likely to face, instead of assuming a generic set of risks faced by a generic set of customers. This would help manufacturers identify the cybersecurity features their customers need their IoT devices to have. Is the proposed process for identifying features appropriate and reasonable? If not, how can it be improved?
2. Are the cybersecurity features and the key elements of those features defined in Section 4 the right set for an  IoT device baseline? If not, which cybersecurity features and key elements should be added, removed, or changed, and why?
3. We have received considerable feedback that consumers need more information about their IoT devices to understand  and address the cybersecurity risks for those devices. Feedback on how useful the communication considerations outlined in Section 6 may be for consumers and manufacturers, as well as how the considerations can be improved, is particularly important.
4. We received feedback as well about the criticality of an organization’s policies and processes to producing a securable device, and while not part of the baseline we felt it useful to highlight secure development practices in Section 7.
5. Are there gaps in the guidance we are providing for IoT manufacturers?