Model-based Safety and Security Co-analysis: a Survey

We survey the state-of-the-art on model-based formalisms for safety and security analysis, where safety refers to the absence of unintended failures, and security absence of malicious attacks. We consider ten model-based formalisms, comparing their modeling principles, the interaction between safety and security, and analysis methods. In each formalism, we model the classical Locked Door Example where possible. Our key finding is that the exact nature of safety-security interaction is still ill-understood. Existing formalisms merge previous safety and security formalisms, without introducing specific constructs to model safetysecurity interactions, or metrics to analyze trade offs.


Introduction
New technology comes with new risks: drones may drop on to people, self-driving cars may get hacked, medical implants may leak in people's body. Such risks concer both accidental failures (safety) and malicious attacks (security). Safety and security are heavily intertwined. Measures that increase safety often decrease security and vice versa: the Internet-of-Things offers ample opportunities to monitor the safety of a power plant, but their many access points are notorious for enabling hackers to enter the system. Passwords secure patients' medical data, but are a hindrance during emergencies. It is therefore widely acknowledged, also by international risk standards [22,24], that safety and security must be analyzed in combination [5,35]. To cater for this need, various risk frameworks have been developed for safety-security co-analysis. Process-oriented frameworks consider the steps needed for performing safety-security risk analysis [23,20]. Various formalisms specifically support the risk assessment phase within this process, i.e., the identification, analysis and evaluation of safety-security risks. Text-based methods include FMVEA [42], CHASSIS [41] and SAHARA [34]. Our focus is on model-based risk assessment. These formalisms provide a detailed insight in This work was partially funded by ERC Consolidator Grant 864075 (CAESAR). different failure and attack modes, mechanisms and their root causes. Understanding these is crucial for effective decision making. Model-based formalisms allow one to compute various dependability metrics. Such metrics quantify key performance indicators, like the availability and mean time to attack/failure. Problem statement. With various formalisms being proposed for the relevant purpose of safety-security co-analysis, it becomes natural to compare these, and assess their merits. Several questions emerge: (Q1) How these formalisms compare? (Q2) Which modeling constructs exist to model the interactions between safety and security? (Q3) Which analyses do these formalisms enable? (Q4) How do these formalisms compare on industrial case studies and (Q5) What would be desirable extensions?
Our literature search followed well-established methodological principles [9], focusing on peer-reviewed publications published until 2020. We queried Scopus, Microsoft Academic and Google Scholar, using the keywords "safety", "security", "dependency" and "model-based". We further explored relevant results through backward and forward search, as well as safety-security surveys [31,36,12].

Ref. Year #Citations
Fault Tree/Attack Tree Integration (FT/AT) [17] 2009 170 Component Fault Trees (CFTs) [44] 2013 52 Attack-Fault Trees (AFTs) [32] [45,30]. This is a classical example of safety-security antagonism: if locked, a door is unsafe in case of a fire; if unlocked, it is insecure in case of a burglary. While being a toy example, similar principles appear in, e.g., fire exits in buildings and emergency stops in factories. We present conclusions and directions for future research.

Related work.
A few papers have surveyed safety and security combinations: paper [31] compares non-model-based and model-based approaches, the latter being graphical or non-graphical. Survey [12] compares seven frameworks with respect to model creation, origin, stages of the risk assessment, and use cases. Our comparison is more technical than [12]. Finally, [36] summarizes practices from safety and security modeling separately. A joint model is proposed, combining the goal structuring notation GSL with Attack-Defense Trees.  Organization. Section 2 presents our findings. Section 3 introduces Fault Trees and Attack Trees. Section 4 presents our definitions for dependencies. Section 5, 6 and 7 compare the various formalisms and Section 8 concludes the paper.

