netops checklist

DISA NetOpsReadiness Review Process

And

DISA NetOpsProgram/System/Application/Service

Readiness Checklist

Version 2.131 Aug 2007

Unclassified UNTIL FILLED IN

Circle one of the following:

FOR OFFICIAL USE ONLY (mark each page)CONFIDENTIAL (mark each page and each finding)SECRET (mark each page and each finding)

3

4

5

6

7

8

9

10

11

13

141516171819202122

23

24252627

UNCLASSIFIEDNetOps Readiness Review Process and P/S/A/S Readiness Checklist, V2.131 Aug 2007 Defense Information Systems Agency

Document Change Record

Version ID Date DescriptionVersion 1 31 May 2006 Initial ReleaseVersion 2 04 Apr 2007 Updated NRRB Process,

updated Recommended P/S/A/S Documentation, updated Requirements and Question Formatting. Updated CFE reviews (Fig 4), CP-SIB and SEPA information. Merge of Process and Checklist documents into one.

Version 2.1 31 August 2007 Updated with administrative comments received as feedback from formal staffing of Version 2 to DISA Directorates. Substantive comments will be addressed in the next major release.

iUNCLASSIFIED

1234

2829

30

567


Table of Contents

1 Introduction..............................................................................................................................11.1 Background.....................................................................................................................11.2 Purpose of the NetOps Readiness Review Process.........................................................11.3 Scope of the Document...................................................................................................3

2 Definition of NetOps................................................................................................................42.1 NetOps Essential Tasks and Desired Effects..................................................................42.2 NetOps in the DISA Framework.....................................................................................5

3 DISA’s Role in NetOps............................................................................................................63.1 DISA’s NetOps Vision....................................................................................................63.2 DISA’s Implementation of the GIG NetOps Vision.......................................................6

4 Management for NetOps..........................................................................................................84.1 DISA NetOps Goals........................................................................................................84.2 Best Practices to Ensure NetOps.....................................................................................8

5 NetOps Readiness Reviews...................................................................................................105.1 NetOps Readiness Review Process...............................................................................10

5.1.1 NetOps P/S/A/S Readiness Checklist...................................................................115.1.2 CONOPS Template..............................................................................................13

5.2 DISA Roles in Achieving NetOps Readiness...............................................................145.2.1 The Chief Financial Executive Role.....................................................................155.2.2 The Component Acquisition Executive Role.......................................................155.2.3 The Corporate Board Role....................................................................................175.2.4 The GIG Engineering and the Program Executive Offices Role..........................175.2.5 The GIG Combat Support Directorate Role.........................................................185.2.6 The GIG Operations Directorate Role..................................................................195.2.7 Configuration Management Control Process.......................................................195.2.8 Supporting the GIG IA Portfolio (GIAP).............................................................20

6 APPENDIX A.. NetOps Program/System/Application/Service Readiness Checklist..........237 GIG ENTERPRISE MANAGEMENT (GEM).....................................................................27

7.1 Assignment of Project Officer.......................................................................................277.2 CONOPS with NetOps Section.....................................................................................277.3 Designation of DNC for Management and Control......................................................287.4 System Status Reporting Requirements and Procedures...............................................287.5 Situational Awareness (SA)/Critical System Status Reporting.....................................297.6 DISA NetOps Center (DNC) Specific Requirements...................................................307.7 Compliance with DISA OSS.........................................................................................317.8 Filtering of Status Data..................................................................................................317.9 Alternate DNC if the Internal Management System is Not Redundant........................327.10 Automated Drill Down and Query Capability..............................................................327.11 Integration to DISA Help Desk Center.........................................................................337.12 Trouble Management System (TMS)............................................................................337.13 Configuration Management Tracking...........................................................................347.14 Proposed Maintenance Schedule for System Devices/Components.............................347.15 Specialized Training Requirements...............................................................................357.16 Formal Agreements with Outside (Non-DISA) Organizations.....................................367.17 Maintenance of System Diagrams.................................................................................377.18 Approval Process for Changes to the System Architecture..........................................377.19 Identification and Registration of System Interfaces....................................................38

iiUNCLASSIFIED

89

1011

31323334353637383940414243444546474849505152535455565758596061626364656667686970717273747576777879

121314


7.20 Key Performance Metrics and Objectives for Service Level Agreement (SLA) Monitoring....................................................................................................................38

7.21 System Performance Capability....................................................................................397.22 Product Support Plan (PSP)..........................................................................................397.23 Employment and Integration of Core Enterprise Services............................................407.24 Does the System Support IPv6......................................................................................40

8 GIG NETWORK DEFENSE (GND).....................................................................................418.1 DoD Net-Centric IA Strategy........................................................................................418.2 IA Design Tenets...........................................................................................................428.3 Assignment of Mission Assurance Category (MAC)/Sensitivity Levels......................438.4 Integrity and Availability Controls Required for the Assigned MAC Level................438.5 Confidentiality Controls Required for the Assigned Sensitivity Level.........................448.6 Identification of P/S/A/S Need-to-Know Requirements and Access Control Procedures

...........................................................................................................................458.7 Capture and UDOP Display of Security Events............................................................468.8 Automated Capability for Detecting and Reporting P/S/A/S Security Events and

Anomalous Behavior....................................................................................................468.9 IAVM Methodology......................................................................................................47

9 GIG CONTENT MANAGEMENT (GCM)..........................................................................489.1 Metadata........................................................................................................................489.2 Federated Search Aggregators.......................................................................................499.3 Service Discovery Registry...........................................................................................509.4 Roles-Based Access......................................................................................................519.5 Smart Push/Pull of Data................................................................................................529.6 Publication Mechanism for Smart Push/Pull of Data....................................................539.7 Caching, Content Management, or Other “Smart” Delivery Mechanisms...................549.8 Receipt and Delivery Notifications...............................................................................559.9 Definition of User Population/COI...............................................................................559.10 Contingency Operations................................................................................................569.11 Monitoring and Analysis...............................................................................................57

10 APPENDIX B. ACRONYMS..........................................................................................5911 APPENDIX C. REFERENCES........................................................................................6212 APPENDIX D. DEFINITIONS........................................................................................66

iiiUNCLASSIFIED

15161718

8081828384858687888990919293949596979899

100101102103104105106107108109110111112113

192021


1 Introduction

This document contains:

1. Definition of NetOps as referenced from the Version 3 Joint Concept of Operations (CONOPS) for Global Information Grid NetOps (04 Aug 2006)

2. DISA’s role in NetOps as seen by the participating directorates3. DISA management and guidance for NetOps on new acquisition and existing programs

regarding NetOps policy and requirements4. DISA NetOps Readiness Review Process overview for assessing NetOps capabilities in

DISA-managed Information Systems5. An overview of the documents used to assess NetOps readiness6. DISA NetOps Program/System/Application/Service Readiness Checklist

1.1 Background

The Commander, USSTRATCOM (CDRUSSTRATCOM) and the Assistant Secretary of Defense for Networks and Information Integration, ASD(NII) have directed a common NetOps framework and process for execution by DoD elements. DISA supports USSTRATCOM and the Joint Task Force – Global Network Operations (JTF-GNO) vision to lead an adaptive force that assures the availability, delivery, and protection of the Global Information Grid (GIG). The NetOps tasks, effects, and organizational relationships described herein formulate a foundation for the operational future of the GIG, but these will not happen automatically, nor will they occur without significant effort from the entire NetOps community of interest (COI). The NetOps COI is defined as the GIG providers, operators, defenders, and subscribers who possess a fundamental understanding of their responsibilities, and act instinctively to ensure DoD’s intelligence, business, and warfighting domains are a success. This vision requires cooperation, innovation, and execution from all mission partners and everyone who touches the GIG.

1.2 Purpose of the NetOps Readiness Review Process

This NetOps Readiness Review Process document is intended to advance NetOps thinking within DISA and to accomplish the following objectives:

1. Define DISA’s requirements for NetOps that comply with USSTRATCOM NetOps requirements

2. Identify how DISA is supporting NetOps requirements and capabilities for DISA’s Information Systems and operations

DISA’s role in achieving NetOps addresses two aspects of DISA’s products and services:

1. The development of new, transformational capabilities2. The evolution of existing capabilities that are in sustainment

This document shows how DISA’s NetOps Readiness Review Process fits in the broader context of DISA’s related processes and strategies, e.g., the DISA Net-Centric Review Process & Strategy. This document also shows how DISA will use it to guide Agency technical decisions

1UNCLASSIFIED

22232425

114115116117118119120121122123124125126

127128129130131132133134135136137138139140

141142143144145146147148149150151152153154155156157158

262728


