Industrial IoT Security

One of the biggest challenges in computer security is protecting Industrial Internet of Things (IIoT) devices. While they perform critical functions in industries ranging from manufacturing, medical and energy, they can be some of our most challenging devices to protect. I’m going to write a series of blog posts that explore everything from why IIoT is so vulnerable to some of the best practices for locking them down.


IIoT Definition

IIoT covers a wide range of devices that both collect and process data. These typically include:

  • Sensors – Provides some level of monitoring. This could be temperature, humidity or a range of other metrics.
  • Programmable Logic Control (PLC) – Effectively a computer that processes the data collected by the sensors.
  • Actuator – Not always present, but this can be used to modify the system based on sensor data. For example, an actuator may open a cooling valve when a sensor detects that the temperature has exceeded a predefined threshold.
  • Data storage – Used to store sensor and telemetry data for long term analysis.
  • Analytics – Analytics may leverage machine learning to make cognitive decisions. For example, analytics may tell us that historically a cooling valve can be operated 10,000 times prior to failure, and that its operation will exceed that threshold within the next seven days so the part should be proactively replaced.

Note that the last two bullets (data storage and analytics) are not considered “classic” IIoT. However, they are part of the holistic system and as such contribute to the overall security posture. In fact, it can be argued that these two items are responsible for much of the security issues we have today (more on this in the next section).


IIoT Communications

IIoT devices predominantly leverage two protocols for communications, Modbus and Distributed Network Protocol version 3 (DNP3). Both are antiquated and based on serial-based communications. When they were created, there was no real need to protect the data transfer because serial communications are point to point. When these protocols were later adapted to Ethernet, the focus was on functionality rather than security. This means that neither protocol includes data privacy (data encryption) or packet level authentication. This makes the communications vulnerable to everything from snooping to session hijacking.

Initially, this was not a huge problem as these systems were isolated. Sensors and PLCs would be partitioned from the rest of the network. This means that an attacker would need to gain physical access in order to compromise the integrity of communications. With the introduction of data storage and analytics, the walls began to break down. The networks would be bridged together so that data could be retrieved and analyzed. At a business level, this made sense as performing analytics on the data provides useful insight. From a security perspective however, it meant that anyone with a foothold on the main network could potentially manipulate the IIoT system.


IIoT Vendor Challenges

Back in the 1990’s we went through an evolution with software. We figured out that you cannot simply focus on functionality, but that security needed to be included in the requirements as well. This led to the use of more secure protocols (SSH instead of Telnet, HTTPS instead of HTTP, etc.). It also forced platform vendors to infuse security into their Software Development Life Cycle (SDLC) by checking for security flaws prior to code release, stop using default account credentials, and simplifying the process of applying fixes when security flaws were found in the wild. It’s been a long road, and we are still far from perfect, but software security is magnitudes better than it was when we started down this road.

IIoT vendors are still on the beginning of this journey. Many security flaws are rooted in basic programming errors such as improper bounds checking (what happens when I input more data than the programmer expected) and data scrubbing (what happens when I send data in an unexpected format). Default credentials are still the norm, and get printed in manuals that can be found online.

Here’s a great example. A quick search on Shodan for Modbus compatible devices returns close to 10,000 systems. Most of the results are pretty similar to Figure 1:

Along with the IP address of the system, I get to see that it is responding to queries from the Internet. The banner returned tells me the make and model of the device, which permits me to search for known vulnerabilities. I can also search for a copy of the user manual, which will identify other potential attack vectors (like HTTP, SNMP, FTP, etc.). The manual may also reveal any default credentials used by the system (like user/user). Further, the device is located on Verizon’s wireless network, so it may very well be in a remote location with no onsite staff to monitor it.


Lessons Learned

The deployment of IIoT brings with it quite a few security challenges. To start, IIoT architecture was designed to rely heavily on physical security. With the proliferation of the Internet, and the need to analyze the data produced by sensors, network isolation can no longer be relied on as the sole source of security. Over the next few blog entries I’ll lay out additional steps that can be taken to help secure your IIoT infrastructure.



Interested in threat hunting tools? Check out AC-Hunter

Active Countermeasures is passionate about providing quality, educational content for the Infosec and Threat Hunting community. We appreciate your feedback so we can keep providing the type of content the community wants to see. Please feel free to Email Us with your ideas!

Share this:
AC-Hunter Datasheet
AC-Hunter Personal Demo
What We’re up To