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.

Threat Intelligence

12/24/2019
09:00 AM
Connect Directly
Twitter
LinkedIn
Google+
RSS
E-Mail
100%
0%

IoT Security: How Far We've Come, How Far We Have to Go

As organizations fear the proliferations of connected devices on enterprise networks, the private and public sector come together to address IoT vulnerabilities.

Experts agree manufacturers should be playing a bigger role in how their products are secured. Most, says Carson, prioritize ease of use, ease of deployment, and low cost over device security.

There are two categories of IoT device manufacturers, Heiland explains. The first, he says, are "white label" manufacturers selling blank devices other companies can put their names on. This often becomes a bigger security issues, he adds, because it's difficult to trace a product back to its manufacturer if vulnerabilities are found. Rapid7 researchers faced this precise vendor visibility challenge when they investigated bugs in children's GPS-enabled smartwatches.

The other category includes brand-name tech companies, which over the past few years have expanded their security involvement and let vulnerabilities be reported. These companies, says Heiland, are better prepared to adopt emerging guidelines and requirements because they have sufficient resources. White-label manufacturers, on the other hand, may not be ready.

"We would argue people should probably getting more security audits throughout the development process," says Shaunak Mirani, researcher with Independent Security Evaluators (ISE), which recently published updated research on its analysis of routers and network-attached storage (NAS) devices. What they found are high-severity vulnerabilities that enable root compromise of a router or NAS from an attacker who has network-level access to the device.

Pivoting activity, says Mirani, is the major threat he sees with IoT devices. "One IoT device by itself may not have a huge risk factor, but when you start chaining things together, and get one device to talk to another, and dig deeper into the network … that's the real threat."

Overall, Clay says, manufacturers are starting to realize security is a critical component of device development, manufacturing, and release; however, "they're slow on the uptake of that." A lack of activity is pushing federal and state regulators to create guidelines and rules.

Regulations and Standards and Ratings, Oh My!

One of these measures is California's IoT Device Security Act (SB-327), which is poised for implementation on Jan. 1, 2020. The bill requires IoT device manufacturers to equip connected products with "reasonable security feature or features" appropriate to the nature or function of the device; appropriate to the data it may collect, hold, or transmit; and designed to protect the device and its data from unauthorized access, destruction, use, modification, or disclosure.

If a connected device has means for authentication outside a local area network, the bill states, it will be considered a security feature if the preprogrammed password is unique to each device, and if the device requires its user to create new credentials before gaining initial access. Even with these specifications, the bill's language is ambiguous, notes Harley Geiger, director of public policy for Rapid7, who points out the law was replicated in Oregon this summer. It doesn't say how "reasonable security" varies among devices, or how the bill will be enforced.

"Whether the companies will meet these obligations will depend on how realistic they are," Geiger continues. Some draft regulations would require fixing every vulnerability to achieve a standard of reasonable security, which he says isn't consistent with risk management practices.

California's bill isn't the only measure aiming to improve IoT security. Some, like this one, are requirements. Others, like NIST's "Core Cybersecurity Feature Baseline for Securable IoT Devices" released this summer, are more like "strongly worded guidelines," Geiger adds.

Indeed, NIST's core baseline details "voluntary recommended cybersecurity features" to build into network-capable devices. These include device identification for connecting to a network; device configuration to provide an option for changing software and firmware; data protection for information stored and sent over the network; limited access to local and network interfaces; updatable software and firmware; and accessible cybersecurity event logging.

Across the pond, the UK published its own Code of Practice for Consumer IoT Security, which contains 13 outcome-focused guidelines detailing best IoT security practices for manufacturers and other industry bodies. It also emphasizes default passwords in its first guideline: "All IoT device passwords shall be unique and not resettable to any universal factory default value."

Its second guideline advises vulnerability disclosure policies and suggests businesses provide a public point-of-contact for security researchers to report issues. The Code of Practice also encourages timely and secure software updates, secure credential storage (hard-coded credentials are discouraged), and encrypted transmission of security-sensitive information.

                                                                     (Continued on Next Page)

Kelly Sheridan is the Staff Editor at Dark Reading, where she focuses on cybersecurity news and analysis. She is a business technology journalist who previously reported for InformationWeek, where she covered Microsoft, and Insurance & Technology, where she covered financial ... View Full Bio
 

Recommended Reading:

Previous
2 of 3
Next
Comment  | 
Print  | 
More Insights
Comments
Oldest First  |  Newest First  |  Threaded View
tlanowitz
50%
50%
tlanowitz,
User Rank: Author
1/24/2020 | 11:58:04 AM
Need for a Shared Security Model
This insightful article exemplifies the need for a shared security model. In a shared security model, the enterprise assumes responsibility for devices (IoT in this example) on the network. And, with a 5G network, which will allow IoT initiatives to gain momentum in the market, the network operator is responsible for the elements of security listed out in 3GPP frameworks and standards (i.e. data encryption and radio access network) as well as the handling the security of the network infrastructure.
COVID-19: Latest Security News & Commentary
Dark Reading Staff 8/10/2020
Pen Testers Who Got Arrested Doing Their Jobs Tell All
Kelly Jackson Higgins, Executive Editor at Dark Reading,  8/5/2020
Researcher Finds New Office Macro Attacks for MacOS
Curtis Franklin Jr., Senior Editor at Dark Reading,  8/7/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
Special Report: Computing's New Normal, a Dark Reading Perspective
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
The Changing Face of Threat Intelligence
The Changing Face of Threat Intelligence
This special report takes a look at how enterprises are using threat intelligence, as well as emerging best practices for integrating threat intel into security operations and incident response. Download it today!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-7029
PUBLISHED: 2020-08-11
A Cross-Site Request Forgery (CSRF) vulnerability was discovered in the System Management Interface Web component of Avaya Aura Communication Manager and Avaya Aura Messaging. This vulnerability could allow an unauthenticated remote attacker to perform Web administration actions with the privileged ...
CVE-2020-17489
PUBLISHED: 2020-08-11
An issue was discovered in certain configurations of GNOME gnome-shell through 3.36.4. When logging out of an account, the password box from the login dialog reappears with the password still visible. If the user had decided to have the password shown in cleartext at login time, it is then visible f...
CVE-2020-17495
PUBLISHED: 2020-08-11
django-celery-results through 1.2.1 stores task results in the database. Among the data it stores are the variables passed into the tasks. The variables may contain sensitive cleartext information that does not belong unencrypted in the database.
CVE-2020-0260
PUBLISHED: 2020-08-11
There is a possible out of bounds read due to an incorrect bounds check.Product: AndroidVersions: Android SoCAndroid ID: A-152225183
CVE-2020-16170
PUBLISHED: 2020-08-11
The Temi application 1.3.3 through 1.3.7931 for Android has hard-coded credentials.