Three actions for IoT device manufacturers from the IoT Cybersecurity Improvement Act of 2020

Signed by the president on December 4, the IoT Cybersecurity Improvement Act of 2020 (IoT CIA) is the first federal law regulating the security of IoT devices, but it should come as no surprise to anyone working in IoT.

Congress proposed several versions and held a number of committee hearings on IoT cybersecurity, and the content of the current law is similar to earlier drafts. It relies on the National Institute of Standards and Technology (NIST) to formalize IoT regulations in coordination with academia and the private sector.

California and several other influential states, as well as the European Union and the United Kingdom, have been moving to regulate the largely unregulated IoT sector. Their actions have had a big impact on global privacy and security law — as has the NIST, which recently drafted a proposed standard for IoT and has helped develop frameworks for best practices in cyber and privacy.

What the IoT CIA regulates

The act considers an IoT device to be a device with at least one sensor or actuator for interacting directly with the physical world, at least one network interface, and the ability to function on its own, not only as part of a larger system. The act excludes smartphones, laptops and other computing devices.

The definition is not black-and-white. Do the new rules apply to industrial automation control systems (IACS) such as manufacturing systems in use at the Bureau of Engraving and Printing? Do they apply to building managed systems (BMS) used at many government facilities? If so, the government and the private sector can expect to feel substantial repercussions.

The law applies to IoT devices owned or controlled by an agency and connected to a federal information system, which NIST defines as “an information system used or operated by an executive agency, by a contractor of an executive agency, or by another organization on behalf of an executive agency.”

Among the IoT CIA’s requirements:

• Federally owned or controlled devices that connect to a federal information system must comply with guidelines that the NIST is expected to produce by March 4. The NIST director will be expected to review the requirements every five years to keep them up to date with the latest technology and standards.
• The Office of Management and Budget must require federal civilian agencies to have information security policies consistent with NIST guidelines within 180 days after those guidelines are finished (or September 2021).
• Federal IoT acquisition rules must be updated to reflect the new guidelines.
• Federal agencies will now be required to procure, obtain and renew contracts only for IoT devices that meet the security guidelines.
• Federal agencies and contractors providing information systems to them must have vulnerability disclosure policies. Contractors and subcontractors involved in developing and selling IoT products to the government must report vulnerabilities and how those vulnerabilities were resolved.

Why is the act necessary? IoT vulnerabilities and risks

How federal agencies use IoT varies, and federal customers make up a small portion of the overall IoT market. But the government’s use of IoT tends to support critical processes — meaning a breach could have serious ramifications. And every IoT device connected to a federal network adds another layer of vulnerability to cyberattack.

Agencies use IoT devices to:

• Track equipment such as fleet vehicles or agency property.
• Collect environmental data. EPA sensors on a buoy in Boston’s Charles River, for example, monitor water temperature, pH, oxygen levels and harmful bacteria blooms.
• Conduct surveillance. The Department of Homeland Security’s autonomous surveillance towers use artificial intelligence to detect and identify “items of interest” for border security.

Device owners must secure and monitor their devices to protect their own environments and to make sure malicious actors don’t use their systems to attack others, as happened in the Mirai botnet DDoS attack in 2016. IoT device owners and manufacturers must work together to securely procure, deploy, configure and monitor these IoT devices.

Although security has made great strides in recent years, many embedded systems including IoT still lack basic security controls. Reasons include hardware constraints, security costs and haste to get the devices on the market.

• The hardware: Constraints in IoT devices preclude standard security controls. To use traditional controls such as encryption requires increasing the load on limited system bandwidth, and using public key infrastructures (PKI) would mean having to update certificates regularly. Adding hardware security modules (HSMs) to the products would make them more expensive. Moreover, tracking the authenticity and integrity of IoT components is difficult because the supply chain is so complex — so difficult that a reliable mechanism for checking integrity has yet to be invented.
• The firmware: The increase in remote work has increased IoT firmware challenges. Poorly written code or a maliciously inserted backdoor, including in code provided by third parties such as code “libraries,” could introduce a hidden risk to an enterprise. Third-party code is especially difficult to trace, but the National Telecommunications and Information Administration is developing guidance for a software bill of materials, an inventory of software components. And IoT devices often run lightweight, single-purpose operating systems that tend to lack adequate security controls. These devices are frequently unmanaged, making it difficult to patch the firmware. Finally, most IoT devices lack hardening guidelines and offer only minimal abilities to audit configurations.
• The network: Insecure protocols pose risks to confidentiality. Devices use a variety of open and proprietary protocols to communicate with each other and with external systems such as Bluetooth, Zigbee and Z-Wave, among others. Many of these protocols don’t emphasize security, and these compromises could lead to the loss of telemetry data, to so-called “man-in-the-middle attacks” or to losing control of the device altogether.