OT & ICS Security
The network that runs the plant was never designed to be attacked.
Operational technology was engineered for availability and determinism, on the assumption that the only people who could reach it were standing next to it. That assumption stopped being true when the historian needed a business-network connection. What is left is a fleet of controllers that cannot be patched on demand, speak protocols with no authentication, and will fault if you scan them the way you scan an office subnet. The work here is not to bolt IT security onto a plant. It is to earn a truthful picture of the environment without disturbing it, then reduce risk in the order that matters.
- Discovery first, so nothing gets scanned into a fault
- PassiveDiscovery first, so nothing gets scanned into a fault
- Zone and conduit model as the organizing artifact
- IEC 62443Zone and conduit model as the organizing artifact
- Attacks proven on a replica, never on the line
- BenchAttacks proven on a replica, never on the line
Sounds like
You might recognise one of these.
We have no idea what is actually on the control network.
Our vulnerability scanner knocked over a PLC, so now we do not scan.
The vendor says patching voids support, and we believe them.
Corporate IT and the plant engineers are not really speaking to each other.
An auditor asked us for our IEC 62443 zone and conduit model and we do not have one.
What this includes
The work, specifically.
Not every engagement needs all of it. This is the range we cover and what each part is actually for.
Passive asset discovery and network baselining
A truthful inventory built from span-port capture rather than active scanning: every controller, drive, HMI, engineering workstation and unaccounted device, with the protocols each one actually speaks. On brownfield sites this stage alone routinely finds equipment nobody in the room knew was connected.
Segmentation and the Purdue boundary
Zone and conduit design against IEC 62443, a DMZ that gives the historian, the MES and the remote-support vendor a defined path, and firewall policy written in terms of the process rather than in terms of subnets. We stage the changes so a misconfiguration never lands on a running line.
Protocol-aware monitoring and anomaly detection
Modbus/TCP, DNP3, EtherNet/IP, Profinet and S7comm parsed for what they mean, not just for who sent them. Control traffic is unusually regular, which makes it unusually easy to baseline: we fingerprint the steady state, including with similarity-preserving hashes over process traffic and controller memory, and alert on the deviation rather than on a signature somebody has to write first.
Controller and logic assurance
Ladder logic and structured-text review, project-file version control, and integrity checking of what is running on the controller against what engineering believes is running on it. Unauthorized logic change is one of the few OT events that is both catastrophic and quiet.
Adversarial validation on a replica, not on production
Denial of service, man in the middle, packet injection and command manipulation against a bench that mirrors your controllers, so you learn what is actually exploitable without an unplanned outage. We have run these classes of attack against Allen-Bradley, Siemens, Beckhoff and Click hardware in a research setting and we will show you the difference between a finding that matters and a CVE that does not apply.
OT incident response that a plant can actually execute
Runbooks written for the operator and the controls engineer, not for a SOC analyst who has never been on the floor. Safe-state procedures, evidence capture that does not require taking the line down, and a documented decision about who is allowed to stop production and on what evidence.
What you get
Deliverables, not documents.
- Passive asset inventory with protocol and firmware detail per device
- Zone and conduit model mapped to IEC 62443 with a costed remediation sequence
- Segmentation design and staged firewall rule sets with rollback
- Process-traffic baseline and tuned anomaly detection with named alert owners
- Controller logic integrity checks wired into a change process
- Bench-tested attack findings with observed impact, not theoretical severity
- OT incident runbooks and a tabletop exercise run with plant staff
Shapes
How this usually runs.
OT discovery
2–4 weeksFixed fee. Passive capture, interviews with the controls engineers, an accurate architecture drawing (usually the first one that has been accurate in years) and a ranked risk register.
Segmentation & monitoring build
8–16 weeksThe DMZ, the zone boundaries and the monitoring, delivered in changes small enough to land during ordinary maintenance windows.
Adversarial validation
3–6 weeksA replica bench of your controller families, attacked deliberately, with the impact of each finding demonstrated rather than asserted.
Tooling
What we build it with.
No tool here was picked because it was new. Where we do reach for something novel, it is in one place, for a stated reason, and it is written down.
- Controllers
- Protocols
- Analysis
- Standards
Proof
Where this has been done.
Questions
OT & ICS security, honestly.
Discovery does not. It is passive capture off a span or tap plus conversations with the people who run the equipment. Active testing happens on a bench that replicates your controller families, and segmentation changes are staged and rehearsed with a rollback before they go anywhere near a production window. If we ever propose something that could interrupt the process, you will hear it as a question, not find it in a report.
No, and patching is usually the least available lever in OT anyway. Most of the risk reduction available to a plant comes from segmentation, removing unmanaged remote access, controlling the engineering workstation, and being able to detect a change to controller logic. Those are all achievable on equipment that will not be patched for another decade.
Sometimes. The commercial OT monitoring tools are good and expensive, and they are worth it at a certain scale of estate. Below that, protocol-aware capture into the SIEM you already own gets you most of the detection value, and we will tell you honestly which side of the line you are on rather than reselling you something.
In practice, whoever is willing to be woken up. The engagements that work define this explicitly: engineering owns the process and the safe state, IT owns the boundary and the telemetry, and there is one named person who can authorize a production stop. The engagements that fail leave it implicit and discover the answer during an incident.
Next step
Tell us what’s breaking.
Forty-five minutes, no charge, no deck. We’ll tell you what we’d do, what it would likely cost, and whether you should be building this at all.