Findings
Our survey revealed several noteworthy findings, summarized in Tables 1 and 2.  [44], Attack-Fault Trees (AFTs) [32]. Others, grouped in Class 2, deploy additional constructs: State/Event Fault Treess (SEFTs) [38] use Petri nets, Boolean driven Markov processes (BDMPs) [30] use Petri nets and triggers, Attack Tree Bow Ties (ATBTs) [6] extend bowties. A third class safety-security frameworks concerns security extensions of architectural languages: STAMP [19], SysML [37] and AADL [13]. We also place Bayesian networks [29] in this class. Finding #2: No novel modeling constructs are introduced. None of the formalisms for safety and security integration that we found introduces novel modeling constructs to capture safety-security interactions. Instead, they merge existing safety and security formalisms without adding new operators. Thus, one can represent safety and security features in one model, but one may wonder to what extend the interaction can be expressed appropriately. Finding #3: Safety-security interactions are still ill-understood. While the paper [31] coins the four dependency types, definitions can be improved. In particular, we propose rigorous definitions that focus on requirements and events, to then specify these for tree-based formalisms in Section 4. Finding #4: No novel metrics were proposed. No novel metrics were introduced to quantify safety-security interactions. Again, classical metrics were studied, such as the mean time to failure and attacker success probabilities. Furthermore, trade offs between safety and security, e.g., through Pareto analysis, were not studied either, even though trade offs are natural to analyze and does not necessitate novel analysis methods.
Finding #5: No large case studies were carried out. This question on whether or not additional constructs are needed becomes more pressing, since no large case studies were carried out. In general, analyzed papers present relatively small examples for illustrative purposes. A notable exception is the medium-size, but realistic, pipeline case study in [30] and [32]. This is remarkable, because for safety and security separately, such large case studies do exist [13].

Conclusion.
In conclusion, the true interaction between safety and security is still ill-understood, and ill catered for. Thus, future work should focus on a fundamental understanding between safety and security, so that dedicated modeling constructs and metrics can be proposed. We suggest starting from a realistic case study, and synthesizing the needs for usable safety-security frameworks that fit the future needs in this important area.

Attack Trees and Fault Trees
FTs and ATs are similar in nature. Section 5 compares plain combinations of FTs and ATs, while Section 6 surveys FTs and ATs extensions with additional features. We first introduce FTs and ATs themselves. Modeling. FTs and ATs model how low level failures (resp. attacks) propagate through the system and lead to system level failures (resp. attacks). FTs have been developed in the early '60s [16]. Due to their popularity, ATs were developed in the '90 as their security counterparts [43]. FTs (resp. ATs) start with a Top Level Event (TLE), modeling a system level failure (attack), which is then refined through Boolean gates: the AND-gate indicates that all children must fail (be attacked) in order for the gate to fail (be attacked).
For the OR-gate to fail (be attacked), at least one of its children need to fail (be attacked). When refining is no longer needed, one arrives at leaves of the tree: The Basic Events (BEs) in FTs model atomic failures; the Basic Attack Step (BAS) in ATs model atomic attack steps. Non-leaves nodes, such as Locked in during fire and Attacker walks through door, are called intermediate events, denoted by rectangles. Despite their name, FTs and ATs are Directed Acyclic Graphs (DAGs), rather than trees, since subtrees can have multiple parent gates. The FT in Figure 1 models that integrity is compromised if one is either locked in during a fire or the door lock fails to close. This is modeled via the top ORgate. One is locked in during a fire if there is a fire and the door is locked. This is modeled via the AND-gate connecting the BEs Fire and Locked.
Analysis. FT and AT enable numerous analysis methods [28]: qualitative analyses include Minimal Cut Sets (MCSs), indicating which combinations of BEs or BASs lead to the TLE. The set {Fire, Locked} is a cut set in Figure 1. Quantitative analyses compute dependability metrics, such as the system reliability, attack probabilities and costs. For example, by equipping the BEs and BASs with probabilities, one can compute the likelihood of a system level failure or attack to occur. Both FTs and ATs are part of international standards [21] and have been used to analyse numerous case studies [46,18,11]. FTs and ATs also feature some differences: FTs often focus on probabilities, whereas ATs consider several other attributes, like cost, effort and required skills. Further, FTs have been extended with repairs [40], and dynamic gates [25,15]; ATs with defenses, and sequential AND (SAND) gates [27,18].

