S 1691 Introduced – Cybersecurity Standards

Yesterday Sen. Warner (D,VA) introduced S 1691, the Internet of Things (IoT) Cybersecurity Improvement Act of 2017 (NOTE: this is a link to an unofficial copy of the bill on Scribd.com provided by Warner’s office). The bill would establish cybersecurity standards for internet connected information systems bought by agencies of the Federal government.

Definitions

Section 2 of the bill establishes ten definitions of terms used in the bill. Seven of those terms are cyber-specific terms:

• Firmware;

• Fixed or hard-coded credential;

• Hardware;

• Internet-connected device;

• Properly authenticated update;

• Security vulnerability; and

• Software

Two of these definitions are of specific importance in establishing the scope of this bill. The first is ‘internet connected device’. This is defined as “a physical object that is capable of connecting to and is in regular connection with the Internet; and has computer processing capabilities that can collect, send, or receive data” {§2(6)}. The second is ‘security vulnerability’. This is defined as “means any attribute of hardware, firmware, software, process, or procedure or combination of 2 or more of these factors that could enable or facilitate the defeat or compromise of the confidentiality, integrity, or availability of an information system or its information or physical devices to which it is connected” {§2(9)}.

Vendor Responsibilities

Section 3(a) of the bill requires the Office of Management and Budget to publish contract guidelines that would establish vendor responsibilities in providing internet connected devices to agencies of the Federal government. Primarily the vendor would be required to provide written certification that each internet connected device {§3(a)(1)(A)(i)}:

• Does not contain, at the time of submitting the proposal, any hardware, software, or firmware component with any known security vulnerabilities or defects;

• Relies on software or firmware components capable of accepting properly authenticated and trusted updates from the vendor;

• Uses only non-deprecated industry-standard protocols and technologies for functions such as communications, encryption and interconnections with other devices or peripherals.

Vendors would also be required to provide agencies subsequent notification “of any known security vulnerabilities or defects subsequently disclosed to the vendor by a security researcher or of which the vendor otherwise becomes aware for the duration of the contract” {§3(a)(1)(B)}. It also requires system support “in a manner that allows for any future security vulnerability or defect in any part of the software or firmware to be patched in order to fix or remove a vulnerability or defect in the software or firmware component in a properly authenticated and secure manner” {§3(a)(1)(C)}. Finally, it would call for repair or replacement of any component that cannot be patched to fix an identified security vulnerability.

On a case-by-case basis, waivers of the above requirements could be requested through the OMB. Justification for the waivers would have to include alternative mitigation measures. NIST would be required to establish standards for alternative mitigation measures. That would include NIST approval of third-party security standards.

Security Vulnerability Research

Section 3(b) would require the DHS National Protection and Programs Directorate (NPPD) to establish guidelines for “for each agency with respect to any Internet-connected device in use by the United States Government regarding cybersecurity coordinated disclosure requirements that shall be required of contractors” {§3(b)(1)} providing internet connected devices. The guidelines would address {§3(b)(2)}:

• Policies and procedures for conducting research on the cybersecurity of an Internet-connected device, which shall be based, in part, on ISO 29147; and

•Require that research on the cybersecurity of an Internet-connected device provided by a contractor to the United States Government shall be conducted on the same class, model, or type of the device provided to the United States Government and not on the actual device provided to the United States Government.

Section 3(c) of the bill would amend two statutes related to computer crimes to provide some protection to security researchers. First the bill would amend 18 USC 1030 to provide an exception to that section for security researchers conducting vulnerability research in accordance with standards established under §3(b)(2) on “an Internet-connected device of the class, model, or type provided by a contractor” {new §1030(k)(1)} to the US government. Second the bill would amend 17 USC 1203 providing a similar exception to the copywrite restrictions in that section.

To make these exceptions usable to security researchers not associated with the contractors providing the devices, the OMB would be required to maintain a publicly accessible database of “devices and the respective manufacturers of such devices for which limitations of liability exist under this Act” {§3(c)(3)}. A similar database would be maintained listing of devices for which notification has been received by the federal government that security support has lapsed on those devices.

