Common Criteria Cleared for Take Off at the FAA
by Debra S. Herrmann
Introduction The National Information Assurance Acquisition Policy, NSTISSP #11, was issued
January 2000. This policy recommended (by January 2001), and then mandated (by July
2002) the use of Common Criteria evaluated products in national security systems. The
phrase “national security systems” is interpreted to include critical infrastructure systems,
like the nation’s air traffic control and management systems for which the U.S. Federal
Aviation Administration (FAA) is responsible, especially since the events of September
Since then federal agencies and industry have been dealing with three challenges:
(1) How to inject the Common Criteria into the federal acquisition process; federal
agencies procure systems, not “black boxes.”
(2) How to integrate the Common Criteria into the system engineering lifecycle; most
agencies have a well defined system engineering lifecycle with associated
milestones and documentation requirements.
(3) How to integrate the results of Common Criteria security evaluations into the
system security certification and accreditation (C&A) process, such as NIST SP
FAA undertook the Protection Profile Library project to address these challenges. The
goal was to provide a ready to use set of tools for the Integrated Product Teams (IPTs)
that would allow them to focus on their domain expertise, while the Office of the CIO
provided the Common Criteria expertise. Specifically, the objectives were to create:
(1) Protection Profiles that captured FAA information security requirements for all
(2) Language to incorporate into a Statement of Work (SOW) stating that the vendor
is to implement the security functional requirements and perform the security
assurance requirements cited in the Protection Profile
(3) Data Item Descriptions (DIDs) that explain to industry what documentation is
needed for the evidence produced as a result of performing the security
(4) A requirements traceability matrix (RTM) illustrating the decomposition of
high-level agency information security requirements into low-level requirements
- 1 -
in the Protection Profile.
(5) A chart that maps agency system engineering lifecycle documentation
requirements to the DIDs and Common Criteria artifacts.
Analysis and Approach
To date most agencies have pursued a “bottom-up” approach to implementing the
Common Criteria by writing Protection Profiles for security appliances, such as VPNs or
firewalls. In contrast, the FAA has taken a “top-down” approach for three key reasons.
(1) Need to secure the enterprise. Ultimately what matters is that the enterprise is
secure, not just a single appliance. To illustrate, it is not very reassuring for FAA
to know that there is an EAL 4 certified firewall installed at the Boise, Idaho airport.
Rather, what is important is that the interactions between the collection of
interdependent systems that comprise the U.S. national airspace system (NAS)
operate in a known consistent secure state.
(2) Need to allocate security requirements. The NAS is a safety-critical enterprise
with ultra high safety and reliability requirements. These safety and reliability
requirements are allocated to the various systems and components in the
enterprise. Consequently, it is only logical for security requirements to be
allocated as well.
(3) Need to specify implementation independent security requirements. The
Common Criteria methodology asserts that a Protection Profile is a collection of
implementation independent requirements. By stating that a Protection Profile is
for a VPN or firewall the customer has imposed a design solution with the
associated constraints and limitations. Instead, FAA generated implementation
independent security requirements so that system developers or vendors could
employ the maximum amount of creativity when proposing a security solution.
A nine-step analytical process was followed to generate the low-level requirements, as
shown in Figure 1.
- 2 -
Figure 1. Analytical Process for Defining Security Requirements
in the Protection Profile Library.
1.0 NAS-SR-1000 Enhanced high-level Validate high-level security security requirements requirements Quality characteristics
Low-level 2.0 Enhanced high-level SFRs and SARs Derive low-level security requirements requirements
SFRs and SARs 3.0 SFRs and SARs assigned to Allocate low-level security enclaves requirements
SFRs and SARs Tailored 4.0 System risk SFRs and SARs Tailor low-level System criticality requirements
5.0 Tailored Completed dependencies
Resolve SFRs and SARs in Section 5 of PP dependencies
6.0 Completed FMT class Tailor security Sections 1-5 of PP requirements, based on management System risk/criticality requirements
- 3 -
Figure 1. Analytical Process for Defining Security Requirements
in the Protection Profile Library (continued).
Completed FAU class 7.0 Sections 1-5 of PP requirements, based on Tailor security
system risk/criticality audit
FAA specific explicit 8.0 Sections 1-5 of PP requirements for IT and Specify
non-IT environment explicit
Section 6 of PP: 9.0 Sections 1-5 of PP security objectives rationale Validate
security reqts. rationale Low-level
Step 1 - Validate High-level Requirements In the FAA environment NAS-SR-1000, the National Airspace System (NAS)
Requirements Specification, is the top-level specification from which all other system
requirements specifications are derived. In particular Section 3.8.5 specifies the
top-level information security requirements to which all NAS systems must comply.
These requirements were compared against the quality characteristics of requirements
identified in IEEE Std. 830-1998 (clear, complete, concise, consistent, correct,
unambiguous, and verifiable) and a few minor changes were made. The high level
requirements fall into 10 categories:
? level of security functionality and security integrity
? security training
? access control
? security audit
? confidentiality - 4 -
? identification and authentication
? security management
The first category is considered a global requirement and was not further decomposed. The second category, training, is not something that can be specified in an IT security requirements specification. However, the appropriate security assurance requirements are specified to ensure that the necessary documentation is developed to support that training. The remaining eight categories are straightforward and were decomposed.
Step 2 - Derive Low-level Requirements from High-level Requirements
Next the appropriate Common Criteria class, family, and components that corresponded to each high-level requirement were identified, for both security functional requirements (SFRs) and security assurance requirements (SARs). Common Criteria elements did not have to be selected, since they come bundled with components. The ten high-level information security requirements from NAS-SR-1000 3.8.5 were used to construct 10 functional packages (or security subsystems). In other words, all high and low-level access control requirements are assigned to one functional package; all confidentiality requirements are assigned to another functional package, and so forth. This modularity of requirements allows the FAA and the system developer to design, build, and test the 10 functional packages on independent time lines, if desired.
Step 3 - Allocate Security Requirements to Security Enclaves
The FAA information system security architecture is divided into three security enclaves:
? Wide area network (WAN)
? Local area network (LAN)/Facility communications
? Application systems
The enclaves are delineated by geography as well as the protocol stack (See Table 1).
Each enclave is responsible for boundary protection, the security functions provided within the enclave and the integrity of those functions, and controlling what information enters and exits the enclave. Each enclave is subject to dissimilar threats and vulnerabilities. As a result, different countermeasures are deployed at various layers of the protocol stack. The allocation of security requirements to security enclaves was made based on the applicability of each low-level requirement to the ISO/OSI reference model layer and the associated technology. Not all low-level requirements were applicable to all three security enclaves. Some requirements apply to all three enclaves; others only apply to a single enclave. As an example rollback (FDP_ROL) is only applicable to application systems; neither the WAN nor LAN/facility communications enclaves can perform this function
- 5 -
Table 1 - Delineation of Security Enclaves ISO/OSI WAN LAN/Facility Application
Reference Model Communications Systems
Layer 1 - physical x x
Layer 2 - data link x x
Layer 3 - network x x
Layer 4 - transport x
Layer 5 - session x
Layer 6 - presentation x
Layer 7 - application x
Step 4 - Tailor Low-level Requirements Based on System Risk and Criticality NAS-SR-1000 defines three categories of system criticality; most federal agencies have
similar system criticality ratings.
Critical: Functions or services which, if lost, would prevent the NAS from
exercising safe separation and control over aircraft.
Essential: Functions or services which, if lost, would reduce the capability of the
NAS to exercise safe separation and control over aircraft.
Routine: Functions or services which, if lost, would not significantly degrade the
capability of the NAS to exercise safe separation and control over aircraft.
These definitions can be translated into measures of robustness and resiliency for the
key security features of confidentiality, integrity, and availability, as shown in Table 2.
FIPS PUB 199 defines three levels of system risk: high, moderate, and low. The high
risk definition corresponds to a NAS-SR-1000 critical system. The definition for
moderate risk corresponds to a NAS-SR-1000 essential system, and the definition for low
risk corresponds to a NAS-SR-1000 routine system.
Table 2. Correlation of System Criticality and System Risk
NAS-SR-1000 Security Robustness/Resilience FIPS PUB 199 Security System System Integrity Criticality Risk Low Moderate High
Critical Confidentiality Availability High EAL 3+
Essential Confidentiality Availability Moderate EAL 3+
Routine Confidentiality Availability Low EAL 2+
- 6 -
Tailoring resulted in a lower number of requirements and less rigorous requirements for
moderate and low risk systems. High risk/critical systems were assigned EAL 3 with
extensive augmentation. Moderate risk/essential systems were assigned EAL 3 with Integrity
minor augmentation. Low risk/routine systems were assigned EAL 2 with minor
augmentation. Table 3 summarizes the allocation of low-level security requirements by
security enclave and system risk and criticality. Table 4 illustrates the requirements
decomposition and tailoring by system risk and criticality.
Table 3. Low-level Requirements Allocation by Security Enclave
and System Risk/Criticality
High Risk/ Moderate Risk/ Low Risk/ Security Enclave Critical System Essential System Routine System
WAN 72 72 60
LAN/Facility 75 75 60
Application 75 75 66
Step 5 - Resolve Dependencies Among Low-level Requirements
The Common Criteria methodology employs a construct known as dependencies to
ensure that the set of security requirements is comprehensive and complete. A
dependency exists when there is a relationship among one requirement and one or more
other requirements such that the requirement(s) that is depended upon must normally be
included for the other requirement to be achieved. For example, for an authentication
requirement to be achieved, an identification requirement must also be specified.
Dependencies among requirements arise when a component is not self-sufficient and
relies upon the functionality of, or interaction with, another component for its own proper
functioning. In summary, a total of 85 dependencies were identified. The analysis
determined that all but three of them were already satisfied in the set of low-level
requirements. This low number indicates that the set of low-level requirements forms a
cohesive whole. The three unresolved dependencies were covert channel analysis
(AVA_CCA.1), exhaustive covert channel analysis (AVA_CCA.3), and subset information
flow control (FDP_IFC.1). AVA_CCA.1 was added to the EAL 3+ requirements for high
risk/critical systems. However, it was deemed not necessary for moderate risk/essential
systems or low risk/routine systems. AVA_CCA.3 was determined to be overkill for all
three scenarios and not added. FDP_IFC.1 was added to the low-level access control
requirements for low, moderate, and high risk scenarios.
- 7 -
Table 4. Requirements Decomposition by System Risk and Criticality.
Functional High-levHigh Risk Moderate Risk Low Risk Package/ el Class Family CompoClass Family CompoClass Family CompoNAS-SR-1000 Reqts. nent nent nent Reference
I. Security Functional Requirements (SFRs) Level of Security 1 - - - - - - - - - Functionality and Integrity 3.8.5.A Security Training 1 - - - - - - - - - 3.8.5.B Integrity 1 2 14 15 2 14 15 2 13 14 3.8.5.C Availability 1 2 4 4 2 4 4 2 4 4 3.8.5.D Access Control 1 2 7 9 2 7 9 2 7 8 3.8.5.E Security Audit 1 2 7 12 2 7 12 2 7 12 3.8.5.F Confidentiality 1 4 8 11 4 8 11 3 5 5 3.8.5.G Identification and 1 3 10 16 3 10 16 1 6 10 Authentication 3.8.5.H Recovery 1 2 2 3 2 2 3 2 2 3 3.8.5.I Security 1 2 11 16 2 11 16 2 12 16 Management 3.8.5.J Total 10 19 63 86 19 63 86 16 57 72
II. Security Assurance Requirements (SARs) Configuration - 1 3 3 1 2 2 1 1 1 Management (ACM) Delivery and Operation - 1 2 2 1 2 2 1 2 2 (ADO) System Development - 1 4 4 1 4 4 1 3 3 (ADV) Guidance Documents - 1 2 2 1 2 2 1 2 2 (AGD) Lifecycle Support (ALC) - 1 2 2 1 1 1 0 0 0 Tests (ATE) - 1 4 4 1 4 4 1 3 3 Vulnerability - 1 5 5 1 3 3 1 2 2 Assessment (AVA) Maintenance of - 1 4 4 1 4 4 1 4 4 Assurance (AMA) Total - 8 26 26 8 22 22 8 17 27 Evaluation Assurance Level EAL 3+ EAL 3+ EAL 2+
- 8 -
Step 6 - Tailor Security Management Requirements
To bridge the gap between technology and its operation and use, the Common Criteria
methodology employs a construct known as management requirements. The Common
Criteria standard includes management requirements as part of the definition of each
security functional requirement component. Management requirements are for
consideration – they are not mandatory. The definition of each security functional requirement lists 1, 2, 3, or no management actions. The Protection Profile author may
choose to implement one, some, or all of the security management actions listed. When
more than one action is listed in the Common Criteria standard, they are hierarchical.
This approach corresponds to the delineation of high risk/critical systems, moderate
risk/essential systems, and low risk/routine systems. Accordingly, when one
management action is listed, it was applied to all three risk categories. When two actions
are listed, the first one was applied to low risk/routine systems, while the second was
applied to moderate and high risk systems. Lastly, when three management actions are
listed, the first was applied to low risk/routine systems, the first and second were applied
to moderate risk systems, and all three were applied to high risk systems.
Step 7 - Tailor Security Audit Requirements
The Common Criteria standards lists, as part of the description of each security
functional requirement, potential security relevant events that could be audited by the
system. The resolution of audit requirements identifies the extent of auditing, types of
events that are audited, and the set of audit-related information that is captured. There
are three hierarchical options for capturing auditable events; each option includes its
The delineation of minimal, basic, and detailed audit requirements aligns with the
division of low risk/routine systems, moderate risk/essential systems, and high
risk/critical systems. For low risk systems a minimum of security audit information is
necessary. As system risk and criticality increases, more detailed security audit
information is needed. Accordingly, low risk/routine systems were assigned minimal
audit requirements, moderate risk/essential systems were assigned basic audit
requirements, and high risk/critical systems were assigned detailed audit requirements.
An auditable event is captured by invoking the appropriate component in the security
audit generation (FAU_GEN) family:
FAU_GEN.1.1 The TSF shall be able to generate an audit record of the
following auditable events:
(1) Start-up and shutdown of the audit function;
(2) All auditable events for the detailed level of audit.
- 9 -
Likewise, the strength of function (SOF) requirements align with the division of system risk/criticality:
High risk/critical systems are specified as SOF-high.
Moderate risk/critical systems are specified as SOF-medium.
Low risk/routine systems are specified as SOF-basic
Step 8 - Specify Explicit Requirements
The Common Criteria standard supplies a rather complete set of security functional requirements and security assurance requirements. Given the incredibly rapid advancements in IT and the extreme diversity of IT systems and security needs, it would be impossible for any standard to include all of the requisite requirements. As a result, an occasion may arise when an organization needs to specify requirements that are not contained in the standard. The Common Criteria Implementation and Management Board recognized this situation and made a provision for a Protection Profile author to include requirements that are not contained in the Common Criteria standard. This feature is known as explicit requirements. FAA included three explicit requirements in the Protection Profiles in the library. One explicit requirement was specified for the IT environment, such that the IT environment shall support the enterprise-wide cryptographic infrastructure. An explicit requirement was specified for the non-IT environment, stating how often security audit records shall be reviewed and retained, on-line and offline. Another explicit requirement concerns how quickly access control rights and privileges shall be implemented and/or revoked by a system administrator.
Step 9 - Validate Low-level Requirements
Lastly, Section 6, the Rationale, was generated and the Protection Profiles in the library were subjected to an informal review by a Common Criteria Testing Laboratory. They are currently undergoing a formal evaluation and certification.
The Rationale proves that the set of security functional requirements and security assurance requirements specified in Section 5 of the Protection Profile are a complete, correct, consistent, coherent, and cohesive whole. The Rationale demonstrates that a system that conforms to the Protection Profile will provide a set of IT security countermeasure that are effective within the specified operational environment. The security objectives rationale presents evidence to demonstrate that stated security objectives are traceable and suitable to cover all identified assumptions, threats, and security policies. The security requirements rationale presents evidence to demonstrate that the stated security requirements are traceable and suitable to satisfy all security objectives. Both rationales prove that as a whole the security objectives and security requirements are necessary, appropriate, and sufficient.
The cost, schedule, and technical benefits from generating a Protection Profile rationale and having the Protection Profiles certified are significant. Several studies conducted
- 10 -