For the sake of brevity, we’re going to summarize key elements of the bill, which deals with government contracts that involve the procurement and use of “Internet-Connected Devices” (henceforth “IoT”):
- Contractors are required to certify that the IoT devices they provide to the government do not contain any known vulnerabilities per the NIST National Vulnerabilities Database or other, similar database as may be directed.
- The software or firmware on IoT devices must be “capable of accepting properly authenticated and trusted updates from the vendor.”
- Devices must use only “non-depreciated industry-standard protocols and technologies” for functions such as; communications, encryption, and interconnection with other devices.
- Contractors would be required to notify the government when they become aware of any new vulnerabilities that are disclosed by a security researcher.
- IoT devices are required to be able to be update or replace firmware or software.
- Repairs to vulnerable systems need to done in a “timely manner.”
- Contractors are required to inform the gov’t when devices or services that are used by devices become obsolete.
- Waivers can be requested for devices with vulnerabilities or weaker security, if there are any number of mitigations in place that would limit the impact of exploitation, if not preclude it altogether.
- It carves out an exception to existing cyber crime laws that protects researchers who are acting in good faith.
- The Act also creates a new IoT vulnerabilities database.
- The idea that we only deploy devices that are not vulnerable to known problems is a great idea. The problem is that the certification is only valid at the time the contractor submits their proposal. If you are not familiar with government contracting, the time between proposal submission, contract award, and the execution of the contract could be weeks or months long.
- To get IoT devices to accept ‘‘authenticated and trusted” updates from a vendor, to use current, standard protocols, maintain vigilance about new vulnerabilities, and alert customers when devices become obsolete will require extra work on the part of device manufacturers, which will drive up costs.
- Repairing vulnerable systems in a timely manner is really only a useful if “timely” is defined. If you’re familiar with the world of vulnerability disclosure, you know that what a researcher thinks is timely, and what a vendor - who has to maintain millions of lines of code - thinks is timely are often wildly different things.
- Accepting risk in any form of IT is a common and well-known process. The difference between adhering to this practice in a generic office environment and any sufficiently IoT-rich environment is that should a mitigation fail the results are not merely lost data or downtime, but potentially disruption of critical services and loss of life.
As far as legislation for computer security-related issues goes, this is arguably one of the better attempts ever taken. In the midst of our headlong rush to connect computers to everything in the name of convenience and functionality, this is Congress standing athwart history saying “stop,” and demanding that some very common-sense steps be taken to reduce risks.
Having said that, it is clearly an effort targeted at the center mass of IoT devices - which is the only way to come up with a workable policy - so by definition it leaves a lot of edges exposed. You don’t have to work in security for very long to know that it is those fringe situations that will get you every time. This bill leads to the eventual creation of discrete pockets of IoT that are more difficult to hack, it does not necessarily make any given enterprise immune to denial, disruption, or destruction.
All of this will, of course, come at a cost. IoT customers writ large demand functional devices. A “secure” IoT device is going to cost more to design, make, and maintain. How much more has yet to be determined, but the cost of automating and operating any sort of critical infrastructure or IoT-rich environment run by the government just got considerably more expensive. Perhaps so expensive a significant number of manufacturers decide doing business with the government is not worth it. Worst-case scenario: a monoculture, and all of its associated risks.
Something the bill does not address: the millions of IoT devices currently in use by government agencies today. We don’t even know if millions is the right order of magnitude when it comes to the presence of IoT devices - in their many flavors, forms, and styles - currently in use by Uncle Sam. The assumption has probably been made that legacy systems will eventually be replaced by devices covered under the proposed legislation, which is really the best we can hope for since the federal budget is not infinite and upgrading such systems cannot be done instantaneously.
The basic principles laid out in the proposed legislation are a great start for any organization that currently has or is planning on increasing the presence of IoT in their enterprise. Additionally, based on our own experience, organizations should consider:
- Threat modeling. Every enterprise is a target. You may think your line of business is unimportant in a geo-political or financial context, but if you have enough IT/IoT resources, or the right trust relationships, you may be more important than you realize. Don’t guess: make security-oriented decisions based on some formal methodology.
- Improve your awareness. Security 101: know what you are protecting. Most enterprises don’t have a handle on the commodity IT they know they’ve bought, much less IoT devices. Tools or services that give you a comprehensive picture of what is actually operating on your networks are critical.
- Gain insight. All those IoT devices connect to something; can they connect to anything? Do they? Are they passing data they shouldn’t? There is no shortage of tools that will help you make sense of what PCs are doing and who they are talking to, but precious few that deal with IoT devices.
As long as current market forces reign supreme, all attempts to “secure” IoT will come up short. This legislation may not be a solution per se, but it is a great example of how to craft a workable policy that recognizes the differences between IoT and commodity IT, and the challenge of legislation keeping pace with technology. If all IoT device and system owners/operators followed suit, it would go a long way towards minimizing the inevitable pain and suffering that will result in attacks against the IoT.