on direction of critical Programs/Systems/Applications/Services (P/S/A/S) that support the enterprise, to include applicable Pilots and Projects, and existing legacy systems’ development, fielding, and ongoing maintenance, through a NetOps Readiness Review Process. An electronic copy of this document is available online at the Systems Engineering Dashboard (https://dashboard.ncr.disa.mil/) under the Policy and Guidance section. This review process monitors program directions (or each program’s direction) toward NetOps readiness and potential cross-program disconnects that may affect successful movement toward NetOps. The following figure depicts where NetOps requirements are incorporated into all phases of the Defense Acquisition Management Framework and DISA’s Acquisition Lifecycle.

Figure 1: Integrating NetOps into DISA’s Acquisition Lifecycle

The application of the NetOps Readiness Review Process for the acquisition of managed services, e.g. Net-Centric Enterprise Services (NCES), requires a modified approach than that depicted in Figure 1. DISA follows the precepts of adopt before buy and buy before create. Managed services adopted from the private sector may not necessarily follow the traditional milestone layout and will still be required to ensure an acceptable level of NetOps. The Agency will decide the level of acceptable risk for managed services that perform below DoD NetOps standards. As capability requirements are presented to industry in a Statement of Objectives (SOO), the NetOps requirements must also be included. A risk analysis will be conducted to determine if NetOps can be achieved. The managed service provider (MSP), Program Management Office (PMO), and government acquisition team will work together to establish a Service Level Agreement (SLA) that clearly articulates the interfacing and compliance of key NetOps requirements. Industry’s approach may be different from DoD’s NetOps approach, however both should have the same objectives to assure the availability, delivery, and protection of the GIG.

The MSP is encouraged to cite Best Business Practices in response to the SOO to demonstrate how the NetOps requirements are satisfied. The government acquisition team will evaluate the responses and eliminate those that do not adequately satisfy functionality, cost, schedule, and NetOps requirements. A site review is conducted on each remaining potential best value

2UNCLASSIFIED

29303132

159160161162163164165166167168

169170171172173174175176177178179180181182183184185186187188189

333435

https://dashboard.ncr.disa.mil/


solution. During the site review the MSP must demonstrate the viability of the solution on three levels. Each level is given added weight to the NetOps certification recommendation developed at the conclusion of the site review. First, the MSP must articulate how they deliver the capabilities proposed in response to the SOO. Second, the MSP must present documentation on how those capabilities are delivered. Third, the MSP must demonstrate how the capabilities are delivered. Those areas that do not initially meet NetOps compliance will need a Plan of Action and Milestones (POA&M) with a mitigating strategy to come into compliance and to reduce risks. The government acquisition team will adjudicate the MSP proposal and present associated risks for Agency acceptance or rejection of associated risks. This approach should not delay the quick deployment associated with network-based services or applications delivered, hosted, and managed between PMO and service providers. As a minimum, any managed service operating across the GIG must be in accordance with the NetOps concept, be properly managed, provide adequate defensive mechanisms, and, if appropriate, stage content information to the warfighter and DoD customers. The NetOps Readiness Review Process constitutes a validation of proposed NetOps capabilities and affords the flexibility necessary to ensure essential NetOps information is synchronized to key acquisition decisions.

1.3 Scope of the Document

This document’s primary function is to aid DISA technical personnel in helping the Agency deliver NetOps compliant products and services to its community of users. This document is also intended for DISA’s Senior Program Directors, Program Managers, their Chief Engineers, the Cross Program – Synchronization and Integration Board (CP-SIB), and the GIG Operations Directorate (GO). The document can serve as a guide to help these leaders achieve NetOps requirements and capabilities for DISA. The document may also serve to inform people outside DISA, such as OSD, the Military Services, the Combatant Commands, and other Defense Agencies, on how DISA is implementing its technical approach to achieve NetOps in its products and services.

3UNCLASSIFIED

36373839

190191192193194195196197198199200201202203204205

206207208209210211212213214215216

404142


2 Definition of NetOps

2.1 NetOps Essential Tasks and Desired Effects

NetOps is defined as the operational framework consisting of: three essential tasks (GIG Enterprise Management (GEM), GIG Network Defense

(GND), and GIG Content Management (GCM)) situational awareness C2 that the CDRUSSTRATCOM employs to operate and defend the GIG.

These tasks produce the desired effects of NetOps, which are: Assured System and Network Availability, Assured Information Protection, and Assured Information Delivery. NetOps relies on the application and integration of information technology and standard processes that provide traditional systems and network management (Fault, Configuration, Accounting, Performance, Security (FCAPS)); information and infrastructure protection; and the ability to maneuver information across GIG terrestrial, space, airborne and wireless environments.

Figure 2, titled NetOps Essential Tasks and Effects, was developed to establish a common understanding of the technical composition that must be considered to provide and sustain the effects of NetOps.

Figure 2: NetOps Essential Tasks and Effects

4UNCLASSIFIED

43444546

217

218219220221222223224225226227228229230231232233234235

236237

474849


2.2 NetOps in the DISA Framework

NetOps is the operational construct that the CDRUSSTRATCOM will use to operate and defend the GIG. The goal of NetOps is to provide assured and timely Net-centric services across strategic operational and tactical boundaries in support of the Department of Defense (DoD) full spectrum of warfighting, intelligence and business missions.

An enabling capability of NetOps is achieving shared situational awareness (SA) of GIG system, network and information availability. The primary purpose is to enhance knowledge of the GIG to improve the quality and timeliness of collaborative decision-making regarding the employment, protection and defense of the GIG. To be useful, much of this GIG SA must be available and shared in near real-time by the relevant decision-makers. DISA is to comply with USSTRATCOM and the JTF-GNO in their vision to lead an adaptive force that assures the availability, delivery, and protection of the GIG.

5UNCLASSIFIED

50515253

238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268

545556


3 DISA’s Role in NetOps

3.1 DISA’s NetOps Vision

DISA has a long history in the area of NetOps resulting from its four decades of exercising operational direction and management control of the Defense Information System Network and its predecessor, the Defense Communications System. Drawing upon this experience, the Secretary of Defense and the CDRUSSTRATCOM are looking to DISA to provide the operational elements with the capabilities necessary to execute NetOps for the GIG. Key attributes of the NetOps operational elements include:

An operational hierarchy and horizontal information sharing Global arbitration of NetOps priorities/requirements Global situational awareness Centralized management (monitoring and control) of DISA GIG resources

By providing these capabilities, DISA supports the GIG NetOps vision.

3.2 DISA’s Implementation of the GIG NetOps Vision

To succeed in achieving its vision, DISA will implement and assess NetOps requirements using the process and tools as described in this document. Centralized management of NetOps will be conducted via the DISA NetOps Centers (DNC). The DNC are comprised of the Global NetOps Support Center (GNSC), Theater NetOps Centers (TNCs), GIG Infrastructure Services Management Center (GISMC), and Systems Management Center (SMC). Additional directives on the decision of which center each DISA P/S/A/S is to be managed from are currently in conception and will be referenced in future versions of this document.

The Global NetOps Support Center (GNSC) provides the day-to-day technical operation, control and management of the portions of the GIG that support Global Operations but are not assigned to a COCOM (global backbone portions of the GIG). The GNSC conducts GIG backbone NetOps along with other services as support as referenced in the Joint CONOPS for GIG NetOps.

Each Theater NetOps Center (TNC) is responsible for the effective operation and defense of the GIG within the theater and for providing onsite, theater support for NetOps as referenced in the Joint CONOPS for GIG NetOps.

The GIG Infrastructure Services Management Center (GISMC) is the primary DOD enterprise level applications services NetOps center that supports the GNSC and TNCs with applications layer network and systems management, visibility, monitoring, analysis, planning, and control. The center optimizes the integrated NetOps of the existing and emerging applications networks and services as referenced in the Joint CONOPS for GIG NetOps.

The Systems Management Center (SMC) create points of convergence for problem resolution and form a gateway to aid in facilitating customer support requirements for accessing and using the IT products and services provided by the Computing Services

6UNCLASSIFIED

57585960

269

270271272273274275276277278279280281282283284

285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314616263


Directorate (CSD). The SMC provides operational management oversight, support, and problem resolution for production environments. The SMC is realigned into primary areas reporting to a single Director or Commander as described in the DISA Operations Support Team (OST) CONOPS.

7UNCLASSIFIED

64656667

315316317318319320

686970


4 Management for NetOps

This section describes how DISA is working to achieve NetOps readiness in its key programs. Additional directives on management models are in conception, and will be referenced in future versions of this document. Further financial, programmatic, and technical management activities are discussed in Section 5, NetOps Readiness Reviews.

4.1 DISA NetOps Goals

The NetOps Readiness Review Process has the following strategic goals, each with important second-tier objectives:

Enable effective and efficient GIG NetOps. Identify and reduce technical obstacles to NetOps implementation. Accommodate DoD and industry changes that will affect NetOps, including net-centric

behavior of the GIG, IP Convergence, and IPv6. Foster development and adoption of a joint NetOps architecture that addresses deployed

and sustainment forces. This must support GIG SA, C2, and all three NetOps essential tasks: GIG Enterprise Management (GEM), GIG Network Defense (GND), and GIG Content Management (GCM).

Enable integration of GIG SA, C2, GEM, GND, and GCM data and analysis to exchange data and conclusions where appropriate.

DISA’s NetOps goals are to support the long-haul part of the end-to-end network, including enterprise services and tactical situational awareness, while individual Services and Agencies help provide this capability in the tactical and specialized domains. The overall goal is to assure effective NetOps across data, voice, and video; including applications, services, computing and transport layers by helping to implement the DISA CONOPS template in conformance with the other appropriate NetOps P/S/A/S Readiness Checklist requirements. To assist in reaching these goals, the DISA Field Security Operations (FSO) will be responsible for development of NetOps Training for the DISA workforce.

4.2 Best Practices to Ensure NetOps

There are some best practices that can be found in the systems engineering and integration literature and in experience gained in government and industry to ensure NetOps. Some DISA programs cannot adopt portions of this guidance due to policy and regulations that direct other standards. Thus cost, schedule, and technical risks can be introduced through adherence to policy guidance and regulations. Other documentation may be requested when existing policy and regulation precludes such adherence, such as a POA&M.

NetOps guidance includes:

Cooperation, innovation, and execution from all mission partners and everyone who touches the GIG (refer to the GIG IA Portfolio (GIAP))

Adopt currently available resources before building new capabilities, and refrain from creating new programs until exhausting the preceding approaches

8UNCLASSIFIED

71727374

321322323324325326

327328329330331332333334335336337338339340341342343344345346347348349

350351352353354355356357358359360361362363364

757677


Assure timely and secure Net-Centric capabilities across strategic, operational, and tactical boundaries in support of DoD’s full spectrum of warfighting, intelligence, and business missions

Document operational purpose of the proposed Program/System/Application/Service (P/S/A/S) to include items such as background and objectives, policies and constraints, roles and responsibilities, support environment/lifecycle management in the form of a Concept of Operations (CONOPS)

9UNCLASSIFIED

78798081

365366367368369370371372

828384

UNCLASSIFIED NetOps Readiness Review Process and P/S/A/S Readiness Checklist, V2.131 Aug 2007 Defense Information Systems Agency

5 NetOps Readiness Reviews

5.1 NetOps Readiness Review Process

All DISA Programs/Systems/Applications/Services (P/S/A/S) are subject to NetOps Readiness Reviews. To ensure Agency P/S/A/S are managed and protected as they evolve over their lifecycle, the DISA Field Security Operations (FSO) marries the NetOps vision with their well established security certification and accreditation process during the NetOps Readiness Review. NetOps Readiness Reviews are to be conducted as part of ongoing DISA Component Acquisition Executive (CAE) program reviews to assure that sound acquisition, engineering, and financial practices are being used and that products and services are being developed in accordance with DoD guidance pursuant to major program milestones. The NetOps Readiness Review process will begin during the pre-system acquisition stage to ensure that NetOps is incorporated during concept refinement and as the Initial Capabilities Document is developed and will follow the sequence of events identified below:

1. The NetOps Readiness Review Board (NRRB) will meet on a regular basis to determine which DISA P/S/A/S to include applicable Pilots and Projects are critical technologies that require a NetOps Review. The NRRB is led by GIG Operations (GO) and consists of members from DISA Field Security Operations Division (FSO), GO Technical Director’s Team (GOTD), GO Integration Support Branch (GO51), CAE, GS, GE, and SPI-CIO.

2. The NetOps P/S/A/S Readiness Checklist requirements are introduced to the system program manager (PM), or proponent for non-PM managed system (e.g. Transition Manager, Migration Manager, etc.) during a pre-coordination meeting with the NRRB.

3. The PM works with Directorate Information Assurance Managers (IAM) and FSO to perform a NetOps self-assessment using the Checklist requirements during the concept refinement stage (pre-Milestone A) of the P/S/A/S’s lifecycle. Additional existing documents (e.g., the Capability Description Document that identifies expected P/S/A/S capabilities) are made available to GO staff.

4. FSO acts as the field agent to check the P/S/A/S documents for points of clarification.

Information is validated by the FSO team during both the NetOps Assessment and IA Assessment. The FSO team may conduct informal review meetings with the PMs as needed to ensure all NetOps P/S/A/S Readiness Checklist requirements are met.

5. The PM will provide the completed Checklist and plan of actions and milestones (POA&M) to address any open findings to the FSO team.

6. FSO acts as the NetOps certifier and will provide a NetOps recommendation memorandum for the particular P/S/A/S reviewed to the NetOps Readiness Review Board (NRRB) for formal evaluation.

7. The P/S/A/S and NRRB meet to review the data and assess progress toward the final operational capability of the P/S/A/S in terms of NetOps. The NRRB review identifies

10 UNCLASSIFIED

85868788

89

373

374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417

909192


actions to correct identified NetOps problems and suggests changes in direction. The NRRB will act as the endorser for final NetOps certification.

8. The NetOps required actions are captured, managed, and may be presented to the NetOps

Governance and Advisory Board (NGAB) in the event of any critical issues associated with the NetOps certification. The NGAB meets quarterly or on an ad-hoc basis as recommended and is comprised of senior members from CAE, GO, GS, GE and SPI.

9. Information regarding NetOps Readiness of a P/S/A/S is included with the P/S/A/S’s accreditation request package for an Authority to Operate (ATO) to the CIO who acts as the DISA Designated Accrediting Authority (DAA).

Throughout the P/S/A/S’s lifecycle and review processes, CIO and GO will cooperate from the security and NetOps aspects to inform each other of the P/S/A/S’s status. Information regarding NetOps Readiness will also be submitted at the next GE Systems Engineering Process Assessment (SEPA) with GO staff support. Further details of the NetOps Readiness Review process are detailed below in section 5.2.6.

Figure 3: NetOps Readiness Review Process

5.1.1 NetOps P/S/A/S Readiness Checklist

The NetOps Program/System/Application/Service (P/S/A/S) Readiness Checklist may be found in Appendix A of this document. The NetOps P/S/A/S Readiness Checklist is a Global Information Grid Operations (GO) led initiative and was developed to provide DISA Designated Accrediting Authority (DAA) and Program Managers (PM)s with a mechanism that is used to assess the NetOps Readiness of critical DISA P/S/A/S and applicable Pilots and Projects prior to their introduction, or incorporation into the Global Information Grid (GIG) Architecture.

The NetOps P/S/A/S Readiness Checklist is also designed as a tool to assess existing DISA P/S/A/S. Existing system’s shortcomings that are captured during the review process would

11 UNCLASSIFIED

93949596

97418419420421422423424425426427428429430431432433434

435436

437438439440441442443444445446447

9899

100


serve as key factors and considerations in existing system strategy planning, with the primary focus of attaining an acceptable NetOps Readiness status.

The NetOps P/S/A/S Readiness Checklist will serve as an internal DISA P/S/A/S certification tool. The Checklist is not intended to replace or supersede any similar or pre-existing DoD processes or guidance. Some items contained in the Checklist may overlap those in other established processes. However, the goal of the Checklist is to both validate the completion of other relative system processes while highlighting and re-emphasizing the most critical considerations for ensuring the NetOps readiness of the system.

An electronic copy of this Checklist is available online at the Systems Engineering Dashboard (https://dashboard.ncr.disa.mil/) under the Policy and Guidance section. The NetOps P/S/A/S Readiness Checklist is to be kept simple with the intent that a review can move quickly over items that appear to be compliant. Items that appear to need greater discussion can be probed more deeply to assure review participants that being reviewed is on track to address any apparent challenges in achieving NetOps readiness.

FSO will use the NetOps P/S/A/S Readiness Checklist, along with the other required system documentation as a framework to ensure that no potential security liability exists with the network. FSO will use the Checklist in combination with their normal certification and accreditation activities, with the main focus on the Top DISA P/S/A/S. In addition to conforming to the NetOps P/S/A/S Readiness Checklist attributes, the FSO team may also look at other requirements as appropriate as indicators of NetOps behavior.

FSO will provide a NetOps recommendation memorandum based on the results of the NetOps P/S/A/S Readiness Checklist. FSO will also provide Checklist support in maintaining version control with the GO Technical Director’s Team (GOTD).

5.1.1.1 Checklist Applicability

The Checklist applies to critical DISA Programs/Systems/Applications/Services (P/S/A/S) that support the enterprise, to include applicable Pilots and Projects, and existing systems. Each newly developed and acquisitioned DISA P/S/A/S, existing P/S/A/S, and all system upgrades/modifications must be assessed to verify/validate its security posture, prior to their introduction or incorporation into the Global Information Grid (GIG) Architecture. The Checklist may be applied to an existing P/S/A/S regardless of where it lies in the Acquisition Lifecycle.

Not all P/S/A/S will need to address the full checklist. For example, a P/S/A/S that primarily provides information transport will have minimal, if any, net-centricity issues having to do with data, applications, or the services infrastructure. Similarly, a P/S/A/S that supports directory services may have data-, applications- and services-, and information assurance infrastructure-related net-centricity issues but not transport-related issues.

5.1.1.2 Checklist Requirements

The desired objective of a NetOps Readiness assessment of a DISA P/S/A/S is to verify full compliance with all requirements in sections six through nine of this document. Requirement compliance is verified through the review of required system documentation for completeness

12 UNCLASSIFIED

101102

103104

105448449450451452453454455456457458459460461462463464465466467468469470471472473474

475476477478479480481482483484485486487488

489490491492493

106107108

https://dashboard.ncr.disa.mil/


and accuracy, along with the evaluation of P/S/A/S functionality and interoperability to include compliance with quality of service (QoS) and security standards specified in the applicable policy and system design requirements. Verification of requirement compliance is guided by responses and results to indicators included with each requirement that are compiled from applicable DoD reference documents listed in Appendix C.

A plan of action and milestones (POA&M) is required for those requirements which can not be verified as fully compliant with the applicable policy and system design requirements. The POA&M should lead to the efficient and effective compliance of the requirement or ensure the mitigation of requirement non-compliance to an acceptable level of risk.

The evaluation requirements contained in the Checklist are organized to assess system compliance within the three essential tasks defined in the Joint Concept of Operations for Global Information Grid NetOps: GIG Enterprise Management (GEM); GIG Network Defense (GND) and GIG Content Management (GCM). Additionally, the requirements are further delineated based upon where the system is within its acquisition life cycle, whether newly acquired, or in the maintenance phase, e.g. existing systems. To ensure that the appropriate life cycle specifics are addressed, the proper milestone associated with each individual requirement is identified. The requirement shall be checked by the FSO accordingly as described below:

Open if the stated requirement is non-compliant and requires mitigation. The appropriate Milestone category shall be “checked” as a justification and a POA&M shall be developed to address the open finding.

Not a Finding if the stated requirement is in compliance and justification provided.

Not Reviewed if the stated requirement is not reviewed during current assessment.

Not Applicable if it pertains to a particular life-cycle stage of development for which the P/S/A/S has not yet attained, or not applicable to the P/S/A/S. The appropriate Milestone category shall be “checked” as a justification for the (N/A) designation.

5.1.1.3 Checklist StructureThe NetOps P/S/A/S Readiness Checklist is organized using the three essential tasks that are described in the US Strategic Command (USSTRATCOM) Joint Concept of Operations for Global Information Grid NetOps. Each Checklist item is assigned to an essential tasks category based on its relationship to the high-level definitions below:

Transport: Enterprise Services Management, Systems Management, Network Management, and SATCOM / Electromagnetic Spectrum Management.

Defense: Availability, Authentication, Confidentiality, Integrity, Non-repudiation, Protection, Monitor, Detection, Analyze, and Response.

Flow: Awareness, Access, Delivery and Support

5.1.2 CONOPS Template

The CONOPS offer a place to showcase the NetOps attributes of the program’s products or services and how the program plans to provide those NetOps capabilities. Many of the

13 UNCLASSIFIED

109110

111112

113494495496497498499500501502503504505506507508509510511512513514515516517518519520521522523524

525526527528529530531532533534535

536537538539114115116


requirements addressed in the NetOps P/S/A/S Readiness Checklist will already be documented in the P/S/A/S’s CONOPS. The CONOPS Template is available online from the DISA Systems Engineering Process website in the Toolbox, under “Templates and Forms” located at https://dashboard.ncr.disa.mil/index.php?page=se_temp_form . You can also access the DISA Systems Engineering Homepage by navigating to the DISA Edge portal (CAC required), Functions, Systems Engineering, SE Process (Groupshare). Access to this site may be granted by contacting [email protected]

5.2 DISA Roles in Achieving NetOps Readiness

Many organizations in DISA have roles in assuring that DISA P/S/A/S achieve NetOps readiness. NetOps achievement is also measured by DISA in its corporate level balanced scorecard. This notion of measurement demands a corporate culture change and requires senior management involvement/participation in all phases of execution.

The GIG Operations Directorate (GO) provides guidance and operational requirements that advocate for NetOps technology solutions and enterprise-wide implementation. The DISA Field Security Operations (FSO) will be responsible for development of NetOps Training for the DISA workforce. GO also acts as the NetOps compliance evaluators using tools such as the CONOPS Evaluation Checklist and NetOps P/S/A/S Readiness Checklist. The Component Acquisition Executive (CAE) conducts acquisition management reviews to assure that DoD and DISA acquisition policy are being followed. The Chief Financial Executive (CFE) is responsible for resourcing NetOps capabilities and conducts financially related reviews to assure that programs conform to financial policy and any prospective financial problems are addressed. The GIG Engineering and the Program Executive Offices (Information Assurance/NetOps (IAN), Defense Enterprise Computing Centers (DECC), Net-Centric Enterprise Services (NCES), Teleport and others that may be created in the future) are responsible for development of new project, program and service capabilities. GE holds engineering reviews to assure that sound systems, communications, and software engineering practices are being applied in the P/S/A/S. The Cross Program – Synchronization and Integration Board (CP-SIB) holds cross-program engineering reviews to assure that all affected programs are addressing program interdependencies.

DISA Test and Evaluation Directorate (TED) will assess DISA products and services for their conformance to requirements in the context of NetOps readiness. Computing Services (part of GIG Combat Services or GS) will host DISA’s net-centric products and services in ways that assure fast and economical response to users’ updates of and access to information anywhere in the world. GS is responsible for the evolution of existing capabilities that are in sustainment and will support new NetOps requirements with consistently high quality of service (QoS) and class of service (CoS). The authority to ratify the NetOps certification of a system is the responsibility of the Principal Director for GIG Operations (GO). The Agency Designated Accrediting Authority (DAA) receives a system NetOps readiness certification recommendation from the NetOps Readiness Review Board (NRRB) and/or NetOps Governance and Advisory Board (NGAB). The basis of the NetOps Board’s certification recommendation is the review of a system accreditation request package that is compiled and submitted by the PM or proponent for non-PM managed system (e.g. Transition Manager, Migration Manager, etc.). The system accreditation request package is comprised of a variety of required system documentation, system assessments and certification assessments that includes the NetOps P/S/A/S Readiness Checklist.

14 UNCLASSIFIED

117118

119120

121540541542543544545546

547548549550551552553554555556557558559560561562563564565566567568569570571572573574575576577578579580581582583584585

122123124

mailto:[email protected]

https://dashboard.ncr.disa.mil/index.php?page=se_temp_form


5.2.1 The Chief Financial Executive Role

Program Financial Reviews

DISA’s Chief Financial Executive (CFE) conducts financially related reviews to assure that programs conform to financial policy, are executing spending plans appropriately and are prepared to address prospective financial problems. CFE holds one Annual Program Plan Review and three subsequent Financial Health Assessments. These reviews are typically held early in a new fiscal year to identify any funding issues that need early attention in a given year. Reviews of particularly complicated programs (e.g., with multiple overlapping blocks or phases) may occur with more frequency than for programs with sequential phases or a single sequence of milestones. Figure 4 depicts the nominal CFE schedule for a P/S/A/S.

Figure 4. Nominal Schedule for P/S/A/S Financial Reviews

5.2.2 The Component Acquisition Executive Role

Acquisition Management Reviews

The CAE conducts acquisition management reviews, mainly of programs and major services, to assure that DoD and DISA acquisition policies are being followed. Acquisition Management Reviews are conducted periodically (typically quarterly or semi-annually). More frequent checks are provided at weekly CAE PM meetings. Other acquisition reviews are conducted on programs prior to Overarching Integrated Product Team (OIPT) reviews at OSD and major milestone reviews. Figure 5 depicts the nominal CAE schedule for acquisition management reviews of major programs. Financial, engineering, and net-centricity reviews are conducted in the context of the CAE pre-OSD milestone readiness reviews.

15 UNCLASSIFIED

125126

127128

129

586587588589590591592593594595596597598

599600

601602603604605606607608609610611612

613130131132


Figure 5. Nominal Annual Schedule of CAE Reviews of Major DISA Programs

The Defense Acquisition Management Framework description is provided in Figure 6 below.

Figure 6. Defense Acquisition Management Framework

5.2.2.1 Milestone A

A Milestone A decision usually comes at the end of Concept Refinement when the Milestone Decision Authority (MDA) approves the result of the Analysis of Alternatives (AoA) and the Technology Development Strategy (TDS). Milestone A is the beginning of the Technology Development stage. Concept Refinement and Technology Development constitute the “Pre-System Acquisition” phase of the Defense Acquisition System.

5.2.2.2 Milestone B

A Milestone B decision follows the completion of Technology Development, and begins the “Systems Acquisition” phase of the Defense Acquisition System. The Systems Acquisition phase is comprised of “System Development and Demonstration”, and “Production and Deployment”. System Development and Demonstration (SDD) is comprised of System Integration, and System Demonstration. Milestone B begins at System Integration, and ends the completion of System Demonstration.

5.2.2.3 Milestone C

A Milestone C decision comes at the completion of “System Development and Demonstration”, and begins the “Production and Deployment” phase.

5.2.2.4 Sustainment

Sustainment and Disposal comprise the “Operations and Support” stage of the Defense Acquisition System.

16 UNCLASSIFIED

133134

135136

137614615616617618

619620

621622623624625626627

628629630631632633634635

636637638639

640641642643644138139140


It is assumed that P/S/A/Ss being considered for NetOps readiness for introduction or incorporation into the GIG architecture would have received a Milestone B decision at a minimum; entering the System Development and Demonstration (SDD) phase. Programs entering the acquisition process at Milestone B shall have an approved Initial Capabilities Document (ICD) that provides the context in which the capability was determined and approved, and an approved Capability Development Document (CDD) that describes specific program requirements.

Programs considered for NetOps readiness may already be in the Production and Deployment, or Sustainment phase. In which case, a Milestone C decision would have been received.

The tables in Enclosure 3 of DODI 5000.2, “Operation of the Defense Acquisition System”, May 12, 2003 identify the statutory and regulatory information requirements of each milestone and decision point. Additional non-mandatory guidance on best practices, lessons learned, and expectations is available in The Defense Acquisition Guidebook at http://dod5000.dau.mil/.

5.2.3 The Corporate Board Role

The DISA Corporate Board is briefed on major DISA programs (i.e., ACAT I and Special Interest programs) as significant issues come up that affect strategic DISA directions. There is no explicit schedule for such Board meetings on program issues, except as dictated by major events on programs.

5.2.4 The GIG Engineering and the Program Executive Offices Role

The GIG Engineering and the Program Executive Offices (IAN, DECC, NCES, Teleport and others that may be created in the future) are responsible for development of new P/S/A/S capabilities. The Program Executive Office for Information Assurance/NetOps (PEO-IAN) is subject to the various reviews in preparation to major milestone and other significant events in a program’s life cycle. PEO-IAN has the responsibility for development of new transformational capabilities and for ensuring that DISA products are NetOps ready when fielded. Figure 7 shows a notional schedule for a program over its life and the associated GE review insertion points to support CAE reviews.

17 UNCLASSIFIED

141142

143144

145645646647648649650651652653654655656657658659660

661662663664665666

667668669670671672673674675676677

678146147148

http://dod5000.dau.mil/.


Figure 7. Notional Life-cycle Schedule of GE Systems Engineering Reviews

Systems Engineering Process Assessments

The GIG Engineering organization (GE) conducts systems engineering reviews in preparation to major milestone and other significant events in a program’s life cycle. The Systems Engineering Process Assessements (SEPA) will occur periodically throughout the programs lifecycle. The purpose of the SEPA is to provide a quick, broad life cycle view of a program’s Systems Engineering activities. The SEPA can be used to identify specific issues or risk areas that require more in-depth evaluation. As a part of this review the SEPA Team will verify that the program is aware of the CONOPS Template and the NetOps P/S/A/S Readiness Checklist and has completed the NetOps P/S/A/S Readiness Checklist questions appropriate to the program’s phase in the lifecycle. GE will partner with GO for NetOps assessments presented during a SEPA. All NetOps assessments should be a result from the most recent P/S/A/S’s NetOps Readiness Review, as described above in section 5.1.

5.2.5 The GIG Combat Support Directorate Role

GIG Combat Support Directorate (GS) is responsible for the evolution of existing capabilities that are in sustainment and is being challenged to support new NetOps requirements with consistently high quality of service (QoS) and class of service (CoS). Any program planning to put capabilities into the DNCs must comply with the DNC requirements (DOTMLPF) and integration framework and will need to coordinate with the DISN Operations Support System (OSS) Division (GS28) in order to ensure their integration to the overall DISN OSS Architecture. New systems that are transitioning into GS responsibility and sustainment will have NetOps readiness reviews and certification as part of the transition process. The originating organization will provide the completed checklist and process the readiness review leading to DAA approval.

Systems in sustainment will have a NetOps certification. Those existing systems that do not have certification will initiate the NetOps Readiness Review Process. Once a system is in sustainment and has had an initial or transition readiness review and DAA approval, it will be the system management office’s responsibility to maintain the NetOps P/S/A/S Readiness Checklist. Changes of varying degrees occur in sustainment and the checklist will be kept current for each change. The system management office will initiate a readiness review for any significant change that negatively impacts NetOps. Negative impacts are when any checklist criteria are degraded. All requirements are critical for NetOps compliance, and whatever areas are not met will need a Plan of Action and Milestones (POA&M). The NGAB reviews all changes for systems that are deployed to GNSC and TNC’s and will determine if a readiness review is required.

5.2.6 The GIG Operations Directorate Role

NetOps Readiness Reviews

As noted earlier, NetOps Readiness Reviews are intended to complement overall P/S/A/S reviews led by CAE and conducted with the CFE and GE. The intent of NetOps Readiness Reviews is to assure that DISA P/S/A/S are developed with the appropriate NetOps requirements. The

18 UNCLASSIFIED

149150

151152

153679680681682683684685686687688689690691692693694

695696697698699700701702703704705706707708709710711712713714715716

717718719720721722723

154155156


information for the NetOps assessment of a given P/S/A/S will be a result of the NetOps review that is done by the NetOps Readiness Review Board (NRRB). The NRRB is led by GO and consists of members from FSO, GO Technical Director’s Team (GOTD), GO Integration Support Branch (GO51), CAE, GS, GE, and SPI-CIO. The expected outcomes include a “report card” for the reviewed P/S/A/S and guidance to the P/S/A/S on corrective technical actions to improve getting to NetOps. FSO will provide a NetOps recommendation memorandum based on the results of the NetOps P/S/A/S Readiness Checklist. The P/S/A/S will need to prepare a Plan of Action and Milestones (POA&M) with a mitigating strategy that addresses those areas that do not initially meet NetOps compliance. That information will be used as input by the NRRB to the Principal Director for GIG Operations (GO) who acts as the authority to accredit the NetOps certification of a system. The agency Designated Accrediting Authority (DAA) receives a system NetOps readiness certification recommendation from the NRRB or NGAB.

GO will also act as the evaluators for P/S/A/S’s CONOPS. GO teams will want to participate in the engineering Working Integrated Product Teams (WIPTs) to provide guidance to programs with respect to their moving toward NetOps readiness. Alternatively, the GO teams may wish to review outcomes of WIPT meetings and work any issues with the appropriate participants from the WIPTs and the programs. The CAE may seek GO guidance on selected operational matters during quarterly program reviews as well.

5.2.7 Configuration Management Control ProcessDISA has several processes that are linked for overall management of assurances through control of changes made to hardware, software, firmware, documentation, and tests of Programs/Systems/Applications/Services (P/S/A/S) throughout its development and operational life. The Configuration Control Boards (CCB) are instrumented with common architecture, tools, and capabilities to accept management of DISA P/S/A/S. Example of DISA CCBs include the following:

The DISA NetOps Configuration Control Board is chaired by GIG Operations (GO) and is the approval authority to introduce new initiatives not approved by higher-level boards to the configuration and routine operation of the DISA NetOps Centers (DNC). The DNCs includes the Global NetOps Support Center (GNSC), Theater NetOps Centers (TNCs), and GIG Infrastructure Services Management Center (GISMC). Initiatives could affect policies, procedures, concepts or strategies, as well as tools, technologies, and infrastructure required to support the DNCs (DOTMLPF issues).

The DISN Network Services Configuration Control Board is chaired by GIG Combat Support, Center for Network Services, Operational Support Systems Division (GS28) and is responsible for establishing the initial integrated DISN core and DISN baseline in terms of architecture, functionality and service offering, and for reviewing all subsequent proposed configuration changes to the established baselines, assessing their impact, and rendering a decision concerning approval or disapproval. Examples of changes include any modifications to approved individual service/transport offerings as part of the overall integrated DISN core and DISN architecture.

5.2.8 Supporting the GIG IA Portfolio (GIAP)

19 UNCLASSIFIED

157158

159160

161724725726727728729730731732733734735736737738739740741742

743744745746747748749750751752753754755756757758759760761762763764765766

767768

162163164


The Deputy Secretary of Defense approved DoDD 8115.01, providing instruction on how to perform portfolio management activities for all GIG Information Technology (IT) investments. IT investments will be managed as portfolios to:

Ensure IT investments support the Department’s vision, mission, and goals Ensure efficient and effective delivery of capabilities to the warfighter Maximize return on investment to the Enterprise using the GIG architecture, plans, risk

management techniques, capability goals

Three major DoD IT Mission Areas include Business, Warfighting, and Enterprise Information Environment, which is comprised of four domain areas (Core Enterprise Services, Computing, Transport, and Information Assurance).

DoD IT Portfolio

EIE Mission AreaPortfolio

GIG IAPortfolio

AMMRoadmap

DTGRoadmap

AISRoadmap

INRRoadmap

CONRoadmap

HAERoadmap

Foundational ActivitiesRoadmap

DoD IT Portfolio

EIE Mission AreaPortfolio

GIG IAPortfolio

AMMRoadmap

DTGRoadmap

AISRoadmap

INRRoadmap

CONRoadmap

HAERoadmap

Foundational ActivitiesRoadmap

Figure 8. DoD IT Portfolio

Figure 8 depicts the GIG IA Portfolio (GIAP) as part of the DoD IT Portfolio. The GIAP is designed to analyze, select, control and evaluate critical IA capabilities and associated investments to enable information superiority. The purpose of GIAP is to:

Develop an integrated IA operational capability roadmap that is accepted community-wide

Develop an investment strategy for IA portfolio to drive investment decisions Continuously analyze and refresh investment strategy to maximize operational benefit. Provide an opportunity to partner with IA community members Optimize existing funding and justify additional funding to meet IA priorities

20 UNCLASSIFIED

165166

167168

169769770771772773774775776777778779780781

782783784785786787788789790791792793794795

170171172


Figure 9. DoD Governance IA Portfolio Management

Figure 9 shows DoD Governance of IA Portfolio Management. Portfolio Management is defined as a holistic view of DoD’s GIG IA Strategy with:

1. Inventory of IA projects (Baseline is the Defense Information Assurance Program (DIAP) Database)

2. Create a master Schedule3. Evaluate Portfolio for synchronization, gaps, duplication, risks4. Impact the Program Objective memorandum (POM) process5. Cradle to grave investment strategy (life cycle management (LCM))

Under the GIAP there are six Capability Roadmaps:

1. Assured Information Sharing (AIS): Provides the user with the right information, at the right time, at the right place, and displayed in the right format, while denying adversaries access to that same information or service.

2. Assured Mission Management (AMM): Provides the ability to coordinate and de-conflict system configuration and resource changes, mission priority changes, and cyber attack responses as well as includes the ability to assign, prioritize, modify, and revoke user and system roles, access rights, COI membership and resources.

21 UNCLASSIFIED

173174

175176

177

796797798799800801802803804805806807808809810811812813814815816817

178179180


3. Confidentiality (CON): Ensure information is not made available or disclosed to unauthorized individuals, entities, devices, or processes.

4. Defend the GIG (DTG): Monitors, analyzes, detects, and responds to potential and actual unauthorized network activities, as well as unintentional non-malicious user errors that could potentially cause harm.

5. Highly Available Enterprise (HAE): Ensures GIG computing and communications resources, services, and information are available and accessible.

6. Integrity and Non-Repudiation (INR): Integrity/Non-Repudiation capabilities provide assurance that information does not change from production to consumption, or from transmission to receipt. It also guarantees that neither recipient can deny the processing or reception of the data.

Additional information on the GIAP is available online (https://gesportal.dod.mil/sites/gigia/default.aspx).

6 Appendix A. NetOps Program/System/Application/Service Readiness Checklist

Classification is based on classification of network reviewed:Date of NetOps RR:________ _____________

22 UNCLASSIFIED

181182

183184

185818819820821822823824825826827828829830831832833834835836837838839840841842843844845846847848849850851852853854855856857858

859860861862863

186187188

https://gesportal.dod.mil/sites/gigia/default.aspx


P/S/A/S Reviewer Phone

Previous RR Y N Date of Previous RR NA VC06 Available Y N

Number of Current Open Findings

P/S/A/S Information:

P/S/A/SName

Program ManagerPhone

P/S/A/S Tracking # (DITPR)DAA: CIO [ ] GO [ ] J6 [ ] DSS [ ] OTHER [ ]

Site Information:

SiteName

Address

Phone

Site Personnel Information:Position Name Phone Number Email Area of Responsibility

IAM

IAO

NSO

NM

The Program/System/Application/Service (P/S/A/S) documentation provides the framework for the NetOps P/S/A/S Readiness assessment prior to incorporation into the GIG.

The list of documentation provided in Table 1-1 is not intended to be all-inclusive, but provides those documents (including the NetOps P/S/A/S Readiness Checklist) recommended for a system

23 UNCLASSIFIED

189190

191192

193

864865866

867868869

870871

872873874875876877194195196


PM, or proponent for non-PM managed systems, to submit for the system accreditation request package. The list also comprises the minimum recommended documentation that may be provided to the NetOps Readiness Review Board for review and consideration of P/S/A/S NetOps readiness certification.

Table 1-1 RECOMMENDED P/S/A/S DOCUMENTATION FOR NETOPS REVIEW

Item Documentation Yes No Notes for the Evaluator

1.

Security Certification and Accreditation documentation (DIACAP): The DIACAP package is a set of documentation submitted to the Designated Accrediting Authority (DAA) for authorization to operate (ATO).

2.

DoD Architecture Framework: The DoDAF is a framework for development of a systems architecture or enterprise architecture (EA). DoDAF views are organized into four basic view sets: overarching All View (AV), Operational View (OV), Systems View (SV), and the Technical Standards View (TV).

3.

Approval/Interim Approval to Operate (I/ATO), Approval/Interim Approval to Test (I/ATT), and Approval/Interim Approval to Connect (I/ATC)Signed documentation by the Designated Accrediting Authority (DAA) authorizing operation of a system for a designated period of time. (In most cases will be part of the SSAA*)

4. P/S/A/S Concept Of Operations (CONOPS): Outlines assumptions or intent in regard to the operations, defense, NetOps, and C2 of a program. (May be part of SSAA)

5.P/S/A/S Operation Manuals: Provide operational instructions that can be used by system administrators to properly configure, manage, and troubleshoot a system.

6.

Configuration Management Plan: Identifies the organizations and procedures to be used by the developers to perform activities related to configuration management. (May be part of SSAA)

7.

Network/System Management Plan: Defines how the network or system will be managed, and possibly what Enterprise management tools will be used for performance monitoring, change and configuration management, reporting, etc.

8.Continuity of Operations Plan (COOP): Describes preparations in place for survival of operations in the case of a catastrophic event. (May be part of SSAA)

24 UNCLASSIFIED

197198

199200

201878879880881882883884

202203204



9.

Disaster Recovery Plan (DRP): Describes the data, hardware, and software critical for an organization to restart operations in the event of a natural or human-caused disaster. (May be part of SSAA)

10.

Systems Integration Test, Security Verification, Site and User Acceptance Test Reports: Reports from security, testing and evaluations as part of the C&A process.

11.

Memorandums of Agreement or Memorandums of Interconnection (MOA/MOI): Document written between parties to cooperatively work together on an agreed upon project or meet an agreed upon objective. The purpose of an MOA is to have a written understanding of the agreement between parties. (May be part of SSAA)

12.System Deployment Schedule: Provides a deployment timeline for a system, accounting for the end user, operator, and sustainment communities.

13.Product (or Logistics) Support Plan: Outline how logistics support and sustainment of a system will be managed over its life cycle.

14.

Functional Requirements Specification/ System Statement of Requirement (SOR): Describes how the user intends to use the system and the expected performance. Issues of security and data integrity should also be included. Functional requirements specify specific behaviors of a system. The SOR details requirements that the system will provide.

15.Implementation Plan: Outlines a program’s strategy for successful execution of a program’s system/service/capability.

16.

FSO Test Reports and IA Controls: A roll-up of a series of physical security assessments and scans on a program’s hardware assets. Hardware is configured according to the required Security Technical Implementation Guides (STIGs), and scanned for potential vulnerabilities.

17.

DISA System Accreditation Checklist and CIO Accreditation Memo: Appendix R contains the CA’s recommendation to the DAA and the authorization to operate in a formal memorandum signed by the DAA, which is the accreditation memorandum.

25 UNCLASSIFIED

205206

207208

209

210211212



18.

NetOps P/S/A/S Readiness Checklist: Internal DISA P/S/A/S certification tool that evaluates compliance within the three essential tasks defined in the Joint CONOPS for GIG NetOps: GIG Enterprise Management (GEM); GIG Network Defense (GND) and GIG Content Management (GCM).

*Systems Security Authorization Agreement (SSAA) – A living document that defines all system specifications including the system mission, target environment, target architecture, security requirements and applicable access policies. The SSAA also describes the applicable planning and certification actions, resources and documentation required to support the certification and accreditation. In essence, the SSAA is the vehicle that guides the implementation of information security. The SSAA is updated and revised during each of the four phases.

The DIACAP Comprehensive Package includes:

System Identification Profile (SIP) - Part of the Executive Package, which contains the minimum required information for an accreditation decision. An information base, i.e., a document, collection of documents, or collection of data objects within an automated information system that uniquely identifies an information system within the DIACAP and contains established management indicators, e.g., DIACAP status.

DIACAP Implementation Plan – Contains the information system’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.

Certification Documentation - A collection of documents that describes the security posture of the system, an evaluation of the risks, and recommendations for correcting any deficiencies.

DIACAP Scorecard - Part of the Executive Package, which contains the minimum required information for an accreditation decision. A summary report that shows the certified or accredited implementation status of a DoD information system’s assigned IA Controls and supports or conveys a certification determination and/or accreditation decision. The DIACAP Scorecard is intended to convey information about the IA posture of a DoD information system in a format that can be easily understood by managers and be easily exchanged electronically.

Plan of Action & Milestones (POA&M) - Part of the Executive Package, which contains the minimum required information for an accreditation decision. A POA&M is required for any accreditation decision that requires corrective actions. It is a tool identifying tasks that need to be accomplished. It specifies resources required to accomplish the elements of the plan, any milestones in meeting the task, and scheduled completion dates for the milestones.

26 UNCLASSIFIED

213214

215216

217

885886887888889890891892893894895896897898899900901902903904905906907908909910911912913914915916917918919920921922923

218219220


7 GIG ENTERPRISE MANAGEMENT (GEM)

7.1 Assignment of Project Officer

Has a DISA NetOps Center (DNC) representative been assigned to serve as a Project Officer responsible for coordinating the deployment of this system? Identify name(s) and role(s).

Procedure: Verify assignment.

References(s): Defense Information Systems Agency Instruction (DISAI) 310-220-1; DODI 5000.2, Para 3.4; DCID 6/3 para 2.B.4.e(4), 2.B.4.e(5); DoDI 8500.2 Encl 4, Att 1,2,3 DCSD-1; DCID 1/19 Sect 5 and 10

Indicators:o Appointment directive.o Personnel know are familiar with the identity of the

Project Officer.

Comments:

Milestone A Requirement: Technology Development

PDI Short Description: No DNC Representative has been assigned to serve as Project Officer.

Open Not a Finding Not Reviewed Not Applicable

7.2 CONOPS with NetOps Section

Has a CONOPS been written for the Program/System/Application/Service (P/S/A/S) that includes a NetOps section?

Procedure: Verify documentation.

References(s): Joint Concept of Operations for Global Information Grid NetOps, DISA CONOPS Template.

Indicators:o Included in CONOPS.

Comments:


PDI Short Description: NetOps is not included in the CONOPS.


27 UNCLASSIFIED

221222

223224

225

924

925926

927928

929

226227228


7.3 Designation of DNC for Management and Control

Has the PM worked with the DNC(s) to define a set of information necessary to manage the P/S/A/S? Procedure: Verify CONOPS includes an appropriate determination of how the DNC(s) will manage this capability.

References(s): Defense Information Systems Agency Instruction (DISAI) 310-220-1; Joint Concept of Operations for Global Information Grid NetOps.

Indicators:o Stated in the CONOPS or fielding document.o DNC acknowledgement or relationships.

Comments:


PDI Short Description: No DNC has been designated to manage and control the P/S/A/S once it is declared operational.


Have the DNC’s Tactics, Techniques & Procedures (TTPs) for system status reporting been included in the P/S/A/S design and implementation documents? Procedure: Interview the Network Security Officer (NSO) and review implementation documentationReferences(s): Joint Concept of Operations (CONOPS) for Global Information Grid (GIG) NetOps, Version 3, 4 August 2006; CJCSI 6215.02A; DISAC 310-55-1, “Status Reporting for the Defense Communications System”; DODI 5000.2, Para 3.8 Indicators:o The DNC has documented status reporting

requirements for the P/S/A/S.o The P/S/A/S documentation satisfies the DNC defined

requirements.o Requirements Traceability Matrix (RTM) showing

DNC requirements and system solutions to meet those requirements.

Comments:

Milestone B Requirement: System Development and Demonstration

PDI Short Description: The P/S/A/S status reporting requirements and procedures have not been established.


7.4 System Status Reporting Requirements and Procedures

28 UNCLASSIFIED

229230

231232

233930

931

932933

234235236


7.5 Situational Awareness (SA)/Critical System Status Reporting

Does the P/S/A/S report the status data on fault, configuration, security and performance data using GEM, GND, GCM tools and capabilities? Identify the tool or capability.

Procedure: Review P/S/A/S documentation.

References(s): Joint Concept of Operations (CONOPS) for Global Information Grid (GIG) NetOps, Version 3, 4 August 2006 (Situational Awareness) ; DODI 5000.2, Para 3.7; DoDI 8500.2 Encl 4, Att ½/3 DCHW-1, DCFA-1, DCPP-1, DCPR-1, DCSW-1; DoDD 5220.22M, Sec 8-101; DCID 6/3 Sec 2.B.4.b.(4), 2.B.5.c.(4), 5.B.1.a.(2), 5.B.2.a.(4)

Indicators:o Sys logs being exported.o SNMP or other fault system integrated into the SA

system.

Comments:


PDI Short Description: Critical system devices do not report status to an internal Management System.


7.6 DISA NetOps Center (DNC) Specific Requirements

Have specific DNC NetOps requirements been met, and have all major issues that affect policies, procedures, concepts or strategies, as well as tools, technologies, and infrastructure required to support the DNCs been properly satisfied?

Procedure: Review requirements documentation.

References(s): Defense Information Systems Agency Instruction (DISAI) 310-220-1; DODI 5000.2, Para 3.4 and 3.8; DCID 6/3 para 2.B.4.e(4), 2.B.4.e(5); DoDI 8500.2 Encl 4, Att 1,2,3 DCSD-1; DCID 1/19 Sect 5 and 10; NISPOMSUP Ch 8 Sec 4Indicators:o The DNC representative reviewed the DNC specific

requirements and has taken/assigned various tasks to manage and control the P/S/A/S once it is declared operational.

o The DNC has the ability to satisfy critical requirements (e.g., requirements for security, reliability, real-time responsiveness, and correctness) under all conditions.

o Doctrine, Organization, Training, Materiel, Leadership and Education, Personnel and Facilities (DOTMLPF) requirements.

Comments:


PDI Short Description: DNC requirements have not been met.

29 UNCLASSIFIED

237238

239240

241

934

935

242243244



7.7 Compliance with DISA OSS

Do the P/S/A/S’s management tools and capabilities fit into the overall DISA Operations Support System (OSS) Architecture?

Procedure: Review P/S/A/S documentation. Should comply with DISA OSS Architecture.

References(s): Joint Concept of Operations (CONOPS) for Global Information Grid (GIG) NetOps, Version 3, 4 August 2006 (Situational Awareness) ; DODI 5000.2, Para 3.7; CJCSM 6510.01 para 2.c

Indicators:o System Requirements Traceability Matrix (RTM)

includes DNC requirements.o System Interface Control Document (ICD) identifies all

information exchange requirements.

Comments:


PDI Short Description: The P/S/A/S’s management data is not compatible with the DISA OSS Architecture.


7.8 Filtering of Status Data

Is the P/S/A/S management data compliant or filterable for incorporation into a DISA Network Operations Common Operational Picture (COP)?

Procedure: Review P/S/A/S architecture.

References(s): CJCSI 6211.02B, “Defense Information System Network (DISN): Policy, Responsibilities and Processes”, 31 July 2003, Encl B; GIG Capstone Requirements Document; DODI 5000.2, Para 3.7

Indicators:o System Element Management System (EMS) data is

entered in the DoD Metadata Registry.o System Ports and Protocols are registered IAW DoDI

8551.1.o Identify P/S/A/S EMS data that are filterable for

incorporation into a DISA Network Operations COP. (User Defined Operational Picture (UDOP), NetCOP, INMS, Amberpoint)

Comments:

Milestone B Requirement: System Development and DemonstrationPDI Short Description: The P/S/A/S is not capable of providing status data that can be filtered for incorporation into a DISA COP.

Open Not a Finding Not Reviewed Not Applicable30 UNCLASSIFIED

245246

247248

249

936

937

250251252


7.9 Alternate DNC if the Internal Management System is Not Redundant

In the event of a DNC failure, can the P/S/A/S’s management data be redirected to an alternate DNC?

Procedure: Interview the NSO.

References(s): Joint Concept of Operations (CONOPS) for Global Information Grid (GIG) NetOps, Version 3, 4 August 2006; DODI 5000.2, Para 3.8; CJCSM 6510.01 para 2.c

Indicators:o CONOPS.o System COOP.

Comments:

Milestone C Requirement: Production & Deployment/Operations & Maintenance

PDI Short Description: The P/S/A/S’s EMS data cannot be redirected to an alternate DNC.


7.10 Automated Drill Down and Query Capability

Does the P/S/A/S support external queries using NetOps technology (UDOP, NetCOP, INMS, Amberpoint)?

Procedure: Interview the NSO.

References(s): Joint Concept of Operations (CONOPS) for Global Information Grid (GIG) NetOps, Version 3, 4 August 2006; DODI 5000.2, Para 3.8 Indicators:o Drill down and query specific system component

configuration information to facilitate situational awareness.

o Compliance with Tele-Management Forum, Multi-Technology Network Management (MTNM) Solutions Suite.

o Compliance with Tele-Management Forum Multi-Technology Operations System Interface (MTOSI) Solutions Suite.

o The Internal Management System interfaces to and correlates with other relevant system management tools and data.

Comments:


PDI Short Description: The P/S/A/S does not support external queries using required NetOps technologies.


31 UNCLASSIFIED

253254

255256

257938

939940

258259260


7.11 Integration to DISA Help Desk Center

If PM has established a separate Help Desk, is it integrated and compliant with the DNC Trouble Management System (TMS) policy?

Procedure: Interview the NSO. Trouble tickets must link to Help Desk and DNC process.

References(s): DODI 5000.2, Para 3.8

Indicators:o Integration plan addresses trouble management process

and relationship with DNC.o GO and DNC involvement is documented.

Comments:


PDI Short Description: The P/S/A/S integration plans do not include integration to an existing DISA Help Desk Center.


7.12 Trouble Management System (TMS)

Does the P/S/A/S seamlessly integrate with the existing DISA TMS?

Procedure: Interview the NSO to ensure the P/S/A/S is compliant with this requirement.

References(s): Director’s Policy Letter: Standard Trouble Management System; DODI 5000.2, Para 3.8

Indicators:o PM using the DISA-TMS.o System automated trouble tickets are generated in

response to alarms and performance thresholds.o Trouble tickets are automatically cleared when alarms

are cleared.o Manual ticket generation capability.

Comments:


PDI Short Description: TMS is not being used as the corporate trouble-ticketing system.


32 UNCLASSIFIED

261262

263264

265941942

943

944945

266267268


7.13 Configuration Management Tracking

Is there an automated configuration management (CM) process for the P/S/A/S?

Procedure: Interview the NSO to ensure the P/S/A/S is compliant with this requirement.


Indicators:o The P/S/A/S has established a plan and business

processes for entering and maintaining configuration management data.

O The P/S/A/S has designated overall CM responsibility to a person and users have attended CM training.

O The P/S/A/S has assigned a member to the DISN Configuration Control Board.

Comments:


PDI Short Description: There is no automated CM process.


7.14 Proposed Maintenance Schedule for System Devices/Components

If P/S/A/S devices/components require scheduled maintenance, has a proposed maintenance plan and procedures been developed?

Procedure: Refer to the Product Support Plan to validate.

References(s): DODI 5000.2, Para 3.8; DoDI O-8530.2 Encl 4, para E4.3.1.2.1; NISPOM Ch 8 and 10; NISPOMSUP Ch 8 Sec 4; DCID 6/3 para 2.B.4.e(13) Indicators:o Instructions have been developed outlining maintenance

procedures for devices/components requiring scheduled maintenance.

o Requirements for scheduled maintenance are detailed in the PSP.

Comments:


PDI Short Description: A proposed maintenance plan/schedule has not been developed for devices/components requiring scheduled maintenance.


33 UNCLASSIFIED

269270

271272

273946

947

274275276


7.15 Specialized Training Requirements

Have specialized training requirements been identified for NetOps center personnel (e.g., O&M, sys config, monitoring…)?

Procedure: Review training documentation.

References(s): CJCSI 6510.01D, “Information Assurance (IA) and Computer Network Defense”, Encl B para 14,15 June 2004; DODI 8500.2, “Information Assurance (IA) Program Implementation”, February 6, 2003, Encl 3 para E3.3.6; DODI 5000.2, Para 3.8; DoDD O-8530.1 para 5.12.10; CJCSM 6510.01 para 5.j and m; DoDI 8500.2 Encl 4, Att 4/5 PRTN-1; DoD 8570.01-M

Indicators:o System specific Training for the NetOps Center:

Copies of presentations for NetOps Center training Schedule for NetOps Center training Subscriber’s NetOps Center personnel are aware of

available training and schedules

Comments:


PDI Short Description: No specialized training requirements have been identified for NetOps center personnel.


7.16 Formal Agreements with Outside (Non-DISA) Organizations

In the case where outside (non-DISA) organizations are required to perform certain tasks and functions, have formal agreements been established between DISA and the external organizations?

Procedure: Review agreements such as Site Concurrence Letters, and Memorandums of Agreement. Refer to the PSP to validate.

References(s): DODI 5000.2, Para 3.8; DOD 5000.2-R C3.2.3.2.1, C3.2.3.2.2.3; NISPOMSUP 7-100; NISPOM Ch 10 Sec 6; DCID 6/3 para 2.B.4.e(4), 2.B.4.e(5) Indicators:o Copy of MOU(s) or written agreement that has been

signed. o Operational relationships covered in the agreement are

detailed in the P/S/A/S CONOPS.o Agreement documents detail the services provided such

that they can be re-established if necessary.

Comments:


34 UNCLASSIFIED

277278

279280

281948949

950951

952

282283284


PDI Short Description: Outside organizations are required to perform certain tasks and functions, but no formal written agreements have been established.


7.17 Maintenance of System Diagrams

Are P/S/A/S diagrams maintained, and is there a process to incorporate updates?

Procedure: Review P/S/A/S configuration documentation and CM process.

References(s): DISAI 310-220-1; DODI 5000.2, Para 3.8; DoDD O-8530.1 para 4.6.1; DoDI O-8530.2 para 6.2.4 and E6.1.6.1; DoDI 8500.2 Encl 4, Att 1,2,3 DCHW-1, DCFA-1, DCPP-1, DCPR-1, DCSW-1; DoDD 5220.22M, Sec 8-101; DCID 6/3 Sec 5.B.1.a.(2), 5.B.2.a.(4); DCID 6/3 2.B.4.b.(4), 2.B.5.c.(4) Indicators:o Copies of the Latest network diagram(s)o Up-to-date inventory of information systems, network

components, software, O/Ss, etc.o Network services utilized by subscribero Network access points and operational importance

identifiedo Personnel display knowledge of subscriber networks

and configurations

Comments:


PDI Short Description: P/S/A/S diagrams are not being maintained, and there is no process to incorporate updates.


7.18 Approval Process for Changes to the System Architecture

Are significant changes to the P/S/A/S architecture approved through the DISA NetOps Center Control Board prior to implementation?

Procedure: Review CM process.

References(s): DISAI 310-220-1; DODI 5000.2, Para 3.8; DoDD O-8530.1 para 4.6.1; DoDI O-8530.2 para 6.2.4 and E6.1.6.1; DoDI 8500.2 Encl 4, Att 1,2,3 DCHW-1, DCFA-1, DCPP-1, DCPR-1, DCSW-1; DoDD 5220.22M, Sec 8-101; DCID 6/3 Sec 2.B.4.b.(4), 2.B.5.c.(4), 5.B.1.a.(2), 5.B.2.a.(4)

35 UNCLASSIFIED

285286

287288

289

953954955

956

957958

290291292


Indicators:o Process addressed in CM Plan. o Minutes from CCB

Comments:


PDI Short Description: Significant changes to the P/S/A/S architecture are not approved through the NetOps Control Board prior to implementation.


7.19 Identification and Registration of System Interfaces

Have P/S/A/S ports, protocols and services (PPS) been identified and registered with the PPS POC?

Procedure: Validate online PPS database.

References(s): DODI 8551.1 “Ports, Protocols, and Services Management (PPSM)”, August 13, 2004; DODI 5000.2, Para 3.8; CJCSI 6510.01D Encl D, para 2.b.(4) and 13.a.(6); DoDI 8500.2 Encl 4, Att ½/3 DCCS-1/2; CMU/SEI-2003-HB-002 Sec 2.3.2.2; DCID 6/3 para 2.B.5.c.(1)

Indicators:o P/S/A/S PPS’s are registered.

Comments:


PDI Short Description: Internal system interfaces have not been identified and registered with the DISA PPS POC.


7.20 Key Performance Metrics and Objectives for Service Level Agreement (SLA) Monitoring

If key performance metrics and objectives for P/S/A/S exist, are they identified to the DNC(s)?

Procedure: Check Service Level Agreement.

References(s): Joint Concept of Operations (CONOPS) for Global Information Grid (GIG) NetOps, Version 3, 4 August 2006 Situational Awareness; DISAC 310-130-2; DODI 5000.2, Para 3.8

36 UNCLASSIFIED

293294

295296

297

959

960

961962963

298299300


Indicators:o Key performance parameters and thresholds have been

identified. (e.g., QOS, packet loss, latency, CPU utilization, etc.)

o Activity doing the monitoring has been identified.o Response actions identified.o P/S/A/S provides end-to-end performance data to

support SLA compliance monitoring.

Comments:


PDI Short Description: Key performance metrics and objectives for SLA monitoring have not been identified.


7.21 System Performance Capability

Is the P/S/A/S instrumented to meet specified performance metrics? (Are there alarms or indicators for performance thresholds?)

Procedure: Review ST&E and user acceptance tests.

References(s): DODI 5000.2, Para 3.7 Indicators:o Use of Modeling and Simulation testing or other

analytical techniques.o The P/S/A/S provides end-to-end performance data to

support monitoring.o The predicted traffic throughput/number of transactions

during periods of peak system load has been validated and documented.

o The P/S/A/S bandwidth requirements have been identified.

Comments:


PDI Short Description: Performance metrics are not validated through system Modeling and Simulation testing.


37 UNCLASSIFIED

301302

303304

305

964965

966967

968

306307308


7.22 Product Support Plan (PSP)

Does the Product Support Plan (PSP) support NetOps?

Procedure: Refer to SSAA, CM Plan, and/or PSP.

References(s): NCOW RM v1.1; DODI 5000.2, Para 3.8, E9.3

Indicators:o Technology refresh plan.o LCM covers ‘cradle to grave’.o Maintenance Plan.

Comments:


PDI Short Description: The PSP has not been established for the P/S/A/S.


7.23 Employment and Integration of Core Enterprise Services

Has the P/S/A/S been designed and developed to employ and integrate the use of Core Enterprise Services (CES)?

Procedure: Review P/S/A/S design documentation.

References(s): NCOW RM v1.1; DODI 5000.2, Para 3.7

Indicators:o CONOPS addresses CESo Application, Discovery, User Assistant, Collaboration,

Storage, Mediation, Messagingo IA/Securityo Enterprise Service Management (ESM)o P/S/A/S provides ability for CES monitoring.

Comments:


PDI Short Description: The P/S/A/S is not designed and developed to employ and integrate the use of CES.


If the P/S/A/S is IP network enabled, does it support Internet Protocol Version Six (IPv6)?

Procedure: Verify P/S/A/S architecture documentation and test documentation (results of IPv6 testing).

38 UNCLASSIFIED

309310

311312

313969

970

314315316


References(s): Request for Comment (RFC) 791; RFC 2460; DoD Memo on IPv6; DODI 5000.2, Para 3.7; DoD Memo Internet Protocol Version 6 (IPv6) Interim Transition Guidance, September 29, 2003; DoD Memo, Internet Protocol Version 6 (IPv6), June 9, 2003 Indicators:o Capable of receiving, processing and forwarding IPv6

packets and/or interfacing with other P/S/A/S and protocols in a manner similar to that of IPv4.

o IP network conformant with the JTA developed IPv6 standards profile.

o IP network operates on or coexists on a network supporting IPv4 only, IPv6 only, or a hybrid of IPv4 and IPv6.

o If the P/S/A/S is IP network enabled and does not support IPv6, a Plan of Action & Milestones (POA&M) for compliance has been developed.

Comments:


PDI Short Description: The P/S/A/S is IP network enabled, and does not support IPv6.


7.24 Does the System Support IPv6

39 UNCLASSIFIED

317318

319320

321

971

322323324


8 GIG NETWORK DEFENSE (GND)

8.1 DoD Net-Centric IA Strategy

Is the P/S/A/S designed to meet the DoD Net-Centric IA Strategy?

Procedure: Validate P/S/A/S design documentation. Verify STIG compliance.

References(s): NCOW RM v1.1, para 3.3; 3.3.1; 6.5.1; 6.5.2; 6.5.3; DODI 5000.2, Para 3.7; DoD Net-Centric Information Assurance (IA) Strategy Ver 1.0 dtd 30 June 2004

Indicators:o P/S/A/S is designed to protect information

confidentiality (from unauthorized access) and integrity (from unauthorized modifications), while at the same time making information available to those who need it in a manner that they can readily use.

o P/S/A/S is designed to be self-protecting by recognizing, reacting to, and responding to threats, vulnerabilities, and deficiencies.

o P/S/A/S is designed to provide IA situational awareness to minimize unauthorized or accidental access to GIG functions, maintain confidentiality, integrity, and availability, and continuously monitor for security breaches.

Comments:


PDI Short Description: The P/S/A/S has not been designed to meet the DoD Net-Centric IA Strategy.


40 UNCLASSIFIED

325326

327328

329

972

973974

330331332


8.2 IA Design Tenets

Does the P/S/A/S comply with all of the IA design tenets as defined in the Net-Centric Operations and Warfare Reference Model (NCOW RM)?

Procedure: Verify P/S/A/S design documentation.

References(s): NCOW RM v1.1, para 6.5.1; 6.5.2; 6.5.3; 3.3; Net-Centric Checklist, para I.A. thru I.H; DODI 5000.2, Para 3.7

Indicators:o The P/S/A/S complies with the Identity Management,

Authentication and Privileges.o The P/S/A/S complies with the Mediate Security

Assertions.o The P/S/A/S complies with the Cross Domain Security

Exchange.o The P/S/A/S complies with the Encryption and HAIPE.o The P/S/A/S complies with the Employment of

Wireless Technologies.o Data packets routed across networks, not switched via

dedicated circuits.o Data posted by authoritative sources is visible,

available, and usable.o Business process owners are making their own data

available on the net as soon as it is created. o Data separates from applications; the applications

“talk” to each other by posting data.

Comments:


PDI Short Description: The P/S/A/S does not comply with all of the IA design tenets as defined in the NCOW RM.


41 UNCLASSIFIED

333334

335336

337

975976

977

338339340


8.3 Assignment of Mission Assurance Category (MAC)/Sensitivity Levels

Have Mission Assurance Category (MAC)/Sensitivity Levels been assigned for the P/S/A/S?

Procedure: Verify designation in C&A documentation.

References(s): DODD 8500.1 “Information Assurance”, October 24, 2002, para 4.7; DODI 8500.2 “Information Assurance (IA) Program Implementation”, February 6, 2003, E4.1.9; DODI 5000.2, Para 3.6

Indicators:o Level are documented in requirements

documentation.o Levels are documented in C&A documentation.

Comments:


PDI Short Description: An appropriate MAC and Sensitivity Level have not been assigned for the P/S/A/S.


8.4 Integrity and Availability Controls Required for the Assigned MAC Level

Does the P/S/A/S meet the Integrity and Availability controls required for the assigned MAC level?

Procedure: Verify controls traceability.

References(s): DODI 8500.2 “Information Assurance (IA) Program Implementation”, February 6, 2003, E4.1.9; DODI 5000.2, Para 3.7;

Indicators:o RTM in SSAA.o IA Controls Check List review with acceptable

POA&M for findings.

Comments:


PDI Short Description: The P/S/A/S does not meet the Integrity and Availability controls required for the assigned MAC level.


8.5 Confidentiality Controls Required for the Assigned Sensitivity Level

42 UNCLASSIFIED

341342

343344

345

978979

980981982

983984

346347348


Does the P/S/A/S meet the Confidentiality controls required for the assigned sensitivity level?

Procedure: Verify controls traceability.

References(s): DODI 8500.2 “Information Assurance (IA) Program Implementation”, February 6, 2003, E4.1.9; DODI 5000.2, Para 3.7;

Indicators:o SSAA RTM.o IA Controls Check List review with acceptable

POA&M for findings.

Comments:


PDI Short Description: The P/S/A/S does not meet the Confidentiality controls required for the assigned sensitivity level.


8.6 Identification of P/S/A/S Need-to-Know Requirements and Access Control Procedures

Does the P/S/A/S implement need-to-know and access control requirements that have been identified?

Procedure: Review P/S/A/S security plan and procedures. Review SRR findings.

References(s): DODI 5000.2, Para 3.8; DISAI 630-230-19

Indicators:o Necessary P/S/A/S need-to-know and access control

requirements and are specified and procedures have been implemented.

o The designated P/S/A/S mode of operation supports the need-to-know requirements and access control procedures.

1. Dedicated Mode2. System High Mode3. Multilevel Mode4. Multilevel, Partitioned Mode

Comments:


PDI Short Description: The P/S/A/S does not implement need-to-know and access control requirements.


43 UNCLASSIFIED

349350

351352

353

985986

354355356


8.7 Capture and UDOP Display of Security Events

Does the P/S/A/S capture and provide security event information to populate the CND User Defined Operational Picture (UDOP)?

Procedure: Review P/S/A/S architecture and test documentation.

References(s): Net-Centric Information Assurance (IA) Requirements Traceability Matrix; DODI 5000.2, Para 3.7; UDOP CONOP.

Indicators:o The DNC can monitor the P/S/A/S security status on

the UDOP.

Comments:


PDI Short Description: The P/S/A/S does not capture and provide security event information to populate the CND UDOP.


8.8 Automated Capability for Detecting and Reporting P/S/A/S Security Events and Anomalous Behavior

Does the P/S/A/S have an automated capability for detecting and reporting P/S/A/S security events and anomalous behavior?

Procedure: Review P/S/A/S security architecture.


Indicators:o P/S/A/S can detect system security events and

anomalous behavior.o Reporting capabilities include page-out and email

alerts.

Comments:


PDI Short Description: The P/S/A/S does not have an automated capability for detecting and reporting P/S/A/S security events and anomalous behavior.


44 UNCLASSIFIED

357358

359360

361

987

988

989990991

362363364


8.9 IAVM Methodology

Is the P/S/A/S capable of interaction with the IA Vulnerability Management (IAVM) process and tools?

Procedure: Review IAVM procedures.

References(s): CJCSM 6510.01 “Defense-In-Depth: Information Assurance (IA) and Computer Network Defense (CND)”, 25 March 2003, Chg 2; DODI 5000.2, Para 3.7.

Indicators:o Demonstrate ability to accept and respond to IAVM

notices and acknowledge compliance or non-applicability in VMS

o Demonstrate ability to accept and respond to IAVM notices.

o Demonstrate ability seamlessly interoperate with the Secure Configuration Compliance Validation Initiative (SCCVI) and Secure Configuration Remediation Initiative (SCRI).

Comments:


PDI Short Description: The P/S/A/S is not capable of interaction with the IAVM process and tools.


45 UNCLASSIFIED

365366

367368

369992993

370371372


9 GIG CONTENT MANAGEMENT (GCM)Questions in this section may only be applicable to web services and-or service oriented architectures.

9.1 Metadata

Is the P/S/A/S metadata registered in the metadata registry?

Procedure: Compare system metadata list with registry.

References(s): NCES Core services; DODI Meta data registration; DoD Net-Centric Data Strategy, May 9, 2003; DODI 5000.2, Para 3.8.

Indicators:o Program system metadata list.

o System metadata is in the metadata registry.

Comments:


PDI Short Description: The P/S/A/S does not use Metadata that is registered within the Metadata registry.


46 UNCLASSIFIED

373374

375376

377

994995996

997998

999

378379380


9.2 Federated Search Aggregators

Does the P/S/A/S use one or more registered Federated Search aggregators?


References(s): DOD Net-Centric Data Strategy, May 9, 2003; DODI 5000.2, Para 3.8

Indicators:o The Content Discovery service provides a standard,

vendor neutral approach for exposing metadata to the GIG.

o The Content Discovery CES defines to interface specifications:

1. Federated Search specification—provides a standard interface allowing submission of a query to one or more existing data sources, such as databases, catalogs, or search engines;

2. Enterprise Search specification—provides a standard interface supporting event-driven updates to metadata in a highly available, scalable enterprise catalog.

o The Domain Federation Service is responsible for managing federation relationships with other trust domains. Its operations include the following:1. Register a trust domain as federated. This is as

simple as putting the domain’s Distinguished Name (DN) suffix in an internal lookup table;

2. De-federate a trust domain;3. Joining a parent domain;4. Retrieving the set of trusted children from the

parent domain;5. Given a specific domain DN, check whether it is

federated.

Comments:


PDI Short Description: The P/S/A/S does not use registered Federated Search aggregators.


47 UNCLASSIFIED

381382

383384

385

10001001

10021003100410051006

386387388


9.3 Service Discovery Registry

Is the P/S/A/S registered with the Service Discovery registry according to the standard Federated Search specification?


References(s): DOD Net-Centric Data Strategy, May 9, 2003; DODI 5000.2, Para 3.8; NCES: Software Center Operator Manual ( SCOM) Final dtd 25 February 05

Indicators:o The Service Discovery services consists of the set of

services that enable the formulation and execution of search activities to locate data assets (e.g., files, databases, services, directories, Web pages, streams) by exploiting metadata descriptions stored in, and/or generated by Information Technology (IT) repositories (e.g., directories, registries, catalogs, repositories, and other shared storage).

o A typical usage scenario for Service Discovery is a publish-find-bind cycle. At a high-level, the scenario is described as follows:1. A service provider publishes a service as well as its

deployed instances to the Service Discovery CES.2. A service consumer searches through Service

Discovery CES and finds the service instance(s) that meet the search criteria.

3. The service consumer uses the end point information of a found service instance to “bind to” and consume the service.

o For both publishing and inquiry, the service interfaces are protected using the techniques prescribed in the NCES Security Architecture, so that: Identities of publishers, inquirers, and discovery

service providers may be established; The publishing and inquiry requests and responses

are authenticated and their message integrity verified;

The requests and responses are authorized against access control policies, if necessary.

Comments:


PDI Short Description: The P/S/A/S is not registered with the Service Discovery registry according to the standard Federated Search specification.


48 UNCLASSIFIED

389390

391392

393100710081009

10101011

394395396


9.4 Roles-Based Access

Does the P/S/A/S employ roles-based access to an OSD level Community of Interest (COI)?

Procedure: Review P/S/A/S architecture and SSAA.

References(s): Joint Concept of Operations (CONOPS) for Global Information Grid (GIG) NetOps, Version 3, 4 August 2006; DODI 5000.2, Para 3.8; NCES: Software Center Operator Manual ( SCOM) Final dtd 25 February 05; NCES Implementation Procedure for Content Staging (CS), Release 4.1.3 For Solaris 8 Document Version 1.0 dtd 29 March 2004; ANSI INCITS 359-2004; NCES CS/IDM Release 4.1.2 SSAA Ver 3.0 dtd November 2004; NCES CS/IDM Release 4.1.2 TFM dtd November 2003

Indicators:o Role based access:

Consumer – A recipient of an information product, or an agent of the recipient; also called an information consumer.

Producer – An originator of an information product, or an agent of the originator; also called an information producer.

Information Management Officer (IMO) – A person responsible for a) describing the information flows across a CS configuration, b) coordinating access to information sources, and c) allocating CS functions to locations and networks.

