Structured Assurance Cases Three Common Standards First Presented

Structured Assurance Cases: Three Common Standards First Presented at: ICSM 2005 in Budapest and HASE 2005 in Heidelberg T. Scott Ankrum Alfred H. Kromholz The MITRE Corporation © 2005 The MITRE Corporation

Agenda z What is an Assurance Case? z Problems With Assurance Cases z Hypotheses z Notations and Tools z Structured Assurance Case Process z Assurance Standards Examined z Practical Application Example z Hypotheses Proved or Disproved MITRE – 2005 T. Scott Ankrum – Alfred H. Kromholz 2

What Is an Assurance Case? MITRE – 2005 T. Scott Ankrum – Alfred H. Kromholz 3

History of Assurance Cases z Originally Only Safety Cases y y y Aerospace Railways, automated passenger Nuclear power Off-shore oil Defense z Security Cases y Use compliance rules more than an assurance case z Cases for Business Critical Systems MITRE – 2005 T. Scott Ankrum – Alfred H. Kromholz 4

Definition of Safety Case z From Adelard’s ASCE manual: “A documented body of evidence that provides a convincing and valid argument that a system is adequately safe for a given application in a given environment. ” MITRE – 2005 T. Scott Ankrum – Alfred H. Kromholz 5

Definition of Assurance Case z Generalizing that definition A documented body of evidence that provides a convincing and valid argument that a specified set of critical claims regarding a system’s properties are adequately justified for a given application in a given environment. MITRE – 2005 T. Scott Ankrum – Alfred H. Kromholz 6

Where is an Assurance Case Used? y Critical systems under regulation or acquisition constraints y Third-party certification, approval, licensing, etc. y Documented body of evidence required y Need a compelling case that the system satisfies certain critical properties for specific contexts y Examples: DO-178 B, Common Criteria, MIL-STD-882 D y “safety case”, “certification evidence”, “security case”… Collectively we’ll refer to them as “assurance cases” MITRE – 2005 T. Scott Ankrum – Alfred H. Kromholz 7

Problems With Assurance Cases MITRE – 2005 T. Scott Ankrum – Alfred H. Kromholz 8

Problems with Assurance Cases z There are problems in every aspect of assurance cases y y Building them Reviewing them Maintaining them Reusing them z Problems result from: y volume of material y little structuring support y ad hoc “rules of evidence” MITRE – 2005 T. Scott Ankrum – Alfred H. Kromholz 9

Building the Assurance Case – 1 z Most guidance is: y strong on excruciating detail format y weak on gathering, merging, and reviewing evidence z Guidance often uses the “cast a wide net” tactic y Assurance costs time and money y “Squandered diagnostic resources” y Some work on a “portfolio management” approach MITRE – 2005 T. Scott Ankrum – Alfred H. Kromholz 10

Building the Assurance Case – 2 z With free format text and no tool support: y coordination is hard y tracking is hard y workflow management is hard z Imagine building a 500 page project plan by hand, on paper MITRE – 2005 T. Scott Ankrum – Alfred H. Kromholz 11

Reviewing the Assurance Case – 1 z Stacks of free-format text makes review tedious y Hard to see linkages or patterns y Hides key results in sheer volume z Weak guidance on review of arguments and evidence often results in ad hoc criteria (be very nice to your reviewer!) z Rarely is there explicit guidance for weighing conflicting or inconsistent evidence MITRE – 2005 T. Scott Ankrum – Alfred H. Kromholz 12

Reviewing the Assurance Case – 2 “Often viewed as irrefutable, evidence is, in fact, an interpretive science, refracted through the varying perspectives of different disciplines. . [Judging evidence requires] reasoning based on evidence that is incomplete, inconclusive, and often imprecise. ” The Evidential Foundations of Probabilistic Reasoning, David Schum MITRE – 2005 T. Scott Ankrum – Alfred H. Kromholz 13

