The Transition from DO178B Certification to CC Evaluation

1
The Transition from DO-178B Certification to CC
Evaluation

• Dr. Jim Alves-Foss
• University of Idaho

2
University of Idaho
3
University of Idaho

• Fact Book
• Land Grant University est.1889
• Located in Moscow, ID
• pop. 20,000 10,000 students 8 miles from WSU
• One of first 7 of 31 NSA Centers of Academic
  Excellence in Information Assurance
• One of Americas 100 Best College Buys
• Yahoos 13th most wired university
• Distance Education MS and PhD (1 yr residency)
  via Video Tape delivery

4
Overview

• Today we have heard discussion regarding
• DO 178B Evaluation
• What are the requirements
• What is the process
• What are the resulting work products
• Common Criteria Evaluation
• What are the requirements
• What is the process
• What are the resulting work products

5
High-Level Comparison - DO-178B Processes to CC
Classes

• CC Assurance Class DO-178B Area
• ACM Configuration Management Software
  Configuration Management
• ADO Deliver and Operation (No
  Correspondence) elsewhere
• ADV Development Software Development Process
• AGD Guidance Documents (No Correspondence) -
  elsewhere
• ALC Life Cycle Support Software Planning
  Process
• ATE Tests Software Verification Process
• AVE Vulnerability Assessment (No
  Correspondence) testing?

6
Non-mapping CC Classes

• Several CC classes dealing only with security
  issues could not be mapped to any DO-178B
  processes.
• These include
• AGD Guidance Documents
• ADO Delivery and Operation
• AVA Vulnerability Assessment CC

7
Non-mapping CC Classes

• Guidance documents refer to documents
  specifically related to the security aspects of
  administration and operation of the software.
• DO-178B does not address documentation relating
  to just the security aspects of system operation.
  Nor does it address user or management
  documentation directly. This is typically the
  function of the integration requirements for the
  system.

8
Non-mapping CC-classes

• The Delivery and Operation class seeks to insure
  that the software was delivered without
  interference or tampering and that the software
  is installed and initially started securely and
  correctly.
• Again, no corresponding DO-178B process
  components addressed the security aspects of
  tampering and initial start-up. This is typically
  a requirement of integration although FAA looks
  at safety, not necessarily security.

9
Non-mapping CC Classes

• AVA-Vulnerability Assessment
• Vulnerability Assessment deals specifically with
  covert channel analysis, deliberate misuse and
  other security function assessments that are
  absent in DO-178B.
• DO-178B requires structural coverage testing and
  traceability avoiding inclusion of unspecified
  features. Does fault tree analysis encompass
  security vulnerability analysis?
• Specific security requirements can be added to
  the product specification, therefore requiring
  verification.

10
Considerations ...

• Certain considerations in Mapping CC to DO-178B
  need to be addressed ...
• Differences exist between the intended purposes
  of the two documents which are important to the
  final outcome of merging requirements from both
  documents.
• DO-178B is intended to certify that software used
  in aircraft is developed with "best known"
  practices and does not contribute to aircraft
  safety hazards.
• Emphasis in DO-178B
• outlining general policies and procedures to
  produce safe software in terms of airworthiness
  requirements
• produce documentation to substantiate that the
  development requirements have been met.

11
Considerations ...

• Consequently, language and content is high-level
  and abstract
• A lot of compliance decisions are left up to the
  developer
• CC higher EALs require more formalism in product
  requirements, development and analysis.
• This formalism is not required by DO-178B, but
  can be added to specific product requirements
• CC does not explicitly require 100 structural
  coverage testing only of security functions
  (ATE_COV), but this would be a bonus to support
  CC verification.

12
Considerations ...

• CC
• The Common Criteria (CC) is intended to specify
  security requirements that a system, hardware or
  software, must satisfy in order to achieve a
  specific level of assurance.
• The CC only deals with security functionality of
  systems and does not address overall development
  issues except where they affect security.
• CC can be considered guidelines for a subset of
  the system.

13
Considerations ...

• Emphasis in CC
• The CC is a much more detailed document in terms
  of specifying how compliance is achieved for an
  intended product.
