The Internet of Things is a bad term

…Perhaps, Internet of Consequences is a better descriptor.

First off, the first main issue is the word ‘Things’, it is too general. Things break down into different categories:

Operating Environment:

Older Windows systems that run information systems (e.g. Passenger Information)
Older Windows systems that run applications that drive hardware (CNC systems etc)
Older Windows systems that are gateways to other types of networks
Embedded Linux systems that run a full Linux distro (that drive hardware etc)
Embedded Linux systems with a custom (cut down distro)
Real Time embedded operating systems with a network connection
Modified phone operating systems used as gateways for remote access
Very small systems with homogenous code for a specific function

Actual Function:

This is almost infinite, and that’s why IoT discussions go astray very fast. Each person has a different context:

Printers, Cameras, TVs, Whitegoods etc.
Internet enabled things (locks, thermostats etc.)
Industrial process and control
Medical, syringe pumps, radiography etc.
Transport, automotive, rail, aviation
CNI – Traffic Lights, Power, Water etc.

Consequence of failure:

Reduced Data – had to go elsewhere to find the weather, train times, or next stop
Poorer automation decisions (temperature sensor not found default value used)
Human irritated (light didn’t switch on, had to get up and use a switch)
Human really annoyed (heating didn’t come on, cold shower not appreciated)
Denial of Service (Car won’t start)
Physical items get stolen – doors and gates opened
Safety impaired – brakes not automatic, door on trains open in wrong places
Safety removed – brakes do not work, car throttle open
Injury – self driving car crashes
Fatalities – auto pilot forced into wrong decision, syringe pump delivers too much drug

So as we can see this is a multi-dimensional conversation. If one party is thinking about Alexa not controlling their TV and the other is thinking of train collisions we end up in the ‘storm in a teacup’ v ‘armageddon’. Without a common frame of reference we have not got a sensible conversation.

Many industries are not thinking through the consequences. So many times we see devices ‘Internet enabled’ so that remote diagnosis can reduce the cost of maintenance. Two examples:

Printers – People in vans with parts are expensive. No-one wants to spent more on printing than is absolutely necessary. Printing is not our core business – no one gets trained or can be bothered to change a cartridge. Therefore printers ‘phone home’. The person with the van now gets a route optimised list of which printers need what when, spares are delivered to them in a just-in-time model.The printers all have the same password, all the engineers know the password, so do the ex-engineers, a few customers and an obscure reference on the Internet. The printers are based on embedded linux with SSH enabled. The printers only phone home, as far as the manufacturer is concerned only authorised people can see data that is not that valuable in the first place.
Traffic Lights – People in vans with parts are expensive. Traffic lights are everywhere, they need to have very good uptime. People need to know what the fault is before they travel to a traffic light location. Traffic lights should report faults immediately. What could possibly go wrong if we connect them to the Internet? Surely this doesn’t actually happen!

Lateral movement of attackers

To return to the printers, the reason I mentioned SSH is the possibility of bounce off attacks. This means that the ‘Thing’ is not attacked, but used as a conduit to direct traffic to other systems on the same network.

ssh eng@cust-01printer.maintenance.com -L 2222:othersystem:22

That will map port 2222 on the attackers system to port 22 on othersystem. ‘othersystem’ may well be protected by firewalls, which the ‘Thing’ has perfectly bypassed.

If a ‘thing’ phones home – do not trust it

The SSH example is a very simple case. There are more complex versions that would used the tools laying around on the ‘thing’ – anyone for nmap? Printers are just an example of remotely serviced devices – remember the Target attack was through the air conditioning supplier. This shows that it’s not just the device, but the chain that counts. At the security level you need to be able to answer the questions:

What is this device, what does it do?
What is this device based on, does it have tools and a development environment laying about?

A ‘thing’ might be based on a Raspberry Pi, a perfectly reasonable and reliable platform. But if the vendors have left tools from the development environment in place, an attacker can install and compile their own code to run alongside the legitimate functions of the ‘thing’.

This is a case where VLANs and SDN are your friend. If you know it needs to phone home for maintenance – put it on a VLAN with a software defined firewall/network rule that let’s it phone home, but not make other outbound connections. This will work for printers, where all normal connections are made to the printer and one connection – the phone home is made from the printer. Put all your printers on that VLAN so that you do work once and benefit many times.

It’s the account credentials

Much is made of the vulnerabilities in IoT, but the absolutely obvious is password management — there is no need to operate complex attacks based on protocol weaknesses when a simple password will open the door. This a people problem – many people need access to many things, and changing the passwords on the things is really inconvenient to people.

Architects tend to design systems where all critical plant in on it’s own network. The failures come where it is assumed that a firewall is good enough. This is just not the case, firewall rules are source and destination based. If the attacker/meddler is coming from an allowed source and bouncing off destination systems – the firewall is useless. This needs to be prevented by a proxy based technology that accepts an identity and connects to the IoT devices with a defined role. If that proxy also checks with the change ticket so much the better. You’re basically creating a digital equivalent of the physical safety locks.

At Osirium, we have of course fixed the entire problem once and for good. The trouble is, the managers that make decisions about what to connect to the Internet often under rate the risk, or even bother to consider the risk, or fail to understand what their CISO is telling them. This is where the industry joke comes from: “The ‘S’ in ‘IoT’ stands for Security”

At this point we could tell you how to fix all the problems in all the places. Suffice it to say that we separate people from those passwords, cycle the passwords so that they are high entropy and regularly changed, and that we control the tools that people can use to access the things so that they can’t move laterally on networks or bounce naughtiness off the things they can see.

If you think we can help you, please get in touch.

‍

IoT, Internet of Things is not a good term…