SCADA and ICS Security Testing

The SCADA Security Challenge

SCADA and ICS environments present security challenges that have no direct parallel in conventional IT infrastructure. The systems controlling physical processes in utilities, water treatment, manufacturing, oil and gas, and transportation were designed at a time when network connectivity was minimal and security was an afterthought. Many of these systems run operating systems that are years or decades past their end of support date, with no vendor-provided patch path and no ability to install modern endpoint security tools without disrupting operations. Patching a Windows XP-based HMI controlling a live production line is a fundamentally different proposition from patching a corporate workstation.

The protocols native to ICS environments, including Modbus, DNP3, OPC-DA and OPC-UA, Profibus, and EtherNet/IP, were designed for reliability and determinism, not security. Most carry no authentication whatsoever: any device on the network that speaks the right protocol can issue commands to a PLC. The assumption that the control network was physically isolated from the outside world made this acceptable for decades. That assumption has collapsed. IT/OT convergence, driven by the legitimate need for operational data visibility, remote support capabilities, and enterprise system integration, has eliminated the air gap in the vast majority of industrial environments, often without a corresponding security architecture review.

The consequences of a successful attack on a SCADA environment are categorically different from a conventional IT breach. A comprehensive industrial security program typically pairs SCADA testing with an OT network assessment covering architecture, segmentation, and IT/OT boundary controls. Organizations with connected devices interacting with industrial systems may also need an IoT security assessment to evaluate firmware and device communications security. Ransomware that encrypts servers causes data loss and business disruption. Ransomware or malware that reaches a control network can cause physical damage to equipment, environmental harm, injury to workers, and public safety incidents. NERC CIP standards for the electric sector, NIST SP 800-82 (Guide to ICS Security), and IEC 62443 (Industrial Cybersecurity) all establish requirements that recognize this distinct risk profile. NYCF's assessments are aligned to these frameworks.

NYCF's SCADA Assessment Methodology

The first principle of any SCADA or ICS security assessment is that the assessment itself must not disrupt production. An active scan against an ICS network can trigger unexpected behavior in PLCs and other devices that are not designed to handle the traffic volumes or unexpected protocol interactions generated by standard security scanning tools. NYCF's SCADA assessment methodology is built around passive network monitoring as the primary discovery technique: we place passive sensors on span ports or network taps to capture and analyze traffic without injecting any packets into the control network.

From passive traffic capture, NYCF builds a complete asset inventory of every device communicating on the control network, including devices that may not appear in any existing configuration management database. We identify every communication relationship between devices, map which PLCs are receiving commands from which HMIs, identify any connections between the control network and enterprise IT systems, and flag any unexpected communication patterns that may indicate unauthorized access, misconfiguration, or existing compromise. Architecture review examines the network design against best practices for ICS segmentation, evaluating the effectiveness of demilitarized zones between IT and OT networks, the security of historian servers that bridge both environments, and the configuration of firewalls and data diodes at network boundaries.

Engineering workstations and HMI systems receive a dedicated security review. These systems are frequently the weak point in ICS security: they run general-purpose operating systems, are connected to both the control network and sometimes the enterprise network, and are used by operators who may not have security training. Remote access infrastructure, including vendor accounts used for equipment maintenance, is audited for authentication strength, access controls, and session monitoring. Where vendor remote access is persistent rather than session-based, this represents a significant risk that NYCF specifically identifies and documents. Firmware versions on PLCs, RTUs, and network devices are checked against known vulnerability databases, and where red team simulation is feasible in an isolated test environment, NYCF can demonstrate the practical exploitability of identified findings.

SCADA Security for Legal and Regulatory Proceedings

When a SCADA or ICS environment is breached, the resulting litigation, insurance claims, and regulatory proceedings require forensic documentation that meets legal standards of evidence. NYCF's post-incident forensic examination of ICS environments follows the same chain-of-custody protocols used in our digital forensics practice: every piece of evidence is acquired with write protection where feasible, hash-verified at acquisition, and documented from intake through report delivery. This documentation is essential when the incident leads to insurance claims under cyber liability policies that require proof of breach scope, causation, and loss quantification.

