Current cybersecurity risk detection systems in complex networked OT (Operational Technology) systems focus predominantly on situational assessments based on: Detection of participants in the system (ID, asset management, scan for known vulnerabilities (CVE) and mapping of participants and detected vulnerabilities to actively exploited attack paths. In the best case, the result is a list of detected vulnerabilities in the overall system and their assignment to assets and weighting according to CVVS (Common Vulnerability Scoring System).

However, in complex networked systems with several hundred to a thousand participants, such a list of CVEs related to assets can easily grow to a confusing length comprising hundreds of thousands of references.  Particularly in the case of OT (Operational Technology) assets, vulnerabilities cannot be closed in practice without major hurdles for a variety of reasons. These include: missing information on installed firmware, limitation of software maintenance windows, sluggish patch supply, and insufficient over-the-air update connectivity.

CVVS-based prioritization of cybersecurity vulnerabilities here inevitably leads to perception and resource problems in planning and executing risk mitigation measures. As a result, measures and resources are implemented in the wrong places and vulnerabilities are often underestimated or not detected in participants with high operational risks. Especially in dynamic and complex OT systems, this results in a permanent attack surface with sufficient options for attackers to create a high operational damage picture.

To solve this problem, asvin proposes “Risk by Context“, a novel method for identifying and prioritizing risks in OT systems. This method thereby relates operational factors and cybersecurity factors (context) and enables a weighting of risks via mathematical methods for the evaluation of topological contexts. The method also allows unknown cybersecurity risks (e.g., zero-day exploits, firmware states) to be included in the risk assessment, extending the risk consideration beyond the horizon of known CVEs and attack paths. In addition, risk states can be simulated in a complex system, for example, to predict the risk impact of adding or removing participants.

With the Risk by Context method, asvin makes a significant contribution to the optimization of Cyber Threat Intelligence and Situational Awareness. Furthermore, the method opens up an accountable (trustworthy) introduction of new security metrics and enables forecasts on the (predictive) impact of cyber attacks on command and control systems. Through an optimized preparation of risks, the use of resources (personnel and material) can be optimized in risk minimization.  This is a significant new contribution to increasing resilience in command and control systems.

Status quo of CVVS-based cybersecurity risks in OT systems

Due to the use of digital systems, the number of software components in OT systems increases, with it the number of errors (bugs) in software components and thus the number of known vulnerabilities (CVEs) as well as the potential of unknown attack possibilities (Zero Day Exploits). The extent of this growth in the attack surface can be illustrated very well in the increase in lines of code in digital products: The software in the on-board computer of Apollo 11 for the moon landing comprised 145,000 lines of code, a Boing Dreamliner requires 14 million lines of source code for safe flight, and a modern networked vehicle (Software Defined Vehicle) is delivered with up to 100 million lines of software code.

Studies assume that on average there are about 3 errors per 1000 lines of written software code. In safety-critical applications, there are about 0.5 errors in 1000 lines of code. For a modern vehicle, this means that between 300,000 – 50,000 potential errors are contained in the source code. This potential includes known vulnerabilities classified with CVE, previously undetected bugs, and zero-day exploits. This growth is partly due to the use of hypervisor architectures, which streamline software development and maintenance, but at the same time result in redundant use of software code in virtualized systems, thus also increasing the absolute number of existing vulnerabilities. As a consequence, a CVE scan on components of a Software-Defined-Vehicle leads to result lists with several hundred thousand entries when considering all components. Ranking these entries according to CVVS leads to a narrowing down of several thousand critical CVEs and hence to the practical question of determining which known CVEs need to be closed and with the priority they are given.

Closing security vulnerabilities is practically limited by the available development resources at operators, manufacturers and suppliers. As a result, critical vulnerabilities remain open or their closure is severely delayed. From the operator’s point of view, the system is in a permanent state of uncertainty due to open CVEs. The economic and technical limits do not allow full closure of all software risks classified as critical. Moreover, the dark field of undetected (zero-day) risks in the software stack is completely ignored.

If we consider not only individual assets (e.g. a vehicle) but also consider them as part of a complex application system, the risks associated with CVE increase. Existing cyber threat intelligence (CTI) systems based on CVE/CVVS metrics have thus reached their limits in practice. Such systems are not capable of mapping risks in a form that effectively supports situation assessment and risk mitigation planning. On the contrary, the focus of existing systems on the severity (CVVS) of a vulnerability, without the context of the use of the affected asset, may lead to inadequate prioritization of resources and actions in risk management. Assets with a factually lower-level vulnerability (e.g., due to limited connectivity) are initially treated and presented in the same way as assets with a factually high vulnerability profile (e.g., with hyperconnectivity).

Risk by Context for OT Systems provides new approaches

asvin’s Risk by Context enables new methods for capturing, assessing and processing cybersecurity risks in complex OT systems. Risk by Context extends the boundaries of CVE-related threat intelligence and risk management systems and enables optimal decision-making for prioritization of actions, in risk mitigation as well as capabilities to simulate decisions and their impact on asset security. Risk by Context looks at the potential of cyber risk in the context of operational risks and objectives. This creates a topological context space that enables reproducible and traceable prioritization of cyber risks through algorithmic processes. This context-aware cyber situational awareness enables a better database for prioritizing decisions and allocating resources in cyber defense.

Examples of risk preparation and assessment using Risk By Context:

 

  1. Context via attack path: Asset A has detected vulnerabilities (CVE) that can be exploited by a known attack path (Attack Path D-A-C-B). Being connected on an attack path increases the assessed risk for Asset A. While Asset A’ has the same known vulnerabilities (CVE) as A, but the connections F-A’-E are not on any known attack path. Therefore, the practical risk for A’ is lower than for A (given the same CVVS scoring). Thus, the risk mitigation measures should be prioritized for A
  2. Context about network connections: Asset A has detected vulnerabilities (CVE) and a high number of connections with other assets in the network. Asset A’ has the same known CVEs but a significantly lower number of direct network connections. Therefore, the practical risk for system G-A’ is lower (and thus for A’) than for system A-B-C-D-E-F (and thus for A with the same CVVS scoring). Thus, the risk mitigation measures should be prioritized for A
  3. Context over dimension network segments: Asset A is located in has detected vulnerabilities (CVE) and is located in a large network segment with assets B-I. Asset A’ has the same known CVEs but is located in a network segment with fewer assets (J-K). Risk mitigation measures should therefore be prioritized for A to minimize the potential for damage to additional asset
  4. Context about external connections: Asset A is in direct and indirect connection with an asset outside a closed network segment (e.g., remote maintenance access or remote telemetry connection). In contrast, Asset A’, which is of the same type, has no direct or indirect outside connection. The risk for A is therefore potentially rated higher than the risk for A’.
  5. Distance from known risks: Asset B has a high recognized risk (e.g., CVVS or actively exploited exploit). The risk to A is rated higher. Since the distance (A-C-B) via network connections to B is lower than for A’ via the connection path A-F-E-D-B.
  6. H-S-E context: Asset A is directly associated with high H-S-E risks (Health- Safety-Environment). While for A’, the associated H-S-E risks are lower. Although A and A’ have equivalent potential or identified vulnerabilities, cyber risk mitigation measures should be prioritized at A, as this also minimizes the potential impact from higher H-S-E risks.
  7. Operational significance: Asset A is associated with a high or critical operational or significance (B). For A’, this operational significance is lower. Although A and A’ have equivalent potential or identified vulnerabilities, cyber risk mitigation measures should be prioritized for A, as this also minimizes the potential operational risks.

Risk by Context as a better basis for decisions

asvin’s Risk by Context method uses the above-mentioned (as well as additional) factors, relates them to each other in a multidimensional space and creates a weighting model that determines the individual risk of an asset. Risks of related assets or whole segments can be inherited. This makes it possible to determine a risk estimate for OT systems with assets that have largely unknown properties (for example, zero-day exploits).

The risk-by-context index determined in this process is based on mathematical methods of graph analysis (cybersecurity knowledge graphs) and topology theory. Here, the authors have done preliminary work in various research projects over the past years, which has been incorporated into the design and creation of asvin’s Risk by Context (M.Ross, R. Bohara, IoT Crawler, Horizon2020; M.Ross, NGI Pointer, Horizon2020, R. Bohara, Eratosthenes, Horizon2020, M.Ross, R.Bohara, CERTIFY, Horizon Europe, M.Ross, R.Bohara, R.Yahalom, R.v. Kranenburg, DataChainSec, BMBF;  R.Yahalom, Cybersecurity at MIT Sloan (CAMS), MIT; R. Yahalom, Cyber Resilient Energy, US Department of Energy; R.v.Kranenburg, TagITSmart, Horizon2020).

Fig.: Representation of risks in a system landscape with a view of network segments, based on the risk-by-context index.

Fig.: Illustration of risk-by-context modeling of individual assets within a network segment.

Fig.: Representation of risk in segments in the weighted list (sorting by risk-by-context) for prioritizing decisions.

The data types and data spaces required for risk-by-context determination are made available to the asvin risk modeling engine via data pipelines. Existing data spaces and data services can be connected to the risk-by-context analysis platform via interfaces (REST/JSON): for example, data from asset management, network topography, OSINT (e.g. MITRE ATT&CK, OT@MITRE), H-S-E and operational risk factors from business continuity and supply chain management.

Advantages of prioritization according to Risk by Context as a basis for decisions

Weighing operational and unknown risks in cyber threat intelligence (CTI).
asvin Risk by Context enables better prioritization of risk mitigation actions than traditional CVE/CVVS-focused methods. By incorporating multi-dimensional context spaces, operational and cybersecurity risks can be intersected. This allows for the identification of assets that need to be prioritized in individual exposure to threats from a myriad of objectively critical CVEs. As a result, SOC and CERT teams are cognitively unburdened and can better plan work resources. Risks can thus be limited and minimized more quickly.

Simulation of changed risks in the event of state changes

Risk-by-context modeling allows the prediction of a change of state for an overall system and its contained assets as soon as the individual risk of an asset changes or new assets are added to the system. The method can therefore simulate the risk assessment of a system in the event of a planned
(or unplanned) change and thus significantly support the planning of a secure system landscape. Complex networked systems are characterized by high dynamics. Assets join or leave the system. This changes the risk profile of the entire system, segments and individual assets. The Risk-by-Context method allows simulating the change of these risks when the system changes. Risk-by-Context thus supports the modeling of predictive effects of cyber attacks on command and control systems.

Unknown cybersecurity risks (zero days) as an analyzable factor in the risk model

CTI based on known CVEs and attack paths only allows a risk assessment and evaluation based on known risks. Especially in OT systems, it is not possible to determine precise metrics on software properties and thus on contained CVEs for assets (e.g., proprietary firmware, missing or incomplete software bill-of-material). Using graph-based analysis, cybersecurity knowledge graphs (CSKG) can be created that are suitable for including unknown risks (e.g., zero-days) in a risk assessment (cf. J.LI, 20109). With this method, Risk-by-Context is superior to conventional CVE/CVVS-based CTI approaches and extends the consideration to the high-risk area of unknown vulnerabilities and attack paths in complex systems. These can thus be planned and set up to be more resilient against attacks using zero-day attacks.

Conclusion Risk by Context

asvin proposes “Risk by Context”, a novel method for identifying and prioritizing risks in OT systems. This method thereby relates operational factors and cybersecurity factors (context) and enables a weighting of risks via mathematical methods for the evaluation of topological contexts. The method also allows unknown cybersecurity risks (e.g., zero-day exploits, firmware states) to be included in the risk assessment, extending the risk consideration beyond the horizon of known CVEs and attack paths. In addition, risk states can be simulated in a complex system, for example, to predict the risk impact of adding or removing participants.

With the Risk by Context method, asvin thus makes a significant new contribution to optimization in Cyber Threat Intelligence and Situational Awareness. Furthermore, the method opens up an explainable (trustworthy) introduction of new security metrics and enables forecasts on the (predictive) impact of cyber attacks on command and control systems. Through optimized processing of risks, the use of resources (personnel and material) can be optimized in risk minimization.  This is a significant new contribution to increasing resilience in command and control systems.