IoT devices built to meet cybersecurity needs

IoT devices built to meet cybersecurity needs

The Internet of Things (IoT) includes things like smart devices, smart watches, and medical sensors. For organizations to enjoy the full benefits and convenience of IoT devices, enterprise customers must fully understand the risks and potential threats to their underlying data and systems. IoT devices often lack built-in security controls, a situation that creates risks and threats to federal agencies and consumers.

As IoT devices proliferate, it is important for manufacturers to provide safe and secure devices. According to NIST, built-in security controls include device cybersecurity capabilities as well as cybersecurity-relevant non-technical support. Both can be used to mitigate risks related to IoT devices.

IoT device non-technical support capabilities

Cybersecurity Program for the Internet of Things (IoT) of the National Institute of Standards and Technology (NIST) announced the drafting of four public documents that provide guidance for federal agencies and IoT device manufacturers on defining IoT cybersecurity requirements. The purpose of this initiative is to help manufacturers and federal government agencies better understand what types of device cybersecurity capabilities and non-technical support capabilities may be required from or around IoT devices used by government agencies. federal.

Distinguishing between technical and non-technical means of protecting IoT devices, NIST notes that IoT devices are protected primarily through technical means, referred to as “device cybersecurity capabilities,” and that non-technical support capabilities include actions that take manufacturers or third parties. in support of initial and ongoing security of IoT devices.

The purpose of NIST Internal Report (IR) 8259B, Non-Technical Support Capabilities The publication is to provide organizations with a starting point that they can use to identify the non-technical support capabilities required in relation to the IoT devices they intend to manufacture, integrate, or acquire. This publication is intended to be used in conjunction with NISTIR 8259, Fundamental Cybersecurity Activities for IoT Device Manufacturers Y NISTIR 8259A, IoT Device Cybersecurity Capability Basic Baseline.

As an example, let’s say an agency wants to purchase an IoT device such as a smart speaker for use in the office. The smart speaker will need to connect to the federal information system so that agency management can remotely access and play audio through the speaker. These remote connections will require proper authentication and authorization. To support authentication and authorization controls, the smart speaker may require device cybersecurity capabilities, such as the ability to deny remote connections, the ability to authenticate and/or authorize entities attempting to make remote connections, and the ability to terminate connections within organization policy.

Additionally, assigned security controls may require the federal agency to configure the smart speaker to authenticate and authorize users within organization policy, which may require non-technical support capabilities from manufacturers. These non-technical support capabilities may include obtaining documentation from the manufacturer on how the IoT device can be configured to support the organization’s authentication and authorization policy.

The wide range of connectivity possible for IoT devices and the ability of these devices to interact with the physical world means that protecting these devices often becomes a priority but also a challenge for customers when not properly supported.

The role of manufacturers in protecting IoT devices

Integrating an IoT device into an information system can present a number of challenges for enterprise customers. However, understanding the challenges will help manufacturers execute the most appropriate deployment strategy for non-technical support capabilities. NIST recommends that manufacturers consider the following non-technical support capabilities for the IoT devices they manufacture:

  • Documentation: The manufacturer’s ability to create, collect, and store IoT device cybersecurity-relevant information throughout a device’s development and subsequent lifecycle.
  • Reception of Information and Consultations: The ability of the manufacturer to receive information and queries related to the cybersecurity of the IoT device from the customer.
  • Dissemination of information: The manufacturer’s ability to transmit and distribute information related to the cybersecurity of the IoT device.
  • Education and Awareness: The manufacturer’s ability to raise awareness and educate customers on information, considerations, features, etc., related to IoT device cybersecurity.

NIST notes that these four items do not represent an exhaustive list and that if additional support capabilities are needed to enable safe use of the device, organizations are encouraged to consider defining additional support capabilities for their particular use case.

NIST IoT Devices Roundtable Discussions

NIST engaged the stakeholder community on the topic of IoT non-technical support capabilities at four round tables corresponding to each capacity area. Feedback from the roundtable sessions shows that while participants found value in all four capabilities, they also expressed that the capabilities may need to be tailored to specific audiences and use cases.

There is no shortage of reports, white papers and blogs related to cybersecurity awareness and training. What about consumer safety awareness? Feedback from the roundtable session revealed that there is a general need to inform customers on how they can safely operate the IoT device, for example by displaying relevant warning labels related to changing the device’s default password and providing instructional content to consumers. Participants noted that the approach to raising awareness could involve online videos and smartphone apps.

Another takeaway from the roundtable sessions was that IoT product owners need vulnerability information and patches to mitigate the risks associated with known vulnerabilities. Specifically, participants expressed a desire to learn about vulnerabilities and patches in IoT products, as well as for manufacturers to provide guidance outlining where consumers can find this type of information. Some participants suggested that Information Sharing and Analysis Center (ISAC) information sources would be a good source of advice for customers of IoT products regarding vulnerabilities and patches. As a starting point, the NIST blog recommends ISAC National Council.


Mitigating the risks associated with IoT devices using non-technical support capabilities could be perceived as a burden for manufacturers (for example, providing customers with standardized documentation, training material in various forms for a variety of customers, and increased consumer safety awareness). IoT device manufacturers are in the best position to communicate important non-technical information related to device cybersecurity. They play a very important role in helping enterprise customers and consumers protect IoT devices. Providing customers and consumers with non-technical capabilities for an IoT device complements the cybersecurity capabilities of the device and strengthens the ability to maintain the ongoing security of the IoT device.

Manufacturers that understand and can support an organization’s cybersecurity needs in a non-technical way, as well as those that provide their customers with the knowledge on how to effectively use device cybersecurity capabilities, help build trust between them and their clients. They also support mitigation of the risks inherent in IoT devices, thereby improving the overall security of associated systems and underlying data.

ambler jacksonAbout the Author: Ambler is an attorney with experience in corporate governance, regulatory compliance, and data privacy. He currently consults on governance, risk and compliance; enterprise data management, as well as data security and privacy issues in Washington, DC.


Twitter: @amblerjackson

Publisher’s note: The views expressed in this guest post are solely those of the contributor and do not necessarily reflect those of Tripwire, Inc.

Leave a Comment