As we mentioned in our last feedback blog, the NIST Cybersecurity for the Internet of Things (IoT) Program has been engaging with public, private, and academic stakeholders through conferences, meetings, and participation in roundtables at industry events. Most recently, we attended:
- The IoT Roundtable on March 29 in Washington, D.C., following the IAPP Privacy Engineering Section Forum.
- “A Discussion of IoT with NIST at Northeastern University,” on April 12 in Boston.
- Three IoT roundtables at RSA Conference 2018 the week of April 16 in San Francisco: one hosted by the Cybersecurity Coalition, the NIST-Led Discussion on Managing IoT Security and Privacy Risks, and the RSA Peer2Peer session, NIST Discussion on IoT Security and Privacy Risk Considerations.
- The 9th Annual Internet of Things European Summit on May 15 and 16 in Brussels, Belgium.
- The Mobile 360 Series – Privacy & Security on May 30 and 31 at The Hague.
These discussions have been instrumental in informing our approach as we develop an introduction to managing IoT cybersecurity and privacy risk for federal systems — an undertaking that would not be possible without stakeholder input. Below are summaries of the discussions we had at these events.
What’s in a name?
Participants agreed on the need for a common language to communicate about IoT and its associated risks. Some participants noted that any definition of IoT should be scoped to indicate what kinds of devices are and are not considered IoT. Many participants advocated for instead using categories or classifications. Some saw categories as more flexible and able to cover various aspects of IoT, including device types, use cases, and capabilities. Categories could help avoid having definitions that are too broad to be useful, and could be used to determine which controls are relevant. Participants in favor of classification noted that benefits include the ability to classify the kinds of functionality a device has; which devices are network accessible; and to differentiate between different kinds of sensors and actuators, based on how they are used and where they are deployed.
Regardless of how it is done, participants agreed that there needs to be a way to parse IoT into different buckets as the associated risks and relevant controls differ by device type, use case, and industry. Some were interested in NIST creating an IoT taxonomy to facilitate discussions, which are currently using different terminology. Discussions on how IoT differs from traditional IT went beyond definition and classification considerations, to include how these differences impact implementing cybersecurity. Further, multi-ownership was mentioned as a concern unique to IoT.
Taking in the whole picture
Participants supported taking an ecosystem approach to IoT rather than looking only at the device. The boundaries are determined by where data is sent. This includes not assuming that the device itself can provide all necessary cybersecurity capabilities. System lifecycle considerations came up in each session, with discussions on the importance of incorporating lifecycle considerations into any guidance or use case. This includes considering existing devices and planning for the integration of new ones, how old and new devices interact, and the challenges that legacy systems and devices pose to securing the overall ecosystem. The concept of a ‘gateway’ playing a role in securing IoT was discussed. Participants also noted that IoT lifecycle considerations are different from traditional IT. For example, biomedical devices are not replaced as often as laptops or mobile phones. Among the most important lifecycle considerations are updates and updatability and transference of ownership. Participants also noted the need to consider future cybersecurity requirements and how to update once new standards are created and other controls are deprecated.
Context matters
Participants noted the importance of understanding the uses of IoT and where they are deployed. Device use raised concerns as IoT devices are often used for an entirely different purpose than what they were built or purchased for. Participants noted that there are vulnerabilities and problems associated with this, depending on the system the device is integrated into and which additional systems they are moved and implemented into. As some devices are only tested for particular uses, certain risks may not be identified. Some participants suggested this could be addressed through stating the device’s intended use, then considering what else it could be used for and how that introduces new risk; others suggested this could be addressed by taking an ecosystem approach.
Others pointed out that based on the use case or context, cybersecurity and privacy might not be the most important concerns. Some indicated that safety, reliability, and resilience are fundamental and may be a higher priority, based on the use case. For example, one participant noted that in an industrial power plant, safety is far more important than privacy.
Don’t reinvent the wheel, but do set a path
Most participants favored NIST publishing guidance that is specific and points to existing cybersecurity and privacy controls. By being descriptive, stakeholders would know what is expected of them and have something to measure against. Some were interested in separating cybersecurity and privacy controls and creating overlays. For those beholden to multiple compliance regimes, decoupling cybersecurity and privacy could allow them to apply the guidance across borders. Participants offered varying perspectives on which existing controls and policies to leverage. The Cybersecurity Framework (CSF) was popular with participants; they were interested in how it could be used for managing IoT risks, including the creation of particular profiles and determining which Subcategories would be most impacted. Controls discussions also included incorporating NIST Special Publication (SP) 800-53, and the possibility of creating overlays that could include a mechanism for choosing and applying the appropriate controls.
Among the strong cybersecurity controls for IoT discussed were: audit logging, strong identity of devices, being able to turn off internet connectivity, a way to opt out of capabilities, and secure boot and secure updates. Baseline cybersecurity and privacy controls emerged as a common theme, with participants interested in NIST establishing this baseline. Some considered baselines necessary, as any device can be an entry point into the ecosystem. The baseline may not be applicable to all IoT devices, but would give stakeholders something to point to and measure against. There was also interest in a superset of controls that could be adjusted for use case or risk level, different overlays, or possibly assurance levels to tailor to the agency’s specific risk environment.
Next steps
Each of us in the NIST Cybersecurity for IoT Program is grateful for the efforts and support of the roundtable and conference organizers and the attendees who took the time to engage in meaningful, informative discussions. Having received this feedback, as well as feedback sent via email, we are now focusing on drafting an introductory publication and planning our upcoming Considerations for Managing IoT Cybersecurity and Privacy Risks Workshop at the NIST Gaithersburg campus on July 11, 2018. We hope to see you there to discuss the state of the publication and hear your feedback on the upcoming discussion draft. Until then, be sure to check out our Program page and Twitter (@NISTcyber, #IoTSecurityNIST) for updates on the event! As always, we welcome feedback on our discussion drafts at iotsecurity@nist.gov.
Add new comment