Rethinking OT Risk Quantification Beyond CVEs

Does Unknown Risk Mean No Risk? Not At All.

In the ever-evolving landscape of industrial cybersecurity, where safety and uninterrupted operations are critical, staying vigilant about vulnerabilities and risks is paramount.

Did you know that 66% of the vendors mentioned in CISA advisories have appeared only once in the past eight years ? (as of the date of writing this article – among over 2,300 advisories). This fact could imply that most of the OT vendors may not be consistently releasing security updates. If they were, we would likely see more than one advisory for each. Additionally, we haven’t even considered the vendors who are not featured in CISA and have no security advisories at all.

Unlike typical IT systems, OT devices and industrial control systems often operate on legacy protocols, have long lifespans, and they don’t always receive continuous CVE reports. While common devices from leading vendors such as Siemens, Rockwell, and Schneider Electric are rigorously assessed and supported by detailed advisories, many less common OT devices are not.

Moreover, some vendors might not disclose vulnerabilities for fear of reputational damage or other reasons. Furthermore, many devices rely on third-party libraries or components, which may have known vulnerabilities that might not be published by the vendor and related directly to the device. So indeed we have an issue to assess that risk for those assets.

This article will try to answer the question of how to assess the risk for those devices with missing documented CVEs.

Does Unknown Risk Equate to No Risk?

Consider two OT devices: One has no reported CVEs, while the other has many reported CVEs without any CVE affecting it’s version. Which device would you consider safer?

The availability of CVEs for devices, is reflecting the combination of two things, the level of device security quality, and level and intensity of security validations.

A lack of documented vulnerabilities can pose a significant challenge to risk assessment, as these parameters might be unknown.

The reality is that just because a vulnerability is not publicly known or documented, doesn’t mean it doesn’t exist. In fact, many vulnerabilities have been exploited long before they were officially reported as CVEs. A prime example is the ‘Fuxnet’ malware.

Asset Classification in Relation to CVEs

Taking the past 6 years, I would like to classify assets into 3 groups:

Group 1 (Green) – Assets with plenty of CVEs – This group has the most accurate risk assessment, since many of potential vulnerabilities are well-documented and clear to us.

Group 2 (Orange) – Assets with very few CVEs (1-3) – These assets have occasional vulnerabilities reported over several years, sometimes identified by individuals and not by the vendor.

Group 3 (Red) – Assets with 0 CVEs – Assets in this group lack disclosed vulnerabilities, which raises the suspicion of potential unreported vulnerabilities.

For group 1 we have sufficient data to calculate risk using the established risk assessment methodology

For groups 2 and 3, we suspect that some of the low hanging vulnerabilities might not be discovered yet, as the absence of reported CVEs, does not automatically imply a device is secure. Instead, it signifies that we may not yet be aware of the existing risks.

Risk Assessment for Devices With Lack of CVEs

How Risk Calculated Today and Why CVEs are Only Part of the Picture?

The usual and established risk assessment formula is Likelihood x Impact. The amount of vulnerabilities on an asset, along with the complexity and impact severity of each one, usually will be a major part of the risk assessment score for the asset.

As we suspect our asset is missing documented vulnerabilities, we will try to assess the risk by alternative parameters.
The challenge lies in calculating the likelihood of CVEs occurring on the asset and their potential severity.

Alternative Risk Parameters to Assess Device Vulnerabilities

The discussion of how to assess that risk can be divided into 2 measures:

Vendor Measures:

1. Vulnerability Management Policy:
   Examining the transparency and responsiveness of a vendor in disclosing and addressing vulnerabilities, reveals their reliability and effectiveness in maintaining device security. Proactive vulnerability management by the vendor helps maintain a lower risk profile for their devices. Devices with no CVEs from vendors who continuously provide security reports/bulletins should be considered more secure and reliable. Equally, vendors that release security updates to address their CVEs demonstrate a strong commitment to security.
2. Certifications and CNA Status:
   Certificates – It is important to assess whether the vendor holds certifications that align with their industry standards and meet customer requirements (IEC 62443-x-x, UL 2900, ISO 27001, ISO 27017, ISO 27018, CSA – STAR Level 1/2, SOC 2, SOC 3, TISAX ..).
   CVE Numbering Authority (CNA) Status – Vendors with CNA status are authorized to independently identify and publish vulnerabilities independently, reflecting their proactive approach to vulnerability management and commitment to transparency.
