AFOTEC_OT_of_IA_Guide _2nd_Edition.pdf

PREPARED BY:

AIR FORCE OPERATIONAL TEST AND EVALUATION CENTER

DIRECTOR OF COMMUNICATIONS

AFOTEC OPERATIONAL TESTING (OT)

OF INFORMATION ASSURANCE (IA) GUIDE

nd

Edition

1 July 2009

Refer requests for copies of the OT of IA Guide to AFOTEC/A6, 8500 Gibson Blvd SE, Kirtland AFB, NM

87117-5558

Page Intentionally Left Blank

FORWARD

The AFOTEC OT of IA Guide captures the best practices and corporate knowledge we have gained to effectively and efficiently test and evaluate information assurance.

Specifically, the guide:

Provides organizational-specific information for use across AFOTEC.

Outlines the processes, procedures, checklists, and techniques for addressing information assurance during the various phases of OT&E.

Information assurance shall be evaluated during OT&E for acquisition programs tested by

AFOTEC. Federal Law and DoD Directives require incorporation of information assurance into all phases of an acquisition program’s lifecycle. AFOTEC personnel will work with the respective program offices during early influence to ensure that operational test of information assurance is fully integrated into the test process from its inception. As a Special Interest Item (SII), it is incumbent upon AFOTEC to convey the criticality of the

SII to every test program we conduct in addition to those we support. Test directors will coordinate with the program office and applicable external agencies to accomplish comprehensive information assurance testing and incorporate the IA evaluation into the operational effectiveness and suitability rating of the system under test.

AFOTEC is known for comprehensive, well written test reports that speak directly to the primary issue of a system’s operational effectiveness and suitability. The guidance and samples will assist the test community by providing a solid foundation to accurately plan, test, and evaluate information assurance. Additionally, the OT of IA Guide amplifies

Director, Operational Test and Evaluation’s Procedures for Operational Test and

Evaluation of Information Assurance in Acquisition Programs (21 January 2009).

Stephen T. Sargeant

Major General, USAF

Commander

Record of Changes

Change # Date of Change Title of Change

SUMMARY OF CHANGES:

Incorporates approved Standardized IA Planning and Reporting in OT&E; updated example test plan entries; added additional example test plan entries for Intelligence

Community Directive 503 systems; updated example DMAP entries; added additional example DMAP entries for Intelligence Community Directive 503 systems; incorporated dual rating process to distinguish developer IA control shortfalls from system owner IA control shortfalls; added appendix with standardized IA test report examples for DoDI

8500.2 and Intelligence Community Directive 503 systems; added appendix of acronyms;

added considerations unique to Platform Information Technology (PIT) systems.

FUTURE CHANGES TO THE OT&E GUIDE:

Submit recommendations for future changes to the AFOTEC OT of IA Guide to

AFOTEC/A6 via e-mail.

i

TABLE OF CONTENTS

1. PURPOSE

2. BACKGROUND

3. APPLICABILITY AND SCOPE

4. GENERAL APPROACH

5. IA REQUIREMENTS AND REFERENCES

6. AFOTEC IA OPERATIONAL TESTING PROCESS PURPOSE

6.1 Early Influence

6.2 Initial Test Planning

6.3 Operational Test Planning

6.4 Operational Test Execution and Reporting

6.5 Test Closeout

APPENDICES

APPENDIX A – REFERENCES ....................................................................... A-1

APPENDIX B – GLOSSARY OF IA TERMS . ................................................ B-1 APPENDIX C – ACRONYM LIST . .................................................................. C-1

APPENDIX D – IA-RELATED TEST CAPABILITIES ................................ C-1

APPENDIX E – IA CHECKLIST. ...................................................................... D-1 APPENDIX F – SAMPLE TEST PLAN ENTRIES . ....................................... E-1 APPENDIX G – SAMPLE DMAP ENTRIES. .................................................. F-1

APPENDIX H – IA REPORT SAMPLES . ....................................................... G-1

GUIDANCE FOR OPERATIONAL TESTING

OF INFORMATION ASSURANCE

1 Purpose The Operational Test of Information Assurance (OT of IA) Guide provides

AFOTEC with a consistent approach for assessing and evaluating information assurance

(IA) during operational test activities that aligns with current Department of Defense and

Air Force IA policy and guidance. DoDD 8500.01 defines IA as measures that protect and defend information and information systems by ensuring availability, integrity, authentication, confidentiality and non-repudiation. These measures include providing for restoration of information systems by incorporating protection, detection and reaction capabilities and by providing for Continuity of Operations (COOP). The OT of IA Guide also provides consistency when assessing and evaluating IA of systems developed to

Intelligence Community Directive (ICD) 503 requirements.

2 Background In March 2008, the AFOTEC/CC tasked the Director of Communications

(A6) with codifying AFOTEC’s operational test process for IA. A6, working with representatives from the Intelligence, Analysis and Assessments Directorate (A2A9), Operations Directorate (A3), the Plans and Program Directorate (A5A8), Detachment 3 and Detachment 4, developed the OT of IA guide to describe AFOTEC’s approach to operationally testing IA. In March 2009, A6 was tasked to revise the AFOTEC OT of IA

Guide to incorporate lessons learned and the results of efforts to standardize IA planning and reporting in OT&E. AFOTEC recognizes information and networks must be protected from attack while using technology to link military systems and forces, therefore, AFOTEC considers IA a Special Interest Item and takes the following steps to implement the DOT&E Special Interest Item on IA.