Dependencies in ATs and FTs Combinations/Extensions
This section proposes formal definitions of the four dependency types from [31] in the specific context of FTs and ATs. While [31] coins these dependencies, it does not give very precise definitions. The paper focuses on dependencies between requirements and/or measures, as do most examples (e.g., firewalls increases security, but decrease safety). We refine these definitions by focusing on events in the formalisms combining FTs and ATs. Note that these events correspond to requirements: the TLE provides the main disruption to be avoided; other events refine the TLE into subrequirements to be prevented. As such, these events and their interactions are the inverse of the logical interactions between the requirements. For each dependency type, we investigate to what extend these are expressible in the various FT and AT formalisms. These dependencies are to a large extend generic, independent of the safety-security context. When fit, we specialize to the safety-security interdependencies.
Antagonism. Two undesirable events A, B are antagonistic, or conflicting, if there is no situation in which neither event has occurred. In tree-based formalisms, let A and B have a shared security/safety event C as a child and let it be connected to either A or B exclusively through a NOT-gate. We then say that A and B are antagonistic with respect to C. The events Locked in during fire and Attacker walks through door in Figure 2b are antagonistic with respect to Door unlocked. As such, expressing antagonism requires a form of negation. . By assumption, all leaves in FTs and ATs are statistically independent. Events that are (mutually) reinforcing can also satisfy this statistical independence requirement. Thus, in tree-based formalisms the absence of (mutual) reinforcement is also required to capture Independence as intended. All tree-based formalisms from Sections 3 to 6 can express independence.
Observations. Since these formalisms combine FTs and ATs rather than developing new formalisms, it is difficult to support safety-security trade offs. No novel metrics were introduced either. It is of interest to extend trees by using two roots, for safety and security goals. These formalisms can be extended with NOT-gates. To assess their modelling capabilities, larger case studies are needed.

Formalisms combining Fault Trees and Attack Trees
This section surveys three combinations of FTs and ATs: Fault Tree/Atack Tree refines a FT's BEs with ATs; Component Fault Trees merges FTs and ATs, while Attack-Fault Trees merge dynamic FTs and dynamic ATs. Our figures use blue for events related to safety, yellow for security, and green for their combination.

Fault Tree-Attack Tree Integration
Modeling. FT/ATs [17] are based on the assumption that attackers try to force a system failure, expressed by the TLE of a FT, to occur. To do so, FT/ATs investigate how the BEs of an FT can be evoked by an attacker, refining these by ATs with the BE as goal. Figure 2a refines basic event Door lock fails in Figure 1, by making this glsbe the goal of the AT depicted in yellow. There is no clear method for modeling dependencies of components in the AT on parts of the FT, so mutual reinforcement can not be modeled due to a lack of bidirectionality. Conditional dependency and antagonism can be modeled as per Section 4.
Analysis. The paper [17] computes the probability for the TLE to occur, given probabilities for the BEs and and the BASs.
Observations. Exploiting safety faults is a common method for hackers to enter a system, e.g.: triggering a fire alarm to disengage a fire safety lock. Thus, it seems reasonable to consider the leaves of a FT as vulnerabilities, refining them as ATs. The fault tree's TLE then becomes the target for hackers. This can be reasonable e.g., shutting down a factory for ransomware. However, attackers are often exploit safety faults to achieve other goals, such as stealing digital assets.
In that case, the forcing of BEs is only a starting point. Subsequent attack steps could be modeled in an AT; this could be a natural extension for FT/ATs. Paper [17] abstractly models a chemical plant as a case study