Maintaining the Assurance Case – 1 z The one thing more brittle than software is – the associated assurance case z It is difficult to understand impact of a change on assurance structure because: y volume of information is immense y impact of a change on assurance structure is complex MITRE – 2005 T. Scott Ankrum – Alfred H. Kromholz 14

Maintaining the Assurance Case – 2 z Reasons for change y y The claims and/or evidence have changed Arguments no longer valid or new ones needed Evidence is irrelevant or new evidence needed “Weak link effect” of discrete systems compounds problem z Revalidation costs are a major burden z “Breakage” of successive dependencies MITRE – 2005 T. Scott Ankrum – Alfred H. Kromholz 15

Reusing the Assurance Case – 1 z Assurance case frameworks are rarely the subject of study per se z More attention for these would be useful y tool support y idioms and templates y extracting patterns for future use MITRE – 2005 T. Scott Ankrum – Alfred H. Kromholz 16

Reusing the Assurance Case – 2 z Relationship among claims, arguments, and evidence y not often explicit y hard to distinguish the reusable from the project specific portions of assurance case z Compare this with building a deck with the help of a project planning tool MITRE – 2005 T. Scott Ankrum – Alfred H. Kromholz 17

Hypotheses MITRE – 2005 T. Scott Ankrum – Alfred H. Kromholz 18

Hypotheses z All Assurance Cases Have Similar Components Assurance is assurance… z An Assurance Standard Implies the Structure y The standards document implies some structure of an assurance case that would conform to it actual or implied structure of an assurance standard MITRE – 2005 inherent structure of assurance case instantiated from that standard T. Scott Ankrum – Alfred H. Kromholz 19

Notations and Tools MITRE – 2005 T. Scott Ankrum – Alfred H. Kromholz 20

Notations Considered z Toulmin Structures (law domain) y Claim, Qualifier, Data, Warrant, Backing, Reservation z Goal Structuring Notation (GSN): T. Kelly y Main node types: Goal, Strategy, Solution y Supporting nodes: Assumption, Justification, Context, Model, Notes z ASCAD (Adelard Safety Claims Arguments Data) y described in the ESPRIT SHIP project y Claim, Argument, Evidence Selected ASCAD for its simplicity MITRE – 2005 T. Scott Ankrum – Alfred H. Kromholz 21

The Tool Selected z Investigated and tested three tools y Structured Evidential Argumentation System (SEAS), SRI y Wisdom Pad, Expert Decision Systems (EXDS), Inc y The Adelard Safety Case Editor (ASCE), Adelard z Selected Adelard Safety Case Editor (ASCE) y y y Supports both ASCAD and GSN Graphical user interface to arrange and connect nodes Rules that identify structure errors like a compiler Structured and unstructured data behind each node Hyperlinks to internal and external references MITRE – 2005 T. Scott Ankrum – Alfred H. Kromholz 22

ASCAD Entities and Tool Notation Claim = assertion to be proven Claim Argument = how evidence supports claim Argument Evidence = required document Evidence MITRE – 2005 T. Scott Ankrum – Alfred H. Kromholz 23

Structured Assurance Case Process MITRE – 2005 T. Scott Ankrum – Alfred H. Kromholz 24

Developing a Structured Assurance Case Related claim needed? Specify Related Claim Evidence needed for this claim? Identify Supporting Evidence Argument needed for this claim? Specify Top-level Claim no Are all child claims “necessary & sufficient” for their parent claims? yes Develop Argument Done Non-Deterministic Flow MITRE – 2005 T. Scott Ankrum – Alfred H. Kromholz 26

Assurance Standards Examined MITRE – 2005 T. Scott Ankrum – Alfred H. Kromholz 27

Standards Selected for Mapping into Structures z The Common Criteria for Information Technology Security Evaluation, ISO/IEC 15408: 1999 y represents the biggest divergence from Adelard’s safety-critical domain z RTCA/DO-178 B Software Considerations in Airborne Systems and Equipment Certification y the only one of the three that sits firmly within Adelard’s territory z ISO 14971 Medical devices – Application of risk management to medical devices y in a domain for which Adelard’s tool has not yet been used y risk management approach is different from the other selected standards MITRE – 2005 T. Scott Ankrum – Alfred H. Kromholz 28

