Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Partner Perspectives  Connecting marketers to our tech communities.
SPONSORED BY
11/9/2017
09:00 AM
Raymond Pompon
Raymond Pompon
Partner Perspectives
Connect Directly
Twitter
RSS
50%
50%

'Goldilocks' Legislation Aims to Clean up IoT Security

The proposed Internet of Things Cybersecurity Improvement Act of 2017 is not too hard, not too soft, and might be just right.

David Holmes contributed to this article.

Cybercrime in general — and most recently, crime perpetrated using IoT devices — has become a serious problem. Legislatures around the world have struggled to write laws to rein things in. The problem has been that governments have issued cybersecurity laws that are either too burdensome or ineffective.

We’ve seen various breach disclosure acts designed to "name and shame" organizations for their security failures in hopes that exposure will lead to better security. There have been presidential directives that seem to only reiterate the importance of security, suggest more study and cooperation, or rearrange government agencies. At the other end of the spectrum, we’ve seen very prescriptive, resource-intensive laws like GDPR and HIPAA mandating large infrastructures of security controls, policies, and reporting.

Now in the US we’re seeing "Goldilocks" proposed IoT legislation that’s not too hard, not too soft, and might be just right. It’s called the Internet of Things (IoT) Cybersecurity Improvement Act of 2017, proposed by Mark Warner (D-VA), Cory Gardner (R-CO), Ron Wyden (D-OR) and Steve Daines (R-MT).

Let’s take a closer look at its pros and cons.

The Power of the Government Purchase Order
For years, cybersecurity experts have been imploring the US government to clean up its own cybersecurity and use its mammoth buying power to push through new standards in security. A major component of the new proposed legislation does this. Not only would this be a powerful way to raise the bar across the industry, it would also be easier to pull off than larger, more direct legal measures.

The bill would require the Office of Management and Budget (OMB) to develop standards for all agencies in its purview to develop specific contractual standards for IoT security.

Government-purchased IoT devices would need to:

  • Be free of known security vulnerabilities, as defined in the NIST National Vulnerability Database
  • Have software or firmware components that accept "properly authenticated and trusted" patches from the vendor
  • Use acceptable standards for communication, encryption, and interconnection with other devices or peripherals. This means that feeble old Telnet would not be acceptable as an administrative mechanism.
  • Not include any "fixed or hard-coded" credentials (that is, passwords) for remote administration, delivery of updates, or communications
  • Have notification and disclosure methods in place for discovered security vulnerabilities
  • Be patched or have security vulnerabilities removed in a timely manner

The legislation would also require government agencies to set inventories of IoT devices and update them every 30 days. Agencies would also be required to publicly disclose which IoT devices have gone out of support, and which have liability protections.

Considering that the US government is budgeted to spend nearly $85 billion (yes, that’s billion) in 2017 on IT, this proposed legislation casts a huge shadow across the industry.

Liberty to Do Research on Security Flaws
Another positive of this bill is that it would provide safe harbor for security researchers who have been under the chilling effects of the Computer Fraud and Abuse Act (CFAA). To recap, CFAA states a person is committing a crime if he or she accesses a computer without authority and causes harm. Unfortunately, this act, which began with good intentions to ensure that computer crimes not go unpunished, has been used against security researchers who often uncover serious weaknesses in software, systems, and devices. As a result, CFAA has dampened efforts by researchers to find new security vulnerabilities before the bad guys do (and the bad guys just ignore this law, anyway).

Specifically, the bill would set up an exemption both in the CFAA and the Digital Millennium Copyright Act (DMCA) (which prohibits tampering with copyright restrictive mechanisms) for security researchers who test "in good faith" the security of any IoT device being used by a federal agency.

Note that the law doesn’t protect security researchers from being sued for libel if they publish false results. There’s already been at least one big dust-up regarding security vulnerability disclosure and libel around medical devices.

What’s Not So Great
One hard nut to crack is defining exactly what an IoT device is. This bill goes a little too gray in that area and scopes in all "Internet-connected devices" which are 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.

This basically includes any computing device, far beyond IoT. It also calls into question any virtual or cloud-computing system. But do they really qualify?

A law wouldn’t be a law if it didn’t have exceptions, and this proposed law has several. For one, manufacturers can be waived from the requirements if they disclose known vulnerabilities, possible mitigations, and provide "a justification for secure use of the device notwithstanding the persisting vulnerability."

There are also exceptions for devices of "severely limited functionality" that would be "unfeasible" or "impractical" to secure to the requirements. Of course, any Internet-connected IoT device could still be subverted into a thingbot for DDoS attacks and other mayhem, regardless of its "limited functionality."

All in all, the proposed legislation is not bad. Let’s hope it passes. If not, manufacturers, without any accountability whatsoever, will continue to build vulnerable IoT devices. And government agencies and consumers will continue to purchase these vulnerable devices, many of which will inevitably become part of worldwide thingbots (like Mirai), used to pull off massive attacks like those seen in late 2016.

Get the latest application threat intelligence from F5 Labs.

 

Raymond Pompon is a Principal Threat Researcher Evangelist with F5 labs. With over 20 years of experience in Internet security, he has worked closely with Federal law enforcement in cyber-crime investigations. He has recently written IT Security Risk Control Management: An ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Threaded  |  Newest First  |  Oldest First
COVID-19: Latest Security News & Commentary
Dark Reading Staff 10/23/2020
Modern Day Insider Threat: Network Bugs That Are Stealing Your Data
David Pearson, Principal Threat Researcher,  10/21/2020
Are You One COVID-19 Test Away From a Cybersecurity Disaster?
Alan Brill, Senior Managing Director, Cyber Risk Practice, Kroll,  10/21/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
Special Report: Computing's New Normal
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-27743
PUBLISHED: 2020-10-26
libtac in pam_tacplus through 1.5.1 lacks a check for a failure of RAND_bytes()/RAND_pseudo_bytes(). This could lead to use of a non-random/predictable session_id.
CVE-2020-1915
PUBLISHED: 2020-10-26
An out-of-bounds read in the JavaScript Interpreter in Facebook Hermes prior to commit 8cb935cd3b2321c46aa6b7ed8454d95c75a7fca0 allows attackers to cause a denial of service attack or possible further memory corruption via crafted JavaScript. Note that this is only exploitable if the application usi...
CVE-2020-26878
PUBLISHED: 2020-10-26
Ruckus through 1.5.1.0.21 is affected by remote command injection. An authenticated user can submit a query to the API (/service/v1/createUser endpoint), injecting arbitrary commands that will be executed as root user via web.py.
CVE-2020-26879
PUBLISHED: 2020-10-26
Ruckus vRioT through 1.5.1.0.21 has an API backdoor that is hardcoded into validate_token.py. An unauthenticated attacker can interact with the service API by using a backdoor value as the Authorization header.
CVE-2020-15272
PUBLISHED: 2020-10-26
In the git-tag-annotation-action (open source GitHub Action) before version 1.0.1, an attacker can execute arbitrary (*) shell commands if they can control the value of [the `tag` input] or manage to alter the value of [the `GITHUB_REF` environment variable]. The problem has been patched in version ...