Component Fault Trees
Modeling. CFTs equip FTs with a modular structure [26], so that a large FT can be modeled and analyzed in terms of smaller components. The paper [44] extends CFTs with security aspects by introducing a new BEs type for security breaches, which are essentially BASs. CFTs make no distinction between BEs and BASs. This is exemplified in Figure 2b, where attacks and failures are freely merged. As per Section 4, CFTs model mutual reinforcement, conditional and antagonistic dependencies. Analysis. The CFTs from [44] enable the same analysis methods as FTs. The authors remark that, if a BAS only occurs in MCSs with multiple, low probability and independent BEs, then this attack is very unlikely to ever cause a disruption, as it requires multiple other unlikely events to occur. However, one may remark that the same holds for any event.
Observations. Not distinguishing between safety and security has the advantage that all existing tools remain applicable. Moreover, one may ask if it really matters whether a disruption is due to a failure or an attack. A disadvantage of merging failures and attacks, however, is that no interactions or trade offs between safety and security can be studied. Paper [44] models an Adaptive Cruise Control system as a case study.

Attack-Fault Trees
Modeling. AFTs [32] treat attacks and failure in the same way of CFTs. However, AFTs merge dynamic ATs and dynamic FTs. These provide additional gates to model dynamic behaviour: dynamic ATs include the sequential ANDgate (SAND), modelling attacks as sequence of steps [4]. Dynamic FTs include gates for modeling spare components (SPARE), functional dependencies (FDEP) and priority ANDs (PAND). The AFTs leaves can be BEs, BASs and instant failures (IFAIL). Further, attacker profiles quantify the attacker's capabilities, such as available resources, skills and damage. These appear as attributes on the BASs. Figure 2c presents the Locked Door Example as a AFTs. The various SAND-gates indicate the order of events. E.g., for the Door lock breached event to happen, first Attack initiated must happen, and then the Access event as well.
In [32], the status of the door is modelled by two IFAIL leaves, Door locked and Door unlocked: if the door is locked, then the probability of it being unlocked is 0. Dependencies can thus be modeled as described in Section 4. Analysis. AFTs are analysed by translating the AFTs to a network of stochastic timed automata, analyzed via statistical model checking. Using the attribute values in the attacker profiles, several metrics can be computed, such as the time, cost and likelihood of the attacks. Pareto frontiers elucidate trade offs between attributes, e.g., the likelihood of an attack within a given budget.
Observations. AFTs share the two disadvantages common to all FT approaches in that there is no distinction between safety or security failures once the TLE occurs, and the methods of modeling interactions may not clearly highlight the antagonistic dependencies. The attacker profiles in AFTs support a wide range of quantifiable parameters, enabling versatile analysis and trade offs. Remarkably, AFTs are used to model the medium-sized case study of an oil pipeline, in addition to modelling the Locked Door Example.

Formalisms extending Fault Trees and/or Attack Trees
This section surveys combinations of FTs and ATs with additional features:

State/Event Fault Trees join a fault tree-like model with Petri nets, Boolean Driven Markov Processes extend FTs and ATs with Petri nets and triggers and
Attack Tree Bow-ties combine Event Trees with an FT/AT-like model.

State/Event Fault Trees
Modeling. State/Event Fault Trees (SEFTs) [38] join FTs and Petri nets † , expressing that certain failures can only happen in certain states. Whereas the leaves in ATs and FTs model atomic events, SEFTs deploy Petri nets to accommodate state changes inside basic events. In Figure 3, the Door component can move between the states Unlocked and Locked. These state changes are triggered by events, depicted as black rectangles, that can be exponentially distributed, deterministic, or triggered by other events. Both states and events can be communicated via the gates of the tree, via in and out ports. In this way, Figure 3 expresses that a fire casualty can only happen if the door is locked. Figure 3 models antagonism: the door should be unlocked to escape from Fire but locked to prevent failure of the AND-gate Enter unlocked door.  Analysis. SEFT support the same dependability metrics as attack-fault tree combinations. The tool ESSaReL translates SEFTs to extended deterministic stochastic Petri nets, which can be further analyzed by the TimeNet tool, e.g., for steady state analysis.
Observations. The authors of [38] model the small-sized example of a Tyre Pressure Monitoring System. Even though not mentioned explicitly in [38], it appears that Petri nets in the SEFT leaves must be disjoint between components. E.g., it is not possible to use the Unlocked state of the Door component as a direct input for an attack step. Allowing this could increase the expressivity of SEFTs.