Process Mechanics – 1 z Goals: y Avoid misrepresenting the standard with our own ideas y Be consistent in structuring each standard z Methods: y Devised a minimal set of rules for mapping each standard y Tried to apply those rules mechanically in our mapping z Mapped the entire standard or a usable subset y DO-178 B and ISO 1497 completely y Common Criteria – only EAL 4 Result: Each mapping should still be recognizable MITRE – 2005 T. Scott Ankrum – Alfred H. Kromholz 29

Process Mechanics – 2 z ASCAD notation requires y y y Quasi-hierarchical (multiple parents are allowed) One claim at top of hierarchy Subordinate claims below Evidence nodes at the bottom Argument positioned between claim and its evidence z We deviated somewhat y Arguments also positioned between claim and sub-claims MITRE – 2005 T. Scott Ankrum – Alfred H. Kromholz 30

The Common Criteria – Detail Leg ARGUMENT AVA Vulnerability Assessment Supports ARGUMENT AVA_MSU. 1. Examination of Guidance Is evidence for EVIDENCE AVA_MSU. 1. Examination of Guidance MITRE – 2005 Supports ARGUMENT AVA_SOF. 1 Strength of TOE Security Functions ARGUMENT AVA_MSU Misuse Supports ARGUMENT AVA_MSU. 2. Validation of Analysis Is evidence for EVIDENCE AVA_MSU. 2. Validation of Analysis Supports ARGUMENT AVA_SOF. 1. Strength of TOE Security Functions Is evidence for EVIDENCE AVA_SOF. 1. Strength of TOE Security Functions ARGUMENT AVA_VLA Vulnerability Analysis Supports ARGUMENT AVA_VLA. 1. Developer Vulnerability Analysis Is evidence for EVIDENCE AVA_VLA. 1. Developer Vulnerability Analysis T. Scott Ankrum – Alfred H. Kromholz Supports ARGUMENT AVA_VLA. 2. Independent Vulnerability Analysis Is evidence for EVIDENCE AVA_VLA. 2. Independent Vulnerability Analysis 31

The Common Criteria – Top Level ARGUMENT ACM Configuration Management Supports ARGUMENT ACM_AUT CM Automation CLAIM EAL 4 [Confidence in Security because the product has been] methodically designed, tested, and reviewed Supports ARGUMENT AVA Vulnerability Assessment Supports Supports ARGUMENT ACM_SCP CM Scope ARGUMENT AVA_MSU Misuse Supports ARGUMENT AVA_SOF Strength of TOE Security Functions ARGUMENT ACM_CAP CM Capabilities Supports ARGUMENT AGD Guidance Documents ARGUMENT ADO Delivery and Operation Supports ARGUMENT ATE Tests Supports ARGUMENT ADO_DEL Delivery ARGUMENT AGD_ADM Administrator Guidance Supports ARGUMENT ADO_IGS Installation, Generation and Start-up ARGUMENT ADV Development ARGUMENT ADV_FSP Development Supports ARGUMENT ADV_HLD High-Level Design MITRE – 2005 ARGUMENT ATE_COV Coverage ARGUMENT AGD_USR User Guidance ARGUMENT ALC Life Cycle Supports ARGUMENT ADV_IMP Implementation Representation ARGUMENT ADV_SPM Security Policy Modeling Supports ARGUMENT ADV_RCR Representation Coorespondence ARGUMENT ADV_LLD Low-Level Design ARGUMENT AVA_VLA Vulnerability Analysis Supports ARGUMENT ALC_DVS Development Security Supports ARGUMENT ATE_DPT Depth Supports ARGUMENT ATE_IND Independent Testing ARGUMENT ATE_FUN Functional Tests Supports ARGUMENT ALC_TAT Tools and Techniques ARGUMENT ALC_LCD Life Cycle Definition T. Scott Ankrum – Alfred H. Kromholz 32