3 Applicability and Scope The OT of IA Guide applies to all AFOTEC Directorates and

Detachments and covers all phases of operational test.

A6 is AFOTEC’s center of excellence for operational testing of IA and is responsible for maintaining the AFOTEC OT of IA Guide. A3 and the gaining Detachment will ensure

IA test requirements are considered for each program during the early influence phase of involvement. Each Detachment will assign IA Subject Matter Expert(s) (SME) to provide the Test Director (TD) IA testing guidance and support during all phases of

OT&E. A6 will provide A3 and Detachment IA SMEs additional technical guidance as needed. IA SME qualifications are described in DoD 8570.01-M, Information Assurance

Workforce Improvement Program Manual. Additional information on IA qualifications is located in IA Requirements and References (Paragraph 5).

4 General Approach AFOTEC, in conjunction with the service OTAs and Joint

Interoperability Test Command (JITC), will ensure adequate IA testing for applicable acquisition systems according to DOT&E IA procedures. AFOTEC will collaborate with applicable external agencies ensuring IA is assessed as early as possible in the acquisition cycle to determine vulnerabilities, risks and mitigating actions. AFOTEC may use integrated developmental test (DT) data to assess and identify significant IA residual risks. When applicable, assessing IA as part of operational assessments (OA) provides insight into progress toward operational effectiveness, operational suitability and system readiness for OT&E. IA evaluations conducted as part of an OT&E will be used in determining operational effectiveness, suitability and overall mission capability. The IA assessment focuses on evaluating the impact of the system’s IA attributes on operational effectiveness, suitability and survivability. Information assurance assessments are accomplished by determining the vulnerabilities and risk associated with the system under test (SUT) or system-of-systems (SoS) under test. The evaluation of IA will reveal the capabilities and limitations of the system’s IA posture and the effectiveness of the applicable IA controls. The evaluation includes protection, detection, reaction and restoration/COOP capabilities and limitations in the presence of realistic information operations (IO) threats and countermeasures (as feasible) using assessment teams to conduct a system vulnerability assessment and penetration testing.

5 IA Requirements and References The program office ensures the system complies with all applicable DoD, Chairman Joint Chiefs of Staff (CJCS), Air Force and Federal

IA policies, regulations and standards. Because of the complexities of IA operational testing in acquisition, AFOTEC/A3 and each Detachment will identify at least one DoD

8570.01-M certified level two IA Management (IAM) subject matter expert (SME) to support testing. AFOTEC mission requirements will dictate the actual number of level two certifications allocated. A6 requires three IA SMEs certified level three under DoD

8570.01. Additional detachment and A6 level three certifications will be considered on a case-by-case basis. Certified IA Technical (IAT) and IAMs will possess the required fundamental IA control knowledge to assess protection, detection, reaction and restoration/COOP capabilities during OT&E against validated threats. The IATs and

IAMs will also help the TD characterize the mission impacts from successful attacks. A listing of applicable references is provided in Appendix A.

6 AFOTEC IA Operational Testing Process

AFOTEC’s test process aligns with the

DOT&E Procedures for Operational Test and Evaluation of Information Assurance in

Acquisition Programs, 21 January 2009. All acquisition programs on the OSD T&E

Oversight list must follow the DOT&E procedures for operational testing of IA, unless they are self-contained systems that do not connect to the Global Information Grid (GIG) and/or National Institute of Standards and Technology (NIST) systems. Commonly, these systems are referred to as Platform Information Technology (PIT) systems. If a program office is considering having their system designated as PIT, they must submit a request to Air Force Network Integration Center (AFNIC)/EV, formerly the Air Force

Communications Agency (AFCA)/EV. While PIT systems have reduced IA requirements compared to GIG-connected systems, they still have IA testing needs and are not waivered for all IA considerations. For PIT systems, AFOTEC IA personnel will review the system’s IA strategy, certification and accreditation efforts and all IA-related developmental testing. AFOTEC’s test team will then make a determination as to whether or not the system’s IA efforts are sufficient and what additional operational testing is required.

The proper conduct of IA testing of acquisition programs requires a collaborative team effort. In general, A3 and the gaining Detachment review documents for required IA verbiage and transition the program to the Detachment after Involvement Determination.

The Detachment IA SME reviews and assists the program office efforts to implement IA

For MOT&E, follow the lead OTA test process as governed by the Memorandum of Agreement on Multi-

Service Operational Test and Evaluation (MOT&E) and Operational Suitability Terminology and

Definitions, Oct 08. The lead OTA should determine which agency to use for conducting vulnerability and penetration testing on Mission Assurance Category (MAC) I, MAC II and MAC III Classified or Sensitive systems.

for their program and to develop/review testable measures. Additionally, IA SMEs assist with conducting IA assessments, coordinating support from external agencies and posting applicable program-related IA documentation on the AFOTEC Management Information

Network. A6 will provide support and guidance in all phases.

6.1 Early Influence

6.1.1 The gaining Detachment, with the assistance of A3O and A6, will use the

DOT&E Procedures for OT&E of IA to determine if the policy applies to the particular program. Early IA activities by the gaining Detachment and A3O include validating that the Program Management Office (PMO) has initiated the DoD Information Assurance Certification and Accreditation Process

