ICS/SCADA common mistakes
ICS/SCADA · Understand the traps and how to avoid them.
Treating IT security controls (patch immediately, scan aggressively, enforce password rotation) as directly transferable to the ICS/SCADA environment, and answering questions as if availability were secondary to confidentiality.
Candidates arrive with IT or CompTIA-style training where CIA ordering and patching cadence are habits, so they default to IT answers on questions that hinge on process safety, uptime, and equipment certification.
What to do instead
For every control question, first ask what the control does to availability and to physical process safety. Learn the ICS priority order (availability, integrity, confidentiality) and be able to justify a slower patch or a passive-only sensor in terms of process risk.
Classifying a network as 'SCADA' or 'ICS' purely by protocol name (Modbus, DNP3, OPC) without considering Purdue level, zone/conduit boundaries, or the function of the asset.
Protocol names are the most visible labels in study material, so candidates use them as shortcuts instead of reasoning about architecture and data flow.
What to do instead
Practice mapping assets to Purdue levels (0-1 field devices, 2 supervisory, 3 operations, 3.5 DMZ, 4-5 enterprise) and identifying which conduits cross which boundaries. Answer architecture questions from the diagram's data flows, not from the protocol label alone.
Confusing the roles of TCP and UDP, or assuming Modbus/TCP, DNP3, or EtherNet/IP are inherently secure because they are 'industrial' protocols, and misidentifying which layer handles reliability versus addressing.
Candidates memorize 'TCP is reliable' without connecting it to specific ICS behaviors such as connection-oriented polling, retransmission masking loss of a device, or UDP-based real-time traffic.
What to do instead
Build a table mapping each common ICS protocol to its transport, default port, and security properties (no authentication, no encryption, no integrity checking). Be able to state what TCP guarantees and what it does not, including that TCP reliability can hide a dead field device from a naive monitor.
Mixing up IP addressing and subnetting mechanics: misidentifying network versus broadcast addresses, choosing the wrong CIDR mask for a host count, or confusing a MAC address with an IP address in a switching or ARP scenario.
Subnetting arithmetic is practiced rarely and under time pressure, and candidates guess at masks rather than computing them.
What to do instead
Drill the 2^n-2 host formula and the /24 to /30 mask boundaries until automatic. For each practice subnet, write out network, first host, last host, and broadcast. Rehearse ARP resolution step by step so MAC-versus-IP roles are unambiguous.
Describing hacking methodology out of order, or jumping straight to exploitation and skipping reconnaissance, enumeration, and maintaining access when a question asks for the sequence or for the purpose of a phase.
Exploitation is the most memorable and dramatic phase, and candidates conflate 'what an attacker does first' with 'what is most interesting to study'.
What to do instead
Memorize the kill-chain-style sequence (reconnaissance, weaponization, delivery, exploitation, installation, command and control, actions on objective) and the penetration-testing phases (scoping, information gathering, threat modeling, exploitation, post-exploitation, reporting). For each phase, be able to name one ICS-specific example, such as Shodan searches for exposed HMIs during reconnaissance.
Confusing vulnerability identification with exploitation, or treating a CVSS score as a complete risk rating without considering exploitability in the ICS context, compensating controls, and asset criticality.
CVSS base scores are numeric and easy to compare, so candidates treat the highest number as the answer and ignore environmental and process context.
What to do instead
Separate the concepts: a vulnerability is a weakness, an exploit is a technique, and risk combines likelihood and impact on the specific asset. Practice adjusting a base score for ICS realities (no internet exposure, compensating network segmentation, physical consequence of loss) and explain why a medium CVSS flaw on a safety controller can outrank a critical flaw on an isolated engineering workstation.
Treating a vulnerability scan as harmless by default in OT, or recommending active scanning of live controllers without acknowledging the risk of disrupting fragile devices.
Candidates equate 'scanning is passive reconnaissance' with 'scanning is safe', forgetting that some legacy PLCs and RTUs crash or hang under unexpected traffic.
What to do instead
Learn to distinguish passive monitoring, active scanning, and credentialed scanning, and state the conditions for each (change window, vendor approval, test environment, passive-first approach). When a question involves scanning production OT, answer with the risk-managed method rather than the fastest method.
Conflating standards and regulations: citing NIST CSF, IEC 62443, NERC CIP, ISO 27001, and ISA/IEC 62443-3-3 interchangeably, or claiming a framework is legally mandatory when it is voluntary guidance.
The names and acronyms overlap heavily and study guides list them together, so candidates memorize labels without the scope, enforceability, or subject they govern.
What to do instead
Build a comparison table with columns for issuer, scope, enforceability (regulation versus voluntary framework), and what it actually requires. Know that NERC CIP applies to bulk electric system assets in North America with mandatory enforceable standards, while NIST CSF and IEC 62443 are widely adopted frameworks with different structures (outcomes versus zones/conduits and security levels).
Designing a 'secure' ICS network that relies on a single control, such as a firewall at the IT/OT boundary, while ignoring the industrial DMZ, zone/conduit segmentation, least privilege for remote access, and the reality that flat OT networks are common.
Candidates default to the perimeter-firewall mental model from IT and underestimate how often OT networks are flat and how many direct paths exist from enterprise to controllers.
What to do instead
Practice drawing a defensible reference architecture: enterprise zone, industrial DMZ with jump hosts and replicated data, operations zone, and control zone, with stateful inspection and no direct enterprise-to-control traffic. For each proposed control, name the attack path it breaks and identify what it does not cover.
Assuming an air gap is absolute, or describing bridging mechanisms only in the abstract without naming concrete vectors such as removable media, dual-homed engineering laptops, cellular modems, and vendor remote support connections.
The phrase 'air gap' implies physical impossibility of remote access, so candidates stop reasoning about the human and maintenance pathways that actually cross it.
What to do instead
List the practical air-gap bypass vectors and the control for each: USB media control and scanning kiosks, disabling or monitoring dual-homed hosts, cellular and VPN egress review, and vendor access brokering. Be able to explain why Stuxnet-style propagation through removable media makes 'we are air gapped' a starting assumption to verify rather than a conclusion.
Confusing IDS with IPS and misplacing them: recommending an inline IPS where it could drop safety-critical traffic, or placing a passive sensor where it cannot see the traffic it needs to inspect.
The two acronyms differ by one letter and candidates focus on detection signatures rather than on deployment mode, placement, and failure behavior.
What to do instead
Anchor on deployment mode and failure semantics: IDS is passive and out-of-band, IPS is inline and can block, and an inline device that fails open or closed has direct process consequences. For placement questions, identify where the traffic actually traverses (span port or tap at the conduit between zones) and state what the sensor can and cannot see.
Choosing an inline prevention action for OT traffic without considering false positives, such as blocking on an anomalous Modbus write that is actually a legitimate operator command or a routine polling pattern.
Candidates equate 'more blocking' with 'more secure' and carry over IT expectations where a blocked packet is low-cost, ignoring that in OT a blocked legitimate command can halt a process or desynchronize a control loop.
What to do instead
For any IPS recommendation, state the tuning prerequisite, the failure mode if the rule misfires, and the fallback (alert-only mode during baseline, then graduated enforcement). Be able to justify why detection-only is often the correct first deployment in control zones.