851001p.pdf

Department of Defense

INSTRUCTION

NUMBER 8510.01

November 28, 2007

ASD(NII)/DoD CIO

SUBJECT: DoD Information Assurance Certification and Accreditation Process (DIACAP)

References: (a) Subchapter III of Chapter 35 of title 44, United States Code, “Federal

Information Security Management Act (FISMA) of 2002”

(b) DoD Directive 8500.01E, “Information Assurance (IA),” October 24, 2002

(c) DoD Directive 8100.1, “Global Information Grid (GIG) Overarching Policy,” September 19, 2002

(d) DoD Instruction 8500.2, “Information Assurance (IA) Implementation,”

February 6, 2003

(e) through (ab), see Enclosure 1

1. PURPOSE

This Instruction:

1.1. Implements References (a), (b), (c), and (d) by establishing the DIACAP for authorizing the operation of DoD Information Systems (ISs).

1.2. Cancels DoD Instruction (DoDI) 5200.40; DoD 8510.1-M; and ASD(NII)/DoD CIO memorandum, “Interim Department of Defense (DoD) Information Assurance (IA) Certification and Accreditation (C&A) Process Guidance” (References (e), (f), and (g)).

1.3. Establishes or continues the following positions, panels, and working groups to implement the DIACAP: the Senior Information Assurance Officer (SIAO), the Principal Accrediting Authority (PAA), the Defense Information Systems Network (DISN)/Global Information Grid (GIG) Flag Panel, the IA Senior Leadership (IASL), the Defense (previously DISN) IA Security Accreditation Working Group (DSAWG), and the DIACAP Technical Advisory Group (TAG).

1.4. Establishes a C&A process to manage the implementation of IA capabilities and services and provide visibility of accreditation decisions regarding the operation of DoD ISs, including core enterprise services- and Web services-based software systems and applications.

DoDI 8510.01, November 28, 2007

1.5. Prescribes the DIACAP to satisfy the requirements of Reference (a) and requires the Department of Defense to meet or exceed the standards required by the Office of Management and Budget (OMB) and the Secretary of Commerce, pursuant to Reference (a) and section 11331 of title 40, United States Code (Reference (h)).

2. APPLICABILITY AND SCOPE

2.1. This Instruction applies to:

2.1.1. The Office of the Secretary of Defense (OSD), the Military Departments, the Office of the Chairman of the Joint Chiefs of Staff, the Combatant Commands, the Office of the Inspector General (IG) of the Department of Defense, the Defense Agencies, the DoD Field Activities, and all other organizational entities within the Department of Defense (hereafter referred to collectively as the “DoD Components”).

2.1.2. DoD-owned ISs and DoD-controlled ISs operated by a contractor or other entity on behalf of the Department of Defense that receive, process, store, display, or transmit DoD information, regardless of classification or sensitivity, consistent with Reference (b).

2.2. Nothing in this Instruction shall alter or supersede the existing authorities and policies of the Director of National Intelligence regarding the protection of Sensitive Compartmented Information (SCI) and special access programs for intelligence as directed by Executive Order 12333 (Reference (i)) and other laws and regulations. The application of the provisions and procedures of this Instruction to SCI or other intelligence ISs is encouraged where they may complement or discuss areas not otherwise specifically addressed.

3. DEFINITIONS

Terms used in this Instruction are defined in Enclosure 2.

4. POLICY

It is DoD policy that:

4.1. The Department of Defense shall certify and accredit ISs through an enterprise process for identifying, implementing, and managing IA capabilities and services. IA capabilities and services are expressed as IA controls as defined in Reference (d). IA controls are maintained through a DoD-wide configuration control and management (CCM) process that considers the GIG architecture and risk assessments that are conducted at DoD-wide, mission area (MA), DoD Component, and IS levels consistent with Reference (a).

4.2. The Department of Defense shall establish and use an enterprise decision structure for IA C&A that includes and integrates GIG MAs pursuant to DoD Directive (DoDD) 8115.01 (Reference (j)) and the DIACAP governance process prescribed in this Instruction.

4.3. The DIACAP shall support the transition of DoD ISs to GIG standards and a net-centric environment while enabling assured information sharing by:

4.3.1. Providing a standard C&A approach.

4.3.2. Providing guidance on managing and disseminating enterprise standards and guidelines for IA design, implementation, configuration, validation, operational sustainment, and reporting.

4.3.3. Accommodating diverse ISs in a dynamic environment.

4.4. All DoD-owned or -controlled ISs shall be under the governance of a DoD Component IA program in accordance with Reference (d). The DoD Component IA program shall be the primary mechanism for ensuring enterprise visibility and synchronization of the DIACAP.

4.5. All DoD ISs shall be implemented using the baseline DoD IA controls in accordance with Reference (d). The baseline DoD IA controls may be augmented if required to address localized threats or vulnerabilities.

4.6. A DIACAP Scorecard with a manual or DoD Public Key Infrastructure (PKI)-certified digital signature shall be visible to the DoD Chief Information Officer (CIO) and the DoD Component CIOs. The DIACAP Scorecard shall document the designated accrediting authority (DAA) accreditation decision as well as the results of the implementation of required baseline IA controls and additional IA controls that may be required by the DoD Component or local IS.

4.7. An Information Technology (IT) Security Plan of Action and Milestones (POA&M) shall be developed and maintained to record the status of any corrective actions directed in association with an accreditation decision.

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.

