Last updated at Fri, 29 Dec 2023 19:57:51 GMT

Update: July 23, 2019 — Both the Senate and House versions of the bill have now gone through their respective committee markup processes, with varying degrees of success. The bills are no longer the same, and concerningly both have challenges, though on our read, the House version seems to have addressed more of its issues.

On March 11, 2019, members of the U.S. Congress introduced the Internet of Things (IoT) Cybersecurity Improvement Act of 2019, which aims to “leverage Federal Government procurement power to encourage increased cybersecurity for Internet of Things devices.” This post will walk through what’s in the bill and Rapid7’s position on it.

In general, Rapid7 supports efforts to encourage adoption of secure-by-design development practices. We appreciate that the bill tries to avoid taking a strong regulatory approach that could chill innovation and entrepreneurialism, and instead focuses on leveraging the buying authority and influence of the government as a way of encouraging technology manufacturers and vendors to embrace cybersecurity best practices. So, at a high level, we agree with the goals and approach of the bill. However, some significant issues with the bill somewhat neutralize our support for this version, as explained below:

What’s the IoT Cybersecurity Improvement Act of 2019 about?

The IoT Cybersecurity Improvement Act of 2019 was introduced as S.734 in the Senate and was sponsored by Sens. Mark R. Warner (D-Va.) and Cory Gardner (R-Colo.), co-chairs of the Senate Cybersecurity Caucus, along with Sens. Maggie Hassan (D-N.H.) and Steve Daines (R-Mont.). At the same time, Reps. Robin Kelly (D-Ill.) and Will Hurd (R-Texas) along with 13 co-sponsors, introduced a companion bill, H.R.1668, in the House of Representatives.

According to the press release accompanying the introduction of the Senate bill, the IoT “is expected to include over 20 billion devices by 2020. While these devices and the data they collect and transmit present enormous benefits to consumers and industry, the relative insecurity of many devices presents enormous challenges. Sometimes shipped with factory-set, hardcoded passwords and oftentimes unable to be updated or patched, IoT devices can represent a weak point in a network’s security, leaving the rest of the network vulnerable to attack.”

The act aims to address this threat by leveraging the considerable buying power of the U.S. government to encourage IoT manufacturers to build devices that are secure by design—i.e., have security features and considerations built in from the ground up.

The bill does this in five main ways:

  1. It requires the National Institute of Standards and Technology (NIST) to issue recommendations addressing, at a minimum, secure development, identity management, patching, and configuration management for IoT devices.
  2. It directs the Office of Management and Budget (OMB) to then issue guidelines consistent with these NIST recommendations and to review these policies at least every five years.
  3. It requires that these guidelines be used by all government agencies—any internet-connected devices purchased by the federal government must comply with those recommendations.
  4. The bill also directs NIST to work with cybersecurity researchers and industry experts to publish guidance on coordinated vulnerability disclosure to ensure vulnerabilities related to agency devices are addressed.
  5. It requires contractors and vendors providing IoT devices to the U.S. government to adopt coordinated vulnerability disclosure policies, so that if a vulnerability is uncovered, that information is disseminated.

What’s Rapid7’s view of the bill?

What we like about the IoT Cybersecurity Act of 2019

As said above, we are generally supportive of the goal and approach of the bill. We appreciate that the bill’s authors have tried to avoid directly regulating the private sector, which would potentially chill innovation, and have instead focused on the procurement behavior of the U.S. government, which can and should be regularly reviewed. The U.S. government spends billions of dollars on technology across its many branches and agencies, translating to considerable buying influence. It has an opportunity—and, arguably, a responsibility—to secure its own systems and lead by example in encouraging manufacturers to improve their processes to avoid exposing customers to unnecessary risk.

Additionally, we think it’s pragmatic to place the focus on NIST-developed recommendations. NIST has been working on IoT security for a while, has a proven track record in developing pragmatic and context-aware frameworks and guidances, and has domain and technical knowledge around cybersecurity. In addition, framing the requirements this way makes it easier to keep them updated as technology and norms evolve. It will likely be a faster and easier process to update NIST guidelines than to pass an amendment to the law. This is an important consideration when you are legislating around technology and innovation.

Called out in Sec. 3.(a)(2), the four primary areas of focus that NIST’s recommendations must address (secure development, identity management, patching, and configuration management) seem reasonable. “Secure development” covers a lot of potential ground, then the three additional headers cover the specific areas most often cited in IoT security discussions, with identity/access management and patching commonly topping the list. If I were to add something, it would probably be around data protection—securing data at rest and in transit, and ensuring credential information, PII, and payment information are all safeguarded.

As long-time advocates for coordinated vulnerability disclosure (CVD), we are particularly happy to see this called out as a special area of focus in the bill. We believe government-wide use of CVD is past due, and we are glad to see this legislation focusing on broad adoption of fundamental CVD processes rather than bug bounties for individual agencies. Again, the language points to third-party, best-practice guidance rather than detailing its own expectations. In this case, the bill points to two ISOs—29147 and 3011—which are pretty widely acknowledged as being the de facto standards in this area. Hat tip to Katie Moussouris and Art Manion, who work diligently with ISO to keep those standards up-to-date.

What concerns us about the IoT Cybersecurity Act of 2019

