SXGuard — Swiss Security
...
OT (Operational Technology) Penetration Testing
Methodology

OT (Operational Technology) Penetration Testing

Safety-first testing of SCADA and PLC environments, carefully scoped to avoid physical downtime.

An operator monitoring an industrial control room

I) Introduction

Definition

An Operational Technology (OT) penetration test is a security assessment of Industrial Control Systems (ICS), including SCADA, Distributed Control Systems (DCS), and Programmable Logic Controllers (PLCs). These systems control physical processes (e.g., manufacturing, power generation, chemical processing).

The Prime Directive: Safety & Availability First

Unlike in IT, where confidentiality is often the main concern, OT security is governed by a different priority:

  • Safety: Ensuring the physical safety of personnel, the environment, and the public.
  • Availability: Ensuring the continuous, real-time operation of the industrial process.
  • Integrity: Ensuring that data and commands are accurate.
  • Confidentiality: This is a distant fourth.

This methodology is built on the non-negotiable principle that this test must NOT, under any circumstances, cause a loss of safety, availability, or control. All active or potentially disruptive testing must be reserved for an isolated, non-production test lab.

II) Penetration Test Phases

Phase 1: Planning and Scoping

This phase is far more detailed and rigid than in any other type of test.

1.1. Define Objectives

  • Primary Goal: To identify vulnerabilities that could allow an attacker to cross the IT/OT boundary and affect a physical process without causing an outage.
  • Secondary Goals:
    • Validate network segmentation (e.g., the Purdue Model).
    • Identify vulnerable assets and misconfigurations.
    • Assess the physical impact of a potential cyber-attack in a controlled test lab.

1.2. Define Scope

  • In-Scope:
    • Specific network segments (e.g., Control Network, DMZ).
    • Specific systems (e.g., HMIs, Engineering Workstations, Historian).
  • Out-of-Scope (Strictly Enforced):
    • The live, production Process Control Network (Level 1) and Safety Instrumented Systems (SIS / Level 0) are off-limits for any active scanning or testing.
    • Any device where a vendor has warned against scanning.
    • Active exploitation of any kind on any production system.

1.3. Establish Rules of Engagement (ROE)

  • Testing Window: MANDATORY. Must be scheduled during a planned maintenance shutdown. Testing on a live, running process is forbidden.
  • SME Escort: MANDATORY. A qualified plant engineer or OT operator with "stop-button" authority must be physically present with the tester at all times.
  • Test Lab: The client must provide a non-production test rig (e.g., a "skid") with identical or similar PLCs, HMIs, and controllers for all "exploitation" and active-testing phases.
  • "Stop" Command: A single verbal command from the SME escort (e.g., "STOP") will result in the immediate cessation of all testing activities.
  • Tooling: All tools must be approved. Standard IT scanners (Nessus, nmap with default scripts) are forbidden on the production network. Use of specialized OT-safe tools is required.

Phase 2: Reconnaissance (Passive & Cautious)

The goal is to build an asset inventory without disrupting operations.

2.1. Passive Reconnaissance (OSINT)

  • Identify vendor manuals, HMI screenshots, network diagrams, or system information that employees or vendors may have posted publicly.
  • Search ICS-CERT advisories for known vulnerabilities related to the client's vendors.

2.2. Passive Network Reconnaissance (Network Tapping)

  • This is the primary recon method.
  • Connect to a SPAN or Tap port on a core switch to receive a mirrored copy of the network traffic.
  • Tools: Wireshark (with OT protocol dissectors like Modbus, DNP3, S7comm), tcpdump.
  • Goals:
    • Asset Identification: Passively discover all active devices (PLCs, HMIs, RTUs) by observing their traffic.
    • Protocol Discovery: Identify all OT protocols in use.
    • Communication Mapping: Map which devices are "masters" (e.g., HMI) and which are "slaves" (e.g., PLC).