(DIACAP). The gaining Detachment, A3O and A6 will develop an understanding of user requirements for the SUT to operate in a secure and net-centric environment. A3O will validate that the PMO has entered the SUT into the AFNIC’s Electronic Information Technology Data Repository (EITDR) for

Air Force managed systems, or other approved database such as the Enterprise

Mission Assurance Support Service (eMASS).

6.1.2 The gaining Detachment IA SME, A3O and A6 confirm Mission Assurance

Category (MAC) and Confidentiality Level (CL) are documented by the program office and user in the IA strategy and Joint Capabilities Integration and Development System (JCIDS) documentation, respectively. A3O and the gaining Detachment IA SME will confirm the adequacy of applicable certification and accreditation documentation, the program’s information support plan (ISP), system CONOPS, Test Evaluation Strategy, TEMP and the

DIACAP Implementation Plan (DIP).

6.1.3 Identifying applicable IA controls for an information system is a critical activity in both the DIACAP and the OT&E process . There are four basic steps in assigning the IA controls: determining the type of information or weapon system (embedded, C4ISR, Automated Information System [AIS], Platform Information Technology products/weapons systems) that have interconnections to external information systems or networks); determining the

MAC and CL for the information system; identifying the baseline IA controls;

and augmenting/modifying baseline IA controls to ensure identification of measures to support operational testing. All IA SMEs should obtain read only permissions in the EITDR to view the Security, Interoperability, Supportability, Sustainability and Usability (SISSU) tab/information for the

SUT to gain insight into the PMO status of these four steps. Information assurance controls in the EITDR are based on MAC and CL should mirror the

DoDI 8500.2 IA controls.

6.1.4 The Detachment IA SME will follow the processes outlined in the AFOTEC

OT&E Guide with support from A3O to develop an initial test design for

OT&E events and resource requirements. In developing the Evaluation

Summary, IA may be incorporated in several ways. If the SUT’s primary function is to provide IA or Computer Network Defense (CND), consider developing an IA critical operational issue (COI). IA may also be a measure of effectiveness (MOE), a measure of suitability (MOS) and/or an operational

See CJCSI 6212.01 for a description of the ISP.

Systems subject to ICD 503 also use the terms ―Level of Concern‖, ―Protection Level‖ and ‖Security

Features and Assurances‖.

capability (OC) with associated measures across applicable COIs. Align measures (Appendices D and E) under applicable COIs. Identify any operational conditions applicable to IA.

6.1.5 In developing a TES/TEMP input, the Detachment IA SME and A3O will include certification strategies (or risk reduction efforts) for IA, as applicable.

The assessment teams should be identified in part II of the TEMP and the assessment resources should be identified in part V. In particular, while conducting an Operational IA vulnerability assessment, all MAC I and II systems and sensitive or classified MAC III systems require a technical and non-technical assessment of technology, people, policy and processes.

Technical assessments include vulnerability assessments using approved assessment tools and penetration testing. Non-technical assessments focus on

IA strategy, certification status and implementation of IA policy and processes.

These same systems require a protection, detection, reaction and restoration/COOP evaluation for an OT&E. Organizations to conduct these assessments/evaluations for DoD 8500 systems include the Service information warfare centers, JITC or National Security Agency (NSA).

When arranging technical testing for ICD 503 systems, ensure that the agency is certified by the

Defense Intelligence Agency (DIA) to perform these tests. The assessment teams should also be invited to participate in all integrated test team (ITT) meetings to ensure required penetration testing/vulnerability assessments are completed prior to IOT&E. The TES/TEMP should also include resource requirements in the resource section (TEMP, part V).

6.1.6 If an early operational assessment is planned, the Detachment IA SME will address IA control implementation progress, IA documentation, IA design and

IA test assets.

6.2 Initial Test Planning (All actions will be conducted by the Detachment IA SME)

6.2.1 Identify and contact the appointed SUT IAM. Review PMO implementation and validation of assigned IA Controls. The DIP execution, validation activities, IT Security Plan of Action and Milestones (POA&M) and the

DIACAP Scorecard are also reviewed.

6.2.2 Plan to assess or evaluate IA control implementation to determine the system’s ability to meet the IA capabilities. Evaluation of the IA controls is easily adaptable to risk management/assessment and provides criteria for entering the dedicated phase of OT&E. The system must conform to the IA controls to receive its interim authorization to operate (IATO) or authority to operate

(ATO), a readiness entrance criterion for OT&E.

6.2.3 Use actual developmental test and evaluation (DT&E) results when appropriate. Record DT&E results according to the criteria and protocols specified in the validation procedure and include these as parts 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).

6.2.4 Identify IA test capability requirements (Appendix D) and potential test venues/simulated scenarios.

The 92 Information Operations Squadron at the 688th Information Operations Wing, performs vulnerability assessments and the 57 IAS at the Air Force Warfare Center, is developing an IA Technical

Assessment (penetration test team) capability that may support these efforts. NSA primarily supports exercises and assessments of other government agencies (acquisition program support is very limited). See

Appendix D for contact information.

6.2.5 Review tasks the PMO will perform to achieve test readiness certification, particularly those tasks related to IA certification of the system. Determine which tasks and deliverables require status monitoring and assign actions through ITT meetings as applicable.

6.2.6 Monitor the preparation of an IT Security POA&M.

6.2.7 Ensure the ITT charter includes IA-related roles and responsibilities.

6.3 Operational Test Planning

