A penetration test on an industrial control system is fundamentally different from an IT pentest: the target is a live production environment where a scan can trip a watchdog, a malformed packet can stop a controller, and the test itself can become the incident. Done responsibly, ICS penetration testing is one of the most valuable security exercises a plant can run — it validates the defenses with evidence and produces the priority list that risk assessments can only guess at. Done irresponsibly, it creates the outage it was meant to prevent. The discipline is in the planning.
Types of ICS Security Testing
| Test type | What it does | Risk profile |
|---|---|---|
| Architecture review | Documented analysis of network design, zones, rule sets, and configurations against the security standard. | None (offline) |
| Configuration review | Hardening audit: accounts, services, patches, device defaults — from evidence, not testing. | None–low (may need read-only access) |
| Passive monitoring | Observe traffic and behavior without sending anything. | None |
| Active testing in a lab | Exploit and validate attacks against replicas of the production systems. | None to production |
| Active testing on production | Real scans and attacks against the live system. | High — needs exceptional justification and controls |
The standard approach: architecture and configuration review plus passive monitoring plus lab testing on a replica — which together deliver most of the value with almost none of the risk. Full active testing on live production is reserved for the situations where it is genuinely necessary, and is executed with the controls below.
Planning: The Rules of Engagement
- Scope in writing — the test plan lists: target systems (by IP/asset), test types permitted, tools allowed, and — critically — the systems excluded (safety systems, SIS, protection relays, anything whose interruption is unacceptable). The SIS is never a test target on a live plant.
- Authorization — signed authorization from the accountable owner (plant manager/OT owner) covering the dates, the scope, and the acceptance of defined risks; the authorization names the decision authority for aborting.
- Baseline and abort criteria — before testing: recorded baseline of controller statuses, alarms, and historians. Abort criteria defined: any safety event, any unexplained controller trip, any process deviation — the test stops and the plant takes priority.
- Timing — outside production-critical windows (planned shutdowns and low-load periods are the norm), with operations informed shift by shift; the control room is told a test is running and who to call.
- Personnel — the testers work with a plant-side coordinator (who knows the process and the people); testers are never alone in the control network.
- Testing methodology — passive first, then gentle active (non-destructive scans with conservative timing — no aggressive scanning of controllers), with every action logged.
Safe Execution Techniques
- Prefer lab replicas — build the replica (virtualized or spare hardware) with the same firmware and configuration; most exploitation and validation happens there, with the production test reduced to confirming what the lab proved.
- Respect protocol fragility — industrial protocols have strict timing; slow scans, single-connection tests, and no fuzzing on production. Fuzzing belongs exclusively in the lab.
- Read-only first — enumeration and observation before any active interaction; many findings (default credentials, exposed services, unencrypted protocols) are visible without touching anything.
- Watch the process — the plant coordinator monitors process and alarm status continuously during active testing; the test pauses at the first anomaly, and the cause is confirmed before resuming.
- Credentials by agreement — testing with and without credentials answers different questions; both are valid, but the credentials used must be provided by the plant under controlled terms, never guessed from documentation lying around.
Reporting and Remediation
The report separates findings by severity and by exploitability on the live plant: a finding may be real but only exploitable in the lab; the report states the production exposure honestly. Every finding gets: evidence, the affected systems, the risk in the plant's language (not CVSS alone — what happens to production if exploited), and remediation options ranked (quick wins: disable services, change credentials; structural: segmentation, monitoring; strategic: program improvements). Findings feed the risk register and the remediation backlog with owners and dates; a pentest without a remediation plan is an expense, not an investment.
Frequency and Program Fit
ICS testing is not a one-off: architecture/config review annually or after major changes, passive monitoring continuously (see the OT monitoring article), and active testing on a cycle justified by the risk picture (typically every 1–3 years for critical plants). The test program should be a standing line item, planned with the production calendar, and its findings reviewed by management — the test is the evidence the security program reports against.
Summary
ICS penetration testing is planning and safety discipline first, technique second: written scope with excluded systems (never the SIS), signed authorization, abort criteria, lab-first testing, conservative live testing with a plant coordinator, and findings reported with production impact and remediation owners. The value is evidence-based priorities; the risk is controlled by the rules of engagement. Test to learn, and the plant gets stronger; test without discipline, and the test becomes the incident.