1. Assurance Case Frameworks Part of High Confidence Software MSR T. Scott Ankrum MITRE — Software Engineering Center March 11, 2004

2. T. Scott Ankrum — MITRE2 Credits Part of the “High-Confidence Software Initiative” research project Supported by the MITRE Sponsored Research program Supporting cast –Chuck Howell –Alfred Kromholz –Jim Moore Working for almost two years.

3. March 11, 2004T. Scott Ankrum — MITRE3 Agenda What is an Assurance Case? Structuring an Assurance Case Problems With Assurance Cases Choosing a Tool Structuring Selected Standards Conclusions and Follow-on

4. March 11, 2004T. Scott Ankrum — MITRE4 What Is an Assurance Case?

5. March 11, 2004T. Scott Ankrum — MITRE5 History of Assurance Cases Originally Only Safety Cases –Aerospace –Railways, automated passenger –Nuclear power –Off-shore oil –Defense Security Cases –Use compliance rules more than an assurance case Cases for Business Critical Systems

6. March 11, 2004T. Scott Ankrum — MITRE6 Definition of Safety Case 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.”

7. March 11, 2004T. Scott Ankrum — MITRE7 Definition of Assurance Case 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.

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

9. March 11, 2004T. Scott Ankrum — MITRE9 Structuring an Assurance Case

10. March 11, 2004T. Scott Ankrum — MITRE10 Elements of an Assurance Case Claims Arguments Evidence Other elements, depending on notation

11. March 11, 2004T. Scott Ankrum — MITRE11 Claims in Assurance Cases Assertion of compliance with key requirements and properties Must be in a specific context –Environment –Services or behavior –Threats –“Is this brick safe?” illustrates why… Sub-claims may be analogous to “lemmas” in a proof –separation of concerns –workflow –makes overall case more manageable

12. March 11, 2004T. Scott Ankrum — MITRE12 Arguments in Assurance Cases Link evidence to claims via inference rules –Deterministic: defined rules => true/false assertion –Probabilistic: quantitative, statistical, numerical threshold (MTTF) –Qualitative: rules with an indirect link to desired properties (standards, process guides) No such thing as perfection: “It is quite possible to follow a faulty analytical process and write a clear and persuasive argument in support of an erroneous judgment.” – R. Heuer, The Psychology of Intelligence Analysis

13. March 11, 2004T. Scott Ankrum — MITRE13 Evidence in Assurance Cases Process and people used to develop the system Systematic testing Product review and analyses Mathematical proofs None of these alone provides adequate evidence

14. March 11, 2004T. Scott Ankrum — MITRE14 Problems With Assurance Cases

15. March 11, 2004T. Scott Ankrum — MITRE15 Problems with Assurance Cases There are problems in every aspect of assurance cases –Building them –Reviewing them –Maintaining them –Reusing them Problems result from: –volume of material –little structuring support –ad hoc “rules of evidence”

16. March 11, 2004T. Scott Ankrum — MITRE16 Building the Assurance Case – 1 Most guidance is: –strong on excruciating detail for format –weak on gathering, merging, and reviewing evidence Guidance often uses the “cast a wide net” tactic –Assurance costs time and money –“Squandered diagnostic resources” –Some work on a “portfolio management” approach

17. March 11, 2004T. Scott Ankrum — MITRE17 Building the Assurance Case – 2 With free format text and no tool support: –coordination is hard –tracking is hard –workflow management is hard Imagine building a 500 page project plan by hand, on paper

18. March 11, 2004T. Scott Ankrum — MITRE18 Reviewing the Assurance Case – 1 Stacks of free-format text makes review tedious –Hard to see linkages or patterns –Hides key results in sheer volume Weak guidance on review of arguments and evidence often results in ad hoc criteria (be very nice to your reviewer!) Rarely is there explicit guidance for weighing conflicting or inconsistent evidence

19. March 11, 2004T. Scott Ankrum — MITRE19 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

20. March 11, 2004T. Scott Ankrum — MITRE20 Maintaining the Assurance Case – 1 The one thing more brittle than software is – the associated assurance case It is difficult to understand impact of a change on assurance structure because: –volume of information is immense –impact of a change on assurance structure is complex

21. March 11, 2004T. Scott Ankrum — MITRE21 Maintaining the Assurance Case – 2 Reasons for change –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 Revalidation costs are a major burden “Breakage” of successive dependencies

22. March 11, 2004T. Scott Ankrum — MITRE22 Reusing the Assurance Case – 1 Assurance case frameworks are rarely the subject of study per se More attention for these would be useful – tool support – idioms and templates – extracting patterns for future use

23. March 11, 2004T. Scott Ankrum — MITRE23 Reusing the Assurance Case – 2 Relationship among claims, arguments, and evidence –not often explicit –hard to distinguish the reusable from the project specific portions of assurance case Compare this with building a deck with the help of a project planning tool

24. March 11, 2004T. Scott Ankrum — MITRE24 Choosing a Tool

25. March 11, 2004T. Scott Ankrum — MITRE25 What Should a Tool Provide? – 1 Simple management of complexity and volume –MS Project-like planning and tracking of complexities –Checking simple structural properties –Browsing and report generation Support for multiple, geographically dispersed users –with data integrity –concurrently or asynchronously Useable for any domain –not specific to any one industry –not specifically for safety cases or security cases

