{"data":{"slug":"ics-penetration-testing","title":"ICS Penetration Testing: Planning and Safe Execution","summary":"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…","category":{"slug":"industrial-cybersecurity","name":"Industrial Cybersecurity"},"url":"https://wiki.aspotomasyon.com/article/ics-penetration-testing","markdown_url":"https://wiki.aspotomasyon.com/article/ics-penetration-testing.md","api_url":"https://wiki.aspotomasyon.com/api/v1/articles/ics-penetration-testing","published":"2026-08-11T13:05:24+00:00","modified":"2026-09-13T11:07:23+00:00","reading_minutes":5,"word_count":947,"image":"https://wiki.aspotomasyon.com/assets/social/ics-penetration-testing-bc5050365e65.png","html":"

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.

\"Conceptual
Conceptual access controls around an OT service. Actual zones, conduits, protections, and response actions require a site-specific assessment. View full size
\n\n

Types of ICS Security Testing

\n\n\n \n \n \n \n \n \n \n \n \n \n
Test typeWhat it doesRisk profile
Architecture reviewDocumented analysis of network design, zones, rule sets, and configurations against the security standard.None (offline)
Configuration reviewHardening audit: accounts, services, patches, device defaults — from evidence, not testing.None–low (may need read-only access)
Passive monitoringObserve traffic and behavior without sending anything.None
Active testing in a labExploit and validate attacks against replicas of the production systems.None to production
Active testing on productionReal scans and attacks against the live system.High — needs exceptional justification and controls
\n\n

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.

\n\n

Planning: The Rules of Engagement

\n\n
    \n
  1. 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.
    2. \n
  2. 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.
    3. \n
  3. 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.
    4. \n
  4. 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.
    5. \n
  5. Personnel — the testers work with a plant-side coordinator (who knows the process and the people); testers are never alone in the control network.
    6. \n
  6. Testing methodology — passive first, then gentle active (non-destructive scans with conservative timing — no aggressive scanning of controllers), with every action logged.
    7. \n
\n\n

Safe Execution Techniques

\n\n\n\n

Reporting and Remediation

\n\n

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.

\n\n

Frequency and Program Fit

\n\n

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.

\n\n

Summary

\n\n

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.

Apply this to your project

Follow an ASP project guide to connect the fundamentals with implementation and acceptance.

\"Engineering
Engineering review sequence: Inventory → Restrict → Observe → Recover. Keep the recorded evidence with the accepted configuration. View full size

Primary references and further reading

Use the original specifications and product documentation for implementation details. The examples in this guide are illustrative engineering scenarios, not published project results.

","markdown":"# ICS Penetration Testing: Planning and Safe Execution\n\n> 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…\n\n- Canonical URL: https://wiki.aspotomasyon.com/article/ics-penetration-testing\n- Publisher: ASP OTOMASYON A.Ş. (ASP OTOMASYON Wiki)\n- Category: Industrial Cybersecurity\n- Published: 2026-08-11 · Updated: 2026-09-13\n- Reading time: 5 min · Language: English\n\nA 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.\n\n![Conceptual access controls around an OT service. Actual zones, conduits, protections, and response actions require a site-specific assessment.](https://wiki.aspotomasyon.com/assets/diagrams/industrial-cybersecurity-context.svg)\n\n*Conceptual access controls around an OT service. Actual zones, conduits, protections, and response actions require a site-specific assessment.*\n\n## Types of ICS Security Testing\n\n| Test type | What it does | Risk profile |\n| --- | --- | --- |\n| Architecture review | Documented analysis of network design, zones, rule sets, and configurations against the security standard. | None (offline) |\n| Configuration review | Hardening audit: accounts, services, patches, device defaults — from evidence, not testing. | None–low (may need read-only access) |\n| Passive monitoring | Observe traffic and behavior without sending anything. | None |\n| Active testing in a lab | Exploit and validate attacks against replicas of the production systems. | None to production |\n| Active testing on production | Real scans and attacks against the live system. | High — needs exceptional justification and controls |\n\nThe 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.\n\n## Planning: The Rules of Engagement\n\n1. **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.\n2. **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.\n3. **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.\n4. **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.\n5. **Personnel** — the testers work with a plant-side coordinator (who knows the process and the people); testers are never alone in the control network.\n6. **Testing methodology** — passive first, then gentle active (non-destructive scans with conservative timing — no aggressive scanning of controllers), with every action logged.\n\n## Safe Execution Techniques\n\n- **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.\n- **Respect protocol fragility** — industrial protocols have strict timing; slow scans, single-connection tests, and no fuzzing on production. Fuzzing belongs exclusively in the lab.\n- **Read-only first** — enumeration and observation before any active interaction; many findings (default credentials, exposed services, unencrypted protocols) are visible without touching anything.\n- **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.\n- **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.\n\n## Reporting and Remediation\n\nThe 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.\n\n## Frequency and Program Fit\n\nICS 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.\n\n## Summary\n\nICS 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.\n\n## Apply this to your project\n\n- Identify asset owners, permitted communications, operational dependencies, and consequences of losing the function.\n- Test access restrictions and visibility without disrupting plant operations; agree the activity with the OT owner.\n- Validate an offline recovery path and document who can authorize isolation, restoration, and return to service.\n\n[Follow an ASP project guide](https://wiki.aspotomasyon.com/guides) to connect the fundamentals with implementation and acceptance.\n\n![Engineering review sequence: Inventory → Restrict → Observe → Recover. Keep the recorded evidence with the accepted configuration.](https://wiki.aspotomasyon.com/assets/diagrams/industrial-cybersecurity-review.svg)\n\n*Engineering review sequence: Inventory → Restrict → Observe → Recover. Keep the recorded evidence with the accepted configuration.*\n\n## Primary references and further reading\n\nUse the original specifications and product documentation for implementation details. The examples in this guide are illustrative engineering scenarios, not published project results.\n\n- [NIST SP 800-82 Rev. 3 — Guide to Operational Technology Security](https://csrc.nist.gov/pubs/sp/800/82/r3/final)\n- [ISA — ISA/IEC 62443 series](https://www.isa.org/standards-and-publications/isa-standards/isa-iec-62443-series-of-standards)\n\n---\n\nCite the canonical article: https://wiki.aspotomasyon.com/article/ics-penetration-testing (ICS Penetration Testing: Planning and Safe Execution, ASP OTOMASYON, updated 2026-09-13).\n","headings":[{"id":"types-of-ics-security-testing","title":"Types of ICS Security Testing"},{"id":"planning-the-rules-of-engagement","title":"Planning: The Rules of Engagement"},{"id":"safe-execution-techniques","title":"Safe Execution Techniques"},{"id":"reporting-and-remediation","title":"Reporting and Remediation"},{"id":"frequency-and-program-fit","title":"Frequency and Program Fit"},{"id":"summary","title":"Summary"},{"id":"apply-this-to-your-project","title":"Apply this to your project"},{"id":"primary-references-and-further-reading","title":"Primary references and further reading"}],"faq":[],"references":[{"name":"NIST SP 800-82 Rev. 3 — Guide to Operational Technology Security","url":"https://csrc.nist.gov/pubs/sp/800/82/r3/final"},{"name":"ISA — ISA/IEC 62443 series","url":"https://www.isa.org/standards-and-publications/isa-standards/isa-iec-62443-series-of-standards"}],"related":[{"slug":"mitre-attack-for-ics-threat-informed-defense","title":"MITRE ATT&CK for ICS: Using the Matrix for Threat-Informed OT Defense","summary":"ATT&CK for ICS gives OT teams a shared catalog of adversary behavior, so detection and control gaps can be tested against plausible scenarios instead of…","category":{"slug":"industrial-cybersecurity","name":"Industrial Cybersecurity"},"url":"https://wiki.aspotomasyon.com/article/mitre-attack-for-ics-threat-informed-defense","markdown_url":"https://wiki.aspotomasyon.com/article/mitre-attack-for-ics-threat-informed-defense.md","api_url":"https://wiki.aspotomasyon.com/api/v1/articles/mitre-attack-for-ics-threat-informed-defense","published":"2026-10-11T11:46:21+00:00","modified":"2026-10-11T11:46:21+00:00","reading_minutes":8,"word_count":1676,"image":"https://wiki.aspotomasyon.com/assets/social/mitre-attack-for-ics-threat-informed-defense-dd88cfe7cb9b.png"},{"slug":"ot-security-architecture-defense-in-depth","title":"OT Security Architecture: Defense in Depth for Industrial Networks","summary":"Operational Technology (OT) environments — including industrial control systems (ICS), SCADA, DCS, and safety instrumented systems (SIS) — present unique…","category":{"slug":"industrial-cybersecurity","name":"Industrial Cybersecurity"},"url":"https://wiki.aspotomasyon.com/article/ot-security-architecture-defense-in-depth","markdown_url":"https://wiki.aspotomasyon.com/article/ot-security-architecture-defense-in-depth.md","api_url":"https://wiki.aspotomasyon.com/api/v1/articles/ot-security-architecture-defense-in-depth","published":"2026-05-13T12:07:53+00:00","modified":"2026-09-13T11:07:23+00:00","reading_minutes":10,"word_count":2092,"image":"https://wiki.aspotomasyon.com/assets/social/ot-security-architecture-defense-in-depth-427478438d17.png"},{"slug":"virtual-plc-iec-61499-software-defined-automation","title":"Virtual PLCs and IEC 61499: What Software-Defined Automation Changes","summary":"Virtual PLCs run control logic on standard computing hardware, and IEC 61499 replaces the scan cycle with events, so both need an explicit timing, redundancy…","category":{"slug":"automation-systems","name":"Automation Systems"},"url":"https://wiki.aspotomasyon.com/article/virtual-plc-iec-61499-software-defined-automation","markdown_url":"https://wiki.aspotomasyon.com/article/virtual-plc-iec-61499-software-defined-automation.md","api_url":"https://wiki.aspotomasyon.com/api/v1/articles/virtual-plc-iec-61499-software-defined-automation","published":"2026-10-11T11:46:21+00:00","modified":"2026-10-11T11:46:21+00:00","reading_minutes":9,"word_count":1820,"image":"https://wiki.aspotomasyon.com/assets/social/virtual-plc-iec-61499-software-defined-automation-1d23170d2c5a.png"},{"slug":"ics-incident-response-recovery","title":"ICS Incident Response and Recovery","summary":"Industrial Control System (ICS) incident response is the structured approach to preparing for, detecting, containing, and recovering from cybersecurity events…","category":{"slug":"industrial-cybersecurity","name":"Industrial Cybersecurity"},"url":"https://wiki.aspotomasyon.com/article/ics-incident-response-recovery","markdown_url":"https://wiki.aspotomasyon.com/article/ics-incident-response-recovery.md","api_url":"https://wiki.aspotomasyon.com/api/v1/articles/ics-incident-response-recovery","published":"2026-07-21T14:45:28+00:00","modified":"2026-09-13T11:07:23+00:00","reading_minutes":4,"word_count":785,"image":"https://wiki.aspotomasyon.com/assets/social/ics-incident-response-recovery-991fe88d57d7.png"}],"citation":"ASP OTOMASYON. ICS Penetration Testing: Planning and Safe Execution. Updated 2026-09-13. https://wiki.aspotomasyon.com/article/ics-penetration-testing"}}