Issues Encountered While Structuring Common Criteria z Highly structured y Easy to map one assurance level into ASCAD y Introductory paragraphs worded like justifications x Fit better as argument nodes x No claims except at the top z No “objectives” paragraph at component/bottom level y Leaving an empty argument at that level y Only evidence requirements for those components z More complex evidence requirements than our mechanical rules allowed for MITRE – 2005 T. Scott Ankrum – Alfred H. Kromholz 33

RTCA/DO-178 B – Detail Legs CLAIM: 4. 0 Software Planning Process is Executed CLAIM: 3. 0 Software Life Cycle is properly defined CLAIM: 3. 1 Software Life Cycle processes are defined EVIDENCE: 3. 1 Life Cycle Process Requirement ARGUMENT: 4, 1 b, 4. 3 Software development and integral processes are defined EVIDENCE: 11. 1 Plan for Software Aspects of Certification MITRE – 2005 CLAIM: 3. 2 Software Life Cycle is defined EVIDENCE: 3. 1 Life Cycle Process Document ARGUMENT: 4. 1 b, 4. 3 Transition criteria are defined EVIDENCE: 11. 2 Software Development Plan ARGUMENT: 4. 1 c Software lifecycle environment is defined EVIDENCE: 11. 3 Software Verification Plan EVIDENCE: 11. 4 SCM Plan ARGUMENT: 4. 1 d Additrional considerations are addressed EVIDENCE: 11. 5 SQA Plan ARGUMENT: 4. 1 ep Software development standards are planned for EVIDENCE: 11. 6 SW Requirements Standards ARGUMENT: 4. 1 e Software development standards are defined EVIDENCE: 11. 7 SW Design Standards EVIDENCE: 11. 8 SW Code Standards T. Scott Ankrum – Alfred H. Kromholz ARGUMENT: 4. 1 f, 4. 6 Software plans comply with DO-178 B ARGUMENT: 4. 1 g, 4. 6 Software plans are coordinated EVIDENCE: 11. 19 SQA Records EVIDENCE: 11. 14 SW Verification Results 34

RTCA/DO-178 B – Top Level CLAIM: DO-178 B Software Considerations are taken into account ARGUMENT: (not explicit) Certification expects all factors be included CLAIM: 2. 0 System Aspects are Taken into Account CLAIM: 3. 0 Software Life Cycle is properly defined ARGUMENT: (not explicit) Certification expects all systems considerations to be addressed MITRE – 2005 CLAIM: 5. 0 Software Development Process is executed as planned CLAIM: 4. 0 Software Planning Process is executed ARGUMENT: (not explicit) All three areas are based on “best practices” and have detailed sub-claims CLAIM: 6. 0 Software Verification [low-level] and Integration Process CLAIM: 7. 0 SCM process is properly established and executed CLAIM: 8. 0 SQA process is properly established and executed CLAIM: 9. 0 Certification Liaison process is properly established & executed ARGUMENT: (not explicit) Satisfactory verification covers products of all processes ARGUMENT: (not explicit) Satisfactory SCM process includes six elements ARGUMENT: (not explicit) Satisfactory SQA process requires three characteristics ARGUMENT: (not explicit) Satisfactory Certification Liaison process comprises three factors T. Scott Ankrum – Alfred H. Kromholz 35

Issues Encountered While Structuring DO-178 B z Time is not inherently an element in ASCAD notation y sub-claims, and evidence were laid out in approximately their chronological order of use from left to right z DO-178 B does not include linkages between the generation of one artifact and its later use y We consulted an expert authorized to perform certification, a Designated Engineering Representative (DER) y DO-178 B does not specify all of the artifacts that the certification evaluator expects to examine y Supplier knows that the DER expects to see the implied documentation MITRE – 2005 T. Scott Ankrum – Alfred H. Kromholz 36

