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
Newest First  |  Oldest First  |  Threaded View
Page 1 / 2   >   >>
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.
RyanSepe
50%
50%
RyanSepe,
User Rank: Ninja
12/30/2019 | 1:08:01 AM
Re: Printers
Any IoT device needs to be secured and patched but you're right, these things way to often take a backseat to more conventional infrastructure.
RyanSepe
50%
50%
RyanSepe,
User Rank: Ninja
12/30/2019 | 1:06:59 AM
Re: Open-source
True, unfortunately the flipped side to that easier to attack coin is that it makes it easier for individuals with more altruistic intent to make a product better than its original form because they have access to the source code.

The dichotemy of the human element is truly astounding to behold.
RyanSepe
50%
50%
RyanSepe,
User Rank: Ninja
12/30/2019 | 1:04:33 AM
Re: DDoS
It's funny you should mention this because I brought this up in a response to one of your other posts. I don't think people outside of the security realm fully comprehend how easy it is to launch a DDoS attack. Very little effort or technical inclination is required and even without those two items you could sub it out using a Remote Access Tool for hire.
RyanSepe
50%
50%
RyanSepe,
User Rank: Ninja
12/30/2019 | 1:02:25 AM
Re: POS
Couldn't agree more. Unfortunately with POS being targets of DDoS and Ransomware, two very simplistic attack methods, they are subject to be targeted by any script kiddy looking for a thrill, all the way up to attackers with more nefarious intentions.
RyanSepe
50%
50%
RyanSepe,
User Rank: Ninja
12/30/2019 | 1:00:46 AM
Re: Patch management
To add to this I think most corporations are not certain where to start. I gave a speech this summer at a security conference that touched on Vulnerability and Patch Management and many were unsure before the topic on how the two were different.

Vulnerability Management highlights the exposures and provides the method for which to remediate them. This is to be performed by the Security Practioner.

Patch Management is to be performed by someone in SysOps or SysEng and NOT to be performed by the security team. 

Providing this data at a high level because I could go on at length about how pivotal it is to optimize these two programs within corporations to stay ahead of the curve.
Dr.T
50%
50%
Dr.T,
User Rank: Ninja
12/29/2019 | 2:32:43 PM
Patch management
Many companies continue to struggle with patch management efforts, And greatly fail. Most of us not up to date in a timely manner, and that is one of the main reasons we have the problems today.
Dr.T
50%
50%
Dr.T,
User Rank: Ninja
12/29/2019 | 2:30:44 PM
POS
Criminals are narrowing their focus on IoT, evolving from ransomware or point-of-sale malware to specifically targeting connected devices. POS devices are target for both DDoS and ransomware, their firmware needs to be up to date.
Dr.T
50%
50%
Dr.T,
User Rank: Ninja
12/29/2019 | 2:24:55 PM
DDoS
who are targeting firmware at scale or leveraging connected devices in DDoS attacks. DDoS is one of the primary problems in IoT world, easy to execute and maximum damage.
Dr.T
50%
50%
Dr.T,
User Rank: Ninja
12/29/2019 | 2:18:47 PM
Open-source
it's open-source and free, so attackers don't have to work very hard. This is one of the problem with open-source, we know what is happening in the code so easier to hack.
Page 1 / 2   >   >>
COVID-19: Latest Security News & Commentary
Dark Reading Staff 7/2/2020
Ripple20 Threatens Increasingly Connected Medical Devices
Kelly Sheridan, Staff Editor, Dark Reading,  6/30/2020
DDoS Attacks Jump 542% from Q4 2019 to Q1 2020
Dark Reading Staff 6/30/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
How Cybersecurity Incident Response Programs Work (and Why Some Don't)
This Tech Digest takes a look at the vital role cybersecurity incident response (IR) plays in managing cyber-risk within organizations. Download the Tech Digest today to find out how well-planned IR programs can detect intrusions, contain breaches, and help an organization restore normal operations.
Flash Poll
The Threat from the Internetand What Your Organization Can Do About It
The Threat from the Internetand What Your Organization Can Do About It
This report describes some of the latest attacks and threats emanating from the Internet, as well as advice and tips on how your organization can mitigate those threats before they affect your business. Download it today!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-9498
PUBLISHED: 2020-07-02
Apache Guacamole 1.1.0 and older may mishandle pointers involved inprocessing data received via RDP static virtual channels. If a userconnects to a malicious or compromised RDP server, a series ofspecially-crafted PDUs could result in memory corruption, possiblyallowing arbitrary code to be executed...
CVE-2020-3282
PUBLISHED: 2020-07-02
A vulnerability in the web-based management interface of Cisco Unified Communications Manager, Cisco Unified Communications Manager Session Management Edition, Cisco Unified Communications Manager IM & Presence Service, and Cisco Unity Connection could allow an unauthenticated, remote attack...
CVE-2020-5909
PUBLISHED: 2020-07-02
In versions 3.0.0-3.5.0, 2.0.0-2.9.0, and 1.0.1, when users run the command displayed in NGINX Controller user interface (UI) to fetch the agent installer, the server TLS certificate is not verified.
CVE-2020-5910
PUBLISHED: 2020-07-02
In versions 3.0.0-3.5.0, 2.0.0-2.9.0, and 1.0.1, the Neural Autonomic Transport System (NATS) messaging services in use by the NGINX Controller do not require any form of authentication, so any successful connection would be authorized.
CVE-2020-5911
PUBLISHED: 2020-07-02
In versions 3.0.0-3.5.0, 2.0.0-2.9.0, and 1.0.1, the NGINX Controller installer starts the download of Kubernetes packages from an HTTP URL On Debian/Ubuntu system.