The New IOT Security Act Shows the Limits of Congressional Policymaking for Cybersecurity

On Dec. 4, President Trump signed H.R. 1668. Although styled the “Internet of Things Cybersecurity Improvement Act of 2020,” the new law could just as well be called the Coordinated Vulnerability Disclosures Act of 2020. It includes a vulnerability disclosure mandate that reaches beyond Internet of Things (IOT) devices to any information system owned or controlled by a federal agency and to the contractors and subcontractors providing such information systems.

On its surface, the law represents an important congressional effort to address an area of notorious insecurity. However, as its history and text show, the legislation is more of a ratification of measures already underway or completed. Its passage, unanimous in both chambers, illustrates the limitations of congressional action on cybersecurity. Nevertheless, the act gives Congress important oversight leverage to push for robust implementation of both IOT security and vulnerability disclosure. And it should be taken by the incoming Biden administration as a foundation for further executive branch action.

First, the IOT part. Section 4 of the act requires the director of the National Institute of Standards and Technology (NIST) to adopt standards and guidelines for IOT devices owned or controlled by an agency. The exact language is a little indirect. It does not require standards or guidelines for the devices themselves but, rather, “standards and guidelines for the Federal Government on the appropriate use and management by agencies” of IOT devices, “including minimum information security requirements for managing cybersecurity risks associated with such devices.” That seems to put the responsibility for security on the government, not the device manufacturers.

When Sen. Mark Warner first introduced an IOT security bill in 2017, he took a very different approach. His initial foray would have required, in any contract for federal acquisition of IOT devices, clauses requiring contractors to certify that their devices did not contain any known security vulnerabilities or defects; that their software or firmware components were capable of accepting properly authenticated and trusted updates from the vendor; that they used only nondeprecated industry-standard protocols and technologies for key functions; and that they did not include any fixed or hard-coded credentials used for remote administration, the delivery of updates, or communication. Exceptions and waivers were available and the bill would have allowed for use of alternate conditions to mitigate risks of noncompliant devices, but the bill was striking in its prescriptiveness.

The U.S. Chamber of Commerce was opposed. Its lengthy critique sounded all the concerns about tech regulation: “mandating standards, guidance, and best practices shunts entities’ resources away from effective risk-based cybersecurity measures,” “likely to become outmoded quickly,” “[r]ed tape could readily quash business inventiveness.” The bill went nowhere—not even receiving a hearing—in yet another manifestation of Congress’s consistent reluctance to regulate the private sector with respect to cybersecurity, even when it comes to the design of devices that will be used in government networks.

When Warner reintroduced the bill in 2019, its provisions for IOT devices were close to those eventually enacted. They focused not on the devices themselves but on the federal government’s use and management of IOT devices. Meanwhile, the executive branch had been pushing forward on IOT security, outpacing Congress—another familiar pattern. For example, the Cybersecurity Enhancement Act (CEA) of 2014 required NIST to develop a cybersecurity framework for critical infrastructure, but President Obama had already directed NIST to do so in Executive Order 13636, signed in February 2013. The NIST framework was issued in February 2014, 10 months before the December 2014 enactment of the CEA’s mandate.

In 2018, while Warner’s first bill languished, NIST released its “Botnet Road Map,” with a detailed work plan for IOT security, including a set of tasks specifically designed to establish “a widely adopted security capability baseline for federal IoT products.” This was followed in September 2018 by a draft publication, “Considerations for Managing Internet of Things (IoT) Cybersecurity and Privacy Risks.” That was finalized as NISTIR 8228 in June 2019, not long after the March reintroduction of the bill. Thereafter the pace of NIST action accelerated, with the May 2020 publication of recommendations for IOT device manufacturers and a Core Device Cybersecurity Capability Baseline, followed by the June 2020 issuance of a federal profile of the Core Baseline.

As urged by the Chamber of Commerce and other industry associations, these NIST products were developed by a consultative process. There’s a lot to be said for consultative processes, and risk mitigation must inform any cybersecurity effort, but NIST’s commitment to collaboration almost certainly pushed its outputs away from specific technical fixes and toward generalities and flexibility. (The history, including a hat-tip to the trade associations for their “encouragement” of the process, is laid out in a blog by the program manager for NIST’s IOT cybersecurity program.)

Whether the new law spurs NIST development of heightened standards remains to be seen. As enacted, the IOT security bill requires the director of NIST to ensure that the standards and guidelines developed under the new law are consistent with these prior efforts. A cynic might read this not as a prod to NIST’s efforts but as a limit against going beyond what can survive an industry-influenced approach. Similarly, the new law’s requirement that the Office of Management and Budget (OMB) review agency information-security policies and principles for “consistency” with the NIST IOT guidelines and standards can be read as establishing them as a floor—or as a ceiling. A lot depends on whether the Biden administration’s NIST is as deferential to the Chamber of Commerce and other industry associations as the Trump administration was. There must be ways in which NIST could be a lot more prescriptive in its IOT work without impeding innovation.