3. Provision of General Security Guidelines:
   Vendors who equip their customers with general security guidelines are more likely to implement best security practices in their products.

Device Measures:

1. CVEs for Similar Devices:
   We aim to determine whether the absence of CVEs in our device is due to negative factor, such as lack of continuous security updates – suggesting potential flaws that we may not be aware of. Or positive factor, like specific model without CVEs. By examining CVEs associated other models within the same series, or similar devices from the same vendor, we can gain clarity on this matter.
2. Potential Attack Surface:
   Analyzing whether the device follows secure configuration practices helps in understanding its susceptibility to unauthorized access or exploitation. This can include checking for default settings and credentials, unnecessary open ports/services, and whether unnecessary features are disabled.
3. Firmware and OS Versions Recency:
   The firmware and OS versions a device runs can dramatically impact its risk profile. Devices with newer firmware and OS versions are likely to have fewer flaws and bugs that could expose them to malicious activities. These newer versions often include updated third-party libraries, likely to be more immune.
   Moreover, frequent updates reduce the time available for potential attackers to discover and exploit security flaws, as these updates limit the time window of exposure.
4. Lifecycle Status:
   The device lifecycle status, or support availability, is another critical factor in assessing device risk. Devices or hardware versions that have reached end-of-life (EOL) or end-of-service (EOS) are particularly vulnerable. Once a device is no longer supported by the vendor, it stops receiving crucial security updates and patches, increasing the risk of exploitation.
   Worth to mention – Each vendor has its own end of life and support policies, which can vary significantly. For instance, some vendors implement a phased approach, with multiple stages before a device is no longer supported with security updates. In contrast, other vendors may consider the end of life declaration as the immediate termination of all support services, including security services.
5. IEC Certification:
   IEC 62443-4-2/1 is part of the IEC 62443 series of standards focused on cybersecurity for industrial automation and control systems (IACS). Specifically, IEC 62443-4-2 addresses the cybersecurity requirements for industrial control system components. It provides a comprehensive framework for ensuring that these components are secure by design and meet specific security capabilities to protect against cyber threats. Devices and software with IEC 62443-4-2 certifications (such as Rockwell 1756-OA8, Siemens 6GK5213-3BD00-2TB2) are considered safer.

Suggested Methodology:

Considering the device and vendor measures we’ve discussed, we developed a “Vulnerability” risk assessment methodology.

Framework for Processing Assessment Parameters

Through our research, we’ve determined specific weights for each parameter after conducting a comprehensive assessment of numerous components across various OT networks and an in-depth evaluation of the associated risks. As a result, we have arrived at what we consider the most accurate distribution of weights.

Each parameter is typically rated on a scale of 1 (indicating the safest condition) to 5 (representing the highest risk).

Vendor Measures (30%):

• Vulnerability Management Policy: 15%
  1: The vendor releases continuous security (CVE) report,s and their security updates address CVEs
  5: No security reports published by the vendor,r and security updates don’t contain CVEs fixes
• Certifications and CNA Status: 10%
  1: The vendor holds OT security certificates and has advanced CNA status
  5: Vendor doesn’t hold any security certificate and no CNA status
• Provision of General Security Guidelines: 5%
  1: The vendor publishes detailed OT security guidelines
  5: No security guidelines published by the vendor

Device Measures (70%):

• CVEs for Similar Devices: 15%
  1: There are plenty of CVEs for other firmware/OS or other models in the series
  5: No CVEs at all for other firmware/OS or models within the series
• Potential Attack Surface: 15%
  1: Secure configurations, strong passwords, and best practices followed
  5: Default settings and open ports
• Firmware and OS Versions Recency: 15%
  1: Latest OS and FW version
  5: Outdated versions
• Lifecycle Status: 20%
  1: Fully supported
  5: Completely end-of-service
• IEC Certification: 5%
  1: The device has IEC 62443-4-2/1 certification
  5: The device doesn’t have IEC 62443-4-2/1 certification

Challenges and Fallbacks

Data Collection