Boolean Driven Markov Processes
Modeling. Boolean Driven Markov Processes [8] extend FTs by equipping each leave with a Markov process (MP), representing the different modes a component can be in. Various templates provide standard MPs to model standard failure behavior. For example, the failure in operation MP contains two modes, operational and failed. One transitions from operational to failed with an exponential failure rate λ, and back to operational with a repair rate µ. The IFAIL MP models instantaneous failures. Moreover, users can define their MPs as a stochastic Petri net [30], similarly to SEFTs. In [7], BDMPs are extended with security aspects by providing additional Markov processes for attacker steps. For example, the Attacker Action MP (AA) contains tree modes: in Idle the attacker has not yet initiated the attack. The Active mode corresponds to actual attempt, requiring an exponentially distributed time to succeed, and leading to the success mode. Further, triggers, represented by dotted red arrows, allow one MP to trigger a mode change in another MP. Figure 4 shows the Locked Door Example from [30]. The triggers pointing from Attack initiated to the OR-gate means that the OR-gate is not activated until Attack initiated happens. The use of Petri nets and the presence of intermediate events allow BDMPs to model all dependencies between safety and security, as detailed in Section 4. Analysis. BDMPs allows both quantitative and qualitative analysis. The authors of [7] build BD-MPs with the KB3 modeling software platform. The computation of the overall mean time to success (MTTS), the probability of success, and the list of possible attack success sequences is possible.
Observations. BDMPs are the only formalism, compared to the others of this work, that handles a medium size case study [10]. Furthermore, the authors discuss dependencies corresponding to those mentioned in the introduction. Because our definitions are more detailed, those do not coincide with our dependencies. Modeling. Attack Tree Bowties (ATBTs) [1] combine Bow-ties with ATs. Bowties [14] themselves combine FT and Event Trees (ETs): the left part of a Bow-tie is a FT modeling the causes of an hazardous event, which is in the middle of the Bow-tie. The ET on the right models its consequences. Barriers, i.e., a measure M preventing some failure F from happening, are modeled as AND(F, M ), so that the failure F only propagates if the barrier M fails. Now, ATBTs extend regular Bow-ties by attaching ATs to the basic events of a FT, just as in FT/ATs. Thus, in ATBTs, the left part of the Bow-tie is an FT/AT, rather than an FT. Figure 5 models the Locked Door Example via ATBTs. The leftmost part is equivalent to the FT/AT from Figure 2a. The ET on the right details the consequences in several cases: if the failure was a fire or a burglary, if alternate escape routes were available or inner doors were locked. Dependencies in ATBTs are the same as in FT/ATs, as further explained in Section 4. Analysis. Just like for regular Bow-ties, [1] identifies vulnerabilities via MCSs. By assigning likelihood level to all BEs and BASs, two likelihood levels are assigned to these cut sets: one for safety and one for security. Thus, trade offs can be made. Observations. Since the left, causal part of ATBTs is similar to FT/ATs, similar observations apply. Further it would be natural to study trade offs between safety and security by equipping ATBTs with two hazardous events, one for safety and one for security. Moreover, ATBTs are one of the few formalisms that consider safety-security trade offs. In [1] the authors create a small case study of a risk scenarioin a chemical facility.

