The DoD Instruction 8510
The DoD Instruction 8510 introduces DIACAP (DoD Information Assurance Certification & Accreditation Program) which establishes a process to manage the implementation of 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 NSTISSP #11 guidelines for IA and IA -enabled products. NSTISSP #11 mandates both FIPS 140-2 and Common Criteria for Commercial-Off-The-Shelf (COTS) security related products.
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.
IA Product Evaluation and DIACAP Evaluation. The DIACAP validation of a DoD IS consists of a single IA -enabled product or solution (e.g., an IA-enabled database management system), and 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.|
Artifacts. System policies, documentation, plans, test procedures, test results, and other evidence that expresses 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)).
220.127.116.11. 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.
18.104.22.168. 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.
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.
E22.214.171.124.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.
E126.96.36.199.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:
E188.8.131.52. 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.
E184.108.40.206. 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.
E220.127.116.11. 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.
NSTISSP #11 – National Information Assurance Acquisition Policy
This document specifies both FIPS 140-2 and Common Criteria:
NSTISSP (National Security Telecommunications and Information Systems Security Policy) was developed as a result of the new threats and technological advances over the past ten years. Because of these new threats, there has been an increasing amount of Commercial-Off-The-Shelf (COTS) security related products that are readily available to take the place of the traditional NSA-developed and produced communications security equipment (Government-Off-The-Shelf or GOTS). The US Government is purchasing COTS products instead of GOTS products and therefore had to implement a system for ensuring the security of the products that they are purchasing.
There are three different validations that products can receive:
- The International Common Criteria for Information Security Technology Evaluation Mutual Recognition Arrangement;
- The National Security Agency (NSA)/National Institute of Standards and Technology (NIST) National Information Assurance Partnership (NIAP) Evaluation and Validation Program; or
- The NIST Federal Information Processing Standard (FIPS) validation program.
Effective January 1, 2001 preference must be given to COTS IA and IA-enabled IT products that have been evaluated and validated by any of the three evaluations listed above. Effective July 1, 2001 all products purchased by the government must have evaluated against the three evaluations listed above as they apply to the specific products. It is the responsibility of the Head of the U.S. Department or the Agency to ensure that the products purchased are validated as indicated in this policy.
NIST Special Publication 800-23
This document specifies both FIPS 140-2 and Common Criteria:
The NIST Special Publication 800-23 directive was written by NIST, and containing guidelines for Federal organizations concerning purchasing or acquiring security-related Information Technology (IT) products. The guidelines cover what Federal agencies need to know about computer security assurance and how computer security assurance is provided.
Computer security assurance provides confidence that security measures work as they are intended. Assurance also has different levels which can be supported through conformance testing, security evaluation, and trusted development methodologies.
There are two programs specifically called out in the SP 800-23 directive that are important in testing commercial products. They are 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 selecting a product 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 that has a lower FIPS level or EAL should not be chosen. Similarly, a low risk environment will not necessarily need a product that is evaluated for high risk environments.
Lastly, before selecting a product, a federal agency or department must consider the entire system. If an agency purchases a product that has been evaluated for high risk environments, it does not necessarily mean that the system will be secure for high risks. If the products do not integrate together securely, then the system is only as secure as the weakest connection because it only takes a single vulnerability to compromise a system.