Securing The Coming M2M Communications Boom
All points connect to exceed 60 billion devices by 2020
- By Cathal McDaid
- Dec 01, 2012
It is beyond dispute that Machine to Machine
(M2M) technology and communications
will influence our daily personal and
business lives in the coming years. We
define M2M communications as involving
a device or devices communicating automatically
using the mobile network, either
to another machine or to another person through embedded
mobile technology. These connections, in part, will allow the
expansion of what is being termed the “Internet of things,”
and telecommunications giant Ericsson predicts the number
of devices connected through all points could exceed 60
billion by 2020.
We will see the technology used in everything from smart meters
measuring energy use to embedded devices in automobiles
that will allow remote car controlling and healthcare devices
that will enable the transmission of patient health statistics from
a device to a physician database.
Ericsson’s data give a sense of what the current rate of M2M
communications are; the company’s statistics show that between
3 to 4 percent of traffic over its network is currently M2M related.
This rate is equivalent to one in 20 messages having been
generated and sent between machines.
Exponential growth in any interconnected environment
brings up security concerns. Historically, in the technology industry,
identifying and remedying security weak points has
come months or years after the growth has occurred. For example,
think of the early days of Internet use before antivirus
technology became commonplace.
For the M2M environment, the very aspects that make it
unique—namely, that it connects machines that contain essential
information for our daily lives—also make securing those
connections that much more complicated.
The industry still has time before the fast-paced growth occurs
to put controls in place that will allow more secure M2M communications.
There are five threat points that need to be understood,
with underlying weaknesses addressed for better M2M security.
Assessing the Threat Points
First, M2M connections can go unchecked. The beauty of M2M
is that it automates the sharing of data that would previously
have needed a human interaction. M2M-enabled smart meters
are a perfect example of this, with the burden of regular—and
potentially inaccurate—meter reading taken away from the customer
and utility company alike. However, this autonomy brings
its own threats. Because M2M-enabled devices can be left to
function without human input, they also can be prime targets
for malicious intent. With no watchful eye on their performance,
threats and security breaches may go unmonitored, or worse,
unnoticed. M2M deployments do not have the valuable input
of traditional communications networks, in which human subscribers
quickly alert the carrier to suspicious activity.
Second, the upgrade mentality for security does not apply
to M2M. Few of the devices connected as part of an M2Menabled
network are likely to be as relatively disposable to their
customers as mobile phones currently are. In industries such as healthcare, where technology costs can stretch into the millions
and even billions of dollars, the prospect of replacing technology
regularly, if at all, is minute. The roles these devices perform
and the business models they work within are expressly long-life,
creating little possibility of upgrade.
Third, the devices are not always mobile. (This fact makes
remote infected devices more difficult to identify and secure.)
When thinking about data transmitted via a mobile carrier,
you can assume that every device sending and receiving is mobile.
But in M2M, there is usually static technology, such as the
smart meters or hospital equipment that can’t be removed from
their location. While it can be relatively easy to replace or treat
compromised mobile phones, with users being able to just walk
into the shop, the remote location and inherent inaccessibility
of some M2M devices means that the cost of investigating and
repairing on a case-by-case basis is likely to be much higher.
Fourth, less sophisticated devices need more protection. The
latest smartphones and tablets come with complex, high-end
operating systems that can be protected and reinforced against
even the most advanced mobile security threats. Unfortunately,
the same cannot be said of all devices that will be connected to
the M2M-enabled Internet of Things. Without hard drives and
with any processing power often devoted solely to performing the
operation it was designed for, the limited nature of many M2M
devices means there is less ability to embed security software.
Finally, the risk, overall, for M2M is more profound—especially
when you consider that M2M can involve utility and healthcare
connections. M2M doesn’t just present a more widespread
threat to deal with, it also presents one that is greater in terms of
both severity and repercussions for networks and their customers
alike. While an attack that affects human subscribers may be
unpleasant for an MNO to deal with, consider the potential consequences
should a similar attack on critical healthcare or utility
grade equipment succeed. No longer is it just personal details at
risk; instead, M2M can present a serious threat to our daily lives.
A security breach that results in medical records being hacked or
important meter readings not reaching a utility is evidently far
more serious than a security issue that stops a homework assignment
being sent to a parent’s mobile phone.
Even though we are in the early days of M2M connections,
there are already examples of M2M weak points being exploited,
either in an actual hack or in a proof of concept attack.
Secure access door hack. In early 2012, the researchers at
AdaptiveMobile conducted its own experiment into one of the
threats discussed in this report. Recreating a secure office environment
and installing a SIM-controlled, commercially available
M2M-enabled door lock, AdaptiveMobile specialists first
tested the locking mechanism using normal test procedures. The
door functioned as planned, with the required code “texted”
from the authorized mobile phone to the M2M lock and allowing
access. The door was then resealed, and a separate test was
conducted. In this test, the specialists were not provided with the
authorized mobile device and instead told to “hack” the door
lock using a laptop.
Accessing the mobile network via the Internet, technicians
were able to replicate the type of message the locking mechanism
was expecting and to bypass the need to send the code
from the authorized device. The locking mechanism, unable
to distinguish between the “fake” message and what it would
consider to be a “real” code, readily unlocked and provided our
technicians with access.
Traffic light SIM swap. In January 2011, traffic lights in Johannesburg,
South Africa, containing phone SIMs for signaling
purposes were broken open, and the SIM cards were stolen.
These SIM cards were then used to make phone calls worth millions
of South African rand while the traffic lights were rendered
inoperable, causing traffic chaos. Naturally, the cost of repairing
the traffic lights was far more expensive than the SIM cards.
GPS location obtaining. Hacked M2M devices don’t only
present an “inward” security threat. They also can be adapted
to push data back to the malicious party as well. The April 2011
reverse engineering of a Zoombak GPS tracking device by security
firm iSec partners revealed that location information could
be obtained by sending an SMS to the SIM card present and
requesting information from the device.
Car hacking. iSEC partners took it upon themselves to breach
an M2M-enabled device, this time in July 2011. Researchers, using
the same techniques proven successful a few months earlier,
analyzed an M2M module in an automobile and revealed what
“commands” it had been programmed to receive over SMS. Doing
so allowed them to replicate the SMS messages using another
device, enabling them to unlock and start the car remotely.
There are actions security providers can take today that can
integrate with their existing network platforms and provide protection
that bridges the gap between legacy “human-to-human”
standards of protection and those required for M2M. A onesize-
fits-all approach will not work with M2M. There needs to
be targeted defenses and controls against specific M2M threats.
Any standard of network protection within M2M should include
the following threat-prevention techniques:
Antivirus controls. Analysis of all messages and IP communications
sent to and from M2M devices should be included to
scan for potential viruses. Viruses present one of the greatest
single threats to M2M and must be vigorously defended against.
Traffic-analysis controls. Intelligent network protection tools
should be able to scan and analyze any and all communications—
rejecting those that don’t explicitly match network format
Identity controls. Making sure that communications are being
issued from an identifiable device helps to reduce the danger of
major security threats making their way onto an M2M network.
Malware identification. In the unlikely event that a threat
does make it past the surrounding network controls, malware
identification can help to quickly identify infected devices and
mitigate the risk of the threat spreading further.
Security policy. Just as policy controls can help to govern a
“human-to-human” network, in the M2M world, they can provide
privacy and protection by defining which devices and device
types can send and receive to each other, when, and by what
bearer. At a network protection level, policies should be enabled
for multiple M2M devices via a single authorization point.
These measures are not a panacea but will help in the secure
growth and use of M2M in the coming months and years. We
are on the edge of an exciting time in which M2M has the potential
to transform the way we live, work, communicate and interact,
and having these communications be secure is essential.
This article originally appeared in the December 2012 issue of Security Today.
Cathal McDaid is a security consultant at AdaptiveMobile.