4.9. All DoD ISs with an authorization to operate (ATO) shall be reviewed annually to confirm that the IA posture of the IS remains acceptable. Reviews will include validation of IA controls and be documented in writing.

4.10. Resources for implementing the DIACAP shall be identified and allocated as part of the Defense planning, programming, budgeting, and execution process.

4.11. Contracts for systems, services, and programs covered by this Instruction shall include clauses requiring compliance with the DIACAP. Failure to include such clauses is not justification for DIACAP non-compliance.

5. RESPONSIBILITIES

5.1. The Assistant Secretary of Defense for Networks and Information Integration/DoD CIO (ASD(NII))/DoD CIO) shall:

5.1.1. Oversee implementation of this Instruction, distribute DIACAP information standards and sharing requirements, and manage the transition from the previous DoD C&A process (Reference (e)) to the DIACAP.

5.1.2. Conduct an annual assessment of DoD Component IA programs for presentation in the annual report to Congress required by Reference (a).

5.1.3. Appoint a PAA for DoD ISs governed by the Enterprise Information Environment

MA (EIEMA).

5.1.4. Appoint a DoD SIAO corresponding to a senior agency information security officer in Reference (a).

5.1.5. Provide annual certification to the Secretary of Defense and Director of OMB confirming that the DIACAP process is current and more stringent than the standards required by the OMB and the Secretary of Commerce pursuant to Reference (a).

5.2. The DoD SIAO, under the authority, direction, and control of the ASD(NII)/DoD CIO, shall direct and coordinate the DoD IA Program (Reference (d)) and:

5.2.1. Ensure DoD ISs are assigned to and governed by a DoD Component IA program.

5.2.2. Advise, inform, and support the GIG PAAs and their representatives.

5.2.3. Establish and maintain a DIACAP CCM process, a DIACAP TAG, and an online DIACAP Knowledge Service (KS).

5.3. The Director, Defense Information Systems Agency (DISA), under the authority, direction, and control of the ASD(NII)/DoD CIO, shall:

5.3.1. Develop security technical configuration and implementation validation requirements and associated expected results for IT products and services and provide automated validation capabilities to the DoD Components for use in the DIACAP.

