Standards for safety and security in avionics


Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Standards for safety and security in avionics

  1. 1. Standards in Safety andSecurity for Avionics Alessandro Bruni, 08/11/2012
  2. 2. A Plethora of StandardsConcerning either:1. Security2. Safetyw.r.t.3. Item development/evaluation4. System development/evaluation
  3. 3. What well see here1. DO-178B: SW development process2. Safety Case Analysis3. Common Criteria for Security
  4. 4. 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
  5. 5. Assurance Levels and Risk
  6. 6. 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)
  7. 7. No SurprisesSafe: identification of the potential hazards, their likelihood and the effectiveness of the countermeasuresStrong requirements: multiple levels of requirements at different abstraction levelsNo unintended function: only what is specified should be present, no dead code, no hidden featuresTraceable: requirements and other project artifacts (eg. source code) are mapped through a navigable relationship between two or more items
  8. 8. RequirementsMust have:1. Requirement ID2. Version ID3. Author4. 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
  9. 9. Development Process1. No prescribed SW life-cyclenot necessarily waterfall to be successful2. Reverse engineeringmay be applied to produce necessary documentation3. Reviews and independenceseparation of responsibilities (DO-178B does not specify how reviews must be done)
  10. 10. Validation and VerificationValidation "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 errorsVerification "Are we building the product right?"1. requirements based tests2. analysis (delivers document providing the evidence of correctness)3. formal methods4. exhaustive input testing (for small models)5. structural coverage analysis (dead code vs. deactivated code)
  11. 11. Obtaining a Certificate In the U.S. the certification authority is the FAA, but the FAA delegates itsresponsibilities to a system of DERs (designated engineering representatives).DERs Stages of Involvement:o SOI-1: o to ensure that there is a plan for certification everyone agrees ono SOI-2: o reviews any open issues from the first meeting o done at 50% of the projecto SOI-3: o takes place when 50% of the verification is completeo SOI-4: o to assess the readiness of the package for certification o done when all certification evidence has been produced
  12. 12. Thoughts from the DO-178C CommitteeD. Daniels, Verocel Ltd.DO-178B: represented consensus of the avionicscommunity as of 1992DO-178C: a series of addenda addressing formal methods,object-oriented technology, model based design andverification, tool qualification. Formal methods dont have certification credit yet.Goal based standard: avoids checklist mentalityNot an aspirational standard!Does not try to advance the state of engineering practices, rather tries to reachan agreement between current practices.
  13. 13. 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. contextFrom: A systematic approach to Safety Case Management, Tim Kelly, University of York, 2003
  14. 14. Safety Case Report1. Scope2. System Description3. System Hazards4. Safety Requirements5. Risk Assessment } product safety argument6. Hazard Control / Risk Reduction Measures7. Safety Analysis / Test } process safety argument8. Safety Management System9. Development Process Justification10.Conclusions
  15. 15. Goal Structuring Notation
  16. 16. LifecycleEvolving Safety Arguments, during the whole software development lifecycle
  17. 17. Common Criteria for IT Security Evaluation1. Huge collection of security criteria2. Useful for: a. software developers b. testers c. evaluators3. Highly customizable
  18. 18. Part 1: Introduction and General ModelAssets and Countermeasures
  19. 19. Evaluation
  20. 20. Security RequirementsLibrary of template requirements, betterspecified by:1. Iteration2. Assignment3. Selection4. Refinement
  21. 21. Part 2: Security Functional Components Classes:Organized in Families: Components:Protection Profiles:Sets of families tailored for certain softwareproducts (e.g. firewalls)
  22. 22. ClassesFAU: Security AuditFCO: CommunicationFCS: Cryptographic supportFDP: User Data ProtectionFIA: Identification and AuthenticationFMT: Security ManagementFPR: PrivacyFPT: Protection of the TSFFRU: Resource UtilizationFTA: TOE AccessFTP: Trusted Path/Channels
  23. 23. Part 3 : Security Assurance ComponentsFamilies, components and levels Assurance levels: Packages!
  24. 24. Classes ..instantiated:EAL1: Functionally testedEAL2: Structurally testedEAL3: Methodically tested andcheckedEAL4: Methodically designed, testedand reviewedEAL5: Semiformally designed andtestedEAL6: Semiformally verified design andtestedEAL7: Formally verified design andtested
  25. 25. Composed Assurance PackagesCAP A: Structurally composedOnly requires cooperation of the developer of theindependent component.
  26. 26. Composed Assurance PackagesCAP A: Structurally composedOnly requires cooperation of the developer oftheindependent component.CAP C: Methodically composed, tested,reviewedMax assurance from rigorous analysis ofinteraction without full access to evaluationevidence of base components
  27. 27. Composed Assurance PackagesCAP A: Structurally composedOnly requires cooperation of the developer of theindependent component.CAP C: Methodically composed, tested,reviewedMax assurance from rigorous analysis ofinteraction without full access to evaluationevidence of base componentsCAP B: Methodically composedDeveloper gains max assurance under interactionbetween components, minimising involvment ofcomponent developer
  28. 28. Thanks for the attention :)