Industrial control system security
I just mentioned that as a target, an IoBT device is more akin to an Exchange server than to a teeny camera. The problem is, though, that ICS/SCADA elements have traditionally not been designed to be secure – they’ve been designed with functionality, accessibility and usability in mind.
For example, take Wikipedia’s rather concise statement about the DNP3 standard, which is one of the best-known protocol families in SCADA installations: “Although the protocol was designed to be very reliable, it was not designed to be secure from attacks by hackers and other malevolent forces.”
Or, look at Modbus, which is another protocol family, about which Shodan states: “Modbus is a popular protocol for industrial control systems (ICS). It provides easy, raw access to the control system without requiring any authentication”.
Shodan is one of a growing collection of search engines and info sites whose purpose is to find and provide information about internet-connected devices. It’s a fascinating source of data on ICS systems that are out there on the Internet, and at first glance the small number of ICS devices seems reassuring: as I write this it knows of only 252 DNP3 devices on the Internet.
Trouble is, though, that there are loads of other protocols out there, with rather higher and more worrying usage levels: in its Modbus device index, for example, there are more than 16,000 devices sitting listening on the internet, of which a tad under 500 are in the UK. For the Siemens S7 protocol there are about 2,600. BACnet has 9,200. And so on. Now, not all the entries in the database are necessarily still listening (if you pick a few and try to connect to them you’ll find that some still respond and some have been taken offline).
But it’s still a worrying number when you remember that IoBT means fewer, but disproportionately more important, systems than IoLT – not least when you consider that many of the protocols they’re using don’t have decent (or sometimes any) security configured into them.
The similarities between IoTs
We’ve established that there’s a gulf between IoLT and IoBT devices when it comes to why someone attacks them: IoLT kit has low value when it comes to stealing data but is useful as part of a zillion-device botnet for DDoSing other kit; IoBT kit is valuable in its own right.
But there are similarities, and the most important is that they both often lack consideration over security. IoLT stuff is often insecure because it’s designed for the non-technical person to be able to get it up and running in their home: turn it on, run the app on your iPhone, product “connect”, and there you are. No complex passwords, and often no passwords at all. And as I’ve mentioned already, many of the protocols designed for ICS equipment weren’t designed with security in mind, so it’s a lot harder to ensure access is restricted without putting your own layers of security around it.
The level of expertise of those configuring the access to both types of kit is also sometimes similar. While you think of ICS equipment as being managed by much more technical, highly trained engineers there’s often a problem: they’re technical and highly trained in running the plant, and often know little or nothing more than the average home user when it comes to IT or, in particular, IT security.
Back in my consulting days I saw several horror stories around office building plants – usually air-con systems – where the premises team whacked in a DSL or other cheap connection so they could monitor and manage the building systems from afar. Their motivation was understandable – it meant that when a manager decided to work Sunday to catch up on their backlog, the premises guys could flip on the air-con, heating or whatever from home.
Sadly this generally meant logging in with default credentials or no password at all – after all, who cared about hacking the office plant? And remember the comment from earlier: the bigger and more complex the plant, the more financially attractive it is to be able to get engineering access from afar.
The final similarity is, of course, that the internet is the internet and IP networking is the same whatever’s hanging off it. If you go Googling for ICS or SCADA discovery/probe tools, much of what you find will look hauntingly familiar as it’s run-of-the-mill port scanning and general network analysis tools.
Port-scanning an IP address range is the same the world over – it’s only when you find something sitting there accepting connections on a particular TCP or UDP port that you then need to drill in and find a tool that can chant the right incantations to actually try an attack. Up to that point, it’s just an IP port scan like any other Internet attack.
SCADA – a rehearsal for an IoT attack?
In some ways it is. ICS and IoLT are often secured in similar ways by people with similarly low levels of expertise, and that just as there are plenty of IoLT devices out there with unpatched but well-known vulnerabilities, so there are also loads of ICS systems too (there are even security emergency response and advisory sites dedicated entirely to ICS and SCADA systems - CERT being the obvious starting place). Combine this with an understandable reluctance to apply regular updates for fear of expensive downtime, and internet-facing ICS systems present a distinct hazard.
But there is one big difference: SCADA/ICS systems are not a jumping off point for IoT hack apprentices: they’re interesting systems in and of their own right, systems with their own peculiar issues when it comes to vulnerable connection protocols and known vulnerabilities - holes that don’t always get patched promptly for fear of breaking production plant.
Welcome to the playground of Things. ®