PCN PEP common mistakes
PCN PEP · Understand the traps and how to avoid them.
Treating the Purdue model as a strict security boundary and asserting that Level 3 to Level 2 traffic must always be blocked outright, rather than describing it as a zone/conduit reference model that requires a defined, controlled conduit.
Candidates memorize the layer diagram and equate 'lower level' with 'must be isolated', missing that the model is a functional reference and that ISA/IEC 62443 zones and conduits govern what crossing is permitted and how it is controlled.
What to do instead
For any Purdue question, state the functional role of each level, then answer in terms of zones and conduits: what traffic crosses, through which controlled interface, with which inspection and logging. Distinguish 'no direct routing' from 'no communication at all'.
Describing the DMZ as a single firewall between IT and OT, or placing the historian or remote-access jump host inside the IT network instead of in an industrial DMZ with separate inner and outer boundaries.
Candidates carry over enterprise edge-firewall mental models and forget that the reference architecture requires a demilitarized zone terminating both the IT-side and OT-side connections, with no direct path from enterprise to control.
What to do instead
Draw the two-boundary model explicitly: enterprise zone, outer firewall, IDMZ (replicated historian, patch/AV staging, jump host, reverse proxy), inner firewall, OT zones. State that all IT-to-OT data flows terminate in the IDMZ and that no protocol passes end-to-end.
Recommending an active-scanning vulnerability tool or a default IT Nmap sweep across a live control network as the first step of assessment.
Candidates apply enterprise assessment habits and underestimate that active probing can disrupt fragile legacy devices, safety instrumented systems, and deterministic protocols; they also forget that many OT devices respond poorly to malformed or unexpected packets.
What to do instead
Default to passive monitoring, configuration review, and vendor documentation first; if active testing is required, scope it to a change window with owner approval, exclude safety and critical controllers, use protocol-aware tools with conservative timing, and have a rollback/abort criterion documented.
Answering every segmentation question with 'install a firewall' without addressing flat-network remediation inside a zone, such as VLANs, ACLs on Layer 3 switches, managed conduits, and host-based controls on engineering workstations.
Candidates reduce defense in depth to perimeter devices and skip the internal segmentation that limits lateral movement once an attacker is inside a zone; they also overlook that many OT switches support ACLs and that VLANs alone are not a security boundary without filtering.
What to do instead
Structure answers in layers: zone definition, conduit control at boundaries, intra-zone segregation of safety/critical controllers, host hardening, and monitoring. Note that VLANs provide logical grouping but require inter-VLAN ACLs or firewalls to enforce policy.
Confusing IT incident response sequence with OT incident response, e.g., isolating or rebooting a controller or shutting down a process as an early containment step without considering physical consequences.
Candidates apply the enterprise 'contain, eradicate, recover' reflex and forget that containment actions in OT can stop production, defeat safety interlocks, or cause unsafe physical states; they also miss that the operations team owns process safety decisions.
What to do instead
In OT IR answers, put safety and process continuity first: notify operations, decide containment with the plant owner, prefer network-level isolation and monitoring over device shutdown, preserve forensic evidence from the historian and network taps, and define recovery with validated backups and staged return to service.
Treating the control network as exempt from patch and vulnerability management because 'you cannot patch OT', rather than describing a risk-ranked, vendor-validated, staged patch and compensating-control program.
Candidates hear the common 'never patch a PLC' folklore and answer with a blanket exemption, missing the exam's emphasis on documented compensating controls, vendor advisories, and lifecycle planning when patching is deferred.
What to do instead
Answer with a lifecycle process: asset inventory and firmware baseline, vendor advisory monitoring, risk ranking, test-lab validation, maintenance-window deployment, rollback plan, and documented compensating controls (segmentation, ACLs, monitoring) for anything deferred, with a review cadence.
Naming a protocol by port or transport alone (e.g., 'Modbus is TCP/502, so it is secure because it is on a closed network') without describing that Modbus/TCP, DNP3, and similar protocols lack authentication and integrity and therefore need compensating controls.
Candidates memorize port numbers as the whole answer and do not connect the protocol's missing security features to the architectural and monitoring controls that must compensate for them.
What to do instead
For each protocol question, state function, transport, and security properties: no native authentication or encryption, cleartext, often no integrity check. Then name the compensating controls: zone/conduit restriction, deep-packet inspection at the conduit, allow-listing of function codes, and anomaly monitoring of write operations.
Assuming the firewall or IDS sees all OT traffic, ignoring that most industrial protocols are east-west between controllers, HMIs, and I/O, and that unmanaged switches, serial links, and cellular links create visibility gaps.
Candidates map enterprise north-south monitoring onto OT, where the majority of critical traffic never crosses the perimeter; they also overlook that span ports may not exist on legacy switches and that encrypted or proprietary protocols defeat signature inspection.
What to do instead
Answer with a visibility architecture: network TAPs and SPAN at zone boundaries and critical segments, passive OT-aware monitoring for asset discovery and baselining, log collection from controllers and HMIs where supported, and explicit acknowledgement of blind spots with compensating physical or procedural controls.
Treating remote vendor access as an acceptable exception handled by a shared account and a VPN concentrator, instead of a brokered, session-recorded, time-bound, least-privilege access path through the IDMZ.
Candidates underestimate third-party maintenance access as a leading intrusion vector and default to 'VPN is fine', missing requirements for approval workflow, MFA, session logging, jump hosts, and immediate revocation.
What to do instead
Describe the control set: vendor access only through an IDMZ jump host or brokered remote-access service, per-session approval, MFA, least-privilege accounts, full session recording, time-boxed windows, and post-session review. Note that shared accounts break accountability and are a finding.
Answering risk-assessment questions with a generic IT CIA ranking, placing confidentiality first, rather than prioritizing safety, availability, and integrity for OT and mapping consequences to physical process impact.
Candidates carry the enterprise security triad ordering into OT, where loss of view or loss of control, safety consequences, and environmental impact dominate; they also skip the consequence-first method used in OT risk assessment.
What to do instead
Use an OT-appropriate method: identify the physical process and safety consequence first, then assess availability and integrity impact, then confidentiality. Reference recognized approaches (consequence-driven or threat-informed analysis, ISA/IEC 62443 risk assessment) and tie each finding to a documented risk acceptance or mitigation decision with an owner.