The IoT market has grown exponentially in recent years and does not show any signs of slowing down any time soon. With the rapid growth in this area, there has been and should continue to be a strong emphasis on the cybersecurity controls being put in place to ensure the security and privacy of these connected devices, the ecosystems they interact with, and the users that are interacting with them on a day-to-day basis.

Understanding IoT Security

IoT security is a complex topic that can be approached from multiple angles. The nature of these devices inherently incorporates several different technologies that result in a full-stack attack surface that must be thoroughly evaluated. In addition to the wide array of technologies interacting with IoT devices, they are often manufactured, programmed, and operated in vastly different environments which can also produce unique attack vectors that should be considered to ensure an IoT device is secured. Finally, these devices are often designed over several months, in some cases years. This lengthy design process gives device manufacturers an opportunity and responsibility to integrate security early into the design process. Early detection of security defects can also save a significant amount of time and cost which further emphasizes the importance of extensive security testing throughout the development process.

IoT Risks

The risks introduced by IoT devices are greatly influenced by the environment in which the device resides. For example, consider a fleet device that is connected to a vehicle’s CAN bus along with various other mechanisms in the vehicle. An attacker might attempt to exploit a remote attack vector to interact with these CAN nodes to cause harm to the vehicle or jeopardize the safety of the operator. An additional vector might be a simple connected device for the operation of a seemingly innocuous consumer product, such as a kitchen appliance. If a single device were compromised it might not result in a horrible incident, however, in many cases attackers will attempt to identify a one-to-many security vulnerability. If a vulnerability like this is identified and exploited it might lead to a large-scale attack on multiple customer systems or even the infrastructure supporting operations, such as data and analytics, diagnostics, and firmware updates. Finally, consider a connected medical device that provides life-critical therapy to a patient. If a malicious user can alter the functionality of the device, either physically or wirelessly, it could potentially lead to patient harm.

Manufacturers vs. Consumers

It is crucial to consider IoT device security from two key perspectives. Consumers in most cases are the final operator of the device and have a different set of risks and mitigations that must be considered to ensure their secure operation. Manufacturers have a responsibility to enable, and in some cases force, consumers to establish security mechanisms on devices and the corresponding infrastructure. Both manufacturers and consumers should also seek to consider the challenges each other is facing and work together to establish a more secure connected world.

What Consumers Can Do

When considering the consumer’s responsibility, the customer should feel empowered to take the following steps to ensure the IoT devices they interact with are secure and do not pose a risk to their data, networks, or other assets.

• Research: Consumers should try to remain informed on the cybersecurity landscape as much as reasonably possible. A proper understanding of vulnerable technologies and attack techniques can help provide specific actions that should be taken by consumers to reduce the cybersecurity risk posture.

• Update Default Configurations: Large-scale IoT attacks have historically preyed on weak passwords or no passwords entirely. Unfortunately, most of these instances could have been avoided if consumers had taken the time to update the default password configuration. Insecure configurations are also not limited to passwords. These configurations also include things like multi-factor authentication, forced secure communications, and enrollment for software updates. Consumers should understand the capabilities of the IoT devices they use and ensure all available security features have been enabled.
• Perform Periodic Software Updates: In recent years, manufacturers have adopted the approach of forcing software updates, especially when the updates include security patches. There are still several IoT devices that do not force software updates of any kind. In these cases, consumers should take ownership of ensuring their devices are enrolled in automatic updates or periodically check for updates if necessary. Ensuring devices are at the latest firmware/software version will reduce the risk of exploitation of IoT devices being used in the field.
• Be Mindful of Trade-offs: IoT devices are generally quick to market, cheap, low power, or a combination of the three. These aspects of IoT devices have historically resulted in insecure IoT devices that often did not adequately consider cybersecurity. Thankfully, these devices are beginning to implement security controls for a variety of reasons; however, they do come with a user experience tradeoff. Consumers should understand that these impacts on user experience will result in a more secure device that will help reduce the overall cyber risk that these devices present.

What Manufacturers Should Do

The majority of the cybersecurity burden falls on the device manufacturers. It is up to them to ensure that consumers have the capability to operate IoT devices in a secure manner throughout the duration of the product lifespan. Manufacturers must integrate security activities early in the product development lifecycle to avoid delays and budget overages that often result in a business decision to descope crucial security controls. Additionally, secure development practices and requirements should take place parallel to functional development to avoid a development team solely focusing on the functionality and user experience of a given device. To further elaborate on the opportunities to employ security activities throughout the development lifecycle, seriously consider the following activities:

