*3.3. Properties*

Together, the EDG model and the defined metrics exhibit a series of characteristics that make them suitable for vulnerability assessment. These properties represent an advantage over the techniques reviewed in the state of the art, including automatic inference of root causes, spatial and temporal distribution of vulnerabilities, and prioritization of patching, which will be described in the following subsections.

### 3.3.1. Automatic Inference of Root Causes

Each CWE natively contains information that is directly related to the root cause of a vulnerability. From this information, new requirements and test cases can be proposed.

### 3.3.2. Spatial and Temporal Distribution of Vulnerabilities

The key feature of the proposed model is the addition of the temporal dimension in the analysis of vulnerabilities. This makes it possible to analyze the location of the vulnerabilities both in space (in which asset) and time (their recurrence), which allows us to track the state of the device throughout the whole life cycle. This approach also enables further analysis of the SUT, by updating data in the model, such as new vulnerabilities that are found or new patches that are released.

Each time that a new vulnerability is found, or an asset is patched (i.e., via an update), the initial EDG is updated to reflect those changes. An example of this process can be seen in Figure 6.

At time *t*0, the initial graph of the SUT *A* is depicted in Figure 6. Because there is no vulnerability at that time, this graph can be simplified using the cluster notation, with just a cluster containing all assets. At time *t*1, a new vulnerability that affects the asset *a*2 is discovered. At time *t*2, the asset *a*2 is updated. This action creates a new version of asset *a*2, asset *a*3. Because the vulnerability was not corrected in the new update, both versions contain the vulnerability that was initially presented in asset *a*2. Finally, at time *t*3, the asset *a*3 is updated to its new version *a*4, and the vulnerability is corrected.

This approach enables a further analysis of the SUT, including updated data, according to new vulnerabilities that are found or new patches that are released.

**Figure 6.** Representation of the temporal behavior in the graphical model using the two kinds of dependencies of the model. It is worth mentioning that these graphs could be further simplified by taking advantage of the cluster notation, as shown at the bottom of this figure.

### 3.3.3. Patching Policies Prioritization Support

The proposed model is not only able to include known vulnerabilities associated with an asset, but it also provides a relative importance sorting of vulnerabilities by CVSS. Relying on the resulting value, it is possible to assist in the vulnerability patching prioritization process. Furthermore, the presence of an existing exploit for a known vulnerability can be also be taken into account, when deciding which vulnerabilities need to be patched first. A high CVSS value combined with an available exploit for a given vulnerability is a priority when patching.

### **4. Real Use Case**

In this section, we applied the EDG model to analyze the vulnerabilities of the Open-PLC project. For the sake of simplicity, the use case focuses on version one (V1) of OpenPLC. We centered the analysis on two of the assets that compose this version of the project: libssl and nodejs.

OpenPLC is the first functional standardized open-source Programmable Logic Controller (PLC), both in software and hardware [86–89]. It was mainly created for research purposes in the areas of industrial and home automation, the Internet of Things (IoT), and SCADA. Given that it is the only controller that provides its entire source code, it represents an engaging low-cost industrial solution—not only for academic research but also for real-world automation [90,91].

### *4.1. Structure of OpenPLC*

The OpenPLC project consists of three parts:


When installed, the OpenPLC runtime executes a built-in webserver that allows OpenPLC to be configured and new programs for it to run to be uploaded. In this use case, we focused the analysis on the runtime of OpenPLC V1.

### *4.2. Setup Through the Analysis*

Ubuntu Linux was selected as the platform to install the runtime of OpenPLC V1. Ubuntu Linux provides comprehensive documentation, previous versions are accessible, and software dependencies can easily be obtained.

To make the analysis fair, a contemporary operating system was selected, according to the version of Ubuntu that was available at the release time of OpenPLC V1. The Long Term Support (LTS) version was chosen because industry tends to work with the most stable version available of any software and security updates are provided for a longer time. OpenPLC V1 was released in 2016/02/05, so we found that Ubuntu 14.04 LTS was the most suitable version [92]. The setup consisted of OpenPLC installed on 14.04 LTS Ubuntu Linux in a virtual machine. All configuration options were by default.