• Each component of each assurance class has
  specific action elements and evidence of
  compliance for both developers and evaluators.
• DO-178B is not nearly as prescriptive. Good
  practices, and experience with certification
  authorities are the guidelines.

14
Considerations ...

• Merging CC security requirements into DO-178B
  will need to address these differences in detail
  so that none of the CC functionality is lost.
• Integrating security functionality into the FAA
  certification process needs to be addressed for
  the total system being evaluated, not just the
  software that will be integrated into the
  aircraft since the CC's scope encompasses entire
  systems. This involves other FAA regulations.

15
Considerations ...

• Consequently, a mapping between DO-178B and the
  CC will only constitute part of the process for
  achieving certification by the FAA for a high
  safety level system and by NSA/NIST for a
  high-level assurance system.
• In conclusion...
• the mapping and integration of CC requirements
  will need to be extended beyond DO-178B to
  satisfy CC certification
• Ex. DO-254 is digital hardware equivalent of
  DO-178B.

16
What work products are required for EAL n?
Formal Methods
17
EAL 7 Requirements
Formal Methods
18
Mapping DO-178B to EAL 7

• Formal Methods
• One of the major differences in DO-178B and CC
  EAL7 is the requirement of formal methods in EAL
  7. Specifically this requires the following work
  products
• Formal Security Policy can use existing
  policies
• Formal Functional Specification -- derivable
  from DO-178 documentation
• Formal High-Level Design -- derivable from DO-178
  documentation
• Semi-formal Low-Level Design -- derivable from
  DO-178 documentation
• Formal Correspondence Demonstration partially
  derivable from DO-178B documentation, most
  requires proof efforts

19
Summary of ADV_SPM.3

• Formal TOE Security Policy Model (TSP)
• Developer shall provide TSP model and proof of
  correspondence between TSP model and FSP model.
• Formal model, describe rules and characteristics
  of all policies of TSP that can be modeled with
  consistency and completeness of policies.
• Correspondence to FSP shall be consistent and
  complete (this requires a formal proof of
  correspondence for EAL 7)

20
Security Policy

• An information flow and data separation security
  policy must address
• Exfiltration When the execution of a process
  affects that state of another process. This
  represents flow of information out of the
  executing process to another process due to the
  behavior of the executing process.
• Infiltration When the execution of a process is
  affected by the state of another process. This
  represents the flow of information into the
  executing process from another process due to the
  behavior of the executing process.

21
Formal Policy for a Separation Kernel

• Depends on the context of the separation
• Are processes isolated for safety reasons?
• What is the top-level, abstract view of the
  system?
• How does the system architect view the system for
  purposes of separation and information flow?
• Enclaves or complete separation?
• Interprocess communication?
• What assumptions are made about the environment?

22
Information Flow Example (Architects View)

• Separation security policy enables this view

23
High Level Security Policy Example

• System Model
• Sys(K,P,M,A)
• K is kernel state, P is set of n partition
  states, M is set of m memory blocks, A is access
  control map for memory blocks
• Next(S,S)
• Transition function of full system executing a
  single step of a partition, lets call that
  partition Pc, transits system from state S to
  state S
• Portion of Policy (for every Next(S,S))
• If Mi ? S, Mi ? S and Mi ? Mi then Pc must
  have written Mi and therefore write access for Pc
  to Mi must be in A
• Read access controls are more complex

24
FSP in ACL2

• (defthm separation
• (let ((segs (intersection-equal (dia seg)
• (segs (current st1)))))
• (implies
• (and
• (equal (selectlist segs st1)
• (selectlist segs st2))
• (equal (current st1) (current st2))
• (equal (select seg st1) (select seg
  st2)))
• (equal
• (select seg (next st1))
• (select seg (next st2))))))

25
Summary of ADV-FSP.4

• Formal Functional Specification (TSF)
• Developer provides functional specification
• Description of TSF (TOE Security Functions) and
  external interfaces is formal internally
  consistent, complete.