ISO 14971 Medical Devices – Detail Leg ARGUMENT H. 4 Rationale for clause 4, Risk analysis Is a subclaim of CLAIM 4 Risk analysis (Steps 1, 2 and 3 of Figure 2) Supports CLAIM 4. 1 Risk analysis procedure ARGUMENT H. 4. 1 Risk analysis procedure Supports ARGUMENT H. 4. 4 Estimation of the risk(s) for each hazard Supports CLAIM 4. 2 Intended use/intended purpose and identification of Supports ARGUMENT 4. 1 Compliance is checked by inspection of the risk Supports EVIDENCE 3. 6 Risk Management File ARGUMENT 4. 2 Compliance is checked by inspection of the risk management file. ARGUMENT H. 4. 2 Intended use/intended purpose and identification of Supports Is evidence for Supports ARGUMENT H. 4. 4 Estimation of the risk(s) for each hazard Is a subclaim of CLAIM 4. 3 Identification of known or foreseeable hazards (Step 2) Supports Is evidence for EVIDENCE 3. 6 Risk Management File Supports Is evidence for EVIDENCE Annex A Questions that can be used to identify medical device characteristics that could impact on safety MITRE – 2005 Is evidence for EVIDENCE Annex B Guidance on risk analysis for in vitro diagnostic medical devices ARGUMENT NOTE 3 EVIDENCE Annec C Guidance on risk analysis procedure for toxicological hazards Is evidence for EVIDENCE 3. 6 Risk Management File Is evidence for Supports ARGUMENT NOTE 1 ARGUMENT NOTE 2 & H. 4. 3 ARGUMENT 4. 4 EVIDENCE 3. 6 Risk Management File Is evidence for ARGUMENT 4. 3 Compliance is checked by inspection of the risk management file. Is evidence for Supports ARGUMENT NOTE 2 ARGUMENT NOTE 4 Supports ARGUMENT NOTE 3 Is a subclaim of CLAIM 4. 3 Foreseeable sequences of events that may result in a Supports ARGUMENT NOTE 1 CLAIM 4. 4 Estimation of the risk(s) for each hazard (Step 3) Is a subclaim of ARGUMENT H. 4. 3 Identification of known or foreseeable hazards Is a subclaim of EVIDENCE Annex D Examples of possible hazards and contributing factors associated with medical devices Is evidence for EVIDENCE Annex F Information on risk analysis techniques T. Scott Ankrum – Alfred H. Kromholz Is evidence for ARGUMENT 4. 4 Compliance is checked by inspection of the risk management file. Is evidence for EVIDENCE 3. 6 Risk Management File 37

