SCADA and ICS Penetration Testing Guide India

Why ICS Pentest Is Different From IT Pentest

An operational technology environment runs physical processes. A misfired command can spin a pump dry, open a relay on a live transmission line, trip a turbine, contaminate a batch, or worse. Indian regulators (CEA for power, MoP&NG for oil and gas, the Ministry of Jal Shakti for water, MeitY and NCIIPC for critical infrastructure) treat ICS systems as safety-critical and expect a markedly different testing posture from typical IT VAPT.

OT devices were not designed with security in mind. PLCs, RTUs, HMIs and historians often run vendor real-time operating systems on hardware built for 15-year service life. Many do not support patching without recertification. Many use protocols where authentication and encryption are absent at the protocol level. Scanning behaviour considered routine on an IT network (an Nmap SYN scan, an OpenVAS run, a credential spray) can crash a 1990s-era PLC and stop production. Methodology must reflect this.

The Purdue Model: Mapping the Battlefield

The Purdue Enterprise Reference Architecture splits an industrial environment into six levels. Level 0 is the physical process (sensors, actuators). Level 1 is basic control (PLCs, RTUs). Level 2 is supervisory control (HMIs, SCADA servers). Level 3 is site-level operations (MES, historians). Level 3.5 is the IT/OT DMZ. Levels 4 and 5 are enterprise IT.

Pentest scope and testing techniques shift dramatically per level. At Levels 4 and 5 we use full IT pentest tooling. At Level 3.5 we focus on the DMZ jump hosts, data-diodes, and replication mechanisms that bridge IT and OT. At Levels 0 to 2 we shift almost entirely to passive observation, protocol-aware fuzzing in a lab, and configuration review with the operations team. Touching Level 0 or Level 1 live is almost always out of scope.

• Level 5 (Enterprise): standard IT pentest, AD, email, perimeter
• Level 4 (Business IT): same as above plus ERP, MES integration
• Level 3.5 (IT/OT DMZ): jump hosts, data-diodes, replication review
• Level 3 (Site Operations): historian, batch servers, asset inventory
• Level 2 (Supervisory): HMI, SCADA master, alarm system
• Level 1 (Basic Control): PLCs, RTUs, IEDs, mostly lab or read-only
• Level 0 (Process): sensors and actuators, never touched live

Safety-First Methodology in Practice

Our engagement starts with a Pre-Engagement Risk Workshop with the customer plant operations team, automation vendor (Siemens, ABB, Rockwell, Honeywell, Schneider, GE) where present, and the customer safety officer. We document the explicit list of devices in scope, the explicit list of devices out of scope, the abort criteria, the testing window (almost always off-peak, often planned outage), and the communications channel during the test (a dedicated bridge call with operations on standby).

From there, testing follows four passes: passive observation (full packet capture on SPAN ports, no active probing), active discovery (constrained Nmap with -sT, low-rate, no service probes), authenticated configuration review (PLC and HMI configurations exported by the operations team and reviewed offline), and protocol testing (executed in a vendor lab replica where possible, never live unless explicitly authorised in writing).

Tooling Allowed by Default

Wireshark with industrial dissectors, GRASSMARLIN for asset inventory, ICS-CERT YARA rules, plcscan, modpoll, modscan, Industrial Cyber-Toolkit, snap7-server for S7 simulation, and Conpot honeypot for safe protocol testing. Vendor diagnostic tools (TIA Portal in offline mode, Studio 5000, RSLogix, Unity Pro) are used for configuration review only, never write actions.

Tooling Banned by Default

Aggressive Nmap scans (-sS at high rate, -A, -O), Nessus default policies, OpenVAS unfiltered, Metasploit modules that target ICS protocols, fuzzers run live, credential spray against any Level 1 or 2 device. Each of these is documented as a risk and only used in lab settings or with explicit signed authorisation.

Industrial Protocol Testing: Modbus, DNP3, OPC UA, S7Comm

Industrial protocols were designed in eras where physical isolation was assumed. Authentication and encryption were not in the design brief. That assumption holds less and less every year as plants converge IT and OT.

Modbus TCP (port 502) is read with modpoll or pymodbus. Coils, discrete inputs, holding registers, and input registers can be read with no credentials. Write commands (function codes 5, 6, 15, 16) can flip outputs and change setpoints. Modbus testing in production is reads only, in lab only for writes.

DNP3 (port 20000) is used heavily in Indian power distribution and water utilities. Without Secure Authentication (DNP3-SA), commands are unauthenticated. Replay attacks, cold restart commands (function code 13), and unsolicited message injection are documented standard tests in lab.

OPC UA is the modern standard with built-in security profiles. We test that the security policy is set to Basic256Sha256 or Aes256_Sha256_RsaPss, not None, and that certificate validation is enforced.

S7Comm (Siemens, port 102) is tested with snap7. Stop CPU, start CPU, write data blocks: all unauthenticated by default on S7-300/400, mitigated only by the optional access-protection password and only if the engineering station enforces it.

IEC 62443 Mapping and Indian Regulatory Context

IEC 62443 is the dominant international standard for ICS security. Our reports map every finding to the relevant IEC 62443-2-4 (service provider requirements), 62443-3-3 (system security requirements) and 62443-4-1 / 4-2 (component requirements) controls.

For Indian critical-infrastructure operators, we additionally map to NCIIPC sector-specific guidelines, CEA Cyber Security in Power Sector Guidelines 2021, the Petroleum and Natural Gas Regulatory Board (PNGRB) cyber security regulations for downstream operators, and the DPDP Act Section 8 where personal data crosses into OT systems (uncommon, but possible in modern SCADA HMI authentication).

ICS Red Team and Tabletop Exercises

Beyond technical VAPT, we also run ICS-focused tabletop exercises and constrained red-team engagements. A tabletop walks the joint IT and OT team through a realistic scenario (ransomware on Level 3 spreading toward the historian, insider threat at engineering workstation, supplier supply-chain compromise on a PLC firmware update) and pressure-tests the response plan against IEC 62443 incident response controls.

Where authorised, a constrained red team operates only at Levels 3 and above, with hard rules against any write action below Level 3. The objective is to test detection and response, not to demonstrate plant disruption. Plant disruption is for the lab. Detection is what matters in production.

What an ICS Pentest Report From Codesecure Looks Like

Each report contains an executive summary with plant safety posture in plain language, a complete asset inventory (often the most-cited section by operations teams, who often discover the report is more accurate than their CMDB), prioritised findings with safety classification (Safety Impacting / Plant Impacting / IT Only), CVSS v3.1 scoring with environmental modifiers tuned for OT, IEC 62443 control mapping, and concrete remediation steps the automation vendor and IT team can divide between them.

Free re-test within 90 days is part of every engagement so plant fixes can be validated before the next NCIIPC or audit cycle, without needing a separate purchase order.