Commander – A definer of user roles and information domains, or an agent of the author.

CS administrator – A computer system administrator responsible for the installation, configuration, and administration of CS software and user accounts.

Comments:


PDI Short Description: The P/S/A/S does not employ roles-based access to a COI.


49 UNCLASSIFIED

397398

399400

401101210131014

10151016

10171018

402403404


9.5 Smart Push/Pull of Data

Does the P/S/A/S subscribe for smart push/pull of data?


References(s): Joint Concept of Operations (CONOPS) for Global Information Grid (GIG) NetOps, Version 3, 4 August 2006; DOD Net-Centric Data Strategy, May 9, 2003; DODI 5000.2, Para 3.8; Understanding Metadata by NISO Press in 2004; NCES Annex T for Discovery Service dtd April 2004

Indicators:o The P/S/A/S has the ability to register and discover

metadata artifacts in the DOD Metadata Registry and Clearinghouse.

o Trust relationship between a service consumer and a provider.

o Service interfaces are protected using the techniques prescribed in the NCES Security Architecture:

Identifies publishers. Identifies inquirers. Establishes discovery service providers.

o The publishing and inquiry requests and responses are authenticated and their message integrity verified.

o The requests and responses are authorized against access control policies, if necessary.

o Owner able to “vouch for” its published entities so that consumers can have some degree of trust on these entities.