26. March 11, 2004T. Scott Ankrum — MITRE26 What Should a Tool Provide? – 2 Replanning as things change: (“No plan survives contact with the enemy.”) Templates and tailoring to –capture lessons learned –reduce wheel reinvention Uses and/or exchanges consistent notation for: –claims, evidence, and arguments Widely executable –runs under Windows 2000 or Windows XP –or has a Windows based GUI

27. March 11, 2004T. Scott Ankrum — MITRE27 Notations Considered Toulmin Structures –Stephen Toulmin, The Uses of Argument, 1958 Goal Structuring Notation –Described in Tim Kelly’s dissertation, York, 1998 ASCAD (Claims-Arguments-Data): –ESPRIT SHIP project headed by Adelard Proprietary

28. March 11, 2004T. Scott Ankrum — MITRE28 Selected Tool: ASCE Established Notations: GSN & ASCAD Not Industry or Safety Specific Extensible through a Schema Case is exportable to project documents Stable, no failures during evaluation

29. ASCAD Notation

30. March 11, 2004T. Scott Ankrum — MITRE30 Structuring Selected Standards

31. March 11, 2004T. Scott Ankrum — MITRE31 Hypotheses Assurance is Assurance is Assurance –All assurance cases are similar enough in structure that a distinct tool for each domain is not required Assurance Standard Assurance Case –There is a relationship between the actual or implied structure of an assurance standard and the structure of an assurance case instantiated from that standard

32. March 11, 2004T. Scott Ankrum — MITRE32 Mapping Standards into ASCE Computer Security: –Common Criteria — Evaluation Assurance Level 4 Aviation Safety: DO-178B –Software Considerations in Airborne Systems Medical Device Safety: –Discussing with FDA Center for Devices & Radiological Health

34. March 11, 2004T. Scott Ankrum — MITRE34 Process Mechanics ASCAD notation: –Claims –Arguments –Evidence We used arguments between claims –This is a deviation from the notation Tried to capture all of the standard

35. March 11, 2004T. Scott Ankrum — MITRE35 Advantages of the Tool Carries both graphic structure and text Hyperlinks from node to a web page or file Enforces structure rules –Rules can be temporarily suspended –User-supplied rules can be added Can export for inclusion in a document User views can show parts of the structure

36. March 11, 2004T. Scott Ankrum — MITRE36 Mapping the Common Criteria Most hierarchical of the standards –Classes, Families, Components, Requirements –Components are atomic and cumulative Nearly mechanical process of mapping Most of the structure consists of Arguments –No sub-claims, only a top-level claim –Requirements are place-holders for evidence Objectives paragraphs became arguments

39. March 11, 2004T. Scott Ankrum — MITRE39 Mapping DO-178B Less structured, its title begins: –“Software Considerations …” Focused on system/software product lifecycle –Other standards are not time-structured –Claims, sub-claims, and evidence are laid out in approximately their chronological order –No linkages between the generation of one artifact and its later use

41. March 11, 2004T. Scott Ankrum — MITRE41 Mapping ISO 14971 Accompanying amendment is essential for mapping into ASCE No structural relation between the document and the assurance case Claims, arguments, and evidence identified by analyzing words and phrases Very few arguments for evidence For Each Identified Hazard…

43. March 11, 2004T. Scott Ankrum — MITRE43 Validating Our Mappings Domain experts reviewed our mappings –Common Criteria System security experts within MITRE –DO-178B Evaluator (FAA Designated Engineering Representative) –ISO 14971 FDA CDRH Varying conclusions from validations

44. March 11, 2004T. Scott Ankrum — MITRE44 Conclusions and Follow-on

45. March 11, 2004T. Scott Ankrum — MITRE45 Ada Lovelace

46. March 11, 2004T. Scott Ankrum — MITRE46 Hypotheses Revisited Assurance Standard Assurance Case –There does not seem to be much of a relationship between the two structures –Experience with actual assurance supports this Assurance is Assurance is Assurance –Negation of the above hypothesis prevents us from coming to any conclusion on this one

47. March 11, 2004T. Scott Ankrum — MITRE47 Standards Templates Mappings might be used as templates –Could be a side benefit of the study –Without structural relation, possibility looks bad Advantages of consistency may help drive assurance-requirements standardization –Currently, hard to “compare apples and oranges” –Evaluation of assurance claims easier if requirements are consistent

48. March 11, 2004T. Scott Ankrum — MITRE48 Extensions to Tool Extend ASCE features to be more helpful Make ACSE more generic Enhance possibilities for user customization

49. March 11, 2004T. Scott Ankrum — MITRE49 Shadow a Real Project Activities –Document a real process –Identify where and how to incorporate technique Advantages –Learning opportunity for us –Minimal impact on the project –Not in the project’s critical path

50. March 11, 2004T. Scott Ankrum — MITRE50 Develop Training How to use the notation and notation options How to develop a structured assurance case How changes affect the assurance case –Software, hardware –Operation, environment How to write a structured assurance standard

51. March 11, 2004T. Scott Ankrum — MITRE51 Use on a Real Project Apply methdology within a project’s schedule Gain experience with maintenance of assurance cases Update process with lessons learned Propagate this knowledge to other projects

52. March 11, 2004T. Scott Ankrum — MITRE52 Discussion