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
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
Newest First  |  Oldest 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.
Edge-DRsplash-10-edge-articles
7 Old IT Things Every New InfoSec Pro Should Know
Joan Goodchild, Staff Editor,  4/20/2021
News
Cloud-Native Businesses Struggle With Security
Robert Lemos, Contributing Writer,  5/6/2021
Commentary
Defending Against Web Scraping Attacks
Rob Simon, Principal Security Consultant at TrustedSec,  5/7/2021
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win an Amazon Gift Card! Click Here
Latest Comment: Take me to your BISO 
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
Flash Poll
How Enterprises are Developing Secure Applications
How Enterprises are Developing Secure Applications
Recent breaches of third-party apps are driving many organizations to think harder about the security of their off-the-shelf software as they continue to move left in secure software development practices.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2021-30174
PUBLISHED: 2021-05-11
RiyaLab CloudISO event item is added, special characters in specific field of time management page are not properly filtered, which allow remote authenticated attackers can inject malicious JavaScript and carry out stored XSS (Stored Cross-site scripting) attacks.
CVE-2021-32544
PUBLISHED: 2021-05-11
Special characters of IGT search function in igt+ are not filtered in specific fields, which allow remote authenticated attackers can inject malicious JavaScript and carry out DOM-based XSS (Cross-site scripting) attacks.
CVE-2021-32563
PUBLISHED: 2021-05-11
An issue was discovered in Thunar before 4.16.7 and 4.17.x before 4.17.2. When called with a regular file as a command-line argument, it delegates to a different program (based on the file type) without user confirmation. This could be used to achieve code execution.
CVE-2020-23369
PUBLISHED: 2021-05-10
In YzmCMS 5.6, XSS was discovered in member/member_content/init.html via the SRC attribute of an IFRAME element because of using UEditor 1.4.3.3.
CVE-2020-23370
PUBLISHED: 2021-05-10
In YzmCMS 5.6, stored XSS exists via the common/static/plugin/ueditor/1.4.3.3/php/controller.php action parameter, which allows remote attackers to upload a swf file. The swf file can be injected with arbitrary web script or HTML.