ICS/OT Penetration Testing

Offensive testing of control systems, built around the safety of the process.

Ask about penetration testingAll services

When you need it

  • Nobody has ever tested whether the corporate network really reaches the controllers
  • A regulator, auditor, insurer or customer has asked for evidence of testing, not a policy
  • You are commissioning a new critical system and need it tested before it goes live
  • You have just finished a segmentation or remote access project and want proof it worked
  • You want to know what your monitoring would actually catch

A penetration test answers the question a risk assessment cannot: can an attacker actually get from the internet, or the corporate network, to the systems that run the plant, and what could they do when they arrive? We test that path the way a real intrusion would take it, with testers who have run offensive engagements and who understand what a controller does when it is pushed.

It is not an IT penetration test pointed at a plant. Scanners and exploits that a web server shrugs off can stop a fifteen-year-old controller. So every engagement is scoped by zone, with rules of engagement, test windows and stop conditions agreed with operations and engineering before anything is sent. Passive discovery comes first. Active testing is done where it is safe, in agreed windows, on agreed systems. Anything that cannot be tested safely on the live plant is reproduced in a lab, on spare or representative equipment, and proven there.

The engagement is shaped to what you need to know: an external exposure test of the internet-facing estate; an assumed-breach test from the corporate network into the OT, the path most real incidents take; a test inside the OT network itself; device and firmware testing in the lab; or all of them as one exercise. Where you have monitoring, we run it with your analysts watching, so the report also says what was seen and what was missed.

How it runs

  1. 1

    Scope and rules of engagement

    Which zones, which systems, which windows, which techniques, and the stop conditions. Agreed in writing with operations, engineering and the vendors who need to know.

  2. 2

    Passive discovery

    Traffic capture, configuration review and documentation: the assets, the protocols, the paths and the accounts, without sending a packet to the plant.

  3. 3

    Vulnerability assessment

    Weaknesses across the paths found: exposed services, remote access, credentials, patching, segmentation, controller and HMI configuration. Ranked by what they would let an attacker do.

  4. 4

    Active testing, live or in the lab

    Exploitation from the outside and from the corporate network in agreed windows, with operations in the room and a stop condition on every step. Anything unsafe to test on the live plant is reproduced on spare or representative equipment and proven there. Live safety systems are never a target.

  5. 5

    Report, walk-through, retest

    The attack path, the findings by consequence, what monitoring saw, and a remediation plan by outage window. Walked through with the people who will fix it, and retested when they have.

What you get

  • The attack path, told end to end: how far an attacker gets and what they could do at each step
  • Findings ranked by consequence to the process, not by scanner score
  • Exploitation evidence where it was safe, and lab reproduction where it was not
  • What your monitoring saw and what it missed
  • A remediation plan sequenced by risk and by outage window, and a retest when it is done

Where it is used most

Questions we get asked

Will it disrupt the plant?

That is the first thing the scope is designed to prevent. Discovery is passive. Active testing happens only in agreed windows on agreed systems, with a stop condition on every step and operations in the room. Live safety instrumented systems are reviewed and lab-tested, never attacked in place.

External, assumed breach or inside the OT: which do we need?

Most clients start with an external exposure test and an assumed-breach test from the corporate network, because that is the route real incidents take. Testing inside the OT network follows once the boundary is understood. We scope the combination that answers your question.

How is this different from a vulnerability scan?

A scan lists what is there. A test proves what an attacker can do with it. Scanning OT is itself a risk, which is why our discovery is passive and our active work is deliberate.

Do you test controllers and firmware?

Yes, in the lab, on spare or representative units, where a crash costs nothing. Findings are then mapped back to the live estate.

Does this satisfy our regulator?

It produces the evidence they ask for: independent testing with a documented method, findings and remediation. India's CEA power sector regulations require vulnerability assessment and penetration testing before a critical system is commissioned; Australia's SOCI regime expects vulnerability assessment on request for systems of national significance and evidence of managed risk under CIRMP.

Further reading

Talk to us about penetration testing.

Tell us about the site, the systems and what you are trying to achieve. A consultant will reply.

Talk to usSee our services