• Blog
  • January 8, 2021

The New Federal IoT Security Law

by Victoria Tollossa

  • Cybersecurity
Share

A new model for cybersecurity law, or a relic before it was passed? ​

KEY TOPICS

After a number of fits and starts, the federal government finally passed The Internet of Things Cybersecurity Improvement Act of 2020, Pub. L. No. 116-207 (the IoT Law). There is a lot of content in the law, but little immediate impact.  State IoT laws certainly have more immediate impact.

One group the law will impact are government contractors. Like with section 889 of the 2019 NDAA, Congress seems to have settled on using the federal government’s purchasing power to impose broadly applicable cybersecurity requirement.

Moving forward, Congress likely will continue to use the government’s purchasing power to impose cybersecurity requirements, choosing to influence industry with dollars instead of imposing requirements directly.  It will delegate the definition of specific controls to experts, either within the government (i.e., NIST), or within industry (e.g., PCI DSS).

What is IoT and Why Does Congress Care? 

IoT began as a buzz word for the proliferation of internet connected devices with the advent of additional IP space, the wide distribution of wireless networks, and the ever-decreasing costs of computing power.  With the advent of 5G, IoT now refers to billions of devices that many of us interact with daily.  The ever-decreasing costs of computing power has changed the typical character of many of these devices from glorified sensors to fully functional computers.

The concept of IoT is positively ancient as far as computing concepts go, but the term was first defined around 1999.  “Internet of Things” was the title of a talk concerning supply chain optimization and the benefits of RFID chips.  Hardly the most exciting topic, but a buzzword was born.  Cybersecurity was not a concern at this time, and few people were talking about how to secure these new devices.

The miniaturization of computing power combined with the natural expansion of any buzz word worked to pull more devices under the IoT umbrella.  Wireless technology changed from poor analog networks that struggled with voice calls to 5G cellular networks capable of transmitting 4K movies.  Computing power provided handheld computers consumers could purchase for $20 and connect to anything in their house.  The value companies can extract from just about any information has incentivized more devices that capture more information, even if that information isn’t helpful to the functioning of the device itself (IoT toaster, anyone?).

This expansion led to the crashing of the internet through a combination of poorly secured internet connected cameras, the Minecraft economy, and an overly ambitious morally deficient college student.  This event, known as the Mirai botnet, highlighted the problems caused by insecure design practices and widespread proliferation of remote controlled devices.  It also showed that the convergence of IoT devices and traditional computers meant that hacking techniques developed over the previous decades had new application in an enormous, immature field.

A Long, Winding Road to Security Standards 

Senator Warner first introduced an Internet of Things law in 2 (2017 IoT Bill).  Senator Warner was motivated by concerns about children’s toys collecting information while connected to the internet, as well as the Mirai botnet.  Like most cybersecurity bills, it did not get out of committee before the end of the term.

While the 2017 bill languished in committee, FTC pursued a complaint against an IoT device manufacturer, D-Link, for its lax security practices, which contributed to the Mirai botnet.  Meanwhile, several states introduced their own bills requiring IoT device manufacturers to implement reasonable security measures.  California’s version was signed into law in September 2018, while Oregon’s passed in May of 2019.  Both bills took effect on January 1, 2020.

Senator Warner introduced a new IoT law in March of 2019 (2019 IoT Bill), while Representative Kelly introduced a companion bill in the House.  Meanwhile, the FTC settled its claims against D-Link in July 2019, setting a benchmark for what the FTC considered reasonable in the context of IoT devices.  Representative Kelly’s bill finally passed the House in September 2020, quickly passed the Senate in November 2020, and was enacted into law on December 4.

The bill that was enacted looks significantly different from both the 2017 and 2019 versions.  Some of this reflects changes in what IoT devices are, but some of the changes reflect an evolution of thinking on how to impose cybersecurity standards.  Looking at how the law evolved tells us some of what to expect from future cybersecurity legislation.

Evolution of the Law 

In response to the Mirai botnet, three different groups moved to regulate IoT security in a completely uncoordinated manner.  Several states, a federal executive agency, and Congress all moved to establish some standard.  Pressures placed on these groups led to a set of broadly similar rules for IoT devices.

The 2017 IoT Bill was both very broad and very prescriptive.  It attempted to regulate “internet-connected devices”, which was basically everything with a network address and a processor.  The law itself required an ability to accept authenticated updates from manufacturers, review of the National Vulnerability Database, and limited permissible types of authentication to devices.