Comments:


PDI Short Description: The P/S/A/S does not subscribe for smart push/pull of data.


50 UNCLASSIFIED

405406

407408

409

101910201021

10221023

410411412


9.6 Publication Mechanism for Smart Push/Pull of Data

Does the P/S/A/S’s data system implement a publication mechanism for smart push/pull of data?


References(s): Joint Concept of Operations (CONOPS) for Global Information Grid (GIG) NetOps, Version 3, 4 August 2006; DOD Net-Centric Data Strategy, May 9, 2003; DODI 5000.2, Para 3.8; Understanding Metadata by NISO Press in 2004; NCES Annex T for Discovery Service dtd April 2004; NCES CS/IDM Release 4.1.2 SSAA Ver 3.0 dtd November 2004; NCES CS/IDM Release 4.1.2 TFM dtd November 2003

Indicators:o A human user / operator serves as the publisher, who

uses a web user interface to publish the service entities in the registry.

o An application (possibly the service itself), uses a publishing Web Service / Application Program Interface (API) provided by the registry to publish the service entities.

o A service dynamically updates its definitions and metadata in the registry, so that the entities in the registry are kept in sync with the operating conditions of the real service.

Comments:


PDI Short Description: The P/S/A/S’s data system does not implement a publication mechanism for smart push/pull of data.


