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.

Risk //

Compliance

11/22/2011
05:00 PM
50%
50%

Firms Slow To Secure Flaws In Embedded Devices

While operating systems and PC applications have evolved fast patch mechanisms, the proliferation of slow-to-patch embedded devices leaves companies vulnerable

At the Black Hat Security conference earlier this year, Jerome Radcliffe, a security researcher who has diabetes, showed off weaknesses in the security of a popular insulin pump. Last month, another researcher at security firm McAfee expanded on the attack, showing how the pumps could be easily attacked and that manufacturers were unprepared to fix the problem.

The hack of the insulin pump demonstrates a major problem with embedded devices: Most systems were never designed to be easily updated. With researchers increasingly looking at software systems embedded in automobiles, network routers, printers, and industrial control systems, a growing number of vulnerabilities will be found. Yet fixing those flaws in the field is not easy, says Stuart McClure, general manager of risk and compliance for McAfee.

"It takes a year to get any bit on the device changed," he says. "It is a big problem that has to be overcome in order to secure the systems."

Android phones are another example. While Google fixes the flaws on the devices quickly, many patches languish in manufacturers' development shops or in quality assurance testing at the carrier.

The problems will become only more common. Security researchers are increasingly targeting the embedded software in devices because general-purpose computer systems have become tougher to exploit, says Ron Gula, chief technology officer for Tenable Network Security.

"We got really, really good at securing Microsoft, so what are people doing? They are going after an easier target," Gula says.

For companies worried about vulnerable embedded devices in their networks, the first action should be to identify every network-connected device and look for vulnerable services. No company should be running a telnet service, even inside the corporate network, Gula says.

"There are devices that you might not know are in your network, so scanning is critical," he says.

Cordoning off the devices that are known to be vulnerable from general network access is a good next step. While business users might want remote administration capabilities, such convenience sacrifices security, says Eric Knapp, director of critical infrastructure markets for NitroSecurity.

"As soon as you give them remote access, you open up a potential security hole," Knapp says.

Finally, any company that makes an appliance or embedded device needs to solve the problem of patches that significantly lag vulnerabilities, Tenable's Gula says. Companies should push their vendors to find ways to securely speed up patch deployment, similar to the major software vendors in the personal computer market.

"We are familiar with Microsoft Tuesday; there is nothing like a Cisco Wednesday," Gula says. "You really need transparency with embedded devices to figure out what patches are necessary."

Yet embedded systems will likely always take longer to patch, says Marc Brown, vice president of tools for Wind River. Many embedded device manufacturers will be able to speed up patch distribution and close security holes, especially on network-connected devices. However, more deeply embedded systems, such as industrial control and monitoring equipment, will not have an easy path to patches, he says.

"You will have high-end devices, like Android phones, that will be patchable, and low-end ones that won't be updated and so still have risk," Brown says.

Have a comment on this story? Please click "Discuss" below. If you'd like to contact Dark Reading's editors directly, send us a message.

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Why Cyber-Risk Is a C-Suite Issue
Marc Wilczek, Digital Strategist & CIO Advisor,  11/12/2019
Unreasonable Security Best Practices vs. Good Risk Management
Jack Freund, Director, Risk Science at RiskLens,  11/13/2019
Breaches Are Inevitable, So Embrace the Chaos
Ariel Zeitlin, Chief Technology Officer & Co-Founder, Guardicore,  11/13/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
Navigating the Deluge of Security Data
In this Tech Digest, Dark Reading shares the experiences of some top security practitioners as they navigate volumes of security data. We examine some examples of how enterprises can cull this data to find the clues they need.
Flash Poll
New Best Practices for Secure App Development
New Best Practices for Secure App Development
The transition from DevOps to SecDevOps is combining with the move toward cloud computing to create new challenges - and new opportunities - for the information security team. Download this report, to learn about the new best practices for secure application development.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-19010
PUBLISHED: 2019-11-16
Eval injection in the Math plugin of Limnoria (before 2019.11.09) and Supybot (through 2018-05-09) allows remote unprivileged attackers to disclose information or possibly have unspecified other impact via the calc and icalc IRC commands.
CVE-2019-16761
PUBLISHED: 2019-11-15
A specially crafted Bitcoin script can cause a discrepancy between the specified SLP consensus rules and the validation result of the [email protected] npm package. An attacker could create a specially crafted Bitcoin script in order to cause a hard-fork from the SLP consensus. All versions >1.0...
CVE-2019-16762
PUBLISHED: 2019-11-15
A specially crafted Bitcoin script can cause a discrepancy between the specified SLP consensus rules and the validation result of the slpjs npm package. An attacker could create a specially crafted Bitcoin script in order to cause a hard-fork from the SLP consensus. Affected users can upgrade to any...
CVE-2019-13581
PUBLISHED: 2019-11-15
An issue was discovered in Marvell 88W8688 Wi-Fi firmware before version p52, as used on Tesla Model S/X vehicles manufactured before March 2018, via the Parrot Faurecia Automotive FC6050W module. A heap-based buffer overflow allows remote attackers to cause a denial of service or execute arbitrary ...
CVE-2019-13582
PUBLISHED: 2019-11-15
An issue was discovered in Marvell 88W8688 Wi-Fi firmware before version p52, as used on Tesla Model S/X vehicles manufactured before March 2018, via the Parrot Faurecia Automotive FC6050W module. A stack overflow could lead to denial of service or arbitrary code execution.