**3. Proposed Approach**

In this research work, we propose an EDG model for the continuous assessment of vulnerabilities over time in industrial components. The proposed model is intended to:


To accomplish this task, the proposed model comprises two basic elements: (1) the model itself, which is capable of representing the internal structure of the system under test; (2) a set of metrics, which allow conclusions to be drawn about the origin, distribution, and

severity of vulnerabilities. Both the model and metrics are very flexible and exhibit some properties that make them suitable for industrial components, and can also be applied to enhance the ISA/IEC 62443 standard.

The content in this section is distributed into four sections, namely:


### *3.1. Description of the Model*

The proposed model is based on directed graphs. It requires knowledge of the internal structure of the device to be evaluated (i.e., the assets, both hardware and software, that comprise it and the relationships between them). This section defines the most basic elements that make up the model, the algorithms to build it for any given system, and its graphical representation.

**Definition 1.** *A System Under Test (SUT) (following the denomination in the ISA/IEC 62443 standard [47], the SUT may be an industrial component, a part of an industrial component, a set of industrial components, a unique technology that may never be made into a product, or a combination of these) is now represented by an Extended Dependency Graph (EDG) model G* = (*<sup>A</sup>*, *<sup>V</sup>*, *E*) *that is based on directed graphs, where A and V represent the nodes of the graphs, and E represents its edges or dependencies:*


In other words, the EDG model can represent a system, from its assets to its vulnerabilities, and its dependencies as a directed graph. Assets and vulnerabilities are represented as nodes, whose dependencies are represented as arcs in the graph. The information in the EDG is further enhanced by introducing metrics.

The EDG model of a given SUT will include four types of node and two types of dependency. The graphical representation for each element is shown in Table 1. Figure 1 shows an example of a simple EDG and its basic elements. All of the elements that make up an EDG will be explained in more detail below:

**Figure 1.** Basic elements of an EDG. Note that clusters are not displayed in this figure. For clusters, see Figure 2. For metric definitions, see Section 3.2.

**Figure 2.** Creating clusters. Application of the two proposed criteria to the creation of clusters to simplify the graph, where (**a**) represents the initial EDG: (1) Establishing a threshold to select which vulnerability stays outside the cluster (upper side). In step (**b1**), potential clusters are detected according to the established threshold, while in (**c1**) the final EDG with the generated clusters is shown. The severity value (CVSS) for v31 and v32 is supposed to be lower than the establish threshold. (2) Choosing the absence of vulnerabilities as the criterion to create clusters (lower side). In step (**b2**), nodes with no vulnerability are detected. In (**c2**), the final EDG with the generated clusters is shown.


**Table 1.** Overview of the information that is necessary to define each of the EDG elements.

### 3.1.1. Types of Node


Root nodes (collectively, set *GR*) are a special type of node that represents the whole SUT. Any EDG starts in a root node and each EDG will only have one single root node, with an associated timestamp (*t*) that indicates when the last check for changes was done. This timestamp is formatted following the structure defined in the ISO 8601 standard for date and time [81].

Asset nodes (collectively, set *GA*) represent the assets that comprise the SUT. The EDG model does not impose any restrictions on the minimum number of assets that the graph must have. However, the SUT can be better monitored over time when there is a higher number of assets. Moreover, the results and conclusions obtained will be much more accurate. Nevertheless, each EDG will have as many asset nodes as necessary, and the decomposition of assets can go as far and to as low-level as needed.

Each asset node node will be characterized by the following set of values:


Figure 3 illustrates how the tracking of the versions of an asset using CPE works. On the one hand, version *ai* is the current version of asset *a*. It contains its current CPE value and the CPE of its previous version. On the other hand, *a*2 and *a*1 are previous versions of asset *a*. The last value of *a*1 points to a null value. This indicates that it is the last value in the chain, and therefore the very first version of the asset *a*.

**Figure 3.** Tracking dependencies between the previous and current CPE values for asset *a*.

Known vulnerability nodes (collectively, set *GV*) represent a known vulnerability present in the asset that it relates to. Each asset will have a known vulnerability node for each known vulnerability belonging to that asset. Assets alone cannot tell how severe or dangerous the vulnerabilities might be, so unique characterization of vulnerabilities is crucial [30].