51 UNCLASSIFIED

413414

415416

417

102410251026

1027102810291030

418419420


9.7 Caching, Content Management, or Other “Smart” Delivery Mechanisms

Does the P/S/A/S employ “smart” delivery mechanisms to minimize bandwidth, assure timely delivery and assure Information Integrity? (Control over own pipe size?)


References(s): Joint Concept of Operations (CONOPS) for Global Information Grid (GIG) NetOps, Version 3, 4 August 2006; DOD Net-Centric Data Strategy, May 9, 2003; DODI 5000.2, Para 3.8; NCES Implementation Procedure for Content Staging (CS), Release 4.1.3 For Solaris 8 Document Version 1.0 dtd 29 March 2004; Understanding Metadata by NISO Press in 2004; NCES Annex T for Discovery Service dtd April 2004

Indicators:o Data flow is bi-directional. o Provides services to manage and prioritize the use of

the communications infrastructure by utilizing customizable, user-defined information profiles.

o These profiles use “smart push” and responsive “user pull” technologies. Dynamically routes information via the best communications path available according to precedence, various qualities of service (timeliness, latency, error-tolerance, delay variation, etc.), size of files, continuous data rates, and other factors.

Comments:


PDI Short Description: The P/S/A/S does not employ caching, content management, or other “smart” delivery mechanisms to minimize bandwidth and/or assure timely delivery, and assure Information Integrity.


