OT Detection: identifying threats and anomalies on the industrial network
Mapping and isolating are essential steps, but they are still not enough on their own. Once the initial mapping has been completed and critical assets protected, two questions remain open: how does the network evolve over time? And how do you detect attacks, particularly in non-isolated zones? New devices, unusual flows, anomalous behavior, newly exploitable vulnerabilities: without continuous monitoring, these signals stay invisible. That is what this article addresses, the last in our series on putting OT security into practice: how to detect deviations and threats on an industrial network, and how Seclab Xplore rises to that challenge.
Key takeaways
- Alert contextualization is the key to operational effectiveness: an IP address without business context means nothing to a SOC analyst who does not know the plant.
- Industrial environments have a characteristic that is genuinely valuable for detection: their drive for stability. Any deviation from normal behavior becomes a warning signal.
- Alerts must be routable to the right people depending on their nature: IT teams, SOC, OT teams, production managers, external maintainers.
- Continuous PCAP recording provides an immediately available evidence base for incident response and threat verification.
A reminder: the five-step OT security methodology
Faced with the rising threat to OT environments, regulations and field experience converge on the same sequence:
- inventory assets and network flows,
- reduce the attack surface by removing what is unnecessary,
- identify critical systems and physically isolate them,
- put the infrastructure under continuous monitoring,
- secure backups with physical isolation.
The previous articles in this series covered mapping with Seclab Xplore and physical isolation with Seclab Xchange, Seclab Xport and Seclab Xlocker. This article addresses the fourth step: monitoring and detection.
Why OT detection is a discipline of its own
Detecting a threat on an IT network is already complex. On an OT network, it is a different exercise entirely. Industrial protocols are specific, often proprietary, sometimes real-time. And the teams receiving the alerts are not always cybersecurity specialists: they are operators, process technicians, production managers.
The first challenge is monitoring without disrupting. In industrial environments, any active probe can interfere with sensitive real-time protocols or destabilize machines that do not tolerate unexpected traffic well. Detection must be as passive as possible, able to observe all flows without ever touching or slowing them down.
The second challenge is distinguishing meaningful signals from noise. An industrial network continuously generates communication flows between PLCs, supervisory systems, and workstations. Identifying what is abnormal within that volume requires a precise understanding of what is normal, meaning a baseline that is granular, segmented by operational scope, and not applied globally.
The contextualization challenge
An alert forwarded to the SOC must be contextualized. A bare IP address or an isolated technical element means nothing to a SOC analyst who does not know the specifics of the plant. Without operational context, the analyst has no way of knowing:– Which production zone the affected device belongs to
– What its criticality level is for the process
– Who to contact in the plant to initiate threat verification
Alert contextualization is therefore the key to operational effectiveness. Without it, response time grows, and the incident spreads.
The third challenge is routing the right alerts to the right people. A cyber alert does not go to the same recipient as an operational alert. Anomalous network behavior on a safety controller does not concern the same teams as a CVE detected on a supervisory workstation. Without precise routing, alerts are lost in undifferentiated notification streams.
How Seclab Xplore addresses these challenges: four detection engines
Seclab Xplore incorporates several distinct rule engines, each covering a different type of detection. They operate in parallel and are all fed by the mapping knowledge built during the discovery phase.
Engine 1: cartographic monitoring (behavioral detection)
The first engine monitors the stability of the mapped environment: links between machines, devices present on the network, communication flows. It monitors flows continuously, including in zones where a conventional firewall would never be deployed, for example where real-time protocols circulate between PLCs in non-segmented areas.
Rules are created directly from the mapping tool. Baselines are defined not as a single global baseline for the entire environment, but as independent subsets corresponding to functional zones. The solution then monitors for deviations: new devices appearing, unexpected IPv6 addresses, connections established toward internet zones. This is stability-oriented detection, distinct from signature-based detection.
Engine 2: signature-based detection (Sigma and Suricata)
The second engine uses rules in Sigma format, a widely recognized format in the systems domain, extended by Seclab to cover the network layer. The choice of Sigma format is deliberate: it is readable, documentable, and understandable, including by OT teams who are not cybersecurity specialists. Rules can be described, annotated, and their logic remains accessible without in-depth training.
Xplore also supports Suricata format through a dedicated engine running in parallel. Suricata alerts are enriched with mapping knowledge before being forwarded to the SOC: operational context is systematically added, so the analyst immediately knows which zone and which device the alert relates to.
Engine 3: AI and machine learning
The third engine exploits a characteristic specific to industrial environments: their drive for stability. Industrial processes are designed to repeat. Communication flows between PLCs follow predictable patterns. It is precisely this stability that makes it possible to train a machine learning model on normal behavior and flag any deviation as a warning signal. The engine does not apply to all protocols, but on the perimeters where it is relevant, it delivers anomaly detection that requires no explicit rule authoring.
Engine 4: CVE vulnerability alerting
The fourth engine continuously cross-references the asset inventory against known vulnerability databases. As soon as a new CVE affects a device present on the network, an alert can be generated depending on the context rules of the device. These alerts can be routed to different recipients depending on their nature: IT teams, SOC, OT teams, production managers, external maintainers. Precise routing prevents information from being diluted in undifferentiated notification streams.
MITRE ATT&CK coverage and rule management
All rules, regardless of which engine they originate from, are tagged against MITRE ATT&CK. This provides a consolidated view of detection coverage against the MITRE matrix and makes it possible to identify any blind spots.
The goal is not to multiply rules in order to maximize a coverage score. The recommended approach is to start from the feared events specific to each environment, target the relevant rules at the right perimeters, and maintain a rule set that is reasonable in size, manageable, and actively maintained over time. A large number of poorly maintained rules is less effective than a targeted, well-documented, and up-to-date perimeter.
Alert queue, incident response and ecosystem integration
The solution includes its own alert queue, which can operate autonomously for an isolated site, or be configured to forward alerts to an external SIEM for centralized management. Reading an alert relies on two essential pieces of information: the impacted zones, and the name of the device concerned along with the operational group it belongs to. If an alert involves a device in the Energy division, the analyst immediately knows who to contact in the plant for threat verification, with no prior manual lookup required.
For incident response, each probe can be configured to record flows continuously. This makes it possible to download the PCAP corresponding to any event, with granular controls over the desired time depth and OSI depth. This continuous recording provides an immediately available evidence base, whether for cyber incidents or operational incidents.
A consolidated hypervision view covers the alert queue and the vulnerability queue in real time, for an at-a-glance picture of current exposure. All this data can be shared with the existing ecosystem: SIEM, centralized dashboards, consolidated IT/OT views. Seclab Xplore positions itself as an information hub capable of feeding third-party tools and integrating fully into existing security processes.
To discover Seclab Xplore, watch this excerpt from our June 2026 webinar replay
What now?
Mapping, isolation, detection: the three capabilities of the Seclab Xcore platform form a defense-in-depth architecture built for the real constraints of industrial environments. Each building block reinforces the others: mapping feeds detection, detection contextualizes alerts, and isolation reduces the surface over which detection must operate.
The threat to OT environments is real, documented, and growing. Organizations that have begun structuring their security approach have a head start. Those that have not yet launched an inventory of their industrial network have an obvious place to start.
