DOC

Common Criteria Cleared for Take Off at the FAA

By Leslie Harper,2014-04-15 03:47
9 views 0
High-level Design (ADV_HLD). - System Design Document. - Requirements Traceability (ADV_RCR), - Requirements Traceability Matrix

    Common Criteria Cleared for Take Off at the FAA

    by Debra S. Herrmann

    Introduction The National Information Assurance Acquisition Policy, NSTISSP #11[10], 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

    2001.

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

    800-37[9].

Goals

    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

    operational scenarios.

    (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

    assurance requirements

    (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

     A

    - 3 -

    Figure 1. Analytical Process for Defining Security Requirements

    in the Protection Profile Library (continued).

     A

     Completed FAU class 7.0 Sections 1-5 of PP requirements, based on Tailor security

     system risk/criticality audit

     requirements

     FAA specific explicit 8.0 Sections 1-5 of PP requirements for IT and Specify

     non-IT environment explicit

     requirements

     Section 6 of PP: 9.0 Sections 1-5 of PP security objectives rationale Validate

     security reqts. rationale Low-level

     requirements

    Step 1 - Validate High-level Requirements In the FAA environment NAS-SR-1000, the National Airspace System (NAS)

    Requirements Specification[7], 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[3] (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

    ? integrity

    ? availability

    ? access control

    ? security audit

    ? confidentiality - 4 -

    ? identification and authentication

    ? recovery

    ? 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[8] 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+

    Integrity

    Essential Confidentiality Availability Moderate EAL 3+

    Integrity

    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

    Communications

    Application 75 75 66

    System

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

    predecessor:

    ? minimal

    ? basic

    ? detailed

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 -

Report this document

For any questions or suggestions please email
cust-service@docsford.com