SCADA and PLC VAPT: A Risk-Aware Approach to OT Network Security
Industrial control systems are not ordinary IT endpoints. SCADA servers supervise processes, HMIs present operational information, engineering workstations provide access to control configurations, and PLCs execute logic
Industrial control systems are not ordinary IT endpoints. SCADA servers supervise processes, HMIs present operational information, engineering workstations provide access to control configurations, and PLCs execute logic that interacts with physical equipment.
This architecture changes how Vulnerability Assessment and Penetration Testing (VAPT) should be scoped and performed.
- Map the IT/OT Boundary
Start by identifying communication paths between corporate IT, industrial DMZs, SCADA networks, engineering workstations, remote access gateways, and PLC-related interfaces.
Validate network diagrams against actual connectivity where possible. Passive traffic analysis and configuration reviews can reveal unexpected paths without immediately probing sensitive devices.
The goal is to understand which systems are reachable and which network boundaries are expected to restrict access.
- Review Remote Access and Privileged Accounts
Remote maintenance introduces additional pathways into industrial environments. Examine VPN access, vendor accounts, engineering workstation permissions, privileged sessions, and restrictions on connections to production assets.
Testing should establish whether access is limited to the intended systems and functions. Shared credentials, persistent vendor access, and excessive privileges may increase exposure.
Authentication testing should be planned carefully to avoid account lockouts or loss of operational access.
- Assess Exposed Services and Firmware
Industrial devices may run older firmware or software because updates can require vendor validation and planned production downtime.
A version number alone does not prove that a device is exploitable. Assessment should consider the specific vulnerability, network exposure, configuration, available mitigations, and the asset's operational role.
Automated scanning should be used selectively. Legacy devices may react unpredictably to unexpected traffic, making passive methods and manual configuration reviews more appropriate.
- Evaluate Industrial Protocol Security
Protocols such as Modbus, DNP3, OPC UA, PROFINET, and Ethernet/IP may appear in industrial environments, depending on the equipment and architecture.
Their security characteristics differ. Assessment should examine the actual protocol implementation, configuration, permitted communication paths, and controls restricting access to sensitive interfaces.
Do not assume that every deployment of a protocol has the same weaknesses or security capabilities.
- Separate Discovery From Exploitation
A vulnerability assessment identifies potential weaknesses. Penetration testing attempts to validate selected weaknesses under controlled, authorized conditions.
For example, a review may identify an exposed industrial service. Further testing may examine whether access controls prevent unauthorized connections, provided the technique is safe for the target environment.
Unapproved control commands, PLC logic changes, device resets, and disruptive payloads should remain outside the scope. If a weakness cannot be safely validated, the report should explain the evidence available and the reason direct exploitation was not performed.
- Define Stop Conditions Before Testing
Before testing begins, document:
Authorized assets, network paths, and excluded components.
Permitted testing methods and approved maintenance windows.
Plant contacts and escalation procedures.
Indicators requiring an immediate pause.
Evidence handling and reporting requirements.
Unusual controller behavior, unexpected alarms, communication loss, or changes in production conditions may require testing to stop.
- Prioritize Findings by Operational Impact
CVSS can contribute to technical severity assessment where appropriate, but industrial risk also depends on asset criticality, exposure, process dependencies, and the consequences of unavailability.
A finding affecting a safety-critical controller may warrant a different response from an issue on an isolated monitoring server.
For organizations reviewing broader assurance priorities, governance, risk, and compliance services provide a relevant starting point.
Key takeaway: SCADA and PLC VAPT should validate meaningful weaknesses within clearly defined boundaries. In OT environments, the quality of the testing approach matters as much as the findings themselves.
Originally published by Dev.to Security. Aggregated on AIWithGhost for educational purposes — full credit and traffic to the original publisher.