In cyber security management, resources - time, budget and people - are always limited. Faced with thousands of potential vulnerabilities and a constant stream of alerts, the key to effectiveness is not to try to fix everything at once, but to prioritize intelligently. We need to focus our efforts where they will have the greatest effect in reducing real risk to the organization. In the IT world, for years the main tool for this prioritization has been the CVSS (Common Vulnerability Scoring System) assessment.
The problem is that blindly transferring this tool to the world of operational technology (OT) is not only inefficient, but downright dangerous. It leads to a situation in which security teams waste valuable energy patching irrelevant systems while ignoring the ticking time bombs at the heart of the production process. This is because CVSS, while useful, measures only one, technical dimension of the threat and completely ignores what is most important in OT: the operational context and potential consequences in the physical world.
Mature risk assessment in OT requires a fundamental shift in thinking. We need to move away from simple ranking based on numbers and implement a process that combines the technical expertise of IT professionals with the invaluable process knowledge of OT engineers. The goal is not to create a list of vulnerabilities, but to map the real risks to the continuity and security of our production.
Shortcuts
- In OT security, why is trying to protect everything at once the easiest way to fail?
- What is a CVSS assessment and why can it be a dangerous trap in the OT world?
Why, in OT security, is trying to protect everything at once the easiest path to failure?
In any complex industrial system, there are thousands of potential points of failure and vulnerability. Trying to address them all at once, without prioritizing them, leads to paralysis and wasted resources. A team that tries to do everything ends up doing nothing right. Initiatives get bogged down, and the most important problems are left unresolved.
In OT security, this principle is even more pronounced. Limited service windows, the risks involved in making changes, and the scarcity of specialized expertise make our “repair resources” extremely valuable. We must use them with surgical precision, focusing only on those wounds that realistically threaten a patient’s life.
The “we want to secure everything 100%” approach is not only unrealistic, but also ineffective. The true art of security management lies not in achieving a mythical state of absolute protection, but in an informed and data-driven decision-making process that allocates scarce resources in a way that yields maximum risk reduction for key business objectives.
📚 Read the complete guide: SOC: Security Operations Center - czym jest, jak działa, jak wybrać
What is a CVSS assessment and why can it be a dangerous trap in the OT world?
CVSS, or Common Vulnerability Scoring System, is an open industry standard for assessing the technical severity of security vulnerabilities. It assigns each vulnerability a rating on a scale of 0 to 10 to reflect its potential “dangerousness.” The rating is calculated based on a number of metrics, such as the attack vector (can it be exploited remotely?), the complexity of the attack (how difficult is it to exploit?) and its impact on the three pillars of IT security: Confidentiality, Integrity and Availability.
In the IT world, CVSS is an extremely useful pre-screening tool. A vulnerability with a 9.8 rating on a publicly accessible web server will almost always have a high priority. The pitfall is that in OT, the same pillars (Confidentiality, Integrity, Availability) are given completely different weights, and a fourth, most important element is added to the equation, which CVSS does not measure at all: Physical Security (Safety).
Relying solely on CVSS leads to absurdity. A system can give low priority to a vulnerability that has little impact on data availability, but allows a command to be sent to a PLC that could cause physical damage to the machine. Conversely, it can give the highest priority to a vulnerability that allows the theft of data from a system that does not process any sensitive information at all. CVSS without context is like a map without scale - it shows the shape of the terrain, but tells us nothing about its real dimensions.
How can a vulnerability with a low CVSS cause a disaster and one with a “critical” one be insignificant?
Let’s consider two scenarios. Scenario One: There is an HMI station running on the network that is isolated in a separate network segment and is only used to visualize data from a non-critical process. It is running on an old operating system that has a known critical RCE (remote code execution) vulnerability with a CVSS rating of 9.8. From the scanner’s perspective, this is a top priority alert. However, contextual analysis shows that in order to exploit this vulnerability, an attacker would already have to have access to this highly protected segment, and the mere compromise of this station has no direct impact on the process. The real-world risk is low.
Scenario Two: A PLC that manages a chemical dispensing system is running on the same network. It has a vulnerability that allows an unauthorized command to be sent to change recipe parameters. Because it requires some knowledge of the protocol, its technical rating is relatively low - CVSS 5.3 (“Medium”). However, contextual analysis shows that exploitation of this vulnerability could lead to the production of an entire batch of defective, toxic product, putting consumers at risk and exposing the company to gigantic losses and lawsuits. The real risk is catastrophic.
These examples vividly demonstrate that prioritization based solely on CVSS assessment is a dead end. It leads to wasted resources on putting out irrelevant fires, while the real threat, hidden under the “medium risk” label, goes unnoticed.
What is the new correct formula for risk in operational technology?
The traditional, simplified formula for risk is Risk = Probability x Impact. In the IT world, “impact” is often equated with CVSS assessment. In the OT world, we need to redefine and expand this formula to reflect industry realities.
The correct formula should be as follows: Risk in OT = Probability (of exploiting a vulnerability in a given context) x Consequences (to physical security, process and business). Let’s note the key differences.
We are no longer talking about abstract “impact,” but about concrete, multidimensional “consequences.” We also don’t talk about the overall “probability,” but about the likelihood that a given vulnerability will be exploited on a given device, taking into account existing protections (e.g., segmentation). This formula forces us to think holistically and is the only way to realistically assess the threat.
Step One - Context: Why must any risk assessment begin with an understanding of the manufacturing process?
Before we even start talking about vulnerabilities and hackers, we need to take a step back and ask the fundamental question, “How does our business work and what is most important to it?” Any effective OT risk assessment must start with a deep understanding of the business and operational context.
This is the stage where the safety team must sit down with production engineers, shift managers and plant managers and create a criticality map of processes. We need to identify those production lines, machines and systems whose failure would cause the most serious consequences. This is a de facto simplified form of the Business Impact Analysis (BIA) that we have discussed in previous articles.
Only by having such a map can we begin to overlay digital threat information on it. Without an understanding of what is our “crown jewel” and what is just a glimmer, any further analysis will lack a foundation. Context is king.
Step Two - Identification: How do you link a technical vulnerability to a specific physical asset?
Once we have a criticality map of the processes, the next step is to create a detailed inventory of the technical resources that support these processes. We need to know that the PLCs with addresses A, B and C, the SCADA server with address D and the HMI station with address E are responsible for the “Critical Mixing Process of Substance X.”
Then, for each of these identified critical assets, we collect information on known technical vulnerabilities. This process combines results from passive network monitoring, information from vendors and data from public vulnerability databases (CVEs).
The goal of this step is to create a precise link: Technical Vulnerability -> Technical Resource -> Business Process. This way, instead of the abstract problem “we have vulnerability CVE-2022-1234,” we have a concrete, localized problem: “The PLC on Line A, which is critical to our production, has vulnerability CVE-2022-1234.” This completely changes the perspective.
The formula for real risk in an OT environment
Formula elementThe question it answersWho provides the answers?Technical Vulnerability”What technical weakness does the system in question have?”IT Security Team, Scanners, CVE Bases**+ Operational Context**“How critical is this system to production and physical security?”Process Engineers, Production Managers**= Real Business Risks**“What will be the real, physical and financial consequences if this weakness is exploited?”Joint IT/OT Team, Steering Committee**-> Priority Action**“Is this risk acceptable or does it require immediate mitigation?”Steering Committee, Board of Directors
Step Three - Consequence Analysis: What “what if?” questions does the joint IT and OT team need to ask themselves?
This is the heart of the entire process and the stage where IT and OT collaboration is absolutely crucial. For each significant vulnerability identified on a critical asset, a workshop should be held where the joint team asks a series of “what if?” questions.
“What happens if an attacker exploits this vulnerability and manages to stop this PLC? What will be the impact on production? What will be the financial losses?” “What happens if an attacker manages to modify the operating parameters of this machine? Could it damage the equipment? Could it create a danger to the operator? Could it affect the quality of the product?”
The goal of this brainstorming is to identify the worst-case, plausible scenario for each vulnerability. The IT team provides insight into what is technically possible for an attacker to achieve. The OT team translates these technical possibilities into real, physical consequences.
How do you assess the worst-case scenario in terms of security, production and finance?
Once the worst-case scenario is identified, it should be evaluated using a predefined scale. The consequence assessment should be multidimensional and include at least three categories:
First, the impact on safety (Safety). This is the highest priority category. Here we evaluate the potential consequences for human health and life and the environment. The scale can be simple: from “no impact” to “serious injury or death.”
Second, the impact on operations (Production). Here we evaluate the potential downtime, loss of production capacity or impact on product quality. The scale can be expressed in downtime hours or as a percentage of lost production.
Third, financial impact (Financial). This is derived from the impact on operations, but expressed directly in financial terms. It includes the cost of downtime, the cost of repairing equipment, potential contractual penalties and other losses. Having such a multidimensional assessment allows for much more informed decision-making.
Step Four - Assessing Probability: How do we estimate whether a given threat is real for our factory?
Simply assessing the consequences is still not enough. A catastrophic incident with extremely low probability of occurrence may pose less risk than an incident with medium consequences but very high probability of occurrence. Therefore, the second element in the equation is a probability assessment.
In assessing the likelihood, we need to consider several factors. First, the attractiveness of the target - are we a strategically important company that could be targeted by advanced hacking groups? Second, the ease of exploiting the vulnerability - does it require specialized knowledge, or is there a ready-made, publicly available exploit for it?
Third, and most importantly, we must take into account existing compensating controls. The probability of exploiting a vulnerability in a controller that is located in a well-isolated network segment is much lower than for a controller accessible directly from the office network. A realistic assessment of the probability is only possible if we have a complete picture of our defense architecture.
Step Five - Prioritization: How do you create a risk matrix that shows what needs to be addressed first?
Once we have an assessment of the consequences and probabilities for each identified vulnerability, we can place them on a risk matrix. A risk matrix is a simple visual tool in which one axis represents probabilities and the other represents consequences.
Each identified risk is placed in the appropriate cell of the matrix. Risks that land in the top right corner (high probability and high consequences) become our number one priority and require immediate mitigation. Risks in the lower left corner (low probability and low consequences) can be accepted or addressed further down the line.
The risk matrix is an extremely powerful communication tool. It shows in a simple and graphical way which problems are really “hot” and which can wait. It allows for objective, data-driven prioritization of actions and is an excellent starting point for steering committee discussions.
What is a risk register for OTs and why is it a key tool for communicating with management?
The result of the entire risk assessment process is the creation and maintenance of a risk register (risk register) for the OT environment. This is a formal, living document that serves as a central repository of knowledge about all identified risks in the area of industrial cyber security.
For each entry, the register should contain detailed information: a description of the risk, the resources involved, an assessment of the probability and consequences, the resulting risk rating (e.g. “Critical”), and, most importantly, a mitigation plan. The mitigation plan should describe what actions will be taken to reduce the risk (e.g., “implementation of virtual patching,” “network segmentation”), who is responsible for them, and the deadline for implementation.
The risk register is a key tool for communicating with the board. Instead of talking about hundreds of technical vulnerabilities, the CISO can present the board with a list of the top 10 business risks, along with a proposed action plan and budget. This allows for a strategic, rather than technical, discussion about security.
How is process-based risk assessment the foundation of NIS2 compliance?
The NIS2 directive explicitly states that the approach to security must be “risk-based.” Conducting and documenting the detailed risk assessment process described above is the best possible way to meet this fundamental requirement.
Having a mature risk register for OT is evidence that a company is approaching its responsibilities in a systematic and informed manner. It shows auditors and regulators that the organization has not just implemented some random security measures, but that its security strategy is a direct response to its unique risk profile.
What’s more, the process helps justify why certain vulnerabilities (even those with high CVSS) have not been patched, but their risks have been consciously accepted or reduced through compensating controls. A documented risk analysis is key evidence of due diligence, which is of paramount importance in the context of management’s personal liability.
How does conscious risk management transform the security department from a “cost center” to a “business partner”?
Traditionally, the security department is often viewed within an organization as a “cost center” - a unit that generates expenses and slows down processes, without bringing in direct revenue. A mature risk management process, based on close cooperation with the business, completely changes this perception.
When the security department begins to speak the language of business risk rather than the language of technical risk, it becomes a strategic partner and advisor to the board of directors and operations managers. It is no longer seen as a “policeman” who says “no,” but as an expert who helps the company achieve its business goals in a safe and sustainable manner.
Presenting its recommendations in terms of financial and operational risk reduction, the CISO shows how its department directly contributes to protecting corporate value. Conscious risk management is a process that elevates cyber security from the basement server room to the boardroom.
How can nFlo help you conduct a comprehensive risk assessment for your OT environment?
At nFlo, we believe that effective OT risk assessment is a process that requires the perfect blend of three worlds: deep knowledge of cybersecurity, deep understanding of industry processes, and facilitation and communication skills. Our team of experts has unique competencies in all of these areas.
We support our clients throughout the entire process described above. We help implement tools to inventory and identify vulnerabilities. We conduct risk analysis workshops where our consultants act as facilitators, helping your IT and OT teams find common ground and effectively assess the consequences of different scenarios.
Our goal is not just to provide you with a ready-made risk register. Our goal is to help you build and implement a sustainable, repeatable risk management process in your company. We teach your teams how to use this methodology so that they can manage their risk landscape independently and effectively in the future. We act as your partner in building organizational maturity.
Related Terms
Learn key terms related to this article in our cybersecurity glossary:
- Security Operations Center (SOC) — Security Operations Center (SOC) is a central location where a team of security…
- SOC as a Service — SOC as a Service (Security Operations Center as a Service), also known as…
- Network Security — Network security is a set of practices, technologies, and strategies aimed at…
- Cybersecurity — Cybersecurity is a collection of techniques, processes, and practices used to…
- Cybersecurity Incident Management — Cybersecurity incident management is the process of identifying, analyzing,…
Learn More
Explore related articles in our knowledge base:
- How to Conduct a Cyber Risk Assessment in Local Government?
- How to implement NIS2 and not go crazy? Use regulation as leverage to get a budget for OT security
- Risk management in cyber security: How to make informed decisions and protect business?
- The human factor in OT security: How to train engineers not to let threats in via USB?
- What is IT Risk Analysis? Everything You Need to Know
Explore Our Services
Need cybersecurity support? Check out:
- Security Audits - comprehensive security assessment
- Penetration Testing - identify vulnerabilities in your infrastructure
- SOC as a Service - 24/7 security monitoring
Related topics
See also:
