Which of the Critical Controls Includes Performing a Risk Assessment in the ICS/OT Network?
Introduction
Industrial Control Systems (ICS) and Operational Technology (OT) networks are the backbone of modern infrastructure—power plants, water systems, oil refineries, chemical plants, and manufacturing operations. Yet these environments are increasingly targeted by cyberattacks, from ransomware to nation-state intrusions.
To defend against these threats, organizations turn to critical cybersecurity controls—structured best practices that reduce risk, strengthen defenses, and ensure continuity of operations.
But here’s the key question:
Which of the Critical Controls addresses performing a risk assessment of a known issue in the ICS/OT environment that could be exploited by an attacker?
The answer lies in the Center for Internet Security (CIS) Controls and NIST SP 800-82, specifically within Asset Management, Vulnerability Management, and Risk Management practices.
Let’s break it down.
Understanding ICS/OT Risk Assessments
A risk assessment is the process of identifying, analyzing, and evaluating vulnerabilities, threats, and impacts to determine the level of risk to an asset or system.
In ICS/OT, risk assessments must account for:
- Legacy systems with no patches
- Flat networks with high trust
- Critical processes that can’t be interrupted
- Safety, human life, and environmental consequences
Answer: CIS Critical Control 6 — Access Management & Control AND Control 7 — Continuous Vulnerability Management
The CIS Critical Security Controls, especially Control 7 (Vulnerability Management) and Control 4/6/8, explicitly involve the steps required to perform risk assessments based on known vulnerabilities in OT systems.
Let’s focus on the most relevant:
✅ CIS Control 7: Continuous Vulnerability Management
What it is:
Control 7 requires organizations to continuously acquire, assess, and take action on information regarding new and existing vulnerabilities, especially those that could be exploited by attackers.
This is the control that covers performing a risk assessment of known vulnerabilities in ICS/OT networks.
Key Activities:
- Maintain asset inventory and software list
- Use vulnerability scanning tools tailored for OT (non-intrusive scanning)
- Map known vulnerabilities (CVEs) to specific devices
- Prioritize based on exploitability and criticality
- Take risk-based remediation action (patch, isolate, monitor)
ICS/OT-Specific Considerations:
- Use passive detection tools (e.g., Nozomi, Claroty, Dragos) to avoid disrupting control devices.
- Leverage vendor-provided security advisories (e.g., Rockwell Automation, Siemens, Schneider).
- Risk assessments must balance cybersecurity risk vs operational risk (e.g., downtime, safety).
✅ NIST SP 800-82 + NIST CSF (Cybersecurity Framework)
NIST SP 800-82 Revision 3 is the authoritative guide on securing ICS environments. It emphasizes risk assessment as part of the Identify function in the NIST Cybersecurity Framework (CSF).
Key NIST Categories:
| NIST CSF Category | Relevance |
|---|---|
| ID.RA-1 | Asset vulnerabilities are identified and documented |
| ID.RA-2 | Threats are identified and documented |
| ID.RA-3 | Potential impacts are identified |
| ID.RA-4 | Risk tolerance is determined |
| ID.RA-5 | Risk response is prioritized and tracked |
So, the risk assessment of known vulnerabilities aligns with:
🔍 ID.RA-1 to ID.RA-5 in the Identify Function of NIST CSF
How the Risk Assessment Process Works in ICS/OT
Step 1: Identify Known Vulnerabilities
- Use vulnerability databases (NVD, CISA ICS Advisories)
- Monitor vendor advisories (e.g., Siemens CERT)
- Collect asset details (firmware version, protocol, OS)
Step 2: Determine Asset Criticality
- Is the asset controlling a critical safety loop?
- Does downtime result in production loss or environmental impact?
- Is it connected to other sensitive assets?
Step 3: Assess Exploitability
- Is the vulnerability remotely exploitable?
- Is it already being exploited in the wild?
- Are there published proof-of-concepts (PoCs)?
Step 4: Calculate Risk
Risk=Likelihood×Impact\text{Risk} = \text{Likelihood} \times \text{Impact}Risk=Likelihood×Impact
Use scoring frameworks like:
- CVSS (Common Vulnerability Scoring System)
- MITRE ATT&CK for ICS
- Custom OT risk matrix (e.g., SIL, HAZOP integration)
Step 5: Prioritize and Act
- Apply patches if available
- Isolate vulnerable assets (network segmentation)
- Increase monitoring/logging
- Implement compensating controls (e.g., firewall rules)
Real-World Example: ICS Risk Assessment in Action
Scenario:
A Rockwell Automation PLC running outdated firmware has a known vulnerability (CVE-2021-22681) that allows unauthenticated remote access.
Actions Taken:
- Identify the vulnerable firmware version using passive OT asset discovery.
- Assess that this PLC controls a critical compressor in a chemical plant.
- Determine that exploitation is possible over the engineering workstation subnet.
- Calculate Risk as high due to exploitability + high consequence of failure.
- Mitigate by:
- Blocking engineering port access from all but one workstation
- Scheduling firmware update during next shutdown window
- Logging all connections to the PLC IP for forensic readiness
Why This Matters in ICS/OT
Traditional IT vulnerability scanning tools are often too aggressive for fragile ICS systems. That’s why OT risk assessments require:
- Non-intrusive techniques
- Human-in-the-loop decision making
- Alignment with process safety
A failed or misconfigured scan can crash a PLC or HMI, bringing down production or safety systems.
Other Critical Controls That Support Risk Assessment
| Control | Description | OT Relevance |
|---|---|---|
| Control 1: Inventory of Assets | Know what’s in your network | Foundation for risk analysis |
| Control 2: Software Inventory | Know what versions and software run | Identify where vulnerabilities exist |
| Control 4: Secure Configuration | Harden systems to reduce attack surface | Baseline comparison |
| Control 10: Logging & Monitoring | Detect signs of exploitation | Validate risk exposure |
| Control 11: Incident Response | Prepare for risk realization | Evaluate consequence side of risk |
Best Practices for OT Risk Assessments
✅ Build a detailed asset inventory with firmware and protocol data
✅ Use passive tools to avoid system disruption
✅ Regularly review vendor security advisories and CISA alerts
✅ Train ICS engineers on basic cyber risk scoring
✅ Use an OT-specific risk matrix that accounts for both process and IT risk
✅ Document and communicate risk findings to both OT and IT teams
Conclusion
In the context of ICS and OT security, CIS Control 7 (Vulnerability Management) and the Identify Function of the NIST CSF (ID.RA) are the most directly related to performing a risk assessment of known issues that could be exploited.
These assessments are not optional—they are a critical part of securing your plant, process, and people.
🎯 If you don’t know your vulnerabilities, attackers will find them for you.
A mature risk assessment process in OT not only prevents attacks, but also supports compliance, asset management, and operational resilience.
FAQs
Q1: Is vulnerability scanning safe in ICS environments?
Not always. Use passive scanning or manual validation for ICS/OT assets to avoid disrupting operations.
Q2: How often should OT risk assessments be performed?
At minimum:
- Quarterly for high-risk systems
- After any major firmware/software update
- Following any known vulnerability disclosure
Q3: What tools are recommended for OT risk assessments?
- Claroty, Dragos, Nozomi (for passive asset & vulnerability mapping)
- CISA ICS advisories
- MITRE ATT&CK for ICS framework
