Secure & Configurable
Connectivity
Take the IoT security challenge –
am I vulnerable?
Take the IoT security challenge - am I vulnerable?
Table of Contents
1
Overview ................................................................................................................................. 1
Accountability .................................................................................................................. 1
The price of poorly implemented IoT security................................................................. 2
IoT traffic, a two-way street ............................................................................................. 3
2
The challenge – attack your own IoT deployment! ................................................................. 4
Validate your things and server’s presence on the internet .............................................. 4
Analysing IoT device visibility ........................................................................................ 6
3
Enabling basic IoT security ..................................................................................................... 8
Make the hacker work for their lunch .............................................................................. 8
4
Implementing robust IoT security ........................................................................................... 9
Introduction to Asavie IoT Connect ................................................................................. 9
Password Protection – put a lock on the door ................................................................ 10
5
4.2.1
Put your things behind a vault door .................................................................................. 10
4.2.2
Cloud/on-premise security ................................................................................................ 11
Security for the lifetime of an IoT deployment ..................................................................... 12
Managed secure SDN platforms .................................................................................... 12
Securing for the unknown .............................................................................................. 12
5.2.1
Scale hurts – take IoT to a private network ....................................................................... 13
Protect against what you know....................................................................................... 13
5.3.1
6
Protect your cellular IoT deployment from overages ........................................................ 13
Conclusion ............................................................................................................................. 14
2
1 Overview
The aim of this technical solution note is to challenge everyone, from makers to enterprises who
are embarking on a path of digital transformation to take an in-depth look at their security. In the
solution note, we will look to uncover the potential security threat exposure associated with
deploying IoT projects unprotected on to the public internet. A secondary objective is to suggest
some quick fixes to assist you in becoming less vulnerable to hacking exploits.
There are many well documented news stories; too many to want to highlight, which emphasize
that the security threatscape has landed and expanded into IoT, seeking out all sorts of
vulnerabilities to exploit.
Accountability
IoT and security is not an easy task, in some instances best practises and advice originate from
different sources. For example, in the enterprise guidance can originate from those who are not
security and/or networking experts. However, as the owner of an IoT project, are you the person
who will be held accountable, if something goes wrong?
How well do you know your IoT hardware, operating systems and running application software?
Are you confident that you can keep your IoT deployment safe? Especially against the next yet
unknown attack vector? How risk-adverse are you, would you gamble with your livelihood - by
telling your management and/or customers that the IoT devices are - on the public internet and
are 100% safe?
It’s clear for many that the answer is a resounding no, but what’s the alternative?
A core focus of this application note, is to highlight the problem of using the public internet for
IoT backhaul and to offer an alternative.
If you are reading this and you have deployed your project over cellular IoT, please do read on as
the question or challenge for you now becomes two parts; where is the mobile network operator
(MNO) / mobile virtual network operator (MVNO) landing your data? Which then raises the
secondary question - do you have the granular control of the IP network to manage your security
posture effectively?
“Through 2018, over 50% of IoT device manufacturers will not be able to
address threats from weak authentication practices.”
source Gartner
1
The price of poorly implemented IoT security
For many the idea of going to a MNO or a MVNO and buying a data plan is easy, but without
the proper IP networking and policy controls this can quickly become a costly problem. Let us
try and put this into context.
Imagine the unfortunate event of an attacker taking control of your device, the price of the
exploit can mean more than egg on your face but a nasty bill from your MNO/MVNO for data
overages.
For example, in the following table, we show a summary of just how costly a security failure is,
but worse still - this is just for a single connected mobile enabled IoT end-point:
Vendor
Potential Exploit
Cost ($)
EU carrier (M2M tariff)
SD video stream
3,500
Global carrier (100MB tariff)
HD video stream
7,000
Instant Message call
475
IoT MVNO
Table 1 The price of poor IoT security
To paraphrase a leading enterprise’s tagline - Knowing that your IoT subscriber identity modules
(SIM) can only talk to your application; Priceless.
Another interesting observation, is that the potential lifetime of the IoT deployment is not weeks
or months but years. Correct device management is a step in the right direction - as in to keeping
the device safe, but is it enough?
Let us not forget that the hacking community is not sitting still, new threats are always in
development and emerging. At a human level - is it right to be constantly worrying about our IoT
deployments and working in a reactive mode as each new threat appears?
A core part of this solution note is to offer an alternative solution, one in which takes the IoT
deployment off the public internet and away from harm.
2
IoT traffic, a two-way street
The basic concept of IoT is the sensing of data and the transmission of the data to an end-point
for analytic/storage purposes. Sadly, from a security standpoint that implies that there is at
minimum two end-points in which a hacker can target.
If your data is traversing the public internet, you should not only concentrate on the potential
exposure of the IoT sensors/gateways but also the host machine aggregating and analysing your
data or the application server.
Another interesting take-away is that the security threatscape is multi-dimensional and can have
multiple layers to it. For example, the table below is a basic overview of the common software
stack layers in which potential vulnerabilities have been exposed by our nemesis “The Hacker”.
Attack Surface
IoT sensor
IoT gateway
IoT application server
Hardware
Yes
Yes
Yes
BIOS Settings
Yes
Yes
Yes
Operating System
Yes
Yes
Yes
Network Service
Yes
Yes
Yes
Application Service
Yes
Yes
Yes
Table 2 Sample of proven attack surfaces for a typical IT deployment
In the table above, we have not even considered the multitude of operating systems that can be
used. Unfortunately for many, to truly assess IoT exposure will dictate multiple iterations of
unique test methodologies to ensure at minimum there is no backdoor vulnerabilities open.
Test and measurement is resource and cost expensive - maintaining and supporting that for the
lifetime of the IoT project can end up being to the tune of hundreds of thousands of dollars. Is
this money well spent over the multiple years of the IoT deployment? It’s a reasonable question
to ask at this stage, but we will discuss later the idea of the unknown attack vector, which puts us
always on the back foot.
A significant part of the solution note, is the IoT security challenge or a way to identify a base
level of exposure. We will suggest some quick fixes, but more importantly offer an alternative
solution which will truly secure your IoT deployment and put your mind at ease.
At most we hope from reading this solution note that you learn something new and perhaps that
you profit by saving yourself a bundle of cash!
3
2 The challenge – attack your own IoT deployment!
Yes, you have read the title correctly, in this section we will look at a few sample test
methodologies to benchmark the level of exposure that your IoT project has. So, let’s begin by
offering some guidance on some of the tools we have seen our customers use over the last few
months.
Our disclaimer is as follows - this is not an exhaustive test list and is intended for informational
purposes only. Asavie accepts no responsibility if you break something, but we are delighted to
acknowledge that we helped you to find any potential vulnerability before the hackers do!
Validate your things and server’s presence on the internet
The key test is to assess the level of visibility of the IoT deployment to the real world. It’s
advisable to run the test against both the things and the server aggregating your data.
To do this, there is an open-source tool for network exploration and security audit is called
NMAP - https://nmap.org/, which is freely available to use, check out their site for more details.
Step 1: Assess the exposure of the connected thing –
a)
b)
c)
d)
e)
Point the machine running NMAP at the IoT device.
In the NMAP target window enter the IP address of the Thing to scan.
Assign a scan profile, in the figure below the scan is set to “Intense scan, all TCP ports”
Grab yourself a coffee!
Save the results
“The great complexity of the infrastructure makes web application servers a
target for attackers.”
source Verizon 2016 Data Breach Investigations Report
4
Figure 1 Intense port scan on the connected things using Wi-Fi
Step 2: Assess the server side for exposure
a) Now point the machine running NMAP at the application server.
b) In the target window enter the IP address of the server to scan.
c) Assign a scan profile, again we use the “Intense scan, all TCP ports”
d) Grab some more coffee!
e) Save the results
Figure 2 Server side scan, as per seen from a public Wi-Fi network
5
Analysing IoT device visibility
Hopefully you have had no surprises and everything is as how you expected, but is worth taking
some to review the scan results.
Firstly, it is worth taking a moment to reflect on how easy it was to run a port scanning tool,
which then makes you wonder who else is doing exactly what you have just done? This is a core
problem of why the public internet is not the place for IoT!
Beginning with the server side the test exposed that there is a remote desktop port open and
listening. Again, without any knowledge the initials highlighted in the service name are “ms”,
perhaps gives a clue as to what OS is in use.
For the hacker, the next steps are easy attack the port with a brute force password attack or seek
out a remote desktop exploit!
Figure 3 Server side open and listening ports
Now, let’s look at the Thing side of our network. This is perhaps the most interesting finding. In
the figure below we can see that there are 3 x open ports. Without any hesitation, the curious
among us would attempt to open a secure session shell (SSH) to the device.
With no hesitation at all, a hacker will turn up an automated script to cycle through the usual
username and password suspects - root:root, admin:admin, admin:password, etc.
In one word – Mirai!
Here lies the problem for IoT, devices are being placed into public networks, with no security
posture and are being exploited at ease, as the original manufacturer user credentials were never
changed!
6
Figure 4 Open ports on the IoT device, note port 22!
As per the opening quote from Gartner, their research suggests this problem is not going to go
away anytime soon!
OK, so what next? What can we do, how can we prove to the leading industry analysts that they
got it wrong?
7
3 Enabling basic IoT security
If you have not done so by now, please ensure that the username and passwords are not those
that were assigned from the manufacturer!
Make the hacker work for their lunch
In the event, that there are open ports, close them quickly! In theory, the only ports open should
be the ports that are sending data to the application server. For example, IoT deployments using
MQTT – the only ports open should be 1883 or 8883.
However as just demonstrated – it is way too easy to find open ports, so a security best practice
is to change your services to run on non-standard ports e.g. MQTT - 1883 could become 51792.
The obfuscation of the port makes it more difficult to identify. Why make it easy to be a target!
A further best practice is to ensure that all unwanted ports are disabled before deploying to the
field. i.e. should an IoT device have a port 80 open?
The following are simple steps that can be used to disable any unwanted open ports Windows OS:
1. Log into the machine and open a command line
2. List the listening ports by typing: netstat -ano
3. Identify the service name associated to the port: tasklist /SVC /FI “PID eq xxx”
4. To stop unwanted services, simply type: net stop <service_name>
5. Make sure the service does not restart on boot: sc config "<service_name>"
start=disabled
Linux OS (Debian):
Note: similar syntaxes exist for other initscript standards used in distributions that are not based
on Debian, therefore, it is advised that you consult your distribution’s documentation first.
1. Log into and open a terminal session (some commands will need root access)
2. Identify the service associated to the port number: netstat -tulpn | grep ":xxx"
3. Stop the running daemon: service <service_name> stop or /etc/init.d /<service_name>
stop.
4. If that fails try: pkill - INT <service_name>
5. Make sure the service cannot start on boot up by removing the service script from the
/etc/init.d directory: rm /etc/rc3.d/<service_name>
Later in the solution note, we will assess how feasible it is to close all ports, especially if routine
maintenance is required.
8
4 Implementing robust IoT security
With some basic security now in place, our aim is to look at how security can be implemented
well, in doing so we will also introduce Asavie IoT Connect. However, as highlighted in the
introduction – we want to save you money!
If at this time, you are not interested in spending a nominal amount for a managed service for
secure IoT deployments, hopefully the basic principles highlighted in this section will serve you
to implementing a more secure IoT project.
Introduction to Asavie IoT Connect
As already indicated in the “Overview” and something that is widely acknowledged in the
telecoms industry is that many people responsible for IoT deployments are not experts in
networking and security.
In many cases, it ends up being information from disparate sources. As the adage goes – “too
many chefs, spoil the broth” and for IoT the outcome tends to be poorly secured deployments.
At Asavie we believe connectivity should be simple, we recognised that there is a need to
abstract network and security complexity and in doing so created Asavie IoT Connect. Asavie
IoT Connect is a self-service web application, which enables users who have basic network and
security knowledge to provision robust, secure, and private IP networks end-to-end, which can
also be provisioned over cellular communications.
This is a subtle and often underestimated feature i.e. the ability to quickly provision, activate and
manage both network and security from a single interface with minimal experience.
Once the user declares the network topology and security posture the instruction is pushed down
to a software defined network (SDN) platform, known as PassBridge. This is the bit that takes
our customers off the public internet and away from cyberattacks.
9
Secure end-to-end IoT connectivity
Figure 5 Asavie IoT Connect user workflow
Password Protection – put a lock on the door
Many of the recent IoT botnet attacks, have at the heart of them poorly implemented password
schemes. From the earlier scan tests, you can see how easy it is to find the right door to push.
Let’s take a moment to reflect on the Mirai attack - imagine deploying a Linux based sensor
gateway which has the standard port 22 open and the username and password defaulted as
root/root. This would be akin to locking your smartphone with “0000”. Not the greatest security,
so why do this in IoT?
4.2.1
Put your things behind a vault door
The problem could relate to the sheer volume of devices being connected i.e. no easy way to
update all devices before deployment. In this case Asavie IoT Connect is the ideal solution as
users can deploy one to many devices.
The idea is simple, connect the devices over a private access point network (APN), for the user it
provides the first layer of security – it forces the use of strong authentication of the devices on
the network before enabling access to the network.
10
On the Asavie platform each device attempting to connect to the network are challenged as
follows Challenge 1: Is your name on the list?
Asavie uses the carrier’s subscriber identity module (SIM), to request from the carrier the right to allow the
device on the network. The carrier acts as a trust authority. The carrier’s subscriber database is core to its
business, which is probably the most protected system on the cellular network. For us this is akin to the
bank vault door.
Challenge 2: Have you ID?
An additional part of the authorization process is a challenge for username and password, using the
Password Authentication Protocol (PAP).
An advantage of Asavie IoT Connect is that the initial security posture is in place for the lifetime
of the IoT deployment, which will scale from the first connected device. An additional
observation is that there is no need for expensive security applications or physical infrastructure
to manage identity throughout the IoT deployment lifetime.
Over the lifetime of the IoT deployment it is expected that hardware will be retired and replaced,
with Asavie IoT Connect you have flexibility to migrate the connectivity to the new device, but
retain the original security posture at no additional cost.
4.2.2 Cloud/on-premise security
Asavie IoT Connect is essentially a connectivity as a service, which means there is no
unnecessary spend on physical network infrastructure, which holds true for the cloud/on-premise
side or IoT application server.
Asavie protects the application servers via a proprietary software client. The installation process
ensures that only a designated server can attach to the private network. On installation Asavie
issues unique credentials to associate the server to the private network.
The Asavie client connects over the port 443 (aka https) to the managed service platform,
however the port 443 is not in listening mode! Therefore, if you repeat the scan test your port
will not respond, which means the attack software will simply move on.
Unfortunately, this is one security zone you cannot ignore i.e. protecting your application data
and we strongly recommend that you spend the money.
If you don’t wish to use Asavie’s connectivity as a service, the alternative is to purchase a next
generation security system and support package. Remember IoT longevity is years, so make sure
to ask for a discount!
11
5 Security for the lifetime of an IoT deployment
Managed secure SDN platforms
At the core of the Asavie IoT Connect architecture, is a proprietary platform developed and
managed by Asavie, called PassBridge. The PassBridge infrastructure is used to provision and
manage elastic IP networks. PassBridge is agnostic to the access network type, meaning users
can federate data from a range of network types e.g. Zigbee, Low power wide area networks
(LPWAN) – LoRa, Mobile - 3G/4G/5G NB-IoT and/or satellite.
PassBridge is designed for high global availability and is distributed across several unique global
datacentres. Using PassBridge’s north-bound application interface (API) aka Asavie IoT
Connect, users have the capability to define IP networks and manage security at the network
layer.
Network layer security manages every data flow in the private network. Based on a user defined
policies unwanted data flows are filtered and dropped. This essentially means that in the event of
a malware compromised device being added to the network, it can never call home.
Securing for the unknown
Hackers are using malware/distributed denial of services to try to compromise our networks and
services. The minute we attach something to the public internet it becomes an instant target for
attack.
The most worrying attack type for an IoT service is Distributed Denial of Service (DDoS), these
attack types can be of any size/ferocity, can happen at any time and last for an undetermined
amount of time. It is the sheer unpredictability of these attacks, that is most concerning.
Ultimately DDoS attacks can cripple a service, potentially knocking it out for days! Clearly this
is not an ideal situation to be in. A key defence mechanism is to become invisible to the attacker
and their ways. Which is the core value proposition of Asavie’s managed platform PassBridge all IoT things and servers are off the public internet.
Ultimately, if you do choose to use public internet networks ensure to –
• Close all listening ports (not as straight forward as it sounds, how do you run updates?)
• Disable all ICMP (Internet Control Message Protocol) responses, essentially eliminating
the threat of the most common DDoS attack the PING of Death.
• Close or alter the common login ports of SSH and Telnet.
12
5.2.1 Scale hurts – take IoT to a private network
However, all the practices listed above are at best designed to be implemented on the assumption
that an individual end-point is being deployed. IoT is by definition - the deployment of large
quantities of connected things.
So how do owners of the IoT deployment a) ensure that the basic security posture is
implemented and that b) every device deployed thereafter adheres to the same security posture?
You can from the outset implement a rigid process of pre-deployment testing, which has an
associated cost OR you could from the beginning look to implement a private IP network. One in
which you have complete control over!
Asavie IoT Connect only allows authenticated devices on the network, from the get-go only your
authenticated things data flows can traverse the network. If an intruder did get into the network
the attack traffic is automatically dropped.
Protect against what you know
Clearly there will be the need to open the IoT network to periodic maintenance traffic flows,
managing these known flows are equally as important. The idea of allowing things and/or servers
to automatically run auto-updates is a potential attack target.
What can we do? Regular and scheduled maintenance is key, but how do you update potentially
thousands of devices in a safe manner? Do you remember or know what was deployed e.g. an
inventory list, which could easily be several years old?
If you are lucky to have architected your IoT deployment on a private IP network using Asavie
IoT Connect, the process is straight forward:
1. Upload the approved software update to a centralized node on the private IP network
2. Dynamically alter the security posture of the network per device or device groups
3. Run the update for individual devices or device groups
4. Assess that all updates are completed, revert to the original security posture
5.3.1 Protect your cellular IoT deployment from overages
If your deployment is through a basic IoT cellular package from a MNO/MVNO, you will not
experience the same level of control. The problem is that the devices are most likely connecting
through the public internet and are most likely running updates in a semi-controlled fashion.
Aside from the security exposure, there is a cost that is going unmanaged!
With thousands of devices all running updates, some of which may be non-essential software
packages - you will quickly notice how the costs rack up! The MNO/MVNO job is not to restrict
your data, in the end that is what they get paid for!
If you have no control of the IP network for your IoT deployment, it’s clear that the cost in terms
of security and dollars quickly adds up!
13
6 Conclusion
The aim of the solution note is to make everyone aware of how vulnerable IoT deployments are,
if they remain connected directly/indirectly to the public internet.
It is important to recall the potential damage and costs associated to a compromised IoT
deployment. An observation in relation to the Table 1 The price of poor IoT security, is that it
only highlights the cost associated with a single exploited cellular IoT device i.e. potential for
thousands of dollars of cost per month, imagine the cost - if tens or even hundreds of similar
devices are exposed!
In an effort, to show how easy it is to exploit IoT devices with weak security credentials, the
simple exercise of using open-source software demonstrated that there is a lot more device
details given away than most would like to believe and that this makes it extremely easy for the
hacker to determine the correct exploit to open the door. Unfortunately for all of us this software
is freely available to everyone including the hacking community!
A fundamental problem will persist for many months to come and that is - that the manufacturer
credentials for many devices are freely available and go unchanged when users deploy them live
on to the internet. Ultimately, making IoT devices the likely targets for recruitment into global
botnet armies, as was seen in the recent IoT attacks.
Essentially, there is no hiding on the public internet and even with basic security best practices
implemented, there is no guarantee of staying safe forever. Ultimately, if you have no control
over the IP network layer in IoT deployments, the IoT deployment will remain vulnerable and
that IoT devices will continue to have the capability to communicate at will, to anywhere on the
internet.
The ability to implement private and secure IP networks as per Asavie IoT Connect, delivers
significant security advantages, but more importantly a managed service helps to significantly
reduce the total cost of ownership of protection over the lifetime of the IOT deployments – by
reducing the need for expensive next generation firewalls, test equipment, software, and
maintenance contracts, etc.
IoT deployments will be in active service for tens of years, Asavie with a long history in
delivering innovative networking solutions, will be here to ensure that connectivity remains
simple and secure for the future of your IoT deployments.
14
TO LEARN MORE, VISIT:
https://www.asavie.com/products/asavie-iot-connect/
Asavie is the leading provider of next-generation enterprise mobility management and Internet of Things (IoT) connectivity
solutions. At Asavie we remove the guesswork from the connectivity conundrum. Asavie allows you to focus on building
your business without the hassle or worry of having to create and manage reliable, resilient and robust networks. Revision (1.0)