52 UNCLASSIFIED

421422

423424

425

1031103210331034

1035

426427428


9.8 Receipt and Delivery Notifications

Does the P/S/A/S use receipt and delivery notifications?


References(s): Joint Concept of Operations (CONOPS) for Global Information Grid (GIG) NetOps, Version 3, 4 August 2006; DODI 5000.2, Para 3.8; NCES CS/IDM Release 4.1.2 SSAA Ver 3.0 dtd November 2004; NCES CS/IDM Release 4.1.2 TFM dtd November 2003

Indicators:o System receipt notifications.o System delivery notifications.

Comments:


PDI Short Description: The P/S/A/S does not utilize receipt and delivery notifications from CS/IDM.


9.9 Definition of User Population/COI Is the user population/COI defined/known (e.g. scope and scaling)?

Procedure: Review P/S/A/S CONOPS.

References(s): Joint Concept of Operations (CONOPS) for Global Information Grid (GIG) NetOps, Version 3, 4 August 2006; DOD Net-Centric Data Strategy, May 9, 2003; DODI 5000.2, Para 3.8; DODD 8320.2 December 2, 2004

Indicators:o Target data consumers are defined.

Comments:


PDI Short Description: The P/S/A/S user population/COI is not clearly defined or known.


53 UNCLASSIFIED

429430

431432

433

103610371038

1039

1040

1041

434435436


9.10 Contingency Operations

Is the P/S/A/S able to provide full services in all contingencies within limits based on P/S/A/S MAC Level?

Procedure: Review accreditation documentation (SSAA).

References(s): Joint Concept of Operations (CONOPS) for Global Information Grid (GIG) NetOps, Version 3, 4 August 2006; DODI 5000.2, Para 3.8; NCES CONOPS dtd September 2004; NIST Special Publication 800-34, Contingency Planning Guide for Information Technology (IT) Systems dtd June 2002;NCES CS/IDM Release 4.1.2 TFM dtd November 2003

Indicators:o Capability should not be lost when COOP.o BCP.o Redundant architecture.

Comments:


PDI Short Description: The P/S/A/S does not include contingency operations.


9.11 Monitoring and Analysis

54 UNCLASSIFIED

437438

439440

441

10421043

10441045104610471048104910501051105210531054105510561057105810591060106110621063

10641065442443444


Is information available on the network that enables monitoring and analysis (e.g. up/down status, info flow and access, impact on network, user quality of service)?


References(s): Joint Concept of Operations (CONOPS) for Global Information Grid (GIG) NetOps, Version 3, 4 August 2006; DODI 5000.2, Para 3.8; NCES CS/IDM Release 4.1.2 SSAA Ver 3.0 dtd November 2004; NCES CS/IDM Release 4.1.2 TFM dtd November 2003

Indicators:o Components provide information that can be used to

monitor both P/S/A/S performance and access.o Available information is used to maintain and improve

quality of service.

Comments:


PDI Short Description: The information is not available on the network that enables monitoring and analysis.


