afi33-210.pdf

DEPARTMENT OF THE AIR FORCE

WASHINGTON, DC

OFFICE OF THE SECRETARY

AFI33-210_AFGM3

19 June 2014

MEMORANDUM FOR DISTRIBUTION C

MAJCOMs/FOAs/DRUs

FROM: SAF/CIO A6

1800 Air Force Pentagon Washington DC 20330-1720

SUBJECT: Air Force Guidance Memorandum to AFI 33-210, Air Force Certification and Accreditation (C&A) Program (AFCAP)

By Order of the Secretary of the Air Force, this Air Force Guidance Memorandum immediately changes AFI 33-210, AFCAP and provides updated guidance on Platform Information Technology (PIT) requirements, Real Time Services (RTS) requirements, Authorization to Connect (ATC) timelines, removal of Emergency Authorization to Connect (E- ATC) and acronym and term changes. Compliance with this memorandum is mandatory. To the extent its directions are inconsistent with other Air Force publications, the information herein prevails, IAW AFI 33-360, Publications and Forms Management.

No additional resources will be provided to implement this Guidance Memorandum outside of the normal Planning, Programming, Budgeting and Execution (PPBE) Process.

Questions regarding this policy can be forwarded to the SAF/CIO A6 Strategy Division, usaf.pentagon.saf-cio-a6.mbx.a3cs-a6cs-strategy-and-policy@mail.mil. This memorandum becomes void after one year has elapsed from the date of this memorandum, or upon publication of an Interim Change or rewrite of the affected publication, whichever is earlier.

MICHAEL J. BASLA, Lt Gen, USAF Chief, Information Dominance and Chief Information Officer

Attachments:

1. References

2. Guidance Changes

3. Acronym and Term Changes mailto:usaf.pentagon.saf-cio-a6.mbx.a3cs-a6cs-strategy-and-policy@mail.mil

Attachment 1

REFERENCES

1. AFI 33-210, Air Force Certification and Accreditation (C&A) Program (AFCAP), 23 Dec

2. AFI 33-360, Publications and Forms Management, 25 Sep 2013

3. DoDI 8500.01, Cybersecurity, 14 Mar 2014

4. DoDI 8510.01, Risk Management Framework (RMF) for DoD Information Technology, 12 Mar 2014

Attachment 2

GUIDANCE CHANGES

(Replace) 2.1.2. Complete training and maintain appropriate cybersecurity certifications in accordance with (IAW) AFMAN 33-285, Information Assurance Workforce Improvement Training.

(Replace) 2.5.4. Complete DAA training and maintain appropriate cybersecurity certification IAW AFMAN 33-285 and CNSSI 4012. Proof of training (e.g. certificate) will be included as an artifact to the IS’s C&A package.

(Replace) 2.6.5. AFMAN 33-285 instead of DoD 8570.01-M (Replace) 2.8.1. AFMAN 33-285 instead of DoD 8570.01-M (Replace) 2.9.1. AFMAN 33-285 instead of DoD 8570.01-M (Replace) 2.10.1. AFMAN 33-285 instead of DoD 8570.01-M (Replace) 2.11.8. AFMAN 33-285 instead of DoD 8570.01-M (Replace) 2.14. AFMAN 33-285 instead of DoD 8570.01-M (Replace) 2.15. AFMAN 33-285 instead of DoD 8570.01-M

3.1 AFCAP

(Replace) 3.1.2.5.1.1. Authorization to Connect (ATC) to the AFIN/DODIN.

(Add) 3.1.2.5.1.1.1. An ATC is granted to allow a system to connect to the AFIN. For enclaves requiring a circuit connection from DISA, ISSMs must follow the DISN Connection Process Guide, located at http://www.disa.mil/Services/Network- Services/Enterprise-Connections/Connection-Process-Guide, to ensure all required artifacts are provided on initial submission.

(Add) 3.1.2.5.1.1.2. Systems authorized through the AF Enterprise AO will receive an ATC as the system is reviewed for its authorization.

(Add) 3.1.2.5.1.1.3. Systems that are authorized by another AO are required, at a minimum, to provide a topology and valid authorization(s) for the system that is being connected. In addition, the following DIACAP artifacts, or their equivalent, are required: Sponsor memo (for guest systems), scorecard, SIP, PPS, hardware/software list, risk assessment report, and POA&M.

(Add) 3.1.2.5.1.1.4. Both systems/enclaves involved in the ATC must have a current authorization. The ATC’s expiration date will be the earlier of the two authorization package dates (e.g., whichever one expires first).

(Add) 3.1.2.5.1.1.5. Guest system sponsors or PMs are required to initiate the ATC request in eMASS.

(Add) 3.1.5. AF Enterprise AO Authorization timelines.

http://www.disa.mil/Services/Network-Services/Enterprise-Connections/Connection-Process-Guide http://www.disa.mil/Services/Network-Services/Enterprise-Connections/Connection-Process-Guide

(Add) 3.1.5.1. Packages with a licensed Agent of the Certifying Authority (ACA) review/recommendation must be uploaded in eMASS at least 30 days prior to mission need date and/or expiration dates of previously provided approvals and pushed to Step 5 (CA Representative review) in eMASS to begin the review.

(Add) 3.1.5.2. Packages without an ACA review/recommendation must be uploaded in eMASS at least 60 days prior to mission need date and/or expiration dates of previously provided approvals and pushed to Step 5 (CA Representative review) in eMASS to begin the review.

(Add) 3.1.5.3. The DIACAP Comprehensive Package must include the System Implementation Plan (SIP), DIACAP Implementation Plan (DIP), DIACAP Scorecard, IT Security Plan of Action & Milestones (POA&M), network topology and supporting documentation to include artifacts associated with the implementation of cybersecurity controls. Packages that do not include the required documentation will be given a maximum of five business days to provide the necessary artifacts.

(Add) 3.1.5.4. Authorization packages that have a residual risk level of CAT I (High or Very High), will require additional time to process the package IAW paragraph 3.1.1.2.1.

(Add) 3.1.5.5. If the above timelines are not met, the circuit will be at risk for disconnection as directed by US CYBER COMMAND.

