Model-Based Safety and Security Engineering

Abstract: By exploiting the increasing surface attack of systems, cyber-attacks can cause catastrophic events, such as, remotely disable safety mechanisms. This means that in order to avoid hazards, safety and security need to be integrated, exchanging information, such as, key hazards/threats, risk evaluations, mechanisms used. This white paper describes some steps towards this integration by using models. We start by identifying some key technical challenges. Then we demonstrate how models, such as Goal Structured Notation (GSN) for safety and Attack Defense Trees (ADT) for security, can address these challenges. In particular, (1) we demonstrate how to extract in an automated fashion security relevant information from safety assessments by translating GSN-Models into ADTs; (2) We show how security results can impact the confidence of safety assessments; (3) We propose a collaborative development process where safety and security assessments are built by incrementally taking into account safety and security analysis; (4) We describe how to carry out trade-off analysis in an automated fashion, such as identifying when safety and security arguments contradict each other and how to solve such contradictions. We conclude pointing out that these are the first steps towards a wide range of techniques to support Safety and Security Engineering. As a white paper, we avoid being too technical, preferring to illustrate features by using examples and thus being more accessible.

• The paper demonstrates how integrating safety and security models via MBE enables automated transformation from GSN assessments to attack-defense trees.
• It introduces a quantitative mechanism that updates safety confidence based on security assessment outcomes.
• It outlines a collaborative, iterative process that supports trade-off analysis and conflict detection between safety and security requirements.

This paper, "Model-Based Safety and Security Engineering" (1810.04866), addresses the critical need to integrate safety and security engineering practices in the development of modern interconnected systems. The increasing attack surface of systems, particularly in domains like automotive, avionics, and Industry 4.0, means that cyber-attacks can have safety-critical consequences. Traditionally, safety and security are treated separately with different methodologies and mindsets, leading to poor integration, increased costs, and potentially less safe and secure systems.

The core problem identified is the lack of a common language and process for integrating safety and security assessments throughout the development lifecycle. Specific challenges include:

1. Developing a common language for integrated assessments.
2. Enabling semi-automated extraction of security-relevant information from safety assessments.
3. Incorporating security assessment findings into safety assessments.
4. Developing techniques for trade-off analysis between safety and security mechanisms.
5. Developing techniques for quantitative evaluation of system safety that includes acceptable risk from security threats.

The paper proposes leveraging Model-Based Engineering (MBE) as a framework to facilitate this integration. MBE uses domain-specific models (like GSN for safety and Attack Defense Trees (ADT) for security) as central artifacts that engineers from different disciplines can work with. The proposed approach aims to allow safety and security engineers to use their specialized models while enabling structured exchange of information and analysis results between these models.

Key techniques illustrated in the paper include:

1. Safety to Security Transformation: The paper demonstrates how security-relevant information can be extracted from safety assessments represented as Goal Structured Notation (GSN) models. To overcome the lack of formal semantics in GSN text, the authors propose adding meta-data to GSN nodes and associated domain-specific requirements. This meta-data, potentially inspired by guide words, provides a machine-readable structure. For example, hazard impact, mechanism type (using guide words like "trigger," "stop"), and traces to components are added as meta-data. This structured information allows for the automated construction of preliminary Attack Trees (or ADTs) from GSN models. For instance, an attacker could aim to trigger events identified in FTA minimum cut-sets or exploit failure modes described in FMEA, and this can be automatically translated into attack tree branches.

   # Pseudocode for GSN to ADT transformation based on meta-data Function GSN_to_ADT(gsn_model): adt_model = new AttackDefenseTree() for each Goal g in gsn_model: if g has meta_data: hazard_impact = g.meta_data.hazard_impact mechanisms = g.meta_data.mechanisms # e.g., "trigger", "stop" traced_component = g.meta_data.trace # Create attack goal based on hazard and impact attack_goal = adt_model.create_attack_goal(g.text, hazard_impact) # Create attack methods based on mechanisms and component for each mechanism in mechanisms: if mechanism is "trigger": # Add attack method for triggering the component/event attack_method = attack_goal.add_attack_method("Attack to trigger " + traced_component) # Further refine attack method based on FTA/FMEA data if available if mechanism is "stop": # Add attack method for stopping the component/event attack_method = attack_goal.add_attack_method("Attack to stop " + traced_component) # Further refine attack method based on FTA/FMEA data if available # Consider attacks on safety mechanisms mentioned in GSN solutions for each Solution s in gsn_model associated with g: if s.type is SafetyMechanism and s has meta_data: voter_signals = s.meta_data.signals voter_threshold = s.meta_data.threshold # Add attack methods for attacking the safety mechanism (e.g., spoofing signals, tampering voter) attack_goal.add_attack_method("Attack Voter " + s.name) return adt_model