One of the primary challenges in quantifying risk for devices without CVEs is the scale of data collection required. Gathering comprehensive data about the device potential attack surface, firmware/OS version, EOL state, Potential CVEs and more, can be an exhaustive process, especially for large-scale OT networks with diverse devices.

The manual collection of this data is not only time-consuming but also prone to human error, leading to potential inaccuracies in risk assessment.

Moreover, some devices might be proprietary or highly specific to a particular industry, making it even harder to gather standardized data. Additionally, these devices might not be well-documented or widely used, compounding the difficulty of amassing reliable information.

Automation tools can help, but they need to be highly sophisticated and adaptable to various environments and devices, which adds another layer of complexity.

Current Actionable Steps

So these are the steps we can do instantly in order to better understand our environment vulnerability risk, and with that prioritize the most important assets.

• Review Most Common Devices in the Environment:
  Review the vendor for each one of the most common devices in the network by evaluating the vendor measures discussed before, such as whether the vendor consistently maintains security updates, the level of support they provide, and their engagement with the community. This systematic approach not only simplifies the risk assessment process but also incentivizes vendors to enhance their performance in these critical areas.
• Detect Assets With No Published CVEs in The Asset Inventory:
  Investing in platforms that can automate the collection and analysis of relevant security data is a step in the right direction. These platforms should be designed to interface with a variety of devices and protocols, extracting data such as configuration details (open ports, services, default credentials etc.), firmware/OS versions, and even network exposure metrics in a standardized format.
• Detect EOL/EOS Devices:
  Finding the EOL/EOS assets in the environment, is a practical and impactful step in the ongoing process of risk management for devices, operating systems and software. It bridges the gap between current state and potential vulnerabilities, enabling organizations to stay ahead of security threats and regulatory demands.
• Review Firmware and OS Updates:
  A good way to determine whether a vendor is addressing SBOM (Software Bill of Materials) vulnerabilities is to verify that updates include fixed versions of vulnerable third-party components. This can be done by reviewing the release notes accompanying the updated versions.
• Use Risk Assessment Calculator:
  Once all the vendor and device measures parameters are gathered, the risk for each asset with missing CVEs can be easily calculated. This allows us to prioritize tasks and assets effectively.

Real-World Examples Presented at S4x25

Zebra Printers Case Study

Zebra is a leading company based in Lincolnshire, Illinois (since 1969), best known for their industrial printers and scanners until today.
Up until 2019, no CVE were associated with Zebra products, however in August 2019, a CVE was identified affecting all Zebra industrial printers (with a web management interface). This including very recent and modern models as well as old models starting from early 2000s, for example Zebra 105SL that released in 2003.

That example emphasizes the huge potential of zero-day vulnerabilities for devices and vendors with no historical CVEs.

The fact that a vulnerability was discovered 16 years after the release of the Zebra 105SL underscores the significant potential for zero-day vulnerabilities in devices and from vendors with no previous history of reported CVEs.

Let’s take the Zebra vendor. One year before the mentioned CVE was discovered in 2019, normalize the weights and calculate its risk parameters according to our methodology:

Vulnerability Management Policy (50 %): 5 – In 2018, Zebra did not provide continuous vulnerability updates and lacked a robust system for addressing and disclosing security vulnerabilities compared to peers in the industry. This would place them in a higher-risk category regarding their ability to manage vulnerabilities effectively.

Certifications and CNA Status (33.33 %): 4 – In 2018, Zebra had some industry-relevant certifications, but it was not as comprehensive as it could have been. They were not a CNA at the time, which is an indication of a moderate level of independent vulnerability management capability.

Provision of General Security Guidelines (16.67 %): 3 – Zebra provided basic security guidelines to its customers, though these guidelines were not as detailed or extensive as those provided by some competitors known for their advanced security practices.

Siemens WinCC and PCS 7:

WinCC (Windows Control Center) and PCS 7 (Process Control System 7) are products developed by Siemens, and they are often used together in industrial automation and process control. WinCC version 6.2 was released in 2005, and PCS 7 version 6.0 was released in 2002.

In June 2010, the malicious computer worm known as “Stuxnet” came to light. This worm specifically targeted Siemens WinCC and PCS 7 software and was first discovered during disruptions to Iran’s nuclear program.

