Content uploaded by Marco Rocchetto
Author content
All content in this area was uploaded by Marco Rocchetto on Sep 22, 2021
Content may be subject to copyright.
The Etiology of Cybersecurity
Francesco Beltramini, Federico De Meo, Olivero Nardi, Mattia Pacchin, Marco Rocchetto
V-Research
Verona, Italy
Email: knowledgezero@v-research.it
Abstract—The objective of this research is to lay the founda-
tions for the development of a scientific theory that determines
(all and only) the possible insecure and secure configurations of
any abstract system. We claim that cybersecurity weaknesses
(i.e. errors) are at the beginning of the causality chain that
leads to cybersecurity attacks. We, then, formulate a scientific
(falsifiable by experiments) hypothesis that we use to predict
all the weaknesses in the architectural design of an abstract
system. The mathematical formulation of our hypothesis is
based on a correlation between the epistemological concepts of
facts, beliefs, and assertions with the engineering concepts of
requirements, functional architectures, and channels. Ultimately,
our hypothesis allows for the definition of a mathematical formula
which describes the cybersecurity of a system. We implemented
a prototype cybersecurity risk assessment tool that, based on
our hypothesis, predicts the weaknesses in a UML model of a
(cyber-physical) system.
I. INTRODUCTION
a) Context and motivation: Ascientific theory is an
explanation of a phenomenon such that the explanation follows
the scientific method. The scientific method is an empirical
method that aims at mitigating potential fallacies in theories.
Karl Popper famously argued (e.g. in [33]) that a scientific
theory can never be verified but only falsified, that a theory
should not be conceived by using the principle of induction1,
and that empirical experiments should be considered as the
only evidence to support the non-falseness of a scientific
theory. If we consider a natural (real-world) phenomenon,
such as gravity, we can think of a scientific theory as an
abstract mathematical formula (or a set of formulas) that
defines axiomatically a certain (natural) phenomenon in a
specific algebraic structure. While such a theory can be proved
to be correct within the mathematical setting it has been
conceived in (e.g. with respect to other axioms of the algebraic
structure where it has been postulated, or with respect to other
background theories), no proof can be carried out to verify
that the theory properly abstracts the phenomenon it describes
(i.e. that the theory is a sound or complete approximation of
the real phenomenon). Similarly, the results of the application
of a scientific theory (i.e. its predictions) can be verified
in the abstract mathematical structure, but how can we be
sure that the theory correctly characterizes the phenomenon
it describes? Popper’s famous “demarcation principle” draws
a line between scientific and pseudo-scientific theories by
1Albert Einstein wrote to Popper: “[...] and I think (like you, by the way)
that theory cannot be fabricated out of the results of observation, but that it
can only be invented.” [33]
proposing that a scientific theory can be considered acceptable
as long as no empirical experiment falsify it. For example, a
theory of gravity, in its mathematical setting, can predict how
objects attract each other, and those predictions can be tested
by empirical experiment. If the theory correctly represents
the phenomenon, no empirical experiment should falsify the
predictions of that theory.
In [19], Cormac Herley explores what he calls “an asymme-
try in computer security”, which he defines as follows: “Things
can be declared insecure by observation, but not the reverse.
There is no observation that allows us to declare an arbitrary
system or technique secure”. With security, Herley only fo-
cuses on cybersecurity (we also use security and insecurity, in
this paper, only to refer to cyber-insecurity and cybersecurity)
and his intuition is that there is no scientific theory that
can predict the cybersecurity of a system, nor a theory that
can predict all possible insecurities of a system (which, by
negation, may be used as a theory of cybersecurity). Herley
then uses this argument to show that “claims that any measure
is necessary for security are empirically unfalsifiable”. An
example is whether or not password masking makes a system
secure. Password masking prevents a complete leakage of
the password, and a system, in which password masking is
implemented, is believed to be secure because an attacker
won’t be seeing the password by “shoulder surfing”. This
reasoning is circular and it is always true that a system in
which password masking is implemented is a system in which
a password is masked. No experiment can ever falsify this
statement2. Given that any theory that is not falsifiable by an
empirical experiment is well known3to be nonscientific (i.e.
unfalsifiability is a fallacy of a theory), Herley concludes that
there is no scientific theory supporting this type of cybersecu-
rity measures; generalizing, cybersecurity seems to lay in the
realm of pseudo-sciences [18]. Herley, e.g. in [17], discusses
the implications of a nonscientific approach to cybersecurity,
and highlights the tremendous impact on the scientific research
and engineering of systems. While the criticism is investigated
in [19], no solution is provided nor envisioned.
b) Contributions: The goal of this paper is to lay the
foundations of a scientific cybersecurity theory. We consider
2In other words, one cannot design an experiment to show that password
masking is not secure or unnecessary, and a correlated problem is that this
may lead to a scenario where more measures are added but there is no good
way of saying which measures are superflous.
3“A theory which is not refutable by any conceivable event is nonscientific.
Irrefutability is not a virtue of a theory (as people often think) but a vice.” –
Karl Popper, Conjectures and Refutations [32].
the problem raised by Herley not confined to “computer
security” but rather we reason on any abstract system (so
that our scientific hypothesis4may be tested in any sound
implementation such as networks, mechanical, cyber, or cyber-
physical system, or even a single computer or a single device
such as a hard-drive).
Instead of starting from reasoning on what makes a system
secure or insecure, we reason on what causes insecurities.
We focus on insecurities only caused by the exploitation
of cybersecurity attacks, and we assume that achieving cy-
bersecurity means preventing all those attacks from being
exploitable or exploited. Our hypothesis is that cybersecurity
attacks are only caused by the presence of errors in the design
or implementation of a system (i.e. cybersecurity weaknesses).
For example, a design or implementation weakness in a
sanitization function may allow an attacker to perform SQL-
injections. If weaknesses are necessary to enable cybersecurity
attacks, a theory that predicts all potential weaknesses can be
effectively used to predict the (in)security of a system. There-
fore, a possible answer to the initial question can be that (def-
inition) cybersecurity is the absence of attacks and (claim) the
absence of weaknesses implies cybersecurity. This, however,
raises another question: “which are all the errors/weaknesses
in (the engineering of) a system that make it possible for
a cybersecurity attack to happen?”. More rigorously, which
scientific theory predicts all possible weaknesses that causes
cybersecurity attacks?
With our approach, a list of weaknesses emerges from the
mathematical formulation of a system in a framework called
ABF -framework, and predicts 4 main classes of weaknesses.
Those classes of weaknesses are used to calculate all the
insecurity configurations of all the components of a system,
obtaining a precise estimation of all potential cybersecurity-
related risks in any given system. Our hypothesis can be
falsified by means of experiments, testing if all the predicted
weaknesses are present in the system under test, or testing
if other (not predicted by our hypothesis) weaknesses are
present. In fact, if any cybersecurity weaknesses were to be
found in a system and not predicted by our hypothesis, the
hypothesis could be declared incomplete. If a cybersecurity
weakness would be predicted by our hypothesis but found to
be impossible to realize, our hypothesis could be declared as
wrong.
c) Structure: We start, in Section II, by detailing the
problem statement, reporting a literature review on the main
concepts and definitions related to cybersecurity. We formulate
a cybersecurity hypothesis in Section III; which we use to
propose a mathematical formulation of our hypothesis on
system cybersecurity in Section IV. In Section IV-C, we
apply our hypothesis for the tool-assisted cybersecurity risk
assessment of a Cyber-Physical System (CPS), with an ad-
hoc example. This application shows how our hypothesis can
4In the reminder of this paper, we will use the word hypothesis to refer
to “scientific hypothesis” as a proposed scientific theory that has not gone
through an extensive series of tests. Instead, we use “logical theory” to refer
to a set of formal logical axioms.
be used to predict all of the possible cybersecurity weaknesses
of a system, allowing the falsification of our hypothesis.
II. LITERATURE REVIEW
In most of the natural languages the concepts of safety
and security are not syntactically differentiated and both
terms (safety and security) are expressed by the same word,
e.g. “sicurezza” in Italian. A semantic distinction between
safety and (cyber)security is correlated to a belief5that safety
deals with accidents (i.e. an unfortunate incident) posed by
the natural environment (e.g. natural events such as wearing
of hardware components), whereas cybersecurity deals with
incidents posed by mankind (e.g. attackers and bugs). The
fundamental difference between nature and mankind (and, in
turn, between safety and cybersecurity) is believed to be on the
different intents (incidents are intentional, whereas accidents
are not) of the causes that generates a threat. Namely, nature is
believed not to have malicious intents (but unfortunate causes-
effects), whereas threats generated by mankind are malicious6.
This conclusion seems to be against a general formulation of a
cybersecurity theory; how can we define a theory that predicts
what a human being will do? Cybersecurity attacks seem to be
related to the creativity of the attacker and thus unpredictable.
Currently, the most complete understanding of insecurity
issues is stored into a network of databases of weaknesses
(e.g. CWE [8]), vulnerabilities (e.g. CVE [7], NVD [46]),
and attacks (e.g. CAPEC [6], ATT&CK [35]). Those in-
security issues can be related to the violation of one or
more requirements (explicit or implicit) in the specification,
design or implementation of a system. The correlation between
insecurity flaws and cybersecurity requirements has been used
to define standards such as the IEC 62443-1-3 (the Industrial
communication networks - Network and system security –
Part 3-3: System security requirements and security levels)
which defines requirements as “confidentiality of informa-
tion in transit/at-rest”. More generally, the idea of defining
cybersecurity requirements as properties of a system was
initially defined in 1970s with the CIA triad (Confidentiality,
Integrity, Availability) and refined over the decades introduc-
ing related concepts such as authenticity or non-repudiation,
or introducing new ones such as “responsibility” in the RITE
approach (see [41] for an overview of the evolution of the
CIA triad). The link between cybersecurity requirements and
vulnerabilities is reported in the NVD databases by the CVSS
[28] scoring system. The CVSS evaluates of the severity of
a vulnerability by means of different metrics (such as attack
complexity and user interaction) and quantitatively evaluates
the impact on the CIA triad. While cybersecurity requirements,
weaknesses, vulnerabilities, and attacks have been extensively
studied and implemented both in academia and industry to
5A belief has to be intended as a proposition which is supposed to be true
but no conclusive evidence makes it known to be true.
6Of course, logical flaws or bugs may be introduced by other means (e.g.
ignorance) without explicit malicious intents, but the exploitation of those
flaws is considered (for now, and detailed afterwards in the article) malicious,
and thus we consider any vulnerability to be malicious even if it is due to the
lack of skills.
malicious
intents
Nature
Mankind
Vulnerability
Incident
Defect
Exploit
Attack Accident
Failure
Hazard
non-malicious
intents
Threat
Asset
generates realization
Weakness
poses
Risk
System designs
impacts Asset
impacts
Causality
Exploitation
process
Attack
process
Errors
Figure 1. Overview of Keywords Related to Cybersecurity and Safety
provide tools for the testing or verification of systems, no
scientific falsifiable theory correlates cybersecurity require-
ments to necessary and sufficient conditions (e.g. mitigations)
to declare a system secure [19]. Nonetheless, the extensive
body of literature has scientific foundations, for example,
providing formal frameworks for the verification of properties
for cybersecurity. As a driver for our argumentation, we start
by reviewing the key concepts in the cybersecurity domain.
A. Terminology
Most of the safety-preserving principles in the field of
engineering of safety-critical cyber-physical systems (such as
elevators and aircraft), upon which safety requirements are
defined (e.g. in standards such as the IEC 61508 or 61511
[1]), are based on empirical tests and measurements. While
reasoning by induction based on the empirical observation
should be avoided in general, since it may easily lead to
false beliefs [33], inducing general principle by means of tests
is often justified by the supposed impossibility of defining a
theory that correctly predicts failures. A failure of a wire due
to environment (e.g. due to humidity, dust, heat &c) is defined
from empirical evidences and processes have been standard-
ized to test qualities of hardware components. This process
completely breaks down when a malicious environment (i.e.
an attacker) is considered instead of the (supposedly honest
and predictable) natural environment. Therefore, the same
approach that is in use for safety, seems not to be applicable
for cybersecurity (e.g. for cybersecurity testing). An overview
on the aforementioned aspects of safety and cybersecurity
is depicted in Figure 1 and is used as a baseline for a
definition of the terms that structure our current understanding
of cybersecurity.
•Mankind “refers collectively to humans” [24], while the
concept of Nature is related “to the intrinsic characteris-
tics that plants, animals, and other features of the world
develop of their own accord” (e.g. the physical universe)
[25]. There exist several terms to refer to an attacker,
e.g. threat agent or threat source, but, from now on, we
consider the Causality principle to be the threat source,
Nature or Mankind to be the threat agents and an attacker
as a specific malicious threat agent which materializes a
threat.
•Vulnerability, as defined in [30] (and adopted in [5]),
is a “weakness in an information system, system se-
curity procedures, internal controls, or implementation
that could be exploited by a threat source”. On the
one hand, the definition is broad to enclose as much
causes (that generates a vulnerability) as possible, on the
other hand the term vulnerability should have a complete
and sound definition, so that no other causes (e.g. other
sources) but the ones in the definition are responsible for
a vulnerability. Furthermore, the term “threat sources”
used in the definition in [30] may be identified with both
Nature and Mankind, not differentiating between safety
and security.
As depicted in Figure 1, a vulnerability does not necessarily
become a threat for the system, unless exploited “through
a channel that allows the violation of the security policy
[. . . ]” [30]. For example, a software or procedure that takes
advantage of the vulnerability causing an attack to the system
may result in several correlated incidents and threats. The
process of exploitation of a defect as a vulnerability is reported
in Figure 1 such that the difference between exploit and failure,
and attack and accident, is to be found just in the maliciousness
of the intents that causes this process (i.e. excluding the intent,
the terms are just syntactic transformation from a vulnerability
to defect, from accident to incident).
•Weakness. The definition given by the MITRE in [13] of
weakness is: “ a type of mistake that, in proper conditions,
could contribute to the introduction of vulnerabilities
within that product. This term applies to mistakes regard-
less of whether they occur in implementation, design, or
other phases of a product lifecycle.” A vulnerability, such
as those enumerated on the Common vulnerabilities and
Exposures (CVE) List, is a mistake that can be directly
used by an attacker to gain access to a system or network.
The definition is circular if we interpret the word “error”
and “mistake” with the same semantics: a weakness is an
error that leads to a vulnerability and a vulnerability is a
mistake which, in turn, is a weakness. The only difference
between a weakness and vulnerability seems to be that
one can consider weakness as a ground term and state
that a vulnerability is caused by a weakness.
•Causality refers to the causality principle; defined in
Errors
Weak System [CWE]
Vulnerable System [CVE]
System under attack [CAPEC]
Causality
Figure 2. Etiology of cybersecurity
[9] as “Causality is a genetic connection of phenomena
through which one thing (the cause) under certain condi-
tions gives rise to, causes something else (the effect). The
essence of causality is the generation and determination
of one phenomenon by another. In this respect, causality
differs from various other kinds of connection, for exam-
ple, the simple temporal sequence of phenomena, of the
regularities of accompanying processes”.
•An Exploit “[. . . ] (from the English verb to exploit,
meaning to use something to one’s own advantage) is
a piece of software, a chunk of data, or a sequence of
commands that takes advantage of a bug or vulnerability
to cause unintended or unanticipated behavior to occur
on computer software, hardware, or something electronic
(usually computerized).” [23].
•An Attack, as defined by the International Standard
ISO/IEC 27000, is an “attempt to destroy, expose, alter,
disable, steal or gain unauthorized access to or make
unauthorized use of an asset”; where an Asset is “anything
that has value to the organization”. Furthermore, we note
that for the purpose of this article, we do not want to
focus on a specific organization or business to define
asset but, in general, on any abstract organization (e.g. a
company or a society). We do not consider ethical hackers
as attacking a system. In fact, we consider the term hack
as non-malicious (as, e.g. in [44]).
•AThreat, as defined in [30], is “Any circumstance or
event with the potential to adversely impact organiza-
tional operations (including mission, functions, image,
or reputation), organizational assets, individuals, other
organizations, or the Nation through an information
system via unauthorized access, destruction, disclosure,
modification of information, and/or denial of service”.
•Defect: “anything that renders the product not reasonably
safe” [37] (i.e. a characteristic of an object which hinders
its proper usability).
•Failure, as defined in [22], is “a state of inability to
perform a normal function”. The term is structured and
detailed in [30, 12], but relying on an abstract notion of
failure without a specific definition.
•Hazard, “a potential source of harm” [12].
Our literature review shows that most of the definitions
relate insecurity to dis-honesty (also called maliciousness or
adversarial) of an agent (often called adversary or attacker). In
fact, weaknesses become vulnerability if an attacker exploits
them in an attack. This, however, just shifts the problem of
defining what cybersecurity is as the problem of defining what
a dishonest agent can or cannot do in a system, where an
agent is any virtual or physical entity of the system or using
the system (e.g. a device, a software, or a human being), and
dishonesty is not necessarily related to malicious motivation
but also to incompetence or lack of skills. As in the Dolev-Yao
attacker model7[10], we may correlate “being dishonest” to
“not following the intended behavior/rules”. In the case of a
generic system, a dishonest agent is, therefore, any agent that
doesn’t follow the intended behavior (or functionality or logic)
of the system. For example, a software can be considered an
agent of the system and whenever it has a bug, it can be
exploited causing an incident. This may lead to the conclusion
that the dishonest behaviors of agents cannot be defined in
general (e.g. due to the heterogeneity of agents and systems)
and that a huge repository of dishonest behaviors should be
kept as definition, such as CAPEC [6]; or that dishonesty of
an agent with respect to a cybersecurity protocol should be
defined as a number of predefined actions as in [50, 4, 3, 38]
(to name a few)8. As depicted in Figure 2, in order to define
a theory on cybersecurity we may say that the presence of
vulnerabilities is a necessary condition in order to cause an
attack in the system. Those vulnerabilities are, in turn, caused
by the presence of weaknesses in the system. Weaknesses are
errors in the design or implementation of a system. Therefore,
a theory on cybersecurity should first predict the errors in a
system design.
III. A CYBERSECURITY HYPOTH ES IS I N TH E
ABF -FRAMEWORK
In order to address the problem raised by Herley, we shall
define how to distinguish between a secure and an insecure
system. While most of the literature have correlated the prob-
lem of in-security to the maliciousness of agents interacting
with the system, we show that cybersecurity doesn’t seem
to stem from a malicious nature but, rather, insecurity raises
from the lack of well-defined cybersecurity requirements for
the development process of a system. We argue that the high
number of cybersecurity vulnerability reported today are sim-
ply the realization of potential system configurations, which
deviate from the intended (or nominal) behavior because the
nominal behavior of the system is not precisely defined in
the specification at the very early stages of the engineering
process. As a reference, we consider the following steps of
the engineering process and our objective is to be able to
predict the cybersecurity requirements instead of axiomatically
assume them.
1) System Specification, where the functional and physical
requirements are defined.
2) Architecture Design, where the specification is structured
into functional and physical architectures.
7The Dolev-Yao attacker model can be considered as abstract model of an
attacker that can be used for the analysis of protocol specifications.
8In formal protocol verifiers, in the DY model, the attacker has a set of hard-
coded inference rules that defines how the attacker deduces new messages
based on the observed message exchange.
3) Cybersecurity Risk Assessment, where the potential weak-
nesses (errors) are identified and, consequently, cyberse-
curity requirements are captured.
Given that, in our investigation, we changed the focus from
the attacker to the potential designs of a system, we start by
defining a general framework for the definition of a system.
On top of this framework we will identify system weaknesses
as potential design errors.
A. Epistemology and Multi-Agent Systems
The ISO/IEC/IEEE 15288:2015 (System Life Cycle Pro-
cesses) provides a definition of system as “A combination
of interacting elements organized to achieve one or more
stated purposes.”[45]. If a system is structured into multiple
sub-systems, a sub-system can be defined in the same way
as a system is defined (i.e. as a composition of interacting
elements). A hierarchy of sub-systems can be limited by a
“bottom-subsystem” often called device (or element in the
aforementioned definition) which is not itself composed by
other elements but is considered atomic. For the sake of
simplicity, we consider a device as a system with only one
element: itself. We then first define a system as composed by a
single element and then extend the definition to a “combination
of interacting” elements. Given that we use concepts from the
multi-agent system research field, instead of using the word
element we will use the word agent.
There is no agreement between the research communities
(e.g. Multi-Agent-System, Epistemic Logic) on what the con-
stituent of an agent are, but the same ideas revolved around for
thousands of years9. Some relevant examples for our objective
are the following.
•In [20], Hintikka describes the concept of belief (as epis-
temological concepts) and their relation with knowledge,
and the whole Doxastic logic defines in details how
beliefs can be formalized.
•In [21], Hintikka describes the concept of information
(and the difference with knowledge and belief).
•In [42], the authors defines an agent as a tuple of asser-
tions, beliefs, and facts. A detailed discussion on facts
and assertions can be found in [29] and [31] respectively.
For our argument, as in [42], an agent is composed by its
beliefs (internal information considered true by the agent),
and assertions (an exchange of information between agents).
As defined in [21], “information is specified by specifying
which alternatives concerning the reality it admits and which
alternatives excludes”. This means that if we consider a propo-
sitional variable (which admits the two alternatives True/False)
its information is defined as believed to be True/False and
not believed to be the opposite. Due to the definition of
information and then with its relation to the probabilistic
9It is interesting to notice that in [11], the author states: “The logical
criterion also may be used in three senses – of the agent, or the instrument,
or the “according to what”; the agent, for instance, may be a man, the
instrument either sense perception or intelligence, and the “according to what”
the application of the impression “according to” which the man proceeds to
judge by means of one of the aforesaid instruments”.
correlation to truth/reality, we consider information in relation
to an agent’s beliefs. Similarly, we consider beliefs to define
the actual behavior of an agent or a system; meaning that
an agent has its own beliefs on top of which it bases its
behavior, the consequences of which, in turn, will update
its initial beliefs. The concepts of facts and assertions as
used in [42], are not precisely discussed in [42]. Furthermore,
those epistemological concepts are difficult to define [49] in
general. For example, Hintikka in [21] states that “A purely
logical definition of information is impossible”. However, a
detailed formalization of those concepts is out of the scope of
this paper. Instead, we now define those concepts informally,
inspired by the ABF -framework defined in [42] and, in
Section IV we detail them, and properly define them, as
engineering concepts.
1) We consider information only when the intention of
exchanging that information is from a sender to recipient;
and we call it assertion.
2) Similarly, the portion of beliefs we consider for system
engineering is the one that builds (input) or describes
(output) the behavior of an agent.
3) We consider a set of axiomatic facts determining how
the system shall be. Similarly, requirements determine
which facts must hold when the system is implemented10.
Specifically, facts/requirements describe: the functional
architecture of each agent, and the physical/structural
(HW/SW) architecture of each subsystem of agents and
agent within a subsystem.
We give a graphical representation of (sub-)system and
agent in Figure 3. The notation will be introduced in the next
section but, intuitively, Figure 3 shows a system composed by
two agents. The system has two ports denoted by “I” (with
incoming assertions) and “O” (with outgoing assertions). The
bottom part of Figure 3 details the structure of a single agent
which is not decomposed into other (sub-)agents. In this case,
ports translates incoming assertions into beliefs that feeds the
behavior block, and outgoing beliefs from the behavior block
are then translated back into (outgoing) assertions.
B. Mereo-topological Reasoning
Similarly to [42], we define agents as a meronomy (an
hierarchy of Part-Whole relations) over the constituents that
we previously defined (assertions, beliefs, and facts), based on
a standard definition of mereology, i.e. based on the definition
of parthood relation between parts. Due to the necessity of
considering different relations between parts (as we’ll show
afterwards) we extend the mereology to a mereo-topology
[43, 51, 34], considering the relations in Table I. For the
sake of readability, we use the term region both to refer to
a mereological part and to a topological region. Our aim is to
create a meronomy (hierarchy of part-whole relations) instead
of the taxonomies (categorization based on discrete sets) such
10We consider facts as definitory rules[21] since they don’t define how a
real system is finally implemented but how it shall be, trough a series of
requirements. Those requirements may not hold, through insecurity, in the
implemented system.
RCC3
RCC5
RCC8
Terminology Notation Definition
Connects with C(X,Y)reflexive and symmetric
Disconnected from ¬C(X,Y)irreflexive or antisymmetric
Part of P(X,Y)∀Z C (Z,X)→C(Z,Y)
Overlaps O(X,Y)∃Z P(Z,X)∧P(Z,Y)
Equal to EQ(X,Y)P(X,Y)∧P(Y,X)
Overlaps Not Equal ONE (X,Y)O(X,Y)∧ ¬EQ(X,Y)
DiscRete from DR(X,Y)¬O(X,Y)
Partial-Overlap PO(X,Y)O(X,Y)∧ ¬P(X,Y)∧ ¬P(Y,X)
Proper-Part-of PP(X,Y)P(X,Y)∧ ¬P(Y,X)
Proper-Part-of-inverse PPi(X,Y)P(Y,X)∧ ¬P(X,Y)
Externally Connected EC (X,Y)C(X,Y)∧ ¬O(X,Y)
Tangential PP TPP (X,Y)PP (X,Y)∧ ∃Z[EC (Z,X),EC (Z,Y)]
Tangential PPi TPPi(X,Y)TPP(Y,X)
Non-Tangential PP NTPP(X,Y)PP(X,Y)∧ ¬∃Z[EC (Z,X),EC (Z,Y)]
Non-Tangential PPi NTPPi(X,Y)NTPP(Y,X)
Table I
RCC3, RCC5, AN D RCC8 RELATIONS BETWEEN REGIONS X,YAND Z
AgentAgent
I O I O
System
I O
Agent
Behavior
I O
Figure 3. Example of system and agent structure
as the one provided in [46, 36] so that we don’t need to rely on
a scoring system (such as the CVSS) to assign a quantitative
evaluation of the cybersecurity of each entry. Instead, we want
a precise calculation of the number of insecure configurations
of a system to emerge from the mathematical formulation of
our cybersecurity hypothesis.
A mereotopology, as defined e.g. in [34], is a mathematical
structure where the basic relation between regions is the
reflexive and symmetric relation Connects With, that we use
to order a universe of agents Ag (see in Table I). We use the
Region Connection Calculus (RCC), as defined in [26, 15], to
provide an axiomatization of the mereo-topological concepts.
In its broader definition, the RCC theory is composed by eight
axioms, and is known as RCC8. In the text, for brevity, we will
often focus only on RCC5 without loss of generality. Using
RCC5 instead of RCC8 prevents us from considering tangen-
tial connections between spatial regions. However, tangential
connections in RCC8 can be considered as special cases of
the more general spatial relations considered in RCC5.
In Table I, we summarize the axioms of the RCC (see, e.g.,
[16]). We can now define a system over the mereotopology
using the RCC calculus, as follows, where rcc(X, Y )on two
generic regions X, Y represents one of the possible RCC
relations between Xand Y. We note that all the RCC relations
are symmetric with the exception of those that have an explicit
(related) inverse.
Definition 1. System State – A CPS system (or
a sub-system) state is defined as the tuple s=
hrcc(F,B), rcc(F,A), rcc(B,A)i, where A,B,F, are re-
gions of assertions, beliefs (i.e. the beliefs generated by the
behavior), and facts expressed as requirements respectively.
As in [42], it follows that, defining a system with a fixed
number of regions, there exists an upper-bound to the number
of possible configuration of a system, defined by the possible
relations between the different regions. For completeness, we
report in the next paragraph the calculation done by the authors
in [42].
a) Number of different configurations of a system: The
general formula to calculate the number of different types of
agents is r(n
k), where ris the number of relations with arity
k, between ndifferent regions. Therefore, r(n
k)expresses the
number of permutation of rrelations over n
kelements with
repetitions, with n
kbeing the number of k-ary combinations
of nregions. In our case, n
k= 3 since we consider 3
regions (A,B,F), and all the relations considered in the RCC
are binary. Hence, using RCC5 (with five different spatial
relations) over three regions, we can theoretically define up to
125 different type of agents. However, only 54 of the 125 (as
showed in [15]) combinations are topologically correct with
respect to the definition of the relations of RCC5. Generalizing
to all the RCCs:
•RCC3 — theoretical: 33= 27, correct: 15.
•RCC5 — theoretical: 53= 125, correct: 54.
•RCC8 — theoretical: 83= 512, correct: 193.
Hence, even if considering a different number of regions
than the three A,B, and Fexponentially affects the number
of theoretical agents, the application of RCC downscales that
number of a factor that ranges from 1.8 to 2.5. In addition,
using RCC5 we consider 3.6 times more (different) types of
agents than RCC3, but using RCC8 would allow us to consider
3.5 times more different agents. In the quantitative evaluation
of a single agent, depicted in Figure 4, we argue that only
Cybersecurity Risk of an Agent
153
Specification Other Designs
72
Excluded Designs
Figure 4. Cybersecurity risk for a single agent
DR(A,B) PO(A,B) PP(A,B) PPi(A,B) EQ(A,B)
DR(B,F)
DR(A,F)
DR(A,F)
DR(A,F)
T(A,F) PO(A,F) DR(A,F) PO(A,F) DR(A,F)
PO(B,F)
DR(A,F) DR(A,F) PO(A,F)
PO(A,F) T(A,F) PO(A,F) PPi(A,F) PO(A,F)
PP(A,F) PP(A,F)
PP(B,F)
DR(A,F) PO(A,F)
PO(A,F) PO(A,F) PP(A,F) EQ(A,F) PP(A,F)
PP(A,F) PP(A,F) PP(A,F)
PPi(A,F)
PPi(B,F)
DR(A,F)
DR(A,F) PO(A,F) T(A,F) PPi(A,F) PPi(A,F)
PPi(A,F)
EQ(B,F) DR(A,F) PO(A,F) PP(A,F) PPi(A,F) EQ(A,F)
Table II
RCC5 CO MPO SI TIO N TABL E OVE R 3REGIONS. THE R ES ULTS S HOW TH AT
TH ERE E XI ST 54 POSSIBLE RELATIONS AND THE COLORING ANTICIPATES
THE IDEAL RISK MATRIX (GREE N THE S EC URE S TATE WIT H LOW R IS K,
RE D THE H IG H RIS K STATE,A ND A G RAD IE NT OF M EDI UM R ISK S TATES ).
T(A,F) = {DR(A,F), PO(A,F), PP(A,F), PPI(A,F), EQ(A,F)}
1 configuration represents the nominal (expected) behavior of
the agent while the other configurations are either impossible
to implement or diverge from the intended nominal behavior.
We note that the numbers reported here do not consider the
details of the engineering process and should be considered a
limit of an abstract representation of the system.
C. Qualitative Evaluation of Agent Space in A,B,F
While a quantitative analysis reveals how many possible
configurations of an agent (i.e. a system) exist w.r.t. the ABF-
framework (i.e. 54/125 in RCC5), a qualitative analysis of the
different configurations describe the configurations allowed by
the ABF -framework, and how those configurations can be
categorized. In Table II, we provide the generic composition
table of RCC5 over 3 regions instantiated over A,B,F, which
shows the whole state space for a single agent. The color
coding of the table represents the cybersecurity risk related to
a generic agent, the risk is highest on the top left corner of
the matrix, lowest on the bottom right corner.
In Figure 5, the relation between facts, and assertions and
beliefs (as inputs and outputs of the behavior of an agent)
is illustrated. Assertions and beliefs generated by the design
of a system may not be exactly aligned with what the facts
mandate (i.e. what the specification mandates). The relation
between facts, and assertions and beliefs can be used as a
metric to determine the soundness of the design with respect
to the specification.
We first analyze the relations between each pair of regions
(i.e. A,B,F), and then we categorize the different agents as
tuple of the three regions. For the sake of simplicity, soundness
FactsSpecification
Assertions & Beliefs
abstraction
soundness
Implementation
Design
and
Figure 5. Example relation between facts, and assertions and beliefs
is opposed to non-soundness in the following, however, with
the RCC one should consider different “degrees” of non-
soundness. For example, in RCC5, if we consider EQ between
two regions as representing soundness, DR over the same re-
gions represents non-soundness; while PP, PO, PPi represents
the different degrees of non-soundness. A similar argument
can be done for completeness.
a) rcc(A,B) – Collaboration: In order to reason on
the relation between assertions and beliefs we first need to
consider that, by definition, assertions are defined as transfer
of information between two agents, e.g., between two agents.
Therefore, as depicted in Figure 3, an agent has two main
categories of assertions, input and output assertions. Given an
agent aand a collection of asserted predicates Φ, the input
assertions are those received by afrom an agent sacting as a
sender, As→aΦ; similarly, output assertions are sent from ato
a receiver r,Aa→rΦ. With a slight abuse of notation, in the
text we simply write As→awhen we abstract away from the
content of the assertion (i.e. Φ). We shall consider two pairs
of regions:
•rcc(As→a,B), where the relation between input-assertions
and beliefs describes the soundness of the execution of
the functional architecture w.r.t. input elicitation. With
more details, the ideal specification of the functional
architecture, along with the expected inputs, defines the
functional behavior of an ideal system. If all the inputs
(assertions) are correctly handled in the functional spec-
ification (beliefs) the specification is complete.
•rcc(Aa→r,B), where the relation between behavior and
outputs describes the completeness of the behavior de-
fined in the specification w.r.t. the input elicitation.
With more details, if all the outputs (assertions) of the
functional architecture can be produced, the functional
architecture is complete.
b) rcc(A,F) and rcc(B,F) – Honesty and Competence:
The relation of assertions and beliefs with facts determines
the quality with respect to the nominal (specified) system.
Given that facts define what needs to be true in the system,
the relation of assertions and facts determines the degree of
quality between the real information circulating in a system
(or within an agent) and the one specified. Since the transfer
of information through assertions generates beliefs, a dishon-
est agent may circulate false information, generating false
beliefs. We note that it is often implied that the intention
behind circulating false information discerns a dishonest and
an incompetent agent. However, we consider honesty related
to sharing truths. The relation between beliefs and facts
determines the competence (on the subjects defined by the
facts) of an agent (i.e. the more competent an agent is, the
more likely a belief of that agent is true).
1) A,B,FCyberSecurity Enumeration (CSE): The follow-
ing cybersecurity requirement for a CPS specification can be
summarized:
CSE-1Proper interaction between correctly-behaving agents is
defined as EQ(Aa,Ba)for an agent a, and can be
detailed as follows when multiple agents are considered.
CSE-1.1The equality relation EQ(As→a,Ba)describes the
intended secure behavior as: the beliefs generated
by the behavior of the functional architecture shall
be complete w.r.t. the specified inputs of the agent.
Therefore, the assertions received by an agent or a
system shall be compliant with the expected inputs of
the functional architecture. For example, the inputs
of the user of a SW must be sanitized to exclude
deviations w.r.t. the expected inputs of the functions
implemented in the SW. Another example is the type
checking between allowed inputs and expected inputs.
CSE-1.2Similarly, the equality relation EQ(Aa→r,Ba)defines
that the outputs of an agent ashall be the outputs of
the functional architecture.
CSE-2The proper adherence of the data transmitted between
agents with respect to requirements, is defined as
EQ(A,F).
CSE-3The proper adherence of the behavior (in terms of input
and output beliefs) with respect to requirements is defined
as EQ(B,F).
We note that our CSE define the properties of a secure
system, and correlated weaknesses can be found in the CWE
dataset. For example, CSE-1can be seen as correlated to the
weakness class of “Improper Interaction Between Multiple
Correctly-Behaving Entities” defined by the CWE–435, CSE-
2with the “Insufficient Control Flow Management” defined
by MITRE in the CWE–691, and CSE-3with the “Improper
Calculation” defined by MITRE in the CWE–682. All those
CWE are in the top “view” of the “research concepts” in [8],
while the other classes of weaknesses do not have a direct
counterpart in our hypothesis; we believe they can be sees as
sub-classes, but a full comparison with the CWE is out of the
scope of this article.
We are now in the position to define what a secure system
is (with respect to the ABF -framework) and, based on that
definition, what the cybersecurity risk is and how to quantify
it in a risk matrix. The following definition holds for abstract
systems defined in the ABF -framework but will be refined
for CPS afterwards in the paper.
Definition 2. Cybersecurity of a System or an Agent – A
secure system is a system where CSE-1, CSE-2, and CSE-3
holds for each agent composing the system.
The ISO 31000 consider risk as the “effect of uncertainty
on objectives” and refers both to positive and negative con-
sequences of uncertainty. Accordingly, we consider risk as
follows.
Definition 3. Risk – The risk is the uncertainty related to the
whole space of potential designs resulting from a specification
in the ABF -framework.
The definition of Risk leads to the risk matrix in Figure 4,
defined as follows.
Definition 4. Risk Matrix – The risk matrix, as summa-
rized in Table II, is a function of the three relations s=
hrcc(F,B), rcc(F,A), rcc(B,A)i, where the maximum risk
is defined by the DR relation between the three groups of
regions, and the minimum risk by the EQ relation over the
same regions. In between the two extremes, the granularity of
possible intermediate configuration is defined by the calculus
used (RCC5 in our case).
While a risk matrix is often defined as a function of the
likelihood and impact of attacks (based on quantitative ad-
hoc estimation of how likely it is that an attacker will exploit
one or more vulnerabilities and what is the magnitude of
the incidents produced by this exploitation), we suggest that
cybersecurity weaknesses are all equally likely to be exploited
if there’s a connection between the weakness and the asset
that an attacker wants to impact. When the whole system is
considered an asset, all weaknesses are equally likely to be
exploited. Therefore, a risk matrix should capture the number
of insecure configurations of a system, rather than predicating
over likelihoods of weaknesses exploitation.
IV. PREDICTION OF CYBERSECURITY WEAKNESSES
Several standards mandate a secure-by-design approach in
which cybersecurity shall be considered at the very early stages
of the design process. For example,
1) DO-326A – “Airworthiness Security Process Specifica-
tion” requires a cybersecurity risk assessment of the de-
sign and “are the only Acceptable Means of Compliance
(AMC) by FAA & EASA for aviation cyber-security
airworthiness certification, as of 2019” as pointed out by
SAE in [40].
2) NIST 800-82 [47] – “guide to Industrial Control System
(ICS) Security”.
3) J3061:2016-1 [39] – “Cybersecurity Guidebook for
Cyber-Physical Vehicle Systems” defines “set of high-
level guiding principles for Cybersecurity as it relates to
cyber-physical vehicle systems” and states that “incor-
porate Cybersecurity into cyber-physical vehicle systems
from concept phase through production, operation, ser-
vice, and decommissioning”.
Standards do not describe in detail how to perform a cyber-
security risk assessment and only vaguely define the over-
all objective, which can be summarized as to provide an
Beliefs Assertions
Facts
Functional
Architecture
Channels
Requirements
Data at rest Data in transit
Block-to-Block Port-to-Port
Ports
MAS
CPS
Figure 6. Mapping Epistemological Concepts to (Cyber-Physical) Systems
Engineering
understanding of the potential cybersecurity risks. Roughly
speaking, a cybersecurity risk assessment (e.g. CORAS [27])
methodology starts from the (i) identification of assets, (ii)
determines the threat scenarios (correlating vulnerabilities,
threats and incidents) e.g. threat diagrams in the CORAS
approach, (iii) calculates the risk as a function of impact and
likelihood of threat scenarios, and (iv) finally provides treat-
ments (mandating a partial re-design) and residual risks. All
the methodologies and tools we reviewed (e.g. Threatmodeler
[48], CORAS [27], SECRAM [14]) rely on the expertise of the
person who performs the risk assessment for the identification
of threats and for the quantitative estimation of risks. As
Herley puts it [18], “we don’t have a test for security and
we don’t have a metric for security” while standards require
a cybersecurity risk assessment which, in turn, mandates
a metric to evaluate the cybersecurity risk. In contrast, in
this section, we define how to specify a CPS in the ABF-
framework and we identify a cybersecurity metric.
So far, we have reasoned on systems in the abstract,
considering generic Multi-Agent System (MAS); mapping
Epistemological concepts to MAS. We now map MAS to CPS
and show how this mapping allows us to predict cybersecurity
weaknesses in a system.
A. From Multi-Agent to Cyber-Physical Systems
As depicted in Figure 6, we relate MAS and CPS as follows.
•We consider a System as a hierarchy of agents. So, we
map agents to systems, sub-systems, or devices, depend-
ing on the granularity of the design. For example, a
modeler can model a specific device as a system not
decomposed into sub-systems or devices (and the device
is considered as an agent).
•Agents reason over beliefs (i.e. transform beliefs into
other beliefs) and each component of a CPS (system, sub-
system, or device) is composed by a functional architec-
ture that transforms input-beliefs into output-beliefs.
•Components of a CPS have ports to exchange information
with the outer environment (which may be a sub-system),
similarly to agents. The transfer of information in a CPS
is defined by channels.
•The concept of facts is related to the requirements that
describe how the CPS shall behave and its physical
architecture.
a) Input and Output Ports: Since the ABF-framework is
a theory of agents, we could consider ports as agents that allow
the exchange of information between a channel and another
agent. However, we considered a port as a special type of
agent to avoid an infinite regress, as described in the following.
While a channel transfers information between agents, and a
functional architecture elaborate information, a port is simply
a connector between a channel and a functional architecture.
One, however, may argue that a similar connection is needed
between a channel and the port itself. While this is not
excluded by the ABF-framework, it would obviously lead
to an infinite nested structure of ports. In order to avoid
this infinite structure, we assume that a port doesn’t require
any other means to transfer information from/to a channel or
from/to a functional architecture.
Definition 5. Input or Output Port – A port forwards
information from the outside of an agent’s boundary to the
inside (input-port) or vice versa (output-port). There exist
two types of ports with the following behavior: an input-port
transforms assertions from a sender s(As→a) to beliefs of
an agent a(Ba), while an output-port transforms beliefs into
assertions.
The quality of a port is determined by the rcc relation
between the assertions received or sent and the belief, i.e.
rcc(As→a,Ba)for the input-port or rcc(Ar→∗ ,Ba)for the
output-port (where ∗is a wildcard for an agent). A port is, in
fact, syntactic sugar to express the relation between assertions
and beliefs. We note that the definition of an input/output
port can be considered “secure”, meaning that we implicitly
formulated the requirement that a port always forwards the
information without modifying it in any way. This is assumed
because we define a port as if the RCC equality relation
holds between the input/output assertions and the input/output
beliefs. In contrast, assuming any RCC relation, between
inputs and outputs of a port, which is not an equality can
be considered as generating a weaknesses, as we describe in
more details in the next paragraph.
b) Port Weaknesses: We now apply the ABF-framework
to list all possible cybersecurity weaknesses of a port.
Theorem 1. Port Weaknesses. From our definition of ports,
it follows that there exist only the following six types of
weaknesses, generating six types of insecure port in RCC5:
W1) Replace port, where assertions reach the port but are
replaced with different and un-related information before
passing the boundary.
W2) Drop port, where assertions reach the port but do not
pass the boundary of the agent (i.e. do not become belief
of the agent).
W3) Insertion port, where some new information is transferred
along with the information incoming from a channel, and
then sent to the intended recipient (agent).
W4) Injection port, where part of the incoming information is
substituted with new information and transferred to the
intended recipient.
W5) Selective port, where some information passes the port
and part is either:
W5.1) Dropped, or
W5.2) Replaced.
Proof. An input port is, in the ABF-framework, defined
secure as long as the relation between the two regions of input
assertions Aand output beliefs Bare equal, i.e. EQ(A,B).
Therefore, any other relation should result in a weakness
(related to an insecurity flaw) of that input port. Using RCC5,
there exist exactly other 4different types of relations, one
of which is the discrete-from (DR) relation, i.e. DR(A,B).
When two regions are related by the DR relations, they have
no subregion in common. Let us define a function weight |X|
such that, for any region X, it represents the smallest possible
cardinality of a (mereo)topological base for X; where a base
is a collection of regions in a (mereo)topology such that every
region can be written as union of elements of that base. We
distinguish between regions that are related to information and
regions that don’t by writing the latter as ∅(e.g. a region
corresponding to an assertion is written A6=∅, while a region
corresponding to an empty assertion as A=∅).
1) If EQ(A,B)then either A=B=∅(no communication)
or A=B 6=∅(forward communication).
2) If DR(A,B)then A=∅⊕B =∅(we call insert the
former and full drop the latter case), or A 6=∅ ∧ B 6=
∅ ∧ A 6=Bwhich we call replace (i.e. drop and insert).
3) If P P (A,B)then Bcontains and extend Awhich we
call insertion.
4) If PPi(A,B)then Acontains and extend Bwhich we
call drop (or selective drop to stress the difference with
the full drop).
5) If P O(A,B)then a part of the Ais contained in the B
which is a combination of selective drop and generation
which we call injection.
c) Communication Channels: In this work, we only
consider mono-directional channels and communication but
the extension to bi-directional channel can be considered as
the union of two unidirectional channels. A mono-directional
channel is defined by the assertions sent or received (over the
channel).
We start by considering the difference between a (commu-
nication) mono-directional channel (channel from now on) and
an agent, as we did for the ports, since the ABF -framework is
a logical theory of agents. In fact, if a channel were considered
an agent (channel-agent) then the question would be how an
agent would transfer its assertions to the channel-agent. If the
channel between the agent and the channel-agent is again an
agent, we would generate an infinite regress. Therefore, we do
allow channel-agents but we assume a finite depth (of detail)
for a channel, where there exists a bottom-channel which is
not an agent. For now, we do not constrain a channel-agent in
any way so there is no difference between a channel agent and
agent. Therefore, we consider channels to be bottom-channels,
defined as agents with the pre-defined behavior (i.e. defined in
an axiomatic way) of forwarding any input-assertion as output-
assertion, without modifying it11.
Definition 6. Mono-directional Channel (bottom-channel)
–A mono-directional channel between two agents (s→r) is
defined as an agent whose behavior is (dogmatically) defined
as: to forward any assertion received from sover an input-
port, to the output-port where ris listening to.
The quality of a mono-directional channel is defined as the
rcc relation between the assertions made by the sender and
the ones received by the receiver, i.e. rcc(As,Ar).
d) Channel Weaknesses: Given that a mono-directional
bottom-channel is assumed to be perfectly forwarding any
assertion (as we assumed for ports) from its input-port to
its output-port, there is no insecure behavior but only the
combination of the weaknesses of the input and output port;
therefore there exist (72)−1 = 48 theoretical configurations
(72because there are 6insecure types of port, plus 1secure
type, on both input and output side; and we exclude the
configuration with 2secure types as input and output, −1);
where only 44 are possible. For the sake of readability, we
report 6 examples in the following but the proof by exhaustion
over all the possible cases is straightforward.
W6) Secure output port and input drop port.
W7) Secure output port and input insertion port.
W8) Output drop port and input drop port.
W9) Output drop port and input insertion port.
W10) Output drop port and input secure port.
W11) Output injection port and input secure port.
e) Cybersecurity Weaknesses – The RIDI-Hypothesis: It
is important to note that all the results of the application of
the ABF -framework to channels (the analysis of the RCC
relations between output and input assertions of an agent)
lead to the same results of the analysis of a pair of an
input and output port. So far we have considered information
generated by a port PIand then sent through a channel C
to another (recipient) port PO. In this scenario, where ports
and channels are atomic (otherwise raising infinite regress),
we can only consider the relations between ports and channel;
considering both input-port to channel and channel to output-
port. In fact, the weaknesses of a channel are defined in
terms of the weaknesses of ports. The same result can be
obtained by analyzing the relation between the outputs of a
functional block and the inputs of another functional block,
where functional blocks are constituents of the functional
architecture as described afterwards. In order to define a
functional block without encountering an infinitely recursive
definition, we must reach the same conclusions as for the
11Nothing prevents us from introducing additional constraints to the channel
as storing assertions that are transferred over the channel, or filter out some
input-assertions.
channel. Therefore, describing the information as flowing over
a channel or in a functional block is purely syntactic sugar.
We can summarize these results by saying that the relations
between assertions and beliefs, output assertions of an agent
and input assertions of another agent, or output beliefs of a
functional block and input beliefs of another block can only be
affected by the following weaknesses: replace, drop, injection,
insertion, selective drop, and selective drop + insertion. We
call this the RIDI-Hypothesis, being the four main categories
of weaknesses: Replace, Insertion, Drop, Injection. We can,
then, deduce the following cybersecurity properties to mitigate
cybersecurity weaknesses of a port or a channel (between
ports, functional blocks, or both).
•Order-preserving – it shall be known if information is
replaced.
•Availability – it shall be known if information is dropped
or selectively dropped.
•Integrity – it shall be known if information is injected.
•Authentication – it shall be known if information is
inserted.
f) Functional Architecture: A functional architecture
takes information as input-beliefs and transforms the informa-
tion into output-beliefs. Those transformations occur within
the functional architecture, where functional blocks transform
beliefs into other beliefs. Similarly to channels, we could con-
sider a functional block as a functional architecture occurring
in an infinite regress. Therefore, we consider functional blocks
as executing an abstract undefined behavior, of which we only
observe the inputs and the resulting outputs (beliefs).
Definition 7. Functional Block and Architecture – A func-
tional block of an agent takes beliefs as inputs (input-beliefs)
and returns output-beliefs. A functional architecture is an
interconnected system of functional blocks.
The quality of a functional block cannot be determined by
the difference between its inputs and outputs (as we did for
ports and channels), because the behavior of a functional block
cannot be determined in general; since any functional block
will have its own purpose based on functional requirements.
Therefore, while the semantics of a port is determined by
the relation between assertions and beliefs, the semantics
of a functional block is determined by the relation between
facts/requirements and I/O beliefs. In other words, a functional
block is a generic agent with no pre-defined general behavior
(while ports and channels have a pre-defined behavior). In
the following, for the sake of simplicity, we use the generic
region Bto refer to the behavior (i.e. the beliefs generated by
the behavior).
W50) P O(B,F)the component has a Byzantine behavior
where occasionally outputs the expected output given the
correct inputs. Not all the inputs are handled properly,
nor all the expected outputs are always generated when
correct inputs are given.
W51) P P (B,F)part of the expected outputs are not generated
in response to the correct inputs
sum
b1
b2
b3
Figure 7. Example of a Functional Block
W52) PPi(B,F)the components correctly perform the ex-
pected behavior when the correct inputs are provided but
is subject to input injections
W53) DR(B,F)the component never performs the expected
behavior (e.g. physical damage)
g) Requirements as Facts: During the specification
phase, for any agent, channel, port, functional block and
architecture, there may exist a requirement (fact) predicating
over them. In other words, any requirement is defined as a
fact since they must be true in any design or implementation.
As we stated in Section IV and depicted in Figure 5, facts are
definitory rules that define how the system shall behave (by
specification), while reality may be shown to be insecure (i.e.
diverging from the expected behavior).
As an example, considering a functional block that performs
the summation of two inputs, as in Figure 7, defined by
the requirement r:= b3=b1+b2for any b1and b2.
The possible relations between the beliefs generated by the
behavior of the functional block and the requirements (i.e.
rcc(B,F)is determined by the relations between the I/O
beliefs sum(b1, b2) = b3and the requirement sum(b1, b2) =
b1+b2, as follows.
•EQ(B,F) = EQ(B3,B1+2), where B3represents the
region of the outputs of the functional block sum while
the region B1+2 represents the expected outputs of an
ideal implementation of the requirement r. Therefore, the
functional block correctly implements the requirements.
•DR(B,F) = DR(B3,B1+2 ), the function block never
implements the requirements.
•P P (B,F) = P P (B3,B1+2), there exist some inputs for
which the output is incorrect.
•PPi(B,F) = PPi(B3,B1+2), there exist some outputs
that are not the result of the summation of the inputs
but given the correct inputs the function always outputs
correctly.
•P O(B,F) = P O(B3,B1+2 ), the component has a
Byzantine behavior where occasionally outputs the ex-
pected output given the correct inputs. Not all the inputs
are handled properly, nor all the expected outputs are
always generated when correct inputs are given.
h) Assertions and Facts: The whole reasoning on the
relation between beliefs and facts can be duplicated for the
relation between assertions and facts; we cannot appreciate
the difference at this level of abstraction. If the functional
architecture would be extended to capture the semantics (i.e.
the logic) of the communication and cybersecurity protocols,
with the relation between assertions and facts we would
compare protocol logics with the requirements. We won’t
consider the verification of the functional architecture and
protocol logic in this paper since we focus on the architecture
specification step of the engineering process without going into
the design of the behavior of agents. We can give an example
but research is needed to apply our hypothesis to the behavior
of agents.
If we consider a functional block that generates nonces (i.e.
number used only once), the semantics of this block must
define a procedure such that a freshness requirement holds. By
the RIDI-Hypothesis we have that the following weaknesses
may occur:
•Replace: the output-nonces of the block are replaced with
non-fresh numbers.
•Insert: the output-nonces are concatenated with other
numbers, resulting in non-fresh nonces. For example, the
nonces 110 and 111 are modified by inserting a 1 and a
0 at the beginning and end respectively, resulting in the
two identical (and the non-fresh) nonces 1110 and 1110.
•Delete: part of output-nonce is dropped. For example, the
last bit of 1101 and 1100 is dropped, resulting in the two
equal and non-fresh nonces: 110 and 110.
•Inject: substitution at bit level results in non-fresh nonces.
For example, 110 and 111 becomes equal by flipping
either the last 0 of the former or the last 1 of the latter.
We summarize our results by categorizing the weak-
nesses predicted by our hypothesis into: data-flow-related
and functionality-related weaknesses; as in Table III.
Functionality-related weaknesses can be seen as a general for-
mulation of our hypothesis while data-flow-related weaknesses
as an application of our hypothesis to components with defined
behavior/requirements.
B. Security and Insecurity of a System
Hypothesis 1. System Security Design – A system security
design (in the ABF -framework) is given by a precise system
specification over the physical and functional architectures
that uniquely defines the design built on top of those require-
ments.
Hypothesis 2. System Insecurity Design – If, given a system
specification as a collection of requirements, there exist a
non-unique design with respect to those requirements, the
number of equivalent designs (that fulfills the requirements)
quantitatively defines the magnitude of insecurity of a system
design.
Based on these hypothesis, we can formulate the concepts of
security and insecurity (in the ABF -framework) as mathemat-
ical equations. Let us consider a CPS S, represented as a graph
G=hV, E iwhere Vrepresents the set of functional blocks
and ports of S, and E⊆V×Vis the set of pairs representing
the channels and connections (data flows) between functional
blocks. We define R⊆V×F, where Fis the set of all
the requirements of S, and extend Gas G0=hV0, E0iwith
E0=E∪Rand V0=V∪F. Let π:E0→RCC (where
RCC is the set of relations in the RCC) be the total function
associating an RCC relation to each edge in G0, and Πbe
the set of all different permutations of RCC relations over E0
User
Architecture
Requirements
[UML Deployment +
Object diagrams]
V
SecRA
Generate
ABF
Graph
ABF
Graph
Weaknesses
List
Weaknesses
(Excel)
Mitigations &
Security Requirements
Update
ABF
Graph
Risk
Calculation
Risk
(Excel)
Figure 8. Cybersecurity Risk Assessment Tool
(i.e. Π = {hπ(e0) = EQ, . . . , π (en) = EQi,...,hπ(e0) =
DR, . . . , π(en) = DRi} where ei∈E0for 0≤i≤n
and |E0|=n). If σ: Π → {0,1}is an evaluation function
such that σ(p) = 1 (where p∈Π) iff the input configuration
is satisfiable with respect to the logical theory defining the
algebraic structure (mereotopology) and constraints of the
calculus RCC (otherwise σreturns 0), we can define
I=X
p∈(Π\πeq)
σ(p)
where πeq ∈Πis the output of the function πthat associates
only EQ relations to any e∈E0, and I∈Nrepresents all the
insecurity configurations of the CPS Swhere, at least, one of
the RCC relations isn’t EQ. In other words, we consider πeq
as the only secure configuration.
C. Cybersecurity Risk Assessment
In order to test our hypothesis we implemented a tool-chain
(open-source under the AGPLv3 license and available at [2])
for the identification of weaknesses and the precise calculation
of potential insecure configurations. The engineering of the
ABF -framework for CPS is summarized in the UML Class
diagram in Figure 12 (in appendix).
As depicted in Figure 8, the cybersecurity risk assessment
process starts with the definition of the use cases and ar-
chitectural requirements. In our process, the specification is
manually translated into a UML design where:
•adeployment diagram describes the physical architecture.
Each agent is defined as an UML node with (physical)
ports, and agent’ ports are connected via UML informa-
tion flow connectors, representing the physical channel.
•afunctional architecture is linked to each agent in the
deployment diagram and is defined by an object diagram.
The object diagram is composed by instances of func-
tional blocks, connected via information flow connectors.
•the connection between the two diagrams is implemented
by “sockets”, functional blocks connected to a physical
port.
RCC5 Quantity: Data Flow Quality: Requirements Adherence
EQ Expected/Nominal Expected/Nominal
DR Drops all the inputs and inserts new malicious data The component never performs/carries the expected behavior/information
PP Selectively drops inputs part of the expected outputs are not generated in response to the correct inputs
PPi Forwards all the inputs but crafts and inserts new
malicious data
The components correctly performs/carries the expected behavior/information
when the correct inputs are provided but is subject to input injections
PO Selectively drops inputs and inserts new data
Byzantine behavior - occasionally outputs the expected output given the
correct inputs. Not all the inputs are handled properly, nor all the expected
outputs are always generated when correct inputs are given
Table III
WEAKNESSES CATEG ORI ZATI ON
Figure 9. Water level reader deployment diagram
The tool generates a graph-like internal structure which rep-
resents the specification (called ABF-graph). The ABF -graph
defines the system as a number of regions of assertions, beliefs,
and facts. Those regions are connected by a generic relation
which is evaluated as follows (according to the formula in
Section IV-B). The graph is translated into a logical formula
that represents the specification in the ABF -framework and,
along with the axiomatization of the RCC5 calculus, is given
as input to the Z3 SMT solver. The solver identifies all possible
configurations of the system and, in turn, identifies all potential
weaknesses. The internal structures of the tool can be viewed
as PDF and the results are reported into an spreadsheet file.
The spreadsheet file also reports the total number of config-
urations as indicating the cybersecurity risk associated to the
specification. A user can change the status of each weakness
in the spreadsheet file, from the initial (default) status (open)
to “mitigated”. As a consequence, the risk is re-calculated
on-the-fly, i.e. without the need of running the tool again,
based on annotations and formulas in the spreadsheet file. In
our approach, cybersecurity requirements are not imposed by
the specification but are automatically extracted by our tool
as mitigations to potential weaknesses. Those weaknesses are
related to the different insecure configurations of the specified
system.
a) Case Studies: We report the results of the evaluation
of a water level reader (sensor ad-hoc example). As in Fig-
ure 9, we defined 2 agents: sensorInTank and sensorBoard,
which represent the physical reader that needs to be placed in
a tank, and the board that interprets the readings and outputs
them as signals. The two components are connected by a wire.
In Figure 10, we report the functional architecture that receives
Figure 10. Sensor Board Object Diagram
the incoming communications from the sensor in the tank,
and communicates them encrypted. The results, summarized
in Figure 11, reports 16777216 possible scenarios in which at
least one component diverge from the specification.
V. CONCLUSION AND FUTURE WO RK S
We proposed an hypothesis for a foundational theory on se-
curity, arguing that cybersecurity-related issues are not linked
to the maliciousness of an agent but to the vagueness in the
design processes. We also provided a prototype tool for the
quantitative estimation of the cybersecurity risk, based on a
UML model of the system under assessment. The cybersecu-
rity verification and test-case generation will be the focus of
our next steps.
APPENDIX
The Class Diagram for the Engineering of the ABF -
framework is reported in Figure 12. A specification of a
CPS is viewed as an aggregation of architectures which can
describe the functional or physical requirements. The physical
components of the architecture are input/output ports and
channels (aggregations of pairs of ports) while functional
blocks are the only constituents of the functional architecture.
All of the classes are abstract except input/output ports and
functional blocks. Therefore, agents (which represents sub-
systems or components) are composed by ports and functional
blocks, as an aggregation of architectures.
Figure 11. Partial View of the results in the spreadsheet file
REFERENCES
[1] International Electrotechnical Commission (IEC). IEC
61511-1:2016+AMD1:2017 CSV Consolidated version.
Aug. 16, 2017. URL: https://webstore.iec.ch/publication/
61289 (visited on 01/21/2020).
[2] 42. Repository.U RL : https://github. com/... (visited on
09/03/2020).
[3] Alessandro Armando, Roberto Carbone, and Luca Com-
pagna. “SATMC: a SAT-based model checker for secu-
rity protocols, business processes, and security APIs”.
In: International Journal on Software Tools for Tech-
nology Transfer 18.2 (2016), pp. 187–204.
[4] David Basin, Sebastian M ¨
odersheim, and Luca Vigano.
“OFMC: A symbolic model checker for security proto-
cols”. In: International Journal of Information Security
4.3 (2005), pp. 181–208.
[5] Rebecca M. Blank and Patrick D. Gallagher. “NIST
Special Publication 800-53 Revision 4 - Security and
Privacy Controls for Federal Information Systems and
Organizations”. In: National Institute of Standards and
Technology Special Publication (Apr. 2013). URL: http:
//dx.doi.org/10.6028/NIST.SP.800-53r4.
[6] Common Attack Pattern Enumeration and Classifica-
tion.UR L: https : / / capec . mitre . org/ (visited on
02/19/2020).
[7] The MITRE Corporation. CVE – Common Vulnerabil-
ities and Exposures. Jan. 16, 2020. URL: https://cve .
mitre.org/ (visited on 01/22/2020).
[8] CWE VIEW: Research Concepts. 2020. UR L: https: / /
cwe. mitre . org / data / definitions / 1000 . html (visited on
02/03/2020).
[9] Dialectical Materialism. Progress Publishers, 1983.
UR L: https : / / www. marxists . org / reference / archive /
spirkin/works/dialectical-materialism/index.html.
[10] Danny Dolev and Andrew Yao. “On the security of
public key protocols”. In: IEEE Transactions on infor-
mation theory 29.2 (1983), pp. 198–208.
[11] Sextus Empiricus. Outline of Pyrrhonism. Prometheus
Book, 1990. IS BN : 978-0-87975-597-3.
[12] Institution of Engineering and Technology (IET). Glos-
sary of safety terminology. Jan. 2017. UR L: https://www.
theiet.org/media/1435/hsb00.pdf.
[13] FAQ – What is the difference between a software
vulnerability and software weakness? Sept. 17, 2019.
UR L: https://cwe.mitre.org/about/faq.html#A.2 (visited
on 02/03/2020).
[14] Martina de Gramatica et al. “The role of catalogues
of threats and security controls in security risk assess-
ment: an empirical study with ATM professionals”. In:
International Working Conference on Requirements En-
gineering: Foundation for Software Quality. Springer.
2015, pp. 98–114.
[15] Rolf Gr ¨
utter, Thomas Scharrenbach, and Bettina Bauer-
Messmer. “Improving an RCC-Derived Geospatial Ap-
proximation by OWL Axioms”. In: ISWC. 2008.
[16] Rolf Gr ¨
utter, Thomas Scharrenbach, and Bettina Bauer-
Messmer. “Improving an RCC-Derived Geospatial Ap-
proximation by OWL Axioms”. In: The Semantic Web
(ISWC). Ed. by Amit Sheth et al. Springer Berlin
Heidelberg, 2008, pp. 293–306.
[17] Cormac Herley. “Justifying Security Measures—a Po-
sition Paper”. In: European Symposium on Research in
Computer Security. Springer. 2017, pp. 11–17.
[18] Cormac Herley. The Unfalsifiability of Security Claims -
Invited Talk USENIX Security. Aug. 2016. UR L: https://
www.usenix.org/conference/usenixsecurity16/technical-
sessions/presentation/herley (visited on 01/15/2020).
[19] Cormac Herley. “Unfalsifiability of security claims”.
In: Proceedings of the National Academy of Sciences
(PNAS) 113.23 (2016), pp. 6415–6420.
[20] Jaakko Hintikka. “Knowledge and Belief: An Introduc-
tion to the Logic of the Two Notions”. In: Studia Logica
16 (1962), pp. 119–122.
[21] Jakko Hintikka. “On proper (popper?) and improper
uses of information in epistemology”. In: Theoria.
Wiley Online Library, 1993, pp. 158–165. URL: https:
//doi.org/10.1111/j.1755-2567.1993.tb00867.x.
[22] Merriam-Webster Inc. failure. 2020. URL: https://www.
merriam - webster . com / dictionary / failure (visited on
01/18/2020).
[23] Wikipedia Foundation Inc. Exploit (computer security).
Nov. 23, 2019. U RL: https : / / en . wikipedia . org / wiki /
Exploit (computer security) (visited on 01/21/2020).
Figure 12. ABF -framework for CPS Design – Class Diagram
[24] Wikipedia Foundation Inc. Mankind. Dec. 19, 2019.
URL: https: / / en . wikipedia . org / wiki / Mankind (visited
on 01/15/2020).
[25] Wikipedia Foundation Inc. Nature. Jan. 14, 2020. UR L:
https : / / en . wikipedia . org / wiki / Nature (visited on
01/15/2020).
[26] Tsau Young Lin, Qing Liu, and Y. Y. Yao. “Logics
Systems for Approximate Reasoning: Approximation
via Rough Sets and Topological Spaces”. In: ISMIS.
1994.
[27] Mass Soldal Lund, Bjørnar Solhaug, and Ketil Stølen.
Model-driven risk analysis: the CORAS approach.
Springer Science & Business Media, 2010.
[28] Peter Mell, Karen Scarfone, and Sasha Romanosky. “A
complete guide to the common vulnerability scoring
system version 2.0”. In: Published by FIRST-forum of
incident response and security teams. Vol. 1. 2007,
p. 23.
[29] Kevin Mulligan and Fabrice Correia. Facts. Ed. by
Edward N. Zalta. 2020.
[30] Committee on National Security Systems (CNSS).
“Glossary No 4009”. In: National Information Assur-
ance (IA) Glossary (Apr. 6, 2015). URL : https://rmf .
org/wp-content/uploads/2017/10/CNSSI-4009.pdf.
[31] Peter Pagin. Assertion. Ed. by Edward N. Zalta. 2016.
[32] R. Karl Popper. Conjectures and refutations: The
growth of scientific knowledge. New York London,
1962.
[33] R. Karl Popper. The Logic of Scientific Discovery. New
York London, 1959.
[34] Saikeerthi Rachavelpula. “The Category of Mereotopol-
ogy and Its Ontological Consequences”. In: University
of Chicago Mathematics Research Program. Ed. by
Michael Neaton and Peter Peter. 2017.
[35] MIT Research and Engineering (MITRE). ATT&CK.
URL: https://attack.mitre.org/ (visited on 06/09/2020).
[36] MIT Research and Engineering (MITRE). Common
Vulnerabilities and Exposures (CVE).URL : https://cve.
mitre.org/ (visited on 01/27/2020).
[37] Patricia A Robinson. Writing and designing manuals
and warnings. CRC Press, 2019.
[38] Marco Rocchetto, Luca Vigan`
o, and Marco Volpe. “An
interpolation-based method for the verification of secu-
rity protocols”. In: Journal of Computer Security 25.6
(2017), pp. 463–510.
[39] SAE. Cybersecurity Guidebook for Cyber-Physical Ve-
hicle Systems. 2016. UR L: https : / / www . sae . org /
standards/content/j3061 201601.
[40] SAE. DO -326A and ED-202A : An Introduction to the
New and Mandatory Aviation Cyber-Security Essentials
C1949. 2019. URL: https://www.sae.org/learn/content/
c1949/.
[41] Spyridon Samonas and David Coss. “the CIA Strikes
Back: Redefining Confidentiality, Integrity and Avail-
ability in Security”. In: Journal of Information System
Security 10.3 (2014).
[42] Katia Santac `
a et al. “A Topological Categorization of
Agents for the Definition of Attack States in Multi-agent
Systems”. In: Proceedings of the European Conference
on Multi-Agent Systems and Agreement Technologies
(EUMAS). 2016, pp. 261–276.
[43] Barry Smith. “Mereotopology: A theory of parts and
boundaries”. In: Data & Knowledge Engineering 20.3
(1996). Modeling Parts and Wholes, pp. 287–303.
[44] Richard Stallman. The Hacker Community and Ethics:
An Interview with Richard M. Stallman. 2002. URL:
https://www.gnu.org/philosophy/rms-hack.html (visited
on 01/22/2020).
[45] International Organization for Standardization (ISO).
ISO/IEC/IEEE 15288:2015, Systems and Software En-
gineering – System Life Cycle Processes. May 2015.
UR L: https://www.iso.org/standard/63711.html (visited
on 02/20/2020).
[46] National Institute of Standards and Technologies
(NIST). National Vulnerability Database.URL: https:
//nvd.nist.gov/ (visited on 01/22/2020).
[47] Keith Stouffer. Guide to industrial control systems (ICS)
security. 82, pp. 16–16.
[48] Threatmodeler. ThreatModeler.URL: https : / /
threatmodeler.com/ (visited on 06/09/2020).
[49] John Turri. “Is knowledge justified true belief?” In:
Synthese 184.3 (2012), pp. 247–259.
[50] Mathieu Turuani. “The CL-Atse protocol analyser”. In:
International Conference on Rewriting Techniques and
Applications. Springer. 2006, pp. 277–286.
[51] Achille C. Varzi. “On the Boundary Between Mereol-
ogy and Topology”. In: Proceedings of the International
Wittgenstein Symposium. 1994, pp. 261–276.
