Posted on by Researchin
Hi folks, Allen Householder here. I want to introduce some recent work we're undertaking to look at vulnerability discovery for emerging networked systems (including cyberphysical systems like home automation, networked cars, industrial control systems and the like). In this post I cover the background and motivation for this work, our approach, and some preliminary findings. In future posts I will cover additional results from this effort.
The project started as "Vulnerability Discovery for Low Power and Low Bandwidth Networks," which quickly became a misnomer as we realized we were really talking about "non-traditional computing" made up of small-scale components and encompassing cyberphysical systems like medical devices, home automation, industrial control systems, smartgrid, and the internet of things (IoT). More recently we've used the phrase "Emerging Networked Systems (ENS)" as the shorthand for what's essentially an "everything else" category of things that probably have an exposed network interface yet are neither full-scale computers nor phones.
Our objective is to look at vulnerability discovery techniques for ENS and determine if and how those techniques differ from vulnerability discovery in traditional computing. We also wanted to identify useful processes, tools, and techniques to improve the security of ENS from the perspective of their developers as well as those who acquire, deploy, and operate them.
This work was motivated by observations made in the course of recent work done by the CERT Vulnerability Analysis team, including
We identified issues such as the inclusion of networked appliances in a larger system where the appliances provided networked services based on sensor data. Enterprise security policy treated the device as a black box rather than a general purpose computer with regard to patch levels, included software, etc. The attack vector posed by the sensor data interface had not been considered either.
In a number of projects, we observed that while many systems were composed of highly specified off-the-shelf and custom components, the vendors providing those systems often could not identify the third-party subcomponents present in the delivered codebase. The problem can be as simple as not identifying statically linked libraries or as complicated as dealing with complex supply chains for code components.
We observed various devices with wireless data capabilities embedded within a larger system yet little or no ability to patch the fielded systems except within very sparse service windows. Instances where physical contact with the device is required in order to update it can be especially problematic once vulnerabilities are discovered. (See Dan Geer's talk at the Security of Things Forum for more on the "long-lived and not reachable" problem.)
We also encountered smart grid devices built out of a traditional electrical component coupled to an embedded Linux system to provide networked services. In a deployment context, the device was treated as an appliance. However the impact of potential vulnerabilities in the general purpose operating system embedded in the device had not been fully addressed.
In discussing this work with other security researchers, we found that some were dismissive of the risks posed by the IoT. A typical comment was that IoT is uninteresting because its elements are "just refrigerators, toasters and crockpots, so who cares if they get owned?" We disagree:
Because many such systems and devices are expected to remain operationally useful for years or even decades with minimal intervention, it is especially important that their security be thoroughly understood prior to deployment.
Our approach involves three phases:
In this post, I focus on phase 1, our survey of recent related work.
We collected more than 70 papers and presentations from the following venues: ACSAC 2010, ACSW-AISC 2013, Australian Information Warfare and Security Conference 2011, BlackHat 2009, 2010, 2011, 2012, 2013, CanSecWest 2007, 2008, 2009, 2010, ACM CCS 2012, Chinacom 2012, Critical Infrastructure Protection (Springer) 2012, DefCon 20 and 21, DerbyCon 2013, Financial Cryptography and Data Security 2011, GreHack 2013, HealthSec 2011, HealthTech 2013, ICACCI 2013, IEEE Conference on Technologies for Homeland Security HST 2012, IEEE Transactions on Smart Grid, Infiltrate 2013, International Journal of Scientific & Engineering Research (April 2012), ITU Telecom World Technical Symposium 2011, NDSS Symposium 2013, PETS 2013, Cyber Security and Information Intelligence Research Workshop 2013, Recent Advances in Space Technologies (RAST) 2013, Shmoocon 2011, 2012, 2013, and Usenix Security 2010
The papers covered topics including
As we reviewed the research in our survey, we found a number of techniques in common use. Ranked in approximately descending order of popularity in the research we surveyed, the vulnerability discovery techniques used were
Many of the techniques listed in this post are common to vulnerability discovery in the traditional computing and mobile world. However, the low hanging fruit (or as some have put it, the windfall) appear to hang much lower in ENS than in traditional computing. From a security perspective, even mobile systems have a head start although they are not as far along as traditional computing platforms. The fact is that many of the vulnerabilities found thus far in ENS would be considered trivial (and rightly so) in the more mature market of servers and desktop computing. Yet the relative scale of the ENS market makes even trivial vulnerabilities potentially risky in aggregate.
Wrapping up, I hope this post has given you a better understanding of how researchers are finding vulnerabilities in ENS and provides some background on why our vulnerability research and analysis at the CERT/CC is branching out in this direction.
In my next post I'll discuss some of the ways ENS are different from traditional computing and mobile systems.