• Completeness involves
• Method and use of all external TSF interfaces,
  detailing all effects, exceptions, error messages
• Completely represents TSF
• Includes rationale for claim of completeness
• Description used

26
Functional Specification Example

• (defun sm-model (st fsm n)
• (if (zp n) st
• (sm-model (cstep-model st fsm) fsm (1- n))))
• (defun cstep-model (st fsm)
• (DST (find-tr st (FSM-TR fsm)))
• (defun find-tr (st tr-list)
• (if (endp tr-list)
• (make-state-trans src st dst st)
• (if (equal st (SRC (car tr-list))) (car
  tr-list)
• (find-tr st (cdr tr-list)))))

27
Summary of ADV_HLD.5

• Formal High-Level Design (HLD)
• Developer shall provide high-level design of TSF
• Description of TSF structure in terms of
  subsystems that is internally consistent,
  complete
• Identifies and specifies functions of underlying
  hardware, firmware, and/or software required
• Specifies separation of TOE into TSP-enforcing
  and other subsystems
• Identification and justification of mechanisms
  for ensuring separation of TSP-enforcing from
  others

28
Example

• (defun cstep-tps1 (input-m1)
• (if (zerop (counter input-m1))
• (context-switch input-m1)
• (let ((m1 (dec-counter input-m1)))
• (if (equal (current-p m1) 1)
• (update-state 1 (cstep (st1 m1)) m1)
• (update-state 2 (cstep (st2 m1)) m1)))))
• (defun context-switch (m1)
• (let ((new-partition
• (if (equal (current-p m1) 1) 2 1))
• (new-counter (get-quantum new-partition m1))
• (new-quantum-list (get-quantum-list m1)))
• (update-state 0 (list new-counter
  new-partition
• new-quantum-list) m1)))

29
Summary of ADV_RCR.3

• Formal Correspondence Demonstration
• Developer shall provide analysis between adjacent
  pairs of TSF representations formal proof
  requires if pairs are formally specified
• All relevant security functions of more abstract
  representation are correctly and completely
  refined by les abstract representation.
• Analysis is formal/semi-formal, depending on the
  formality of the adjacent pairs.

30
Example

• (defthm equal-sm-no-interference2
• (let ((tr2 (GetTr2 tr)))
• (implies
• (and (is-in tr (FSM-Tr m))
• (FSM-equal (PI2 m) m2)
• (not (equal (SRC tr2) (DST tr2))))
• (is-in tr2 (FSM-tr m2))))
• hints (("Goal" in-theory
• (disable PI2 GetTR2 FSM-equal))))
• (defthm model-exe-preserves
• (and
• (implies (compstate-p s)
• (multi1-p (model-to-exe s)))
• (implies (multi1-p s)
• (compstate-p (exe-to-model s)))))

31
Commuting
High-Level Step
Low Level - High-Level Mapping
Low Level - High-Level Mapping
Low-Level Step
32
Formal Methods Gotchas

• Some difficulties that may occur with FM
• Specifications are models, which necessarily
  abstracts away details.
• Some of these details may be essential resulting
  in incomplete correctness proofs
• Abstractions and models have implicit assumptions
• Must fully document these assumptions
• Must very consistency of assumptions
• Specifications may contain errors
• Must verify specification consistency and
  completeness
• Multiple individuals should validate the
  specifications and theorem statements. Machines
  can check the proofs.

33
Formal Methods Process From Here (where
University of Idaho fits in)

• Obtain and review relevant DO-178B documentation
  from vendor.
• Instantiate Protection Profile for specific
  Security Target.
• Work with vendor to develop Functional
  Specification (TSF).
• Prove correspondence (RCR) between TSF and TSP.
• Work with vendor to develop formal high-level
  design (HLD).
• Prove correspondence between HLD and TSF.

34
Estimated Effort

• Estimated effort 1 person year per 1000 lines of
  kernel code for PhD formal methods mathematician.
• Time frame for 1 RTOS verification complete by
  Sept 2003.
• With student effort the FTEs increase but cost
  decreases.
• Reuse is possible, reducing cost and effort for
  subsequent efforts.