Safety and security interdependencies in complex systems and SoS: Challenges and perspectives

Transcription

1 Complex Systems Design & Management 2011 Safety and security interdependencies in complex systems and SoS: Challenges and perspectives Sara Sadvandi (Sodius) Nicolas Chapon (C-S) Ludovic Piètre-Cambacédès (EDF R&D) 1

2 Content 1. Introduction 2. A first fundamental step: towards asafety and security ontology for System Engineering (SE) a. General b. Safety paradigm c. Security paradigm d. A safety and security integrated ontology 3. Orchestrating safety and security into SE processes a. Key issues to integrate safety and security in complex systems b. Extending the existing tools and workbenches, and their limitations c. Orchestrating the security and safety departments d. Decompartmentalization of normative and collaborative initiatives 4. Conclusion, limits and perspectives 2

3 Introduction Context Growing complexity of industrial systems Systems of systems Safety (accidental failures) Security (malicious activities) Digitalization and interconnectivity Safety and security used to concern different components, and be dealt by different teams. They now concern more and more the same systems/sos 3

4 Introduction Issue/challenge Recent but general phenomenon Safety and security are strongly interdependent A growing but unsufficient attention (Eames & Moffett 1999, Derock et al. 2010, ) A visual simple example Mutual reinforcements Antagonisms Conditional dependencies 4

5 Introduction Stakes Mutual reinforcements Redundant efforts, useless costs Antagonisms hidden weaknesses or erroneous risk evaluation Difficulties Transverse, multi-phases/processes Multi-disciplinary, multi-cultural Numerous methodologies, standards, regulations, actors Safety and security need to be considered together in complex systems/sos: SE tools/methodologies bring and appropriate framework 5

6 A first fundamental step: towards a safety and security ontology for system engineering General Environment Fault avoidance Fault tolerance Design Phase Operational Phase Users Hazards Failures Designers Faults Technical System Failures System Elements Errors External Threats/Events System External Threats/Events Criteria / properties Basis for a common understanding Security Safety Changing meanings of the terms safety and security, Availability depending on the context Availability Malicious (M-A Security) Integrity Confidentiality Accidental (M-A Safety) Maintainability Env. Sys. (S-E Security) Integrity Reliability Maintainability Sys. Env. (S-E Safety) Sys. Sys. (Other) Auditability A glimpse on existing integrated frameworks Laprie: Imputability everything as dependability Firesmith: too many new concepts Business Deleuze: criteria cybersecurity not included Efforts and contributions are still necessary 6

7 A first fundamental step: towards a safety and security ontology for system engineering General Criteria / properties Environment Designers External Threats/Events Security Safety Fault avoidance Design Phase Faults Technical System Failures System Availability Integrity Confidentiality Availability Integrity Reliability Fault tolerance Operational Phase Users Hazards Failures System Elements Errors External Threats/Events Maintainability Auditability Imputability Business criteria Maintainability 7

8 A first fundamental step: towards a safety and security ontology for system engineering Safety paradigm adapted from MIL-STD-882 and ESARR (Eurocontrol) ENVIRONMENT EXTERNAL EVENTS Operators Procedures Technical system induce Errors Errors Technical failures System induce Functions HAZARDS induce EFFECTS 8

9 A first fundamental step: towards a safety and security ontology for system engineering Security paradigm adapted from EBIOS exploits the flaws in the system ENVIRONMENT Operators Procedures Technical system Compromised Compromised Compromised System induce Functions HAZARDS induce EFFECTS 9

10 A first fundamental step: towards a safety and security ontology for system engineering Safety and security integrated paradigm [1/2] ENVIRONMENT 0-DAY THREATS EXTERNAL EVENTS HARDLY PREDICTABLE KNOWN THREATS System USE DEFENCE IN-DEPTH PREDICTABLE THREAT MODELING IN FORMAL RISK ASSESSMENT FRAMEWORKS EFFECTS 10

11 A first fundamental step: towards a safety and security ontology for SE processes Safety and security integrated paradigm [2/2] Formal risk assessment frameworks may be used to cover both safety and security known threats and thereby helping to: 1. achieve consistency, 2. give a clear understanding of safety-security interdependencies (including potential reinforcements and conflicts). Defence in-depth (DiD) may help to mitigate both safety and security hardly-predictable risks (in addition to known ones). This may increase the ROI of expensive measures which can be mutualized in some cases. NB: safety DiD and security DiD may differ in terms of implementation (different threats and measures). The mutualization can only be partial. E.g., safety-oriented DiD implies redundancy which may be useless from a malicious perspective, vulnerabilities being simply duplicated. 11

12 Harmonizing safety and security into system engineering processes Key issues to integrate safety and security in complex systems Multiple types of design and conception Requirement analysis, functional disciplines, dysfunctional disciplines, re-engineering Disconnected models between the different disciplines (for now) Different points of view for the same system Numerous tools with different levels of abstraction Long term project life cycle Security and safety being evaluated over time Replacements of the methodologies Evolution of the systems Redundant and repetitive analysis activities Often similar methodologies/tools with different vocabulary and terminology Common required properties and final objectives Integrity and availability are both key to safety and security Needed conditions for the system to fulfill correctly its missions 12

13 Harmonizing safety and security into system engineering processes Leveraging and extending the existing tools and workbenches Exemples of tools OCAS Simfia, EADS KB3 MDWorkbench, SODIUS SARRA Entreprise Architect DOORS And many more Principles/perspectives Heterogeneous Solutions Centralized Solutions Federated Solutions 13

14 Harmonizing safety and security into system engineering processes Orchestrating the security and safety departments Organizational and process harmonization Clearly defined interfaces between departments Formalized circulation of information Collaborative platform Consistent decision-making Safety and security reflected at the board level Equivalent treatments Adequate management of confidentiality Regulatory constraints Certification, audits, homologations Coordination between safety/security regulators 14

15 Harmonizing safety and security into system engineering processes Decompartmentalization of normative and collaborative initiatives Existing initiatives are very sector-oriented Aeronautics: EuroCAE, RTCA, FAA Process industry: ISA Automotive: Autosar, MISRA Academia: EWICS TC7 The issue is cross-sectorial, the stakes are significant A higher level forum may help In the system engineering community (e.g., AFIS / INCOSE) In the international standardization bodies (e.g., ISO) 15

16 Conclusion, limits and perspectives This may just be a starting point Industrial systems have growing complexity and interconnectivity Safety and security concerns are now converging on the same systems Mastering safety-security interdependencies is a key and challenging issue Unexploited possible reinforcements/redundancy may lead to additional costs Undetected antagonisms/dependencies may lead to inaccurate risk evaluation Presently different communities, tools, concepts, despite these links A need for a common ontology A need for harmonization within/between organizations System Engineering may provide an appropriate methodological framework, leveraging its body of knowledge, exploiting and enhancing existing tools Stong need to set-up a cross-sectorial and high-level forum In the S.E. community (AFIS, INCOSE) and/or in standardization bodies (ISO, IEC) 16