6.3.1 Refine the IA operational test measures and evaluation criteria or identify standards (Appendix F). Contact the selected assessment/evaluation team to participate in the test planning process to scope the test. Ensure the assessment team capabilities are commensurate with the threat and expected risks for the program. Begin coordinating approval for IA test teams to access the SUT.

Coordination and approval timelines for Sensitive Compartmented Information

(SCI) level systems may require additional clearances and coordination through the lead OTA. Update test resource plan and TEMP to include costs associated with the assessment team vulnerability/penetration testing. Use the checklist in Appendix E. Use Appendix F as a basis for developing the operational test plan and Appendix G for data management and analysis plan

(DMAP) development.

6.3.2 For programs on DOT&E oversight, obtain informal DOT&E action officer coordination/concurrence to use available DT&E IA data. If DOT&E concurs, use DT&E IA data during Operational Test Readiness Review (OTRR) including electronic warfare (e.g., jamming) and anti-tamper countermeasures

(see AFMAN 63-119, Certification of System Readiness for Dedicated

Operational Testing). Review DIACAP package for status of the assigned

DoDI 8500.2 IA controls. Use the appropriate IA Test Support Checklist available via the link provided in Appendix A.

6.3.3 Detachment IA SME will confirm status of DIACAP package, IATO or ATO memo from designated accrediting authority (DAA) via Certification Authority as entrance criteria for OTRR.

6.4 Operational Test Execution and Reporting

6.4.1 For all test events other than OT&E, conduct assessment according to actions identified in Step 4 of the DOT&E Procedures for Operational Test and

Evaluation of Information Assurance in Acquisition Programs and follow measures detailed in the test plan. Apply measures and evaluation criteria as explained in Appendix F.

6.4.2 For all OT&E events, conduct an evaluation in the operational environment as feasible. Reference Steps 4 through 6 of the DOT&E Procedures for

Operational Test and Evaluation of Information Assurance in Acquisition

Programs and as detailed in the test plan (see Appendix F for examples).

6.4.3 Report results by aggregating external assessment reports, including applicable

DT&E data, into AFOTEC’s final report (see Appendix H for examples).

Develop test team estimate of the level of IA risk to include operational interoperability and key interface protocols. Test team estimates are reported under the net-ready key performance parameter or under IA specific measures, as appropriate.

6.5 Test Closeout

The TD, with assistance of the Detachment IA SME, will submit IA operational testing lessons learned and best practices.

A-1

APPENDIX A - REFERENCES

1 Key IA Documents

a) DOT&E Procedures for Operational Test and Evaluation of Information

Assurance in Acquisition Programs, 21 Jan 2009

b) DoDI 5000.02, Operation of the Defense Acquisition System, 2 Dec 2008

c) DoDD 8500.01, Information Assurance (IA), 9 Jul 2004

d) DoDI 8500.2, Information Assurance (IA) Implementation, 6 Feb 2003

e) DoDI 8580.1, Information Assurance (IA) in the Defense Acquisition System, 9 Jul 2004

f) DoDD 8581.1E, Information Assurance (IA) Policy for Space Systems Used by the Department of Defense, 21 Jun 2005

g) National Institute of Standards and Technology (NIST) special publication

(SP) 800-series (multiple publications/dates)

h) Intelligence Community Directive (ICD) 503, Intelligence Community

Information Technology Systems Security: Risk Management, Certification and Accreditation, 15 Sep 2008

i) AF 33-series publications (multiple publications/dates)

j) AFI 99-103, Capabilities-Based Test and Evaluation, 26 Feb 2008

k) Chairman Joint Chiefs of Staff Instruction (CJCSI) 6212.01E, Interoperability and Supportability of Information Technology and National Security Systems, 8 Mar 2006

2 Key IA Operational Test Planning Documents

a) DoDI 8510.01, DoD Information Assurance Certification and Accreditation

Process (DIACAP), 28 Nov 2007 (for acquisition program management and test activities)

b) AFMAN 63-119, Certification of System Readiness for Dedicated

Operational Testing, 20 Jun 2008, Attachment 10, Information Technology

(IT) and National Security Systems (NSS)

c) CJCSI 3170.1, Joint Capabilities Integration and Development System, 11

May 2005

d) CJCSI 6510.01, Information Assurance (IA) and Computer Network Defense

(CND), 15 Aug 2007

e) Defense Acquisition Guidebook (DAG), sections 4.4.15, 7.2, 7.5 and 9.9.2

(multiple chapterss/dates, for system development and testing considerations)

f) JCIDS documents (multiple publications/dates, for IA requirements)

g) AFPD 10-20, Air Force Defensive Counterinformation (DCI) Operations, 1

Oct 1998

h) AFDD 2-5, Information Operationsand system CONOPS (11 Jan 2005, for operational scenarios)

i) AFI 10-2001, Defensive Counterinformation Planning, Operations and

Assessment, 4 Oct 2001

3 IA Technical Framework (IATF) Integrated architecture products described in the

DoD Architecture Framework (DoDAF) are found at: https://dars1.army.mil

4 IA-Related Test Capabilities As identified in Appendix D.

https://dars1.army.mil/

A-2

5 IA-Related Courses These courses can be accessed online at:

http://iac.dtic.mil/iatac/training.html and https://golearn.csd.disa.mil. IA-specific training, education and certification are governed by DoDD 8570.01, Information

