SCADA and ICS Security Testing

ICS Penetration Testing

Passive assessment and architecture review identify the majority of significant vulnerabilities in ICS/SCADA environments, but some findings require active testing to confirm exploitability and accurately characterize impact. GDF's ICS penetration testing engagements go beyond assessment to execute controlled exploitation in environments designed to protect production operations throughout the engagement. The result is a technically definitive finding set that eliminates uncertainty about whether identified vulnerabilities are genuinely exploitable, supporting prioritization decisions and providing the evidence base required for regulatory compliance documentation and legal proceedings.

ICS penetration testing requires a fundamentally different approach from IT network penetration testing. In an IT environment, the primary concern with active exploitation is data confidentiality. In an ICS environment, the concern is physical: incorrect commands sent to a PLC, unexpected traffic hitting a real-time controller, or disrupted communications between a safety instrumented system and its sensors can cause equipment damage, process shutdowns, or personnel injury. GDF's ICS penetration testing methodology is built around this constraint. Where active exploitation against production systems is not appropriate, GDF uses digital twin environments, isolated lab setups with hardware-in-the-loop configurations, and documented controlled exploitation windows that are planned in detail with operations staff before execution begins.

Digital Twin and Lab Environment Testing

For organizations where testing against production ICS components carries unacceptable risk, GDF can conduct penetration testing against a digital twin or physical lab replica of the target environment. GDF works with the client's engineering team to configure the test environment to accurately reflect the production system's network topology, protocol configuration, PLC logic, and HMI setup. Vulnerabilities identified and exploited in the test environment are documented with sufficient technical detail to confirm that the same exploitation path would succeed against the corresponding production system, without requiring any active probing of live operational assets.

Hardware-in-the-loop configurations use actual PLCs, RTUs, or HMI hardware in the test environment, providing a higher-fidelity test than purely simulated environments. When the client has spare hardware available, this approach allows GDF to execute protocol-specific exploitation techniques against real device firmware rather than software emulation, producing findings that accurately characterize the production device's actual vulnerability to the tested attack technique.

IT/OT Boundary Penetration Testing

The boundary between IT and OT networks is the most frequently exploited attack path in ICS security incidents. Attackers who establish access on the corporate IT network move laterally through inadequately segmented DMZ zones, vendor remote access channels, and engineering workstations that bridge both networks to reach the control network. GDF's IT/OT boundary penetration testing explicitly targets this attack path, testing whether an adversary with IT-side access can reach OT network assets and, if so, what access they can obtain once they arrive.

Boundary penetration testing covers firewall rule validation (testing whether rules documented in policy are actually enforced by the deployed firewall configuration), DMZ architecture testing (verifying that DMZ hosts cannot be used as pivot points to the OT network), jump server security testing (assessing whether administrative access to OT systems through jump servers is adequately controlled), and vendor remote access testing (examining the security of persistent or on-demand remote access channels established by equipment vendors). Findings from this phase frequently identify paths from corporate networks to safety-critical OT assets that the organization's security architecture was intended to prevent.

Protocol-Specific Exploitation

Industrial control systems use specialized protocols that carry commands and data in formats designed for reliability and determinism rather than security. Many of these protocols, including Modbus, DNP3, and OPC UA, were designed without authentication or encryption, operating on the assumption that network isolation provided adequate protection. As OT networks have become connected to corporate infrastructure and the internet, these protocol-level weaknesses have become exploitable by adversaries who can reach the control network.

GDF's protocol-specific exploitation testing uses purpose-built ICS security tools to conduct controlled exploitation of Modbus, DNP3, and OPC UA implementations. Modbus testing covers command injection (sending unauthorized read and write commands to coil and register addresses), addressing scheme reconnaissance (enumerating PLC memory maps to identify control-relevant registers), and replay attacks that capture and retransmit legitimate command sequences. DNP3 testing covers spoofed command injection, unsolicited response flooding, and exploitation of DNP3 Secure Authentication weaknesses where implemented. OPC UA testing covers certificate validation bypass, session hijacking attempts, and exploitation of access control misconfigurations in OPC UA server implementations.

GDF conducts protocol-specific exploitation testing only in lab or digital twin environments, or against isolated test instances of the target devices with explicit written approval from the client's operations and safety teams. Findings document the exact exploitation technique, the tool configuration used, the attacker's required network position, and the operational impact that successful exploitation would produce against production equipment.

Physical-to-Cyber Attack Path Testing

Physical access to ICS facilities creates attack paths that are not visible in network architecture diagrams. Engineering workstations left unlocked, USB ports without media controls, removable devices used to transfer files between air-gapped networks, and maintenance laptops that connect to both IT and OT networks are all examples of physical access vectors that have been used in documented ICS attacks. The Stuxnet attack depended on a USB-based initial access path to cross an air gap. Many industrial ransomware incidents have originated from service technician laptops brought into OT environments for maintenance.

GDF's physical-to-cyber attack path testing examines these vectors with the cooperation of facility security and operations staff. Testing covers USB port access controls on engineering workstations and HMIs (verifying whether device controls prevent execution of unauthorized code from removable media), physical access to network infrastructure (testing whether an adversary with brief physical access to a control room could attach a network device or extract credentials), and portable device policy enforcement (assessing whether service technician and contractor devices are screened before connecting to OT networks). Findings from this phase frequently identify physical attack paths that bypass the network-level security controls the organization has invested in.

ICS Red Team Exercises

ICS red team exercises simulate a targeted, multi-stage attack against an industrial facility, executed by a GDF team operating with attacker methodology and objectives. Unlike individual penetration tests that examine specific systems or techniques, red team exercises test the organization's detection and response capability against a realistic adversary operating across the full kill chain: initial access, persistence, lateral movement through IT infrastructure, IT/OT boundary crossing, and final-stage OT access or disruption.

GDF designs each ICS red team exercise around a specific threat actor model relevant to the client's sector and asset type. Electric utility red team exercises model nation-state actors with documented interest in electric grid disruption. Water utility exercises model criminal actors and ideologically motivated groups documented in public incident reports. Manufacturing exercises model industrial espionage actors seeking production process data alongside ransomware actors seeking to maximize disruption impact. This specificity produces exercise findings that are directly applicable to the client's actual threat environment rather than generic attack scenarios.

Red team exercise reporting documents the complete attack narrative, including the detection opportunities the exercise created and whether existing security monitoring identified them. This provides a direct measure of the organization's detection and response capability against the simulated threat actor, informing both security tool investment decisions and security operations center training priorities.