(Delete) 3.6. Emergency Authorization to Connect (E-ATC) and all sub paragraphs

(Replace) 3.19. Platform IT (PIT), Platform IT Systems (PIT Systems), and Research, Development, Test, & Evaluation (RDT&E) systems

(Replace) 3.19.1. Cybersecurity risk for PIT, PIT Systems, and RDT&E systems may only be accepted by an AO appointed by SAF/CIO A6. Risk acceptance must be clearly documented by the AO before a system may commence testing or operations in the form of an ATO, ATO with conditions, IATT, or other digitally-signed authorization decision. The AO will provide specific guidance on how the C&A package for a PIT, PIT System, or RDT&E system will be developed and submitted.

(Replace) 3.19.2. All PIT, PIT System, and RDT&E systems will fall within the authorization boundary of an AO. The authorization boundaries will be specified in the AO appointment letter. In addition, the boundary definitions will be posted to the AFCKS AFCAP site, https://cs1.eis.af.mil/sites/AFCKS/Compliance/AFCAP/SitePages/Home.aspx.

For questions regarding authorization boundaries, contact the SAF/CIO A6 Cybersecurity Division, usaf.pentagon.saf-cio-a6.mbx.a3ci-a6ci-cybersecurity@mail.mil.

(Replace) 3.19.3. For a system to be approved to be PIT, PIT System, or RDT&E, the PM must obtain an approved Determination Letter.

(Replace) 3.19.3.1. PMs will submit a Determination package IAW the respective Information Assurance Platform IT Guidebook, https://cs1.eis.af.mil/sites/AFCKS/Compliance/AFCAP/Shared%20Documents/Guides/IA_P IT_Guidebook_v1.5.pdf, or the Air Force Research, Development, Test, and Evaluation (RDT&E) Implementation Guide, https://cs1.eis.af.mil/sites/AFCKS/Compliance/AFCAP/SitePages/Home.aspx mailto:usaf.pentagon.saf-cio-a6.mbx.a3ci-a6ci-cybersecurity@mail.mil https://cs1.eis.af.mil/sites/AFCKS/Compliance/AFCAP/Shared%20Documents/Guides/IA_PIT_Guidebook_v1.5.pdf https://cs1.eis.af.mil/sites/AFCKS/Compliance/AFCAP/Shared%20Documents/Guides/IA_PIT_Guidebook_v1.5.pdf https://eis.af.mil/cs/rdte/Resources/AF%20RDTE%20Implementation%20Guide%20- %20September%202011.pdf.

(Replace) 3.19.3.2. The results of the determination will be returned to the PM and IAM for the system.

(Replace) 3.19.3.3. The PM will work with the SCA to determine the specific C&A process and applicable security controls for their system.

(Add) 3.19.4. PMs are responsible to identify candidate PIT systems and document PIT determinations in their program’s Cybersecurity Strategy.

(Add) 3.19.5. PIT, PIT System, and RDT&E systems require cybersecurity risks to be identified continually and assessed throughout system design and operation. PMs must establish a cybersecurity risk management program. PMs should use a multi-disciplined Integrated Product Team (IPT) or equivalent science/research team to identify and assess cybersecurity risk. The team should include all necessary stakeholders and will recommend solutions to the PM.

(Add) 3.19.6. PIT PMs will use the Information Assurance Platform IT Guidebook developed by the Platform IT Working Group to assist with the C&A of their systems. The current version of the guidebook can be found on the AFCKS, https://cs1.eis.af.mil/sites/AFCKS/Compliance/AFCAP/Shared%20Documents.

(Add) 3.19.7. RDT&E PMs will use the AF RDT&E SharePoint site, https://eis.af.mil/cs/rdte, for specific procedures to assess and authorize their systems.

(Replace) 3.20. Real Time Services.

(Add) 3.20.1. Real Time Services (RTS) are defined as IP-based network, two-way voice, and/or video capabilities, not wireless, and official conferencing capable. Examples include, but are not limited to: Voice over Internet Protocol (VoIP), Voice over Secure Internet Protocol (VoSIP), Video Teleconferencing over Internet Protocol (VTCoIP), Video Teleconferencing over Secure Internet Protocol (VTCoSIP), and Voice and Video over Internet Protocol (VVoIP). This policy does not cover Internet Protocol Television (IPTV), Land Mobile Radio (LMR), or Radio over Internet Protocol (RoIP).

(Add) 3.20.2. This applies to all implementations of AF RTS capabilities connecting to AF enclaves configured within the AFIN boundary to include IP VTC capabilities registered within the Defense Information Systems Agency (DISA) Defense Information Systems Network Video Services (DVS).