ISO 14971 Medical Devices – Top Level CLAIM Introduction & Scope Medical Devices – Application of risk management to supports ARGUMENT H. 1 Rationale for Clause 1, Scope Is a subclaim of CLAIM 3 General requirements for risk management supports ARGUMENT H. 4 Rationale for clause 4, Risk analysis Is a subclaim of supports ARGUMENT H. 3 Rationale for Clause 3, General Management requirements for risk MITRE – 2005 CLAIM 4 Risk analysis (Steps 1, 2 and 3 of Figure supports ARGUMENT H. 4. 1 Risk analysis procedure supports ARGUMENT H. 5 Rationale for Clause 5, Risk evaluation supports ARGUMENT H. 7 Rationale for Clause 7, Overall residual risk evaluation supports ARGUMENT H. 8 Rationale for Clause 8, Risk management report ARGUMENT H. 9 Post-production information (Step 13) Is a subclaim of CLAIM 5 Risk evaluation Is a subclaim of CLAIM 7 Overall residual risk evaluation (Step 11) Is a subclaim of CLAIM 8 Risk management report (Step 12) Is a subclaim of CLAIM 9 Postproduction information (Step 13) CLAIM 6 Risk control T. Scott Ankrum – Alfred H. Kromholz 38

Issues Encountered While Structuring ISO 14971 z No direct relation between document structure and the structure of the intended assurance case y Major sections correspond to legs on the hierarchy y Statements representing claims, arguments, or evidence, have to be identified by analyzing the words and phrases z One generic evidence type referenced in many places z Document defines once what is instantiated several times z Risk Control: under Risk Evaluation in the hierarchy, but is an optional level of decomposition MITRE – 2005 T. Scott Ankrum – Alfred H. Kromholz 39

Practical Application Example MITRE – 2005 T. Scott Ankrum – Alfred H. Kromholz 40

Practical Application Example – Background z NSA research division – secure enclave y multiple authentication systems and an access log y software developed for them by a contractor y using formal methodology, validated by a third party z The NSA provided us with y Common Criteria Protection Profile document, from NSA y related Security Target document, from developer y EAL 5 targeted z Documents addressed Common Criteria components plus y hierarchical arrangement of assumptions and policies y objectives that address the policies y threats, as they relate to the assumptions MITRE – 2005 T. Scott Ankrum – Alfred H. Kromholz 41

Structuring the NSA Assurance Case z Combined Protection Profile with Security Target z Created three separate structures in ASCAD y Security assurance requirements x Enhanced our EAL 4 structure to EAL 5 x Amended it according to the protection profile and security target y Security functional requirements y Security threats, assumptions, and security policies x From tables in the protection profile MITRE – 2005 T. Scott Ankrum – Alfred H. Kromholz 42

Lessons Learned from NSA Project z Structuring revealed missing dependencies y Many security functional requirements list dependencies z Identified security threats went unanswered y Most threats were connected to requirements below y At least one had nothing below y Others may be insufficiently answered MITRE – 2005 T. Scott Ankrum – Alfred H. Kromholz 43

Hypotheses Proved or Disproved MITRE – 2005 T. Scott Ankrum – Alfred H. Kromholz 44

Second Hypothesis Proved or Disproved? z An Assurance Standard Implies the Structure y DO-178 B indicates structure in text and tables y Common Criteria implies structure through its own structure y ISO 14971 text suggests a reasonable approach for organizing z Based on this limited trial … One way or another, cases based on a given standard will inherently tend to be similar in structure MITRE – 2005 T. Scott Ankrum – Alfred H. Kromholz 45

First Hypothesis Proved or Disproved? z All assurance cases have similar components y Not clear that standards or assurance cases will have similar components y Use of a structuring notation helps identify gaps y Allows the applicant to present a case in a consistent manner y Rigor of a claim-argument-evidence structure creates fulfillment of the original hypothesis for a given standard, regardless of product y Makes consistency across different assessors more likely y Use of a consistent notation across standards is at least feasible y Opens possibility of tool use to identify gaps MITRE – 2005 T. Scott Ankrum – Alfred H. Kromholz 46

Using Our Results z Structured Standards can serve as templates – especially if we z Enhance structure of Common Criteria EAL 4 y Create empty argument nodes where they are needed y Document those nodes to be filled in for each assurance case y Divide evidence nodes to reference one thing each z Enhance structure of DO-178 B y Explicitly incorporate implied documentation and precedences z Enhance structure of ISO 14971 y y Create empty argument nodes where they are needed Document those nodes to be filled in for each assurance case Document the need to create a set of “risk evaluation” nodes for each risk The generic evidence node might become several nodes in the template MITRE – 2005 T. Scott Ankrum – Alfred H. Kromholz 47

Conclusion z Tools such as ASCE and its notation are applicable to a broad range of assurance standards z Mapping a standard into a notation may be a little time-consuming but is not difficult z Using mappings as assurance-case templates is only a side benefit MITRE – 2005 T. Scott Ankrum – Alfred H. Kromholz 48

Credits z Principal Investigators y Chuck Howell y Jim Moore z Research Assistant y Samarina Lowrie MITRE – 2005 T. Scott Ankrum – Alfred H. Kromholz 49