Following Part I and Part II, we will give another example why OT monitoring is necessary to have a look about what is happing in industrial environment. The last one finished if somebody connected their laptop to the network and then to a PLC. Today, we will see what happens if somebody, that is, a third party, contractor, support team, etc. carries out a task that requires that the PLC CPU goes to STOP and the process, as well.

Having said this, imagine a manufacturing plant in operation and during an intervention, an engineer puts online and accidentally sends a STOP command by STEP7 software or something similar that requires it. Obviously other scenario can be a targeted attack on an exposed controller in the network.

If this occurs a message will appear in “Alerts” tab with score of “10” in the risk column. In the picture below we can see the steps since the PC (IP: 10.10.201. 103)  establishes connection with the CPU (IP, 10.10.201.102) by COTP protocol and sends STOP and START requests.

If we open both alerts, we will find more information of the source, its MAC and IP address, port, protocol, direction and so on.

For troubleshooting purposes, we can download a trace of the packets to find more low-level information. After that we are able to open it with a network protocol analyzer.

This example has been done once Guardian is in Protecting mode. Before this, we have to configure the tool in a “Listening” mode to learn about the asset, protocol, communication, behavior, etc. to take a picture of the network and everything it contains.

If this event occurs during this time, the alert can be different. In this case the alert will be scored with 9 and 6 values, respectively. In the first example we have to remember that the device from which we send STOP command, has not been discovered during “Listening” phase so the tool will categorize the action with a higher value.

Until now, we talked about a concise command. But if the CPU is not protected as I wrote in previous posts.

So, we can go one step ahead and think that if we can reach the PLC to STOP and START the CPU we could access and download it’s program. If it can be done, we could modify it and then upload it again to cause error condition, alter variables, configure passwords in order to do not permit legitimate access, and so on. If this occurs, we could identify it as shown in the  following picture.

Today we have analyzed different actions that can be identified by Nozomi Guardian monitoring tool, it can help us to detect actions that could alter normal operations. After this, we could start to investigate how a machine tool, production line or other facility stops without any reason.

However, it is important to remark that before deploying any security monitoring tool, an organization should have carried out other technical actions. One of them is to separate and segregate IT and OT environments. To do so, it is necessary to identify, analyze and decide which traffic must be permitted to pass across our firewalls. Once it has be done, we will have the criteria to say if what is happening is a normal or abnormal behavior. In other words, if we do not identify and understand which workstations  can access  industrial equipment and implement a strict change management process, we will not have the capacity to discover the root cause of the alert. Does somebody act on a PLC? Is it an attack? Has the communication module  failed?

These tools are useful solution if we implement it on stable, well-know and secure OT network.

Thanks for reading the post! See you!!