2.3. Cautious Active Reconnaissance

  • Performed only if the ROE allows, only during the maintenance window, and only with the SME present.
  • Do not run a default nmap -sS -p- scan. This can and will crash fragile OT devices.
  • Method:
    • Use vendor-specific discovery utilities (e.g., Rockwell's RSLinx) which use safe, proprietary discovery protocols.
    • If nmap is used, it must be a specific, targeted scan using OT-safe scripts (e.g., nmap --script modbus-discover.nse -p 502 <IP>).

Phase 3: Vulnerability Analysis

3.1. Vulnerability Mapping

  • Correlate the discovered asset inventory (from Phase 2) with known vulnerabilities (e.g., default credentials, insecure protocols, ICS-CERT alerts).
  • Key Focus: Purdue Model Violations.
    • Can an HMI on Level 2 directly access the internet?
    • Can a workstation on the IT network (Level 4) send a command directly to a PLC on Level 1? This is a critical segmentation failure.

3.2. Test Rig Attack Planning

  • Based on the vulnerabilities found, develop attack scenarios to be tested only in the offline test lab.
  • Example Scenarios:
    • "If we gain access to the Engineering Workstation, can we use its software to download a modified program to the test PLC?"
    • "If we are on the control network, can we send a 'STOP' command to the PLC using a simple Modbus script?"
    • "Can we intercept traffic between the test HMI and test PLC to create a 'false reading'?"

Phase 4: Exploitation (SIMULATED & LAB-ONLY)

CRITICAL: THIS PHASE IS NEVER PERFORMED ON THE PRODUCTION NETWORK.

All activities in this phase are conducted in the isolated, non-production test lab.

Attack Simulation

  • Gain Initial Access: (e.g., Exploit a vulnerability on the IT/OT jump-box).
  • Protocol Abuse: Use OT-specific tools (modbus-cli, s7pclient) to interact with the test PLC.
  • Read Commands: (Harmless) Read a coil or register (e.g., READ_COIL).
  • Write Commands: (The "Exploit") Attempt to write to a register or coil (e.g., WRITE_SINGLE_COIL) to change a setting or stop the test PLC.
  • Man-in-the-Middle (MITM): Use tools like ettercap (in the lab!) to intercept traffic between the test HMI and test PLC.
  • Goal: Inject false data. Make the HMI show a "Normal" (e.g., 100 PSI) value while sending a "Danger" (e.g., 200 PSI) command to the PLC, or vice-versa.
  • HMI Hijacking: Use default VNC/RDP credentials to take remote control of the test HMI.

Phase 5: Reporting

5.1. Impact Analysis (Business Risk)

  • Do not focus on data exfiltration. Focus on the physical consequences.
  • Work with the SME to document the real-world impact of the lab-proven exploit.
  • Examples:
    • Finding: "We stopped the test PLC using a single, unauthenticated Modbus packet."
    • Impact: "This would cause an immediate shutdown of the assembly line, resulting in an estimated $500,000 in lost revenue per hour."
    • Finding: "We successfully changed a 'setpoint' value in the test PLC's memory."
    • Impact: "This could cause a chemical mixture to overheat, creating a significant safety and environmental hazard."

5.2. Reporting

  • Executive Summary: Must be focused on physical risk, safety, and business continuity. Use financial and operational impact language.
  • Technical Report:
    • Attack Narrative: "By simulating an attacker on the corporate network, we successfully crossed the IT/OT firewall (due to misconfiguration) and, in a controlled lab environment, demonstrated the ability to stop the production process."
    • Vulnerability Details: Must be clear and provide evidence.

Phase 6: Remediation

Remediation

  • This is NOT like IT . You cannot just "patch the PLC." Patches are often vendor-dependent, require a full plant shutdown, and may not even exist.
  • Focus on Compensating Controls:
    • Network Segmentation: This is the #1 remediation. Aggressively enforce the Purdue Model with firewalls. Block all traffic between IT and OT except for what is explicitly proxied and required.
    • Passive Monitoring: Deploy an OT-aware network monitoring solution (e.g., Nozomi, Dragos, Claroty) that can passively detect anomalous commands (e.g., "A 'STOP' command was sent from a new, unauthorized device").
    • Harden the Boundary: Secure all jump-boxes, Engineering Workstations, and HMIs. Implement MFA, change default passwords, and restrict access.
    • Vendor Patching: Create a plan to apply vendor-approved patches only during scheduled maintenance windows.
Back to all services

Ready to scope this engagement?

Tell us about your environment and objectives — we'll return a tailored scope, timeline, and quote within 24 hours.

Request a Free Scoping Call