55 UNCLASSIFIED

445446

447448

449

10661067

450451452


This page is intentionally left blank.

56 UNCLASSIFIED

453454

455456

4571068106910701071107210731074107510761077107810791080108110821083108410851086

458459460


10 APPENDIX B. ACRONYMSAcronym Definition

ACAT Acquisition CategoryAIS Assured Information SharingAMM Assured Mission ManagementASD(NII) Assistant Secretary of Defense for Networks & Information IntegrationATO Approval to OperateCAE Component Acquisition ExecutiveC4ISR Command, Control, Communications, Computers, Intelligence, Surveillance,

and ReconnaissanceCDRUSSTRATCOM Commander, USSTRATCOMCDS Cross-Domain SolutionCES Core Enterprise ServiceCFE Chief Financial ExecutiveCIO Chief Information OfficerCJCS Chairman, Joint Chiefs of StaffCJCSI Chairman, Joint Chiefs of Staff InstructionCJCSM Chairman, Joint Chiefs of Staff ManualCM Configuration ManagementCOI Community of InterestCON ConfidentialityCONOPS Concept Of OperationsCOOP Continuity of Operations PlanCOP Common Operational PictureCoS Class of ServiceCOTS Commercial Off-The-ShelfCP-SIB Cross Program – Synchronization and Integration BoardCTO Chief Technology OfficeDAA Designated Accrediting AuthorityDCN Dedicated Control NetDECC Defense Enterprise Computing CentersDHCP Dynamic Host Configuration ProtocolDIACAP DoD Information Assurance Certification and Accreditation ProgramDIAP Defense Information Assurance ProgramDITSCAP Defense Information Technology Security Certification and Accreditation

ProcessDISA Defense Information Systems AgencyDISAC Defense Information Systems Agency CircularDISAI Defense Information Systems Agency InstructionDISN Defense Information Systems NetworkDNC DISA NetOps CenterDoD Department of DefenseDoDAF DoD Architecture FrameworkDoDD Department Of Defense DirectiveDoDI Department Of Defense Instruction

57 UNCLASSIFIED

461462

463464

465

1087

466467468


DOTMLPF Doctrine, Organization, Training, Materiel, Leadership and Education, Personnel and Facilities

DTG Defend the GIGEMS Element Management SystemFCAPS Fault, Configuration, Accounting, Performance, SecurityFSO Field Security OperationsGE GIG EngineeringGES Global Enterprise ServicesGIAP GIG IA PortfolioGIG Global Information GridGIG-OPS Global Information Grid – OperationsGISMC GIG Infrastructure Services Management CenterGCM GIG Content ManagementGEM GIG Enterprise ManagementGND GIG Network DefenseGNSC Global NetOps Support CenterGO GIG OperationsGOTD GIG Operations Technical Director’s TeamGS GIG Combat ServicesHAE Highly Available EnterpriseIA/CND Information Assurance / Computer Network DefenseIAM Information Assurance ManagerIATO Interim Approval To OperateIAVA Information Assurance Vulnerability AlertIAVM Information Assurance Vulnerability ManagementIAW In Accordance WithICATS Integrated Configuration and Tracking SystemINMS Integrated Network Management SystemINR Integrity and Non-RepudiationIP Internet ProtocolISP Internet Service ProviderIT Information TechnologyJTF-GNO Joint Task Force – Global Network OperationsLCM Life Cycle ManagementMAC Mission Assurance CategoryMAIS Major Automated Information SystemMNS Mission Need StatementMOA/MOI Memorandum of Agreement / Memorandum of InterconnectionMSP Managed Service ProviderMTNM Multi-Technology Network ManagementMTOSI Multi-Technology Operations System InterfaceNCES Net-Centric Enterprise ServicesNCOW RM Net-Centric Operations and Warfare Reference ModelNetOps NetOps is not a traditional acronym but rather shorthand for an integrated

approach to accomplishing GIG SA, C2, and the three interdependent tasks necessary to operate the GIG — GIG Enterprise Management (GEM), GIG Network Defense (GND) and GIG Content Management (GCM).

58 UNCLASSIFIED

469470

471472

473

474475476


NGAB NetOps Governance and Advisory BoardNRRB NetOps Readiness Review BoardNIPRNET Non-Classified Internet Protocol Router NetworkNSO Network Security OfficerNSTISSP National Security Telecommunications and Information Systems Security

PolicyOIPT Overarching Integrated Product TeamOSD Office of the Secretary of DefenseOSS Operations Support SystemPDI Path Defect IndicatorPEO-IAN Program Executive Office – Information Assurance/NetOpsPOA&M Plan Of Action & MilestonesPSP Product Support PlanPM Program ManagerPMO Program Management OfficePOM Program Objective MemorandumPPS Ports, Protocols, and ServicesP/S/A/S Programs/Systems/Applications/ServicesQOS Quality of ServiceRFC Request for CommentRTM Requirements Traceability MatrixSA Situational AwarenessSCCVI Secure Configuration Compliance Validation InitiativeSCRI Secure Configuration Remediation InitiativeSEPA Systems Engineering Process AssessmentSLA Service Level AgreementSSAA System Security Authorization AgreementSSP System Security PlanSOO Statement of ObjectivesSOP Standing Operational ProcedureSOR Statement of RequirementSTIG Security Technical Implementation GuideTED Test and Evaluation DirectorateTMS Trouble Management SystemTNC Theater NetOps CentersTPPU Task, Post, Process, UseUDOP User Defined Operational PictureUSSTRATCOM US Strategic CommandWIPT Working Integrated Product Teams

59 UNCLASSIFIED

477478

479480

481

1088

482483484


11 APPENDIX C. REFERENCES

DISA Publications

(a) DISA CONOPS Template, 12 February 2007.

(b) DISA Net-Centric Enterprise Services (NCES), 15 June 2007.

(c) DISA NetOps Common Operational Picture (NETCOP) Functional Requirements Specification, Version 1.0, 10 September 2004.

(d) DISA Operations Support Team (OST) CONOPS, Version 3, November 2006.

(e) Director’s Policy Letter 2006-8: Trouble Management System (TMS), 15 August 2006.

(f) NCES Annex T for Discovery Services

(g) NCES CS/IDM Release 4.1.2 SSAA Ver 3.0, November 2004.

(h) NCES CS/IDM Release 4.1.2 TFM, November 2003.

(i) NCES Implementation Procedure for Content Staging (CS), Release 4.1.3 For Solaris 8 Document Version 1.0, 29 March 2004.

(j) NCES: Software Center Operator Manual ( SCOM) Final, 25 February 2005.

(k) Net-Centric Review Process and Strategy for DISA, Version 1.1, 25 July 2006.

(l) Net-Centric Operations and Warfare Reference Model (NCOW RM) v1.1, 8 November 2004.

(m) Request for Comment (RFC) 791; INTERNET PROTOCOL,DARPA INTERNET PROGRAM PROTOCOL SPECIFICATION, http://www.ietf.org/rfc/rfc0791.txt

(n) Request for Comment (RFC) 2460; Internet Protocol, Version 6 (IPv6) Specification http://www.ietf.org/rfc/rfc2460.txt

(o) DISAC 310-130-2, Management Thresholds and Performance Objectives, 4 May 2006.

(p) DISAC 310-55-1, Status Reporting for the Defense Communications Systems, 8 May 2002.

(q) DISAI 310-220-1, “Boards and Committees, DISA Network Operations (NetOps) Boards”, Draft, 20 May 2007.

(r) DISAI 630-230-19, Automatic Data Processing, Information Assurance, 2 March 2007.

DoD Publications

(s) Acquisition Information Assurance Strategy for Net-Centric Enterprise Services (NCES), Version 1.0, 10 May 2006.

(t) ASD/NII Net-Centric Checklist, Version 2.1.4, 30 July 2004.60 UNCLASSIFIED

485486

487488

489

1089109010911092109310941095109610971098109911001101110211031104110511061107110811091110111111121113111411151116111711181119112011211122112311241125112611271128112911301131113211331134

11351136113711381139490491492

http://www.ietf.org/rfc/rfc2460.txt

http://www.ietf.org/rfc/rfc0791.txt


(u) DCID 1/19, Security Policy for Sensitive Compartmented Information and Security Policy Manual, 1 March 1995.

(v) DCID 6/3 "Protecting Sensitive Compartmented Information Within Information Systems", MANUAL 24 May 2007.

(w) DoD Architecture Framework (DoDAF), Version 1.5, Volume I: Definitions and Guidelines, 23 April 2007.

(x) DoD Architecture Framework (DoDAF), Version 1.5, Volume II: Product Descriptions, 23 April 2007.

(y) DoD Architecture Framework (DoDAF), Version 1.5, Volume III: Architecture Data Description, 23 April 2007.

(z) DoD Memorandum from the Deputy Assistant Secretary of Defense, IPv6, June 2003.

(aa) DoD Memorandum from the Deputy Assistant Secretary of Defense, Internet Protocol Version 6 (IPv6) Interim Transition Guidance, 29 September 2003.

(bb) DoD Net-Centric Data Strategy, 9 May 2003.

(cc) DoD Net-Centric Information Assurance (IA) Strategy Ver 1.0, 30 June 2004.

(dd) DoD 5200.2-R “DoD Personnel Security Program,” January 1987.

(ee) DoD 5220.22M,"National Industrial Security Program Operating Manual", (NISPOM)

29 February 2006.

(ff) DoD 5220.22-M,"National Industrial Security Program Operating Manual Supplement"

(NISPOMSUP), 4 February 1995.

(gg) DoD 8570.01-M, "Information Assurance Workforce Improvement Program", 19 December 2005.

(hh) DoDD 5000.1, “The Defense Acquisition System”, 12 May 2003.

(ii) DoDD 8115.01 “Information Technology Portfolio Management”, 10 October 2005.

(jj) DODD 8320.02 “Data Sharing in a Net-Centric Department of Defense”, 23 April 2007.

(kk) DoDD 8500.01E “Information Assurance (IA),” 24 October 2002, Certified Current as of 23

April 2007.

(ll) DoDD O-8530.1, "Computer Network Defense (CND)", 8 January 2001.

(mm) DoDI 5000.2, “Operation of the Defense Acquisition System”, 12 May 2003.

(nn) DoDI 8410.x, “NetOps for the Global Information Grid (GIG)”, Draft 19, 26 February 2007.

(oo) DoDI 8500.2 “Information Assurance (IA) Program Implementation”, 6 February 2003. Includes

IA Control Numbers DCCS-1, DCCS-2, DCFA-1, DCHW-1, DCPP-1, DCPR-1, DCSD-1,

DCSW-1 from Enclosure 4

(pp) DoDI 8551.1 “Ports, Protocols, and Services Management (PPSM)”, 13 August 2004.

61 UNCLASSIFIED

493494

495496

49711401141114211431144114511461147

114811491150115111521153115411551156115711581159116011611162116311641165

1166

11671168

11691170

1171

1172

11731174

11751176

1177

1178

1179

118011811182

498499500

http://www.fas.org/irp/offdocs/dcid1-19.html

http://www.fas.org/irp/offdocs/dcid1-19.html


(qq) DoDI 8580.1, “Information Assurance (IA) in the Defense Acquisition System”, 9 July 2004.

(rr) DoDI O-8530.2, "Support to Computer Network Defense (CND)", 9 March 2001.

Joint Publications

(ss) Joint Concept of Operations (CONOPS) for Global Information Grid (GIG) NetOps, Version 3, 4 August 2006.

(tt) Joint Requirements Oversight Council (JROCM) Memorandum 134-01, Capstone Requirements Document, Global Information Grid (GIG), 30 August 2001.

(uu) CJCSI 6211.02B “Defense Information System Network (DISN): Policy, Responsibilities and Processes”, 31 July 2003, Enclosure B RESPONSIBILITIES – Certified Current as of 30 August 2006.

(vv) CJCSI 6510.01D “Information Assurance & Computer Network Defense”, 15 June 2004.

(ww) CJCSM 6510.01 “Defense-In-Depth: Information Assurance (IA) and Computer Network Defense (CND)”, CHG 3, 8 March 2006, Current as of 14 Mar 2007.

(xx) JP 1-02 DoD Dictionary of Military and Associated Terms, 12 April 2001 as amended through 13 June 2007.

Other Publications

(yy) ANSI INCITS 359-2004, "Role Based Access".

(zz) CMU/SEI-2003-HB-002, Handbook for Computer Security Incident Response Teams, Second Edition, April 2003.

(aaa) NIST Special Publication 800-34, Contingency Planning Guide for Information Technology (IT) Systems, June 2002.

(bbb) Understanding Metadata, NISO Press in 2004.

Websites

(ccc) DISA Core Services – NetOpshttp://www.disa.mil/main/prodsol/cs_netops.html

(ddd) GIG Enterprise IA Architecture and Standards Engineering, https://gesportal.dod.mil/sites/gigia/default.aspx

(eee) DISA Net-Centric Enterprise Services (NCES) Core Serviceshttp://www.disa.mil/nces/enterprise_services.html

(fff) DOD Metadata Registry and Clearinghousehttps://metadata.dod.mil/mdr/homepage.htm

62 UNCLASSIFIED

501502

503504

5051183

1184

11851186

118711881189119011911192119311941195119611971198119912001201120212031204120512061207

1208120912101211121212131214121512161217121812191220

1221122212231224122512261227122812291230123112321233

506507508

https://metadata.dod.mil/mdr/homepage.htm

http://www.disa.mil/nces/enterprise_services.html

https://gesportal.dod.mil/sites/gigia/default.aspx

http://www.disa.mil/main/prodsol/cs_netops.html


(ggg) DoD Dictionary of Military Termshttp://www.dtic.mil/doctrine/jel/doddict/

(hhh) DoD GIG Enterprise Services (GES) Strategy v1.1a. https://gesportal.dod.mil/sites/DoDGESS/default.aspx

63 UNCLASSIFIED

509510

511512

513123412351236123712381239

514515516

https://gesportal.dod.mil/sites/DoDGESS/default.aspx

http://www.dtic.mil/doctrine/jel/doddict/


12 APPENDIX D. DEFINITIONS

1. Accessible . A data asset is accessible when a human, system, or application may retrieve the data within the asset. Data assets may be made accessible by using shared storage space or web services that expose the business or mission process that generates data in readily consumable forms.

2. Application. Software program that performs a specific function directly for a user and can be executed without access to system control, monitoring or administrative privileges. Examples include office automation, electronic mail, web services, and major functional or mission software programs.

3. Approval to Operate (ATO). The authorization, granted by a DAA, for a DoD information system to process, store, or transmit information. Authorization is based on acceptability of the IA component, the system architecture and implementation of assigned IA Controls. The ATO accreditation decision must specify an Authorization Termination Date (ATD) that is within three years of the authorization date.

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

5. Authoritative Source . A source of data or information that is recognized by members of a COI to be valid or trusted because it is considered to be highly reliable or accurate or is from an official publication or reference (e.g., the United States (U.S.) Postal Service is the official source of U.S. mailing ZIP codes).

6. Authorized User. Any appropriately cleared individual with a requirement to access a DoD information system in order to perform or assist in a lawful and authorized governmental function.

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

8. Community of Interest (COI). A collaborative group of users that must exchange information in pursuit of its shared goals, interests, missions, or business processes and therefore must have shared vocabulary for the information it exchanges.

