The number of Internet of Things (IoT) devices is increasing at a pace where owners can’t keep up with device updates and secure configurations. Statista reports that the total number of IoT devices is expected to reach 30.9 billion units in 2025. That’s more than double the 13.8 billion devices that were connected in 2021.
Simultaneously, there is a lack of skilled expertise when it comes to securing IoT. This is changing … but slowly and partially. Documentation resources for IoT security, such as moving toward labels and other guidance for enterprises, are increasing. However, when the Center for Internet Security (CIS) surveyed the market resources available, there was no guide aimed at vendors for embedding IoT security.
Given this discrepancy, we decided we wanted to assist vendors with decisions on which protocol stack makes the most sense for their product and what their security options are within that protocol stack. As a result, we created the whitepaper, Internet of Things: Embedded Security Guidance.
In this blog post, I’ll describe the purpose of the whitepaper, go over what it contains, and discuss how you can use it.
IoT security built-in and by default
Embedded IoT security is increasingly important. Attackers target IoT because it’s a possible entry point into corporate (and home) networks. While a gateway can help to protect devices, attackers can bypass the gateway in many instances. Additionally, embedding security reduces the need for add-on or bolt-on security products and approaches. At the very least, this makes it more difficult for cyber threat actors (CTAs) to conduct an attack. It’s no surprise that the White House’s Executive Order 14028, ‘Executive Order on Improving the Nation’s Cybersecurity‘, and its follow-on documentation identified security that’s built-in by design and by default as an important theme for IoT devices.
To achieve embedded IoT security, vendors need resources that help them understand the necessary security requirements and how they can meet them. Take the design phase of an IoT product, for instance. The team has certain constraints that require consideration and that drive a decision to one of many protocol stacks to support those constraints. Since there are upwards of 10 protocol stacks, vendors would need to perform significant research to find what’s most applicable. They would also need to spend time researching the security capabilities that are either intrinsic to the protocol or available as optional extensions.
This is unrealistic. There has to be a better way.
Two defining characteristics of the whitepaper
Developed and vetted by industry experts, Internet of Things: Embedded Security Guidance aims to provide a resource to IoT vendors to ease the process of building security by design and by default. It does this with the four different IoT communication and data-sharing patterns in mind.
Our whitepaper stands out in two ways:
- Prescriptive recommendations. It includes recommendations for security options to better scale management and ‘shift it left’ to the vendor when possible (CIS members along with small- and medium-sized businesses are particularly interested in scale to reduce resource requirements). We conducted significant research to develop these recommendations and lessen the burden on individual developers from having to perform it themselves.
- Vetted research. It pulls from IoT industry experts engaged with vendors, standards work, and government to better understand the potential set of protocols that can be used. Additionally, it details the security options available within each of those protocol stacks. The research and verification takes an effort that many development teams do not have the time for when building a product and meeting timelines. This also brings forward all of the security options to ease that process for vendors. They might select a different protocol stack with different security options by having the ability to easily compare these options.
Get the conversation going
Our aim is to maintain this as a resource if it is found to be beneficial. As a reader, you can learn about options to enable security management at scale, such as the Manufacturer Usage Description (MUD) documented in RFC 8520 as well as the resources available to implement MUD. You can also use it to advocate for greater levels of IoT security in your organization and countless others.
A bright future for embedded IoT security
If security is built in, enabled by default, and managed at scale by the vendor, the overall security landscape will improve.
If you’re an organization, you can begin the conversation with your vendors on embedded IoT security requirements for your products. You can specifically use this document as an educational tool and potentially provide it as a guide for the vendor.
Currently, the burden for IoT security fully rests with you, where it’s your responsibility to add on security to protect products and services using resources such as the CIS Controls v8 Internet of Things Companion Guide. By embedding security and changing the expectations for security to be built in, we may be able to reduce the overall costs for security as well as reduce the distributed management burden.
We want to hear from the community and understand if this whitepaper is helpful. We’re also interested to learn what supplemental resources might aid in improving security to provide meaningful resources that assist in the ‘shift-left‘ security movement.
If security is built in, enabled by default, and managed at scale by the vendor, the overall security landscape will improve. While there is always a way in for an attacker, measures to build in security increase the costs to the attacker and may help shift attackers away from the cyber under-resourced.
Kathleen Moriarty is Chief Technology Officer at the Center for Internet Security and the former IETF Security Area Director. She has more than two decades of experience working on ecosystems, standards, and strategy.
Adapted from this post on CIS Blog.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.