5.3.2. Develop and provide DIACAP training and awareness products and a distributive training capability to support the DoD Components according to Reference (b) and DoDD 8570.1 (Reference (k)) and post the training materials on the IA Support Environment Web site (http://iase.disa.mil/).

5.3.3. Appoint a flag-level representative to the DISN/GIG Flag Panel (previously the DISN Flag Panel).

5.4. The Under Secretary of Defense for Acquisition, Technology, and Logistics (USD(AT&L)) shall:

5.4.1. Appoint a PAA for DoD ISs governed by the Business MA (BMA).

5.4.2. Participate in the DIACAP TAG to ensure that the DIACAP and execution of the responsibilities established in DoDI 5000.2 (Reference (l)) are mutually supportive.

5.5. The Under Secretary of Defense for Intelligence (USD(I)) shall appoint a PAA for all DoD ISs governed by the Defense Intelligence MA (DIMA).

5.6. The Director, Defense Intelligence Agency, under the authority, direction, and control of the USD(I), shall appoint a flag-level representative to the DISN/GIG Flag Panel.

5.7. The Director, National Security Agency, under the authority, direction, and control of the USD(I), shall:

5.7.1. Develop the IA component of the GIG architecture (Reference (c)) and publish supporting implementation material in the DIACAP KS.

5.7.2. Engage the GIG IA capability, services provider, and user communities -- to include commercial, defense, and other government agencies -- to foster development and evaluation of IA implementation and validation solutions that support the DIACAP.

5.7.3. Ensure that IA security engineering services provided to the DoD Components support the DIACAP.

5.7.4. Appoint a flag-level representative to the DISN/GIG Flag Panel.

5.8. The Heads of the DoD Components shall:

5.8.1. Ensure DoD ISs under their purview comply with the DIACAP.

5.8.2. Operate only accredited ISs (i.e., those with a current ATO, interim authorization to operate (IATO), or interim authorization to test (IATT)).

5.8.3. Comply with all accreditation decisions, including denial of authorization to operate (DATO), and enforce authorization termination dates (ATD).

5.8.4. Ensure that an annual assessment of the DoD Component IA program is conducted as required by Reference (a).

5.8.5. Appoint DAAs for DoD ISs under their purview.

5.8.6. Provide training and ensure appropriate professional certification for personnel engaged in or supporting the DIACAP is consistent with Reference (k) and supporting issuances.

5.8.7. Ensure that the information owner(s) appoints a user representative(s) (UR) for DoD ISs under the DoD Component’s purview.

5.8.8. In the absence of a DoD Component CIO, appoint the SIAO.

5.9. The Chairman of the Joint Chiefs of Staff shall:

5.9.1. Appoint a PAA for DoD ISs governed by the Warfighting MA (WMA).

5.9.2. Ensure that Joint Capabilities Integration and Development System (JCIDS) implementation guidance requires DIACAP planning consistent with this Instruction.

5.10. The Commander, United States Strategic Command, shall:

5.10.1. Assign DAAs for space systems used by the Department of Defense in accordance with DoDD 8581.1 (Reference (m)).

5.10.2. Accredit IS processing, storing, or transmitting Nuclear Command and Control Extremely Sensitive Information (NC2-ESI) data.

5.10.3. Appoint a flag-level representative to the DISN/GIG Flag Panel.

5.11. The PAAs shall:

5.11.1. Represent the interests of the MA and, as required, issue accreditation guidance specific to the MA, consistent with this Instruction.

5.11.2. Appoint flag-level (e.g., general officer, senior executive) PAA Representatives to the DISN/GIG Flag Panel.

5.11.3. Resolve accreditation issues within their respective MAs and work with other PAAs to resolve issues among MAs, as needed.

5.11.4. Designate DAAs for MA ISs, if required, in coordination with appropriate DoD Components.

5.12. The PAA Representatives shall:

5.12.1. Serve as members of the DISN/GIG Flag Panel.

5.12.2. Provide MA-related guidance to DAAs, Milestone Decision Authorities (Reference (j)), the DSAWG, and the DIACAP TAG.

5.12.3. Advise the corresponding MA PAAs and assist the ASD(NII)/DoD CIO and SIAO in assessing the effectiveness of GIG IA capabilities.

5.13. The DoD Component CIOs shall:

5.13.1. Appoint a DoD Component SIAO in accordance with Reference (a) to direct and coordinate the DoD Component IA program consistent with the strategy and direction of the Defense-wide Information Assurance Program (DIAP).

5.13.2. Ensure that implementation and validation of IA controls through the DIACAP are incorporated as an element of the DoD Component IS life-cycle management processes.

5.13.3. Ensure that the C&A status of the DoD Component ISs is visible to the ASD(NII)/DoD CIO and PAAs.

5.13.4. Ensure collaboration and cooperation between the DoD Component IA program and the PAA and DAA structure.

5.13.5. Verify that a program or system manager is identified for each DoD Component

IS.

5.13.6. Establish and manage an IT Security POA&M program.

5.14. The DoD Component SIAOs, under the authority, direction, and control of the DoD Component CIOs, shall:

5.14.1. Establish and enforce the C&A process within the DoD Component IA program.

5.14.2. Ensure DoD Component-level participation in the DIACAP TAG.

5.14.3. Track the C&A status of ISs that are governed by the DoD Component IA program.

5.14.4. Establish and manage a coordinated IA certification process for ISs governed by the DoD Component IA program. This includes but is not limited to:

5.14.4.1. Functioning as the certifying authority (CA) or formally delegating CA for governed ISs.

5.14.4.2. Ensuring and overseeing a qualified certification cadre (e.g., validators, analysts, CA representatives).

5.14.4.3. Identifying and recommending changes and improvements to certification and validation procedures to the TAG for inclusion in the DIACAP KS.

5.14.4.4. Ensuring that DoD Component certification guidance is posted to the DoD Component portion of the KS.

5.14.5. Serve as the single IA coordination point for joint or Defense-wide programs that are deploying ISs to DoD Component enclaves.

5.15. The DAAs, in addition to the responsibilities established in Reference (d), shall:

5.15.1. Comply with DISN/GIG Flag Panel direction issued on behalf of the GIG MA PAAs.

5.15.2. Ensure a DIACAP package is initiated and completed for assigned ISs.

5.15.3. Ensure assigned DoD ISs comply with applicable DoD baseline IA controls.

5.15.4. Ensure security classification guides are established according to DoD 5200.1-R (Reference (n)).

5.15.5. Authorize or deny operation or testing of assigned DoD ISs. Coordinate with the Director, Operational Test and Evaluation before denying IATT.

5.16. The Program Manager (PM) or System Manager (SM) for DoD ISs shall:

5.16.1. Ensure that each assigned DoD IS has a designated IA manager (IAM) with the support, authority, and resources to satisfy the responsibilities established in Reference (d) and this Instruction.

5.16.2. Implement the DIACAP for assigned DoD ISs.

5.16.3. Plan and budget for IA controls implementation, validation, and sustainment throughout the system life cycle, including timely and effective configuration and vulnerability management.

5.16.4. Ensure that information system security engineering is employed to implement or modify the IA component of the system architecture in compliance with the IA component of the GIG Architecture (Reference (c)) and to make maximum use of enterprise IA capabilities and services.

5.16.5. Enforce DAA accreditation decisions for hosted or interconnected DoD ISs.

5.16.6. Develop, track, resolve, and maintain the DIACAP Implementation Plan (DIP) for assigned DoD ISs.

5.16.7. Ensure IT Security POA&M development, tracking, and resolution.

5.16.8. Ensure annual reviews of assigned ISs required by FISMA are conducted.

5.17. The DoD IS URs shall:

5.17.1. Represent the operational interests of the user community in the DIACAP.

5.17.2. Support the IA controls assignment and validation process to ensure user community needs are met.

5.18. The IAMs, in addition to the responsibilities established in Reference (d), shall:

5.18.1. Support the PM or SM in implementing the DIACAP.

5.18.2. Advise and inform the governing DoD Component IA program on DoD ISs C&A status and issues.

5.18.3. Comply with the governing DoD Component IA program information and process requirements.

5.18.4. Provide direction to the IA Officer (IAO) in accordance with Reference (d).

5.18.5. Coordinate with the organization’s Security Manager to ensure issues affecting the organization’s overall security are addressed appropriately.

6. PROCEDURES

6.1. Background. This section describes the DoD procedures for identifying, implementing, validating, certifying, and managing IA capabilities and services, expressed as IA controls, and authorizing the operation of DoD ISs. It also describes the processes for configuration management of DoD IA controls and supporting implementation materials. DIACAP activities and roles are distributed across all levels of the DoD and GIG governance structures, as well as all stages of the life cycle of both the IA Component of the GIG (Reference (c)) and of individual ISs. DIACAP implementation is supported by the DIACAP KS, a Web-based DoD resource that provides the most current requirements, guidance, and tools for implementing and executing the DIACAP, including IA control implementation procedures. Enclosure 4 provides additional information on the KS.

6.2. DIACAP Enterprise Governance. This structure is intended to synchronize and integrate DIACAP activities across all levels of the DoD and GIG MAs, all aspects of the IT life cycle, and logical and organizational entities. It comprises three major elements: an accreditation structure; a CCM structure; and a C&A process structure. These elements are illustrated in Figure F1. and described in subparagraphs 6.2.1. through 6.2.4.

Figure F1. DIACAP Enterprise Governance

6.2.1. Accreditation

6.2.1.1. PAAs are appointed for each of the GIG MAs (i.e., the EIEMA, BMA, WMA, and DIMA). PAAs may directly appoint DAAs for DoD ISs supporting an MA Community of Interest (COI) (DoD 8320.2-G (Reference (o))). DAAs have the authority and responsibility for accreditation decisions.

6.2.1.2. The DISN/GIG Flag Panel (charter under development), acting on behalf and in support of the PAAs, is responsible for advising PAAs; assessing enterprise risk; authorizing information exchanges and connections for enterprise IS, cross-MA IS, cross security domain connections, and non-DoD connections; and approving changes to the DoD IA control baseline.

6.2.1.3. The DSAWG (DoD CIO memorandum (Reference (p))), under the DISN/GIG Flag Panel, is the community forum for reviewing and resolving C&A decisions related to the sharing of community risk. The DSAWG develops and provides guidance to the DAAs for IS connections to the GIG.

6.2.2. CCM

6.2.2.1. The DIACAP TAG (ASD(NII) memorandum (Reference (q))) provides CCM of the DIACAP through interfacing with the DoD Component IA programs, IA COIs, and other entities (e.g., the GIG IA Program Office, DSAWG) to address issues that are common across all entities, by:

6.2.2.1.1. Providing detailed analysis and authoring support for the enterprise portion of the DIACAP KS content.

6.2.2.1.2. Recommending changes to the baseline IA controls to the DISN/GIG Flag Panel.

6.2.2.1.3. Recommending changes to the C&A process to the DoD SIAO.

6.2.2.1.4. Advising the IASL and other IA advisory forums identified by the DoD SIAO to resolve C&A priorities and cross-cutting issues.

6.2.2.1.5. Developing and managing DoD enterprise-level C&A automation requirements.

6.2.2.2. The TAG is supported by the DIACAP KS, described in Enclosure 4. The DIACAP KS enables TAG functions and activities, including maintenance of membership;

voting, analysis, and authoring; and configuration control of KS enterprise content and functionality.

6.2.3. C&A Responsibilities. The DoD SIAO directs and coordinates the DoD IA Program. DoD Component SIAOs have authority and responsibility for certification. Each DoD Component SIAO serves as the CA for all DoD ISs assigned to or governed by the DoD Component CIO and supporting IA program. Each CA may task, organize, staff, and centralize or delegate certifying activities. Regardless of the adopted model, the SIAO is responsible for certification quality, capacity, visibility, and effectiveness. In addition, each CIO, supported by an appointed SIAO, is responsible for administration of the overall C&A process. This includes the integration of certification with other DIACAP activities, participation in the DIACAP CCM, visibility and sharing of the C&A status of assigned ISs, enforcement of training requirements for persons participating in the DIACAP, support to DAAs, and responsiveness to the DoD CIO.

The IASL (DoD CIO memorandum (Reference (r))) serves as an SIAO community forum for assessing and improving C&A process administration. The IASL provides strategic direction and guidance to ensure integrated Defense-wide IA. It provides for the integrated planning, coordination, and oversight of the Department’s IA programs.

6.2.4. C&A Role Appointment. Table T1. identifies the appropriate authority for the appointment of C&A roles.

Table T1. Appointment of C&A Roles

C&A Role Appointed By

PAA GIG MA Owner

PAA Representative PAA

DAA DoD Component Head or designee; PAA for MA-managed ISs

CIO DoD Component Head

SIAO DoD Component CIO or, in organizations in which the position of DoD Component CIO does not exist, the DoD Component Head Note: DoD SIAO appointed by DoD CIO

CA SIAO is the Component CA, but may formally delegate the CA role as appropriate

CA Representative, Analyst, Validator Component CA or CA delegates

IAM PM or SM

IAO IAM

UR Information Owner

DIACAP TAG Representative DoD Component SIAO or DoD Component

CIO

6.3. DIACAP Activities. The DIACAP consists of the activities and tasks depicted in Figure F2. The DIACAP parallels the system life cycle, and its activities should be initiated at inception (e.g., documented during capabilities identification or at the implementation of a major system modification). However, failure to initiate the DIACAP at system inception is not a justification for ignoring or not complying with the DIACAP. Unaccredited systems shall initiate the DIACAP immediately, regardless of the system life-cycle stage (e.g., acquisition, operation).

Figure F2. DIACAP Activities

6.3.1. Initiate and Plan IA C&A. This activity includes registering the system with the governing DoD Component IA program, assigning IA controls based on Mission Assurance Category (MAC) and Confidentiality Level (CL), identifying the DIACAP Team for the IS, and initiating the IS’s DIP.

6.3.1.1. Register the System with the DoD IA Program. System registration establishes the relationship between the DoD IS and the governing DoD Component IA program which continues until the DoD IS is decommissioned. DIACAP registration is related to other DoD initiatives to collect IT-related information (e.g., the Defense Information Technology Portfolio Repository); however, specific registration instructions change over time and are therefore maintained through the DIACAP CCM and published in the DIACAP KS. The System Identification Profile (SIP) is generated during the registration process and becomes part of the DIACAP package for the IS. Attachment 1 to Enclosure 3 of this Instruction identifies the minimum data requirements and explanations for the SIP.

6.3.1.2. Assign IA Controls. Identifying applicable IA controls for an information system is a critical activity in the DIACAP. There are four basic steps in assigning the IA controls: determining the type of information system; determining the MAC and CL for the information system; identifying the baseline IA controls; and augmenting the baseline IA controls.

6.3.1.2.1. Baseline IA controls originate from Reference (d) control sets, are based on MAC and CL, and are implemented through procedures presented in the DIACAP

KS.

6.3.1.2.2. Baseline IA control sets can be augmented with additional IA controls to address special security needs or unique requirements of the IS(s) to which they apply. Augmenting IA controls originate from an MA, a DoD Component, a COI, or a local system. Augmenting IA controls must neither contradict nor negate DoD baseline IA controls, must not degrade interoperability across the DoD Enterprise, and may not be used as a basis for denying connectivity of systems that have met the DoDI 8500.2 baseline IA controls for MAC and CLs of the gaining IS. Procedures for implementing augmenting IA controls are the responsibility of the originator.

6.3.1.2.3. Assigned IA controls may be inherited. Inheritance refers to situations where IA controls along with their validation results and compliance status are shared by two or more systems for the purposes of C&A. Through inheritance, an existing IA control and its compliance status extends from an originating IS to a receiving IS. Inheritance eliminates the need for the receiving systems to duplicate testing and documentation of inherited IA controls.

The DIP specifically identifies IA controls inherited from other systems. The compliance status of IA controls inherited from the originating IS is reflected on the DIACAP Scorecard of the receiving IS.

6.3.1.3. Assemble the DIACAP Team

6.3.1.3.1. The members of the DIACAP Team are required to meet the trustworthiness investigative levels for users with IA management access to DoD unclassified ISs as established in Section E3.4.8. of Reference (d). SIAOs shall meet the same investigative requirements as those for DAA, and certification cadre members shall meet the same requirements as those established for monitoring and testing in Table E3.T1. of Reference (d).

6.3.1.3.2. DIACAP Team members will be trained and certified in accordance with Reference (k), as required.

6.3.1.3.3. Allowable relationships among DIACAP Team members are outlined in Table T2.

Table T2. Allowable Relationships Among DIACAP Team Members

Relationships Allowed (Y/N)

PAA may be a DAA Yes

DAA reports to the PM, SM, or Program Executive Officer (PEO) No

DAA and CA for a DoD IS may be the same person Yes

CIO may be a DAA Yes

CA reports to a DAA Yes

CA reports to the PM , SM, or PEO No

PM or SM and CA both report to the DAA Yes

PM or SM and CA for a DoD IS may be the same person No

PM or SM and DAA for a DoD IS may be the same person No

PM or SM and UR for a DoD IS may be the same person No

PM or SM reports to CA No

PM or SM reports to the CIO Yes

PM or SM reports to the DAA Yes

UR reports to the CIO Yes

UR reports to the PM or SM No

UR reports to the SIAO/CA Yes

6.3.1.4. Initiate the DIP. This plan contains the IS’s assigned IA controls, including inherited IA controls. The plan also includes the IA control implementation status, responsible entities, resources, and the estimated completion date for each assigned IA control. The plan may reference applicable supporting implementation material and artifacts.

6.3.2. Implement and Validate Assigned IA Controls. This activity includes executing the DIP, conducting validation activities, preparing the IT Security POA&M, and compiling the validation results in the DIACAP Scorecard.

6.3.2.1. Execute the DIP. Each assigned IA control is implemented according to the applicable implementation guidelines described in the DIACAP KS.

6.3.2.2. Conduct Validation Activities. Validation procedures are maintained through the DIACAP CCM and published in the DIACAP KS. Each validation procedure describes requisite preparatory steps and conditions, actual validation steps, expected results, and criteria and protocols for recording actual results. Each procedure includes associated supporting background material, sample results, or links to automated testing tools. Actual results are recorded according to the criteria and protocols specified in the validation procedure and are made a permanent part of the comprehensive DIACAP package, along with any artifacts produced during the validation (e.g., output from automated test tools or screen shots that depict aspects of system configuration). For inherited IA controls, validation test results and supporting documentation are maintained by the originating IS and are made available to CAs of receiving ISs on request.

6.3.2.3. Record Compliance Status. The status of each assigned IA control is indicated on the DIACAP Scorecard. An example of a Scorecard and discussion of its fields are provided in Attachment 2 to Enclosure 3.

6.3.2.3.1. Compliant (C) IA controls are those for which the expected results for all associated validation procedures have been achieved.

6.3.2.3.2. Non-compliant (NC) IA controls are those for which one or more of the expected results for all associated validation procedures are not achieved. Not achieving expected results for all validation procedures does not necessarily equate to unacceptable risk.

6.3.2.3.3. Not applicable (NA) IA controls are those that do not impact the IA posture of the IS as determined by the DAA.

6.3.2.4. Prepare an IT Security POA&M. An IT Security POA&M identifies tasks that need to be accomplished. It specifies resources required to accomplish the elements of the plan and milestones for completing tasks, along with their scheduled completion dates. IT Security POA&Ms are permanent records. Once posted, weaknesses will be updated, but not removed, after correction or mitigation actions are completed. Inherited weaknesses are reflected on the IT Security POA&Ms. IT Security POA&Ms may be active or inactive throughout a system’s life cycle as weaknesses are newly identified or closed. The DoD Component CIOs are responsible for monitoring and tracking the overall execution of system-level IT Security POA&Ms until identified security weaknesses have been closed and the C&A documentation appropriately adjusted. The DAAs are responsible for monitoring and tracking overall execution of system-level IT Security POA&Ms. The PM or SM is responsible for implementing the corrective actions identified in the IT Security POA&M and, with the support and assistance of the IAM, provides visibility and status to the DAA, the SIAO, and the governing DoD Component CIO. In order to reflect the complete IA posture of a DoD IS at all times in a single document, the IT Security POA&M is also used to document DAA-accepted NC IA controls and baseline IA controls that are NA because of the nature of the system. A full discussion and templates for preparing an IT Security POA&M are provided in Attachment 3 to Enclosure 3.

6.3.3. Make Certification Determination and Accreditation Decision

6.3.3.1. The CA makes certification determinations.

6.3.3.1.1. A CA representative is an active member of the DIACAP Team from inception and continuously assesses and guides the quality and completeness of DIACAP activities and tasks and the resulting artifacts.

6.3.3.1.2. Certification considers:

6.3.3.1.2.1. The overall reliability and viability of the DoD IS plus the acceptability of the implementation and performance of IA mechanisms or safeguards inherent in the system.

6.3.3.1.2.2. The system behavior in the larger information environment, including consideration of vulnerabilities to the environment, correct and secure interactions with the information environment management and control services, and visibility into situational awareness and network defense services.

6.3.3.1.3. Impact codes are assigned by the TAG to IA controls at the time of authoring and are maintained through the DIACAP CCM. They indicate the TAG’s assessment of the consequences of a failed IA control. Impact codes are expressed as high, medium, and low, with high indicating the greatest impact. In conjunction with the severity category, the impact code indicates the urgency with which corrective action should be taken. Within a severity category, non-compliant IA controls should be prioritized for correction or remediation according to their impact codes.

6.3.3.1.4. Severity categories are assigned to a system weakness or shortcoming by a CA or a designated representative as part of a certification analysis to indicate the risk level associated with the security weakness and the urgency with which the corrective action must be completed. Severity categories are expressed as category (CAT) I, CAT II, and CAT III.

Severity categories are assigned after considering all possible mitigation measures that have been implemented within system design and architecture limitations for the DoD IS in question. For instance, what may be a CAT I weakness in a component part of a system (e.g., a workstation or server) may be offset or mitigated by other protections within hosting enclaves so that the overall risk to the system is reduced to a CAT II.

6.3.3.1.4.1. CAT I weaknesses shall be corrected before an ATO is granted.

6.3.3.1.4.2. CAT II weaknesses shall be corrected or satisfactorily mitigated before an ATO can be granted.

6.3.3.1.4.3. CAT III weaknesses will not prevent an ATO from being granted if the DAA accepts the risk associated with the weaknesses.

6.3.3.1.5. The certification determination is based on the actual validation results.

It considers impact codes associated with IA controls in a non-compliant status, associated severity categories, expected exposure time (i.e., the projected life of the system release or configuration minus the time to correct or mitigate the IA security weakness), and cost to correct or mitigate (e.g., dollars, functionality reductions). The weaknesses identified on the IT Security POA&M reflect residual risk to the system. See Attachment 3 to Enclosure 3 for further discussion on IT Security POA&M formulation.

6.3.3.1.6. A certification determination is always required before an accreditation decision. If a compelling mission or business need requires the rapid introduction of a new DoD IS into the GIG, validation activity and a certification determination are still required. If the operation will be required beyond the time period of an IATO, a complete validation should be initiated immediately.

6.3.3.2. The DAA issues accreditation decisions.

6.3.3.2.1. An accreditation decision is communicated via the DIACAP Scorecard and accompanying IT Security POA&M, if required.

6.3.3.2.2. Documentation (e.g., artifacts, actual validation results) supporting an accreditation decision will be provided in electronic form if requested by DAAs of interconnecting systems.

6.3.3.2.3. An accreditation decision always applies to a specifically identified DoD IS and is based on a balance of mission or business need, protection of personal privacy, protection of the information being processed, and protection of the information environment and thus, by extension, protection of other missions or business functions reliant on the shared information environment.

6.3.3.2.4. An accreditation decision always requires a certification determination.

If the validation is abbreviated as a result of mission urgency, the accreditation decision cannot exceed an IATO. If operation will be required beyond the time period of an IATO, a complete validation should be initiated immediately.

6.3.3.2.5. When there is compelling operational necessity, DoD ISs may be allowed to operate despite IT security weaknesses that cannot be corrected or adequately mitigated within prescribed timeframes because of technology limitations or, in rare cases, prohibitive costs. Such instances must be fully justified, approved, and documented.

6.3.3.2.6. An accreditation decision is expressed as an ATO, an IATO, an IATT, or a DATO. A system is considered unaccredited if an accreditation decision has not been made.

6.3.3.2.6.1. ATO

6.3.3.2.6.1.1. An ATO accreditation decision must specify an

authorization termination date that is within 3 years of the authorization date.

6.3.3.2.6.1.2. A system with a CAT I weakness may not be granted an ATO. A system can operate with a CAT I weakness only when it is critical to military operations as determined by affected military commanders and if failure to deploy or allow continued operation for deployed systems will preclude mission accomplishment. When requested by an affected military commander, the DoD Component CIO shall authorize operation of a system with a CAT I weakness through an IATO. This responsibility cannot be delegated below the DoD Component CIO, and a signed copy of the authorization memorandum with supporting rationale shall be provided to the DoD SIAO and the system’s DAA.

6.3.3.2.6.1.3. A system with a CAT II weakness can be granted an ATO only when there is clear evidence that the CAT II weakness can be corrected or satisfactorily mitigated within 180 days of the accreditation decision.

6.3.3.2.6.1.4. An ATO can be granted with CAT III weaknesses. The DAA will determine if these weaknesses will be corrected or the risk accepted. CAT III weaknesses accepted by the DAA will appear on the IT Security POA&M with the “Resources Required,” “Scheduled Completion Date,” “Milestones with Completion Dates,” and “Milestone Changes” columns marked “NA,” and with the “Status” column marked “Risk Accepted by

DAA.”

6.3.3.2.6.2. IATO

6.3.3.2.6.2.1. An IATO accreditation decision is intended to manage IA security weaknesses while allowing system operation. It is not intended to be a device for signaling an evolutionary acquisition. A version of a DoD IS acquired in one of a planned series of acquisition increments or development spirals should be granted an ATO, even if additional or enhanced capabilities and services are planned for future increments or spirals. The ATO accreditation decision should not be reserved for DoD ISs for which no change is planned or foreseen. Such thinking engenders an abuse of the IATO accreditation status and is an inaccurate portrayal of the DoD ISs’ IA posture.

6.3.3.2.6.2.2. An IATO accreditation decision must specify an ATD that is within 180 days of the authorization date. A DAA may not grant consecutive IATOs totaling more than 360 days.

6.3.3.2.6.2.3. A request for an IATO must be accompanied by an IT Security POA&M that documents identified weaknesses and specifies corrective measures, as appropriate. Corrective actions specified in the IT Security POA&M must be achievable within the authorization period and resourced accordingly.

6.3.3.2.6.2.4. If CAT II weaknesses have not been corrected or satisfactorily mitigated after system operation under IATOs for a total of 360 days, the DAA will normally issue a DATO that will remain in effect until all corrective actions identified in the IT Security POA&M are implemented satisfactorily and the DAA is able to grant an ATO.

6.3.3.2.6.2.5. The DoD Component CIO may authorize continuation of operation under IATO for systems with CAT II weaknesses that have operated for 360 consecutive days. This responsibility cannot be delegated below the DoD Component CIO. The DAA must certify in writing or through DoD PKI-certified digital signature that continued system operation is critical to mission accomplishment. A copy of the authorization to continue system operation with supporting rationale shall be provided to the DoD SIAO.

6.3.3.2.6.3. IATT

6.3.3.2.6.3.1. The IATT accreditation decision is a special case for authorizing testing in an operational information environment or with live data for a specified time period. IATTs should be granted only when operational environment/live data is required to complete specific test objectives (e.g., replicating certain operating conditions in the test environment is impractical).

6.3.3.2.6.3.2. All applicable IA controls should be tested and satisfied prior to testing in an operational environment or with live data except for those which can only be tested in an operational environment. In consultation with the PM or SM, the DAA will determine which IA controls can only be tested in an operational environment.

6.3.3.2.6.3.3. An IATT may not be used to avoid ATO or IATO

validation activity and certification determination requirements for authorizing a system to operate. Operation of a system under an IATT in an operational environment is for testing purposes only (i.e., the system will not be used for operational purposes during the IATT period).

6.3.3.2.6.4. DATO. A DATO will be issued if the DAA determines that a DoD IS should not operate because the IA design is inadequate, assigned IA controls are not adequately implemented, or because of a lack of other adequate security is revealed through certification activities and there are no compelling reasons to allow system operation under subparagraphs 6.3.3.2.6.1.2 or 6.3.3.2.6.2.5. If the system is already operational, the DAA will issue a DATO and halt operation of the system immediately.

6.3.4. Maintain Authorization to Operate and Conduct Reviews. Continued ATO is contingent on the sustainment of an acceptable IA posture. The DoD IS IAM has primary responsibility for maintaining situational awareness and initiating actions to improve or restore IA posture.

6.3.4.1. Maintain Situational Awareness. Included in the IA controls assigned to all DoD ISs are IA controls related to configuration and vulnerability management, performance monitoring, and periodic independent evaluations (e.g., penetration testing). The IAM continuously monitors the system or information environment for security-relevant events and configuration changes that negatively impact IA posture and periodically assesses the quality of IA controls implementation against performance indicators such as security incidents, feedback from external inspection agencies (e.g., IG DoD, Government Accountability Office (GAO)), exercises, and operational evaluations. In addition the IAM may, independently or at the direction of the CA or DAA, schedule a revalidation of any or all IA controls at any time.

Reference (a) requires revalidation of a select number of IA controls at least annually.

6.3.4.1.1. DoD ISs with a current ATO that are found to be operating in an unacceptable IA posture through GAO audits, IG DoD audits, or other reviews or events such as an annual security review or compliance validation shall have the newly identified weakness added to an existing or newly created IT Security POA&M.

6.3.4.1.2. If a newly discovered CAT I weakness on a DoD IS operating with an ATO cannot be corrected within 30 days, the system can only continue operation under the terms prescribed in subparagraph 6.3.3.2.6.1.2.

6.3.4.1.3. If a newly discovered CAT II weakness on a DoD IS operating with a current ATO cannot be corrected or satisfactorily mitigated within 90 days, the system can only continue operation under the terms prescribed in subparagraph 6.3.3.2.6.2.5.

6.3.4.2. Maintain IA Posture. The IAM may recommend changes or improvement to the implementation of assigned IA controls, the assignment of additional IA controls, or changes or improvements to the design of the IS itself.

6.3.4.3. Perform Reviews. The IAM shall annually provide a written or DoD PKI-certified digitally signed statement to the DAA and the CA that indicates the results of the security review of all IA controls and the testing of selected IA controls as required by Reference (a). The review will either confirm the effectiveness of assigned IA controls and their implementation, or it will recommend: changes such as those described in subparagraph 6.3.4.2.;

a change in accreditation status (e.g., accreditation status is downgraded to IATO or DATO); or development of an IT Security POA&M. The CA and DAA shall review the IAM statement in light of mission and information environment indicators and determine a course of action that will be provided to the concerned CIO or SIAO for reporting requirements described in Reference (a). The date of the annual security review will be recorded in the SIP. A DAA may downgrade or revoke an accreditation decision at any time if risk conditions or concerns so warrant.

6.3.4.4. Initiate Reaccreditation. In accordance with OMB Circular A-130 (Reference (s)), an IS must be recertified and reaccredited once every 3 years. The results of an annual review or a major change in the IA posture at any time may also indicate the need for recertification and reaccreditation of the IS.

6.3.5. Decommission. When a DoD IS is removed from operation, a number of DIACAP-related actions are required. Prior to decommissioning, any inheritance relationships should be reviewed and assessed for impact. Once the system has been decommissioned, Lines 8, “DIACAP Activity,” and 9, “System Life Cycle Phase,” of the SIP should be updated to reflect the IS decommissioned status. Concurrently, the DIACAP Scorecard and any POA&Ms should also be removed from all tracking systems. Other artifacts and supporting documentation should be disposed of according to its sensitivity or classification. Data or objects in IA infrastructures that support the GIG, such as key management, identity management, vulnerability management, and privilege management, should be reviewed for impact.

6.4. Transition to DIACAP. All DoD ISs are required to transition to the DIACAP in accordance with the timeline and instructions specified in Enclosure 5. The DoD Components are responsible for ensuring that all assigned DoD ISs meet the specified timelines.

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 and 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; and

2. 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.

6.6. System Interconnection. Reference (s) requires “written management authorization, based upon the acceptance of risk to the system, prior to connecting with other systems.” DoD ISs generally satisfy this requirement through compliance with connection management procedures established by the Chairman of the Joint Chiefs of Staff. Separately accredited ISs that communicate directly through tightly coupled mechanisms, such as shared memory or direct code invocation, are not subject to this requirement. In addition, for IA purposes, loosely coupled ISs (e.g., by proxy) communicating via Web services are not considered system interconnections and do not require connection approval, a security memorandum, or written management authorization. Dynamic interaction among accredited software systems that have been designed to interact is not considered a security-relevant event. This includes authorized messaging with non-DoD ISs (e.g., electronic commerce/electronic data interchange transactions with an IS belonging to another department or agency).

6.7. Type Accreditation. The type accreditation is the official authorization to employ identical copies of a system in specified environments. This form of C&A allows a single DIACAP package (i.e., SIP, DIP, supporting documentation for certification, DIACAP Scorecard, and IT Security POA&M (if required)) to be developed for an archetype (common) version of an IS that is deployed to multiple locations, along with a set of installation and configuration requirements or operational security needs, that will be assumed by the hosting location. Automated Information System (AIS) applications accreditations are type accreditations. Stand-alone IS and demilitarized zone (DMZ) accreditations may also be type accreditations.

6.8. Stand-Alone IS Accreditation. Stand-alone ISs are treated as special types of enclaves that are not interconnected to any other network. Stand-alone systems do not transmit, receive, route, or interchange information outside of the system’s accreditation boundary. IA requirements for a stand-alone system are determined by its MAC and classification or sensitivity and need-to-know just as for other DoD ISs. Stand-alone systems must always be clearly identified as such on the IT Security POA&M, the SIP, and the DIACAP Scorecard.

Because of the unique architecture of a stand-alone system, certain IA controls do not pose a risk to the system as a result of their non-implementation and thus are considered NA. NA IA controls are labeled as NA on the DIACAP Scorecard and addressed on the IT Security POA&M simply as a means to document and explain why the IA control is NA in the comments column.

Refer to the KS for a discussion of IA controls that may be considered NA for stand-alone systems. Additionally, stand-alone systems that are deployed to multiple locations may be type accredited.

6.9. Outsourced IT-Based Processes. Outsourced IT-based processes supported by private sector ISs, outsourced ITs, and outsourced information services fall into two sub-categories that are treated differently for C&A purposes.

6.9.1. Outsourced IT-Based Processes Established for DoD Purposes Only. Outsourced IT-based processes that are dedicated to DoD processing and are effectively under DoD configuration control (e.g., the Navy Marine Corps Intranet) are certified and accredited as DoD enclaves.