Assurance Training, Certification, and Workforce Management, 15 Aug 2004

(certified current as of 23 Apr 2007) and DoDD 8570.01M, Information Assurance

Workforce Improvement Program, 19 Dec 2005, Change 1, 15 May 2008.

6 Key IA Websites.

a) IA Test Support Checklists: Access available through the AFOTEC portal, Communications (A6), A6 Information Assurance Division, IA OT&E Branch or

(https://infonet.afotec.af.mil/directorates/a6/a6m/IA%20OT_E%20Branch.cfm)

b) IA document library (http://iase.disa.mil/index2.html)

c) IA technology analysis center (http://iac.dtic.mil/iatac/)

d) DIACAP Knowledge Service (https://diacap.iaportal.navy.mil)

e) IA Community of Practice

(https://afkm.wpafb.af.mil/ASPs/CoP/OpenCoP.asp?Filter=OO-SC-IA-01)

f) Defense Acquisition Guidebook, select Chapter 7.5 for IA

(https://akss.dau.mil/dag/DoD5000.asp?view=functional) http://iac.dtic.mil/iatac/training.html https://golearn.csd.disa.mil/ https://www.my.af.mil/gcss-af/USAF/ep/globalTab.do?channelPageId=s6925EC13330E0FB5E044080020E329A9&parentCategoryId=p6925EC14A21B0FB5E044080020E329A9 https://www.my.af.mil/gcss-af/USAF/ep/browse.do?categoryId=p6925EC14A21B0FB5E044080020E329A9&channelPageId=s6925EC13330E0FB5E044080020E329A9&parentCategoryId=p6925EC14A21B0FB5E044080020E329A9 https://www.my.af.mil/gcss-af/USAF/ep/browse.do?programId=t6925EC2ACC770FB5E044080020E329A9&channelPageId=s6925EC13330E0FB5E044080020E329A9&parentCategoryId=p6925EC14A21B0FB5E044080020E329A9 https://infonet.afotec.af.mil/directorates/a6/a6m/IA%20OT_E%20Branch.cfm http://iase.disa.mil/index2.html http://iac.dtic.mil/iatac/ https://diacap.iaportal.navy.mil/ https://afkm.wpafb.af.mil/ASPs/CoP/OpenCoP.asp?Filter=OO-SC-IA-01 https://akss.dau.mil/dag/DoD5000.asp?view=functional

B-1

APPENDIX B - GLOSSARY OF IA TERMS

Accreditation Decision. A formal statement by a designated accrediting authority (DAA) regarding acceptance of the risk associated with operating a DoD information system (IS) and expressed as an authorization to operate (ATO), interim ATO (IATO)or denial of

ATO (DATO). The accreditation decision may be issued in hard copy with a traditional signature or issued electronically, signed with a DoD public key infrastructure (PKI)-certified digital signature.

Adequate Security. Security commensurate with the risk and magnitude of harm resulting from the loss, misuse or unauthorized access to or modification of information.

Adequate security includes assuring DoD information systems operate effectively and provide appropriate confidentiality, integrity and availability, through implementation of assigned IA Controls. The DoD methodology for determining assigned IA Controls is defined in DoDI 8500.1 and the baseline DoD management, personnel, operational and technical IA Controls are established in DoDI 8500.2

Artifacts. System policies, documentation, plans, test procedures, test results and other evidence that express or enforce the information assurance (IA) posture of the DoD IS.

They make up the certification and accreditation (C&A) information and provide evidence of compliance with the assigned IA controls.

Assigned IA Controls. The set of IA controls a given DoD IS must address to achieve an adequate IA posture. Consist of baseline IA controls plus any augmenting IA controls.

Augmenting IA Controls. IA controls that augment baseline IA controls to address special security needs or unique requirements (e.g., cross security domain solutions, health information portability, privacy, etc.) of the IS(s) to which they apply.

Augmenting IA controls may originate from a mission area (MA), a DoD Component, a

Community of Interest or a local system. Augmenting IA controls must neither contradict nor negate DoD baseline IA controls and must not degrade interoperability across the DoD Enterprise.

Authorization Termination Date (ATD). The date assigned by the DAA indicating when an ATO or IATO expires.

Authorization to Operate (ATO). Authorization granted by a designated accrediting authority (DAA) for a DoD IS to process, store or transmit information. An ATO indicates a DoD IS has adequately implemented all assigned IA controls to the point where residual risk is acceptable to the DAA. ATOs may be issued for up to 3 years.

Baseline IA Controls. The minimum set of IA controls that must be addressed to achieve adequate security. Baseline IA controls are prescribed by DoDI 8500.2 (Reference (d)) based on mission assurance category (MAC) and confidentiality level (CL).

Certification. For the purpose of the OT of IA guide, a comprehensive evaluation and validation of a DoD IS to establish the degree to which it complies with assigned IA controls based on standardized procedures.

B-2

Certification Determination. A Certifying Authority’s (CA) determination of the degree to which a system complies with assigned IA controls based on validation results. It identifies and assesses the residual risk with operating a system and the costs to correct or mitigate IA security weaknesses as documented in the Information Technology (IT)

Security POA&M.

Certifying Authority (CA). The senior official having the authority and responsibility for the certification of ISs governed by a DoD Component IA program.

Communities of Interest. The inclusive term used to describe groups of individuals who share information relative to common goals, interests, missions or business processes.

Confidentiality Level (CL). Applicable to DoD information systems, the confidentiality level is primarily used to establish acceptable access factors, such as requirements for individual security clearances or background investigations, access approvals and need-to-know determinations; interconnection controls and approvals; and acceptable methods by which users may access the system (e.g., intranet, Internet, wireless). The DoD has three defined confidentiality levels: classified, sensitive and public.

Denial of Authorization to Operate (DATO). A DAA decision that a DoD IS cannot operate because of an inadequate IA design, failure to adequately implement assigned IA controls or other lack of adequate security. If the system is already operational, the operation of the system is halted.

Designated Approval Authority (DAA). The official with the authority to formally assume responsibility for operating a system at an acceptable level of risk. The term is synonymous with designated accrediting authority.

Developer. Entity responsible for designing and implementing the acquisition system.

The developer must make sure their system is designed with the best information assurance practices as dictated by DoD and Federal Government policy. The developer will make sure all hardware and software elements conform to recognized standards (e.g., Federal Information Processing Standards [FIPS], National Information Assurance

Partnership [NIAP]) prior to the system being placed in operation.

DIACAP Implementation Plan (DIP). Contains the IS’s assigned IA controls. The plan also includes the 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.

DIACAP Knowledge Service (KS). A web-based repository of information and tools for implementing the DIACAP, which is maintained through the DIACAP Technical

Advisory Group (TAG).

DIACAP Package. The collection of documents or collection of data objects generated through DIACAP implementation for an IS. A DIACAP package is developed through implementing the activities of the DIACAP and maintained throughout a system’s life cycle. Information from the package is made available as needed to support an accreditation or other decision such as a connection approval.

B-3

DIACAP Scorecard. A summary report that succinctly conveys information on the IA posture of a DoD IS in a format that can be exchanged electronically. It shows the implementation status of a DoD IS’s assigned IA controls (i.e., compliant (C), non compliant (NC) or not applicable (NA)) as well as the C&A status.

DIACAP Team. Comprised of the individuals responsible for implementing the

DIACAP for a specific DoD IS. At a minimum the DIACAP Team includes the DAA, the CA, the DoD IS program manager (PM) or system manager (SM), the DoD IS IA manager (IAM), IA officer (IAO) and a user representative (UR) or their representatives.

DIACAP Technical Advisory Group (TAG). A formally chartered body established by the Assistant Secretary of Defense for Networks and Information Integration/DoD Chief

Information Officer. Examines and address common C&A issues, including changes to the baseline IA controls across the DoD Component IA programs, IA Communities of

Interest and other GIG entities. The DIACAP TAG also maintains configuration control and management of the DIACAP and all its supporting content on the DIACAP KS.

DoD-Controlled IS. An IS that is established only for DoD purposes, dedicated to DoD processing and is effectively under DoD configuration control (e.g., Net-Centric

Enterprise Services).

DoD Information Assurance Certification and Accreditation Process (DIACAP). The

DoD process for identifying, implementing, validating, certifying and managing IA capabilities and services, expressed as IA controls. Authorizes the operation of DoD ISs, including testing in a live environment, in accordance with statutory, Federal and DoD requirements.

Global Information Grid (GIG). The globally connected, end-to-end set of information capabilities, associated processes and personnel for collecting, processing, storing, disseminating and managing information on demand to warfighters, policy makers and support personnel.

Implementation Procedures. Procedures describing the required steps and guidance for implementing DoD IA controls. Implementation procedures are found in the DIACAP

KS.

Information Assurance (IA). Measures that protect and defend information and information systems by ensuring their availability, integrity, authentication, confidentiality and non-repudiation. These measures include providing for restoration of information systems by incorporating protection, detection and reaction capabilities.

Availability. Timely, reliable access to data and information services for authorized users.

Integrity. Quality of an information system reflecting the logical correctness and reliability of the operating system. The logical completeness of the hardware and software implementing the protection mechanisms and the consistency of the data structures and occurrence of the stored data.

B-4

Authentication. Security measures designed to establish the validity of a transmission, message or originator. A means of verifying an individual’s authorization to receive specific categories of information.

Confidentiality. Assurance that information is not disclosed to unauthorized entities or processes.

Non-repudiation. Assurance the sender of data is provided with proof of delivery and the recipient is provided with proof of the sender’s identity, so neither can later deny having processed the data.

Restoration. (capability) to restore the information system to a fully functional and trusted state.

Protection. (capability) to keep information systems away from intentional, unintentional and natural threats; preclude an adversary from gaining access to information for the purpose of destroying, corrupting or manipulating such information; deny use of information systems to access, manipulate and transmit mission-essential information.

Detection. (capability) to discover threat activity within information systems, such as initial intrusions, during the threat activity or post-activity.

Reaction. (capability) to respond to threat activity within information systems when detected and mitigate the consequences by taking appropriate action.

IA Certification and Accreditation. The standard DoD approach for identifying information security requirements, providing security solutions and managing the security of DoD information systems.

IA Control. An objective IA condition of integrity, availability or confidentiality achieved through the application of specific safeguards or through the regulation of specific activities that is expressed in a specified format (i.e., a control number, a control name, control text and a control class). Specific management, personnel, operational and technical controls are applied to each DoD information system to achieve an appropriate level of integrity, availability and confidentiality.

IA-Enabled Information Technology Product. Product or technology whose primary role is not security, but which provides security services as an associated feature of its intended operating capabilities. Examples include such products as security-enabled web browsers, screening routers, trusted operating systems and security-enabled messaging systems.

IA Manager (IAM). The individual responsible for the information assurance program of a DoD information system or organization. While the term IAM is favored within the

DoD, it may be used interchangeably with the IA title Information Systems Security

Manager (ISSM).

IA Product. Product or technology whose primary purpose is to provide security services

(e.g., confidentiality, authentication, integrity, access control, nonrepudiation of data), B-5 correct known vulnerabilities and provide layered defense against various categories of non-authorized or malicious penetrations of information systems or networks. Examples include such products as data encryptors, firewalls and intrusion detection devices.

Impact Code. A code indicating the consequences of a non-compliant IA control. It is an indicator of the impact associated with exploitation of the IA control.

High Impact Code. The absence or incorrect implementation of the IA control may have a severe or catastrophic effect on system operations, management, or information sharing. Exploitation of the weakness may result in the destruction of information resources and/or the complete loss of mission capability.

Medium Impact Code. The absence or incorrect implementation of the IA control may have a serious adverse effect on system operations, management, or information sharing. Exploitation of the weakness may result in loss of information resources and/or the significant degradation of mission capability.

Low Impact Code. The absence or incorrect implementation of the IA control may have a limited adverse effect on system operations, management, or information sharing. Exploitation of the weakness may result in temporary loss of information resources and/or limit the effectiveness of mission capability.

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

Information Technology (IT). See Information System.

Interim Authorization to Operate (IATO). A temporary authorization to operate a DoD

IS under the conditions or constraints enumerated in the accreditation decision.

IT Security Plan of Action and Milestones (POA&M). A permanent record identifying tasks to be accomplished in order to resolve security weaknesses. Required for any accreditation decision that requires corrective actions, it specifies resources required to accomplish the tasks enumerated in the plan and milestones for completing the tasks.

Also used to document DAA-accepted non-compliant IA controls and baseline IA controls that are not applicable. An IT Security POA&M may be active or inactive throughout a system’s life cycle as weaknesses are newly identified or closed.

Mission Area (MA). A defined area of responsibility with functions and processes that contribute to mission accomplishment.

Mission Assurance. A process to ensure that assigned tasks or duties can be performed in accordance with the intended purpose or plan. It is a summation of the activities and measures taken to ensure that required capabilities and all supporting infrastructures are available to the DoD to carry out the National Military Strategy. It links numerous risk management program activities and security related functions—such as force protection;

antiterrorism; critical infrastructure protection; information assurance; continuity of operations; chemical, biological, radiological, nuclear, and high-explosive defense;

readiness; and installation preparedness—to create the synergistic effect required for

B-6

DoD to mobilize, deploy, support, and sustain military operations throughout the continuum of operations.

Mission Assurance Category (MAC). Applicable to DoD systems, the mission assurance category reflects the importance of information relative to the achievement of DoD goals and objectives, particularly the warfighters' combat mission. Mission assurance categories are primarily used to determine the requirements for availability and integrity.

The DoD has three defined mission assurance categories:

Mission Assurance Category I (MAC I). Systems handling information that is determined to be vital to the operational readiness or mission effectiveness of deployed and contingency forces in terms of both content and timeliness. The consequences of loss of integrity or availability of a MAC I system are unacceptable and could include the immediate and sustained loss of mission effectiveness. MAC I systems require the most stringent protection measures.

Mission Assurance Category II (MAC II). Systems handling information that is important to the support of deployed and contingency forces. The consequences of loss of integrity are unacceptable. Loss of availability is difficult to deal with and can only be tolerated for a short time. The consequences could include delay or degradation in providing important support services or commodities that may seriously impact mission effectiveness or operational readiness. MAC II systems require additional safeguards beyond best practices to ensure adequate assurance.

Mission Assurance Category III (MAC III). Systems handling information that is necessary for the conduct of day-to-day business, but does not materially affect support to deployed or contingency forces in the short-term. The consequences of loss of integrity or availability can be tolerated or overcome without significant impacts on mission effectiveness or operational readiness. The consequences could include the delay or degradation of services or commodities enabling routine activities. MAC III systems require protective measures, techniques or procedures generally commensurate with commercial best practices.

Net-Centric. Relating to or representing the attributes of net-centricity. Net-centricity is a robust, globally interconnected network environment (including infrastructure, systems, processes and people) in which data is shared timely and seamlessly among users, applications and platforms. Net-centricity enables substantially improved military situational awareness and significantly shortened decision making cycles. Net-centric capabilities enable network-centric operations and net-centric warfare.

Platform Information Technology (PIT). PIT refers to computer hardware and software resources that are physically part of, dedicated to or essential in real time to the mission performance of special purpose systems (weapons, training simulators, diagnostic test and maintenance equipment, medical technologies, transport vehicles, etc.). PIT systems reside on a platform performing a war-fighting mission or performing a special-purpose mission. PIT may be physically part of the platform on which it resides, may be stand-alone and may have an interconnection to other PIT (known as a ―PIT-to-PIT

Interconnection‖ or ―PITI‖). PIT does not refer collectively to all IT aboard a platform, but rather to a specific IT system or IT component performing a special-purpose mission.

B-7

Program Management Office (PMO). The organization with responsibility for and authority to accomplish program or system objectives for development, production and sustainment to meet the user’s operational needs.

Residual Risk. Portion of risk remaining after security measures have been applied.

Stand-Alone Information System. An information system operating independently of and without interconnection to any other information system.

System Assurance. The justified measure of confidence that the system functions as intended and is free of exploitable vulnerabilities, either intentionally or unintentionally designed or inserted as part of the system at any time during the life cycle.

System of Systems (SoS). A set or arrangement of interdependent systems related or connected to provide a given capability. The loss of any part of the system will degrade the performance or capabilities of the whole. An example of a SoS could be interdependent information systems. While individual systems within the SoS may be developed to satisfy the peculiar needs of a given user group (like a specific Service or agency) the information they share is so important the loss of a single system may deprive other systems of the data needed to achieve even minimal capabilities.

System Owner. Entity that manages and operates the system in its intended working environment. System owner includes senior leadership, information assurance professionals, system administrators and users. The system owner will make sure proper policies and procedures are established to conform to DoD and Federal Government information assurance guidance during the entire life cycle of the system.

Validation. Activity applied throughout the system’s life cycle to confirm or establish by testing, evaluation, examination, investigation or competent evidence a DoD IS’s assigned IA controls are implemented correctly and are effective in their application.

Validation Procedure. Preparatory steps and conditions, actual validation steps, expected results and criteria and protocols for recording actual results that are used for validating

IA controls. May include associated supporting background material, sample results or links to automated testing tools.

Web Services. Self-describing, self-contained, modular units of software application logic that provide defined business functionality. Web services are consumable software services that typically include some combination of business logic and data. Web services can be aggregated to establish a larger workflow or business transaction.

Inherently, the architectural components of Web services support messaging, service descriptions, registries and loosely coupled interoperability.

C-1

APPENDIX C - ACRONMS

ACRONYM MEANING

AFOTEC Air Force Operational Test and Evaluation Center

ACTFAST

Air Traffic Control Communications Test Facility and Avionics

Systems Test

AFCA Air Force Communications Agency

AFNIC Air Force Network Integration Center

AFWC Air Force Warfare Center

AIS Automated Information System

ATAF AFOTEC Test & Analysis Facility

ATD Authorization Termination Date

ATO Authority to Operate

C Compliant

C&A Certification and Accreditation

C2ISR Command and Control, Intelligence, Surveillance and Reconnaissance

C4ISR

Command, Control, Communications, Computers, Intelligence, Surveillance and Reconnaissance

CA Certifying Authority

CCB Configuration Control Board

CDD Capability Development Document

CENTER Consolidated Enterprise Network T&E Range

CERT Computer Emergency Response Team

CIA Confidentiality, Integrity and Availability

CINC Commander in Chief

CJCS Chairman, Joint Chiefs of Staff

CJCSI Chairman, Joint Chiefs of Staff Instruction

CL Confidentiality Level

CM Configuration Management

CND Computer Network Defense

CNO Computer Network Operation

CNSSI Committee on National Security Systems Instruction

COA Course of Action

COI Critical Operational Issue

COMSEC Communications Security

CONOPS Concept of Operations

COOP Continuity of Operations

COTS Commercial Off The Shelf

CPD Capability Production Document

CT Core Team

DAA Designated Accrediting Authority/Designated Approval Authority

C-2

DAG Defense Acquisition Guidebook

DATO Denial of Authority to Operate

DCI Director, Central Intelligence or Defensive Counterinformation

DCID Director, Central Intelligence Directive

Det Detachment

DIA Defense Intelligence Agency

DIACAP DoD Information Assurance Certification and Accreditation Process

DIP DIACAP Implementation Plan

DISA Defense Information Systems Agency

DISN Defense Information Switched Network

DITSCAP

DoD Information Technology Security Certification and Accreditation

Process

DMAP Data Management and Analysis Plan

DoD Department of Defense

DoDAF DoD Architecture Framework

DoDD Department of Defense Directive

DoDI Department of Defense Instruction

DOT&E Director, Operational Test and Evaluation

DRP Disaster Recovery Plan

DT Developmental Test

DT&E Developmental Test and Evaluation

ECD Estimated Completion Date

EITDR Electronic Information Technology Data Repository eMASS Enterprise Mission Assurance Support Service

EOA Early Operational Assessment

EWS Electronic Warfare Squadron

FIPS Federal Information Processing Standards

FOUO For Official Use Only

FTP File Transfer Protocol

GIG Global Information Grid

GOTS Government Off The Shelf

I&A Identification and Authentication

IA Information Assurance

IAM IA Manager

IAO IA Officer

IAT IA Technical

IATAC Information Assurance Technology Analysis Center

IATF IA Technical Framework

IATO Interim Authorization to Operate

IAVA Information Assurance Vulnerability Alert

IAVM Information Assurance Vulnerability Management

C-3

ICD Intelligence Community Directive

ID Identification

IDS Intrusion Detection System

INFOCON Information Operation Condition

IO Information Operations

IOS Information Operations Squadron

IO-Sim Information Operation Simulation

IOT&E Initial Operational Test and Evaluation

IOW Information Operations Wing

IS Information System

ISP Information Support Plan

ISSM Information Systems Security Manager

ISSO Information Systems Security Officer

IT Information Technology

ITT Integrated Test Team

JCIDS Joint Capabilities Integration and Development System

JIAL Joint Information Assurance Laboratory

JITC Joint Interoperability Test…