Architectural formalisms and Bayesian Networks
Formalisms not based on trees are STAMP, SysML and AADL -which are all based on the system architecture -and Bayesian networks. Modeling. The System-Theoretic Accident Model and Processes (STAMP) is rooted in the observation that system risks do not come from component failures, but from inadequate control or enforcement of safety-related constraints. "In STAMP, systems are viewed as interrelated components that are kept in a state of dynamic equilibrium by feedback loops of information and control" [33]. Each component enforces the safety and security constraints in the processes it controls, using control actions and feedback messages. Inability to enforce these constraints results in failures in safety or security. System Theoretic Process Analysis (STPA) and its extension STPA-safesec [19] systematically identify the consequences of incorrect control actions and feedback, e.g., when these happen too early, in the wrong order, or were maliciously inserted. Figure 6 shows the Person, who can lock and unlock the door. Locking mechanism is controlled by Person, and controls if the Door can open. A safety constraint is that Person must be able to unlock a door in case of fire; a security constraint is an unauthorised person must not be able to gain access. A violation is, e.g., the scenario where the person locks the locking mechanism while the door is open, forcing the door to stay open and granting unauthorised access. STPA-safesec can discover these risks in a structured manner, however this is a manual process requiring domain knowledge and cannot be automated. STAMP is not geared towards expressing dependencies. However, STPA-safesec analysis may reveal safety-security conflicts. Analysis. STPA is used to identify potential hazards and undesired behaviours: e.g., the violation previously described. Observations. STAMP models control flows of the system and further analysis identify safety and security hazards in that control flow. Domain experts are required to properly identify issues. STAMP provides a structured way of reasoning based on a high level description of the system that should ensure the identification of safety and security requirements. STAMP can identify safety and security issues in a system, it is not for documenting those interactions. It is suited to help with the syntheses of a model describing safety and security interactions. Paper [19] uses the system connecting synchronous-islanded operating microgrids, microgrids that locally generate power separately from the main power grid, to the main grid as a case study. Modeling. The Systems Modeling Language (SysML) is a general-purpose modeling framework for systems engineering, and extends the Unified Modeling Language (UML). SysML-sec [39] extends SysML to express safety and security requirements. Its functional model describes the communication channels between processes, detailing the encryption methods and their complexity overhead cost. SysML-sec also includes a system mapping model. SysML-sec enables both safety and security properties to be expressed and verified via separate model checkers. E.g., checking if confidential communications can be intercepted by compromising the bus. The interaction between safety and security properties is not modeled. Since SysML-sec is geared to embedded software, we replaced the Locked Door Example with a digital keypad lock. Figure 7 shows the mapping model. Within the keypad, the CPU is connected to the main memory and an Input-Output Bus. Connected to this bus is the physical button pad and a Digital Analog Converter that engages and disengages the lock. Figure  8 details the process of (dis)engaging the lock. The correct codes are stored in an encrypted format, and an input code is received unencrypted. Both codes are collected, and the input code is checked against the stored key, either by decrypting the stored key or encrypting the input key. On a match, a command is sent to (un)lock the door. Analysis. The TTool [37] can encode ATs and FTs in a SysML parametric model. It then uses UP-PAAL to test for reachability of the TLE. Counter measures can be annotated to the ATs and FTs models, and individual attack vectors/BEs switched on or off. UPPAAL will then indicate if preventing the chosen subset of attack vectors/BEs is sufficient to prevent the TLE. No method for capturing the ATs and FTs is included. TTool can also verify security requirements with ProVerif [2]. Requirements can be tagged as e.g. Confidentiality, Non Repudiation, Data Origin Authenticity [3]. For example, a confidentiality requirement on all communications can be created, and comm channels from the functional model linked to these requirements. An unsecured bus does not satisfy the confidential requirement, and with no other mitigation e.g., encrypted messaging, ProVerif will find a state where the confidential requirement of the comm channel is violated, and return a trace showing how this state was reached. Safety and security are modeled and analyzed separately. Thus, violation of safety and security requirements can be observed, as well as attempts at mitigation violating other requirements, but no direct interactions.