• Threat Modeling: Manufacturers should conduct periodic threat modeling to better understand the broader system the device interacts with, as well as the low-level implementation details. Threat modeling reviews should be held throughout development with participation from various supporting groups to identify key assets, mitigating security controls, and any existing attack vectors. It is often helpful to evaluate the cybersecurity risks revealed by threat modeling using a recognized framework, such as STRIDE, to standardize the approach. Finally, manufacturers should consider programmatic threat modeling to simplify the process of diagraming the system and encourage continuous improvement to the threat model by reducing the friction it takes to modify complex threat model documentation.
• Software Composition Analysis (SCA): A significant risk manufacturers consistently face is the risk inherited by third-party software/firmware dependencies. To help mitigate this risk, manufacturers should perform SCA when code is committed to reduce the potential of redeveloping portions of the firmware/ software due to the use of insecure libraries. If SCA is properly configured and used it will allow developers to understand the potential risks some third-party libraries pose to the product and what versions of those libraries they intend to use, so they can ensure proper mitigations are in place if necessary. Additionally, this information allows manufacturers to quickly react when zero-day vulnerabilities are discovered in their own code from these external sources.
• Static Application Security Testing (SAST): Proprietary source code can also present a cyber risk to an IoT device and its supporting infrastructure. It is crucial that manufacturers constantly scan their source code from a secure code perspective and employ secure code practices throughout the stack. Similar to SCA, SAST should take place when code is committed to make sure that insecure coding practices are identified early in the development process. It is also important to note that not all SAST tools are intended for the same use case. Security teams should evaluate the best SAST solution for the target software/firmware application depending on factors, such as coding language, target architecture, build frameworks, target operating systems, etc.
• Unit Testing: The concept of targeted testing on a small aspect of the application has been leveraged in software/firmware development for many years. These practices have historically been effective at identifying edge conditions, such as improper error handling, bounding issues, and unexpected input processing. If an attacker can find and replicate these edge conditions, they can potentially craft larger-scale or more directed attacks against the device and its ecosystem. Manufacturers should continue to approach unit testing to save time identifying functional defects while also considering the potential security threats a unit test might be able to effectively simulate.
• Penetration Testing: An invaluable aspect of any device or application is an independent penetration test with a scope that includes the full stack. This testing can help uncover any missed areas throughout development, whether it be a vector that was not considered or an invalid implementation of the intended control. The nature of penetration testing obviously does not allow for unlimited time or budget. These restrictions emphasize the need for white-box penetration testing where manufacturers provide the penetration testing team with as much information as possible to optimize their security dollars and gain an edge on a malicious user that might not be hindered by the same time and cost restrictions.
• Security Maturity Assessments: The security activities noted above are high-level and capture just some of the security steps that can be taken throughout the development of a device. In most cases, manufacturers have varying levels of security maturity in each of the development phases. A helpful first step to improving an organization’s cybersecurity maturity is to conduct an assessment to determine gaps against industry frameworks, such as the IoT Security Foundation: Security Assurance Framework and the IoT Security Maturity Model.

In addition to the security steps throughout the development process to design a secure device, manufacturers should ensure the secure operation of IoT devices that remain connected to the manufacturer’s infrastructure. This includes the ability to securely deploy updates, monitor for malicious activity, and response plans when incidents do occur.

Each security consideration mentioned here has been gaining traction in various regulatory bodies. Manufacturers should review any regulations that pertain to their specific industry to ensure robust security and regulatory compliance. Additionally, manufacturers should look to leading industry regulations, such as the FDA’s medical device premarket guidance, ISO/SAE 21434, and the upcoming Cyber Trust Mark program to get ahead of the upcoming cybersecurity expectations.

Conclusion

According to all projections, IoT devices will continue to grow rapidly. IoT is not the only growth area projected in the next few years. The explosion of AI/ML and the potential for quantum computing will have a substantial impact on all industries leveraging IoT devices, something that manufacturers and consumers alike should take into consideration. Amidst the remarkable advancements in our technological landscape, it is paramount that cybersecurity continues to hold a pivotal role in shaping our increasingly interconnected world.