### *4.3. Building the EDG*

We built the entire EDG for OpenPLC V1, which can be found in Appendix B. Nevertheless, for the sake of clarity, we restricted this analysis in two ways: (1) focusing on two assets, libssl and nodejs; (2) integrating only security updates (discarding updates that introduced more functionalities). Table 3 shows the updates and their date of availability for both libssl [93] and nodejs [94] for Ubuntu 14.04 LTS. There were two security updates available for the amd64 architecture for each asset. Figure 7 illustrates step by step the partials EDG graphs, and Figure 8 shows the final EDG with all the updates merged in a single graph.

**Table 3.** Update information of both libssl and nodejs.


**Figure 7.** Temporal evolution of the EDG for OpenPLC V1 for both libss and nodejs.

**Figure 8.** Final EDG for libssl and nodejs integrating all the updates for Ubuntu Linux 14.04 for amd64 architecture.

*4.4. Analysis of the EDG*

> Using Figure 8 as reference, we can analyze the obtained EDG:

1. Analysis of the induced EDG model: The structure, assets, and dependencies are the focus of this first step. Weobservethatlibsslisusedandnotatthelevelof

 can by nodejs, they are same the hierarchy. So vulnerabilities could propagate upwards through the EDG.


Table 4 shows the root cause for each vulnerability. Using this data, new requirements, test cases, and training activities were proposed (see Appendix C).

**Table 4.** Relationship between vulnerabilities and weaknesses for both libssl and nodejs.


### **5. Conclusions and Future Work**

Vulnerability analysis is a critical task which ensures the security of industrial components. The EDG model that we propose performs continuous vulnerability assessment throughout the entire life cycle of industrial components. The model is built on a directed graph-based structure and a set of metrics based on globally accepted security standards. Metrics can be used by the model to improve the development process of the SUT, enhance its security, and track its status. The key feature of the proposed model is the addition of the temporal dimension in the analysis of vulnerabilities. The location of vulnerabilities can be analyzed in both space (in which asset) and time (their recurrence), which allows the state of the device to be tracked throughout the whole life cycle.

The model was successfully applied to the OpenPLC use case, which demonstrated its advantages, applicability, and potential. The use case showed that the model can assist in updating managemen<sup>t</sup> activities, applying patching policies, launching training activities, and generating new test cases, and requirements. This has significant implications for cybersecurity evaluators, as it can serve as a starting point for identifying vulnerabilities, weaknesses, and attack patterns.

Further research will enhance the EDG by adding a mathematical model to aggregate the values of the CVSS metric for each asset, and a value for the whole SUT. This will enable the comparison of different SUTs over time. More improvements will be made in the prioritization of patching, taking into account the context and the functionalities of the SUT. Finally, historical information about the developers can be integrated into the EDG model to predict future vulnerabilities.

**Author Contributions:** Conceptualization, Á.L.-R., J.L.F. and I.G.; data curation, Á.L.-R.; formal analysis, Á.L.-R. and J.L.F.; funding acquisition, R.I. and J.L.F.; investigation, Á.L.-R.; methodology, Á.L.-R.; project administration, Á.L.-R.; resources, R.I., J.L.F. and I.G.; software, Á.L.-R.; supervision, Á.L.-R. and J.L.F.; validation, Á.L.-R., J.L.F. and I.G.; visualization, Á.L.-R. and J.L.F.; writing—original draft, Á.L.-R.; writing—review and editing, Á.L.-R., Rosa Iglesias, J.L.F. and I.G. All authors have read and agreed to the published version of the manuscript.

**Funding:** This work was partially supported by both the Department of Economic Development and Infrastructures, and the Ayudas Cervera para Centros Tecnológicos gran<sup>t</sup> of the Spanish Centre for the Development of Industrial Technology (CDTI). This work was partially funded by REMEDY project (KK-2021/00091), EGIDA project (CER-20191012), and H2020 (957212).

**Institutional Review Board Statement:** Not applicable.

**Informed Consent Statement:** Not applicable.

**Data Availability Statement:** Not applicable.

**Conflicts of Interest:** The authors declare no conflict of interest.