SysML
Observations. SysML is not suitable for generally visualising the interactions between safety and security in arbitrary systems, but for designing complex embedded systems with safety and security requirements. Paper [37] uses Key Masters Keying Protocol, which aims to securely distribute a randomly generated key among a group of in-car Electronic Control Units, as a case study. Modeling. AADL models the software and hardware architecture of embedded, real-time systems. It consists of a core language and several annexes: the core describes the multithreaded, distributed software architecture, and the annexes describe real-time behaviour, and error modelling. To detect software failures (safety), the AADL standard contains the EMV2 language.Safety and security are added in one AADL model in [13]. Safety analysis computes the mean time between failures (MTBF) of the system. For security, the goal is to avoid unauthorized access to sensitive data. Data is accessed through AADL ports of subprograms. So it is important to verify that the indirect data access points are secure enough. A dedicated property set is used to associate a security level, which is an integer value, to AADL data. Figure 9 models the Locked Door Example with AADL: this is uncommon for AADL because it is often used for the interaction between software and hardware components. Here we consider a Person, a Locking mechanism, and Door access as components. They are linked through ports. AADL does not model any kind of dependencies: safety and security are considered separately, although they share the same AADL model to perform the analysis. Analysis. For safety, the MTBFs of the system is calculated via the AADL Error model statements which are in various components descriptions. They are compiled together to generate a FT. For security, the goal is to avoid unauthorized access to sensitive data via the Stood for AADL tool.

The Architectural Analysis and Design Language AADL
Observations. An AADL model is scalable and appropriate for version and configuration management, because it can be fully described by its textual representation.FTs can be analyzed after transforming AADL to another tool which makes AADL an excellent application for FTs. Interesting for future work could be to integrate also ATs with AADL. There is a small case study in [13] on the locked door created by the authors. (BN) is a probabilistic graphical model that represent probabilistic dependencies between several variables via a directed acyclic graph. Each node A represents a variable, and an edge from A to B indicates that A stochastically depends on B. A conditional probability table yields the conditional probabilities P [A|B]. If the probabilities of the leaves in the BN are known, the probabilities of the root nodes can be calculated. In [29], BNs are proposed to model safety and security dependencies. The two root nodes represent system safety and security. Figure 10 expresses that Door locked is a common factor for safety and security. BNs model conditional dependency, mutual reinforcement, and antagonism. Analysis. Qualitative analysis can be done in the form of conditional independence analysis (analyzing which nodes influence other nodes and how). BNs enable quantitative analysis to calculate reliability metrics such as mean time to failure.

Modeling. A Bayesian Network
Observations. Fault trees and attack trees can be seen as special cases of Bayesian networks, where the CPT tables encode the Boolean gates, e.g., P [A = 0|B = 1, C = 1] = 1, 0 for other B and C, for an AND-gate A with children B and C. Thus, the BNs extend ATs and FTs with flexible dependencies, and separate TLEs for safety and security. However, the gates in ATs and FTs provide a clearer visualization of the gates, since in BNs these must be read from the probability tables. Paper [29] uses the pipeline example as a case study.

Conclusion and Future Work
We surveyed 10 model-based formalisms that capture safety/security interdependencies. Out of these, only AFTs, BDMPs and BNs fully capture all four interactions: antagonism, mutual reinforcement, conditional dependency and independence. None of the formalisms present specific constructs for safety/security interdependencies: they are acquired from safety-only or security-only frameworks and joint afterwards, following different strategies. The same holds for metrics: none of those is specific for safety/security interactions. To the best of our knowledge, safety/security interactions are studied inside limited scenarios and large industrial case studies are still missing. More rigorous definitions of safety/security dependencies are needed, to account for: 1. Directionality. Are safety and security directional or bi-directional and from which direction do they flow? 2. Intensity. For a quantifiable co-analysis, intensity of these interaction has to be considered. 3. Nature of the interaction. For each of the possible interactions, from influence, to dependency or antagonism, accounting for the positive or negative impact of such an interaction is fundamental. Further extensions could be considered for every FT/AT-based formalism, i.e., using two roots to account for different safety and security TLEs, similarly to BNs. Analyzed formalisms join analysis methods and metrics from the fields of security and safety: this approach does not consider the possibility to develop metrics that are instead safety-security specific. The visualization of safety/security interdependencies should also be considered to ease readability of complex models.