Continuous Monitoring

In the previous chapter, we started to understand the core features of MDIoT. Now, let us delve deeper into another of its features: continuous monitoring.

OT network sensors monitor the network traffic continuously across an organization’s assets (for IoT and OT devices). This monitoring is done through the SPAN port or network TAP. This continuous monitoring is important in the field of cybersecurity, as it immediately picks up on any changes in the environment and reports anomalous behavior.

Continuous monitoring helps with the detection of policy violations, protocol violations, industrial malware, anomalies, and operational incidents. It helps in responding to the alerts generated by the system.

In this chapter, we will cover the following topics:

• The protocol violation detection engine
• The policy violation detection engine
• The industrial malware detection engine
• The anomaly detection engine
• The operational engine
...

The protocol violation detection engine

Generally, protocol violations can be identified by field values and packet structures that are being used in ways that go against the ICS protocol specifications.

In Figure 8.1, we can see Modbus Exception as an example of something picked up by the protocol violation engine. A secondary device did not send a response to the primary device when sending the exception code. This violation of the protocol was detected by MDIoT:

Figure 8.1 – Example of a protocol violation

Note

In the MDIoT portal for the Modbus alert, the primary device is referred to as the master device, and the secondary as the slave. However, due to their unsavory connotations dating back to colonization, standardization organizations have spoken against the usage of these terms. We have used primary and secondary in this book, but there are various alternatives available, such as controller-responder and primary-replica. You can read more...

The policy violation detection engine

Any deviation from the learned baseline behavior or configured baseline behavior is detected by MDIoT and alerted on. In Figure 8.3, the Unauthorized Internet Connectivity Detected alert is seen, and from the name itself, we can understand that it is a breach of the baseline behavior, as the source is not authorized to communicate with the internet address:

Figure 8.3 – Example of a policy violation

We will learn more about the structure of the alerts and their components in detail in Chapter 9.

The industrial malware detection engine

Understanding OT/IoT-based industrial malware is a must. The MDIoT detection engine contains this information to aid in better detection and alerting. Malicious activity on the network will be discovered by this engine.

In Figure 8.4, we can see the Suspicion of Malicious Activity pane in the MDIoT Alerts section. From the name itself, we understand that this attack could lead to exploitation by known malware – hence, further action is required from the Security Operations Center (SOC) or the admin team:

Figure 8.4 – The industrial malware detection engine

To gather further information about the malware, we can look into the full details of the Suspicion of Malware Activity alert:

Figure 8.5 – Industrial malware detection engine: Triton malware

We can see that the name of the known malware is Triton malware. The lateral movement attempted by Triton malware is shown in the...

The anomaly detection engine

Simply put, network behavioral anomalies are detected by the anomaly detection engine. In Figure 8.6, we can see an example of the anomaly detection engine at play. The Port Scan Detected pane depicts all the ports that were scanned by an attacker and the alert calls for immediate attention to the criticality of the incident. A port scan is a network anomaly and is detected by MDIoT:

Figure 8.6 – Example of the anomaly detection engine at play

You can find out more about the alert and the anomaly by viewing the full details of the alert, as shown in Figure 8.7:

Figure 8.7 – Deep dive into the anomaly detection engine

You can find the details about the devices involved, including the Media Access Control (MAC) address, protocols, and vendor.

The operational engine

All malfunctioning entities and operational incidents are tracked by the operational engine.

In the example shown in Figure 8.8, we can see that the operating mode has changed, indicating that the PLC is not secure:

Figure 8.8 – Example of an operational violation

This change in the state might constitute a protocol violation as well.

Summary

Here, we got an understanding of the various engines that are part of MDIoT. All these detection engines contribute to the continuous monitoring of any threat vectors aimed at any organization’s OT or IoT network or devices. These five engines provide ways to identify attacks and alert you about any attack coming the organization’s way.

In the next chapter, we will interpret alerts in vulnerability management and threat monitoring.