The Annual Pen Test Problem

Most critical infrastructure organizations conduct penetration testing once a year — or once per compliance cycle. A team of external testers spends one to two weeks probing network perimeters, pivoting through IT systems, and writing a report that lands on the CISO's desk months later.

For IT environments, this model has known limitations. For OT/ICS environments, it's fundamentally inadequate.

Why OT Changes the Equation

Traditional penetration tests assume the environment can tolerate aggressive testing. Port scans, exploit attempts, credential stuffing, and lateral movement are acceptable risks when the worst case is a crashed web server that restarts in seconds.

In OT environments, the worst case is a tripped safety system, a disrupted manufacturing process, or physical equipment damage. A single malformed Modbus packet to a PLC controlling a chemical dosing system isn't just a test — it's a potential safety incident.

This creates a paradox: the environments that most need security validation are the ones least able to tolerate traditional testing methods.

What Is Purple Teaming?

Purple teaming merges offensive (red) and defensive (blue) team operations into a collaborative exercise. Rather than red team operating covertly while blue team reacts, both sides work together with shared visibility:

Red team designs and executes attack scenarios based on real-world threat intelligence
Blue team monitors detection and response capabilities in real time
Joint analysis identifies gaps in detection, prevention, and response after each scenario

The result isn't a penetration test report listing vulnerabilities. It's a validated assessment of your security program's ability to detect and respond to specific attack techniques.

Purple Teaming Adapted for OT

Adapting purple team methodology for OT/ICS environments requires three fundamental changes:

1. Protocol-Aware Validation

OT environments communicate over industrial protocols — Modbus TCP, DNP3, OPC UA, EtherNet/IP, S7comm, IEC 61850. Effective purple team exercises must understand these protocols at a deep level:

Modbus: Read-only function codes (FC 01-04) are safe for reconnaissance. Write function codes (FC 05, 06, 15, 16) must be bounded to test registers that don't control physical processes.
DNP3: Unsolicited responses and broadcast messages require careful handling. Class 0-3 data polling is generally safe; direct operate commands are not.
OPC UA: Browse and read operations are non-disruptive. Write operations to process variables require explicit safety boundaries.

A protocol-unaware pen test tool sending arbitrary packets to these services creates unacceptable operational risk.

2. Safety-Bounded Execution

Every purple team scenario in OT must define explicit safety boundaries before execution:

Acceptable operations: Asset discovery, passive traffic analysis, authentication testing against isolated systems, read-only protocol interactions
Controlled operations: Write operations to non-production test registers, lateral movement through IT/OT boundary systems, credential access on engineering workstations
Prohibited operations: Any operation that could modify PLC logic, alter setpoints on live processes, or trigger safety instrumented systems

These boundaries aren't optional — they're the difference between security validation and operational disruption.

3. Continuous vs. Periodic Execution

Annual pen tests provide annual risk snapshots. Purple team exercises integrated into a CTEM framework provide continuous validation:

Weekly: Automated replay of detection rules against known ICS attack techniques (MITRE ATT&CK for ICS)
Monthly: Protocol-specific validation of segmentation boundaries and access controls
Quarterly: Full-scope purple team exercises simulating nation-state adversary TTPs targeting your specific sector
Continuous: Passive monitoring of OT network traffic for techniques that shouldn't exist in normal operations

Real-World Attack Scenarios

Effective OT purple team exercises map to real adversary behavior. Key scenarios include:

IT-to-OT Pivot: An attacker compromises IT infrastructure (phishing, VPN exploit, supply chain attack) and attempts to reach Level 2/1/0 of the Purdue Model. The purple team validates whether segmentation, firewall rules, and jump server controls actually prevent this lateral movement.

Engineering Workstation Compromise: Attack scenarios targeting the engineering workstations that program PLCs and configure HMIs. Can an attacker with workstation access modify control logic? Do your change detection systems catch it?

Protocol Exploitation: Testing whether OT devices accept unauthenticated commands, respond to unauthorized read requests, or expose configuration data to non-engineering endpoints.

Historian/DMZ Traversal: Validating that data historians in the DMZ cannot be used as pivot points from IT to OT networks, and that SQL injection or similar attacks against historian databases don't enable control plane access.

Measuring Purple Team Effectiveness

Purple team exercises produce concrete, measurable outputs:

Detection coverage: Percentage of executed attack techniques detected by your security monitoring
Response time: Mean time from technique execution to analyst acknowledgment
Containment time: Mean time from detection to effective containment action
Prevention rate: Percentage of techniques blocked before execution completes

These metrics are far more valuable than a penetration test's vulnerability count. Knowing you have 47 vulnerabilities tells you little. Knowing that your SOC detects 3 of 12 ICS-specific attack techniques tells you exactly where to invest.

From Annual Testing to Continuous Validation

The shift from periodic pen testing to continuous purple team validation fundamentally changes OT security posture. Instead of hoping your defenses work until the next test, you have ongoing evidence of what works, what doesn't, and where your detection blind spots are.

For organizations running critical infrastructure — where a successful attack has physical, environmental, and public safety consequences — hope is not a security strategy. Continuous, protocol-aware, safety-bounded validation is.