First off, the first main issue is the word ‘Things’, it is too general. Things break down into different categories:
This is almost infinite, and that’s why IoT discussions go astray very fast. Each person has a different context:
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:
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 firstname.lastname@example.org -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.
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:
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.
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.