nexus_dj-likelihood.jpg
Operational Technology
Cyber Resilience
Vulnerability Management
Risk Management

Throw Likelihood to the Wind: OT Cybersecurity is Categorical, Not Mathematical

Danielle Jablanski
/
Jul 24, 2025

Caution is in. Safety is supreme. And the likelihood variable of risk—the probability or chance that a potential security threat will exploit existing vulnerabilities—is an incomplete way to assess cyber-physical systems and environments. (Never mind the fact that business leaders hear the word and immediately equate it with the likelihood of being attacked, rather than the likelihood that a threat actor will achieve success when targeting a specific vulnerability in your environment.) 

Despite a general understanding that operations that tolerate little to no physical downtime are lucrative targets, it remains challenging to standardize attack patterns in operational technology (OT), as case-by-case knowledge is required to secure each operation based on its process and function—what is treated, produced, fabricated, manufactured, pumped, assembled, etc. 

While ransomware statistically remains the most likely forecasted incident for every sector and industry, the likelihood of being targeted and the probability of success of exploitation are nearly impossible to predict in OT environments with current tools. Purpose-built systems, designed for use cases ranging from mundane to hazardous, tie their safety, alarming, and redundancy to the function of their outputs, rather than the design of their deployments.  

Ransomware is Not Going Anywhere 

As we know, ransomware only sometimes impacts operations, directly or inadvertently. This, of course, depends on the level of connectivity between business systems and operational or process equipment, as well as the implementation, or lack thereof, of layered network defenses. 

Beyond ransomware, the most likely incident types are unauthorized access, phishing and email compromise, malware, and denial of service. It’s worth noting that the MITRE threat and vulnerability analysis (TARA) workbook for industrial control systems (ICS) does not mention ransomware. It also omits attack likelihood in its mapping of threat vectors and countermeasures, detailing potential threat actor objectives instead. 

Vulnerabilities, Likelihood, and Severity

Several years ago, when the Critical Effect Conference was still known as Hack the Capitol, my presentation focused on risk assessment methodologies that were not holistic. Internal risk registers often focus on a handful of identified vulnerabilities that may have compensating controls, while external risk often focuses on the means and capabilities of specific threat actors—regardless of how much impact they may or may not have in each environment.

According to the National Institute of Standards and Technology (NIST) SP 800-82 rev. 3: “OT cybersecurity programs should always be part of broader OT safety and reliability programs at both industrial sites and enterprise cybersecurity programs because cybersecurity is essential to the safe and reliable operation of modern industrial processes.” 

This is typically where anomaly detection enters the chat. However, there are still more holes to poke in the current vulnerability analysis. Let’s not forget that the CVSS—Common Vulnerability Scoring System—does not provide sufficient context regarding the real-world exploitability and impact of a vulnerability. 

Focusing on the likelihood of success of a threat actor’s tactics, techniques, and procedures (TTPs) targeting known vulnerabilities in your OT environment does almost nothing to reduce the severity of potential impacts from a tailored attack. A tailored attack in your environment is not likely to look exactly like something that has been witnessed before, so why rely on known exploitable vulnerabilities to do consequence mapping? 

The NIST 800-82 guide lists possible incidents that an OT system may face:

  • Blocked or delayed flow of information through OT networks, which could disrupt OT operation, including loss of view and loss of control

  • Unauthorized changes to instructions, commands, or alarm thresholds that could damage, disable, or shut down equipment, create environmental impacts, and/or endanger human life

  • Inaccurate information sent to system operators, either to disguise unauthorized changes or to cause operators to initiate inappropriate actions that could have various negative effects

  • Modified OT software or configuration settings or OT software infected with malware, which could have various negative effects

  • Interference with the operation of equipment protection systems, which could endanger costly and difficult-to-replace equipment

  • Interference with the operation of safety systems, which could endanger human life

If it were easy to specify what systems and components would be targeted to realize these incidents in each OT environment, there would be a lucrative startup company doing just that. Severity ratings, from negligible to severe, would be obvious. Instead, dozens of variables act as indicators of severity (is the threat novel or unique? Does access require lateral movement from a corporate network? Does exploitation require interaction with the target?) 

Where to Start Instead: Crawl, Walk, Run 

This NIST categorization of incidents can lead to the loss of view or control of OT systems and processes. However, organizations struggle with mapping their environment to the risks associated with each incident type. This challenge arises because a thorough understanding and contextualization is required before risk assessments can be tailored to specific OT environments. Additionally, it’s important to note that cybersecurity operates within an unregulated market, where customers may have a limited ability to vet and verify whether the solutions they invest in deliver what they claim.

