Vulnerabilities / Threats
9/9/2013
11:48 PM
Connect Directly
Twitter
Twitter
RSS
E-Mail
50%
50%
Repost This

Tackling Enterprise Threats From The Internet Of Things

Embedded device dangers don't just plague consumers or industrial control systems

With all of the sensational stories about baby monitors being taken over by remote intruders and SCADA systems perennially vulnerable to potentially disastrous flaws, it's easy to forget that insecurity in the Internet of Things isn't just relegated to consumer devices and critical infrastructure.

The ever-growing fabric of smart devices with dumb security poses very real workaday risk to the average enterprise. Risk comes by way of network devices, physical security systems, instrumentation systems, and any number of machine-to-machine (M2M) communications running in enterprises today.

In short, the Internet of Things "brings a whole new Internet of harms," says Jeff Williams, CEO of Aspect Security.

"Currently, most harms caused by Internet attackers cause digital harm, not physical," he says. "But when attacks can have real-world consequences, attackers will surely find a whole new set of ways to cause harm: causing fires, overloading networks, turning off refrigeration, opening locks, blocking communications, starting alarms, suppressing alarms, cutting power, releasing chemicals, stopping cars, hiding the remote. The jump to an Internet of Things is huge, and so is the leap in security thinking that will be needed to make it safe."

As Williams' examples show, one of the big issues posed by embedded systems and M2M is the blurring of the line between physical and logical security, with vulnerabilities in either potentially compromising both.

[Is IPS in it for the long haul? See The Future of IPS.]

"As these lines blur and more systems and things are brought into the IT/IS framework, it stretches the boundaries of what is now considered a targetable asset and how we must protect them," says Vann Abernethy, senior product manager at NSFOCUS. "It is no longer just information that we must safeguard, but physical security systems, manufacturing automation, and the physical machines themselves."

Often the weakest and most dangerous links in the embedded device ecosystem are those small devices that are small enough for administrators to forget about, but large enough to be running a full Linux stack or a full version of embedded Windows, says Spencer McIntyre, security researcher for SecureState.

"These devices are running software that is well-known enough that there are vulnerabilities in them, and these vulnerabilities can be leveraged by attackers," he says. "A lot of times it's all that is needed by an attacker to be able to pivot into a network and gain access into more systems."

McIntyre gives an example of a penetration test one of his colleagues ran just last week that played out that scenario exactly. According to McIntyre, his co-worker used an exploit that McIntyre had written in the past year for LifeSize teleconferencing systems to compromise one of those devices in the client's environment.

"He was able to use that as a beachhead to actually contact the internal domain controllers of this organization, and he was able to run attacks on internal systems from this teleconferencing system that was exposed to the Internet," he says.

According to HD Moore, chief research officer at Rapid7, the pervasive susceptibility of embedded systems to exploit is like de ja vu for the security world.

"This is like 1995 all over again; it's great from an exploit standpoint, but it's terrible for all of security," he says. "We spent all this time trying to lock things down, like Windows 7 having ASLR, and [developing] all these really great tools to lock down your desktops and clients and even mobile phones that are getting pretty solid. You don't see these types of improvements happening in the embedded device world."

Moore has spent a good part of 2013 conducting research about the state of embedded devices online -- this past spring he published a report that showed more than 300 million IPs online hosting network devices with known flaws or configuration problems. Such statistics show that we're at another security inflection point, experts say.

"I think we're at a place where we need to figure out what to do because we do need to do something about this," says Adam Ely, co-founder of Bluebox Security. "We have to understand how we protect ourselves, how we update ourselves, and then once we understand that, to apply context and risk-based practices to it to really know what to address -- and in what order -- and what doesn't matter."

Abernethy believes that in this quest of improving the security around embedded devices, forensics and situation awareness become even more important than with traditional systems.

"Track and monitor everything," he suggests. "Build zones and track their interactions - understand how each system works, how they interrelate and look at all possible vectors."

Additionally, the industry and enterprises must work together to find better ways to update systems when vulnerabilities are discovered.

Perhaps more radical, some within the identity and access management (IAM) world say that getting embedded risks under control will require a paradigm shift in access management, moving from a user-centric to a device-centric view of how identities are managed.

"As more and more devices become connected and 'self aware,' we are going to need to be able to reliably and uniquely identify each thing, regardless of location or any kind of static context," says Allan Foster, vice president of community at IAM vendor ForgeRock. "Not only do we need to identify the thing, but we also need to ensure that the identity cannot be hijacked or impersonated, whether the cause is malevolence or a stressed environment."

This may not necessarily supersede other pushes for user federation schemes, but it could mean added layers of complexity and standards, involved in IAM initiatives, says Patrick Harding, CTO of Ping Identity.

"The identity protocols and token formats used to communicate device identity versus user identity should be consistent," he says. "There are existing initiatives that aim to standardize M2M interactions across this heterogeneity, so the hope is that, like IP and HTTP on the Internet, there will be a common addressing model and set of protocols."

Have a comment on this story? Please click "Add Your Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message. Ericka Chickowski specializes in coverage of information technology and business innovation. She has focused on information security for the better part of a decade and regularly writes about the security industry as a contributor to Dark Reading.  View Full Bio

Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
White Papers
Cartoon
Current Issue
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2012-0360
Published: 2014-04-23
Memory leak in Cisco IOS before 15.1(1)SY, when IKEv2 debugging is enabled, allows remote attackers to cause a denial of service (memory consumption) via crafted packets, aka Bug ID CSCtn22376.

CVE-2012-1317
Published: 2014-04-23
The multicast implementation in Cisco IOS before 15.1(1)SY allows remote attackers to cause a denial of service (Route Processor crash) by sending packets at a high rate, aka Bug ID CSCts37717.

CVE-2012-1366
Published: 2014-04-23
Cisco IOS before 15.1(1)SY on ASR 1000 devices, when Multicast Listener Discovery (MLD) tracking is enabled for IPv6, allows remote attackers to cause a denial of service (device reload) via crafted MLD packets, aka Bug ID CSCtz28544.

CVE-2012-3062
Published: 2014-04-23
Cisco IOS before 15.1(1)SY, when Multicast Listener Discovery (MLD) snooping is enabled, allows remote attackers to cause a denial of service (CPU consumption or device crash) via MLD packets on a network that contains many IPv6 hosts, aka Bug ID CSCtr88193.

CVE-2012-3918
Published: 2014-04-23
Cisco IOS before 15.3(1)T on Cisco 2900 devices, when a VWIC2-2MFT-T1/E1 card is configured for TDM/HDLC mode, allows remote attackers to cause a denial of service (serial-interface outage) via certain Frame Relay traffic, aka Bug ID CSCub13317.

Best of the Web