It is believed that Stuxnet had been in development since at least 2005 and potentially deployed in the wild as early as 2007 or 2008. Estimates suggest that Stuxnet caused significant physical damage to approximately 1,000 centrifuges at the Natanz uranium enrichment facility in Iran. This was achieved by making the centrifuges spin out of control while simultaneously displaying normal operation data to the operators utilizing the WinCC and PCS 7 software.

In July 2010, the associated CVE was officially reported. Both WinCC 6.2 and PCS 7 6.0 are vulnerable to this CVE. This means that the CVE was documented approximately 5 years after the release of WinCC 6.2 and 8 years after the release of PCS 7 version 6.0, although the vulnerability had existed since its released.

Let’s take WinCC 6.2 as an example, one year before Stuxnet was discovered (2009), and calculate its “Vulnerability” risk parameters according to our methodology:

Vendor Measures:

• Vulnerability Management Policy (15%): 5 – Siemens started publishing continues security updates in 2011, as for 2009, no security updates were published by Siemens.
• Certifications and CNA Status (10%): 5 – In 2009, Siemens didn’t hold any security certificate and has no CNA status.
• Provision of General Security Guidelines (5%): 1 – In 2009, Siemens did provide general security guidelines for their OT devices. These guidelines were part of Siemens’ broader effort to enhance the security of their industrial control systems and other OT equipment.
  ** I would like to emphasize that, as of today, Siemens has significantly improved in these areas and in security overall. They now regularly release continuous CVE updates, hold CNA status, possess relevant certifications, and provide comprehensive security guidelines for their OT products.

Device Measure:

• CVEs for Similar Devices (15%): 5 – No CVEs at all were available for other industrial software from Siemens, like PCS 7 or STEP 7, back in 2009.
• Potential Attack Surface (15%): 5 – Many industrial control systems in the Iranian network, including those running WinCC, used Siemens’ default passwords that were later exploited by Stuxnet and made it easier for the worm to gain access and propagate. The lack of comprehensive security measures in place, such as strong access controls and network monitoring, made it easier for Stuxnet to infiltrate and spread across the network.
• Firmware and OS Versions Recency (15%): 5 – WinCC 6.2 was at least two revisions behind the latest available release – WinCC V7.0 which released in 2007, signifying it was relatively old and potentially missing out on important updates and security enhancements that newer versions provided.
• Lifecycle Status (20%): 3 – In 2009, WinCC 6.2 would not have been completely EOL/EOS, it would have been in its late support phase with limited new development and a push towards upgrading to newer versions. It reached its end of service life on September 30, 2010.
• IEC Certification (5%): 5 – In 2009, Siemens WinCC was not IEC 62443 certified.

That emphasizes that although WinCC didn’t have any CVEs back in 2009, using our risk assessment method would have rated the software with a very high severity, thus by a better prioritization security measures and adopting better practices, maybe the success of the Stuxnet attack could have been prevented.

Summary

• The absence of CVEs does not equate to the absence of risk. Hidden vulnerabilities can persist undetected for years.
• A structured approach combining vendor and device measures offers clearer risk assessments for devices without CVEs.
• Help us enrich this framework by exploring more vendors, uploading feedback, and collaborating to refine the methodology.
• This open-source tool is now available for the market—everyone can use it, contribute to it, and share their insights. Together, we can stay ahead of emerging threats and better protect critical assets.

Conclusion and Call to Collaborate on Further Research

In conclusion, the absence of reported CVEs does not equate to the absence of risk. As we’ve seen, vulnerabilities can persist in devices for years before being discovered, and the lack of reported CVEs can often cloud our understanding of an asset’s true security posture.

Our methodology, which takes into account both vendor and device measures, provides a structured approach to assessing the risk of assets without CVEs. By evaluating factors such as vendor vulnerability addressing, certifications and authorizations, provision of general security guidelines, device configuration, and more, we can gain a clearer picture of potential vulnerabilities and make informed decisions to enhance our cybersecurity defenses.

However, this is just the beginning. The landscape of cybersecurity is dynamic and ever-evolving. To keep pace, we must commit to continuous research and development. I urge you all to collaborate within and across organizations, sharing insights, data, and strategies to refine our methodologies and tools further. By pooling our collective knowledge and resources, we can stay one step ahead of emerging threats and better protect our critical assets.