Standards for safety and security in avionics
?
1 like?3,158 views
1. The document discusses several standards related to avionics safety and security, including DO-178B for software development processes, safety case analysis, and the Common Criteria for security evaluation. 2. DO-178B defines 5 design assurance levels (DALs) from A to E based on the level of risk. It also requires objective-based development, requirements traceability, and verification and validation plans. 3. Safety cases evaluate the safety argument and risk reduction measures through a structured report. The Common Criteria provides a framework for defining and evaluating security requirements and components through protection profiles, classes, and assurance levels.
Standards for safety and security in avionics
- 1. Standards in Safety and Security for Avionics Alessandro Bruni, 08/11/2012
- 2. A Plethora of Standards Concerning either: 1. Security 2. Safety w.r.t. 3. Item development/evaluation 4. System development/evaluation
- 5. What we'll see here 1. DO-178B: SW development process 2. Safety Case Analysis 3. Common Criteria for Security
- 6. 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 Effect From: Verification of Safety-Critical Software by B. Scott Andersen And George Romanski, Oct 2011
- 7. Assurance Levels and Risk
- 8. 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)
- 9. 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
- 10. Requirements Must have: 1. Requirement ID 2. Version ID 3. Author 4. Reviewer 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
- 11. 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)
- 12. 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)
- 13. 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
- 14. Thoughts from the DO-178C Committee D. 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.
- 15. 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
- 16. Safety Case Report 1. Scope 2. System Description 3. System Hazards 4. Safety Requirements 5. Risk Assessment } product safety argument 6. Hazard Control / Risk Reduction Measures 7. Safety Analysis / Test } process safety argument 8. Safety Management System 9. Development Process Justification 10.Conclusions
- 18. Lifecycle Evolving Safety Arguments, during the whole software development lifecycle
- 19. Common Criteria for IT Security Evaluation 1. Huge collection of security criteria 2. Useful for: a. software developers b. testers c. evaluators 3. Highly customizable
- 20. Part 1: Introduction and General Model Assets and Countermeasures
- 21. Evaluation
- 22. Security Requirements Library of template requirements, better specified by: 1. Iteration 2. Assignment 3. Selection 4. Refinement
- 23. Part 2: Security Functional Components Classes: Organized in Families: Components: Protection Profiles: Sets of families tailored for certain software products (e.g. firewalls)
- 24. 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
- 25. Part 3 : Security Assurance Components Families, components and levels Assurance levels: Packages!
- 26. Classes ..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
- 27. Composed Assurance Packages CAP A: Structurally composed Only requires cooperation of the developer of the independent component.
- 28. Composed Assurance Packages CAP A: Structurally composed Only requires cooperation of the developer ofthe independent component. CAP C: Methodically composed, tested, reviewed Max assurance from rigorous analysis of interaction without full access to evaluation evidence of base components
- 29. Composed Assurance Packages CAP A: Structurally composed Only requires cooperation of the developer of the independent component. CAP C: Methodically composed, tested, reviewed Max assurance from rigorous analysis of interaction without full access to evaluation evidence of base components CAP B: Methodically composed Developer gains max assurance under interaction between components, minimising involvment of component developer
- 30. Thanks for the attention :)