Cybersecurity is a relatively new challenge for many IoT device makers who have traditionally produced non-connected devices. These devices were less vulnerable to exploitation and, as a result, manufacturers often lack the expertise and experience needed to effectively secure their connected products.
IoT devices are built on a foundation of insecure software—a large portion of the open-source software and the chips used to build devices are poorly secured. Chipmakers are constantly getting caught sneaking hidden APIs that deeply compromise the security of their silicon. Open-source software is not much better. Most open-source OSes used in IoT haven’t been scrutinized and haven’t gone through robust static analysis and fuzzing.
Customers, users, and regulators do not have good tools or frameworks to evaluate the security of the devices they buy. Say what you will about SOC2 or ISO 27001, but they successfully establish a floor of security that customers have learned to demand. Not so in the IoT space, where no standard has reached any level of consensus. This leaves ad hoc analysis as the only viable approach to risk management.
IoT security regulation
Up to now, the IoT industry has relied mainly on security by obscurity and the results have been predictable: one embarrassing compromise after another. IoT devices find themselves recruited into botnets, connected locks get trivially unlocked, and cars can get remotely shut down while barreling down the highway at 70mph. Even Apple, who may have the most sophisticated hardware security team on the planet, has faced some truly terrible security vulnerabilities.
Regulators have taken note, and they are taking action. In September 2022, NIST fired a warning shot by publishing a technical report that surveyed the state of IoT security and made a series of recommendations.
This was followed by a voluntary regulatory scheme—the Cyber Trust Mark, published by the FCC in the US—as well as a draft regulation of European Union’s upcoming Cyber Resilience Act (CRA). Set to begin rolling out in 2025, the CRA will create new cybersecurity requirements to sell a device in the single market. Standard bodies have not stayed idle.
The Connectivity Standards Alliance published the IoT Device Security Specification in March of this year, after more than a year of work by its Product Security Working Group.
What is striking about the new regulations and standards is how similar they are, and how much they get right. While a deep dive into the laws is beyond the scope of this article, here are the key themes:
1. Secure configuration. Change to device configuration must be authenticated, passwords must be unique per device, and a factory reset function to a secure default must be provided.
2. Data security. Data stored on and transmitted by the device must be protected (e.g., via encryption).
3. Vulnerability management. Known vulnerabilities must be identified (e.g., by software scanning and supply chain analysis), disclosed, and mitigated.
4. Device monitoring. The device must be capable of identifying, logging, and reporting security events (e.g., compromises) to its manufacturer.
5. Software update. Devices must have a software update mechanism by which security issues can be patched.
Few organizations comply with all of these requirements today. Take, for example, the requirement for a software update mechanism, which is arguably the most basic one. In a recent survey conducted by VDC Research on the embedded software industry, only one-third of projects had remote firmware-over-the-air update capability. Yet this requirement is hardly superfluous: how can we expect to fix device vulnerabilities if the software cannot be updated?
This leaves a large majority of businesses scrambling to build capabilities and infrastructure they have no prior experience with to comply with the law. While we do not yet know how aggressively regulators will enforce these new statutes, we recommend IoT manufacturers start investing in the following security features:
Over-the-air (OTA) software update: The ability to update your device’s software is your escape hatch in the event a security issue is discovered after your device has shipped. This should be a priority.
Firmware signing: While encrypting firmware has little benefit, signing in to authenticate its source is a must-have.
Observability: Catching and fixing software bugs such as buffer overflows reinforces the security of your device, and monitoring via metrics can help you identify compromises (e.g., by spotting odd network usage patterns by a device). This means you can find and patch a vulnerability before most of your customers are impacted by it.
Static analysis: Better than catching a bug in production is catching it in development. Static analysis looks through your source code for bugs and vulnerabilities. Robust solutions, both open source (e.g. Clang Static Analyzer) and proprietary (e.g. Sonarcloud), exist in the market today and can be deployed very quickly.
Software Bill of Material (SBOM): Maintain a list of third-party software your product relies on and compare it against known vulnerabilities in the CVE database. Several solutions exist to scan your software for third-party dependencies and automatically alert you when security issues are found against them.
While we expect the next few years will be challenging for the IoT industry, we applaud regulators acting to make devices more secure. Over the next decade, the industry’s cybersecurity challenges will only get more daunting. The time to start building secure products is now.