9. Community Risk. The probability that a particular vulnerability will be exploited within an interacting population and adversely impact some members of that population.

10. Computer Network. The constituent element of an enclave responsible for connecting computing environments by providing short-haul data transport capabilities such as local or campus area networks, or long-haul data transport capabilities such as operational, metropolitan, or wide area and backbone networks.

11. Computing Environment. Workstation or server (host) and its operating system, peripherals, and applications.

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

13. Connection Approval. Formal authorization to interconnect information systems.

64 UNCLASSIFIED

517518

519520

521

124012411242124312441245124612471248124912501251125212531254125512561257125812591260126112621263126412651266126712681269127012711272127312741275127612771278127912801281128212831284128512861287128812891290

522523524


14. Data Asset. Any entity that is comprised of data. For example, a database is a data asset that is comprised of data records. A data asset may be a system or application output file, database, document, or web page. A data asset also includes a service that may be provided to access data from an application. For example, a service that returns individual records from a database would be a data asset. Similarly, a web site that returns data in response to specific queries (e.g., www.weather.com) would be a data asset. A human, system, or application may create a data asset.

15. Data. A representation of facts, concepts, or instructions in a formalized manner suitable for communication, interpretation, or processing by humans or by automatic means. Data and information are equivalent terms for the purposes of this document.

16. Data-Centric. Data separate from applications; applications talk to each other by posting data. Focus on metadata registered in DoD Metadata Repository.

17. Defense Information System Network (DISN). The DoD consolidated worldwide enterprise-level telecommunications infrastructure that provides the end-to-end information transfer network for supporting military operations.

18. Defense-in-Depth. The DoD approach for establishing an adequate IA posture in a shared-risk environment that allows for shared mitigation through: the integration of people, technology, and operations; the layering of IA solutions within and among IT assets; and, the selection of IA solutions based on their relative level of robustness.

19. Designated Accrediting Authority (DAA). The official with the authority to formally assume responsibility for operating a system at an acceptable level of risk. This term is synonymous with Designated Accrediting Authority and Delegated Accrediting Authority.

20. DMZ (Demilitarized Zone). Perimeter network segment that is logically between internal and external networks. Its purpose is to enforce the internal network's IA policy for external information exchange and to provide external, untrusted sources with restricted access to releasable information while shielding the internal network from outside attacks. A DMZ is also called a "screened subnet."

21. DoD Information System. Set of information resources organized for the collection, storage, processing, maintenance, use, sharing, dissemination, disposition, display, or transmission of information. Includes P/S/A/S applications, enclaves, outsourced IT-based processes, and platform IT interconnections.

22. Domains. In this Directive, domains are subsets of Mission Areas and represent a common collection of related, or highly dependent, information capabilities and services. Managing these related information capabilities and services within domains improves coordination, collaboration, integration, and consistency of processes and interfaces for information sharing.

23. Enclave. Collection of computing environments connected by one or more internal networks under the control of a single authority and security policy, including personnel and physical security. Enclaves always assume the highest mission assurance category and security classification of the P/S/A/S applications or outsourced IT-based processes they support, and derive their security needs from those systems. They provide standard IA capabilities such as boundary defense, incident detection and response, and key management, and also deliver common applications such as office automation and electronic mail. Enclaves are analogous to general support systems. Enclaves may be specific to an organization or a mission, and the computing environments may be organized by physical proximity or by function independent of

65 UNCLASSIFIED

525526

527528

52912911292129312941295129612971298129913001301130213031304130513061307130813091310131113121313131413151316131713181319132013211322132313241325132613271328132913301331133213331334133513361337133813391340134113421343

530531532


location. Examples of enclaves include local area networks and the applications they host, backbone networks, and data processing centers.

24. Enterprise Information Environment Mission Area. The Department of Defense’s Mission Area responsible for managing the part of the DoD portfolio known as the enterprise information environment (EIE), which is the common, integrated computing and communications environment of the GIG. The EIE is composed of GIG assets that operate as, or that assure, local area networks, campus area networks, tactical networks, operational area networks, metropolitan area networks, and wide area networks. The EIE is also composed of GIG assets that operate as, or that assure, end user devices, workstations, and servers that provide local, organizational, regional, or global computing capabilities. The EIE includes all software associated with the operation of EIE assets and the development environments and user productivity tools used in the GIG. The EIE includes a common set of enterprise services, called Core Enterprise Services, which provide awareness of, access to, and delivery of information on the GIG.

25. Enterprise. Refers to the Department of Defense, its organizations, and related Agencies.

26. Extensible Markup Language (XML) is a tagging language used to describe and annotate data so it can be consumed by human and system interactions. XML is typically arranged hierarchically using XML elements and attributes. It also uses semantically rich labels to describe elements and attributes to enable meaningful comprehension. An example of XML data describing an element named “Person” appears as follows:

<Person><FirstName>John</FirstName><MiddleInitial>H</MiddleInitial><LastName>Doe</LastName></Person>

27. Federated Data. Data that is joined or otherwise merged. The information from multiple data sources, of potentially different types. It should do this in a manner that is invisible to the end user, who should be able to merely issue a standard query to the system and receive the consolidated results. This is a capability that is independent of any abstraction layer and provides uniform, integrated access to disparate systems.

28. For Official Use Only (FOUO). In accordance with DoD 5400.7-R. DoD information exempted from mandatory public disclosure under the Freedom of Information Act (FOIA).

29. 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 war fighters, policy makers, and support personnel.

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

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

32. Information Capability. The ability to consume and generate information in the form of data assets by performing a specific task using IT and/or NSS.

66 UNCLASSIFIED

533534

535536

53713441345134613471348134913501351135213531354135513561357135813591360136113621363136413651366136713681369137013711372137313741375137613771378137913801381138213831384138513861387138813891390139113921393139413951396

538539540


33. Information Owner. Official with statutory or operational authority for specified information and responsibility for establishing the controls for its generation, collection, processing, dissemination, and disposal.

34. Information Technology (IT). Any equipment or interconnected system or subsystem of equipment that is used in the automatic acquisition, storage, manipulation, management, movement, control, display, switching, interchange, transmission, or reception of data or information by the DoD Component. For purposes of the preceding sentence, equipment is used by a DoD Component if the equipment is used directly by the DoD Component or is used by a contractor under a contract with the DoD Component which requires the use of such equipment or requires the use, to a significant extent, of such equipment in the performance of a service or the furnishing of a product. The term “information technology” includes computers, ancillary equipment, software, firmware and similar procedures, services (including support services), and related sources. It also includes NSS as defined below. Notwithstanding the above, the term “information technology” does not include any equipment that is acquired by a Federal contractor incidental to a Federal contract.

35. 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. Note that, in a formal security mode, integrity is interpreted more narrowly to mean protection against unauthorized modification or destruction of information.

36. Interim Approval to Operate (IATO) . Temporary authorization to operate a DoD information system under the conditions or constraints enumerated in the accreditation decision. An IATO accreditation decision is intended to manage IA security weaknesses, and must specify an Authorization Termination Date (ATD) that is within 180 days of the authorization date.

37. Law, Policy, or Security Classification. The pertinent statutory and regulatory authority dealing with data assets includes, but is not limited to: personal information, intelligence information, medical information, information on a non-DoD person, and classified information.

38. Metadata. Information describing the characteristics of data; data or information about data; or descriptive information about an entity’s data, data activities, systems, and holdings. For example, discovery metadata is a type of metadata that allows data assets to be found using enterprise search capabilities.

39. Metadata Registry. A metadata registry is a system that contains information that describes the structure, format, and definitions of data. Typically, a registry is a software application that uses a database to store and search data, document formats, definitions of data, and relationships among data. System developers and applications are the predominant users of a metadata registry.

A federated metadata registry is one in which multiple registries are joined electronically through a common interface and exchange structure, thereby effecting a common registry.

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

41. Mission Assurance Category (MAC). Applicable to DoD information systems, the mission assurance category reflects the importance of information relative to the achievement of DoD goals and objectives, particularly the war fighters' combat mission. Mission assurance categories are primarily used to determine the requirements for availability and integrity. The Department of Defense has three defined mission assurance categories:

67 UNCLASSIFIED

541542

543544

54513971398139914001401140214031404140514061407140814091410141114121413141414151416141714181419142014211422142314241425142614271428142914301431143214331434143514361437143814391440144114421443144414451446144714481449

546547548


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.

42. Mobile Code. Software modules obtained from remote systems, transferred across a network, and then downloaded and executed on local systems without explicit installation or execution by the recipient.

43. National Information Assurance Partnership (NIAP). Joint initiative between the NSA and the National Institute of Standards and Technology responsible for security testing needs of both IT consumers and producers and promoting the development of technically sound security requirements for IT products and systems and appropriate measures for evaluating those products and systems.

44. National Security Systems (NSS). Any telecommunications or information system operated by the U.S. Government, the function, operation, or uses of which involves intelligence activities; involves crypto logic activities related to national security; involves command and control of military forces; involves equipment that is an integral part of a weapon or weapons system; or is critical to the direct fulfillment of military and intelligence missions, but excluding any system that is to be used for routine administrative and business applications (including payroll, finance, logistics, and personnel management applications).

45. Need-to-Know Determination. Decision made by an authorized holder of official information that a prospective recipient requires access to specific official information to carry out official duties.

46. Need-to-Know . Necessity for access to, or knowledge or possession of, specific official DoD information required to carry out official duties.

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

68 UNCLASSIFIED

549550

551552

55314501451145214531454145514561457145814591460146114621463146414651466146714681469147014711472147314741475147614771478147914801481148214831484148514861487148814891490149114921493149414951496149714981499150015011502

554555556


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 (NCW).

48. Network-Centric Warfare (NCW). An information superiority-enabled concept of operations that generates increased combat power by networking sensors, decision makers, and shooters to achieve shared awareness, increased speed of command, higher tempo of operations, greater lethality, increased survivability, and a degree of self-synchronization. In essence, NCW translates information superiority into combat power by effectively linking knowledgeable entities in the battle space.

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

50. Official DoD Information. All information that is in the custody and control of the Department of

Defense, relates to information in the custody and control of the Department, or was acquired by DoD employees as part of their official duties or because of their official status within the Department.

51. Platform IT Interconnection. For DoD IA purposes, platform IT interconnection refers to network access to platform IT. Platform IT interconnection has readily identifiable security considerations and needs that must be addressed in both acquisition, and operations. Platform IT refers to computer resources, both hardware and software, that are physically part of, dedicated to, or essential in real time to the mission performance of special purpose systems such as weapons, training simulators, diagnostic test and maintenance equipment, calibration equipment, equipment used in the research and development of weapons systems, medical technologies, transport vehicles, buildings, and utility distribution systems such as water and electric. Examples of platform IT interconnections that impose security considerations include communications interfaces for data exchanges with enclaves for mission planning or execution, remote administration, and remote upgrade or reconfiguration.

52. Post in Parallel. Process owners make their data available on the net as soon as it is created. Focus on data being tagged and posted before processing.

53. Privacy Data. Any record that is contained in a system of records, and information the disclosure of which would constitute an unwarranted invasion of personal privacy.

54. Proprietary. Information that is provided by a source or sources under the condition that it not be released to other sources.

55. Proxy. Software agent that performs a function or operation on behalf of another application or system while hiding the details involved. Typical proxies accept a connection from a user, make a decision as to whether or not the user or client network address is authorized to use the requested service, optionally perform additional authentication, and then complete a connection on behalf of the user to a remote destination.

56. Public Domain Software. Software not protected by copyright laws of any nation that carries no warranties or liabilities, and may be freely used without permission of or payment to the creator.

57. Public Information. Official DoD information that has been reviewed and approved for public release by the information owner.

69 UNCLASSIFIED

557558

559560

56115031504150515061507150815091510151115121513151415151516151715181519152015211522152315241525152615271528152915301531153215331534153515361537153815391540154115421543154415451546154715481549155015511552155315541555

562563564


58. Robustness. A characterization of the strength of a security function, mechanism, service or solution, and the assurance (or confidence) that it is implemented and functioning correctly. The Department of Defense has three levels of robustness:

Basic Robustness: Security services and mechanisms that equate to good commercial practices.

Medium Robustness: Security services and mechanisms that provide for layering of additional safeguards above good commercial practices.

High Robustness: Security services and mechanisms that provide the most stringent protection and rigorous security countermeasures.

59. Security Domain . Within an information system, the set of objects that is accessible. Access is determined by the controls associated with information properties such as its security classification, security compartment or sensitivity. The controls are applied both within the information system and in its connection to other classified or unclassified information systems.

60. Semantic Metadata . Information about a data asset that describes or identifies characteristics about that asset that convey meaning or context (e.g., descriptions, vocabularies, taxonomies).

61. Sensitive But Unclassified (SBU). A term commonly and inappropriately used within the Department of Defense as a synonym for Sensitive Information, which is the preferred term.

62. Sensitive Compartmented Information (SCI). Classified information concerning or derived from intelligence sources, methods, or analytical processes, which is required to be handled within formal access control systems established by the Director of Central Intelligence.

63. Sensitive Information . Information the loss, misuse, or unauthorized access to or modification of could adversely affect the national interest or the conduct of Federal programs, or the privacy to which individuals are entitled under Section 552a of title 5, United States Code, "The Privacy Act", but which has not been specifically authorized under criteria established by Executive order or an Act of Congress to be kept secret in the interest of national defense or foreign policy (Section 278g-3 of title 15, United States Code, "The Computer Security Act of 1987". This includes information in routine DoD payroll, finance, logistics, and personnel management systems.

64. Shared Space. Storage on a file server or in electronic media that is addressable by multiple users or COIs. Also, web services that are made available to the enterprise that expose the business or mission processes that generate data in readily consumable forms.

65. Smart Pull (vice Smart Push). Applications encourage discovery; users can pull data directly from the net, or use value added discovery services. Focus on data sharing, with data stored in accessible shared space and advertised (tagged) for discovery.

66. Structural Metadata. Information provided about a data asset that describes the internal structure or representation of a data asset (e.g., database field names, schemas, web service tags).

67. Understandable. Capable of being comprehended in terms of subject, specific content, relationships, sources, methods, quality, spatial and temporal dimensions, and other factors.

68. Users. Humans, systems, and applications that create, find, access, and exploit data. Also known as consumers and producers, or publishers and subscribers. System developers are also considered

70 UNCLASSIFIED

565566

567568

56915561557155815591560156115621563156415651566156715681569157015711572157315741575157615771578157915801581158215831584158515861587158815891590159115921593159415951596159715981599160016011602160316041605160616071608

570571572


to be users. For this Directive, users may be expected and planned for, or unanticipated and not planned for.

69. Visible. Able to be seen, detected, or distinguished and to some extent characterized by humans and/or IT systems, applications, or other processes.

70. Web Services. A standardized way of integrating web-based applications using open standards over an Internet Protocol backbone. Web services allow applications developed in various programming languages and running on various platforms to exchange data without intimate knowledge of each application’s underlying IT systems.

71 UNCLASSIFIED

573574

575576

57716091610161116121613161416151616161716181619

578579580

netops checklist

Business

netops readiness reviews

definition of netops

disa netops goals

disas netops vision

gig netops vision

netops essential tasks

updated nrrb process

merge of process