For organizations subject to NERC CIP reliability standards, a cybersecurity incident affecting bulk electric system assets triggers mandatory notification and documentation obligations. NYCF's forensic documentation supports the incident reports required by NERC CIP-008 (Incident Reporting and Response Planning) and provides the technical factual record that regulators need to assess the incident. Our examiners have experience presenting technical findings to non-technical audiences, including regulatory bodies and court proceedings, in terms that are accurate without requiring specialized knowledge to understand.

ICS security failures increasingly generate civil litigation, particularly where equipment damage, production losses, or safety incidents result from a cyber intrusion. NYCF's expert witnesses can address the technical circumstances of an ICS breach, including the specific vulnerabilities exploited, whether the operator's security posture met applicable industry standards, and the causal relationship between identified security failures and the losses claimed. For insurance disputes where carriers challenge the scope of a cyber event affecting OT systems, NYCF provides technically grounded expert analysis that supports the policyholder's position in coverage proceedings.

ICS Penetration Testing

Passive assessment identifies what vulnerabilities exist. Penetration testing answers the question that matters most to executives and legal teams: can those vulnerabilities actually be exploited, and what can an attacker do once they are inside the control network? NYCF conducts active ICS penetration testing under controlled conditions designed to produce definitive answers without putting live production systems at risk.

The central challenge of ICS penetration testing is that the devices on a control network cannot absorb the same testing activity that IT systems can. A scan that would be routine on a corporate network can crash a PLC mid-cycle, causing an uncontrolled process shutdown with real physical consequences. For this reason, NYCF conducts active ICS penetration testing against a replicated test environment wherever possible. Digital twin environments, which mirror the target system's architecture and device configuration in an isolated lab, allow NYCF analysts to conduct controlled exploitation of identified vulnerabilities, demonstrate their practical impact, and test proposed mitigations, all without touching the live production environment. Where a digital twin is not feasible, NYCF performs active testing against isolated components or segments that can be taken offline for the test window, coordinating with operations teams to schedule testing during planned maintenance windows.

IT/OT boundary penetration testing specifically evaluates the controls at the point where enterprise IT networks connect to operational technology environments. This boundary is consistently the highest-value target for attackers seeking to reach ICS systems: an attacker who compromises an IT system with a path to the OT network does not need to break through the physical controls protecting the facility. NYCF tests the effectiveness of DMZ configurations, firewall rule sets, jump server access controls, and historian server security at the IT/OT boundary, attempting to traverse from a simulated IT compromise to meaningful access within the OT environment. Findings from this testing directly address the attack path that ransomware groups have used most successfully against industrial targets in recent years.

Protocol-specific exploitation testing addresses the authentication and authorization gaps inherent in industrial protocols. Modbus TCP carries no authentication: any device on the network that can reach a Modbus server can issue read and write commands to it. NYCF tests whether this protocol's lack of authentication is exposed on production networks by attempting to issue commands to Modbus-enabled devices from simulated attacker positions. DNP3, used extensively in electric utilities and water systems, has historically lacked authentication in deployed implementations even though the standard defines authentication extensions. NYCF verifies whether DNP3 authentication is actually implemented and tests for known weaknesses in DNP3 implementations including malformed packet handling and command injection. OPC UA includes security features including authentication and encryption, but these features require correct configuration to be effective. NYCF tests OPC UA deployments for certificate validation failures, authentication bypass conditions, and access control enforcement across the available service endpoints.

Physical-to-cyber attack path testing evaluates whether physical access to ICS components provides escalated logical access to control systems. Engineering workstations that boot from USB, PLCs with accessible serial ports, and panel PCs with unlocked BIOS settings all represent physical access points that an attacker with facility access could exploit. NYCF tests these physical attack paths as part of comprehensive ICS red team exercises, which simulate a realistic attacker with a defined level of physical and logical access attempting to achieve a specific operational impact objective. Red team exercises produce findings that go beyond individual vulnerability identification to show the complete attack chain from initial access through to the attacker's goal, whether that is data theft, ransomware deployment, or direct manipulation of industrial processes.