Understanding the threats that a system could be subjected to is a starting
point for deciding on what countermeasures to use to protect it. That idea
is the motivation behind the development of
"threat models", which is a term used in various contexts including
both military and computer security. It is impossible to defend
against all possible threats, so understanding which threats are to be
defended against helps focus the efforts to elements that will thwart those
attacks—without getting lost in a wide variety of other possibilities.
In the embedded systems context, a threat model is the summation of the kinds of threats the device is meant
to thwart. It is essentially a list of the attack types that will be
defended against by all elements of the system: hardware and software.
The good folks at the Embedded Linux
Conference accepted my talk, "Understanding
threat models for embedded devices", which I thought might best be
organized around this article, effectively killing two birds with one
The threat model can be considered long before
specific software choices for a device are made, as it is largely determined by the
intended function of the device. There are several things that need to be
considered, including things like the connectivity of the device (wired,
wireless, remote control, etc.), the data that the device has—or controls—access to,
the kinds of environments where it will be installed, and the technical
sophistication expected of its users. From a threat model perspective, those characteristics are
interdependent, so they can't be analyzed in isolation.
What is being protected?
One of the first things that needs to be identified is what is being
protected. At the most basic level, the proper functioning of the device
likely requires protection, so that attackers cannot cause a
denial-of-service, but there are often more assets to protect than that.
Another way to look at the problem is to consider what the consequences are
if the device is successfully attacked. Beyond just being able to disrupt
the user's enjoyment of the device, the data stored in the device or
protected by it—think router/firewall for example—needs to be
The value of that data, both to the user and to a potential attacker, is a
key factor in determining what threats are relevant.
like a television or microwave, which either don't store much in the way of
data or only store data that has a fairly low value (various settings,
favorite channels, etc.),
protecting the data from disclosure or erasure is probably not a high
priority. But for other devices, a successful attack
might drain a user's bank account, snoop on their phone calls, or permanently
delete their family photo album. From a
user—customer—perspective those differences are very important.
As the value of the data to an attacker increases, the sophistication of
the attacks also increases. A basic tenet of security is that making attacks require more
resources than an attacker gains if they are successful is an effective
means of repelling attacks.
One of the biggest factors that impacts a device's threat model is the kinds
of connectivity it has to the external world. Devices like home wireless
internet routers or network-attached storage servers have obvious network
connections, but other devices, even some that might seem to be
connection-free, often still have some means of interacting with users that
be a potential means for attack. Remote controls—or even
front panel buttons, depending on the installation location—provide a
means for providing input to a device. Any input can, of course, be used
for good or ill.
There are very few devices that take no input at all, so identifying those
inputs is important. There are obvious inputs, wired and wireless
networking, bluetooth, GPS signals, cellular voice/data, etc. There are
more subtle, and likely less useful, inputs that should also be
considered. Cameras are being added to more devices these days, and
depending on what kind of processing is done to an image, could become a
vector for attack. There have certainly been enough exploits of flaws in
image-handling libraries to give one pause.
Some inputs have much more potential for abuse than others, but as part of
coming up with a threat model, all of the system inputs should at least be
considered. It may make sense for business or other reasons to explicitly
ignore certain kinds of attacks, especially if the input mechanism is
protected in other ways. If the device is intended to be physically
secure—locked up in someone's house or server room for
instance—it may be reasonable to exclude attacks requiring physical
access from the model. That doesn't mean that those attacks are impossible
but that they require an attack focused on a particular individual or
organization, which are some of the hardest attacks to thwart.
Physical security is often assumed for servers, but embedded devices don't
necessarily have that luxury. Depending on the function of the device and
the technical knowledge of its owner, devices may be deployed in ways that
are outside of the expectations of the developers. "Home" wireless routers
are often used in small businesses and are sometimes explicitly set up for
use by the general public, in coffee shops for example. Televisions and
DVRs may be installed in bars and restaurants which expands the kinds of
attacks those devices might be subjected to.
It is important to at least think about other ways that a device might be
used. It is much easier to assume that a device will only be installed in
a "friendly" environment, or that its owner will keep it physically safe,
but those expectations may not be borne out in practice. It is also important
to consider the target market for the device and the expected level of
technical knowledge for its users.
Technically savvy computer users would probably never even consider hooking
up their NAS—with their music, photo, and movie
collection—directly to the Internet, but less sophisticated users
might. If they were trying to share photos with a relative, or some kind
of photo printing service, it might seem to be far easier to just "put it
on the net" without recognizing the privacy and security implications.
So some consideration should be given to the target market. Less
sophisticated users probably need a higher level of security, at least for
some types of devices. If the device is targeting the IT department at a
company, some level of security knowledge can
probably—hopefully—be assumed. But that same device in the
hands of someone with no security training or awareness may be at much more
Another consideration is how the device gets its updates in the event of a
security flaw. These days, most devices have some means to update the
firmware for security, other bugs, or to add—and sometimes subtract—functionality.
In order for security updates to get installed, though, the user must know
about the problem, and have the capability to perform the upgrade. Systems
that do not plan to have an easy path for user upgrades will probably want
to put more effort into ensuring that the firmware that ships has been
carefully vetted based on the other factors in its threat model.
A television with HDMI, remote control, and front panel inputs is not
susceptible to very many kinds of attacks. There are potentially
denial-of-service attacks possible via the latter two input methods, but
the data being protected is of fairly low value (if there is any data at
all). The users are likely to have little security awareness, but since
there is little of value and few ways to impact the device, the security
needs are fairly minimal. The biggest problem might be someone
surreptitiously changing the channel or volume via a universal
remote—something that is completely outside of the scope of problems
that a television manufacturer should be expected to thwart.
A NAS box targeted at home users to store various multimedia files
throughout the home has an entirely different profile. Other than a power
switch, there probably isn't any real front panel, but there is a network
interface, which is where most of the exposure comes from. The data is of
fairly high value to its owner, and while its value to an attacker is variable,
it is probably fairly low. An attacker who could deny access to the device
or its contents might be in a position to extract a ransom to restore it.
If the system could be compromised, though, it is likely to be powerful enough to
be of interest as a botnet participant, which may be the most likely attack
Targeting the home market means that users are not likely to
have a lot of technical expertise, so they may install and use the device
in unexpected ways. But even for those devices that are properly installed
behind a router/firewall, there may be attacks via malware running on other
computers in the network. Home networks are often considered to be "safe",
but browser and other malware attacks against devices behind the firewall,
or the firewall itself, are certainly not unknown. Probably one of the
more common mistakes that is made with these kinds of devices is using a
default administrative password that never gets changed—malware
doesn't have to work very hard to exploit that flaw.
Other devices will have different characteristics, of course, but analyzing
the device to determine
the threats to defend against is similar. Using the value of the
data, the kinds of inputs the device has, its users, and how it is intended
to be installed, one can start prioritizing which functional areas of the
device software need the most attention. Explicitly rejecting certain
kinds of attack scenarios will also assist in cutting down on the work that
needs to be done, as long as customer expectations are set correctly.
Doing this analysis during product planning, rather than after there is
working prototype or, worse yet, a shipping product, will make it much less
disruptive resulting in a better, more secure device.
Device manufacturers, like software vendors, often see security problems as
a public relations issue, which it is to some extent. But it is really
more of a customer relations problem—if customers have been burned by
security problems in a particular vendor's device, they are much less likely
to purchase from that vendor again. As a large software vendor in the
found out, once a reputation for poor security is established, it can be
very hard to undo. It's much better to "bake security in" rather than just
hope that no security issues arise.
to post comments)