Assurance%20Case%20Frameworks%20Part%20of%20High%20Confidence%20Software%20MSR

1
Assurance Case FrameworksPart of High
Confidence Software MSR

• T. Scott Ankrum
• MITRE Software Engineering Center
• March 11, 2004

2
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
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
What Is an Assurance Case?
5
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
Definition of Safety Case

• From Adelards 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
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 systems
  properties are adequately justified for a given
  application in a given environment.

8
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 well refer to them as assurance
  cases

9
Structuring an Assurance Case
10
Elements of an Assurance Case

• Claims
• Arguments
• Evidence
• Other elements, depending on notation

11
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
Arguments in Assurance Cases

• Link evidence to claims via inference rules
• Deterministic defined rules gt 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
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
Problems With Assurance Cases
15
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
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
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
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
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
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
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
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
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
Choosing a Tool
25
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
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
Notations Considered

• Toulmin Structures
• Stephen Toulmin, The Uses of Argument, 1958
• Goal Structuring Notation
• Described in Tim Kellys dissertation, York, 1998
  
• ASCAD (Claims-Arguments-Data)
• ESPRIT SHIP project headed by Adelard
• Proprietary

28
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
Structuring Selected Standards
31
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
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

33
(No Transcript)
34
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
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
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

37
(No Transcript)
38
(No Transcript)
39
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

40
(No Transcript)
41
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

42
(No Transcript)
43
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
Conclusions and Follow-on
45
Ada Lovelace
46
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
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
Extensions to Tool

• Extend ASCE features to be more helpful
• Make ACSE more generic
• Enhance possibilities for user customization

49
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 projects critical path

50
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
Use on a Real Project

• Apply methdology within a projects schedule
• Gain experience with maintenance of assurance
  cases
• Update process with lessons learned
• Propagate this knowledge to other projects

52
Discussion