*[ allpages, angle=55, scale=17, xpos=-70, ypos=50 ] PREPRINT

# A Novel Model for Vulnerability Analysis through Enhanced Directed Graphs
and Quantitative Metrics

1st Ángel Longueira-Romero, 2nd Rosa Iglesias, 3rd Jose Luis Flores
Industrial Cybersecurity
Ikerlan Technology Research Centre (BRTA)
Arrasate/Mondragón, Spain
{alongueira, riglesias<EMAIL_ADDRESS>4th Iñaki Garitano  Dept. of
Electronics and Computing
Mondragon Unibertsitatea
Arrasate/Mondragón, Spain
<EMAIL_ADDRESS>
###### Abstract

Industrial components are of high importance because they control critical
infrastructures that form the lifeline of modern societies. However, the rapid
evolution of industrial components, together with the new paradigm of Industry
4.0, and the new connectivity features that will be introduced by the 5G
technology, all increase the likelihood of security incidents. These incidents
are caused by the vulnerabilities present in these devices. In addition,
although international standards define tasks to assess vulnerabilities, they
do not specify any particular method. Having a secure design is important, but
is also complex, costly, and an extra factor to manage during the lifespan of
the device. This paper presents a model to analyze the known vulnerabilities
of industrial components over time. The proposed model is based on two main
elements: a directed graph representation of the internal structure of the
component, and a set of quantitative metrics that are based on international
security standards; such as, the Common Vulnerability Scoring System (CVSS).
This model is applied throughout the entire lifespan of a device to track
vulnerabilities, identify new requirements, root causes, and test cases. The
proposed model also helps to prioritize patching activities. To test its
potential, the proposed model is applied to the OpenPLC project. The results
show that most of the root causes of these vulnerabilities are related to
memory buffer operations and are concentrated in the libssl library.
Consequently, new requirements and test cases were generated from the obtained
data.

###### Index Terms:

CPE, CVE, CVSS, CWE, CAPEC, directed graph, IACS, cybersecurity, vulnerability
assessment, security metrics, IEC 62443, OpenPLC.

##  I Introduction

Industrial components are the driving force of almost every industrial field,
such as automotive, manufacturing, telecommunications, energy production,
transportation, healthcare, and defense [1, 2, 3, 4, 5, 6]. These types of
components are rapidly evolving [7, 8] and are rapidly increasing in number
[9]:

  * •

Open-source hardware and software, and Commercial Off-The-Shelf (COTS)
components are being integrated to speed up their development.

  * •

They are increasingly connected, providing more advanced connectivity
features, enabling new automation applications, services, and data exchange.

  * •

The complexity of industrial systems is also increasing, thus the complexity
of their software and hardware is also increasing.

The reuse of open-source software components is a de facto industry norm, with
90% of the participants using pre-existing code [10, 11, 12, 13]. Moreover,
Commercial Off-The-Shelf (COTS) components are highly available in the market,
which makes them suitable for speeding up the development of industrial
components [14]. COTS components are used for hardware, software, and
communication interfaces. Thus, vulnerabilities within such components can
create potential entry points for malicious adversaries aiming to disrupt CPS
operations [15]. In addition, the use of COTS components makes it easier than
ever for industrial components to connect among them and to the Internet,
increasing their attack surface even further [16].

Interconnected systems significantly increase the exposure to many security
risks, with critical, environmental and wellbeing impacts. The fifth
generation (5G) of wireless technology for cellular networks will facilitate
an enhanced Internet connectivity and accommodate the connection of multiple
devices through the IoT architecture, which will open further the window of
exposure to any threat [17, 9, 6, 18]. Furthermore, this increased
connectivity is part of the new paradigm of Industry 4.0. Thus, technologies
such as the Internet of Things (IoT) [19, 20, 21, 18], cloud computing,
Artificial Intelligence (AI) [21, 22], and big data (among others) are being
extensively used [23, 24, 25, 26, 27, 28], which will again open even further
the door for potential attacks.

Industrial components are working on an evolving ecosystem that becomes more
complex over time: the use of COTS components and open-source software, the
enhanced connectivity among them and to the Internet, and the integration of
technologies such as IoT, AI, and big data. To face this scenario, industrial
components are also becoming more complex. Complexity is a critical aspect of
industrial components design, because it is closely related to the number of
vulnerabilities [29, 30].

Security is turning into a key issue in an environment where security is
traditionally addressed as Security through obscurity, and treated as an add-
on feature instead of being a priority during the development stage [31, 32,
33, 34]. Numerous attacks have been reported targeting industrial enterprises
across the globe since 2010 [35], and an exponential rise in such attacks is
predicted for the upcoming years [36, 37].

Under this scenario, a model for continuous vulnerability assessment is needed
to manage the security of existing industrial components during their lifespan
to deal with emerging threats [38, 39]. That is to say, performing a
vulnerability analysis at a single point in time (e.g., during development or
when a product has been released) is not enough for industrial components and
their large lifespan has to be considered [40, 41]. Such a model should be
able to compute the number and distribution of vulnerabilities among the
assets of an industrial component, to detect and classify security
vulnerabilities for further remediation or mitigation actions. Moreover, this
model should be able to integrate other metrics, such as the severity value of
vulnerabilities. Severity is closely related to risk assessment and threat
model activities. So this value can help in early steps (e.g., design). By
incorporating information on their severity, more metrics could be developed
to track and enhance the development of industrial components, which will
create a more precise threat model [42]. Metrics help in prioritizing the
patching of vulnerabilities, obtaining their root causes, and monitoring the
evolution of industrial components, not only during their development, but
also throughout their lifespan. Finally, the model should be aligned with the
most relevant cybersecurity standards to enhance evaluation tasks that they
propose or even to cover gaps. Furthermore, both software and hardware should
be evaluated because it is of high importance in industrial components, given
that the strong bonding between hardware and software is an intrinsic feature
of industrial components [43, 44, 45, 14].

Although great efforts are being made to develop new and better ways to
analyze vulnerabilities [46, 47], to measure them (e.g., Common
Vulnerabilities and Exposures (CVE), Common Vulnerability Scoring System
(CVSS) [48, 49, 50, 51], or Common Weakness Enumeration (CWE) [52, 53], or to
aggregate them [54]), to the best of our knowledge, existing models do not
cover industrial components. To set the first steps toward filling this gap,
this research work proposes a model with the aim of performing a continuous
vulnerability assessment to determine the source and nature of
vulnerabilities, and enhance the security of industrial components.

The proposed model is built on top of a directed graph-based structure, and a
set of metrics based on globally accepted security standards. This model is
intended to be used to help manage the analysis of known vulnerabilities,
their root causes, and their impact on the entire life cycle of an industrial
component. The internal structure, in terms of assets, of an industrial
component is represented using directed graphs: different types of nodes
represent vulnerabilities for both software and hardware assets. For further
analysis, metrics were developed integrating internationally recognized
security standards, such as Common Platform Enumeration (CPE) [55, 56, 57],
CVE [49], CVSS [51], CWE [52], and Common Attack Pattern Enumeration and
Classification (CAPEC) [58, 59]. By using the proposed metrics, the evaluator
is capable of identifying the source and nature of the detected
vulnerabilities, and help in prioritizing their patching. Finally, the work
presented here is also aligned with the ISA/IEC 62443 standard “Security for
industrial automation and control systems”.

This paper is structured as follows: First, the related work is reviewed in
Section II. Then, the main pieces of the proposed model are defined in Section
III. Second, to demonstrate the potential of this proposal, the proposed model
is applied to a real use case (Section IV. Finally, conclusions and future
work of this research are described in Section V.

##  II Related Work

This section will review the current status of vulnerability assessment. This
review aims to find similar approaches from the literature, including the
current standard and metrics.

###  II-A Vulnerability Analysis in Security Standards

Industry is currently making a significant effort to incorporate security
aspects into the development of industrial components, which has led to a set
of standards, such as the ISA/IEC 62443. ISA/IEC 62443 is a family of
standards which includes several parts, where Part 4 is focused on the
specific development of components (e.g., embedded systems, host systems,
network devices, and software applications). This standard, in which certain
parts are not yet fully defined, has been inspired by previous standards that
have a long tradition of use, such as the Common Criteria. Consequently, this
section will not only describe the ISA/IEC 62443 standard, but will also
analyze the Common Criteria. This review is focused on how these standards
conduct vulnerability analysis, the use of metrics, their management of the
life cycle of the device, the techniques that they propose, and the security
evaluation of both software and hardware.

####  II-A1 ISA/IEC 62443

Based on the ISA-99 document, the ISA/IEC 62443 constitutes a series of
standards, technical reports, and related information that define the
procedures and requirements for implementing electronically secure Industrial
Automation and Control Systems (IACSs) [60]. As expressed by this standard,
security risk management shall jointly and collaboratively be addressed by all
the entities involved in the design, development, integration, and maintenance
of the industrial and/or automation solution (including subsystems and
components) to achieve the required security level [61].

This joint effort is reflected in the organization of the documents of the
standard, which is divided into four parts:

  1. 1.

Part 1 - General: Provides background information such as security concepts,
terminology and metrics;

  2. 2.

Part 2 - Policies and procedures: Addresses the security and patch management
policies and procedures;

  3. 3.

Part 3 - System: Provides system development requirements and guidance;

  4. 4.

Part 4 - Component: Provides product development and technical requirements,
which are intended for product vendors.

The ISA/IEC 62443-4-1 technical document is divided into eight practices,
which specify the secure product development life cycle requirements for both
the development and the maintenance phases [62]. “Practice 5 - Security
verification and validation testing” (SVV) section of this document specifies
that a process shall be employed to identify and characterize potential
security vulnerabilities in the product, including known and unknown
vulnerabilities [63, 64]. Two requirements in Practice 5 are in charge of the
task of analyzing vulnerabilities, as follows:

  * •

Requirement SVV-3. Vulnerability Testing [62]. This requirement states that a
process shall be employed to perform tests that focus on identifying and
characterizing potential and known security vulnerabilities in the product
(i.e., fuzz testing, attack surface analysis, black box known vulnerability
scanning, software composition analysis, and dynamic runtime resource
management testing).

  * •

Requirement SVV-4. Penetration Testing [62]. This requirement states that a
process shall be employed to identify and characterize security-related issues
via tests that focus on discovering and exploiting security vulnerabilities in
the product (i.e., penetration testing).

Although the ISA/IEC 62443-4-1 document considers the possibility of analyzing
and characterizing the vulnerabilities of an industrial component, it does not
propose a technique to perform this task, but instead refers to other
standards for vulnerability handling processes [65]. In addition, it does not
indicate how the data obtained from the analysis should be interpreted, and it
does not define metrics or reference values for the current state of
compliance with the requirement. Finally, it does not take into account
neither the dependencies among the assets of the industrial component
(dependency trees), nor their evolution of the number of vulnerabilities over
time.

####  II-A2 Common Criteria

The Common Criteria (CC) for Information Technology Security Evaluation
(ISO/IEC 15408) is an international standard that has a long tradition in
computer security certification [66]. CC is a framework which provides
assurance that the processes of specification, implementation, and evaluation
of a computer security product have been conducted in a rigorous, standard,
and repeatable manner at a level that is commensurate with the target
environment for use.

To describe the rigor and depth of an evaluation, the CC defines seven
Evaluation Assurance Levels (EALs) on an increasing scale [66], from EAL1 (the
most basic) to EAL7 (the most stringent security level). It is important to
notice that the EAL levels do not measure security itself. Instead, emphasis
is given to functional testing, confirming the overall security architecture
and design, and performing some testing techniques (depending on the EAL to be
achieved).

The CC defines five tasks in the Vulnerability Assessment class, which manage
the deepness of the vulnerability assessment. The higher the EAL to be
achieved, the greater the number of tasks in the list to be performed [67]:

  1. 1.

Vulnerability survey,

  2. 2.

Vulnerability analysis,

  3. 3.

Focused vulnerability analysis,

  4. 4.

Methodical vulnerability analysis, and

  5. 5.

Advanced methodical vulnerability analysis.

Every task checks for the presence of publicly known vulnerabilities.
Penetration testing is also performed. The main difference among the five
levels of vulnerability analysis described here is the deepness of the
analysis of known vulnerabilities and the penetration testing.

The CC scheme defines the general activities, but it does not specify how to
perform them, therefore no technique for analyzing vulnerabilities is
proposed. The evaluator decides the most appropriated techniques for each test
in each scenario and for each device, which adds a large degree of
subjectivity to the evaluation. Furthermore, dependencies among
vulnerabilities and assets are not considered in the analysis. Moreover, the
CC does not define a procedure to manage the life cycle of the device. In
other words, when updated, the whole device has to be reevaluated [68, 31, 69,
70]. Finally, although the usage of metrics is encouraged by the CC, it does
not propose any explicitly defined metric to be used during the evaluation.

###  II-B Vulnerability Analysis Methodologies

Vulnerability analysis is a key step towards the security evaluation of a
device. Consequently, many research efforts have been focused on solving this
issue. In this subsection, the most relevant works related to vulnerability
analysis are reviewed.

Homer et al. [71] present a quantitative model for computer networks that
objectively measures the likelihood of a vulnerability. Attack graphs and
individual vulnerability metrics, such as CVSS, and probabilistic reasoning
are applied to produce a sound risk measurement. However, the main drawback is
that their work is only applicable to computer networks. Although they propose
new metrics based on the CVSS for probabilistic calculations, they do not
integrate standards such as CAPEC to enhance their approach centered on
possible attacks and privilege escalation. They also fail to establish a
relationship among existing vulnerabilities, and they fail to obtain the
source problem causing each vulnerability.

Zhang et al. [72, 73] developed a quantitative model that can be used to
aggregate vulnerability metrics in an enterprise network based on attack
graphs. Their model measures the likelihood that breaches can occur within a
given network configuration, taking into consideration the effects of all
possible interplays between vulnerabilities. This research is centered on
computer networks, using attack graphs. Although the proposed model is capable
of managing shared dependencies and cycles, only CVSS-related metrics are
used. Moreover, this model assumes that the attacker knows all of the
information in the generated attack graphs. Finally, the method that they
proposed for the aggregation of metrics is only valid for attack graphs, and
is not valid for vulnerability analysis.

George et al. [74] propose a graph-based model to address the security issues
in Industrial IoT (IIoT) networks. Their model is useful because it represents
the relationships among entities and their vulnerabilities, serving as a
security framework for the risk assessment of the network. Risk mitigation
strategies are also proposed. Finally, the authors discuss a method to
identify the strongly connected vulnerabilities. However, the main drawback of
this work is that each node of the generated attack graph represents a
vulnerability instead of representing a device or an asset of that device.
This leads to a loss of information in the analysis, because there is no way
to know which vulnerability belongs to which device. Moreover, these methods
need to know the relationships among present vulnerabilities in the devices.
This information is not trivially obtained, and a human in the loop is needed.
The proposals of [75] and [76] follow a similar graph-based approach to study
the effects of cascade failures in the power grid, and a subway network.

Poolsappasit et al. [77] propose a risk management framework using Bayesian
networks that enables a system administrator to quantify the chances of
network compromise at various levels. The authors are able to model attacks on
the network, and also to integrate standardized information of the
vulnerabilities involved, such as their CVSS score. Although their proposed
model lends itself to dynamic analysis during the deployed phase of the
network, these results can only be applied to computer networks. Meanwhile,
the prior probabilities that are used in the model are assigned by network
administrators, and hence are subjective. The proposed model also has some
issues related to scalability.

Muñoz-González et al. [78] propose the use of efficient algorithms to make an
exact inference in Bayesian attack graphs, which enables static and dynamic
network risk assessments. This model is able to compute the likelihood of a
vulnerability, and can be extended to include zero-day vulnerabilities,
attacker’s capabilities, or dependencies between vulnerability types. Although
this model is centered on studying possible attacks, it fails to integrate
standards (such as CAPEC) that are related to attack patterns. Moreover, the
generated graphs are focused on privilege escalation, trust, and users, rather
than including information about vulnerabilities and the analyzed device.

Liu et al. [79] carry out a detailed assessment of vulnerabilities in IoT-
based critical infrastructures from the perspectives of applications,
networking, operating systems, software, firmware, and hardware. They
highlight the three key critical infrastructure IoT-based cyber-physical
systems (i.e., smart transportation, smart manufacturing, and smart grid).
They also provide a broad collection of attack examples upon each of the key
applications. Finally, the authors provide a set of best practices and address
the necessary steps to enact countermeasures for any generic IoT-based
critical infrastructure system. Nevertheless, their proposal is focused on
attacks and countermeasures, and it leaves aside the inner analysis of the
targets. Continuous evaluation over time is not considered in this proposal,
and no enhancements of the development process are generated.

Hu et al. [80] Hu et al. propose a network security risk assessment method
that is based on the improved hidden Markov model (I-HMM). The proposed model
reflects the security risk status in a timely and intuitive manner, and it
detects the degree of risk that different hosts pose to the network. Although
this is a promising approach, it is centered on computer networks and is at a
higher abstraction level. No countermeasure or enhancement in the development
process is proposed or generated.

Zografopoulos et al. [81] provide a comprehensive overview of the Cyber-
Physical System (CPS) security landscape, with an emphasis on Cyber-Physical
Energy Systems (CPES). Specifically, they demonstrate a threat modeling
methodology to accurately represent the CPS elements, their interdependencies,
as well as the possible attack entry points and system vulnerabilities. They
present a CPS framework that is designed to delineate the hardware, software,
and modeling resources that are required to simulate the CPS. They also
construct high-fidelity models that can be used to evaluate the system’s
performance under adverse scenarios. The performance of the system is assessed
using scenario-specific metrics. Meanwhile, risk assessment enables system
vulnerability prioritization, while factoring the impact on the system’s
operation. Although this research work is comprehensive, it is focused on
enhancing the existing adversary and attack modeling techniques of CPSs of the
energy industry. Moreover, their model does not integrate the internal
structure of the target of evaluation, and it does not take both software and
hardware into account for the evaluation. Continuous evaluation over time is
not considered. Finally, they do not propose countermeasures, or any kind of
mechanism to enhance the security or the development of the CPSs.

Most of the works reviewed here are more focused on modeling threats and
attacks. They do not propose solutions to protect CPSs, enhancing their
development, or manage their update throughout their whole life cycle. It is
worth noting that they are still more focused on software evaluation, while
hardware is usually neglected in their proposals.

As shown in this review, most of the research has adopted dependency trees,
attack graphs, or directed graphs as the main tool to manage and assess
vulnerabilities in computer networks. Graphs are an efficient technique to
represent the relationships between entities, and they can also effectively
encode the vulnerability relations in the network. Furthermore, the analysis
of the graph can reveal the security-relevant properties of the network. For
fixed infrastructure networks, graphical representations, such as attack
graphs, are developed to represent the possible attack paths by exploiting the
vulnerability relationships. For these reasons, vulnerability analysis
techniques based on directed graphs are frequently found in the literature
[82]. However, despite their potential, these analysis techniques have been
relegated to vulnerability analysis in computer networks. Graph-based analysis
has rarely been applied to industrial components.

###  II-C Security Metrics

Standards of measurement and metrics are a powerful tool to manage security
and for making decisions [83, 84, 85]. If carefully designed and chosen,
metrics can provide a quantitative, repeatable, and reproducible value. This
value is selected to be related to the property of interest of the systems
under test (e.g., number and distribution of vulnerabilities). The use of
metrics enables results to be compared over time, and among different devices.
In addition, they can also be used to systematically improve the security
level of a system, or to predict this security level in a future point in
time.

Although the capabilities of metrics have been demonstrated, they are not free
of drawbacks. In our previous research work [85], we performed a systematic
review of the literature and standards. To detect possible gaps, our objective
was to find which types of metrics have been proposed and in which fields have
been applied. This research work concludes that, in general, standards
encourage the use of metrics, but they do not usually propose any specific set
of metrics. If metrics are proposed, then they are conceived to be applied at
a higher level (i.e., organization level), and then cannot be applied to
industrial components. This type of metric is usually related to measuring the
return on security investment, security budget allocation, and reviewing
security related documentation.

Our previous results also highlight that scientific papers have focused their
efforts on software-related metrics: $77.5\%$ of the analyzed metrics were
exclusively applicable to software (e.g., lines of code, number of functions
and so on), whereas only $0.6\%$ were related exclusively to hardware (e.g.,
side-channel vulnerability factor metric). In addition, $14.8\%$ of them could
be applied to both software and hardware (e.g., the historically exploited
vulnerability metric that measures the number of vulnerabilities exploited in
the past), and the remaining $7.1\%$ are focused on other aspects, such as
user usability. This shows that there is a clear lack of hardware security
metrics in the literature, and the main contributions are centered in software
security.

Other research works also reveal common problems across security metrics [86,
87]:

  * •

Hardly any security metric has a solid theoretical foundation or empirical
evidence in support of the claimed correlation.

  * •

Many security metrics lack an adequate description of the scale, unit, and
reference values to compare and interpret the results.

  * •

Only a few implementations or programs were available to test these security
metrics, and only one of the analyzed papers performed some kind of
benchmarking or comparison with similar metrics.

  * •

The information provided in the analyzed papers is insufficient to understand
whether the proposed metrics are applicable in a given context, or how to use
them.

Under this scenario, it seems reasonable that future research should be
focused on the development of a convincing theoretical foundation, empirical
evaluation, and systematic improvement of existing approaches, in an attempt
to solve the lack of widely-accepted solutions. In this research work, metrics
constitute a key element. They are developed to analyze the distribution of
vulnerabilities and to track their evolution over time.

##  III Proposed Approach

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

  * •

Identify the root causes and nature of vulnerabilities, which will enable the
extraction of new requirements and test cases.

  * •

Support the prioritization of patching.

  * •

Track vulnerabilities during the whole lifespan of industrial components.

  * •

Support the development and maintenance of industrial components.

To accomplish this task, the proposed model comprises two basic elements: the
model itself, which is capable of representing the internal structure of the
system under test; and 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:

  1. 1.

Model: The proposed model is explained, together with the systems in which it
can be applied and the algorithms that are used to built it.

  2. 2.

Metrics: Metrics are a great tool to measure the state of the system and to
track its evolution. The proposed metrics and their usage are described in
this section.

  3. 3.

Properties: The main features of the proposed model and metrics (e.g.,
granularity of the analysis, analysis over time, and patching policy
prioritization support) are described in detail.

  4. 4.

Applicability: Even though the reviewed standards exhibit some gaps, the
proposed model aims to serve as the first step towards generating a set of
tools to perform a vulnerability analysis in a reliable and continuous way.
This last section will discuss the requirements of the ISA/IEC 62443-4-1 that
can be enhanced using our model.

###  III-A Description of the Model

The model that is proposed in this research work is based on directed graphs,
and 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 give system, and its
graphical representation.

######  Definition III.1.

A System Under Test (SUT111Following the denomination in the ISA/IEC 62443
standard [60], 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=\left(\langle A,V\rangle,E\right)$
that is based on directed graphs, where $A$ and $V$ represent the nodes of the
graphs, and $E$ represents its edges or dependencies:

  * •

$A=\\{a_{1},...,a_{n}\\}$ represents the set of assets in which the SUT can be
decomposed, where $n$ is the total number of obtained assets. An asset $a$ is
any component of the SUT that supports information-related activities, and
includes both hardware and software [88, 89, 90]. Each asset is characterized
by its corresponding CPE identifier, while its weaknesses are characterized by
the corresponding CWE identifier. In the EDG model, the assets are represented
by three types of nodes in the directed graphs (i.e., root nodes, asset nodes
and cluster).

  * •

$V=\\{v_{1},...,v_{q}\\}$ represents the set of known vulnerabilities that are
present in each asset of $A$, where $q$ is the total number of
vulnerabilities. They are characterized by the corresponding CVE and CVSS
values. In the EDG model, vulnerabilities are represented using two types of
nodes in the directed graphs (i.e., known vulnerability nodes and clusters).

  * •

$E=\\{e_{ij}|\forall i,j\in\\{1,...,n+q\\}\text{ such that }i\neq j\\}$
represents the set of edges or dependencies among the assets, and between
assets and vulnerabilities. $e_{ij}$ indicates that a dependency relation is
established from asset $a_{i}$ to asset $a_{j}$. Dependencies are represented
using two different types of edges in the EDG (i.e., normal dependency and
deprecated asset/updated vulnerability edges).

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 I.
Fig. 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 Fig. 3. For metrics definition, see Section
III-B. TABLE I: Overview of the information that is necessary to define each
of the EDG elements.

SYMBOL | NOTATION | MEANING | VALUES
---|---|---|---
$\square$ | $A(t)$ |  | Root Node /
---
Device Node
$CPE_{current}$
$\bigcirc$ | $a(t)$ | Asset Node | $CPE_{previous},CPE_{current},CWE_{a_{i}}(t)$
| $\underline{a}(t)$ | cluster | $\\{CPE_{previous},CPE_{current},CWE_{a_{i}}(t)\\},\\{CVE_{a_{i}}(t),CVSS_{v_{i}}(t),CAPEC_{w_{i}}(t)\\},\\{Dependencies\\}$
$\blacktriangledown$ | $v(t)$ | Known Vulnerability Node | $CVE_{a_{i}}(t),CVSS_{v_{i}}(t),CAPEC_{w_{i}}(t)$
$\longrightarrow$ | $e(t)$ | Dependency Relation | —
$\dashrightarrow$ | $e(t)$ |  | Updated Asset /
---
Patched Vulnerability
—

####  III-A1 Types of Node

The EDG model uses four types of node:

  * •

Root nodes represent the SUT,

  * •

Asset nodes represent each one of the assets of the SUT,

  * •

Known vulnerability nodes represent the vulnerabilities in the SUT, and

  * •

Clusters summarize the information in a subgraph.

Root nodes (collectively, set $G_{R}$) are a special type of node that
represent 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
[91].

Asset nodes (collectively, set $G_{A}$) 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 known vulnerability node will be characterized by the following set of
values:

  * •

$CPE_{current}$: Current value for the CPE. This points to the current version
of the asset it refers to.

  * •

$CPE_{previous}$: Value of the CPE that identifies the previous version of
this asset. This will be used by the model to trace back all the versions of
the same asset over time, from the current version, to the very first version.

  * •

$CWE_{a_{i}}(t)$: Set of all the weaknesses that are related to the
vulnerabilities present in the asset. The content of this list can vary
depending on the version of the asset.

Fig. 2 illustrates how the tracking of the versions of an asset using CPE
works. On the one hand, version $a_{i}$ 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 2: Tracking dependencies between the previous and current CPE values
for asset $a$.

Known vulnerability nodes (collectively, set $G_{V}$) 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 [74].

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

  * •

$CVE_{a_{i}}(t)$: This serves as the identifier of a vulnerability of asset
$a_{i}$.

  * •

$CVSS_{v_{i}}(t)$: This metric assigns a numeric value to the severity of
vulnerability $v_{i}$. Each CVE has a corresponding CVSS value.

  * •

$CAPEC_{w_{i}}(t)$: Each vulnerability (CVE) is a materialization of a
weakness (CWE) $w_{i}$ that can be exploited using a concrete attack pattern
(CAPEC). In many cases, each CWE has more than one CAPEC associated.
Consequently, this field is a set that contains all the possible attack
patterns that can exploit the vulnerability that is being analyzed.

Clusters (collectively, set $G_{S}$) are a special type of node that
summarizes and simplifies the information contained in a subgraph in an EDG.
Fig. 3 shows how the clusters work.

Figure 3: Creating clusters. Application of the two proposed criteria to the
creation of clusters to simplify the graph: (1) Establishing a threshold to
select which vulnerability stays outside the cluster (upper side). (2)
Choosing the absence of vulnerability as the criterion to create clusters
(lower side). The severity value (CVSS) for $v_{211}$ and $v_{212}$ is
supposed to be lower than the establish threshold.

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: $\\{CPE_{previous},CPE_{current},CWE_{a_{i}}(t)\\}$,
$\left(CVE_{a_{i}}(t),CVSS_{v_{i}}(t),\\{CAPEC_{w_{i}}(t)\right)\\}$, and
their dependencies.

Two types of criteria can be used to create clusters and to simplify the
obtained graph (Fig. 3:

  1. 1.

Absence of vulnerabilities: Using this criterion, clusters will group all
nodes that contain no associated vulnerabilities.

  2. 2.

CVSS score below a certain threshold: With this criterion, a threshold for the
CVSS scores will be chosen. Nodes whose CVSS score is less than the defined
threshold will be grouped into a cluster.

####  III-A2 Types of Edge

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

  * •

Normal dependencies relate two assets, or an asset and a vulnerability. They
represent that the destination element depends on the source element.
Collectively, they are known as set $G_{D}$.

  * •

Deprecated asset or patched vulnerability dependencies indicate when an asset
or a vulnerability is updated or patched. They represent that the destination
element used to depend on the source element. Collectively, they are known as
set $G_{U}$.

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 then from a normal dependency to a deprecated asset
or vulnerability dependency to reflect that change.

####  III-A3 Conditions of Application of EDGs

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

  * •

Software and hardware composition: In our approach, the model is created by
means of a white-box analysis. The absence or impossibility to perform a
white-box analysis limits the ability to create an accurate model. Some
knowledge about the internal structure and code is expected. This information
is usually only known by the manufacturer of the component, unless the
component is publicly available or open-source. It should be also possible to
decompose the SUT into simpler assets to generate a relevant EDG.

  * •

Existence of publicly known vulnerabilities: The EDG model focuses on known
vulnerabilities. This is not critical because many industrial components use
commercial or open-source elements. The SUT must be composed of assets for
which public information is available. If the majority of SUT assets are
proprietary, or the SUT is an ad hoc development that is never exposed, then
the generated EDG will not evolve. Therefore, the analysis will not be
relevant.

####  III-A4 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 Fig. 4, and
Fig. 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
[66]. 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 [56] for internal use in the model.

Step 3 — Add known vulnerabilities to the assets. In this step, the
vulnerabilities ($CVE_{a_{i}}(t)$) of each asset are set. This is done by
consulting public databases of known vulnerabilities [49, 92] 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
($CWE_{a_{i}}(t)$) are added, along with the corresponding attack patterns
($CAPEC_{w_{i}}(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 III-B.), generating the corresponding reports, and tracking 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 give SUT. Figure 5:
Example of the process of building the EDG model of a given SUT $A$.

###  III-B Security Metrics

The EDG model that was proposed in the previous sections is by itself capable
of representing the internal structure of the SUT, and it can display it
graphically for the user. This representation not only includes the internal
assets of the SUT, but it also captures their relationships, existing
vulnerabilities, and weaknesses. Moreover, assets, vulnerabilities, and
weaknesses are easily identified using their corresponding CPE, CVE, and CWE
values, respectively. All together, this constitutes a plethora of information
that the model can use to improve the development and maintenance steps of the
SUT, enhance its security, and track its status during its whole life cycle.
Metrics are a great tool to integrate these features into the model.

Metrics can serve as a tool to manage security, make decisions, and compare
results over time. They can also be used to systematically improve the
security level of an industrial component or to predict its security level in
a future point in time.

In this section, the basic definitions that serve as the foundation of the
metrics are described. Then, the proposed metrics are introduced to complement
the functionality of the EDG model. The main feature of these metrics is that
they all depend on time as a variable, so it is possible to capture the actual
state of the SUT, track its evolution over time, and compare the results.

####  III-B1 Basic Definitions

In this section, the basic concepts on which the definitions of the metrics
will be based are formalized.

######  Definition III.2.

The set of all possible weaknesses at a time $t$ is represented as $CWE(t)$,
where $CWE(t)=\\{cwe_{1},...,cwe_{m}\\}$, and where $m$ is the total number of
weaknesses at time t. This set contains the whole CWE database defined by
MITRE [52].

######  Definition III.3.

The set of all of the possible vulnerabilities at a time $t$ is represented as
$CVE(t)$, where $CVE(t)=\\{cve_{1},...,cve_{p}\\}$, and where $p$ is the total
number of vulnerabilities. This set contains the whole CVE database defined by
MITRE [49].

######  Definition III.4.

The set of all possible attack patterns at a time $t$ is represented as
$CAPEC(t)$, where $CAPEC(t)=\\{capec_{1},...,capec_{q}\\}$, and where $q$ is
the total number of attack patterns at time t. This set contains the whole
CAPEC database defined by MITRE [58].

######  Definition III.5.

The set of weaknesses of an asset $a_{i}$ at a time $t$ is defined as
$CWE_{a_{i}}(t)=\\{cwe_{j}|cwe_{j}\text{ is in the asset }a_{i}\text{ at time
}t\land cwe_{j}\in CWE(t)\land\forall k\neq j,cwe_{j}\neq cwe_{k}\\}$. From
this expression, the set of all the weaknesses of a particular asset
throughout its life cycle is defined as
$CWE_{a_{i}}=\bigcup_{t=1}^{T}CWE_{a_{i}}(t)$ where $|CWE_{a_{i}}|$ is the
total number of non-repeated weaknesses in its entire life cycle.

######  Definition III.6.

The set of vulnerabilities of an asset $a_{i}$ at a time $t$ is defined as
$CVE_{a_{i}}(t)=\\{cve_{j}|cve_{j}\text{ is in the asset }a_{i}\text{ at time
}t\land cve_{j}\in CVE(t)\\}$. From this expression, the set of
vulnerabilities of an asset throughout its entire life cycle is defined as
$CVE_{a_{i}}=\bigcup_{t=1}^{T}CVE_{a_{i}}(t)$ where $|CVE_{a_{i}}|$ is the
total number of vulnerabilities in its entire life cycle.

######  Definition III.7.

The set of weaknesses of a SUT $A$ with $n$ assets at a time $t$ is defined
as:

$CWE_{A}(t)=\bigcup_{i=1}^{n}CWE_{a_{i}}(t)$ (1)

######  Definition III.8.

The set of vulnerabilities of a SUT $A$ with $n$ assets at a time $t$ is
defined as:

$CVE_{A}(t)=\bigcup_{i=1}^{n}CVE_{a_{i}}(t)$ (2)

######  Definition III.9.

The set of vulnerabilities associated to the weakness $cwe_{j}$ and to the
asset $a_{i}$ at a time $t$ is defined as:

$\begin{split}CVE_{a_{i}|cwe_{j}}(t)=\\{cve_{k}|cve_{k}\text{ associated to
weakness }\\\ cwe_{j}\text{ and to asset }a_{i}\text{ at time
}t\\}\end{split}$ (3)

It is worth noting that CWE is used as a classification mechanism that
differentiates CVEs by the type of vulnerability that they represent. A
vulnerability will usually have only one associated weakness, and weaknesses
can have one or more associated vulnerabilities [93].

######  Definition III.10.

The partition $j$ of an asset $a_{i}$ at time $t$ conditioned by a weakness
$cwe_{k}$ is defined as
$CVE_{a_{i}|cwe_{k}}(t)=\\{cwe_{l}|cwe_{l}=cwe_{k}\land cwe_{l}\in
CVE_{a_{i}}(t)\\}$

######  Definition III.11.

The partition $j$ of the SUT $A$ at time $t$ conditioned by a weakness
$cwe_{k}$ is defined as $CVE_{A|cwe_{k}}(t)=\\{cwe_{l}|cwe_{l}=cwe_{k}\land
cwe_{l}\in CVE_{A}(t)\\}$

######  Definition III.12.

The set of attack patterns associated to a weakness $w_{i}$ at a time $t$ is
defined as $CAPEC_{w_{i}}(t)=\\{capec_{j}|capec_{j}\text{ can exploit weakness
}w_{i}\text{ at time }t\land capec_{j}\in CAPEC(t)\\}$.

######  Definition III.13.

$M=\\{m_{1},...,m_{r}\\}$ represents the set of metrics that are defined in
this research work based on the EDG model, where $r$ is the total number of
metrics. This set can be extended, defining more metrics according to the
nature of the SUT.

####  III-B2 Metrics

This section will describe the metrics that were defined based on the EDG
model and the previous definitions. Although it might seem trivial, the most
interesting feature of these metrics is that they all depend on time. Using
time as an input variable for the computation of the metrics opens the
opportunity to track results over time, compare them, and analyze the
evolution of the status of the SUT. Furthermore, some metrics take advantage
of time to generate an accumulated value, giving information about the life
cycle of the SUT. Table II shows all of the proposed metrics, their
definition, and their reference values.

TABLE II: Proposed metrics for the model.

METRIC |  DEFINITION |  REFERENCE VALUE
---|---|---
VULNERABILITIES | $M_{0}(A)=\frac{|CVE_{A}(t)|}{n(t)}$ |  Arithmetic mean of vulnerabilities in the SUT $A$, where $n(t)$ is the number of assets in a SUT at a time $t$. $M_{0}$ shows how many vulnerabilities would be present in each asset if they were evenly distributed among the assets of the SUT. The result of $M_{0}$ can serve as a preliminary analysis of the SUT, related to the criticality of its state. |  $M_{0}<1$: The number of vulnerabilities is lower than the number of assets. $M_{0}\geq 1$: Every asset has at least one vulnerability.
$M_{1}(A,t)=|CVE_{A}(t)|$ |  Number of vulnerabilities in a SUT $A$ at time $t$. |  Ideally, the values of $M_{2}$ should be zero (no vulnerability in $A$), but the lower the value of $M_{2}$, the better.
$M_{2}(A)=\sum_{t=1}^{T}|CVE_{A}(t)|=\sum_{t=1}^{T}M_{1}(A,t)$ |  Number of vulnerabilities in a SUT $A$ throughout its entire life cycle $T$. This metric computes the accumulated value of the number of vulnerabilities of a SUT throughout its entire life cycle. |  The lower the value of $M_{3}$, the better.
$M_{3}(a_{i},t)=|CVE_{a_{i}}(t)|$ |  Number of vulnerabilities in an asset $a_{k}$ at time $t$ The values of $M_{3}$ can be useful during a vulnerability analysis, or when performing a penetration test, to identify the asset with more vulnerabilities. |  Ideally, the value of $M_{5}$ should be zero.
$M_{4}(a_{k},t)=\frac{|CVE_{a_{k}}(t)|}{\sum_{i=1}^{n}|CVE_{a_{i}}(t)|}$ |  Relative frequency of vulnerabilities of the asset $a_{k}$ at a time $t$. |  Ideally, the value of $M_{6}$ should be zero, or at least $M_{6}\leq\frac{1}{n(t)}$, being $n(t)$ the number of assets in the SUT. This value can also be expressed as the percentage of vulnerabilities of asset $a_{i}$ respect to the total number of vulnerabilities in the SUT, $M_{6}(a_{k},t)=\frac{|CVE_{a_{k}}(t)|}{\sum_{i=1}^{n}|CVE_{a_{i}}(t)|}\text{\textperiodcentered}100$
$M_{5}(a_{i},cwe_{j},t)=|CVE_{a_{i}|cwe_{j}}(t)|$ |  Multiplicity of weakness $cwe_{j}$ of the asset $a_{i}$ at a time $t$. This metric represents the number of times a weakness is present among the vulnerabilities of the asset $a_{i}$. This is possible because a vulnerability can have associated the same weakness as other vulnerabilities. |  Ideally, the value of $M_{7}$ should be zero, or at least, $M_{7}\leq\frac{|CVE_{A|cwe_{j}}(t)|}{n(t)}$, being $n(t)$ the number of assets in the SUT. The value of the metric could be further narrowed by assuming that $cwe_{j}$ will be present in all but one asset, so $M_{7}\leq\frac{|CVE_{A|cwe_{j}}(t)|}{n(t)-1}$ to be in acceptable values.
$M_{6}(A,cwe_{j},t)=|CVE_{A|cwe_{j}}(t)|$ |  Multiplicity of weakness $cwe_{j}$ of the SUT $A$ at a time $t$. This metric represents the number of times a weakness is present among the vulnerabilities of the SUT $A$. |  Ideally, the value of $M_{8}$ should be zero.
WEAKNESSES |  |  |
$M_{7}(A,t)=|CWE_{A}(t)|$ |  Number of weaknesses in a SUT $A$ at time $t$. |  Ideally, the value of $M_{1}$ should be zero (no weakness in $A$), but the lower the value of $M_{1}$, the better.
$M_{8}(A)=\sum_{t=1}^{T}|CWE_{A}(t)|=\sum_{t=1}^{T}M_{7}(A,t)$ |  Number of weaknesses in a SUT $A$ throughout its entire life cycle $T$. This metric computes the accumulated value of weaknesses of a SUT throughout its entire life cycle. |  The lower the value of $M_{4}$, the better.

In addition to the metrics in Table II, the model allows the definition of
other types of metrics according to the analysis to be performed, and the
nature of the SUT (e.g., the vulnerability evolution function for SUT $A$ up
to time $t$ for all vulnerabilities can be defined as the linear regression of
the total number of vulnerabilities in each time $t$ for SUT $A$).

###  III-C 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.

####  III-C1 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.

####  III-C2 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 a 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 Fig. 6.

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.

At time $t_{0}$, the initial graph of the SUT $A$ is depicted in Fig. 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.

####  III-C3 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.

###  III-D Applicability in the Context of ISA/IEC 62443

In this section, the potential application of the proposed EDG model to the
existing security standards is described. The proposed EDG model can be used
isolated by itself, or in combination with other techniques that complement
the analysis. In this sense, the EDG model can be used to enhance some task in
the security evolution processes defined by security standards.

The ISA/IEC 62443-4-1 standard specifies 47 process requirements for the
secure development of products used in industrial automation and control
systems [62]. Thus, the EDG model was developed to enhance the execution of
one of those requirements defined by the standard: the “SVV-3: Vulnerability
testing” requirement, serving as a support for the execution of Practice 5 —
Security Verification and Validation testing. According to the SVV-3
requirement, both known and unknown vulnerability analysis has to be
performed. The EDG model proposed in this research work is intended to support
the identification of known vulnerabilities, their dependencies, and the
possible consequences of their propagation, yielding the opportunity to
analyze them systematically. Nevertheless, more requirements of the ISA/IEC
62443 can be mapped to one or more of the metrics defined in this research
work. Using this relationship, it is possible to apply the EDG model to
enhance the analysis and review of the following requirements:

####  III-D1 Security Requirements - 2: Threat Model (SR-2)

“A process shall be employed to ensure that all products have a threat model
specific to the current development scope of the product. The threat model
shall be reviewed and verified periodically” [62]. The proposed EDG model can
serve as an abstraction of the threat model that has to be obtained. Moreover,
the standard states that this threat model has to be reviewed periodically for
updates. Given that the EDG of a given SUT evolves with every update, the
threat model would be always up-to-date. Potential threats and their severity
using the CVSS can also be analyzed with this proposal. Finally, these results
can be used to enhance the risk assessment of the SUT.

####  III-D2 Security Management - 13: Continuous Improvement (SM-13)

“A process shall be employed for continuously improving the secure development
life cycle” [62]. The EDG model can be used to identify recurrent issues in
the development of an industrial component, due to its ability to track the
state of a SUT over time. Consider the scenario where a piece of code contains
an unknown vulnerability. For example, this code can implement a communication
protocol, or the generation of a cryptographic key. If this piece of code is
recurrently integrated in many type of devices, then when they are released to
the market, the end users can identify that vulnerability and report it to the
product supplier. The EDG can reflect the presence of that vulnerability. If
an EDG is done for each type of device, then this problem can be detected
beforehand. Using the CWE, the root problem can be detected. With this
information, new training and corrective actions can be proposed to avoid this
issue.

####  III-D3 Specification of Security Requirements - 5: Security Requirements
Review (SR-5)

“A process shall be employed to ensure that security requirements are
reviewed, updated, and approved” [62]. As before, taking advantage of the
previous scenario, the information extracted from the generated EDG model can
be used to propose new requirements or to update the existing requirements.

####  III-D4 Security Verification and Validation Testing - 4: Penetration
Testing (SVV-4)

“A process shall be employed to identify and characterize security-related
issues via tests that focus on discovering and exploiting security
vulnerabilities in the product” [62]. The EDG model facilitates the
identification of possible entry points to the SUT when carrying out a
penetration test. In addition, existing attack patterns (CAPEC) and weaknesses
(CWE) can serve as a starting point to discover unknown vulnerabilities and
exploits.

####  III-D5 Management of Security-related Issues - 3: Assessing Security-
related issues (DM-3)

“A process shall be employed for analyzing security-related issues in the
product” [62]. When a new vulnerability is detected, end users will report it
to the product suppliers. Then, the corresponding EDG model of that SUT will
be updated to reflect that change. This information, in addition to that
previously contained in the EDG, can be used to obtain the severity value of
the discovered vulnerability using the CVSS. This also facilitates the
identification of root causes, related security issues, or the impact.

TABLE III: Mapping between the developed metrics and the requirements they
refer in the ISA/IEC 62443.
SR (Security Requirements), SM (Security Management), SVV (Security Validation
and Verification), DM (Management of Security-Related Issues).

METRIC | SR-2 | SR-5 | SM-13 | SVV-4 | DM-3
---|---|---|---|---|---
$M_{0}(A)=\frac{|CVE_{A}(t)|}{n(t)}$ | $\blacksquare$ | $\blacksquare$ | $\blacksquare$ | $\blacksquare$ | $\blacksquare$
$M_{1}(A,t)=|CVE_{A}(t)|$ | $\blacksquare$ | $\blacksquare$ | $\blacksquare$ | $\blacksquare$ | $\blacksquare$
$M_{2}(A)=\sum_{t=1}^{T}|CVE_{A}(t)|=\sum_{t=1}^{T}M_{1}(A,t)$ | $\square$ | $\blacksquare$ | $\blacksquare$ | $\square$ | $\square$
$M_{3}(A,t)=|CVE_{a_{i}}(t)|$ | $\blacksquare$ | $\blacksquare$ | $\blacksquare$ | $\blacksquare$ | $\square$
$M_{4}(a_{k},t)=\frac{|CVE_{a_{k}}(t)|}{\sum_{i=1}^{n}|CVE_{a_{i}}(t)|}$ | $\square$ | $\blacksquare$ | $\blacksquare$ | $\square$ | $\square$
$M_{5}(a_{i},cwe_{j},t)=|CVE_{a_{i}|cwe_{j}}(t)|$ | $\blacksquare$ | $\blacksquare$ | $\blacksquare$ | $\blacksquare$ | $\square$
$M_{6}(A,cwe_{j},t)=|CVE_{A|cwe_{j}}(t)|$ | $\blacksquare$ | $\blacksquare$ | $\square$ | $\blacksquare$ | $\blacksquare$
$M_{7}(A,t)=|CWE_{A}(t)|$ | $\blacksquare$ | $\square$ | $\square$ | $\blacksquare$ | $\blacksquare$
$M_{8}(A)=\bigcup_{t=1}^{T}|CWE_{A}(t)|=\bigcup_{t=1}^{T}M_{7}(A,t)$ | $\square$ | $\blacksquare$ | $\blacksquare$ | $\square$ | $\square$

Finally, the ISA/IEC 62443-4-2 document defines four types of components of an
IACS (i.e., software applications, embedded devices, host devices, network
devices) [94]. The proposed model is capable of representing the inherent
complexity of each of them.

##  IV Real Use Case

In this section, the EDG model and the proposed metrics will be applied to
perform a vulnerability assessment of the OpenPLC project, which will be the
SUT. In the subsections, we will assess the three available versions of the
OpenPLC project. For each, the EDG model will be obtained, and the proposed
metrics will be applied to draw conclusions about the vulnerability status of
each version.

OpenPLC is the first functional standardized open source Programmable Logic
Controller (PLC), both in software and hardware [95]. It was mainly created
for research purposes in the areas of industrial and home automation, 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 [96, 97].

###  IV-A Structure of OpenPLC

The OpenPLC project consists of three parts:

  1. 1.

Runtime: It is the software that plays the same role as the firmware in a
traditional PLC. It executes the control program. The runtime can be installed
in a variety of embedded platforms, such as the Raspberry Pi, and in Operating
Systems (OSs) such as Windows or Linux. Industrial Modbus slave devices can be
attached to expand the number of inputs and outputs.

  2. 2.

Editor: An application that runs on a Windows or Linux OS that is used to
write and compile the control programs that will be later executed by the
runtime.

  3. 3.

HMI Builder: This software is to create web-based animations that will reflect
the state of the process, in the same manner as a traditional HMI.

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.

###  IV-B Setup Through the Analysis

The OpenPLC project is constituted by three different versions [98, 99, 100]
as can be seen in Table IV. For this research work, Ubuntu Linux was selected
as the platform to install the OpenPLC runtime. Ubuntu Linux provides
comprehensive documentation, previous versions are accessible, and software
dependencies can easily be obtained.

To make the analysis of OpenPLC fair, a contemporary operating system was
selected for each of the OpenPLC versions, according to the version of Ubuntu
that was available at the release time of each OpenPLC version (see Table IV).
The Long Term Support (LTS) version was chosen, given that the industry tends
to work with the most stable version available of any software and security
updates are provided for a longer time.

TABLE IV: Versions and release dates of OpenPLC and the available Ubuntu Linux
LTS at that time for each date.

VERSION | RELEASE | OS | OS RELEASE
---|---|---|---
OpenPLC V1 | 2016/02/05 | Ubuntu 14.04 LTS | 2014/04/17
OpenPLC V2 | 2016/05/13 | Ubuntu 16.04 LTS | 2016/04/21
OpenPLC V3 | 2018/06/14 | Ubuntu 18.04 LTS | 2018/04/26

The scenario used for the analysis consists of OpenPLC installed on Ubuntu
Linux in a virtual machine, following the OSs shown in Table IV.

###  IV-C Steps of the Analysis

The EDG model of OpenPLC was built following the steps described in Section
III-A4 (see flowchart in Fig. 4). It is worth noting that these steps are
followed for each one of the three versions available of OpenPLC, so an EDG is
generated for each one. Obtaining the EDG for each version of OpenPLC will
give information about the evolution of vulnerabilities over time.

For the sake of clarity and ease of analysis, the three obtained dependency
graphs for each OpenPLC version were not merged into a single diagram. Fig. 7,
Fig. 8, and Fig. 9, show the obtained EDG for versions V1, V2, and V3,
respectively. In reality, these three diagrams would be the result of applying
this method over time, updating the graph each time that a new vulnerability
is discovered or a new patch/update is issued.

###  IV-D Analysis

In this stage, the analysis of the SUT is performed based on the generated EDG
and the value of the computed metrics. This process can be structured into
three main steps, as follows:

  1. 1.

Analysis of the induced EDG model: This step involves the analysis of the
obtained directed-graph model. The structure, assets and dependencies are the
focus of this first step.

  2. 2.

Vulnerability analysis: Vulnerability number, distribution, and severity are
analyzed in this step, which is supported by metrics. A proposal for
vulnerability prioritization is also proposed.

  3. 3.

Root causes analysis (weaknesses): Finally, the root cause of each
vulnerability if found (related to the associated weakness). In this step, new
requirements, test cases, and training activities are proposed based on the
results of the analysis.

For each of the previously described steps, the analysis is done in both the
spatial and temporal dimensions:

  1. 1.

Spatial Dimension: This kind of analysis focuses on the distribution of
vulnerabilities among the assets at a time $t$. In this example, this
corresponds to independently analyzing each obtained EDG, because each one
represents an instant in time (a different version of OpenPLC).

  2. 2.

Temporal Dimension: This kind of analysis focuses on the evolution and
distribution of vulnerabilities over time. In this example, this corresponds
to analyzing the changes in the number of assets and vulnerabilities, and
their distribution over all three EDGs (over all three versions of OpenPLC).

####  IV-D1 Analysis of the Induced EDG Model

OpenPLC V1 is analyzed in this subsection, focusing on the internal structure
and dependencies among the assets.

The first result of the EDG model is thegraph obtained for OpenPLC V1 (Fig.
7). From the spatial dimension point of view, assets depend on a main service,
server.js, based in Java. This web server offers a web GUI for the user to
configure, start, and stop the PLC execution. Below this level, the main
components of OpenPLC can be seen: OPLC Starter (responsible to start the
OpenPLC and constantly monitor if it is running or not), OPLC Compiler
(compiler from ladder logic to ANSI C code), and openplc (initialization
procedures for the hardware, network and the main loop). The other assets are
dynamic libraries of the system, such as libstdc++, libm, textttlibc (for C
programming), and textttlibssl (C library for SSL and TLS).

Moreover, the libc library is a wrapper around the system calls of the Linux
kernel, which provides and defines system calls and other basic functions.
Thus, it is expected that all of the identified assets depend on this library
in every version of OpenPLC. Fig. 7 shows that this is indeed the case.

Figure 7: EDG for OpenPLC V1. Notice that, for simplicity, CWE, and CAPEC
values are omitted, and only the CPE identifier of the SUT is shown.

From the temporal dimension point of view, OpenPLC V2 has to be analyzed in
comparison to the previous version of OpenPLC to find changes in the structure
and the number of assets. Fig. 8 shows the EDG for OpenPLC V2. Comparing both
OpenPLC V1 and OpenPLC v2, it can be noted that their structure is very
similar. In OpenPLC V2, new assets were introduced to provide new features to
the project: Matiec compiler (which is an open-source compiler for programming
languages defined in the IEC 61131-3 standard), ST optimizer (which is
responsible for the optimization process after the initial compilation from
OpenPLC Editor), Glue Generator (which is responsible for gluing the variables
from the IEC program to the OpenPLC memory pointers), and OpenDNP3 (which is
an implementation of the DNP3 protocol stack written in C++11).

In OpenPLC V2, and in comparison with OpenPLC V1, the OPLC compiler has
disappeared and has been substituted by the Matiec Compiler, which supports
all programming languages defined in the IEC 61131-3 standard. Moreover, the
ST Optimizer and the Glue Generator were added to support the compilation
process. Finally, the OpenDNP3 library has been added for high-performance
applications, such as many concurrent TCP sessions.

Figure 8: EDG for OpenPLC V2. Note that for the sake of simplicity, CWE, and
CAPEC values are omitted and only the CPE identifier of the SUT is shown.

Finally, and keeping the analysis in the temporal dimension, OpenPLC V3 can be
compared to its ancestor, OpenPLC V2. Fig. 9 shows the EDG for OpenPLC V3.
This last version of the project is the simplest. Now, the Java-based web
server has been replaced by a Python-based web server, webserver.py. The main
components of this version are: Matiec compiler, ST optimizer, Glue Generator,
OpenDNP3, and LibModbus.

Figure 9: EDG for OpenPLC V3. Note that only the CPE of SUT is shown for the
sake of simplicity.

####  IV-D2 Vulnerability Analysis

In this step, all three available versions of the OpenPLC project are analyzed
from a vulnerability perspective, both in the spatial and temporal dimensions.
The goal here is to use the defined metrics as a support of the analysis,
obtaining the number of vulnerabilities, their distribution, and their
severity score. Table V shows the values of the proposed metrics for all three
versions of OpenPLC. Finally, a ranked prioritization by severity for the
vulnerabilities of each version is proposed.

TABLE V: Metric values for each asset and version of OpenPLC. Notice that
“CWE-NULL” refers to a void value of CWE for a certain CVE value.

METRIC | OpenPLC V1 | OpenPLC V2 | OpenPLC V3
---|---|---|---
libgcc_s | libc | libz | libcares | nodejs | libssl | others | libgcc_s | libc | libz | libicuuc | libssl | others | libgcc_s | libc | others
vulnerabilities | $n(t)$ | 19 | 22 | 19
$M_{0}(A)=\frac{|CVE_{A}(t)|}{n(t)}$ | 4.79 | 3.50 | 0.26
$M_{1}(A,t)=|CVE_{A}(t)|$ | 91 | 77 | 5
$M_{2}(A)=\sum_{t=1}^{T}|CVE_{A}(t)|=\sum_{t=1}^{T}M_{1}(A,t)$ | 173
$M_{3}(A)=|CVE_{a_{i}}(t)|$ | 2 | 9 | 4 | 2 | 9 | 65 | 0 | 3 | 5 | 4 | 2 | 63 | 0 | 2 | 3 | 0
$M_{4}(a_{k},t)=\frac{|CVE_{a_{k}}(t)|}{\sum_{i=1}^{n}|CVE_{a_{i}}(t)|}$ | 0.02 | 0.10 | 0.04 | 0.02 | 0.10 | 0.71 | 0.00 | 0.04 | 0.06 | 0.05 | 0.03 | 0.82 | 0.00 | 0.40 | 0.60 | 0.00
weaknesses | $M_{5}(a_{i},cwe_{j},t)=|CVE_{a_{i}|cwe_{j}}(t)|$ | CWE-17 | - | 1 | - | - | - | 2 | - | - | - | - | - | 3 | - | - | - | -
CWE-19 | - | - | - | - | 1 | - | - | - | - | - | - | - | - | - | - | -
CWE-20 | - | - | - | - | 3 | 5 | - | - | - | - | - | 3 | - | - | - | -
CWE-22 | - | 1 | - | - | - | - | - | - | - | - | - | - | - | - | - | -
CWE-94 | - | 1 | - | - | - | - | - | - | - | - | - | - | - | - | - | -
CWE-113 | - | - | - | - | 1 | - | - | - | - | - | - | - | - | - | - | -
CWE-119 | 1 | 5 | - | - | - | 9 | - | 1 | 3 | - | 1 | 6 | - | 1 | 3 | -
CWE-125 | - | - | - | - | - | 2 | - | - | - | - | - | 3 | - | - | - | -
CWE-189 | - | - | 4 | - | - | 2 | - | - | - | 4 | - | 4 | - | - | - | -
CWE-190 | - | - | - | - | - | 1 | - | - | - | - | 1 | 1 | - | - | - | -
CWE-200 | - | - | - | 1 | 3 | 5 | - | 1 | - | - | - | 12 | - | - | - | -
CWE-295 | - | - | - | - | - | - | - | - | - | - | - | 1 | - | - | - | -
CWE-310 | - | - | - | - | - | 12 | - | - | - | - | - | 5 | - | - | - | -
CWE-311 | - | - | - | - | - | - | - | - | - | - | - | 2 | - | - | - | -
CWE-320 | - | - | - | - | - | - | - | - | - | - | - | 3 | - | - | - | -
CWE-331 | 1 | - | - | - | - | - | - | 1 | - | - | - | - | - | 1 | - | -
CWE-362 | - | - | - | - | - | 4 | - | - | - | - | - | 1 | - | - | - | -
CWE-399 | - | - | - | - | - | 8 | - | - | 1 | - | - | 6 | - | - | - | -
CWE-400 | - | - | - | - | - | 1 | - | - | - | - | - | 1 | - | - | - | -
CWE-426 | - | 1 | - | - | - | - | - | - | 1 | - | - | - | - | - | - | -
CWE-787 | - | - | - | 1 | 1 | 2 | - | - | - | - | - | 2 | - | - | - | -
CWE-NULL | - | - | - | - | - | 12 | - | - | - | - | - | 10 | - | - | - | -
$M_{6}(A,cwe_{j},t)=|CVE_{A|cwe_{j}}(t)|$ | CWE-17 | 3 | 3 | -
CWE-19 | 1 | - | -
CWE-20 | 8 | 3 | -
CWE-22 | 1 | - | -
CWE-94 | 1 | - | -
CWE-113 | 1 | - | -
CWE-119 | 15 | 11 | 4
CWE-125 | 2 | 3 | -
CWE-189 | 6 | 8 | -
CWE-190 | 1 | 2 | -
CWE-200 | 9 | 13 | -
CWE-295 | - | 1 | -
CWE-310 | 12 | 5 | -
CWE-311 | - | 2 | -
CWE-320 | - | 3 | -
CWE-331 | 1 | 1 | 1
CWE-362 | 4 | 1 | -
CWE-399 | 8 | 7 | -
CWE-400 | 1 | 1 | -
CWE-426 | 1 | 1 | -
CWE-787 | 4 | 2 | -
CWE-NULL | 12 | 10 | -
$M_{7}(A,t)=|CWE_{A}(t)|$ | 19 | 18 | 2
$M_{8}(A)=\bigcup_{t=1}^{T}|CWE_{A}(t)|=\bigcup_{t=1}^{T}M_{7}(A,t)$ | 22

From the spatial dimension perspective, just by observing the generated EDG
for OpenPLC V1 (Fig. 7), it can be stated that:

  * •

Most of the vulnerabilities are present in third-party open-source components,
such as libssl ($M_{3}=65$), and node-js ($M_{3}=9$), having libssl the
$M_{4}=71.4\%$ of the vulnerabilities in this version. A priori, just by
looking the number of vulnerabilities in each asset, it can be said that
libssl is the most vulnerable asset in this version. Nevertheless, it is never
enough to analyze the number of vulnerabilities ($M_{3}$), and the CVSS score
for each has to be taken into account, as well as the existence of known
exploits (e.g., updating the value of the CVSS using the temporal score).

  * •

The other vulnerabilities in OpenPLC V1 affect the assets of the operating
system, such as libc ($M_{3}=9$).

  * •

The ad hoc assets developed for this project have no known vulnerabilities.
This does not mean that they are secure, but rather that there are no known
vulnerabilities available for them. Zero-day vulnerabilities could be present
in the SUT.

Values of $M_{1}=91$ suggests a high number of vulnerabilities in this
project. This is expected given that OpenPLC V1 was the first version of
OpenPLC. In the following versions, the value of $M_{1}$ is expected to
decrease.

The most striking fact when observing the EDG for OpenPLC V1 is the large
number of vulnerabilities that are present in libssl. From this perspective,
if a pen-tester were to evaluate OpenPLC V1, libssl would be a promising
target. When the values of the CVSS are checked, three
vulnerabilities222CVE-2016-2842, CVE-2016-0799, and CVE-2016-0705. have a
score of 10.0 out of 10.0. As can be seen, EDGs are a powerful tool for
inspecting the structure of the SUT, and they can be used to analyze how the
exploitation of a vulnerability can affect the rest of the SUT.

All of the assets point to libc, which is a wrapper around the system calls of
the Linux kernel. An evaluator, even without this information, can understand
the importance of this dependency with libc using the EDG. On closer
inspection, the highest score of CVSS for the vulnerabilities of libc is 9.3
out of 10.0333CVE-2017-16997. If the exploitation of this vulnerability is
possible, then it would allow a local user to gain privileges, exposing other
assets of the SUT.

Using the value of severity of each vulnerability, it is possible to generate
a list of vulnerabilities to be patched. This list can either be ordered by
the global CVSS or by asset. Table VI shows all the vulnerabilities whose CVSS
value is between 6.0 and 10.0 ordered by asset and by descending CVSS. This
can be used to decide in which order the vulnerabilities have to be patched,
both at asset level or at SUT level.

TABLE VI: Vulnerability prioritization by asset and by CVSS for OpenPLC V1.
Only the vulnerabilities whose value is between 6.0 and 10.0 are shown.

CVE | CVSS | ASSET
---|---|---
CVE-2019-15847 | 7.5 | libcares
CVE-2018-12886 | 7.5 | libgcc
CVE-2016-9843 | 7.5 | libz
CVE-2016-9841 | 7.5 | libz
CVE-2016-9840 | 6.8 | libz
CVE-2016-9842 | 6.8 | libz
CVE-2017-16997 | 9.3 | libc
CVE-2014-9984 | 7.5 | libc
CVE-2014-4043 | 7.5 | libc
CVE-2015-5277 | 7.2 | libc
CVE-2015-7547 | 6.8 | libc
CVE-2014-0475 | 6.8 | libc
CVE-2016-2842 | 10.0 | libssl
CVE-2016-0705 | 10.0 | libssl
CVE-2016-0799 | 10.0 | libssl
CVE-2016-6304 | 7.8 | libssl
CVE-2016-0798 | 7.8 | libssl
CVE-2014-8176 | 7.5 | libssl
CVE-2016-2182 | 7.5 | libssl
CVE-2014-3512 | 7.5 | libssl
CVE-2016-6303 | 7.5 | libssl
CVE-2015-0292 | 7.5 | libssl
CVE-2016-2177 | 7.5 | libssl
CVE-2014-3567 | 7.1 | libssl
CVE-2014-3513 | 7.1 | libssl
CVE-2015-1791 | 6.8 | libssl
CVE-2012-2333 | 6.8 | libssl
CVE-2015-0209 | 6.8 | libssl
CVE-2014-3509 | 6.8 | libssl
CVE-2014-0195 | 6.8 | libssl
CVE-2014-3505 | 5.0 | libssl

From the information in Table VI, it is clear that all the three
vulnerabilities with a CVSS value of $10.0$ are in libssl, which makes this
asset the most vulnerable by number of vulnerabilities and by CVSS. These
vulnerabilities should be a priority during the patching stages. It is worth
noting that libc, which is an important asset in Ubuntu Linux, has a
vulnerability whose score is $9.3$ (CVE-2017-16997). This should also be a
priority when patching.

Moving now to OpenPLC V2, and comparing it with OpenPLC V1 (temporal
dimension), similar conclusions can be drawn:

  * •

Most of the vulnerabilities are in third-party open-source components.
Moreover, libssl ($M_{3}=63$) remains as the asset with the majority of
vulnerabilities (with $M_{4}=81.8\%$ of them), followed by libz ($M_{3}=4$)
from node-js.

  * •

The remaining vulnerabilities are related to the operating system, just as in
OpenPLC V1, libc ($M_{3}=5$).

For this version, $M_{1}=77$, less than $M_{1}=98$ for the previous version.
As was expected, the total number of vulnerabilities has decreased. From the
spatial dimension, it is worth noting that libssl is still the asset with the
highest number of vulnerabilities and is still a promising target for a pen-
tester or an attacker. Nevertheless, the number of vulnerabilities for libssl
($M_{3}$) has decreased from OpenPLC V1 to OpenPLC V2, as it was expected.

As was done earlier, a list of vulnerabilities can be generated that is
ordered by asset and by descending CVSS. Table VII shows all of the
vulnerabilities for OpenPLC V2 whose CVSS value is between 6.0 and 10.0.

TABLE VII: Vulnerability prioritization by asset and by CVSS for OpenPLC V2.
Only the vulnerabilities whose value is between 6.0 and 10.0 are shown.

CVE | CVSS | ASSET
---|---|---
CVE-2018-12886 | 6.8 | libgcc_s
CVE-2017-16997 | 9.3 | libc
CVE-2017-18269 | 7.5 | libc
CVE-2016-9843 | 7.5 | libz
CVE-2016-9841 | 7.5 | libz
CVE-2016-9842 | 6.8 | libz
CVE-2016-9840 | 6.8 | libz
CVE-2016-0799 | 10.0 | libssl
CVE-2016-2108 | 10.0 | libssl
CVE-2016-0705 | 10.0 | libssl
CVE-2016-2842 | 10.0 | libssl
CVE-2016-0798 | 7.8 | libssl
CVE-2016-6304 | 7.8 | libssl
CVE-2016-2109 | 7.8 | libssl
CVE-2016-2177 | 7.5 | libssl
CVE-2016-2182 | 7.5 | libssl
CVE-2016-6303 | 7.5 | libssl
CVE-2015-0209 | 6.8 | libssl
CVE-2015-1791 | 6.8 | libssl
CVE-2016-2106 | 6.5 | libssl
CVE-2016-2176 | 6.4 | libssl

Table VII shows that libssl now has four instead of three vulnerabilities
whose CVSS value is 10.0 (CVE-2016-0799, CVE-2016-2108, CVE-2016-0705,
CVE-2016-2842). In OpenPLC V2, libc is still affected by the same
vulnerability with a score of 9.3 (CVE-2017-16997). All of these
vulnerabilities should be a priority during patching activities.

Finally, OpenPLC V3, which is the last available version, is analyzed. The
most striking fact when comparing OpenPLC V3 with the other versions (temporal
dimension) is the significant reduction in the global number of
vulnerabilities. This effect is caused by the absence of libssl in this
version.

Focusing on the spatial dimension for this version, vulnerabilities in OpenPLC
V3 are only related to assets in the operating system, libgcc_s ($M_{3}=2$),
and libc ($M_{3}=3$). In OpenPLC V3, neither third-party open-source assets
nor ad hoc assets have any known vulnerability. In fact, OpenPLC V3 has the
lowest values of $M_{1}=5$ for the whole life cycle of the project, and
therefore has the lowest number of vulnerabilities.

Table VIII shows an ordered list of all the vulnerabilities in OpenPLC V3
whose CVSS value is between 6.0 and 10.0.

TABLE VIII: Vulnerability prioritization by asset and by CVSS for OpenPLC V3.
Only the vulnerabilities whose value is between 6.0 and 10.0 are shown.

CVE | CVSS | ASSET
---|---|---
CVE-2018-12886 | 6.8 | libgcc_s
CVE-2018-11236 | 7.5 | libc
CVE-2017-18269 | 7.5 | libc

For OpenPLC V3, the most vulnerable asset is libc, according to the CVSS score
shown in Table VIII.

####  IV-D3 Root Causes Analysis (Weaknesses)

In this last step of the analysis, the information about the root causes of
the vulnerabilities is extracted. This can be achieved through weaknesses.
Each CWE contains data about the main issue to be solved for any given
vulnerability. This information is useful to propose new requirements, test
cases, and training. The analysis of the root causes will also be carried out
in both the spatial and temporal dimensions.

The analysis of the root causes starts by extracting the weaknesses for each
vulnerability for all three versions of OpenPLC. All of the extracted
weaknesses for all three available versions of OpenPLC are shown in Fig. 10
and in Table IX.

TABLE IX: Weakness analysis for all versions of OpenPLC.

METRIC | OpenPLC V1 | OpenPLC V2 | OpenPLC V3 | $\sum_{i=1}^{T}M_{8}(A,cwe_{j},t)$
---|---|---|---|---
$M_{8}(A,cwe_{j},t)=|CVE_{A|cwe_{j}}(t)|$ | CWE-17 | 3 | 3 | - | 6
CWE-19 | 1 | - | - | 1
CWE-20 | 8 | 3 | - | 11
CWE-22 | 1 | - | - | 1
CWE-94 | 1 | - | - | 1
CWE-113 | 1 | - | - | 1
CWE-119 | 15 | 11 | 4 | 30
CWE-125 | 2 | 3 | - | 5
CWE-189 | 6 | 8 | - | 14
CWE-190 | 1 | 2 | - | 3
CWE-200 | 9 | 13 | - | 22
CWE-295 | - | 1 | - | 1
CWE-310 | 12 | 5 | - | 17
CWE-311 | - | 2 | - | 2
CWE-320 | - | 3 | - | 3
CWE-331 | 1 | 1 | 1 | 3
CWE-362 | 4 | 1 | - | 5
CWE-399 | 8 | 7 | - | 15
CWE-400 | 1 | 1 | - | 2
CWE-426 | 1 | 1 | - | 2
CWE-787 | 4 | 2 | - | 6
CWE-NULL | 12 | 10 | - | 22
$M_{7}(A,t)=|CWE_{A}(t)|$ | 19 | 18 | 2 | 22

Focusing on the spatial dimension, OpenPLC V1 has the widest range of
weaknesses ($M_{7}=19$), and therefore has the widest range of root causes.
From the total number of vulnerabilities in OpenPLC V1 ($M_{3}=91$),
$M_{6}=15$ of them are related to weaknesses CWE-119444Description for
CWE-119: https://cwe.mitre.org/data/definitions/119.html: “The software
performs operations on a memory buffer, but it can read from or write to a
memory location that is outside the intended boundary of the buffer.”
$M_{6}=12$ of them are related to CWE-310 555Description for CWE-310:
https://cwe.mitre.org/data/definitions/310.html.: “Weaknesses in this category
are related to the design and implementation of data confidentiality and
integrity. Frequently, these deal with the use of encoding techniques,
encryption libraries, and hashing algorithms. The weaknesses in this category
could lead to a degradation of the quality of data if they are not addressed.”

Repeating this same analysis with OpenPLC V2, we can see that the number of
different weaknesses ($M_{7}=18$) is almost the same as before. But in this
version, the most repeated weakness is CWE-200666Description for CWE-200:
https://cwe.mitre.org/data/definitions/200.html: “The product exposes
sensitive information to an actor that is not explicitly authorized to have
access to that information.” Followed by CWE-119.

Comparing the previous versions with OpenPLC V3, we find now that the total
number of weaknesses ($M_{7}=2$) has been reduced drastically. Nevertheless,
weakness CWE-119 is still present in this version, and is the most repeated.

This analysis can also be done by combining the information of all three
versions, drawing conclusions for the whole life cycle of OpenPLC.
Requirements and test cases can be extracted from the most recurrent
weaknesses, and training can be proposed to avoid weaknesses that repeat over
time. In our example, CWE-119 has the greatest frequency over time
($\sum_{i=1}^{T}M_{6}=30$), followed by CWE-200 ($\sum_{i=1}^{T}M_{6}=22$),
and CWE-310 ($\sum_{i=1}^{T}M_{6}=17$). Table X shows the generated
requirements, Table XI shows the proposed training, and Table XII shows the
proposed test cases for OpenPLC.

Figure 10: Evolution of the number of vulnerabilities over consecutive
versions of OpenPLC. TABLE X: An example of generated requirements for
OpenPLC.

CWE ID |  REQUIREMENTS
---|---
CWE-19, CWE-20, CWE-119, CWE-125, CWE-189, CWE-190, CWE-362, CWE-399, CWE-400, CWE-787 |  Use languages that perform their own memory management.
CWE-19, CWE-20, CWE-119, CWE-125, CWE-189, CWE-190, CWE-787 |  Use libraries or frameworks that make it easier to handle numbers without unexpected consequences. Examples include safe integer handling packages such as SafeInt (C++) or IntegerLib (C or C++).
CWE-19, CWE-20, CWE-119, CWE-125, CWE-189, CWE-190, CWE-200, CWE-362, CWE-787 |  Use a CPU and operating system that offers Data Execution Protection (NX) or its equivalent.
CWE-19, CWE-20, CWE-125, CWE-189, CWE-190, CWE-200, CWE-362 |  Ensure that all protocols are strictly defined, such that all out-of-bounds behaviors can be identified simply, and require strict conformance to the protocol.
CWE-19, CWE-20, CWE-399, CWE-400 |  Run or compile the software using features or extensions that randomly arrange the positions of a program’s executable and libraries in memory (e.g., Address Space Layout Randomization (ASLR), or Position-Independent Executables (PIE)).
CWE-19, CWE-295, CWE-310, CWE-311, CWE-320, CWE-331 |  Clearly specify which data or resources are valuable enough that they should be protected by encryption. Require that any transmission or storage of this data/resource should use well-vetted encryption algorithms. Up-to-date algorithms must be used, and the entropy of the keys must be sufficient for the application.
CWE-22, CWE-94, CWE-113, CWE-399, CWE-400, CWE-426 |  Hard-code the search path to a set of known-safe values (such as system directories), or only allow them to be specified by the administrator in a configuration file. Do not allow these settings to be modified by an external party.
CWE-20, CWE-22, CWE-94, CWE-113, CWE-399, CWE-400, CWE-426 |  Use an input validation framework such as Struts or the OWASP ESAPI Validation API.
CWE-19, CWE-20, CWE-22, CWE-94, CWE-113, CWE-295, CWE-426 |  Assume all input is malicious. Use an ”accept known good” input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.
CWE-19, CWE-20, CWE-119, CWE-125, CWE-399, CWE-400, CWE-787 |  Run or compile the software using features or extensions that automatically provide a protection mechanism that mitigates or eliminates buffer overflows.
CWE-19, CWE-22, CWE-119, CWE-125, CWE-399, CWE-400, CWE-787 |  Replace unbounded copy functions with analogous functions that support length arguments, such as strcpy with strncpy. Create these if they are not available.

TABLE XI: Example of proposed training for OpenPLC.

CWE ID |  TRAINING
---|---
CWE-19, CWE-20, CWE-22, CWE-94, CWE-113, CWE-119, CWE-125, CWE-426 |  Identification of all potentially relevant properties of an input (length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields).
CWE-19, CWE-20, CWE-22, CWE-94, CWE-113, CWE-119, CWE-125, CWE-426 |  Input validation strategies.
CWE-19, CWE-20, CWE-22, CWE-94, CWE-113, CWE-119, CWE-125, CWE-200, CWE-426 |  Allowlists and Denylists.
CWE-19, CWE-20, CWE-22, CWE-94, CWE-113, CWE-119, CWE-125, CWE-189, CWE-190, CWE-426 |  Character encoding compatibility.
CWE-19, CWE-20, CWE-94, CWE-113, CWE-119, CWE-125, CWE-426 |  Buffer overflow detection during compilation (e.g., Microsoft Visual Studio /GS flag, Fedora/Red Hat FORTIFY_SOURCE GCC flag, StackGuard, and ProPolice).
CWE-19, CWE-20, CWE-94, CWE-113, CWE-119, CWE-125, CWE-200, CWE-426 |  Secure functions, such as strcpy with strncpy. Create these if they are not available.
CWE-19, CWE-20, CWE-94, CWE-113, CWE-119, CWE-125, CWE-189, CWE-190, CWE-426,CWE-787 |  Secure programming: memory management.
CWE-19, CWE-20, CWE-22, CWE-94, CWE-113, CWE-119, CWE-125, CWE-189, CWE-190, CWE-787 |  Understand the programming language’s underlying representation and how it interacts with numeric calculation.
CWE-19, CWE-20, CWE-22, CWE-94, CWE-113, CWE-119, CWE-125 |  System compartmentalization.
CWE-200, CWE-295, CWE-310, CWE-311, CWE-320, CWE-331 |  Certificate management.
CWE-200, CWE-295, CWE-310, CWE-311, CWE-320, CWE-331 |  Certificate pinning.
CWE-310, CWE-311, CWE-320, CWE-331 |  Encryption integration (Do not develop custom or private cryptographic algorithms).
CWE-310, CWE-311, CWE-320, CWE-331 |  Secure up-to-date cryptographic algorithms.
CWE-189, CWE-200, CWE-362, CWE-399, CWE-400, CWE-426 |  Shared resources management.
CWE-200, CWE-362, CWE-399, CWE-400, CWE-426 |  Thread-safe functions.

TABLE XII: Example of generated test cases for OpenPLC.

CAPEC ID |  TEST CASES
---|---
CAPEC-10 |  Check for buffer overflows through manipulation of environment variables. This test leverages implicit trust often placed in environment variables.
CAPEC-14 |  Static analysis of the code: secure functions and buffer overflow.
CAPEC-24 |  Feed overly long input strings to the program in an attempt to overwhelm the filter (by causing a buffer overflow) and hoping that the filter does not fail securely (i.e. the user input is let into the system unfiltered)
CAPEC-45 |  This test uses symbolic links to cause buffer overflows. The evaluator can try to create or manipulate a symbolic link file such that its contents result in out of bounds data. When the target software processes the symbolic link file, it could potentially overflow internal buffers with insufficient bounds checking.
CAPEC-46 |  Static analysis of the code: secure functions and buffer overflow.
CAPEC-47 |  In this test, the target software is given input that the evaluator knows will be modified and expanded in size during processing. This test relies on the target software failing to anticipate that the expanded data may exceed some internal limit, thereby creating a buffer overflow.
CAPEC-59 |  This test targets predictable session ID in order to gain privileges. The evaluator can try to predict the session ID used during a transaction to perform spoofing and session hijacking.
CAPEC-97 |  Automated measurement of the entropy of the keys generated.
CAPEC-475 |  Fuzz testing to externally provided data, such as directories and filenames.

##  V Conclusions and Future Work

Industrial components have become the driving force behind the development of
modern industry. They are a key element in many sectors. They perform critical
tasks and they process critical data. Following the introduction of
connectivity, the use of COTS and open-source components, and the
exponentially increasing complexity of industrial components, the number of
threats to which industrial components are exposed has increased. These
factors, together with the large lifespan of industrial components, call for a
vulnerability assessment methodology that monitors the entire life cycle of
industrial components. Existing security standards agree that vulnerability
assessment is a critical task, but they usuallyonly consider software in their
analysis, when both software and hardware should be taken into account.

The EDG model that is proposed in this research work constitutes a method to
assess known vulnerabilities that is aligned with the ISA/IEC 62443 standard.
EDGs have been specially developed to assess vulnerabilities in industrial
components, but they can also be applied to any SUT that can be decomposed
into assets. 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 vulnerabilities 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. In addition, metrics constitute a plethora of
information that that can be used by the model to improve the development
process of the SUT, enhance its security, and track its status during its
whole life cycle. The proposed EDG model has successfully achieved the
integration of the following features:

  * •

Directed graph-based analysis model.

  * •

Temporal evolution of the SUT, its assets, and its vulnerabilities.

  * •

Quantitative metrics to measure the state of the SUT over time.

  * •

Assess vulnerabilities in both software and hardware.

Moreover, with the information gathered by the model, it is possible to assist
in update management activities, apply patching policies, launch training
activities, and generate new test cases and requirements. This model can serve
as a starting point for pen-testers, because it identifies vulnerabilities,
weaknesses, and attack patterns for a given SUT.

Finally, the OpenPLC use case served as a demonstration of the advantages of
the EDG model, its applicability, and the potential of the model. The
generated EDG for all three OpenPLC versions serve as a visual tool for the
evaluators, helping them to know the preliminary status of the SUT, before any
further analysis. Furthermore, the proposed model is able to explore internal
dependencies to understand how a vulnerability would propagate throughout the
SUT. We also found that the main root causes for the vulnerabilities in
OpenPLC are related to buffer management operations, and cryptographic issues.
With this data, we are able to propose new requirements, test cases, and
training. Lists of vulnerability prioritizations for each version were also
generated.

As a future work, the EDG model will be enhanced by adding a mathematical
model to aggregate the values of the CVSS metric for each asset, and a value
for the whole SUT. This would allow us to compare different SUTs over time.
More improvements will be done 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.

## References

  * [1] O. Qingyu, L. Fang, and H. Kai, “High-security system primitive for embedded systems,” in 2009 International Conference on Multimedia Information Networking and Security, vol. 2, pp. 319–321, 2009.  https://ieeexplore.ieee.org/document/5368926.
  * [2] T. M. Chen and S. Abu-Nimeh, “Lessons from stuxnet,” Computer, vol. 44, pp. 91–93, April 2011.  https://ieeexplore.ieee.org/document/5742014.
  * [3] M. Vai, B. Nahill, J. Kramer, M. Geis, D. Utin, D. Whelihan, and R. Khazan, “Secure architecture for embedded systems,” in 2015 IEEE High Performance Extreme Computing Conference (HPEC), pp. 1–5, 2015.  https://ieeexplore.ieee.org/document/7322461.
  * [4] C.-W. Ten, G. Manimaran, and C.-C. Liu, “Cybersecurity for critical infrastructures: Attack and defense modeling,” IEEE Transactions on Systems, Man, and Cybernetics - Part A: Systems and Humans, vol. 40, no. 4, pp. 853–865, 2010.  https://ieeexplore.ieee.org/document/5477189.
  * [5] L. Gressl, C. Steger, and U. Neffe, “Design space exploration for secure iot devices and cyber-physical systems,” ACM Trans. Embed. Comput. Syst., vol. 20, May 2021.  https://dl.acm.org/doi/10.1145/3430372.
  * [6] M. Gupta, M. Abdelsalam, S. Khorsandroo, and S. Mittal, “Security and privacy in smart farming: Challenges and opportunities,” IEEE Access, vol. 8, pp. 34564–34584, 2020.  https://ieeexplore.ieee.org/document/9003290.
  * [7] S. Mumtaz, A. Alsohaily, Z. Pang, A. Rayes, K. F. Tsang, and J. Rodriguez, “Massive internet of things for industrial applications: Addressing wireless iiot connectivity challenges and ecosystem fragmentation,” IEEE Industrial Electronics Magazine, vol. 11, no. 1, pp. 28–33, 2017.  https://ieeexplore.ieee.org/document/7883984.
  * [8] M. O. Ojo, S. Giordano, G. Procissi, and I. N. Seitanidis, “A review of low-end, middle-end, and high-end iot devices,” IEEE Access, vol. 6, pp. 70528–70554, 2018.  https://ieeexplore.ieee.org/document/8528362.
  * [9] K. Shafique, B. A. Khawaja, F. Sabir, S. Qazi, and M. Mustaqim, “Internet of Things (IoT) for Next-Generation Smart Systems: A Review of Current Challenges, Future Trends and Prospects for Emerging 5G-IoT Scenarios,” IEEE Access, vol. 8, pp. 23022–23040, 2020.  https://ieeexplore.ieee.org/document/9103025.
  * [10] S. E. Ponta, H. Plate, and A. Sabetta, “Detection, assessment and mitigation of vulnerabilities in open source dependencies,” Empirical Software Engineering, vol. 25, pp. 3175–3215, Sept. 2020.  https://link.springer.com/content/pdf/10.1007/s10664-020-09830-x.pdf.
  * [11] Hejderup, J.I. and Van Deursen, A. and Mesbah, A., In Dependencies We Trust: How vulnerable are dependencies in software modules? PhD thesis, Department of Software Technology, TU Delft, may 2015.  http://resolver.tudelft.nl/uuid:3a15293b-16f6-4e9d-b6a2-f02cd52f1a9e.
  * [12] I. Pashchenko, H. Plate, S. E. Ponta, A. Sabetta, and F. Massacci, “Vulnerable open source dependencies: Counting those that matter,” in Proceedings of the 12th International Symposium on Empirical Software Engineering and Measurement (ESEM), Oct 2018.  https://dl.acm.org/doi/10.1145/3239235.3268920.
  * [13] Sonatype, “Open source development and application security survey,” tech. rep., 2014.  http://img.en25.com/Web/SonatypeInc/%7Becc5f531-1f0b-4a9c-8f52-6514c6516056%7D_2014_Survey_Final_Results.pdf.
  * [14] P. Arpaia, F. Bonavolontà, A. Cioffi, and N. Moccaldi, “Reproducibility enhancement by optimized power analysis attacks in vulnerability assessment of iot transducers,” IEEE Transactions on Instrumentation and Measurement, vol. 70, pp. 1–8, 2021.  https://ieeexplore.ieee.org/document/9521880.
  * [15] I. Zografopoulos, J. Ospina, X. Liu, and C. Konstantinou, “Cyber-physical energy systems security: Threat modeling, risk assessment, resources, metrics, and case studies,” IEEE Access, vol. 9, pp. 29775–29818, 2021\.  https://ieeexplore.ieee.org/document/9351954.
  * [16] S. McLaughlin, C. Konstantinou, X. Wang, L. Davi, A.-R. Sadeghi, M. Maniatakos, and R. Karri, “The cybersecurity landscape in industrial control systems,” Proceedings of the IEEE, vol. 104, no. 5, pp. 1039–1057, 2016.  https://ieeexplore.ieee.org/document/7434576?reload=true&arnumber=7434576.
  * [17] A. Mathew, “Network slicing in 5g and the security concerns,” in 2020 Fourth International Conference on Computing Methodologies and Communication (ICCMC), pp. 75–78, 2020.  https://ieeexplore.ieee.org/abstract/document/9076479.
  * [18] K. Christidis and M. Devetsikiotis, “Blockchains and smart contracts for the internet of things,” IEEE Access, vol. 4, pp. 2292–2303, 2016.  https://ieeexplore.ieee.org/document/7467408.
  * [19] V. Hassija, V. Chamola, V. Saxena, D. Jain, P. Goyal, and B. Sikdar, “A survey on iot security: Application areas, security threats, and solution architectures,” IEEE Access, vol. 7, pp. 82721–82743, 2019.  https://ieeexplore.ieee.org/document/8742551.
  * [20] M. Ayaz, M. Ammad-Uddin, Z. Sharif, A. Mansour, and E.-H. M. Aggoune, “Internet-of-things (iot)-based smart agriculture: Toward making the fields talk,” IEEE Access, vol. 7, pp. 129551–129583, 2019.  https://ieeexplore.ieee.org/document/8784034.
  * [21] A. Fuller, Z. Fan, C. Day, and C. Barlow, “Digital twin: Enabling technologies, challenges and open research,” IEEE Access, vol. 8, pp. 108952–108971, 2020.
  * [22] Y. Xin, L. Kong, Z. Liu, Y. Chen, Y. Li, H. Zhu, M. Gao, H. Hou, and C. Wang, “Machine learning and deep learning methods for cybersecurity,” IEEE Access, vol. 6, pp. 35365–35381, 2018.  https://ieeexplore.ieee.org/document/8359287.
  * [23] N. Benias and A. P. Markopoulos, “A review on the readiness level and cyber-security challenges in industry 4.0,” in 2017 South Eastern European Design Automation, Computer Engineering, Computer Networks and Social Media Conference (SEEDA-CECNSM), pp. 1–5, 2017.  https://ieeexplore.ieee.org/document/8088234.
  * [24] W. Matsuda, M. Fujimoto, T. Aoyama, and T. Mitsunaga, “Cyber security risk assessment on industry 4.0 using ics testbed with ai and cloud,” in 2019 IEEE Conference on Application, Information and Network Security (AINS), pp. 54–59, 2019.  https://ieeexplore.ieee.org/document/8968698.
  * [25] G. Culot, F. Fattori, M. Podrecca, and M. Sartor, “Addressing industry 4.0 cybersecurity challenges,” IEEE Engineering Management Review, vol. 47, no. 3, pp. 79–86, 2019.  https://ieeexplore.ieee.org/document/8758411.
  * [26] M. Lezzi, M. Lazoi, and A. Corallo, “Cybersecurity for industry 4.0 in the current literature: A reference framework,” Computers in Industry, vol. 103, pp. 97–110, 2018.  https://www.sciencedirect.com/science/article/abs/pii/S0166361518303658.
  * [27] A. Ustundag and E. Cevikcan, Industry 4.0: Managing The Digital Transformation.  Springer International Publishing, 2018.  https://link.springer.com/book/10.1007/978-3-319-57870-5.
  * [28] L. Thames and D. Schaefer, eds., Cybersecurity for Industry 4.0.  Springer International Publishing, 2017.  https://link.springer.com/book/10.1007/978-3-319-50660-9.
  * [29] N. Medeiros, N. Ivaki, P. Costa, and M. Vieira, “Software metrics as indicators of security vulnerabilities,” in 2017 IEEE 28th International Symposium on Software Reliability Engineering (ISSRE), pp. 216–227, 2017.  https://ieeexplore.ieee.org/document/8109088.
  * [30] M. Alenezi and M. Zarour, “On the relationship between software complexity and security,” International Journal of Software Engineering & Applications (IJSEA), vol. 11, no. 1, 2020.  https://aircconline.com/abstract/ijsea/v11n1/11120ijsea04.html.
  * [31] S. N. Matheu, J. L. Hernandez-Ramos, and A. F. Skarmeta, “Toward a cybersecurity certification framework for the internet of things,” IEEE Security Privacy, vol. 17, no. 3, pp. 66–76, 2019.  https://ieeexplore.ieee.org/document/8713275.
  * [32] Keith Stouffer and Victoria Pillitteri and Suzanne Lightman and Marshall Abrams and Adam Hahn, “Guide to Industrial Control Systems (ICS) Security,” nist spetial publication, National Institute for Standards and Technology (NIST), 2015.  http://dx.doi.org/10.6028/NIST.SP.800-82r2.
  * [33] ENISA, “Communication network dependencies for ICS/SCADA Systems,” tech. rep., European Union Agency For Network And Information Security, 2017.  https://www.enisa.europa.eu/publications/ics-scada-dependencies.
  * [34] M. Muench, J. Stijohann, F. Kargl, A. Francillon, and D. Balzarotti, “What you corrupt is not what you crash: Challenges in fuzzing embedded devices,” in NDSS, 2018.  https://www.ndss-symposium.org/wp-content/uploads/2018/02/ndss2018_01A-4_Muench_paper.pdf.
  * [35] R. Langner, “Stuxnet: Dissecting a cyberwarfare weapon,” IEEE Security Privacy, vol. 9, pp. 49–51, May 2011.
  * [36] G. George and S. M. Thampi, “A graph-based security framework for securing industrial iot networks from vulnerability exploitations,” IEEE Access, vol. 6, pp. 43586–43601, 2018.  https://ieeexplore.ieee.org/document/8430731.
  * [37] D. Papp, Z. Ma, and L. Buttyan, “Embedded systems security: Threats, vulnerabilities, and attack taxonomy,” in 2015 13th Annual Conference on Privacy, Security and Trust (PST), pp. 145–152, July 2015.  https://ieeexplore.ieee.org/document/7232966.
  * [38] ISECOM, The Open Source Security Testing Methodology Manual (OSSTMM).  2010\.  https://www.isecom.org/OSSTMM.3.pdf.
  * [39] OWASP, “The Open Web Application Security Project.”  https://github.com/OWASP/wstg/releases/download/v4.2/wstg-v4.2.pdf.
  * [40] D. Kleidermacher and M. Kleidermacher, “Practical methods for safe and secure software and systems development,” in Embedded Systems Security (D. Kleidermacher and M. Kleidermacher, eds.), Oxford: Newnes, 2012.  https://www.sciencedirect.com/science/article/pii/B9780123868862000011.
  * [41] O. Andreeva, S. Gordeychik, G. Gritsai, O. Kochetova, E. Potseluevskaya, S. Sidorov, and A. Timorin, “Industrial control systems vulnerabilities statistics,” tech. rep., 03 2016.  https://www.researchgate.net/publication/337732465_INDUSTRIAL_CONTROL_SYSTEMS_VULNERABILITIES_STATISTICS.
  * [42] R. J. Thomas and T. Chothia, “Learning from vulnerabilities - categorising, understanding and detecting weaknesses in industrial control systems,” in Computer Security (S. Katsikas, F. Cuppens, N. Cuppens, C. Lambrinoudakis, C. Kalloniatis, J. Mylopoulos, A. Antó, S. Gritzalis, W. Meng, and S. Furnell, eds.), (Cham), pp. 100–116, Springer International Publishing, 2020.  https://link.springer.com/chapter/10.1007/978-3-030-64330-0_7.
  * [43] D. Hwang, P. Schaumont, K. Tiri, and I. Verbauwhede, “Securing embedded systems,” IEEE Security Privacy, vol. 4, no. 2, pp. 40–49, 2006.  https://ieeexplore.ieee.org/document/1621059.
  * [44] J. Viega and H. Thompson, “The state of embedded-device security (spoiler alert: It’s bad),” IEEE Security Privacy, vol. 10, no. 5, pp. 68–70, 2012\.  https://ieeexplore.ieee.org/document/6322974?section=abstract.
  * [45] P. Marwedel, “Embedded systems foundations of cyber-physical systems, and the internet of things,” in Embedded System Design, Switzerland: Springer Nature, 2018.  https://link.springer.com/book/10.1007%2F978-3-319-56045-8.
  * [46] B. B. Nielsen, M. T. Torp, and A. Møller, “Modular call graph construction for security scanning of node.js applications,” in Proceedings of the 30th ACM SIGSOFT International Symposium on Software Testing and Analysis, ISSTA 2021, (New York, NY, USA), p. 29–41, Association for Computing Machinery, 2021.  https://dl.acm.org/doi/10.1145/3460319.3464836.
  * [47] R. E. Sawilla and X. Ou, “Identifying critical attack assets in dependency attack graphs,” in Computer Security - ESORICS 2008 (S. Jajodia and J. Lopez, eds.), (Berlin, Heidelberg), pp. 18–34, Springer Berlin Heidelberg, 2008.  https://link.springer.com/chapter/10.1007/978-3-540-88313-5_2#citeas.
  * [48] MITRE Corporation, “CVE - Common Vulnerabilities and Exposures.”  https://cve.mitre.org/about/terminology.html.
  * [49] MITRE Corporation, “CVE - Common Vulnerability and Exposures.”  https://cve.mitre.org/index.html.
  * [50] National Institute for Standards and Technology (NIST), “National Vulnerability Database NVD — Vulnerabilities.”  https://nvd.nist.gov/vuln/full-listing.
  * [51] FIRST - global Forum of Incident Response and Security Teams, “Common Vulnerability Scoring System (CVSS).”  https://www.first.org/cvss/.
  * [52] MITRE Corporation, “CWE - Common Weakness Enumeration.”  https://cwe.mitre.org/index.html.
  * [53] MITRE Corporation, “CWE - Common Weakness Enumeration.”  https://cwe.mitre.org/about/faq.html.
  * [54] Y. Jiang, Y. Atif, and J. Ding, “Cyber-physical systems security based on a cross-linked and correlated vulnerability database,” in Critical Information Infrastructures Security (S. Nadjm-Tehrani, ed.), (Cham), pp. 71–82, Springer International Publishing, 2020.  https://link.springer.com/book/10.1007/978-3-030-37670-3.
  * [55] National Institute for Standards and Technology (NIST), “CPE - Common Platform Enumeration.”  https://nvd.nist.gov/products/cpe.
  * [56] Brant A. Cheikes and David Waltermire and Karen Scarfone, “NIST Interagency Report 7695 - Common Platform Enumeration: Naming Specification Version 2.3,” nist interagency report, National Institute for Standards and Technology (NIST), Gaithersburg, Maryland, 2011.  https://tsapps.nist.gov/publication/get_pdf.cfm?pub_id=909010.
  * [57] Mary C. Parmelee and Harold Booth and David Waltermire and Karen Scarfone, “NIST Interagency Report 7696 - Common Platform Enumeration: Name Matching Specification Version 2.3,” nist interagency report, National Institute for Standards and Technology (NIST), Gaithersburg, Maryland, 2011.  https://tsapps.nist.gov/publication/get_pdf.cfm?pub_id=909008.
  * [58] MITRE Corporation, “CAPEC - Common Attack Pattern Enumeration and Classification.”  https://capec.mitre.org/.
  * [59] MITRE Corporation, “CAPEC - Common Attack Pattern Enumeration and Classification.”  https://capec.mitre.org/about/glossary.html.
  * [60] “IEC 62443: Industrial Communication Networks—Network and System Security,” standard, IEC Central Office, Geneva, Switzerland, 2010.
  * [61] I. Mugarza, J. L. Flores, and J. L. Montero, “Security issues and software updates management in the industrial internet of things (iiot) era,” Sensors, vol. 20, no. 24, 2020.  https://www.mdpi.com/1424-8220/20/24/7160.
  * [62] International Electrotechnical Commission, “IEC 62443: Security for Industrial Automation and Control Systems — Part 4-1: Secure Product Development Lifecycle Requirements,” standard, International Electrotechnical Commission, Geneva, Switzerland, 2018.
  * [63] A. Avizienis, J. . Laprie, B. Randell, and C. Landwehr, “Basic concepts and taxonomy of dependable and secure computing,” IEEE Transactions on Dependable and Secure Computing, vol. 1, no. 1, pp. 11–33, 2004\.  https://ieeexplore.ieee.org/document/1335465.
  * [64] W. He, H. Li, and J. Li, “Unknown vulnerability risk assessment based on directed graph models: A survey,” IEEE Access, vol. 7, pp. 168201–168225, 2019.  https://ieeexplore.ieee.org/abstract/document/8906081.
  * [65] “Information technology —– Security techniques –— Vulnerability handling processes,” standard, International Organization for Standardization, Geneva, CH, oct 2019.  https://www.iso.org/standard/69725.html.
  * [66] CC, “The Common Criteria for Information Technology Security Evaluation - Introduction and General Model.”  https://www.commoncriteriaportal.org/files/ccfiles/CCPART1V3.1R5.pdf.
  * [67] Common Criteria (CC), “Part 3: Security Assurance Components.”  https://commoncriteriaportal.org/files/ccfiles/CCPART3V3.1R5.pdf.
  * [68] D. Herrmann, Using the Common Criteria for IT Security Evaluation.  12 2002.  https://www.taylorfrancis.com/books/mono/10.1201/9781420031423/using-common-criteria-security-evaluation-debra-herrmann.
  * [69] D. Mellado, E. Fernández-Medina, and M. Piattini, “A common criteria based security requirements engineering process for the development of secure information systems,” Computer Standards & Interfaces, vol. 29, no. 2, pp. 244–253, 2007.  https://www.sciencedirect.com/science/article/pii/S0920548906000511.
  * [70] A. Hohenegger, G. Krummeck, J. Baños, A. Ortega, M. Hager, J. Sterba, T. Kertis, P. Novobilsky, J. Prochazka, B. Caracuel, A. L. Sanz, F. Ramos, H. Blasum, M. Brotz, C. Gries, T. Vögler, J. Neškudla, J. Rollo, L. Burgstaller, M. Truskaller, K.-M. Koch, Technikon, R. Hametner, S. Rauscher, P. Tummeltshammer, T. Austria, F. Golatowski, and T. Schulz, “Security certification experience for industrial cyberphysical systems using common criteria and iec 62443 certifications in certmils,” in 2021 4th IEEE International Conference on Industrial Cyber-Physical Systems (ICPS), pp. 25–30, 2021.  https://ieeexplore.ieee.org/document/9468241.
  * [71] J. Homer, X. Ou, and D. Schmidt, “A sound and practical approach to quantifying security risk in enterprise networks,” tech. rep., 2009.  https://www.cse.usf.edu/~xou/publications/tr_homer_0809.pdf.
  * [72] S. Zhang, X. Ou, A. Singhal, and J. Homer, “An empirical study of a vulnerability metric aggregation method,” tech. rep., KANSAS STATE UNIV MANHATTAN, 2011.  https://www.cse.usf.edu/~xou/publications/stmacip11.pdf.
  * [73] J. Homer, S. Zhang, X. Ou, D. Schmidt, Y. Du, S. R. Rajagopalan, and A. Singhal, “Aggregating vulnerability metrics in enterprise networks using attack graphs,” Journal of Computer Security, vol. 21, no. 4, pp. 561–597, 2013.  https://content.iospress.com/articles/journal-of-computer-security/jcs475.
  * [74] G. George and S. M. Thampi, “A graph-based security framework for securing industrial iot networks from vulnerability exploitations,” IEEE Access, vol. 6, pp. 43586–43601, 2018.  https://ieeexplore.ieee.org/document/8430731.
  * [75] S. Li, Y. Chen, X. Wu, X. Cheng, and Z. Tian, “Power Grid-Oriented Cascading Failure Vulnerability Identifying Method Based on Wireless Sensors,” Journal of Sensors, vol. 2021, p. 8820413, June 2021\.  https://www.hindawi.com/journals/js/2021/8820413/.
  * [76] B. Liu, G. Zhu, X. Li, and R. Sun, “Vulnerability assessment of the urban rail transit network based on travel behavior analysis,” IEEE Access, vol. 9, pp. 1407–1419, 2021.  https://ieeexplore.ieee.org/document/9306836.
  * [77] N. Poolsappasit, R. Dewri, and I. Ray, “Dynamic security risk management using bayesian attack graphs,” IEEE Transactions on Dependable and Secure Computing, vol. 9, no. 1, pp. 61–74, 2012.  https://ieeexplore.ieee.org/document/5936075.
  * [78] L. Muñoz-González, D. Sgandurra, M. Barrère, and E. C. Lupu, “Exact inference techniques for the analysis of bayesian attack graphs,” IEEE Transactions on Dependable and Secure Computing, vol. 16, no. 2, pp. 231–244, 2019.  https://ieeexplore.ieee.org/document/7885532.
  * [79] X. Liu, C. Qian, W. G. Hatcher, H. Xu, W. Liao, and W. Yu, “Secure internet of things (iot)-based smart-world critical infrastructures: Survey, case study and research opportunities,” IEEE Access, vol. 7, pp. 79523–79544, 2019\.  https://ieeexplore.ieee.org/document/8730298.
  * [80] J. Hu, S. Guo, X. Kuang, F. Meng, D. Hu, and Z. Shi, “I-hmm-based multidimensional network security risk assessment,” IEEE Access, vol. 8, pp. 1431–1442, 2020.  https://ieeexplore.ieee.org/document/8941077.
  * [81] I. Zografopoulos, J. Ospina, X. Liu, and C. Konstantinou, “Cyber-physical energy systems security: Threat modeling, risk assessment, resources, metrics, and case studies,” IEEE Access, vol. 9, pp. 29775–29818, 2021\.  https://ieeexplore.ieee.org/document/9351954.
  * [82] M. Khosravi-Farmad and A. Bafghi, “Bayesian decision network-based security risk management framework,” Journal of Network and Systems Management, vol. 28, 10 2020.  https://link.springer.com/article/10.1007/s10922-020-09558-5.
  * [83] A. Atzeni and A. Lioy, “Why to adopt a security metric? a brief survey,” Advances in Information Security, vol. 23, pp. 1 – 12, 2006.  https://link.springer.com/chapter/10.1007%2F978-0-387-36584-8_1.
  * [84] T. Zeb, M. Yousaf, H. Afzal, and M. R. Mufti, “A quantitative security metric model for security controls: Secure virtual machine migration protocol as target of assessment,” China Communications, vol. 15, no. 8, pp. 126–140, 2018.  https://ieeexplore.ieee.org/document/8438279.
  * [85] A. Longueira-Romero, R. Iglesias, D. Gonzalez, and I. n. Garitano, “How to quantify the security level of embedded systems? a taxonomy of security metrics,” in 2020 IEEE 18th International Conference on Industrial Informatics (INDIN), vol. 1, pp. 153–158, 2020.  https://ieeexplore.ieee.org/document/9442219.
  * [86] M. Rudolph and R. Schwarz, “A critical survey of security indicator approaches,” in 2012 Seventh International Conference on Availability, Reliability and Security, pp. 291–300, Aug 2012.  https://ieeexplore.ieee.org/document/6329197.
  * [87] S. Sentilles, E. Papatheocharous, and F. Ciccozzi, “What Do We Know about Software Security Evaluation? A Preliminary Study,” in QuASoQ@APSEC, 2018\.  http://ceur-ws.org/Vol-2273/QuASoQ-04.pdf.
  * [88] M. A. Amutio, J. Candau, and J. A. Mañas, “MAGERIT V3.0. Methodology for Information Systems Risk Analysis and Management. Book I - The Method,” National Standard, Ministry of Finance and Public Administration, Madrid, Spain, 2014.
  * [89] Marnix Dekker, and Christoffer Karsberg, “Guideline on Threats and Assets: Technical guidance on threats and assets in Article 13a,” tech. rep., European Union Agency For Network And Information Security, 2015.  https://www.enisa.europa.eu/publications/technical-guideline-on-threats-and-assets.
  * [90] ISO, ISO/IEC 13335-1:2004 - Information technology — Security techniques — Management of information and communications technology security — Part 1: Concepts and models for information and communications technology security management.  Geneva, Switzerland: International Organization for Standardization.
  * [91] ISO, ISO 8601:2019. Data and time -Representation for information interchange - Part 1: Basic rules.  Geneva, Switzerland: International Organization for Standardization.
  * [92] NIST - National Institute of Standards and Technology, “National Vulnerability database (NVD).”  https://nvd.nist.gov/.
  * [93] A. Dimitriadis, J. L. Flores, B. Kulvatunyou, N. Ivezic, and I. Mavridis, “Ares: Automated risk estimation in smart sensor environments,” Sensors, vol. 20, no. 16, 2020.  https://www.mdpi.com/1424-8220/20/16/4617.
  * [94] International Electrotechnical Commission, “IEC 62443: Security for Industrial Automation and Control Systems — Part 4-2: Technical Security Requirements for IACS Components,” standard, International Electrotechnical Commission, Geneva, Switzerland, 2019.  https://www.isa.org/products/ansi-isa-62443-4-1-2018-security-for-industrial-au.
  * [95] Thiago Alves, “OpenPLC Project.”  https://www.openplcproject.com/.
  * [96] T. R. Alves, M. Buratto, F. M. de Souza, and T. V. Rodrigues, “Openplc: An open source alternative to automation,” in IEEE Global Humanitarian Technology Conference (GHTC 2014), pp. 585–589, 2014.  https://ieeexplore.ieee.org/document/6970342.
  * [97] T. Alves and T. Morris, “Openplc: An iec 61,131–3 compliant open source industrial controller for cyber security research,” Computers & Security, vol. 78, pp. 364–379, 2018.  https://www.sciencedirect.com/science/article/pii/S0167404818305388?via%3Dihub.
  * [98] Thiago Alves, “OpenPLC V1.”  https://github.com/thiagoralves/OpenPLC.
  * [99] Thiago Alves, “OpenPLC V2.”  https://github.com/thiagoralves/OpenPLC_v2.
  * [100] Thiago Alves, “OpenPLC V3.”  https://github.com/thiagoralves/OpenPLC_v3.