Work · Schneider Electric · 2022 to date
Detection engineering for OT
Industrial networks speak their own protocols and behave in their own ways. Detections written for office IT miss most of what matters on a plant floor, so we built our own.
- 230+custom OT detections built in-house
- 3OT monitoring platforms brought together
- ATT&CK for ICSand IEC 62443 as the frame
The problem
Many OT networks we took on had never been monitored. Asset visibility came first: you cannot detect an attack on a controller you do not know exists. After that, the detections had to understand industrial behaviour, not just IT indicators.
What I did
- Visibility first. Deployed Claroty and Nozomi into previously unmonitored OT networks for full ICS asset visibility, and brought Claroty, Nozomi and Tenable together into one OT/IT detection strategy.
- A custom detection library. More than 230 OT detections built in-house on Microsoft Sentinel, alongside the platform's own content, mapped to MITRE ATT&CK for ICS and aligned to IEC 62443.
- Rule frameworks. Snort and YARA rule frameworks for the network and file side, tuned for precision so analysts see fewer false positives.
How we work
- Observe before you allow-list. A new rule runs and shows real activity before any exceptions are added. Pre-loading an allow-list hides exactly what you were hunting.
- Detections decay. Plants change, networks change, and a rule that worked last year can go quietly blind. Every detection has an owner and gets reviewed, like any other part of the plant.
- Count what you can defend. The number we quote is the detections we engineered ourselves, never the platform's built-in content added on top.
Described at the level of my public CV. No customer or confidential detail is published here.