To identify each known vulnerability node, each will be characterized by the following set of features (formally defined in Section 3.2:


Clusters (collectively, set *GS*) are a special type of node that summarizes and simplifies the information contained in a subgraph in an EDG. Figure 2 shows how the clusters work.

To identify each cluster, and to be able to recover the information that they summarize, each is characterized by the data that define each of the elements that they contain: {*CPEprevious*, *CPEcurrent*, *CWEai* (*t*)}, (*CVEai* (*t*), *CVSSvi* (*t*), {*CAPECwi* (*t*)}), and their dependencies.

Two types of criteria can be used to create clusters and to simplify the obtained graph Figure 2:


### 3.1.2. Types of Edge

In the EDG model, edges play a key role in representing dependencies. Two types of edge can be identified:


The possibility of representing old dependencies brings the opportunity to reflect the evolution of the SUT over time. When a new version of an asset is released, or a vulnerability is patched, the model will be updated. Their dependencies will change from a normal dependency to a deprecated asset or vulnerability dependency to reflect that change.

### 3.1.3. Conditions of Application of EDGs

The EDG model is applicable to SUTs that meet the following set of criteria:


### 3.1.4. Steps to Build the Model

This section explains the process and algorithms that were used to build the corresponding EDG of a given SUT. The main scenarios that can be found are also described.

Before extracting useful information about the SUT, the directed graph associated with the SUT has to be built. This comprises several steps, which are described in the following paragraphs (see the flowchart in Figures 4 and 5):

Step 1—Decompose the SUT into assets. For the model to work properly, it relies on the SUT being able to be decomposed into assets. With this in mind, the first step involves obtaining the assets of the SUT, either software or hardware. In the CC, this process is called modular decomposition of the SUT [53]. Ideally, every asset should be represented in the decomposition process, but this is not compulsory for the model to work properly. Each one of the assets obtained in this step will be represented as an asset node. In this step, the dependencies among the obtained assets are also added as normal dependencies.

Step 2—Assign a CPE to each asset. Once the assets and their dependencies have been identified, the next task is to assign the corresponding CPE identifier to each asset. If there is no publicly available information of a certain asset, and therefore, it does not have a CPE identifier, then it is always possible to generate one using the fields described in the CPE naming specification documents [79] for internal use in the model.

Step 3—Add known vulnerabilities to the assets. In this step, the vulnerabilities (*CVEai*(*t*)) of each asset are set. This is done by consulting public databases of known vulnerabilities [34,84] looking for existing vulnerabilities for each asset. When a vulnerability is found, it is added to the model of the SUT, including its dependencies. If there were no known vulnerabilities in an asset, then the asset would become the last leaf of its branch. In this step, the corresponding value of the CVSS of each vulnerability is also added to the model.

Step 4—Assign to each asset its weaknesses and possible CAPECs. After the vulnerabilities, the corresponding weaknesses to each vulnerability (*CWEai*(*t*)) are added, along with the corresponding attack patterns (*CAPECwi*(*t*)) for each weakness. If there is no known vulnerability in an asset, then there will be no weaknesses. Meanwhile, it would be possible to have a known vulnerability in an asset, but no known weakness or attack pattern for that vulnerability. Finally, more than one CAPEC can be assigned to the same weakness. Consequently, it would be common to have a set of possible CAPECs that can be used to exploit the same weakness. It is worth noting that not all of them could be applied in every scenario.

Step 5—Computing Metrics and tracking the SUT. At this point, the EDG of the SUT is completed with all the public information that can be gathered. This last step is to calculate the metrics defined (for further information, see Section 3.2), generate the corresponding reports and track the state of the SUT for possible updates in the information of the model. This step is always triggered when the SUT is updated. This can imply that a new asset can appear, an old asset can disappear, an old vulnerability can be patched, or a new one can appear in the SUT. All of these scenarios will be reflected in the model as they arise during its life cycle.

**Figure 4.** Algorithm to generate the initial EDG of a given SUT.

**Figure 5.** Example of the process of building the EDG model of a given SUT *A*. (**a**) Decompose of the SUT into assets. (**b**) Assign a CPE to each asset. (**c**) Add known vulnerabilities. (**d**) Add weaknesses and attack patterns.
