Abstract
Changes, such as the introduction of new technology, may have considerable impact on the risk to which a system or organization is exposed. For example, in the oil and gas domain, introduction of technology that allows offshore installations to be operated from onshore means that fewer people are exposed to risk on the installation, but it also introduces new risks and vulnerabilities. We need suitable methods and techniques to understand how a change will affect the risk picture. This paper presents an approach that offers specialized support for analysis of risk with respect to change. The approach allows links between elements of the target of analyses and the related parts of the risk model to be explicitly captured, which facilitates tool support for identifying the parts of a risk model that need to be reconsidered when a change is made to the target. Moreover, the approach offers language constructs for capturing the risk picture before and after a change. The approach is demonstrated on a case concerning new software technology to support decision making on petroleum installations.
Similar content being viewed by others
Notes
We often use indentation to represent conjunction.
Hence, \(H\vdash X\wedge Y\) means \(H\vdash X\) and \(H\vdash Y\).
References
Aven, T., Sklet, S., Vinnem, J.E.: Barrier and operational risk analysis of hydrocarbon releases (BORA-Release). Part I. Method description. J. Haz. Mater. A137, 681–691 (2006)
Ben-Gal, I.: Bayesian networks. In: Ruggeri, F., Kenett, R.S., Faltin, F.W. (eds.) Encyclopedia of Statistics in Quality and Reliability. Wiley, Chichester (2007)
Bergomi, F., Paul, S., Solhaug, B., Vignon-Davillier, R.: Beyond traceability: Compared approaches to consistent security risk assessments. In: Proceedings of Eighth International Conference on Availability, Reliability and Security (ARES’13), pp. 814–820. IEEE Computer (2013)
Breu, M., Breu, R., Löw, S.: MoVEing forward: towards an architecture and processes for a Living Models infrastructure. Int. J. Adv. Life Sci. 3(1–2), 12–22 (2011)
EUROCONTROL. Methodology report for the 2005/2012 integrated risk picutre for Air Traffic Management in Europe. EEC Technical/Scientific Report No. 2006–041 (2006)
Gigerenzer, G.: Calculated Risks—How to Know When Numbers Deceive You. Simon & Schuster, New York (2002)
Hogganvik, I., Stølen, K.: Risk analysis terminology for IT-systems: does it match intuition? In: 4th International Symposium on Empirical Software Engineering (ISESE’05), pp. 13–23. IEEE Computer Society (2005)
Hogganvik, I., Stølen, K.: A graphical approach to risk identification, motivated by empirical investigations. In: 9th International Conference on Model Driven Engineering Languages and Systems (MoDELS’06), volume 4199 of LNCS, pp. 574–588. Springer (2006)
Howard, R.A.: Dynamic Probabilistic Systems, Volume I: Markov Models. Wiley, New York (1971)
Howard, R.A., Matheson, J.E.: Influence diagrams. Decis. Anal. 2(3), 127–143 (2005)
Innerhofer-Oberperfler, F., Breu, R.: Using an enterprise architecture for IT risk management. In: Information Security South Africa Conference (ISSA’06) (2006)
International Electrotechnical Commission. IEC 61025 fault tree analysis (FTA) (1990)
International Electrotechnical Commission. IEC 61165 application of Markov techniques (1995)
International Organization for Standardization. ISO 31000 risk management—principles and guidelines (2009)
Lund, M.S., Solhaug, B., Stølen, K.: Model-Driven Risk Analysis—The CORAS Approach. Springer, Berlin, Heidelberg (2011)
Lund, M.S., Solhaug, B., Stølen, K.: Risk analysis of changing and evolving systems using CORAS. In: Foundations of Security Analysis and Design VI (FOSAD VI), volume 6858 of LNCS, pp. 231–274. Springer (2011)
MoVE—Model Versioning and Evolution. http://move.q-e.at/. Accessed 27 Aug 2014 (2014)
Object Management Group. OMG Unified Modeling Language (OMG UML), Superstructure. Version 2.2. OMG Document: formal/2009-02-02 (2009)
Seehusen, F., Solhaug, B.: Tool-supported risk modeling and analysis of evolving critical infrastructures. In: Multidisciplinary Research and Practice for Information Systems, volume 7465 of LNCS, pp. 562–577. Springer (2012)
Solhaug, B., Seehusen, F.: Model-driven risk analysis of evolving critical infrastructures. J. Ambient Intell. Hum. Comput. 5(2), 187–204 (2014)
Solhaug, B., Stølen, K.: The CORAS language—Why it is designed the way it is. In: Safety, Reliability, Risk and Life-Cycle Performance of Structures and Infrastructures, Proceedings of 11th International Conference on Structural Safety and Reliability (ICOSSAR’13), pp. 3155–3162. CRC Press (2013)
Tran, L.M.S., Solhaug, B., Stølen, K.: An approach to select cost-effective risk countermeasures exemplified in coras. Technical report A24343, SINTEF ICT (2013)
Voirin, J.-L.: Method and tools for constrained system architecting. In: 18th Annual International Symposium of the International Council on Systems Engineering (INCOSE’08), pp. 775–789. Curran Associates, Inc. (2008)
Acknowledgments
This work has been conducted as a part of the NESSoS network of excellence (256980) funded by the European Commission within the 7th Framework Programme, and the CONCERTO project (333053) funded by the ARTEMIS Joint Undertaking and the Research Council of Norway (232059), as well as the Dynamic Risk Assistant project (217213) funded by the Research Council of Norway.
Author information
Authors and Affiliations
Corresponding author
Appendices
Appendix A: Formal foundation
In the following we introduce the formal machinery.
1.1 A.1 Basics
\({\mathbb {N}}\) and \({\mathbb {R}}\) denote the sets of natural numbers and real numbers, respectively. We use \({\mathbb {N}}_0\) to denote the set of natural numbers including 0, while \({\mathbb {R}}^+\) denotes the set of nonnegative real numbers. This means that
For any set of elements, we use \({{\mathbb P}(A)}\) to denote the powerset of \(A\).
A tuple is an element of a Cartesian product. We use \(\pi _j\) to extract the \(j\)th element of a tuple. Hence, if
then \(\pi _1.(a,a')=a\) and \(\pi _2.(a,a')=a'\).
1.2 A.2 Sequences
By \({A\,^{\infty }}, {A\,^{\omega }}\) and \({A\,^{*}}\) we denote the set of all infinite sequences, the set of all finite and infinite sequences and the set of all finite sequences over some set of elements \(A\), respectively. Hence, we have that
We define the functions
to yield the length and the \(n\)th element of a sequence. Hence, \(\#s\) yields the number of elements in \(s\), and \(s[n]\) yields the \(n\)th element of \(s\) if \(n\le \# s\).
We also need functions for concatenation and filtering:
Concatenating two sequences implies gluing them together. Hence, \(s_{1}{\mathop {\mathop {\ }\limits ^{\frown }}}s_{2}\) denotes a sequence of length \(\#s_{1}+\#s_{2}\) that equals \(s_{1}\) if \(s_{1}\) is infinite and is prefixed by \(s_{1}\) and suffixed by \(s_{2}\), otherwise.
The filtering operator is used to filter away elements. denotes the subsequence obtained from \(s\) by removing all elements in \(s\) that are not in the set \(B\).
1.3 A.3 Timed events
\({{\mathbb {E}}}\) denotes the set of all events, while the set of all timestamps is defined by
A timed event is an element of
1.4 A.4 Histories
A history is an infinite sequence of timed events that is ordered by time and progresses beyond any finite point in time. Hence, a history is an element of:Footnote 1
The first conjunct requires the timestamp of a timed event to be at least as great as that of its predecessor. The second conjunct makes sure that time will always progress beyond any finite point in time. That is, for any timestamp \(t\) and history \(h\) there is a timed event in \(h\) whose timestamp is greater than \(t\).
We also need a function for truncating histories
The truncation operator captures the prefix of a history up to and including a certain point in time. Hence, \({h\!\!\mid \!\!_{t}}\) describes the maximal prefix of \(h\) whose timed events all have timestamps less than or equal to \(t\).
1.5 A.5 Frequencies
As explained above, we use the nonnegative real numbers to represent time. The time unit is equal to 1. For simplicity, we assume that all frequencies are per time unit. The set of frequencies \(F\) is therefore defined as follows:
Hence, \(f\in {{\mathbb {F}}}\) denotes the frequency of \(f\) occurrences per time unit.
Appendix B: Risk graphs
1.1 B.1 Syntax of risk graph formulas
1.1.1 B.1.1 Risk graph definition
A risk graph \(G\) is a pair of two sets \((V,R)\) where
We refer to the elements of \(V\) as vertices and to the elements of \(R\) as relations. We use \(v(f)\) to denote a vertex, while \(v\xrightarrow {r} v'\) denotes a relation.
1.1.2 B.1.2 Vertex expressions
The set of vertex expressions is the smallest set \(X_V\) such that
We need a function
that for any vertex expression yields its set of events. Formally, \(s\) is defined recursively as follows:
1.1.3 B.1.3 Risk graph formulas
A risk graph formula is of one of the following forms:
-
\(H\vdash v(f)\)
-
\(H\vdash v\xrightarrow {r} v'\)
-
\(H\vdash v\sqcup v'(f)\)
-
,
where
-
\(H\in {{\mathbb P}({{\mathbb {H}}})}\!\setminus \!\)Ø
-
\(v,v'\in X_V\)
-
\(f\in {{\mathbb {F}}}\)
-
\(r\in {\mathbb {R}}^+\)
1.2 B.2 Semantics of risk graph formulas
We use the brackets \({[\![\ \ ]\!]}\) to extract the semantics of a risk graph formula. If \(v\in {{\mathbb P}({{\mathbb {E}}})}\) we define
The semantics of any other risk graph formula is defined recursively as follows:
For a risk graph \(G = (V,R)\) the semantics of \(H \vdash G\) is defined as follows:
1.3 B.3 Calculus of risk graph formulas—proofs of soundness
We now prove soundness of three example rules. The three rules below correspond to rules 13.10, 13.11 and 13.12 in the CORAS book [15], respectively. There are some minor differences. In the CORAS book the real number decorating a leads-to relation is restricted to \([0,1]\). The statistical independence constraint in Rule 13.12 of the CORAS book is not needed.
1.3.1 B.3.1 Rule for leads-to
Soundness
Assume
Then
Proof: (2) implies there are \(f_1, f_2\in {{\mathbb {F}}}\) such that
(1) and (4) imply
(6) and (7) imply
(5) and (8) imply (3).
1.3.2 B.3.2 Rule for mutually exclusive vertices
For simplicity we have merged four premises into two using logical conjunction.Footnote 2
Soundness
Assume
Then
Proof: (1) and (2) imply
(1) and (2) imply
(4), (5) and (6) imply (3).
1.3.3 B.3.3 Rule for separate vertices
Soundness
Assume
Then
Proof: (3) implies
(1), (2), (5) and the fact that \(f_1+f_2-0\le f_1+f_2\le f_1+f_2\) imply (4).
Appendix C: Binary risk graphs
1.1 C.1 Syntax of binary risk graph formulas
A binary risk graph formula is of the form
where \(H_1 \vdash G_1\) and \(H_2 \vdash G_2\) are risk graph formulas. A pair of histories \((H_1,H_2)\) fulfills a pair of risk graphs \((G_1,G_2)\), written
if
1.2 C.2 Semantics of binary risk graph formulas
Rights and permissions
About this article
Cite this article
Refsdal, A., Solhaug, B. & Stølen, K. Security risk analysis of system changes exemplified within the oil and gas domain. Int J Softw Tools Technol Transfer 17, 251–266 (2015). https://doi.org/10.1007/s10009-014-0351-0
Published:
Issue Date:
DOI: https://doi.org/10.1007/s10009-014-0351-0