2. Security to Safety Integration: The paper proposes integrating the results of security assessments (ADT evaluations) into the confidence levels of safety assessments (GSN models). Building on existing work that quantifies GSN confidence using belief ($B$), disbelief ($D$), and uncertainty ($U$) values (e.g., based on identified vs. outruled defeaters), the security assessment's outcome is used to update these values.
   • If no security assessment is done for an item, uncertainty ($U$) in the corresponding safety assessment increases.
   • If the security risk is deemed acceptable based on ADT evaluation, belief ($B$) increases, and disbelief ($D$) and uncertainty ($U$) decrease.
   • If the security risk is unacceptable, disbelief ($D$) increases, and belief ($B$) and uncertainty ($U$) decrease. A weight parameter ($w$) determines the impact of the security assessment on the safety confidence. This quantitative integration helps address Challenges 3 and 5, providing a way to reflect security findings in the safety case's credibility.
3. Collaborative Development Process: The techniques are embedded within a proposed iterative process cycle involving safety and security engineers.
   • An initial safety assessment (GSN) is created.
   • Security assessment (ADT) is generated or refined based on the GSN (Safety to Security).
   • The ADT is evaluated for risk acceptability.
   • Security feedback (acceptable/unacceptable risk or no assessment) is integrated into the GSN confidence (Security to Safety).
   • If the safety confidence is unacceptable, either the safety assessment is refined, or security is requested to add further mitigations.
   • Added mitigations may necessitate a safety revision to ensure they don't introduce new hazards or conflicts. This cycle repeats until acceptable safety and security risk levels are achieved, allowing engineers to use their domain-specific expertise and tools while ensuring collaboration.
4. Trade-off Analysis: The paper illustrates how MBE models and associated requirements can be used to detect conflicts between safety and security mechanisms. Domain-specific requirements linked to GSN solutions and ADT counter-measures contain functional specifications (e.g., boolean conditions for door lock status). By extracting the logical clauses from these requirements and using automated reasoning tools (like Answer-Set Programming - ASP, or potentially model checkers), engineers can check for contradictions. The example shows how conflicting requirements for an emergency door (safety: unlocked when fire; security: locked when unauthorized access) can be automatically identified using ASP.

   % ASP code snippet illustrating conflict detection DoorLock :- negAuth. % Security Requirement: Door is locked if Auth is false negDoorLock :- SigFire. % Safety Requirement: Door is NOT locked if SigFire is true negAuth v Auth. % Auth is either true or false negSigFire v SigFire. % SigFire is either true or false contradiction :- DoorLock, negDoorLock. % Contradiction if both DoorLock and negDoorLock are true :- not contradiction. % Only show answer sets that contain a contradiction

   If the ASP solver finds a solution (answer set), it indicates a scenario where the requirements conflict. This allows engineers to identify and resolve contradictions, such as refining requirements or choosing alternative mechanisms.

The authors state that these techniques have been implemented or are under implementation as new features in the Model-Based tool AF3, developed by fortiss.

The paper concludes by outlining future work, including further development of techniques (meta-data schemas, handling timing contradictions, trade-off analysis compilation), refining the collaborative processes (extending to other disciplines like performance, tool support, addressing assessment completeness and V&V challenges), and connecting the methods to existing certification processes (like ISO 26262). The challenges of assessment completeness are discussed in detail, proposing definitions based on formal properties, intruder capabilities, known attacks, and known defects.

In summary, this white paper presents a model-based approach to integrating safety and security engineering. It proposes concrete steps for translating between safety and security models, incorporating security analysis results into safety cases, enabling a collaborative development process, and automating the detection of conflicts between safety and security mechanisms, all within an MBE framework using tools like AF3. It sets the stage for developing more integrated and rigorous methods for building safe and secure systems in the face of increasing cyber threats.