There are some pretty serious issues in “Sec. 2. DEFINITIONS” that concern us.

First, in Sec. 2(2)(A)(iii), the bill exempts Programmable Logic Controls (PLCs) from being covered by the requirements. Wikipedia has a pretty good description of PLCs, saying a PLC is “an industrial digital computer which has been ruggedized and adapted for the control of manufacturing processes, such as assembly lines, or robotic devices, or any activity that requires high-reliability control and ease of programming and process fault diagnosis.” I’ve heard some debate over whether PLCs can be considered IoT, but regardless, we feel they are an important type of connected technology, and because they are widely deployed in high-value target environments (often for a long time and with no patching path), exempting them feels like a mistake.

Side note: The bill defines “covered device” but only uses that term in the section on CVD. In the section on security standards for government procurement, the bill uses the term “Internet of Things devices,” which is undefined. It is unclear whether this is intentional. If it is intentional, it leaves open the crucial question of what counts as an “IoT device,” including whether PLCs qualify as part of that group.

Moreover, in its definition of “covered device,” the bill cites PLCs as an example of “general-purpose computing devices,” which is misleading. Again, I refer you to the Wikipedia description above: PLCs are not general-purpose computers, and positioning them as such feels misleading to me. Given the legal world’s absolute love of precedent, creating a legal definition of PLCs as “general-purpose computing devices” seems like a thing that could have harmful repercussions down the road for future legislation, guidance, and policy discussions on security.

Finally, Sec. 2.(2)(B)(i) provides a provision for “interested parties” to petition to exempt additional devices, but not to add any. This is problematic in three ways:

  1. Most critically, it could widen the “poverty gap” among IoT manufacturers. The provision grants an opportunity for manufacturers that have resources to get themselves exempted. Meanwhile, smaller IoT startups—already often at a disadvantage selling into the government—are unlikely to be able to dedicate resources to lobbying on this, resulting in the bigger players potentially securing yet another competitive advantage.
  2. The bill places the responsibility for adjudicating the process on OMB, who are not generally expected to be experts on cybersecurity. This seems like a somewhat unfair burden to place on them and is unlikely to yield great results. It is notable that the bill does not specify any basis on which the decision to exempt additional devices can rely, so the final process for additional device exemptions could consider a range of ambiguous or non-security factors.
  3. If you’re going to provide a provision acknowledging that technology changes and you need to adapt, it seems like a missed opportunity to place such a strong emphasis on exempting additional technologies and not also leave room for expanding the definition or removing technology from the exemptions.

So, where do we stand?

In addition to the concerns raised above, there have been some criticisms that the bill does not go far enough and that the timelines are too long (pretty much everything is done in blocks of 180 days). In all honesty, I think the timelines are pretty reasonable and practical. Yes, many of us in the security community would love to see manufacturers adopting better practices now, but that isn’t very realistic given the complexity of the challenge and the other factors at play in IoT manufacturing.

The good news is that change is happening, though it’s sadly still a very small percentage of companies that are adopting secure-by-design practices, and things are moving slowly. Progress is and will be incremental, which is the point of this bill—driving more widespread adoption of secure-by-design practices. We won’t achieve a security revolution overnight, but we can build more momentum and create an important foundation for more learning and evolution in the future.

It is unfortunate that the definitions section is so challenging, as I would really like to say we wholeheartedly support the bill given that we do support its stated goals. However, it matters how you get there, and there’s a meaningful difference between something that limits the positive impact versus something that creates the potential for negative impact. I believe the definitional issues outlined above fall into the latter category, and therefore, I can’t say I would support this bill moving forward in its current form. This is the most conflicted I can remember being on a bill, because I really do want to see the important cybersecurity progress the bill is reaching for.

My hope is that before the bill goes for any kind of vote, the definitions section will be updated and those issues addressed. If that happens, I hope the security community will get behind it and show support for driving broader adoption of secure-by-design practices.

Hungry for more IoT policy?

The U.S. Congress is not the only policy body worried about IoT security. There are numerous efforts to create policy that drives adoption of cybersecurity best practices in the development of IoT technologies, both in the United States and internationally. Below is just a small selection of guidances and policy efforts we’ve seen in this area over the past few months:

  • In September 2018, the governor of California signed S.B.327, titled Security of Connected Devices, which basically calls for device manufacturers to equip devices with “reasonable” security features and specifically calls out authentication as an area of focus.
  • In October 2018, the FDA issued a draft guidance, Content of Premarket Submissions for Management of Cybersecurity in Medical Devices, which provides updated recommendations to the industry on cybersecurity considerations for device design, labeling, and documentation that the FDA recommends be included in premarket submissions for medical devices with cybersecurity risk.
  • Also in October 2018, the Department of Digital, Culture, Media and Sport in the U.K. published the Code of Practice for Consumer IoT Security, a set of 13 principles for building secure-by-design IoT. It’s expected that the U.K. government will legislate some of the more essential practices soon.
  • In March 2019, the European Parliament overwhelmingly approved the EU Cybersecurity Act, which now goes to the European Council for a final vote. The act authorizes a permanent EU cybersecurity agency, ENISA, and charges it with creating a framework for cybersecurity certification for ICT products, which will be rolled out across the EU. It is expected the certifications will primarily focus on IoT and critical infrastructure technologies.