The law was problematic because many items that fell under “internet-connected devices” already had cybersecurity standards, established through regulation, private entities, or a combination.  Layering more standards on top of these, especially standards as linked to technology as the 2017 IoT Bill was (e.g., it defined firmware), was problematic.

The state level bills—at least the ones that passed—narrowed the definition of device somewhat, and were more general in their requirements.  While both laws did have some terms directed specifically at the causes of the Mirai botnet, they both required manufacturers to implement reasonable security features, the definition of which they generally left in the hands of the manufacturers.  These laws also excluded private claims, which would allow the states to maintain control of enforcement.  In other words, attorneys general would decide what was sufficiently unreasonable as to warrant enforcement actions.  Still, the language of the laws caused concern among many of those in industry responsible for implementation.

Meanwhile, the FTC was focused on manufacturers’ security programs.  In the D-Link settlement, the FTC required a “comprehensive software security program.”  It imposed some specific controls, but focused mainly on the development of an auditable secure development process.  Such a process would arguably be part of determining what security features are reasonable under the state IoT laws.  Although the FTC and the states address IoT devices in different ways, the rules they imposed are roughly similar.

When initially introduced, the 2019 IoT Bill excluded general purpose computing devices, narrowing its scope considerably.  It also did away with specific technical controls, instead directing the National Institute of Standards and Technology (NIST) to complete ongoing efforts related to the management of IoT risks, and to use the resulting standards to assist in the development of controls for the federal government.

The 2019 IoT Bill changed while it worked its way through Congress to become the version that passed.  First, it dramatically tightened the definition of IoT device.  Now, regulated devices are limited to devices that have a transducer for interacting with the physical world and excludes “conventional Information Technology devices.”  In keeping with the 2019 bill, most of the actual work has moved to NIST, and to a lesser extent, the Office of Management and Budget (OMB).  NIST is responsible for establishing security standards, guidelines on vulnerability disclosure, and standards for the resolution of vulnerabilities.  OMB is responsible ensuring that agencies comply with NIST guidance.  Congress recognized that there needs to be cybersecurity standards, but more importantly, recognized that Congress is poorly placed to define those standards.

Congress also recognized that devices will continue to converge.  It tasked the Comptroller General to brief it on “convergence of information technology, internet of things, and operational technology devices, networks, and systems.”  As these devices converge, Congress will likely attempt to pass a more generic cybersecurity law.

Current IoT Security Requirements 

IoT devices are targeted by three different legal regimes.  Current state laws target manufacturers of IoT devices, defined broadly.  The FTC targets IoT devices provided to consumers, just like any other consumer good.  Finally, federal statutory law targets IoT devices through the government acquisition process.

Although these laws differ, it is possible to harmonize the security requirements.

At bottom, these laws require a programmatic approach to security.  Manufacturers must use a secure development methodology when designing covered devices.  How that methodology operates will differ based on the specific device.  The development methodology will, in most instances, need to continue past sale; vulnerability patching is a component of all three legal regimes.

Organizations, a group broader than manufacturers, must have a security program that governs the integration and use of these devices.  Connecting a device to your network assumes the vulnerabilities present in that device, and organizations must plan accordingly.

Of particular interest to the federal government is identity management, patching, and configuration management.  It is hard to imagine a secure development methodology that does not address these issues, but they merit special attention as they are called out in the legislative language.  That does not provide a reason to ignore other security controls, however.

Finally, as with all programmatic requirements, documentation is key.  This means both documentation of the policies and documentation that the policies were executed properly.  Organizations that follow a documented secure development process are in a strong position to show that they are in compliance with the various IoT laws.

What This Means for Everyone Else: Be Reasonable 

The IoT Law narrows the definition of IoT device substantially (in part to reduce the parties pushing back on the law) but recognizes that such distinctions are growing harder to maintain.  Rules and regulations will continue to converge.  Ultimately, most organizations will be subject to reasonable security requirements at both the device and operational level.  What is “reasonable” may be informed by specific standards (e.g., the FTC adopting PCI DSS as the reasonable standard in Wyndham), but it will always require a programmatic approach.

Building a reasonable security program takes time.  Organizations should be laying the foundation now, instead of waiting for Congress, regulatory agencies, or private entities to define specific guidelines.  If there is a strong foundation, organizations can address any controls they may not have in new guidelines quickly and efficiently.  Without a strong foundation, organizations will scramble to meet new guidelines, which they will do poorly.