Instead of buying down risk, owners and operators are beginning to develop ways to crawl, walk, and run toward OT cybersecurity programs that refuse to compromise safety and reliability—before vulnerabilities are part of the equation. 

Crawl: Mapping Your Infrastructure 

  1. Identify your key mission or business processes—what essential services do you provide or what drives your revenue?

  2. Develop and maintain an inventory of your organization’s current and future systems, hardware, software, and firmware that support key mission or business processes

  3. Identify which systems are critical to the key mission or business processes identified

    1. Primary Tier: Critical to the mission, which cannot be met without it; potential single source of failure

    2. Secondary Tier: Important to the mission, though not essential; backup process/solution or redundancy exists (cyber or physical) 

    3. Tertiary Tier: Related to the mission, but not essential for safety, availability, maintenance, etc.

Walk: Mapping Your Dependencies 

  1. Understand how your software (current or future purchases) supports or otherwise relates to your key processes

  2. Research and document how each product license is supported by its supplier (e.g., Are patches provided? Hardening and implementation guidance? etc.)

  3. Cross-reference the NIST scenarios above with the systems and processes that would be necessarily impacted across the primary, secondary, and tertiary tiers identified in step 3 

    1. Tag each system accordingly

Run: Prioritizing Your Controls 

  1. Rank and detail which NIST scenarios would cause a loss of view or loss of control of key mission or business processes

    1. Include the organization’s level of preparedness for each

  2. Sort your newly tiered inventory:

    1. Highest risk – Tier 1 systems if impacted would result in a loss of control 

    2. Medium risk – Tier 2 systems if impacted would result in a loss of control

    3. Mild risk – Tier 1 systems if impacted would result in a loss of view 

    4. Low risk – Tier 2 systems if impacted would result in a loss of view 

  3. Document how you plan to address hardware/software for which a vulnerability is disclosed – i.e. patching, upgrading, or compensating control – by risk level from step 8

The final step of this process is to review security controls that will address the bulk of identified risks that are within the bounds of your resources, rather than spending a tremendous amount of time and effort analyzing the relative risk of every product vulnerability that has been disclosed while draining your budget. 

Different activities can be worked into this model. For example, attack pattern analysis can be done alongside dependency mapping. Tabletop exercises can happen before the prioritization of controls. Securities Operations Center (SOC) capabilities can be enhanced based on the identification of tiered assets or where visibility gaps exist, and penetration testing can occur before documentation on how to address vulnerabilities. 

The focus of this exercise of mapping scenario type to systems and impacts allows organizations to take an effects-based (rather than means-based) approach to OT security, if they understand their systems and processes – the caveat that matters most. 

If you’ve read this far, you already know there is no silver bullet solution on the market that does all of the above. Operators may find they are prepared for interference with the operation of safety systems, which could endanger human life, but have never considered the impacts from inaccurate information sent to system operators, either to disguise unauthorized changes or to cause operators to initiate inappropriate actions that could have various adverse effects.

Countermeasures and Compensating Controls 

Cybersecurity is an ongoing pursuit to ensure the integrity of data, systems, and operations. Likelihood calculations are out of style, and continuous improvement – improving your ability to operate under compromise – is the only trend worth following. 

Countermeasures—actions, devices, procedures, or techniques that meet, oppose or counter an attack by preventing it, minimizing the harm it can cause, or by discovering and reporting it in order that corrective action can be taken—become expensive wishful thinking without the explicit understanding of your environment. 

Compensating controls are effective security measures tested, deployed, implemented, and maintained to address risks in the pursuit of continuous improvement—indicating a different starting place for each organization. Therefore, there is no hierarchy of security controls that is perfect for every environment. 

Security does not happen by default with the adoption of any one control and is not satisfied by implementing any given tool. If done correctly, any variation of the mapping exercise above will allow for better informed decision-making on, and investments in countermeasures and compensating controls. 

Operational Technology
Cyber Resilience
Vulnerability Management
Risk Management
Danielle Jablanski
OT Cybersecurity Consulting Program Lead, STV

Danielle “DJ” Jablanski leads STV’s operational technology (OT) cybersecurity consulting program, advising clients in security program development, strategy, tool selection and deployment to mitigate cybersecurity threats facing operational technology and cyber-physical environments across transportation, energy, water, and infrastructure projects. Formerly a SME in the Office of the Technical Director at CISA, at Nozomi Networks, and Guidehouse, she is an experienced strategist, analyst, and program manager, with hands-on industry and governance expertise in OT and industrial control systems (ICS). In her free time, she teaches two college courses on Cyber-Physical Cybersecurity.

Stay in the know Get the Nexus Connect Newsletter
You might also like… Read more
Latest on Nexus Podcast