Moving Forward

Warner is not a member of the Senate Homeland Security and Governmental Affairs Committee to which this bill was assigned for consideration. One of his three cosponsors {Sen. Daines (R,MT)} is, however, a member of that Committee so it is possible that the bill could be considered in Committee.

This would be a fairly large change in congressional action on cybersecurity, so it is likely to take some time for this bill to move forward. There would be some push-back from industry on the requirements of the bill (see my discussion below), but nothing that should prevent the bill from passing if considered. I suspect that there will be significant changes to the bill made in Committee before it has a chance to move forward.

Commentary

The title of the bill is a serious misnomer. There is no mention of IoT in the bill and the requirements are certainly not limited to devices that are normally included in the term ‘internet of things’. Almost any electronic device capable of internet connection (certainly including lap top computers, office computers, servers, and even cell phones) would be included in the definition of ‘internet connected device’.

Whether or not the definition specifically applies to industrial control systems used by federal agencies is slightly less clear. They can certainly be ‘internet connected devices’, but arguments could be made that ICS devices are not included since they are not ‘information systems’ as that term is used in the definition of security vulnerability. I do not think that anyone on Warner’s staff had a firm idea either way when they wrote this bill.

The biggest problem with this bill (from the view point of contractors) are the provisions of §3(a)(1)(A)(i) that prohibit the supplying of devices with known security vulnerabilities. Typically, computers and other electronic devices are shipped with a basic version of the software. Security updates that are developed between the date that version was installed and the contract date are then provided to the customer once the system is set up. This provision would require the contractor to open the box, apply the interim updates, and then deliver the computer. The additional time and personnel required to complete these tasks could increase the costs of the system.

Another problem is that a contractor may not be (I suspect frequently is not) the manufacturer/vendor of the device. They thus they may not know all of the security vulnerabilities known to the manufacturer. The wording of the bill does not include a qualifying ‘known to the contractor’ provision, setting the contractor up for a variety of potential problems if the contractor does not have a very close relationship with the manufacturer/vendor. This problem is made even more vexing by the use of third-party software and libraries(see for example my post here) by the manufacturer/vendor; they may not even be aware of all of the ‘known security vulnerabilities’. In some circumstances the manufacturer/vendor may not be willing to share ‘all of the known vulnerabilities’ with the contractor.

I understand the need for the first database (the listing of device types). Since researchers can only get credit for coordinated disclosure research when they conduct their research “on the same class, model, or type of the device provided to the” government, the independent researcher needs to know which devices should be used for their research. The reason for the second database (listing of devices for which security support has expired) is much less clear. I’m not sure that the crafters of the bill realize that the information in the database combined with the use of a search engine like Shodan, could provide attackers with a very interesting list of potentially vulnerable government devices.

I am rather surprised that the crafters of the bill did not provide some additional instructions about these databases. First, given congressional concern with privacy, I would have expected to see a prohibition about including personally identifiable information in the database. More importantly, I would have liked to have seen it specified that the database would not include the agency or office to which the device belonged in the device listing.

I will be surprised to see this bill actually pass in this Congress. There has been a reluctance to establish any firm cybersecurity rules legislatively. Part of that is (I hope) a realization that there is a basic lack of the necessary technological background in Congress (or its staffs) to write effective legislation about cybersecurity matters.

Having said that, I think that this legislation (with some minor fine tuning) may actually be an interesting alternative to cybersecurity mandates upon the general population. While it does not directly affect most businesses (very few actually sell to the federal government) it should have a bootstrap effect as devices meeting the government standards would also be sold to the private sector. Additionally, business wishing to ensure the cybersecurity of their own devices would have model contract language available as well as a stable of contractors available that were used to abiding by that language.

This is almost certainly not the most effective way to get to a society with an adequate basic level of cybersecurity proficiency, but it is probably the most politically expedient.