CCS Federal Directives

The DoD Instruction 8510

The DoD Instruction 8510 introduces DIACAP (DoD Information Assurance Certification & Accreditation Program) which establishes a process of implementation management for IA capabilities and services. and provides visibility of accreditation decisions regarding the operation of DoD Information Systems (ISs). This instruction formally replaces DITSCAP.

DIACAP was set up by the Office of the Assistant Secretary of Defense as a more interoperable IA accreditation process than NIACAP, which grew from FISMA. DIACAP specifies that products meet CNSSP #11 guidelines for IA and IA -enabled products. CNSSP #11 mandates both FIPS 140-2 and Common Criteria for Commercial-Off-The-Shelf (COTS) security related products.

View the DoD Instruction 8510

Section 4.8
“The accreditation status and supporting DIACAP Package of DoD ISs shall be made available to interconnecting ISs, if requested, to support DAA accreditation decisions and to the Office of the IG DoD for audit and Federal Information Security Management Act (FISMA) assessment purposes.”

Section 6.5
IA Product Evaluation and DIACAP Evaluation. The DIACAP validation of a DoD IS that consists of a single IA -enabled product or solution (e.g., an IA-enabled database management system) may also serve as the IA-enabled product evaluation. These conditions are reiterated in Table T3.

Table T3. IA Product Evaluation & DIACAP Evaluation
Condition Acceptable Evaluation/Validation Approach
Accreditation boundary includes both IT products or services and IA or IA -enabled IT products. 1. National Security Telecommunications and ISs Security Policy No.11 (Reference (t)) evaluation for IA and IA -enabled products; and2. DIACAP for overall system design and configuration.
Proposed accreditation boundary includes ONLY a single IT product or service that is IA -enabled and nothing else. DIACAP validation is sufficient; separate Reference (t) evaluation is not required.

Section E2.4
Artifacts. System policies, documentation, plans, test procedures, test results, and other evidence that express or enforce the information assurance (IA) posture of the DoD IS, make up the certification and accreditation (C&A) information, and provide evidence of compliance with the assigned IA controls.

The DoD Wireless Directive 8100

The Wi-Fi directive encompasses all the requirements of IEEE 802.11i including FIPS 140-2 validation. The document mandates that wireless devices be compliant with DoD 8500.1 and 8500.2, both of which specify FIPS 140-2 and Common Criteria as part of their requirements. In 2006, the DoD released a supplemental policy which specified the use of Common Criteria for WLAN devices.

4.1. Wireless devices, services, and technologies that are integrated or connected to DoD networks are considered part of those networks, and must comply with DoD Directive 8500.1 (reference (d)) and DoD Instruction 8500.2 (reference (e)) and be certified and accredited in accordance with DoD Instruction 5200.40 (reference (f)). In addition:

4.1.2. Encryption of unclassified data for transmission to and from wireless devices is required. Exceptions may be granted on a case-by-case basis as determined by the Designated Approving Authority (DAA) for the wireless connections under their control. At a minimum, data encryption must be implemented end-to-end over an assured channel and shall be validated under the Cryptographic Module Validation Program as meeting requirements per Federal Information Processing Standards (FIPS) Publication (PUB) 140-2, Overall Level 1 or Level 2, as dictated by the sensitivity of the data (reference (g)).

4.1.2.1. Encrypting unclassified voice is desirable; voice packets across an Internet protocol (e.g., VoIP) shall use encryption that is validated as meeting FIPS 140-2 requirements.

4.1.2.2. For data at rest, PEDs shall use file encryption that is validated as meeting FIPS 140-2 requirements. Individual exceptions may be granted on a case-by-case basis as determined by the DAA.

4.4. Pursuant to subparagraph 4.1.2., DAAs shall ensure that Wireless Personal Area Network (WPAN) capability is removed or physically disabled from a device unless FIPS PUB 140-2-validated cryptographic modules are implemented (reference (g)). Exceptions may be granted on a case-by-case basis as determined by the DAA.

View the Wi-Fi Directive

The DoD Directive 8500.2

This document specifies both FIPS 140-2 and Common Criteria:

5.6. The Director, National Security Agency shall:

5.6.3. Generate Protection Profiles for IA and IA-enabled IT products used in DoD information systems based on Common Criteria (reference (j)), and coordinate the generation and review of these Profiles within the National Information Assurance Partnership (NIAP) framework.

E3.2.4.3.3. Medium robustness security services and mechanisms provide for additional safeguards above Basic. Medium robustness technical solutions require, at a minimum, strong (e.g., crypto-based) authenticated access control, NSA-approved key management, NIST FIPS-validated cryptography, and the assurance properties as specified in NSA-endorsed medium robustness protection profiles or the Protection Profile Consistency Guidance for Medium Robustness.

E3.2.4.3.4. Basic robustness security services and mechanisms are usually represented by good commercial practice. Basic robustness technical solutions require, at a minimum, authenticated access control, NIST-approved key management algorithms, NIST FIPS-validated cryptography, and the assurance properties specified in NSA-endorsed basic robustness protection profiles or the Protection Profile Consistency Guidance for Basic Robustness.

E3.2.5. Product Specification and Evaluation. At the enterprise level, implementation-independent specifications for IA and IA-enabled IT products are provided in the form of protection profiles. Protection profiles are developed in accordance with the Common Criteria (reference (j)) within the NIAP framework. Regardless of the mission assurance category or confidentiality level of the DoD information system, all incorporated IA products, and IA-enabled IT products that require use of the product’s IA capabilities, acquired under contracts executed after July 1, 2002, shall comply with the evaluation and validation requirements of NSTISSP No. 11 (reference (ah)), with the following qualifications:

E3.2.5.1. If an approved U.S. Government protection profile exists for a particular technology area and there are validated products available for use that match the protection profile description, then acquisition is restricted to those products; or to products that vendors, prior to purchase, submit for evaluation and validation to a security target written against the approved protection profile. Products used within the Department of Defense may be submitted for evaluation at evaluation assurance levels (EALs) 1-7 through the NIAP Common Criteria Evaluation and Validation Scheme (CCEVS). Alternatively, the United States recognizes products that have been evaluated under the sponsorship of other signatories and in accordance with the International Common Criteria for Information Security Technology Evaluation Recognition Arrangement (CCRA) for EALs 1-4 only.

E3.2.5.2. If an approved U.S. Government protection profile exists for a particular technology area, but no validated products that conform to the protection profile are available for use, the acquiring organization must require, prior to purchase, that vendors submit their products for evaluation and validation by a NIAP EVP or CCRA laboratory to a security target written against the approved protection profile or acquire other U.S.-recognized products that have been evaluated under the sponsorship of other signatories to the CCRA.

E3.2.5.3. If no U.S. Government protection profile exists for a particular technology area and the acquiring organization chooses not to acquire products that have been evaluated by the NIAP CCEVS or CCRA laboratories, then the acquiring organization must require, prior to purchase, that vendors provide a security target that describes the security attributes of their products, and that vendors submit their products for evaluation and validation at a DAA-approved EAL. Robustness requirements, mission, and customer needs will together enable an experienced information systems security engineer to recommend a specific EAL for a particular product to the DAA.

View the DoD 8500.2 Directive

CNSSP #11 – Committee for National Security Systems Policy

This document specifies both FIPS 140-2 and Common Criteria:

On June 10, 2013 the CNSS (Committee for National Security Systems) published CNSS Policy No. 11 (CNSSP #11) to supersede NSTISSP #11 to clarify the evaluation process for COTS and GOTS IA and IA-enabled IT products.

NSTISSP (National Security Telecommunications and Information Systems Security Policy) NSTISSP #11 was effective from January 1, 2001 to June 10,2013. NSTISSP #11 allowed the US government to take advantage of the increased amount of Commercial-Off-The-Shelf (COTS) security related products that were readily available to take the place of NSA-developed and produced communications security equipment (Government-Off-The-Shelf or GOTS). This represented a shift to purchase COTS products rather than GOTS products and necessitating implementation of a system to ensure the security of the products they purchase.

CNSSP #11 continues the emphasis on purchasing of COTS products and states that layered COTS product solutions (e.g., selecting two or more IA and IA-enabled IT products), when available, are preferred to meet an organization’s requirements.  Also, GOTS products shall only be acquired or developed if an existing COTS IA and IA-enabled IT product solution is not available to meet that organization’s requirements.  The Heads of U.S. Government Departments and Agencies are required to select the evaluated and validated COTS IA and IA-enabled IT products from the PCL (Product Compliant List).  However, currently the National Information Assurance Partnership (NIAP) has defined the PCL to include:

  • all products on the PCL as being on the NIAP website,
  • all products on NIAP’s Validated Products List (VPL),
  • all products on the Common Criteria Portal.

In other words, the PCL referenced in CNSSP #11 includes all currently evaluated and mutually recognized products worldwide. NIAP is responsible for the eventual transition from recognizing products on all three lists shown above to just the NIAP PCL.  The PCL will be maintained by NIAP to include all COTS IA and IA-enabled IT products that have been evaluated and validated against a NIAP approved Protection Profile.

View the CNSSP #11

NIST Special Publication 800-23

This document specifies both FIPS 140-2 and Common Criteria:

The NIST Special Publication 800-23 is a directive written by NIST that contains guidelines for Federal organizations concerning the purchase or acquisition of security-related Information Technology (IT) products. The guidelines deal primarily with what Federal agencies need to know about computer security assurance and how it is provided.

This document specifies both FIPS 140-2 and Common Criteria:

The NIST Special Publication 800-23 is a directive that was written by NIST containing guidelines for Federal organizations concerning purchasing or acquiring security-related Information Technology (IT) products. The guidelines deal mainly with what Federal agencies need to know about computer security assurance and how computer security assurance is provided.

View the SP 800-23 Publication

Computer security assurance provides confidence that security measures work as intended. Assurance also has different levels supported through conformance testing, security evaluation, and trusted development methodologies.

Two programs specifically called out in the SP 800-23 directive are important in testing commercial products, the National Information Assurance Program (NIAP) Common Criteria Evaluation and Validation Program and NIST’s Cryptographic Module Validation Program (CMVP). NIAP is the U.S. CC scheme and CMVP is a program run jointly by NIST and the Canadian Security Establishment (CSE) for evaluating products against the FIPS 140-2 standard. Corsec specializes in both of these validations and offers classes to explain the procedures of successfully completing the validations.

Another important aspect of product selection is finding one that meets the security needs of the entire system. NIST SP 800-23 provides guidance on selecting the appropriate level of validation. If a system is considered to be a high risk environment, a product with a lower FIPS level or EAL should not be chosen. Similarly, a low risk environment will not necessarily require a product evaluated for high risk environments.
Before selecting a product, a federal agency or department must consider the entire system. If agency purchases products evaluated for high risk environments, it does not necessarily mean that the system will be secure against high risks. If the products do not integrate together securely, the system is only as secure as the weakest connection because it only takes a single vulnerability to compromise an entire system.