(Add) 3.20.3. All AF RTS capabilities supported by AF enclaves must be implemented using components listed on the DISA Approved Products List Integrated Tracking System (DISA APLITS: https://aplits.disa.mil/processAPList.do), and configured IAW applicable guidance

(Add) 3.20.4. RTS shall be assessed and authorized through the enclave that it is connected to according to DoD Information Assurance Certification and Accreditation Process (DIACAP), http://iase.disa.mil/diacap/, and the DIACAP Knowledge Service, https://diacap.iaportal.navy.mil/login.htm.

https://eis.af.mil/cs/rdte/Resources/AF%20RDTE%20Implementation%20Guide%20-%20September%202011.pdf https://eis.af.mil/cs/rdte/Resources/AF%20RDTE%20Implementation%20Guide%20-%20September%202011.pdf https://cs1.eis.af.mil/sites/AFCKS/Compliance/AFCAP/Shared%20Documents https://eis.af.mil/cs/rdte https://aplits.disa.mil/processAPList.do http://iase.disa.mil/diacap/ https://diacap.iaportal.navy.mil/login.htm

(Add) 3.20.5. Detailed guidance on implementing RTS as a part of an enclave authorization can be found in the RTS Certification and Accreditation Guide found on the AFCKS AFCAP site, https://cs1.eis.af.mil/sites/AFCKS/Compliance/AFCAP/SitePages/Home.aspx.

(Add) 3.20.5. Changes to Systems with an Established Authorization Decision.

(Add) 3.20.5.1. After an authorization decision has been issued and a security baseline established (i.e., ATO), positive or negative changes to the system must be assessed by the system’s ISSM to determine if the change has a security impact. The ISSM is critical in initiating the change review process. The ISSM will consult the SCA for an assessment of any change to the system to determine if re-authorization is required. If the implementation of a cybersecurity control is affected by the change (especially for cybersecurity or cybersecurity-enabled products), there must be a validation of the cybersecurity control. This change may impact the authorization status, and the SCA must assess the implementation and validation of the cybersecurity control. They will determine if the risk level remains consistent with the current authorization.

(Add) 3.20.5.2. If the ISSM determines the system change does not affect the security baseline of the system (i.e., no security impact (NSI)), the system may continue to operate under its current authorization decision. Changes are documented and included with the system security and C&A documentation. The ISSM will provide a synopsis of the NSI to the SCA for concurrence. If the SCA concurs with the NSI, a new authorization decision and connection approval is not required. However, if the SCA does not concur with the NSI, the ISSM must take the actions identified in paragraph 3.20.5.3.

(Add) 3.20.5.3. If the ISSM determines a change impacts the security baseline of the system, the SCA must evaluate the change and determine the appropriate course of action. If the SCA concurs the change impacts the security baseline of the system, and/or a weakness cannot be mitigated in a timely manner to bring the risk back to the level the AO accepted in the current authorization, a new authorization decision and connection approval is required. NOTE: If the change results in a new “High” or “Very High” (formerly known as a CAT I) vulnerability that can be corrected within 30 days or a new CAT II weakness that can be corrected/satisfactorily mitigated within 90 days, the system can continue to operate under the existing authorization decision and connection approval.

https://cs1.eis.af.mil/sites/AFCKS/Compliance/AFCAP/SitePages/Home.aspx

Attachment 3

ACRONYMS AND TERMS

Acronyms

1. Remove the following abbreviations:

AFCA—Air Force Communications Agency

2. Replace the following abbreviations:

(Delete) AF-DAA—Air Force Provisioned Portion of the Global Information Grid Designated Accrediting Authority to (Replace) AF Enterprise AO—Air Force Enterprise Authorizing Official

(Delete) AF-GIG—Air Force Provisioned Portion of the Global Information Grid (Replace) AFIN—Air Force Information Network

(Delete) AF SIAO—Air Force Senior Information Assurance Officer (Replace) AF SISO—Air Force Senior Information Security Officer

(Delete) GIG—Global Information Grid (Replace) DODIN—Department of Defense Information Network

(Delete) CA—Certifying Authority (Replace) SCA—Security Control Assessor

(Delete) IAM—Information Assurance Manager (Replace) ISSM—Information System Security Manager

(Delete) IAO—Information Assurance Officer (Replace) ISSO—Information System Security Officer

(Delete) DAA—Designated Accrediting Authority (Replace) AO—Authorizing Official

3. Add the following abbreviations:

AFCKS – Air Force Cybersecurity Knowledge Service PIT—Platform Information Technology PITI—Platform Information Technology Interconnection SIP—System Information Profile

Terms and Definitions

1. Add the following terms and definitions

Platform Information Technology (PIT)—A special purpose system which employs computing resources (i.e., hardware, firmware, and optionally software) that are physically embedded in, dedicated to, or essential in real time to the mission performance. It only performs (i.e., is dedicated to) the information processing assigned to it by its hosting special purpose system (this is not for core services).

2. Replace the following definition

Information System (IS)—Set of information resources organized for the collection, storage, processing, maintenance, use, sharing, dissemination, display, or transmission of information.

* NOTE: The Air Force is adopting DoD cyberspace terminology from recently published DoDI

8500.01 and DoDI 8510.01.

BY ORDER OF THE AIR FORCE INSTRUCTION 33-210

SECRETARY OF THE AIR FORCE

23 DECEMBER 2008

Communications and Information

AIR FORCE CERTIFICATION AND ACCREDITATION

(C&A) PROGRAM (AFCAP)

COMPLIANCE WITH THIS PUBLICATION IS MANDATORY

ACCESSIBILITY: Publications and forms are available for downloading or ordering on the e-Publishing website at www.e-publishing.af.mil.

RELEASABILITY: There are no releasability restrictions on this publication.

OPR: SAF/XCPP Certified by: SAF/XCP-2

(Brig Gen Ronnie Hawkins) Pages: 31

This Air Force Instruction (AFI) im plements DoDI 8510.01, Department of Defense Information Assurance Certification and Accreditation Process (DIACAP), 28 Nove mber 2007, and associated processes outlined on the DIACAP Knowledge Servi ce, for authorizing the ope ration of Air Force Information Systems (ISs) consistent with the Federal Information Security Management Act (FISMA), DoD Directive (DoDD) 8500.01E, Information Assurance (24 Oct 02), and DoDD 8100.01, Global Information Grid (GIG) Overarching Policy (19 Sep 02). Additionally, this AFI im plements the approval to connect process for DoD infor mation systems consistent with Air Forc e Policy Dir ective (AFPD) 33-2, Information Assurance (IA) Program (19 Apr 07); S AF memo, Implementation of Information Technology Lean Reengineering Improvements (28 Nov 05); AF-CIO m emo, IT System Certification and Accreditation Plan of Action and Milestones (POA&M) (9 Dec 04) ; SAF/XC memo, Designated Approval Authority (DAA) for the Air Force Provisioned Portion of the Global Information Grid (5 Aug 05); and SAF/XC mem o, Accountability of Designated Approval Authority (DAA) and Program Manager (PM) for System Security (8 Nov 05). This instru ction applies to all Air Force military, civilian, and contractor personnel und er contract by DoD who devel op, acquire, deliver, use, operate, or manage Air Force inform ation systems, including the Air Nati onal Guard (ANG) and Air Force Reserve Command. The term Major Comm and (MAJCOM), when used in this publication, includes Field Operating Agencies (FOA) and Direct Reporting Units (DRU). Ensure tha t all records created as a result of processes pr escribed in this publi cation are m aintained in accordance with Air Force Manual (AFMAN) 33-363, Management of Records, and disposed of in acco rdance with the Air Force Records Disposition Schedule located at https://afrims.amc.af.mil/. Refer recommended changes and questions about this publication to the Office of Primary Responsibility (OPR) using the AF IMT 847, Recommendation for Change of Publication; route AF IMT 847s from the field through the appropriate functional’s chain of command. Send any im plementing publications of this instruction to HQ AFCA/EVP, 203 W. Losey Street, Room 2200, Scott AFB IL 62225-5222, for review, coordination, and approval prior to publication. Provide a copy of each final supplement to HQ AFCA/EASD, 203 W.

Losey Street, Room 1100, Scott AFB IL 62225-522.

http://www.e-publishing.af.mil/ https://afrims.amc.af.mil/

AFI 33-210 23 DECEMBER 2008 2

Chapter 1

GENERAL INFORMATION

1.1. Purpose. This AFI implements DIACAP for authorizing the operation of Air Force ISs consistent with federal, DoD, and Air Force policies. This AFI along with the IT Lean Re-engineering Guidebook will provide the basic framework of the C &A process, the AF con nection approval process, and procedures for individual task accomplishment. Compliance with this AFI supports the following tenets:

1.1.1. Standardized Air Force C&A approach to meet DoD requirements.

1.1.2. Dynamic process capable of supporting all types of ISs.

1.1.3. Development of secure, interoperable, supportable, sustainable, and useable ISs.

1.1.4. Managem ent of the IA postu re of DoD infor mation systems across the Air Force-provisioned portion of the Global Information Grid (AF-GIG).

1.2. Applicability. This AFI is applicable and m andatory for the development and operation of all Air Force ISs, and applications with the exception of those systems indicated in paragraph 2.2. below.

1.2.1. AF sponsors of Guest ISs (form erly known as Non-Air Force ISs) seeking connection to the AF- GIG must ensure the Air Force connection approva l requirement is followed. This includes ANG ISs wholly funded by ANG.

1.2.2. W hile the Air F orce accepts other serv ice, agency, or departm ent C&A do cumentation, such C&A documentation must be reviewed to ensure that any de trimental impacts on the networks supporting Air Force warfighters are unlikely to occur and that appropriate Ports, Protocols, and Services (PPS) are available to the IS seeking connection.

1.2.3. Joint organizations and Joint bases hosted by the Air Force with Air Force receiving accreditation from the other s ervices will follo w the con nection approval process of this publication. Joint organizations and Joint bases hoste d by the Air Fo rce with Air Force providing C&A servic es will follow the AFCAP in its entirety.

1.3. Objectives. To ensure IA for all Air Fo rce procured Information Systems, and Guest system s operating on or accessed from the AF-GIG. The central component used to satisfy policy requ irements of DIACAP is the com pletion of IT Lean a nd the Security, Interope rability, Supportability, Sustainability, and Usability (SISS U) checklist in the E nterprise Information Technology Data Repository (EITDR). This dynam ic application provi des an autom ated certification and accreditation workflow capability. IA will be im plemented with IA controls as defined by DoDI 8500.2, Information Assurance (IA) Implementation and the DIACAP Knowledge Service, as well a s specific IA controls required by the Air Forc e. Air Force specific IA controls will be lim ited to those that only affect Air Force ISs and will be p osted to the DIACAP Knowledge Service (h ttps://diacap.iaportal.navy.mil). Air Force IA controls must be applied to Air Force ISs; Guest ISs are no t required to implement Air Force component IA controls.

1.4. Transition from DITSCAP to DIACAP. All ISs are to convert from Department of Defense Information Technology Security Certification and Accreditation Pr ocess (DITSCAP) to DIACAP. In addition to the inf ormation below, the IT Lean Re-engineering Guidebook provides additional information for systems in various activities of C&A transition. Th e guidebook is available on the Air Force IA Community of Practice (CoP).

1.4.1. Follow the DIACAP Transition Timeline and Instructions outlined in the DIACAP policy.

AFI 33-210 23 DECEMBER 2008 3

1.4.2. PM/SM (or Inform ation System Owner (ISO) if the IS does not have a PM/SM) shall subm it a copy of the IS’s strategy and schedul e to transition to DIACAP as stated in Enclosure 5 of the DIACAP policy. This document will be uploaded in EITDR as an artifact to the system record. If IA Controls are found to be non-compliant, a POA&M is required to be uploaded in EITDR immediately.

AFI 33-210 23 DECEMBER 2008 4

Chapter 2

ROLES AND RESPONSIBILITIES

2.1. Senior Information Assurance Officer (SIAO). AF-CIO has appointed the Deputy Director, Warfighter Systems Integration and Deploym ent (SAF/XCD-2) as the Air Force SIAO, to direct and coordinate the Air Force IA Program consistent with the strategy and direction of the DoD IA Program.

NOTE: The term “Senior Information Assurance Officer" is synonymous with the term “Senior Agency Information Security Officer” as defined in FISMA. The SIAO shall:

2.1.1. Establish and enforce the C&A process, role s and responsibi lities, and review and approval thresholds and milestones within the Air Force IA Program.

2.1.2. Complete training and m aintain appropriate IA certifications in acco rdance with (IAW ) DoD 8570.01- M, Information Assurance Workforce Improvement Program, 19 December 2005.

2.1.3. May delegate Certification Authority for AF SAP/SAR and AF Space systems to respective Lead DAAs (see para 2.3).

2.1.4. Appoints a prim ary and alternate representatives to serve on the DIACAP Technical Advisory Group (TAG). These representatives will also co-chair the AFCAP TAG.

2.1.5. Approves licensing of Agents to the Certif ying Authority (ACA) thru the use of an ACA licensing guide located on the IA CoP.

2.1.6. Ensures the IT Lean Re-engineering Guidebook is coordinated with SAF/AQ prior to release of new versions.

2.2. Deputy Chief of Staff, Intelligence, Surveillance and Reconnaissance (AF/A2). IAW DoDD 8520.1, AF/A2 is the AF Lead for IA of National a nd AF Sensitive Compartmented Information (SCI) systems (see DoDD 8520.1, Protection of Sensitive Compartmented Information (SCI), and AFPD 14-3.

Control, Protection, and Dissemination of Intelligence Information) and all ISs within AF SCI facilities and is responsible for protection of confidentiality, integrity, and availability of all SCI systems. AF/A2 or other authorized AF entity (e.g. AF Service Cryptological Elem ent) will ensure these requirements are fulfilled in accord ance with national and DoD dir ectives and policies. AF/A2 will be the D AA for AF SCI systems and for Guest SCI systems when authorized by National Authorizing Officials. .

2.2.1. The AF appointed authorized entity for nati onal intelligence system s in addition, shall, as requested by SAF/AA, provide S AF/AA with gui dance concerning security requirem ents and implementation of ISs in SCI facilities to include SAP/SAR programs.

2.3. Lead Designated Accrediting Authority (Lead DAA). The Secretary of the Air Force (SAF) appointed AFNETOPS/CC as the AF-DAA, who is the Lead DAA for all Air Force ISs, excluding multi-component space ISs and S AP/SAR ISs. Ot her Lead DAAs are defined in AFPD 33-2. Lead DAAs shall:

2.3.1. Complete training and m aintain certification IAW DoD 8570.01-M, chapter 5 and CNSSI 4012, National Information Assurance Training Standard for Senior System Managers, June 2004. Proof of training (e.g. certificate) will be included as an artifact to an y IS C&A package for which he/she is the System DAA.

2.3.2. Be able to appoint System DAAs and must hold them accountable for decisions m ade regarding the security of their IS. Appointments will be documented in writing and a copy will be maintained as an artifact in each accreditation packag e for IS Sys tem DAAs are appointed for. System DAAs must meet

AFI 33-210 23 DECEMBER 2008 5

the General Officer (civilian equivalent) requirement in AFPD 33-2. Digital signatures are authorized for the appointment letters.

2.3.2.1. Review written requests for appointm ent of DAA responsibilities. Digital signatures are authorized for the request letters. A DAA ap pointment request letter tem plate resides within the IA Community of Practice (https://afkm.wpafb.af.mil/IA).

2.3.2.2. Ensure System DAAs are identified for onl y ISs under their purview and that System DAAs have the ability to influence the application of resources to achieve acceptable security.

2.3.3. SAP/SAR & Space Lead DAAs will provide reco mmendations to the SIAO for delegation of Certifying Authority for systems under their purview.

2.3.3.1. IAW national ISR authorizing official policy, AF entities will be appointed to perform C A responsibilities for all Air Force national intelligence systems (see para 2.2).

2.3.4. On behalf of SAF and consistent with DoD Principal Accrediting Authority (PAA) guidelines and authorities, may appoint System DAAs for Air Force ISs.

2.4. System Designated Accrediting Authority (DAA). The System DAA shall:

2.4.1. Have a level of authority commensurate with accepting, in writing, the ri sk of operating all ISs under the System DAA’s jurisdiction. Must be resourced with indi viduals knowledgeable in all areas of security to support the System DAA so that t echnically correct assessm ents of the security characteristics are made for IS.

2.4.2. Perform functions outlined in DIACAP, as well as the following guidelin es: DoDD 8500.01E, DoDI 8500.2; AFPD 33-2; and CJCSM 6510.01, Defense-in-Depth: Information Assurance (IA) and Computer Network Defense (CND), 8 March 2006 (Appendix A, Enclosure A).

2.4.3. Complete training and maintain appropriate IA certification IAW DoD 8570.01-M, chapter 5 and CNSSI 4012. Proof of training (e.g. certificate) will be included as an artifact to the IS’s C&A package.

2.4.4. Not further delegate accredit ation authority. However, System DAAs m ay designate others to support the accreditation process (e.g. DAA Representative).

2.4.4.1. Ap point DAA Representatives in writing. Digital signatures ar e authorized for appointm ent letters, which will be an artifact in the accreditation package.

2.4.4.2. Provide written expectatio ns and specific responsibilitie s to the DAA Representative upon appointment.

2.4.5. System DAA may delegate to installation commanders or higher the authority to approve IS access (including stored electronic data or communications) for systems under the commander’s control in order to support authorized investigative activity conducted by Air Force Office of Special Investigations (AFOSI) or other Law Enforcement personnel.

2.5. DAA Representative. If appointed, DAA Representatives shall:

2.5.1. Perform responsibilities as outlined by the System DAA.

2.5.2. Perform all responsibilities outlined by the DAA except formally accept risk for an IS (i.e. cannot sign the accreditation letter).

2.5.3. Make accred itation recommendations to the Sy stem DAA based on input and validation of IA controls from the CAR and/or ACA.

2.5.4. Complete DAA training and maintain appropriate IA certification IAW DoD 8570.01-M, chapter 5 and CNSSI 4012. Proof of training (e.g. certificate) wi ll be included as an ar tifact to the IS’s C&A package.

https://afkm.wpafb.af.mil/IA

AFI 33-210 23 DECEMBER 2008 6

2.6. Information System Owner. Must be a DoD official (O-6 o r civilian equivalent), be a United States citizen, and have a level of authority comme nsurate with operating the IS on behalf of the Air Force so as to manage the mission risk. The ISO shall:

2.6.1. Be appointed by HAF 2 letter or MAJCOM/C V based on the functional mission area of the system. A copy of the appointment letter must be maintained with the accreditation package.

2.6.1.1. M AJCOM/CV may delegate the authority to appoint the ISO to th e MAJCOM functional 2 Letter. HAF 2-letter may delegate the authority to appoint the ISO to the HAF 3-letter.

2.6.1.2. Existing ISOs (i.e. former System DAAs) continue to function as such until a new appointm ent is done for that system.

2.6.2. Perform all roles and responsibilities of a DAA, with the exception of accepting risk for a system, which can only be done by the DAA in the form of an accreditation decision.

2.6.2.1. Ensure the system is deployed and operated according to the agreed-upon security requirements.

2.6.2.2. In line with this, endorse the POA&M.

2.6.3. Ensure that User Representa tives (UR) are appointed for assi gned Air Force ISs according to guidelines established by the GIG PAAs. Appointment of UR will b e in writing. Digital s ignatures are authorized for the appointm ent letters. Appointm ent letters will be an artif act in the accreditation package. (Note: It is ass umed the System DAA, as the Information Owner, will appoint the UR if no ISO role is appointed.

2.6.4. May act as a Rev iewer in the IT Lean process. At a minimum will have visibility to the system’s C&A progress in EITDR and perform a review prior to allowing the system to move into the next IT Lean Phase.

2.6.5. Complete DAA training and maintain appropriate IA certification IAW DoD 8570.01-M, chapter 5 and CNSSI 4012. Proof of training (e.g. certificate) wi ll be included as an ar tifact to the IS’s C&A package.

2.7. Program Manager. In add ition to exec uting duties cited in other policies, Program Managers shall:

2.7.1. When necessary to complete validation procedures for the program , will plan and fund for an independent Agent of the Certifying Authority (ACA) for each IS to accom plish all validation procedures spelled out in DIACAP Knowledge Service.

2.7.2. Ensure POA&M developm ent, tracking, and re solution as well as im plement the corrective actions identified in the POA&M.

2.7.3. Ensure IS details are provided in EITDR and the IT Lean Process.

2.7.4. Enforce DAA accreditation decisions.

2.7.5. Ensure annual security reviews are conducted.

2.8. User Representative (UR). In addition to executing duties cited in other policies, User Representatives shall:

2.8.1. Complete training and maintain appropriate IA certification, if applicable, IAW DoD 8570.01-M.

Proof of training (e.g. certificate) will be included as an artifact to the IS’s C&A package.

2.8.2. Represent the user community for a particular system for DIACAP purposes

2.9. Certifying Authority (CA). The Air For ce SIAO has delegated the role of CA, for all AF ISs, to AFCA/EV. The CA shall:

2.9.1. Complete training and m aintain appropriate IA certification IAW DoD 8570.01-M and C NSSI 4015. Proof of training (e.g. certificate) will be included as an artifact to the IS’s C&A package.

AFI 33-210 23 DECEMBER 2008 7

2.9.2. Perform security validations, conduct a risk analysis, and provide connection recomm endations for SAP/SAR, Space, and Guest systems seeking connection to the AF-GIG, using the IT Lean process.

2.9.2.1. Provide final certification recommendation to support System DAA accreditation decisions and AF-DAA connection approval decisions for AF IS using the IT Lean process.

2.9.3. Appoint CARs at the MAJCOM or Functional level as requested by the MAJCOM or Functional.

2.10. Certifying Authority Representative (CAR).

2.10.1. Complete training and m aintain appropriate IA certification IA W DoD 8570.01-M and CNSSI 4015. Proof of training (e.g. certificate) will be included as an artifact to the IS’s C&A package.

2.10.2. Serve as an active m ember of the DIACAP Tea m from its inception, to assist with planning of IA requirements. These personnel ensure that the implementation and validation procedures are performed as identified in the DIACAP, on beha lf of the CA, if these activities ar e not contracted to an ACA (see 2.11).

2.10.3. Continuously assess and guide the quality and completeness of DIACAP activities, tasks, and the resulting artifacts.

2.10.4. Be directly responsible to the CA, and ultimately the DAA.

2.10.5. W ork with the PM and DIACAP team to pr ovide answers and artifacts to SISSU que stions which consider the overall reliability and viability of the DoD IS.

2.11. Agent of the Certifying Authority (ACA). The ACA is a licensed organization which m ay be contracted by the PM to assist in certification activities and shall:

2.11.1. Report directly to the Air Force Certifyi ng Authority (AFCA/EV) fo r guidance related to validation activities and procedures.

2.11.2. Request licensing approval from the AF SI AO and m aintain license IA W with the ACA licensing guide.

2.11.3. Re spond to PM’s and System DAA’s (or ISO) requests for inform ation regarding their respective systems.

2.11.4. Perfor m comprehensive evaluation of the tech nical and non-technical security features (IA Controls) of an IT system , determine the degree to which the IS meets its specified security requirements, and provide mitigation recommendations,.

2.11.5. Perfor m validation procedu res of each applicab le IA Control as identified in the DIACAP Knowledge Service.

2.11.6. Follow the requirem ents, standards, and processes set by the SIAO and CA in the ACA Licensing Guide, located in the IA CoP.

2.11.7. Meet the intent of DIACAP’s independence between the PM/SM and the individuals performing security testing. Note: The ACA mu st not be part of the developm ent team or program office. The PM/SM/ISO shall only provide funding for orga nizations or contract ors to perform ACA responsibilities.

2.11.8. Complete training and m aintain appropriate IA certification IA W DoD 8570.01-M and CNSSI 4015. Proof of training (e.g. certificate) will be included as an artifact to the IS’s C&A package.

2.12. DIACAP TAG. The DIACAP TAG provides action officer support to the DSAWG in regards to DIACAP. Specifically, the DIACAP TAG implements deliberate methods to incorporate validation and certification needs and lessons learned in the DIACAP Knowledge Service.

2.13. AFCAP TAG. The AFCAP TAG shall:

AFI 33-210 23 DECEMBER 2008 8

2.13.1. Be chaired by DIACAP TAG representatives (see paragraph 2.1.4.).

2.13.2. In clude membership from MAJCOM and S ecretariat/Air Staff functional comm unities (e.g.

USAF/A1, SAF/FM, etc.); one voting member (and sufficient alternates as required) per MAJCOM and Secretariat/Air Staff functional communities. Members should have a broad understanding of DIACAP, AFCAP, and IA Controls.

2.13.3. Recommend proposed C&A process changes to the DIACAP TAG.

2.13.4. Provide configuration control for A FCAP related services (e.g. IT L ean baseline change requests).

2.13.5. Examine C&A related issues that are common across the Global Information Grid entities and recommend changes to the baseline IA Controls.

2.13.6. Review proposed changes to Air Force IA C ontrol sets (located in the D IACAP Knowledge Service) for compatibility with the baseline IA Controls and with other established IA Control sets.

2.13.7. Advise the AFNETOPS Architecture Integrated Product Team or other IA advisory forum s as identified by the Air Force SIAO to determine C&A priorities and resolve cross-cutting issues.

2.14. Information Assurance Managers (IAM) and Information Assurance Officers (IAO). The IAM has primary responsibility for m aintaining situational awareness and initia ting actions to improve or restore IA posture as well as conducting annual security reviews of all IA cont rols and a test of selected IA controls. In addition to the respons ibilities listed in DIACAP, IAMs and IAOs assigned to Air Force ISs will complete and maintain appropriate IA certification IAW DoD 8570.01-M.

2.15. Client Support Administrator (CSA) will ensure functional communities of interest systems, servers, workstations, peripherals, communications devices, and software are on-line and supported, and maintain appropriate IA certification IAW DOD 8570.01-M.

2.16. AFCA/EV. AFCA/EV personnel will p erform C&A post- assessment evaluations to assist in identifying network vulnerabilities, providing AF-DAA visibility to network security operations and capabilities, as well as assisting System DAAs with operational security reviews.

AFI 33-210 23 DECEMBER 2008 9

Chapter 3

POLICY

3.1. AFCAP. AF inform ation system accreditation an d connection approval is accom plished using DIACAP and the IT Lean process described in th e paragraphs below. The IT Lean Re-engineering Guidebook provides further information on the IT Lean process.

3.1.1. Completion of the IT Lean process provides fo r the following possible accreditation decisions by the system DAA:

3.1.1.1. Authorization to Operate (ATO). Authoriza tion granted by a DAA for a DoD IS to process, store, or transmit information. An ATO indicates a DoD IS has adequately im plemented all assigned IA controls to the point where residual risk is accept able to the DAA. ATOs may be issued for up to 3 years. (see Table 3.1. for a correlation of IT Lean and DIACAP processes)

3.1.1.2. Interim Authorization to Operate (IATO). An IATO accreditation decision is intend ed to manage IA security weaknesses. It is not intended to be a devi ce for signaling an evolutionary acquisition. If IA/security is adequate for the intended processing tim e, the version of an DoD information system acquired in one of a planned seri es of acquisition increments or development spirals may (and should) be g ranted ATO, even if ad ditional or enhanced IA capabilities and s ervices are planned for future in crements or spirals. The ATO accreditation decision shoul d not be reserved for DoD information systems for which no change is planned or foreseen. Such thinking engenders an abuse of the IATO accreditation status and an inaccurate po rtrayal of the DoD infor mation system’s IA posture. SAF/XC, as the Air Force Chief Inform ation Officer (AF-CIO), is the o nly Air Force member that may authorize an Air Force IS to operate (receive an IATO) with “CAT I” weaknesses, as described in DIACAP. Delegation below the AF-CIO is not authorized. Likewi se, ISs with CAT I weaknesses, which are accredited by other DoD Compone nts, wishing to connect to the AF-GIG require their component CIO approval, and joint systems require DoD CIO approval.

3.1.1.2.1. I nformation Systems with unm itigated CAT I vulnerabilities must submit their DIACAP packages to the AF-CIO prior to making an accreditation decision.

3.1.1.2.1.1. After validation of the Build & Test phase in IT Lean the CA will inform the ISO (who acts as the affected military commander as described in DIACAP) to justify the critical nature of the system to military operations and the necessity to allow operation of the system to prevent mission impact.

3.1.1.2.1.2. The ISO will send justification to the AF -DAA Rep, who will then submit the DIACAP Executive package to the AF-CIO w ith the c ertification determination and the ISO’s request for an IATO for 180 days. That time will be used to mitigate or correct the identified weakness.

3.1.1.2.1.3. The AF-CIO will p rovide an accreditation d ecision (IATO or DATO) and return the Accreditation decision to the AF-DAA Rep, who will then upload the decision outcome in to EITDR for continued staffing of the Authorization to Connect (ATC) package.

3.1.1.2.1.4. A copy of the AF-CIO authorized IATO w ill then be forwarded to the DoD Senior IA Officer (SIAO) and the System DAA.

3.1.1.3. Interim Authorization to Test (IATT). The IATT accreditation decision is a special case for authorizing testing in an operation al information environment or with live d ata for a specif ied time period. An IATT m ay not be used to avoid ATO or IATO validation activ ity and certification determination requirements for auth orizing a system to operate. If required and requested, an IATT decision will be provided during the Build & Test phase in IT Lean.

3.1.1.3.1. The term “operational information environment” may be defined as a composite of the conditions, circumstances, and influences that aff ect the employm ent of capabilities and bear on the

AFI 33-210 23 DECEMBER 2008 10

decisions of the comma nder. It encompasses physical areas and f actors (of the air, land, m aritime, and space domains) and the information environment. Included within these are the adversary, friendly, and neutral systems that are relevant to a specific joint operation (Joint Publication 3-0).

3.1.1.4. Denial of Authorization to Operate (D ATO). A DAA decision that a DoD IS cannot operate because of an inadequate IA design, failu re to adequately implement assigned IA controls, or oth er lack of adequate security. If the system is already operational, the operation of the system is halted.

3.1.2. A connection approval is the form al approval for an IS to connect to the AF-GIG and the acceptance of risk associated with the IS connec tion by the AF-GIG Designated Accred iting Authority (AF-DAA) or delegated individual. The AF-GIG connection approval au thority shall be delegated only to a qualified government official (see AFPD 33-2) with a rank/grade of O-6 (or civilian equivalent) or higher as follows:

3.1.2.1. Mission Assurance Category (MAC I) syst ems (see DoDI 8500.2 for guidance). Air Force Network Operations (AFNETOPS)/CC or AFNETOPS/CV has connection approval authority.

3.1.2.2. MAC II system s. AFNETOPS/CC del egates connection approval authority to AFCA/CC or

CV.

3.1.2.3. MAC III systems. AFNETOPS/CC delegates co nnection approval au thority to AFCA/EV or EV Deputy.

3.1.2.4. In addition, AFNETOPS/CC may appoint additional connection approval authorities as needed, following the same guidelines as listed in par. 3.1.2.

3.1.2.5. A connection approval decision is acquired by completing the Security discipline of the IT Lean process. AFCA/EV performs an IA review, validat es the im plementation of the IA controls, and provides comments to AFCA/CC, as the AF-DAA Representative, who in turn provides the approval recommendation to AF-DAA. The AF-D AA will then issue a decision for an ATC. By awarding an ATC, the AF-DAA ens ures the IS is certified and accredited (has an approved accreditation decision prior to the ATC decision) and is in compliance with the assigned IA controls to perform mission related activities. More inform ation on t he IT Lean process can be found in the IT Lean Re-engineering Guidebook.

3.1.2.5.1. Connection approval decisions are limited to:

3.1.2.5.1.1. Authorization to Connect (ATC). The offici al AF-DAA approval for system connection to the AF-GIG. The AF-DAA assu mes all risks associated with the connection of the system on the AF- GIG. Usually granted to systems where the acceptable res idual risk after proper co untermeasures and safeguards are implemented

3.1.2.5.1.2. Denial of Authorization to Connect (DATC). AF-DAA d etermination that an IS cannot connect to the AF-GIG because of an inadequate IA design, failure to adequately implement assigned IA Controls, or other lack of adequate security. If the IS is already connected, the connection of the IS must be terminated. All denial decisions m ust be si gned by the AF-DAA, not dele gated to AFCA as for certain approval decisions.

3.1.2.5.2. AF sponsor of Guest ISs is required to en ter minimal system information into EITDR and upload Executive DIACAP package or equivalent in formation to obtain connection approval to the AF- GIG; the IS will be tracked by its DITPR number.

3.1.2.5.2.1. ISs accredited under th e authority of the Director of Natio nal Intelligence (DNI) use the DNI C&A num ber as applic able for entry in to EITDR and will f ollow guidance set by DNI f or registration. These systems will follow the Guest ISs process as applicable for ATC approval.

3.1.3. Systems for which AFNETOPS/CC is the DAA will have an ISO appointed who will have direct oversight and management (as related to Inf ormation Assurance) of the system and will pe rform all responsibilities outlined in this policy and AFPD 33-2.

AFI 33-210 23 DECEMBER 2008 11

3.1.4. POA&M. A POA&M, also referred to as a corr ective action plan, is a tool that identifies tasks that need to be accomplished. It details resources required to accom plish the elements of the plan, any milestones in meeting the task, and scheduled completion dates for the milestones.

The purpose of the POA&M is to assi st agencies in identif ying, assessing, prioritizing, and monitoring the progress of corrective effort s for security weaknesse s found in IT program s and system s. For further POA&M information, refer to the AF POA&M Guide located on the IA CoP.

3.1.4.1. SAF/XCPPI will monitor and track the overall execution of system level IT Security POA&Ms (on behalf of the AF CIO and SIAO) until identified security weaknesses have been closed and the C&A documentation appropriately adjusted.

3.1.4.2. The PM is responsible for im plementing the corrective actions identified in the IT S ecurity POA&M and, with the support and assi stance of the IAM, pr ovides visibility and status to the ISO, DAA, and SAF/XCPPI.

AFI 33-210 23 DECEMBER 2008 12

Table 3.1. DIACAP Activities Mapped to IT Lean Phases.

DIACAP Activity 1

Initiate and Plan IA C&A IT Lean Phase 1

Define Need Register System with DoD Component IA Program

Register System with DoD Component IA Program

Assign IA Controls Assign IA Controls Assemble DIACAP Team Assemble DIACAP Team Initiate DIACAP Implementation Plan (DIP) Initiate DIP

Security Validators ensure appropriate IA Controls are assigned based upon assigned

MAC and Confidentiality Level (CL) DIACAP Activity 2

Implement and Validate Assigned IA Controls IT Lean Phase 2 Design & Review

Execute DIP Populate DIP Conduct Validation Activities Security Validators review DIP to ensure plan is IAW DoD and AF security policies Prepare POA&M IT Lean Phase 3

Build & Test Compile Validation Results in DIACAP Scorecard

Execute DIP Conduct DIACAP Validation Activities

DIACAP Activity 3 Make Certification Determination and

Accreditation Decision

Compile Validation Results in DIACAP Scorecard

Certification Determination Prepare POA&M Issue Accreditation Decision Certification Determination

Issue Accreditation Decision Security Validators verify validation procedure results are IAW requirements

DIACAP Activity 4 Maintain Authorization to Operate and

Conduct Reviews

IT Lean Phase 4 Release & Support

Maintain Situational Awareness Maintain Situational Awareness Maintain IA Posture Maintain IA Posture Conduct Reviews (Review of IA Controls must occur at least annually)

Conduct Reviews (Review of IA Controls must occur at least annually)

Initiate Re-accreditation Initiate Re-accreditation DIACAP Activity 5 - Decommission Retire System

Retire System Information Assurance Manager (IAM) performs annual assessment and Security

Validators perform random assessments to ensure continuing compliance with DIP

AFI 33-210 23 DECEMBER 2008 13

3.2. Registration.

3.2.1. All systems on which AF dolla rs are spent must be registered in EITDR, the of ficial Air Force registration vehicle for ISs, with the exception of those identified by other policy (e.g. SPACE, Special Access Programs/Special Access Required, Joint, etc), to be registered in another registration vehicle.

EITDR will systematically assign a temporary registration number for each IS until the next scheduled replication with DoD I nformation Technology Port folio Repository (DITPR). A DITPR number will then be system atically assigned and included in EITDR as the per manent “official” information technology (IT) registration num ber. See IT Lean Re-engineering Guidebook for procedures on how t o use EITDR.

3.3. IT Lean. The IT Lean process is a tailored version of the DoD 5000 series acquisition process that must be ap plied to sm all IT pr ograms when appropriate and a pproved by the Milestone Decision Authority. When used in conjunction with the IT L ean process, th is tailored process replaces the Certificate of Networthiness and Certificate to Operate processes through the use of the ATC process.

3.3.1. The IT Lean process applies to systems in acquisition or sustainm ent including upgrades or modernizations. A m odified IT Lean/SISSU process will also be u sed for commercial off th e shelf (COTS) and governm ent off the shelf (GOTS) pr oducts being integrated into the AF-GIG.