Standards in Safety and Security for Avionics

Alessandro Bruni, 08/11/2012

A Plethora of Standards

Concerning either:

1. Security

2. Safety

w.r.t.

3. Item development/evaluation

4. System development/evaluation

What we'll see here

1. DO-178B: SW development process

2. Safety Case Analysis

3. Common Criteria for Security

DO-178B

Objective Based:

"Objectives and activities that must be met or performed to earn certification for the software product."

5 Design Assurance Levels (DALs):A. Catastrophic

B. Hazardous/Severe-Major

C. Major

D. Minor

E. No EffectFrom: Verification of Safety-Critical Software by B. Scott Andersen And George Romanski, Oct 2011

Assurance Levels and Risk

Software Engineering 101

"Most accidents are not the result of unknown scientific principles but rather of a failure to apply well-known,

standard engineering practices."

How to apply good practices?

1. PSAC (Plan for Software Aspects of Certification)

2. SDP (Software Development Plan)

3. SVP (Software Verification Plan)

4. SCMP (Software Configuration Management Plan)

5. SQAP (Software Quality Assurance Plan)

No Surprises

Safe:identification of the potential hazards, their likelihood and the effectiveness of the countermeasures

Strong requirements:multiple levels of requirements at different abstraction levels

No unintended function:only what is specified should be present, no dead code, no hidden features

Traceable:requirements and other project artifacts (eg. source code) are mapped through a navigable relationship between two or more items

Requirements

A Good Requirement:

a. compliance with system requirements,

b. accuracy and consistency,

c. compatibility with the target computer,

d. verifiability,

e. conformance to standards,

f. traceability, and

g. algorithmic aspects

Must have:1. Requirement ID2. Version ID3. Author4. Reviewer

Development Process

1. No prescribed SW life-cyclenot necessarily

waterfall to be successful

2. Reverse engineeringmay be applied to produce

necessary documentation

3. Reviews and independenceseparation of

responsibilities

(DO-178B does not specify how reviews must be done)

Validation and Verification

Validation "Are we building the right product?"

design error, comment error, documentation error,error-handling

problems, test errors, structural coverage problems,

modified functionality, requirements errors, code errors

Verification "Are we building the product right?"

1. requirements based tests

2. analysis (delivers document providing the evidence of correctness)

3. formal methods

4. exhaustive input testing (for small models)

5. structural coverage analysis (dead code vs. deactivated code)

Obtaining a Certificate

In the U.S. the certification authority is the FAA, but the FAA delegates its responsibilities to a system of DERs (designated engineering representatives).

DER's Stages of Involvement:o SOI-1:

o to ensure that there is a plan for certification everyone agrees on

o SOI-2:o reviews any open issues from the first meeting

o done at 50% of the project

o SOI-3:o takes place when 50% of the verification is complete

o SOI-4:o to assess the readiness of the package for certification

o done when all certification evidence has been produced

Thoughts from the DO-178C CommitteeD. Daniels, Verocel Ltd.

DO-178B: represented consensus of the avionics community as of 1992

DO-178C: a series of addenda addressing formal methods, object-oriented technology, model based design and verification, tool qualification.

Formal methods don't have certification credit yet.

Goal based standard: avoids checklist mentality

Not an aspirational standard!Does not try to advance the state of engineering practices, rather tries to reach an agreement between current practices.

The Safety Case

Safety case: a clear, comprehensive and defensible argument that a system is acceptably safe to operate in a

particular context.

Important aspects:1. argument

2. clarity

3. system level

4. acceptable

5. context

From: A systematic approach to Safety Case Management, Tim Kelly, University of York, 2003

Safety Case Report1. Scope

2. System Description

3. System Hazards

4. Safety Requirements

5. Risk Assessment

6. Hazard Control / Risk Reduction Measures

7. Safety Analysis / Test

8. Safety Management System

9. Development Process Justification

10.Conclusions

process safety argument}

product safety argument}

Goal Structuring Notation

Lifecycle

Evolving Safety Arguments, during the whole software development lifecycle

Common Criteriafor IT Security Evaluation

1. Huge collection of security criteria

2. Useful for:a. software developers

b. testers

c. evaluators

3. Highly customizable

Part 1: Introduction and General Model

Assets and Countermeasures

Evaluation

Security Requirements

Library of template requirements, better specified by:

1. Iteration

2. Assignment

3. Selection

4. Refinement

Part 2: Security Functional Components

Families:

Classes:

Components:

Organized in

Protection Profiles:Sets of families tailored for certain software products (e.g. firewalls)

Classes

FAU: Security Audit

FCO: Communication

FCS: Cryptographic support

FDP: User Data Protection

FIA: Identification and Authentication

FMT: Security Management

FPR: Privacy

FPT: Protection of the TSF

FRU: Resource Utilization

FTA: TOE Access

FTP: Trusted Path/Channels

Part 3 : Security Assurance Components

Assurance levels:

Families, components and levels

Packages!

..instantiated:

EAL1: Functionally tested

EAL2: Structurally tested

EAL3: Methodically tested and checked

EAL4: Methodically designed, tested and reviewed

EAL5: Semiformally designed and tested

EAL6: Semiformally verified design and tested

EAL7: Formally verified design and tested

Classes

Composed Assurance Packages

CAP A: Structurally composedOnly requires cooperation of the developer of the independent component.

Composed Assurance Packages

CAP A: Structurally composedOnly requires cooperation of the developer ofthe independent component.

CAP C: Methodically composed, tested, reviewedMax assurance from rigorous analysis of interaction without full access to evaluation evidence of base components

Composed Assurance Packages

CAP A: Structurally composedOnly requires cooperation of the developer of the independent component.

CAP B: Methodically composedDeveloper gains max assurance under interaction between components, minimising involvment of component developer

CAP C: Methodically composed, tested, reviewedMax assurance from rigorous analysis of interaction without full access to evaluation evidence of base components

Thanks for the attention :)