Another section of the new law requires OMB, by December 2022, to develop and oversee the implementation of policies, principles, standards or guidelines as may be necessary to address security vulnerabilities of federal information systems. But OMB is already doing that, at least since 2002 under 40 U.S.C. § 1133, as further fleshed out in 44 U.S.C. § 3553 (added by the Federal Information Security Modernization Act of 2014), and Executive Order 13800, “Strengthening the Cybersecurity of Federal Networks and Critical Infrastructure,” issued in May 2017. It is hard to see the benefit of adding a slightly differently worded mandate on top of existing mandates requiring the same thing.

The law’s vulnerability disclosure requirements are also more of a ratification of measures already taken than a manifestation of congressional leadership. Section 5 of the new law requires the NIST director to develop and publish guidelines for the reporting, coordinating, publishing and receiving of information about a security vulnerability relating to federal agency information systems (including but not limited to IOT devices). The guidelines must also apply to any contractor or subcontractor providing an information system to an agency.

Vulnerability disclosure (or coordinated vulnerability disclosure) refers to the techniques and policies for individuals (including independent security researchers) to discover vulnerabilities in products and to report those to the product vendors and for the vendors to receive such vulnerability reports and publish remediation information. This is distinct from the vulnerabilities equities process, which concerns the intelligence agencies’ handling of vulnerabilities they secretly discover and exploit.

Vulnerability disclosure used to be highly controversial, but it has long since gone mainstream, even within the federal government. “Hack the Pentagon,” the U.S. government’s first-ever bug bounty (a form of vulnerability disclosure that pays researchers for their findings), launched in 2016. The Department of Justice issued its guidelines for vulnerability disclosure programs (VDPs) in 2017. The 2018 version of the NIST cybersecurity framework recommended maintenance of a VDP as part of a comprehensive security program. A small industry has grown up around the provision of VDP services to government agencies and corporations that do not want to run their own. In December 2019, Homeland Security’s Cybersecurity and Infrastructure Security Agency, through the General Services Administration (GSA), issued a request for information to identify potential vendors that could provide “a software-as-a-service web application that serves as the primary point of entry for vulnerability reporters to alert the government of potential issues on federal information systems for those agencies that participate in the platform.” In August, the GSA issued a request for proposal on behalf of Homeland Security for a vulnerability disclosure platform to facilitate the submission of vulnerabilities to any agency not wanting to manage its own system.

Culminating this evolution, in September the Cybersecurity and Infrastructure Security Agency issued Binding Operational Directive 20-01, which requires individual federal civilian executive branch agencies to publish vulnerability disclosure policies for their internet-accessible systems and services and to maintain processes to support vulnerability disclosure. Simultaneously, OMB ordered agencies to develop and implement vulnerability disclosure policies. Also in September, NIST issued a draft revision of its SP 800-53, “Security and Privacy Controls for Information Systems and Organizations,” which included vulnerability disclosure as part of the standard for vulnerability monitoring.

So the new law adds little. Perhaps the congressional mandate will lead to more robust vulnerability disclosure programs. Perhaps the law’s requirement that “[t]he Federal Acquisition Regulation shall be revised as necessary to implement the provisions under this section” will dovetail with the VDP amendments to SP 800-53 and make them mandatory in all federal procurements of information systems. The bill’s prohibition in Section 7 on procurement or use of devices that prevent compliance with both the IOT and vulnerability provisions, although caveated, should influence device makers, who must now fear rejection of their products. And the explicit directive to NIST to update the IOT standards and guidelines no less often than every five years and to OMB to update its policies accordingly is new. NIST has a general practice of periodically reviewing and updating its work, but it’s useful to have the practice codified, and there’s no obligation for OMB to issue updated policies and procedures in response to NIST publications. Indeed, transmitting NIST guidelines into agency information-technology management and procurement practices through binding OMB policies may be highly effective in propagating NIST’s work. In this way, the IOT act may be a model.

Overall, though, the IOT law illustrates some of the limits of Congress’s power. It remains difficult if not impossible to enact anything over industry opposition. By insisting on their prerogatives, executive branch entities, notably OMB, can weaken congressional measures. Even without this measure, the incoming administration, like the outgoing one, will have plenty of authority—and plenty of incentive—to use its procurement power to improve the security of government information systems and thus to influence private-sector systems as well. Congress, unless it finds a way to be a lot more aggressive, is frequently going to be in the position of codifying or only marginally improving measures already taken.