testing-ics-ot-protocols

Testing ICS/OT Protocols

ICS/OT protocols were designed for reliability in isolated networks, not security on connected ones. Most have no authentication, no encryption, and no integrity checking. The danger is not that they are hard to exploit — it is that exploitation can have physical consequences, which is why safety constraints govern everything you do here.

When to Use

• Assessing SCADA networks or ICS environments during an authorized engagement
• Testing Modbus, DNP3, OPC UA, BACnet, EtherNet/IP, S7comm, or MQTT devices in scope
• Performing an ICS-specific penetration test with OT safety requirements
• Reviewing OT network segmentation and Purdue model compliance
• Evaluating remote access pathways into control system networks
• Inventorying ICS assets and identifying unauthenticated protocol exposure

When NOT to Use

• Standard IT network scanning — use enumerating-network-services
• HMI web interfaces tested as regular web apps — use testing-web-applications
• Writing ICS-specific detection rules — use engineering-detections

Safety-First Principles

OT pentesting is not IT pentesting with different ports. The rules of engagement are fundamentally different because the targets control physical processes.

Why active scanning is dangerous in OT:

• PLCs and RTUs run minimal embedded firmware. A malformed packet or unexpected connection can crash the device, halt a process, or cause it to fail to a dangerous state.
• Restarting a PLC may require physical access, and the process it controls may not tolerate interruption.
• Some devices interpret any TCP connection as a command session — connecting is acting.
• Nmap's default service probes have crashed PLCs in production environments.

Mandatory constraints:

1. Always have an OT engineer or plant operator present or on immediate call during active testing.
2. Obtain written authorization that explicitly covers ICS/OT assets — general network pentest scope does not imply OT scope.
3. Test in maintenance windows whenever possible. Never test safety-instrumented systems (SIS) without explicit, separate authorization.
4. Start with passive observation. Move to active enumeration only after the passive phase confirms device types and the OT engineer approves.
5. Distinguish read-only operations (reading registers, querying device info) from write operations (setting coils, writing registers, issuing commands). Write operations require per-device approval.
6. Have a rollback plan for every write operation. Know the expected state before you change anything.
7. Document every interaction with every device, including timestamps and the exact commands sent.