The Answers Are Within Your Data




In the evolution of the OT and IIoT, one of the most commonly overlooked areas within network security is: values in the data. Contextually, what I mean when I use the term: ”data” is, the data seen beyond network meta data (i.e. source address, source port, destination address, destination port, etc.). Specifically, I am focused on the data elements that actually have an impact of the physical realm (values) because when faced with a security incident, the objective is to not allow a hostile/dangerous element of data (i.e. value change) to reach a destination end point (as in a PLC) where there is negative/unwanted physical impact.

The OT/IIoT security space is at a stage eerily parallel to the web application security space in the early 2000’s. Back in those days, the information security (infosec) community was predominantly populated by those with a very heavy network centric background/skillset. And yes, before the “cyber security” experts emerged, there were “infosec” experts that ruled the land. The OT/IIoT space is in a state where the skillsets and focus do not always match certain aspects of the problem and challenges at hand. In the early 2000's when we, the ones who understood that a major aspect to securing web applications existed at the data level (think payload in an HTTP POST), used to speak to the security experts, we would get a lot of blank stares because the experts were just not getting it. Their answer to most problems existed in network-centric solutions, and the use of SSL/TLS (because “using HTTPS over HTTP makes your web application secure” - yes that is a sarcastic dig to what I used to hear all the time back in those days). We were pushing security awareness past the point of understanding because security personnel were not thinking in terms of the data, and the values within the data.

The reasons for the disjointedness in understanding were understandable. How does one explain code/data level issues in a web application to people who live in a space of subnet masks? It’s a different mindset. For example, we show SQLi attacks to people who probably had never written a SQL query in their entire careers. In the OT/IIoT space we currently see parallels to the early days of web application security. For instance, network segmentation is pushed a lot, and while there is certainly some value to network segmentation, it is no silver bullet. And, if bypassed, offers very little in the face of real protection.

One of the main focal areas is, and has been for the last five-six years, network level visibility (i.e. asset discovery: what source is talking to what destination, etc.). This kind of visibility only gives you a partial view of the overall attack surfaces at hand. This data is certainly important, but only provides a basic understanding that offers very little by way of actual protection. Sophisticated attacks, such as Stuxnet, have clearly shown that somewhere in the chain of an attack there will actually be a value level trigger/event that forces a change downstream, and which will have a physical impact. This will most likely take place with an action that forces an unwanted change at a data/value level. Think of set point data, such as coil/register values in the Modbus/TCP space, as an example. But ultimately we are talking about an event where “knowing what is on your network”, offers little real security value other than some insight and understanding

Let’s use Modbus/TCP to point out some details relevant to my musings. We are talking about operations that take place at Layer 7 in the OSI Model. A “Master” is the client when it comes to network communications, and the server is a “Slave”. Let’s focus on where the relevant data/value elements exist when Modbus/TCP transactions take place: These exist inside of the Protocol Data Unit (PDU), which in turn exists inside of the Application Data Unit (ADU). The PDU is further broken down into a 1 byte Function Code (an integer), and a variable byte length “Data” section.
Figure 1.



To give this entire concept some real world relevance let’s look at some concrete examples which detail some of the registers that are interesting, via Modbus/TCP, for a Variable Frequency Drive (VFD) that interacts with a motor. The values that are set in certain registers are used to alter the physical behavior of the motor, and if set past normal operating constraints can create physical damage. Some concrete subjective (i.e. they are for a specific make and model of VFD) examples:

  • The Acceleration Ramp Time (register 9001) is used to control how quickly the VFD will accelerate a motor. The nominal value is 100. Writing a value of 1 to this register will cause the drive to accelerate as fast as possible, which is usually an unacceptable rate. On a large motor this can be physically destructive to it, as well as any devices connected to it. Figure 2 shows you an example of this data when captured in a pcap.
  • The Deceleration Ramp Time (register 9002) is used to control how quickly the VFD will decelerate a motor. The nominal value is 100. Writing a value of 1 to this register will cause the drive to decelerate as fast as possible, which again is usually a rate that can be physically destructive.
  • The Low Speed Register (register 3105) is the lowest speed that the motor is allowed to run at. The High Speed Register (register 3106) is the highest speed that the motor is allowed to run at. Writing a value of 1000 to both of these registers forces the drive to run at 100%, which creates a condition where there is potential negative impact.

 Figure 2.



A hostile act can also include a change to the cooling fan mode (register 3130) to a value of 2, which turns the fan off. That will severely elevate the temperature of the VFD, and in turn, shorten the life of the motor windings. Beyond this, there are other registers that can cause conditions of overheating and/or physical denial of service.

For the sake of variety, and in the spirit of the importance of data values, take a look at Figure 3, which represents a proprietary IIoT protocol example.

Figure 3.


This data is typically seen going across the wire in raw binary form. To an analyst who doesn’t understand this type of binary data, represented in hex, the difference between ’19’ and ‘6e’ may seem trivial. But, when converted to decimal values (shown above in green and red) the numbers may not seem so trivial. There could be a huge difference when telling a downstream device to set a value to 25, as opposed to 110. Think about this in terms of the spinning speed of some physical device. The implications at that point start to seem non-trivial.

These examples showcase the importance of domain expertise (i.e. knowing how this equipment works, and more importantly knowing the safe range of operational values for specific gear). Moreover, the examples showcase the relevance of data in the spectrum of security protection in the IIoT/OT space. So, the question here becomes: is knowing, that these value set conditions can create high risk situations, enough? If you are aware of this level of risk, and yet, some malicious Modbus value set traffic makes it to your VFD - the negative impact is significant.

We have to accept the fact that IIoT/OT Security is not a sexy or hip thing. There is no cool app that young generations will fall in love with. This may be a hard pill for some to swallow. There are grey screens with primary colors on them. There are hot and dusty environments where PC’s reside. There are those humble, honorable, non-glamorous PLC’s that endlessly churn away at their simple instruction sets, and keep many aspects of our modern day lives in order. They need to be understood in order to be protected. More importantly, the network communications, that contain the key elements of data (i.e. set points, etc.) that touch those PLC’s need to be understood in order for protection to actually exist.

We need to understand, so that we can protect. We need to do our jobs, and be proactive in terms of gaining this deeper data level understanding, so that we can build proper protective mechanisms. Moreover, we need to be proactive in putting proper protective mechanisms in place, such that disasters can be avoided.

Modern day CISO’s must either accept the risk of non-active security solutions, or diligently put accurate and actively blocking solutions in place that are subjectively data aware. Otherwise there will always be this risk gap within their domains. One key answer to that risk is in the data: native and subjective data in a payload of some ICS protocol, not simply in some network related meta-data. Our industry has grossly overlooked the values in the data, and the risk gap it has created for OT security. The answers are within your data, now go protect it with Active OT protection.

 Figure  Source:

- Andres Andreu, CTO