IEC 62443-3-2 Vulnerabilities

A vulnerability is a flaw or weakness in a system’s design, implementation or operation that could be exploited to compromise the system. Part 3-2 requires identification of known vulnerabilities (including access points) for each zone or conduit in the detailed assessment (ZCR 5.2).

Vulnerability vs cyber risk

Vulnerability analysis is not cyber risk analysis. Not every vulnerability represents material risk to the OT environment, and exploiting a vulnerability does not always produce a consequence that matters to the organisation. Vulnerability work finds and classifies weaknesses; risk assessment adds threat realism and consequence/impact (risk equation).

Assessment results feed the detailed risk assessment as an input (ZCR 5.2 and ZCR 5.13 supporting evidence) — they do not replace it.

Classes of vulnerability

IACS weaknesses commonly fall into the classes below. Use them as a discovery checklist when building the ZCR 5.2 list.

Policy and procedures

Inadequate security policy for the IACS
No formal IACS security training and awareness program
Absent or deficient IACS equipment implementation guidelines
Lack of administrative mechanisms for security policy enforcement
Inadequate review of effectiveness of IACS security controls
No IACS-specific contingency plan
Lack of configuration management policy
Lack of adequate access control policy
Inadequate incident detection and response plan and procedures
Lack of redundancy for critical components

Architecture and design

Inadequate incorporation of security
Insecure architectures allowed to evolve or expand
No security perimeter defined
Control networks used for non-control traffic
Control-network services not kept within the control network
Inadequate collection of event data history

Configuration and maintenance

Hardware, firmware and software not under configuration management
OS and vendor patches delayed long after vulnerabilities are known
Security patches not maintained, or vendor declines to patch
Inadequate testing of security changes
Poor remote access controls
Poor configurations; critical configurations not stored or backed up
Data unprotected on portable devices
Password generation, use and protection not in accordance with policy
Inadequate access controls; improper data linking
Malware protection missing, outdated, or installed without sufficient testing
Intrusion detection/prevention not installed; logs not maintained

Physical

Unauthorised personnel have physical access to equipment
Radio-frequency or EMP exposure
Lack of backup power; loss of environmental control
Unsecured physical ports

Software development

Improper data validation
Installed security capabilities not enabled
Inadequate authentication, privileges and access control in software

Communication and network

Flow control not employed
Improperly configured or absent firewalls
Well-documented protocols used in plain text
Authentication of users, data or devices lacking
Insecure IACS protocols (for example Modbus without integrity protection)
No integrity checks on communications
Weak wireless authentication or unprotected links between clients and access points

Discovery questions by layer

When listing vulnerabilities for a zone or conduit (ZCR 5.2), walk the path an attacker or malware would take: first the access points, then the internal LAN(s) inside the zone, then the end devices. The prompts below turn that path into workshop questions — use them alongside the classes above and any prior vulnerability assessments.

Access points

What vulnerabilities exist that would allow an attacker or malware to pass through or circumvent access controls at access points?

Firewall / DMZ rules that are overly permissive or poorly documented
Remote-access paths (VPN, jump hosts, vendor portals) with weak authentication or shared accounts
Wireless access points bridging into the zone without adequate authentication or segmentation
USB / portable media introduction points and maintenance laptop docking paths
Physical ports or console access that bypass logical perimeter controls

Internal networks (LAN within the zone)

What vulnerabilities exist that would allow an attacker or malware to compromise the LAN(s) within the zone?

Flat L2/L3 design with little or no east–west filtering between hosts
Insecure or plaintext industrial protocols on shared segments
Misconfigured VLANs, trunks or switch ACLs
Lack of monitoring / detection on OT segments (no IDS, sparse logging)
Broadcast or storm conditions that can disrupt real-time traffic

End devices

What vulnerabilities exist at the end devices (for example computers, industrial controllers) that would allow an attacker or malware to compromise the device?

Unpatched OS, firmware or application software
Default or shared credentials; weak or disabled authentication
Unnecessary services and open ports; missing hardening
Controllers or HMIs with known product vulnerabilities and limited compensating controls
Absent or outdated malware protection where it can safely be used

Teaching note: Threats succeed by exploiting one or more of these layers. Recording vulnerabilities by access point, LAN and end device makes the later threat-vector and countermeasure discussion concrete (Threats, Bowtie Diagrams).

IACS cybersecurity vulnerability assessment

An IACS cybersecurity vulnerability assessment defines, identifies and classifies security vulnerabilities in an IACS and its related network infrastructure. It evaluates design, implementation, configuration, operation and management; judges adequacy of security measures; and identifies known component vulnerabilities.

It does not by itself determine consequence or organisational risk ranking.

Four types (least to most invasive)

Type	What it does	Typical techniques
High-level (gap)	Compare practices with standards and peer norms	Interviews, walk-throughs, drawing/config review, policy review, questionnaires
Passive	Discover network and issues without active probing	Drawing review, walk-through, traffic capture/analysis, ARP tables, device data, config review, vulnerability database research
Active	Invasive discovery of devices and weaknesses	Network scanners (for example Nmap, ping/ARP/IP sweeps), vulnerability scanners (for example OpenVAS, Nessus, Nexpose)
Penetration test	Extreme invasion — exploit and attempt unauthorised access	Attacker perspective; exploit known/unknown weaknesses; validate countermeasures

OT caution: Active scans and penetration tests can disrupt real-time control. Authorise methods explicitly, prefer offline or maintenance windows, and escalate invasiveness only when the risk of testing is accepted. See network discovery and scanning for defender vs attacker use of Nmap-class tools and safer IACS practices.

Conducting a high-level assessment

Identify benchmark standards.
Gather information (drawings, walk-throughs, interviews, configs).
Compare performance with the benchmarks.
Document and report results.

Vulnerability Assessment Report

The Vulnerability Assessment Report records what was examined and what was found so results can feed ZCR 5.2 and be archived with the detailed assessment (ZCR 5.13). See also the document catalogue on Documentation.

Include at least:

Scope of the assessment
Information on the as-found system architecture
Assessment details: dates, location, participants and the vulnerability process used
A prioritized summary of findings, covering:
- Discovered cyber assets
- Policy and procedural vulnerabilities
- Architecture and design vulnerabilities
- Configuration and maintenance vulnerabilities
- Physical vulnerabilities
- Software vulnerabilities
- Communication and network vulnerabilities

Those finding classes align with the discovery questions by layer and the vulnerability classes above. Protect the report — it often lists weaknesses an attacker would value.

Assessment tools (including CSET)

Common supports include custom spreadsheets/databases and structured tools such as CSET (Cybersecurity Evaluation Tool from CISA / formerly DHS).

CSET strengths

Repeatable and systematic
Compares practice against selected industry standards and regulations
Facilitates SME discussion across disciplines
Flags potential vulnerabilities in design and security policies
Offers guidance toward mitigations

CSET limitations

One component of analysis — not a full network architecture or hardware/software review
More component-oriented than whole-system focused
Does not create a detailed Part 3-2 risk assessment by itself
Not a substitute for in-depth analysis
Produces sensitive reports that must be protected
A security program based on CSET alone is incomplete and not IEC 62443-3-2 compliant by itself

Typical CSET process

Form a team
Add assessment information
Select mode and standards
Determine the security level
Build a network diagram
Answer questions
Analyse results

Reference standards selectable in CSET commonly include ISA-62443-4-1, NIST CSF, NERC CIP, NIST SP 800-82, NIST SP 800-53, DoD Instruction 8500.2, NRC RG 5.71, FIPS 199 and CFATS RBPS guidance (tool version dependent).