A waiver is a permanent approved exclusion or deviation from information security standards.

Defense Information System Network

Connection Process Guide

Version 6 | 2020

Defense Information Systems Agency
Risk Management Executive (RME)
Risk Adjudication and Connection Division (RE4)
Post Office Box 549
Fort Meade, Maryland 20755-0549
https://cyber.mil/connect/connection-approval/

EXECUTIVE SUMMARY

DoDI 8010.01 defines DISN as:
“DoD’s enterprise capability of DoD-owned and -leased telecommunications and computing subsystems, networks, and capabilities, centrally managed and configured by DISA, to provide an integrated network with cybersecurity, telecommunication, computing, and application services and capabilities (e.g., voice, video, teleconferencing, computing, imagery, satellite, and data services) for all DoD activities and their authorized mission partners.”

The Defense Information System Network (DISN) Connection Process Guide (DCPG) implements responsibilities assigned to the Director of DISA in the Department of Defense Instruction (DoDI) 8010.01, DODIN Transport and DoDI 8500.01, Cybersecurity to oversee and maintain the DISN connection approval process.  In addition, this document also provides the necessary requirements and processes established by Chairman of the Joint Chief of Staff Instruction (CJCSI) 6211.02D Defense Information System Network (DISN) Responsibilities, which states that all connections to the DISN shall be in accordance with (IAW) this DCPG.   

The goal of the DCPG is to describe a process that will help the warfighter, DoD Components, and DoD Mission Partners obtain DISN services while ensuring DISA effectively tracks and securely manages connections to the DISN.

The DCPG complies with current version of the DoD policies listed in the References Section (Appendix N) and does not establish DoD policy.  

The DISA Public Affairs Office approved this DCPG for public release.  The current DCPG is available on the Internet from the DISA website:

https://cyber.mil/connect/connection-approval/

Underlined text indicates a hyperlink to other Sections of the DCPG. To navigate a hyperlink to a reference, definition, or point of contact:

• Position your cursor over the hyperlink, press and hold the “CTRL” key on your keyboard, then click the left-mouse-button
• To return to the text, press and hold the “ALT” key then press the left-arrow-key on the keyboard. (This makes navigating the DCPG very simple.)

The instructions in this guide are effective immediately.  Major updates shall be approved by DoD CIO.  Interim updates to this guide (e.g., Version 6.1) shall be issued as required by the DISA Risk Management Executive/Authorizing Official. 

Sections 1 and 2 of the DCPG provides guidance for the end-to-end life cycle processes of the connection requirement.  The Appendices provide additional detailed guidance and necessary information associated with respective portions of the life cycle of the connection requirement and allows customers to focus on those areas of the process most relevant to their needs.

Please send suggestions for improving the DCPG to the DISN Connection Approval Office (CAO). 

Approvals:

REVISION HISTORY

DISA will review and update this guide as directed or as needed.  The revision history table reflects critical and substantive changes.  The Revision History starts with Version 5.0 release.

LIST OF FIGURES

Figure 1   DISN Connection Process Overview.

Figure 2   DoD Component customer obtains a SNAP/SGS Account.

Figure 3   DoD CIO review and approval workflow for commercial alternatives to DISN-provided transport and non-standard cloud services and unapproved cloud access points.

Figure 4   DODIN Internet Gateways: Internet Access Points (IAP) and Authorized Alternate Connections (ACC) Connection Types.

Figure 5   DoD Mission Partner Connections to DISN.

Figure 6   DoD CIO MOA for a Federal Mission Partner Connection to DISN.

Figure 7   C-ITP Registration and Connection.

Figure 8   C-ITP Connection to a Provisionally Authorized CSO via the appropriate CAP.

Figure 9   Cloud Connection Sustainment and Maintenance Process.

Figure 10  CSO Authorization, Registration, and Connection Process.

Figure 11  Activating the CSO Connection to the DISA BCAP/ICAP.

Figure 12  Permanently Discontinue a CSO Connection to DISN.

Figure 13  NIPR/SIPR Customer Network Enclave Topology Sample.

Figure 14  JRSS Security Stack Topology Overlay.

Figure 15  Sample DSN Topology.

Figure 16  Example Installation Topology.

Figure 17  RMF Lifecycle.

Figure 18  CDS Connection Process.

Figure 19  P2P CDS Exemption Review/Approval.

Figure 20  Streamlined Onboarding Process for an ECDSP.

Figure 21  IC CDS Registration Process.

Figure 22  Generic DISN DMZ and Gateway Connections.

Figure 23  The NFG Connection Process.

Figure 24  NFG Firewall Policy Change Process.

Figure 25  The SIPRNet FED DMZ Connection Process.

LIST OF TABLES

Table 1  DISN services addressed in this guide.

Table 2  Registration and Connection Process Information and Tailored Guidance.

Table 3   Description of unclassified DODIN commercial connections referenced by DoDI 8010.01, paragraphs 4.4.f through 4.4.i.

Table 4  Other Policy and Guidance for Cross Domain Solutions.

Table 5  Initial SIPRNet Scan Prerequisites.

1 INTRODUCTION

1.1 Purpose

“The Defense Information System Network (DISN) is the core element of DODIN transport. All connections to the DISN, including DoD Component and mission partner systems connected to DISN gateways, must be implemented and registered in the DODIN tracking and management repository in accordance with the DISN Connection Process Guide (DCPG) and DISN Cloud Connection Process Guide (DCCPG).” DoDI 8010.01, DODIN Transport

Establishing and sustaining the cybersecurity of the DODIN is one of the most serious challenges facing DoD and our Mission Partners.  The DISN connection approval process significantly influences the continued availability, reliability, and performance of DISN services for all DoD.  The DISN Connection Process Guide (DCPG) outlines procedures DoD Components and Mission Partners follow to obtain and retain an enclave or network connection to the DISN that helps protect the DODIN as a whole.  The DCPG does not establish policy, instead it is a guide for ensuring due diligence that all appropriate policies, procedures, and guidelines are followed when connecting a DoD Component or Mission Partner enclave or network to DISN.  

1.2 Authorities

The DCPG implements portions of the following issuances[1] related to DISN connections:

· DoDD 5105.19, Defense Information Systems Agency

· DoDD 5144.02, DoD Chief Information Officer

· DoDI 5000.02T, Operation of the Defense Acquisition System

· DoDI 5000.74, Defense Acquisition Services

· DoDI 8010.01, DODIN Transport

· DoDI 8100.04, DoD Unified Capabilities (UC)

· DoDI 8500.01, Cybersecurity

· DoDI 8510.01, Risk Management Framework for DoD Information Technology (IT)

· DoDI 8530.01, Cybersecurity Activities Support to DoD Information Network Operations

· DoDI 8540.01, Cross Domain (CD) Policy

· DoDI 8551.01, Ports, Protocols, and Services Management (PPSM)

· CJCSI 6211.02D, Defense Information System Network (DISN): Responsibilities

· DoD CIO Memorandum, Updated Guidance on the Acquisition and Use of Commercial Cloud Computing Services

· DoD Cloud Computing Security Requirements Guide (CC SRG)

1.3 General Guidance

The DISN Connection Process Guide (DCPG) is a living document that continues to evolve as processes are refined and as additional networks/services become available.  Always check for the current version of the DCPG.  This version of the DCPG focuses on connections to DISN services summarized below in Table 1.

1.4 Scope

This guide applies to all DoD Component and Mission Partner enclave owners seeking to connect to the DISN or DoD-authorized cloud computing services. 

This version of the DCPG consolidates the connection processes for DISN and DoD cloud computing services into one document, helps customers understand connection requirements and timelines, and provides contacts for assistance throughout the process.  Figure 1 depicts the DISN connection process.  Where appropriate, this guide refers customers to related websites and points of contact.  The connection process described in this Section of the guide applies to all DISN services.  The appendices listed in Table 2 supplement Section 2 of this guide by providing supporting information and tailored guidance unique to individual DISN customers and services.  Any type of connection or service that involves unified capabilities must comply with DoDI 8100.4 requirements.

NOTE: Proceed to Section 2.6 of this guide if renewing an existing DISN connection.

2.1 The DoD Component lead identifies the Customer and the Required Service

The DoD Component first determines the required service and if the DoD Component or the DoD Component’s Mission Partner will use the service.

The DISN services catalog is the portal that lists and describes available DISN and DISA-provided services.

2.2 Is DoD CIO Approval Required?

Connections made that are not compliant with DoD policy and this guide or do not have a valid DoD CIO waiver are not authorized, will be reported to JFHQ-DODIN for disconnection, and may jeopardize approval of other complicit DISN or DODIN connections.

2.2.1Is this a request to use a commercial alternative to DISN-provided transport, non-compliant cloud service, or unapproved cloud access point?

IAW DoDI 8010.01, DODIN Transportparagraph 4.4.a requires DoD CIO review and approval of a DoD Component request for - “commercial transport services procured as an alternative to DISN-provided transport.” 

In addition, paragraph 4.5 in DoDI 8010.01 requires a connection to a Cloud Service Offering (CSO) to be “implemented in accordance with the CC SRG.”  DoD CIO approval is required before using a cloud service that does not comply with the CC SRG or for the use of a Cloud Access Point that has not been approved by the DoD CIO.

If the desired service requires DoD CIO approval, proceed to Appendix A of this guide. 

2.2.2Is this a request for a Mission Partner[3] Connection to DISN?

DoDI 8010.01 paragraph 2.1.g states that the DoD Chief Information Officer (CIO) - “Reviews and approves DoD Component requests for mission partner connections to DISN.”

If the request is for a mission partner connection to the DISN, then proceed to Appendix B of this guide that describes the DoD CIO process for approving a mission partner connection to the DISN. 

2.3 Is this a request for a cloud computing connection?

DISA is currently integrating cloud computing services into the DISN provisioning process.  For this version of the DCPG, proceed to Appendix C that documents the procedures for authorization, registration, connection, sustainment, and discontinuation of a Cloud Computing connection to DISN. 

2.4 The DoD Component requests the required DISN service

Only a DoD Component can initiate a request for a DISN connection either for the DoD Component or for a Mission Partner.  The DoD Component uses DISA StoreFront (DSF) to order DISN services available in DSF or use the “How to Order” link in the DISN services catalog. 

2.4.1The DoD Component requests the required DISN service using DSF

Use the unclassified DSF web page to request the DISN service.  Do not post classified information to the unclassified DSF web page.  The Classified DSF Portal is in the acquisition phase but not yet available.  Currently, classified services can be ordered several different ways.  If you require classified services, contact the DISA Mission Partner Engagement Office (MPEO) for assistance. 

The DSF web page has descriptions of DISN services that include UC, DSN, voice, video, data, computing services[4]  The DSF also describes service features, service support, billing rates, and procedures for ordering the service.  The DISN Mission Partner Portal and DISA Mission Partner Engagement Office are helpful sources of additional information about DISN and cloud computing services.  For Help with DSF or general order entry questions/concerns contact the GIG Service Management Organization (GSM-O) Customer Advocacy Group.   

2.4.2A TSO assigns a unique identifier for the connection

After the DoD Component has entered a DISN connection request in DSF, a Telecommunications Service Order (TSO) is issued to the DoD Component that includes a Command Communications Service Designator (CCSD) or other unique system identifier (e.g., a Virtual Private Network (VPN) Identifier, Virtual Routing and Forwarding Identifier (VRF ID)) assigned in the TSO issued for the connection.  The DoD Component provides the CCSD or other unique system identifier when registering and maintaining information about their enclave connection in the SNAP or SGS as described in this guide. 

2.5 Is this a DISN customer request to discontinue an existing service?

A DISN customer must submit a request via DSF to discontinue permanently an existing DISN service.  When the customer submits a discontinuation request, the process proceeds to Section 2.16 of this guide that describes how DISA permanently disables the connection and ceases billing the customer for the discontinued service.

2.6 The customer obtains an Authorization Decision Document (ADD) with supporting artifacts

Customers must ensure Assessment and Authorization (A&A) of all enclaves or networks IAW the appropriate standard prior to connection to the DISN. 

For reauthorization of an existing connection, the DISN customer should initiate enclave A&A and obtain an authorization decision before the Authorization Termination Date (ATD)[5] established in the ADD for the enclave/network.

For a new physical or logical connection, the DISN customer obtains an authorization decision for their enclave/network IAW the applicable A&A guidance as described in Section 2.6.1.  The ADD must include the Command Communications Service Designator (CCSD), Virtual Private Network (VPN) Identifier, or Virtual Routing and Forwarding Identifier (VRF ID)) assigned in the TSO issued for the connection (see Section 2.4.2),  or other unique system identifier such as the Universal System Identifier (USI) assigned by SNAP when registering a DSN voice switch, or the system’s DITPR ID. 

The customer may leverage Type-Authorized systems as its Authorization decision as outlined in the RMF Knowledge Service provided there are no significant changes to the archetype (common) configuration, otherwise a separate authorization decision is required with associated documentation.   Refer to the RMF Knowledge Service (RMF KS website) for additional guidance.  DISA hosted customers must document the security control inheritance model used for authorization decisions identified on the RMF KS website.  At the completion of the A&A process, the Authorizing Official (AO) for the enclave or network issues an ADD in the form of an Authorization to Operate (ATO), ATO-with-Conditions, or an Interim Authorization to Test (IATT)[6].  Note that the DoD RMF process no longer permits an “Interim Authorization to Operate.” 

2.6.1Applicable Assessment and Authorization Guidance. 

The appropriate standard used to A&A an enclave or network prior to connection to the DISN varies depending on the customer as described in DoDI 8500.01, DoDI 8510.01, the DoD RMF KS website, and CJCSI 6211.02D:

a. DoD Components authorize DoD Component and unclassified DoD Contractor enclaves or networks and prepare a Security Authorization Package
IAW DoDI 8500.01 and DoDI 8510.01[7] and issue an ADD for the contractor enclave/network IAW CJCSI 6211.02D, Enclosure B, paragraph 2.C.(7).

b. The Defense Counterintelligence and Security Agency (DCSA)[8] (formerly the Defense Security Service (DSS)) authorizes Classified DoD Contractor Enclaves/Networks IAW DoDI 8510.01 and DoD 5220.22-M. 

c. Intelligence Community (IC) authorizes enclaves or networks IAW Intelligence Community Directive (ICD) 503.

d. Federal Mission Partners Authorize National Security Systems (NSS) in accordance Committee on National Security Systems Instruction (CNSSI) No. 1253 and as stipulated in a DoD CIO agreement IAW DoDI 8010.01.

e. Federal Mission Partner authorizes non-NSS systems IAW National Institute of Standards and Technology (NIST) 800-37 and as stipulated in a DoD CIO agreement IAW DoDI 8010.01 as described in Appendix B of this guide.

f.Other Mission Partners enclaves/networks connections to DISN are authorizedIAW standards stipulated in a formal agreement with the DoD Component sponsor (e.g., Support Agreement, Mission Partner Environment (MPE) Joining/Membership/Exit Instruction, Memorandum of Agreement, contract, terms of reference) and validated by DoD CIO as described in Appendix B of this guide.

2.6.2Type-Authorized Systems. 

A Type-Authorized System is used to deploy identical copies of an IS or PIT system in specified environments. This method allows a single security authorization package to be developed for an archetype (common) version of a system. The system can be deployed to multiple locations with a set of installation, security control and configuration requirements, or operational security needs that will be provided by the hosting enclave.  When Type Authorized Systems are implemented as the only IT system in a local enclave, the Type Authorization package can be used for the SNAP or SGS registration, but must have a topology that shows, among other things, the unique IP addresses and CCSD assigned to that enclave.  If there are significant changes to the archetype (common) configuration, a separate authorization decision is required with associated documentation.  When multiple IT systems reside on an enclave, the enclave authorization package is used for the SNAP or SGS registration.  See the RMF Knowledge Service for additional guidance.

2.6.3Cross Domain Solutions and the RMF Assessment and Authorization (A&A) process  

Cross Domain Solutions (CDS) are IT products that do not undergo the RMF A&A process.  A CDS is issued a Cross Domain Solution Authorization (CDSA) obtained IAW DoDI 8540.01 as described in Appendix G of this guide.  AOs should leverage CDS risk assessments and approvals when implementing.

2.7 The customer registers the information system in DoD repositories

2.7.1The Customer registers the Information System in the DoD IT Program Repository (DITPR), SIPRNet IT Registry (SITR), and the Defense Information Technology Investment Portal (DITIP)

DoDI 8500.01 and CJCSI 6211.02D require that DoD Components register Information Systems (IS) in the DoD Information Technology Portfolio Repository (DITPR).  Use of the unclassified DITPR is preferred for registration of all ISs including classified systems.  The entries for classified systems in DITPR do not include any classified information.  However, a DISN customer may register an IS using the SITR if information about the system must contain classified material, or, if the organization, such as a Combatant Command, routinely uses the SIPRNet.  To obtain a DITPR account, contact the DoD IT Portfolio Repository POC.  For a SITR account, contact the SITR POC.  Note thatthe DISN customer may also need to update DoD Component internal IT program registration database with system information.  

IAW DoD 7000.14-R, all IT resources must be reported within investments.  The Defense Information Technology Investment Portal (DITIP) provides for the entry and maintenance of common investment data elements in DITPR and Select and Native Programming Data Input System for Information Technology (SNaP-IT).

2.7.2The customer register a SIPRNet connection with the SIPRNet Support Center (SSC)

Register ISs connected to SIPRNet with the SSC.  Refer to the SSC website on SIPRNet for details.

2.7.3Obtain a PPSM Tracking Identifier

IAW DoDI 8551.01, Ports, Protocols, and Services Management (PPSM) DISN customers must register their system’s ports and protocols in either the SIPRNet or NIPRNet version of the PPSM Registry as appropriate.  DISN CAO will only approve a connection request that includes a valid PPSM Tracking Identifier.  Customers may collaborate with their DoD Component’s PPSM TAG representative to get ports, protocols, and services (PPS) registered in the PPSM Registry located on SIPRNet or NIPRnet.  A PPSM account is required for access.  Request accounts through your DoD Component PPSM TAG representative. 

A customer enclave, network, or application that requires information to traverse both the NIPRNet and the Internet may need to register this requirement in the NIPRNet Demilitarized Zone (DMZ) Whitelist to ensure the DISN Internet Access Points (IAPs) are configured to permit information to flow between the Internet and NIPRNet[9].  The DISN customer should consult with their DoD Component sponsor’s PPSM TAG representative to determine whether the ports, protocols and services required by the DISN customer must be registered in the NIPRNet DMZ Whitelist.

DoD IS and Platform IT (PIT) systems must have only a single valid authorization IAW DoDI 8510.01 Enclosure 5-Cybersecurity Reciprocity. Multiple authorizations indicate multiple systems under separate ownership and configuration control. PPSM registration for enterprise/core services is the responsibility of the service provider. Receiving organizations will execute a documented agreement between the provider and the receiver (e.g., memorandum of understanding (MOU), memorandum of agreement (MOA), SLA) for the maintenance and monitoring of the security posture of the system (security controls, cybersecurity service provider (CSSP), etc.).

For more information on PPSM, please refer to the DISA RE42 PPSM home page, the DISA PPSM web page, access PPSM computer based training at DISA Risk Adjudication and Connection Division’s Mission Partner Training Program (MPTP), or contact the DoD PPSM team (DISA RE42). 

2.7.4Align to a DoD operations security center (OC) and supporting Cybersecurity Service Provider (CSSP)

DoDI 8530.01 requires that DoD Components align their systems with a joint or DoD Component operations center (OC) and supporting Cybersecurity Service Provider (CSSP) to allow mission operators to have confidence in the confidentiality, integrity, and availability of DoD IT and DoD information.  U.S. CYBERCOM maintains a list of DoD certified and accredited CSSPs under the Cybersecurity Service Provider (CSSP) Program.  The Defense Working Capital Fund (DWCF) Rate Book includes billing information for Cybersecurity services provided by the DISA CSSP Office. 

2.8 DoD Component registers connection information in SNAP or SGS

IAW DoDI 8010.01, DoD Components must “implement and register all connections to the DISN, including DoD Component and Mission Partner systems connected to DISN gateways, in the DODIN tracking and management repository IAW the DCPG.”  DISA currently implements this policy using the DISA SNAP database on NIPRNet and the SGS database on SIPRNet to track connections to DISN.  The SNAP database on NIPRNet has modules for registering requests for unclassified services including: DSN and UC, NIPRNet (unclassified IP-based data services), VPN services, Cloud computing connections to DISN, DoD CIO Approval of Commercial Alternatives to DISN Enterprise Services, and DoD CIO Approval of Mission Partner Connections to DISN.  The SGS database on SIPRNet has modules for registering requests for classified services including: VPNs, SIPRNet (Secret GENSER IP-based data services), and Cross Domain Solutions.

DoD Components use the modules in SNAP or SGS to register connection requests that include information needed by the DISN CAO to determine whether to issue an Approval to Connect (ATC), Interim Approval to Connect (IATC), or a VPN Permission to Connect (PTC) to DISN. 

2.8.1 DoD Component customer obtains an account on the NIPRNet SNAP database or the SIPRNet SGS database

To request a SNAP or SGS account,

In your web browser

https://snap.dod.mil for NIPRNet SNAP

https://giap.disa.smil.mil for SIPRNet SGS

Select the green “Request Account”  as illustrated in Figure 2

Step 1:  On the “REQUEST SNAP ACCOUNT” web page:

Select the hyperlink for  “DD Form 2875”

On the “REFERENCE DOCUMENTS” web page

Select “All Systems”

Select “DD Form 2875” then “Download” the DD Form 2875 from SNAP and/or SGS located on the “Reference Documents” page

Complete the form DD 2875.  The user will need to provide the following information to complete the User Account Request form:

- First and last name

- Physical address

- DoD component, sub agency

- Unclassified e-mail address, commercial telephone number, DSN phone number

In section 13 of the DD Form 2875, “Justification for Access” mark  the SNAP and/or SGS module(s) you wish to access

Upload the completed and signed DD Form 2875 SAAR on the SNAP “REQUEST SNAP ACCOUNT” web page

· Step 2 – On the “REQUEST SNAP ACCOUNT” web page

Provide your profile information - asterisked item are required fields

When Step 1 and Step 2 are completed, select  the green “Submit Request” button at the bottom of the “REQUEST SNAP ACCOUNT” web page

· Step 3 – DISN CAO creates the SNAP Account.

Once the user has submitted all required information, a DISN CAO analyst will review the request for a SNAP/SGS account. 

SNAP and SGS users must renew their accounts annually by emailing an annual Cyber Awareness Challenge training certificate of completion to the DISN CAO. Otherwise, access to SNAP/SGS will be suspended.

The user will receive an e-mail message either approving the request for a SNAP/SGS account or explaining why DISN CAO denied the request.

2.8.2 DISN Customer logs into SNAP (Unclassified) or SGS (Classified) and registers the connection request:

Log on to SNAP for Unclassified Connections or SGS for Classified Connections.

Hover the cursor over the applicable DISN service tab.

Then select “View/Update.”

The customer interacts with the module to complete all “Information sections” in the NIPR/SIPR Checklist.  Note that SNAP reserves sections marked with a “pad locked” icon are for use by the DISN CAO Analyst.

2.8.3Required documents:

For either a logical enclave or physical enclave connection to DISN, the DoD Component uploads the following required documents into SNAP or SGS:

Authorization Decision Document (ADD) prepared IAW the applicable A&A policies listed in Section 2.6 of this guide and signed by the Authorizing Official (AO)

CSSP agreement IAW DoDI 8530.01 or as stipulated in agreements with Mission Partners.

· Topology prepared in accordance with guidance in Appendix E

Consent to Monitor  (may be included in the ADD - see the sample with instructions in Appendix I)

DoD Component CIO concurrence memo submitted to ISRMC and DoD CIO for an ATO issued for a Component IS with a level of risk of “Very High” or “High” for a non-compliant security control IAW DoDI 8510.01 Enclosure 4 paragraph 1.b.(2).(e) and Enclosure 6 paragraphs 2.e.(4).(b) and (e).

DoD Sponsor request for a Mission Partner connection to DISN:

For a DoD Contractor, Federal Department/Agency mission partner connection request, the DoD Sponsor also uploads the DoD CIO approval memo or Memorandum of Agreement (see Appendix B)

For a 5-Eyes, allied, or coalition mission partner connection request, the DoD Sponsor also uploads the Chairman of the Joint Chiefs of Staff approval memo IAW DoDI 5530.3 and CJCSI 6740.01C[10]

2.8.3.1 Other Supporting documents:

Recommend the customer upload the following RMF Security Package documents (prepared IAW A&A policies listed in Section 2.6 of this guide) to support Defensive Cyber Operations information sharing:

Security Plan (SP) (optional)

Security Assessment Report (SAR) (optional)

The SGS system is a repository for connections to SIPRNet at the Secret level. If a document or artifact associated with a system connection to SIPRNet is classified higher than Secret GENSER please contact the DISN CAO for additional guidance.

Plan of Action and Milestones (POA&M) (optional)

2.8.3.2 JRSS Connection Registration

Customers must reauthorize connections moving to the DISA JRSS Stack.  This only applies to NIPRNet connections at this time since SIPRNet connections are not yet moving to JRSS. 

The customer uses the following procedures to create a registration in the NIPRNet module:

1. To register a JRSS connection in SNAP, in the NIPRNet module select ‘New Registration’. 

2. In section 0, for Circuit Type, select JRSS instead of DoD.

3. In section 1, there is a question, 'Is this systems connection type JRSS?'  Select “Yes” and type in the VRF ID in the block below.  (NOTE:  Currently the VRF ID will not show if the customer goes to “My Entries” report.  Until this is fixed, the customer will have to search by Registration ID for that registration.)

4. Internal boundary defense equipment (firewall, IDS/IPS) is no longer required on the enclave’s topology diagram since JRSS provides cybersecurity perimeter protections.  The topology must show the JRSS stack as illustrated in Section E.2 of this guide.

5. The customer submits a JRSS package like any other NIPRNet Connection Approval package except that the customer identifies the JRSS by a “Virtual Routing and Forwarding Identifier (VRF ID)” rather than by a CCSD.  Please remember to identify the VRF ID (and associated CCSD if applicable) in the ADD and topology.  For additional information, contact the JRSS PMO.

2.8.3.3 Documentation for registering a VPN connection in SNAP/SGS:

In addition to the required documents and other supporting documents listed in Section 2.8.3 , the customer must upload the following VPN related documents:

When a VPN Owner registers a new VPN in SNAP/SGS, the VPN Owner must upload into SNAP/SGS the order confirmation email received from DSF that approves establishment of the VPN

When a VPN Member registers a connection to an existing VPN, the VPN Member uploads the email that contains the TSO issued by DSF that approves the VPN member's connection to the VPN

2.8.3.4 Documentation for a Dedicated Point-to-Point Connections and DISN Backbone Connections

DoDI 8010.01, paragraph 1.2.c requires DoD Components to register all connections to the DISN in the DODIN tracking and management repository (currently SNAP/SGS).  As such, dedicated point-to-point connections and DISN Backbone connections must be registered in SNAP or SGS (if classified).  A Dedicated point-to-point connection uses DISN transport but does not connect to NIPRNet, SIPRNet, or DSN.  A DISN Backbone Connection links DISN elements such as switches, sensors, gateways, network operations centers, and other active tools that are under the operational direction and management control of DISA.  The customer uploads the required documents and other supporting documents listed in Section 2.8.3. 

2.8.4The Customer submits the DISN Service Request to DISN CAO for review

When the customer has completed all SNAP/SGS Information sections and uploaded Security Package documentation, a “SUBMIT” button will appear at the bottom of the screen.  The customer selects this button to submit the connection request to DISN CAO for review.

2.9 DISN CAO reviews the connection request for “sufficiency and completeness”

After the DISN customer submits the connection request package, a DISA analyst performs a quality review of submitted evidence registered in SNAP or SGS for “sufficiency and completeness” consistent with DoDI 8510.01 (See enclosure 5 paragraph 1.e).  The DISN CAO confirms the following for a DISN connection request:

1. The AO signed the ADD and Consent to Monitor (CTM)
2. The enclave Topology was completed IAW guidance in Appendix E
3. DoD Component CIO concurrence memo submitted for a Component IS with a level of risk of “Very High” or “High” for a non-compliant security control
4. For a Mission Partner connection request, the DoD CIO approved the request as described in Appendix B
5. DoD enclaves or networks are “aligned to DoD network operations and security centers (NOSCs)” and a supporting CSSP IAW DoDI 8530.01 or as stipulated in an agreement with a Mission Partner
6. Cloud Services are approved and registered as outlined in Appendix C, paragraph C.2.
7. VPN Owner’s order confirmation or VPN Member TSO confirmation (where applicable)
8. For a new SIPRNet enclave connection:
   • DISN CAO issues an Interim Approval To Test (IATT) for the connection Note:  this is not the same as an Authorizing Decision Document (ADD) that may be issued by the system’s AO);
   • The customer then contacts the DISA Compliance Monitoring Team (CMT) to schedule a Remote Compliance Monitoring scan of the enclave/network as described in Appendix J.

IAW DoDI 8510.01, Enclosure 4, paragraph 1.a.(2), the DISN CAO will refer all new Federal Mission Partner SIPRNet connection requests to the Defense Security/Cybersecurity Authorization Working Group (DSAWG) and Information Security Risk Management Committee (ISRMC).  The DoD Component sponsor prepares a DSAWG and ISRMC presentation IAW the DSAWG briefing template.  The DoD Component sponsor and Mission Partner will upload the body of evidence and security related artifacts into SGS to support the briefing to the DSAWG.

2.10 Does the connection request meet connection requirements?

2.10.1 No, DISN CAO provides needed corrective actions to the Points of Contact

The DISN CAO analyst will identify corrective actions needed for the request to obtain an ATC or IATC.  SNAP/SGS will notify the customer POCs.  The customer logs into SNAP/SGS, makes the needed updates, and resubmits the connection request to DISN CAO as described in Section 2.8 of this guide.

2.10.2 Yes, DISN CAO issues an ATC or IATC

The SNAP/SGS database will send an automated email to the registration point of contact as proof of registration.  The email will have an ATC, or IATC[11] letter attached.  The approval will include an Approval Termination Date.  The DISN CAO typically completes the review of a complete connection request package within five business days.

a. Connection approval expiration date.  The Approval Termination Date for the DISA issued ATC or IATC, is usually the same as the Authorization Termination Date included in the customer’s ADD.  The expiration date for an ATC is also within three years unless the enclave has a system-level continuous monitoring program as described in Section 2.6 of this guide.  An IATC is normally limited to 180 days consistent with DoDI 8510.01 limit on an “ATO with Conditions.”  DISN CAO may grant an IATC for up to one year for units deployed in the CENTCOM area of responsibility.  In some instances, the risk assessment may warrant DISN CAO assigning an expiration date shorter than that of the associated ATO or IATT.  The IATC for an enclave operating under an IATT is normally for a period of less than 90 days IAW DoDI 8510.01.

b. For a Dedicated Point-to-Point Connection or DISN Backbone Connection.  DISA will email the Approval to Connect (ATC) letter to the customer.  The email will indicate the status of the dedicated connection as “Operational – No ATC.”  The customer does not need to renew the ATC for a dedicated point-to-point connection or DISN backbone connection.  DISN CAO will not report an “Operational – No ATC” connection in the 30/60/90-day report to JFHQ/DODIN.  However, the office of primary responsibility for the connection must keep the connection’s supporting documentation up to date in SNAP/SGS.

c. Reissuances of an ATC or IATC:  A significant change to an enclave or network may affect the cybersecurity posture of that enclave, and consequently, the risk the enclave poses to the DISN community at large.  A significant change may require the DISN customer to initiate an Assessment and Authorization before the ATC expiration date specified in the original connection approval letter.  If the DISN enclave has a significant change, the DISN customer must:

• Notify the DISN CAO of significant changes effecting the enclave connection
• Update topologies and risk decision artifacts,
• Update and resubmit the SNAP/SGS registration for the connection including updated Security Package documents described in Section 2.8 of this guide

d. Note:  The following events are not significant changes and do not require a new A&A effort and reissuance of the ATC or IATC.  Instead, the DISN customer must notify the DISN CAO of the proposed change and update the network topology diagram in SNAP/SGS before deployment/implementation.

• Deployment of new VoIP phones requiring a new VLAN segment in the enclave
• Deployment of a Video Teleconference product that is on the DoD UC APL
• Changes in the IP address range assigned to the IS/enclave
• DISA transport re-homing actions that change the connection points to DISN but the enclave remains at the same facility
• Change in the service’s bandwidth

2.11  DISA activates then sustains the operational connection to DISN

Upon receipt of the DISN CAO email containing the approval to connect (e.g., ATC, IATC) the DISA Global Operations Center (DGOC) activates the connection to the requested DISN service.  The customer must work with DISA Implementation Testing and Request Fulfillment Activations team to complete the connection and satisfy the customer’s operational requirement.  DISA sustains the DISN connection for the period specified in the ATC or IATC.  IAW DISA Circular 310-130-001, and DISA Circular 310-070-057, DISA performs Implementation, Testing, and Activation (IT&A) and Quality Management for each connection to ensure it is ready for use and has operational utility that meets the customer’s stated requirements.  For connection activation support, contact the DISA Implementation Testing and Request Fulfillment Activations team.  For Questions regarding Provisioning (Telecommunications Service Requirements (TSR) writing), or general request fulfillment status/questions contact DISA Provisioning Customer Support.  Contact the DISA Infrastructure Global Service Desk (IGSD) to report an outage or to request status of an outage.

2.11.1 IP-Based Access Connection

DoD CIO is leading efforts to terminate costly legacy network technologies and associated transport infrastructure circuits (e.g., TDM circuits) to align with Joint Information Environment (JIE) Reference and Solution Architectures and the Department of Defense Strategy for Implementing JIE by optimizing use of IP-based network infrastructure.  DISA will connect customers using existing IP bandwidth at DISN Infrastructure Service (DIS) (formerly DSS) locations or using a readily available commercial IP network at non-DIS locations.  For information on IP-based connection delivery timelines, contact the DISA IGSD.

2.11.2 TDM-Based Access Circuits

As stated in the DoD CIO Memo, Legacy Networking Technologies DISN customers use TDM or other legacy circuits only as a last resort when IP-based services are not available.  If a TDM circuit is required, DISA Circular 310-130-001 (Tables T1.1 through T1.4) provide estimated “Lead-Times For Service” to fulfill a circuit ordered through DSF.  Customers should utilize these circuit lead-times for planning purposes when ordering a physical circuit to minimize the time between delivery of circuit and activation of the circuit.  A critical path action is for the customer to complete the A&A process (see Section 2.6 of this guide) and obtain an ATO for the enclave.  A customer should only order a circuit when certain about completing all actions (including A&A activities) within the specified timeline to ensure best use of costly legacy circuits.[12]  There is an expedited process available, for service fulfillment and connection approval of an Emergency or Essential National Security/Emergency Preparedness telecommunications service requirement.  For additional information on TDM delivery timelines, contact the DISA IGSD.

2.11.3 Mission Partner Gateway (MPGW) Connections to DISN

DoDI 8010.01 tasks DoD Component heads to - “Leverage commercial IP network transport and cloud services available on Defense IT Contracting Organization contracts to securely connect to the DISN services if DISN service is not available at the required operating location.”

Mission partners connect to DISN through a MPWG IAW DoDI 8010.01 and CJCSI 6211.02D.  Appendix H addresses Mission Partner Gateway (MPGW) Connections to DISN.

2.12 Has the ATC expired?

In accordance with JFHQ DODIN Task Order 16-0158, Connection Accreditation Enforcement Process, each week DISN CAO runs a report in SNAP or SGS that lists DISN connection with an expired ATC.  The DISN CAO forwards the list of connections with an expired ATC to JFHQ DODIN for action as described in Section 2.15 of this guide.

2.13 Does the ATC expire within 90 days?

Each week, DISN CAO also runs a 90-day-pull report that builds a list of DISN connections with ATCs that expire within the next 30, 60, or 90 days. 

2.14 DISA posts the weekly 90-Day-Pull Report on SIPRNet.

DISA posts the weekly report on the 90-Day-Pull Warning Order (WARNORD) web page   Additionally, SNAP and SGS automatically sends email reminders to the registered points of contact for a connection reminding them to initiate actions required to renew these expiring approvals to connect to DISN. 

Upon receipt of the initial 90-day expiration warning, the DISN Customer should:

Obtain an updated ADD for the system as described in Section 2.6 of this guide. 

Update information about the system in SNAP/SGS

Submit the updated connection renewal request as described in Section 2.8 of this guide before the connection ATC expires.

The connection renewal cycle (Sections 2.8 through 2.14 of this guide) typically repeats until the DoD Component submits a request to discontinue permanently the DISN connection as described in Sections 2.5, and 2.16 of this guide.

The DISN CAO will then review the request as described in Sections 2.9 through 2.11 of this guide.

2.15 JFHQ DODIN issues a temporary disconnect Task Order (TASKORD) with corrective actions

An expired ATC will prompt a review by Joint Force Headquarters DODIN (JFHQ DODIN), and may result in an order to disconnect the enclave/network from the DISN service in accordance with JFHQ DODIN Task Order 16-0158, Connection Accreditation Enforcement Process. 

2.15.1 JFHQ DODIN Temporary Disconnection TASKORD provides corrective actions

A JFHQ DODIN Task Order (TASKORD) directs DISA to disconnect temporarily a DISN connection with an expired ATC.  JFHQ DODIN posts disconnection TASKORDs on the JFHQ DODIN Notification of Non-Compliant Circuit Disconnection website on SIPRNet.  The TASKORD includes guidance for the DISN customer to restore the connection.

2.15.2 DISA Implements the temporary disconnection order

JFHQ DODIN will direct DISA to disconnect temporarily the enclave’s connection to DISN.  The charges for the DISN connection will continue during the temporary disconnection. 

2.15.3 DISN customer completes required actions

The DISN customer completes the required corrective actions, updates information about the connection in SNAP or SGS system as required, and resubmits the request as described in Section 2.8 of this guide.  The DISN CAO will review the request as described in Section 2.9 of this guide.  If the connection request meets all requirements described in Section 2.10 of this guide, DISN CAO issues an approval to connect (e.g., ATC, IATC) and JFHQ DODIN directs DISA to restore the connection.  DISA restores the connection to sustainment status as described in Section 2.11 of this guide.

If the DISN customer determines that the connection to DISN is no longer required, the customer must submit a discontinuation request through DSF.  Charges for an access circuit stop after DISA processes the customer’s TSR requesting discontinuation of the enclave’s connection to DISN as described in Sections 2.5 and 2.16 of this guide.

2.16 DISA Permanently Discontinues the connection and updates SNAP/SGS

2.16.1 DISA Notifies Stakeholders about Service Discontinuation. 

In response to the DISN Customer request described in Section 2.5 of this guide, DISA Command Center will issue a DISA TASKORD to DISA Global to discontinue permanently the DISN connection.  DISA will apprise stakeholders (e.g., VPN members and Cloud service subscribers) about discontinuation actions affecting their connections so they can take appropriate action.  (If discontinuing a Cloud Service Offering (CSO), see supplemental procedures in Section D.2 of this guide.)

2.16.2 Discontinuation of a DISN Connection. 

DISA Global permanently disconnects the system from DISN.  For NIPRNet connections, DISA Global revises the NIPRNet DMZ Whitelist as needed.  When DISA completes processing of a TSR to discontinue a physical circuit, the DSF will update the Telecommunication Inventory and Billing Information (TIBI) entry for a reimbursable service (e.g., mobility, DISN IS services).  For pass-through services (e.g., DISN TDM access circuits), The Defense Information Technology Contracting Office (DITCO) will notify the commercial vendor, and manually update TIBI.  The pass-through charges for the commercial circuit will stop within 30 days.[13]  When the customer receives the e-mail containing the TSR that confirms the connection has been the discontinued, the customer must forward the email containing the TSR to the DISN CAO.  Upon receipt of the forwarded TSR, DISN CAO updates the appropriate repositories (e.g., SNAP, SGS).

The Life Cycle of a DISN Connection ends here. 

Appendix A DoD CIO review and approval of requests for commercial alternatives to DISN-provided transport and non-standard cloud services, and unapproved cloud access points

This Appendix describes the process used by a DoD Component to request DoD CIO review and approval of commercial alternatives to DISN-provided transport (referred to in this appendix as a DODIN commercial connection) and non-standard cloud services, and use of Boundary Cloud Access Points (BCAP) that lack an existing DoD CIO approval.

DoD policy requires DoD components to use DISN capabilities for transport and meet DoD standards for cloud services and use only approved cloud access points:

Per DoDI 8010.01, section 1.2, C:

“DoD Components will use the Defense Information Systems Network (DISN) as the core element of DODIN Transport.”

Per DoDI 8010.01, section 1.2, E:

“DoD Components will use the DISN-provided transport, when available, to satisfy DoD information transfer requirements between DoD installations and facilities….”

Per DoDI 8010.01, section 4.5:

“Connections to a cloud service offering (CSO), both internal and external to the DODIN, will be implemented in accordance with the DoD Cloud Computing Security Requirements Guide, the DCCPG (until integrated with the DCPG), and applicable DoD policy.”

Per DoD CIO Memo: Updated Guidance on the Acquisition and Use of Commercial Cloud Computing:
"Commercial cloud services used for Sensitive Data must be connected to customers through a Cloud Access Point (CAP) provided by DISA or through a CAP provided by another DoD Component."

DoD Components who have unique mission requirements that are unable to be met by the DISN or supported by DoD policy, may request authorized alternate connectivity.  Per DoD policy, DoD CIO review and approval is required for DODIN commercial connections and non-standard cloud services, and unapproved cloud access points:

Per DoDI 8010.01, section 3.2, F.2:

“Internet traffic will flow through one of the authorized IAPs, unless the DoD CIO has authorized alternate connectivity (e.g., intelligence, law enforcement, or other specific mission requirements).”

Per DoDI 8010.01, section 4.4, A:

“Commercial transport services procured as an alternative to the DISN-provided transport requires compliance with this issuance or DoD CIO review and approval.”

Per DFARS, 252.239-7010 Cloud Computing Services:

“The Contractor shall implement and maintain…in accordance with the Cloud Computing Security Requirements Guide (SRG) unless notified by the Contracting Officer that this requirement has been waived by the DoD Chief Information Officer.”

“The contracting officer may award a contract to acquire cloud computing services from a cloud service provider that has not been granted provisional authorization when-

(i) the requirement for a provisional authorization is waived by the DoD Chief Information Officer; or….”

Per DoD CIO Memo: Updated Guidance on the Acquisition and Use of Commercial Cloud Computing:

“All CAPs must be approved by DoD CIO.”

The missions described below in Table 3 are listed in DoDI 8010.01 paragraph 4.4 and grouped by mission types and corresponding allowable actions.  These missions do not encompass all missions that may require an authorized DODIN commercial connection nor are they pre-authorized DODIN commercial connections. 

All DODIN commercial connections require DoD CIO approval and are subject to Command Cyber Readiness Inspections (CCRI) and Command Cyber Operational Readiness Inspection (CCORI) in order to ensure conformance with DoD cybersecurity requirements and compliance with DoDI 8510.01, DoDI 8530.01, and other DoD cybersecurity policies and guidance.

The DoD CIO review and approval process of DODIN commercial connections and non-standard cloud services is depicted in Figure 3 and described subsequently below.

A.1.DoD CIO review and approval of requests for DODIN commercial connections and non-standard cloud services

A.1.1. System Owner requests DISA validation of connection request:

Missions listed in Table 3 do not require DISA validation as they are validated for unclassified commercial connections per DoD policy.

DISA reviews request and validates inability of an enterprise capability to meet mission requirements. 

If DISA can provide capability and it meets mission requirements, request is rejected.  If requestor disagrees that DISA can provide capability, decision is elevated to DSAWG/ISRMC for review.

A.1.2. System Owner requests DoD Component Chief Information Security Officer (CISO) acknowledgment and validation of request:

CISO (or deputy CISO if necessary) acknowledges the request complies with the component CIO policy and has an operational requirement.

CISO office conducts initial review of the request and determines if the submission is valid, complete, and technically adequate.  If the CISO non-concurs with the system owner’s request, the CISO returns the package to the system owner with documented concerns.

CISO will provide risk perception of request to DoD CIO.  Requests will only be elevated to DoD CIO for review and approval following CISO review and concurrence.

If the DoD Component does not have a CISO, the DoD CIO will coordinate the request with a representative of the DoD Component’s CIO or senior IT official.

A.1.3. System owner obtains a SNAP account as described in Section 2.8 of this guide, and submits a request for a DODIN commercial connection and cloud service under the “non-DISN Connections” module in SNAP.

SNAP Portal URL: https://snap.dod.mil
SNAP User Guide URL: https://snap.dod.mil/gcap/user-guide.do

The system owner initiates DoD CIO review and approval of request by uploading the DoD CIO request template and required artifacts in SNAP.  The intent of the registration is to capture the following key information, to include information to address conditions as outlined in DoDI 8010.01, section 4.4, E:

A Memo signed by DISA validating request (if request does not support a mission listed in Table 3)

A Memo signed by the DoD Component’s CISO that acknowledges request and validates completeness of package.

Business case for request of Approved Alternate Connection (AAC), to include purpose or mission directive

Type of request: Temporary or Permanent/Enduring Mission Support

The sensitivity of the data being processed, stored, and transmitted

Plan for annual review of need for connection and compliance

Equipment used by the DoD Component on the DoD Approved Products List

Architecture and detailed topology diagram

Physical and/or logical separation (specify any requirement to connect to DISN)

Transition plan to DISN

Cybersecurity Service Provider (CSSP) Narrative

CSSP Alignment (Yes/No)

CONOPS (Incident Response, System Recovery, Vulnerability Management, Configuration Management)

If there is not a CSSP alignment, provide cybersecurity activities/defensive measures in response to vulnerabilities and threats as outlined in DoDI 8530.01

Business case cost analysis

Templates for aforementioned required artifacts can be found on the SNAP portal.

DODIN commercial connections are required to be logically and physically isolated from the DISN. Any exceptions that require configurations with any type of connectivity to DISN to support mission requirements must be implemented via a NIPRNet Federated Gateway (NFG) and must be approved by DoD CIO as illustrated in Figure 4.

This process is completely dependent on universal use of SNAP for processing of requests to include notifications, review, tracking, and approval.  All required artifacts must be uploaded in SNAP portal.

A.2.The DoD Component CISO determines request requires an expedited process due to urgent mission requirements.

If an operational case exists with a need for immediate mission support with temporary requirements (less than 90 days), the request can be expedited.  Expedited requests must be validated with DoD Component GO/FO level approval.

A.2.1. Service CISO coordinates immediate support actions; DoD CIO elevates request

Component CISO acquires GO/FO validation, mission requirements, and coordinates immediate actions necessary to support system owner.  DoD CIO moves request for immediate review and approval (five business days).

A.3.Joint Team Engineering Review and Analysis

The office of the DoD Deputy CIO for Cybersecurity (DCIO CS) will act as the primary point of contact and will collaborate with the joint team consisting of the DSAWG Chair (represents and coordinates with voting members), DISA, JFHQ-DODIN in order to determine whether business case submission is valid, complete and technically adequate.  The joint team produces a report and submits a recommendation to the Principal Deputy (PD) CIO for Cybersecurity for approval or non-approval by the DoD SISO. 

A.3.1   DoD CIO returns request to the system owner with documented concerns. 

If the request is determined not to be valid or complete, DoD CIO returns request package to the system owner with documented concerns.

System owner has the option to address concerns and re-submit or present business case to ISRMC.

A.4.DoD SISO Approval

DoD SISO reviews request package with corresponding recommendations from PD CIO for CS, the joint team, and the Component SISO.

DoD SISO focus points include, but are not limited to:

Level of Sensitivity of Data Protected

Foreign Nationals

Physical and Logical Isolation from DISN

Strong Authentication

Device Hardening

Reduced Attack Surface

Alignment to Cybersecurity Service Provider

United States Cyber Command Responsiveness

A.4.1. DoD SISO Approves request and signs approval memo

DoD CIO decision approval memo sent to system owner, Component CISO, and appropriate stakeholders - status is updated in SNAP accordingly.

The system owner may then acquire the commercial connection in accordance with the approved Business Case Analysis. 

Note that DoD Component orders for connections via DoD-approved Federal contracts (e.g., NETWORX) must come through DITCO as the mandated DoD ordering agency. DoD Components must attain DoD CIO approval for ALL commercial connections procured via DITCO.  Ordering commercial circuits via DITCO does not exempt DoD CIO approval.

If the Component CIO determines that the DoD Component’s alternate solution is more cost/mission effective than the DITCO solution, then the customer may choose their best option for ordering the service. 

For an approved cloud, service request, upon receipt of the approval notification, registers the use of the Cloud service as described in Appendix C of this guide.

For an approved DoD Component Boundary Cloud Access Point (BCAP) or alternate CSO, the DoD CIO will send a copy of the approval notification to DISA Secure Cloud Computing Architecture (SCCA) PMO.  The DISN CAO will add the approved Component BCAP or alternate CSO to SNAP as valid selections.

A.4.2. Post approval actions and monitoring begin

Per DoDI 8010.01,section 4.4 C:

“Authorized commercial connections are subject to CCRIs to ensure conformance with DoD cybersecurity requirements consistent with DoDI 8510.01, DoDI 8530.01, and other DoD cybersecurity policies and guidance.”

DoD CIO memo approvals will be tracked and monitored for expiration and compliance with caveats/directives specified in the memo. 

All DoD Components are required to comply with the standards and conditions set forth in the decision memo.  Deviation or non-compliance at any point during the duration of the approval will be considered means for disconnection. Decision memos must be tracked by the DoD Component and maintained in a current status.  Renewal requests are subject to full compliance of previous decision memos.

A.4.3. ISRMC is informed monthly of DoD SISO approved and returned requests.

A.4.4. DoD SISO returns request

DoD CIO returns the request with comment to the DoD Component System Owner; memo is uploaded to portal and status is updated in portal.

END OF PROCESS.  Process Duration: 30-45 Days

Appendix B Mission Partner Connections to DISN

DoDI 8010.01 paragraph 2.1.g states that the DoD Chief Information Officer (CIO) - “Reviews and approves DoD Component requests for mission partner connections to DISN.”  This Appendix describes the process illustrated in Figure 5 for a DoD Component request to connect a Mission Partner’s enclave or network to the DISN.

Mission Partner Connections (MPC) are DISN connections for DoD Contractors; Federal Partners; or Allied/Coalition Partners.  A DoD Component sponsor is required for DoD Contractors with a valid contract.  A DoD CIO Memorandum of Agreement is required (IAW DoDI 8010.01) for a Federal Department/Agency Mission Partner connections to the DISN.  A Joint Staff validated requirement is required for Allied and Coalition Partners for connection to the DISN.  Federal Partners and Allied/Coalition Partners are connected through a Mission Partner Gateway, described in Appendix H of this guide.

B.1.The DoD Component sponsor submits a formal Mission Partner Connection (MPC) request to the DISN Service Manager.

B.1.1. For a DoD Contractor Connection:

When a DoD Component has a requirement for a DoD contractor connection to DISN, the DoD Component sponsor prepares a Validation Letter for Mission Partner Connections to DISN and a DoD Mission Partner Connection Briefing as described in Appendix M of this guide following the process identified in Figure 5.  An O-6 equivalent or higher DoD Component sponsor must digitally sign the Validation Letter with the attached briefing and email the request to the appropriate DISN Service Manager (i.e., the SIPRNet Service Manager or NIPRNet/Virtual Private Network (VPN) Service Manager).

B.1.2. For a Federal Department or Agency Mission Partner Connection:

In general, the DoD Deputy CIO for Cybersecurity is the sponsor.  A Memorandum of Agreement is entered into between DoD CIO and that Federal Department/Agency CIO IAW DoDI 8010.01.  The MOA establishes the framework of cooperation between DoD and the Federal Partner.  There can be special cases where a specific DoD organization may be the sponsor for a Federal Partner connection.

B.1.3. For an Allied and Coalition Mission Partner Connection:

When a Combatant Commander (COCOM) has a requirement to connect a Coalition partner to the DISN, the DoD Component sponsor prepares a Validation Letter for Mission Partner Connections to DISN and a DoD Mission Partner Connection Briefing as described in Appendix M of this guide.  An O-6 equivalent or higher DoD Component sponsor must digitally sign the Validation Letter with the attached briefing and email the request to the appropriate DISN Service Manager (i.e., the SIPRNet Service Manager or NIPRNet/Virtual Private Network (VPN) Service Manager).

B.2.DISA Service Manager reviews/validates the service request

Either the DISN NIPRNet/VPN Service Manager or the SIPRNet Service Manager validates whether DISN can support the requested service.  In most cases, this is a simple determination of whether the type of connection is appropriate and available.  Some validations may require the DISN Service Manager to propose a different type of connection.  An example of this may be proposing the use of a Demilitarized Zone connection (e.g., SIPRNet Federal DMZ), instead of a direct connection to the SIPRNet.  If the request is validated, the DISN Service Manager digitally signs the formal request, and provides a validation number.  The DISN Service manager then emails the validation or rejection of the request to the DoD Component CISO for review. 

B.3.The DoD Component CISO Reviews the DoD Component request

B.3.1. For a DoD Contractor, Allied, or Coalition Partner Connection:

The Component CISO[14] reviews the DoD Component request for adequacy, and completeness of the cybersecurity requirements. For Allied and Coalition Partner connections Joint Staff J6 CISO Rep performs this function.  If the DoD Component CISO rejects the request, the CISO will provide additional guidance to the submitting organization for revising and resubmitting the request.   If the request meets the cybersecurity requirements, the DoD Component CISO digitally signs the request and forwards the request to DoD CIO.

B.3.2. For a Federal Department or Agency Mission Partner Connection:

DoD CIO OPR works with the Federal Partner to develop a Memorandum of Agreement (MOA) IAW Figure 6.  The MOA is reviewed by both parties, to include a General Council review. The DoD SISO is the sponsor for Federal Department and Agency Mission Partner Connections and they are signed by the DoD CIO and the Federal Department or Agency CIO.

B.4.DoD SISO reviews the DoD Component request

DoD SISO staff reviews the DoD Component request for cybersecurity requirements.  To be approved the DoD Component must execute an agreement with a qualified Cybersecurity Service Provider.

B.4.1. DoD SISO rejects the request for a Mission Partner Connection

If the request does not meet cybersecurity requirements, DoD SISO will send a rejection notification with additional guidance to the DoD Component sponsor organization that originated the request with copies to the DoD Component CISO, DCSA, US Cyber Command, and others for situational awareness.  The DoD Component sponsor may then resubmit the request as described in Section B.1 of this guide.

B.4.2. DoD SISO approves the request for a Mission Partner Connection

If the request meets the cybersecurity requirements, the DoD Senior Information Security Officer (SISO) signs an approval memorandum with caveats.  Approval caveats must be achieved to maintain DoD SISO approval for connection. DoD CIO OPR sends the DoD SISO approval Memorandum to the DoD Component sponsor organization that originated the request with copies to the DoD Component CISO, DISA, DCSA, US Cyber Command, and others for situational awareness.  The DoD SISO approval shall be valid for up to three years and shall be reviewed annually to determine if the sponsor is maintaining the mission partner connection within the risk appetite of the DoD SISO.

For a Federal Department or Agency Mission Partner Connection, DoD CIO and the Federal Partner agree to an MOA, and both parties sign the MOA.  The MOA shall be valid for up to nine years, and shall be reviewed annually. 

Once the DoD Component sponsor receives DoD SISO approval memo (or signed MOA), the DoD Component sponsor can initiate a DISN connection request as described starting at Section 2.4 of this guide.  Note: When registering the connection request in SNAP/SGS as described in Section 2.8 of this guide, the DoD Component sponsor must also upload the DoD SISO approval memo into the SNAP/SGS entry and select the “OSD Approved” option.  

Appendix C Cloud Information Technology Project (C-ITP) Registration and Connection Process

This appendix describes the process used by a DoD Mission Owner to register and connect a Cloud Information Technology Project (C-ITP) to the DISN.  IAW the DoD Cloud Computing Security Requirements Guide (CC SRG), “All Mission Owners are required to register all Cloud based systems/applications, their CSP/CSO, MCD [i.e., Mission Cyberspace Defense (MCD) provider], and connection method in the DISA Systems/Network Approval Process (SNAP) database Cloud Module.” 

Note:  This appendix addresses the registration and connection of a Mission Owner’s Cloud IT Project (C-ITP) to a Cloud Service Offering (CSO) via the DISN[15].  It assumes that the Mission Owner has an existing communications connection to the DISN.  Instructions for obtaining a communications connection to the DISN are provided in Section 2 of this guide.

Figure 7 and Sections C.1 through C.9 describe the process used by a Mission Owner (a Cloud Consumer) to register, connect via the DISN, and onboard a C-ITP to a CSO that has an appropriate DoD Provisional Authorization (DoD PA).  A computer-based presentation of the process for registration and connection of a C-ITP is available on the DISA’s Risk Adjudication and Connection Division’s Mission Partner Training Program (MPTP) website. 

C.1.Mission Owner Initiates a Cloud Information Technology Project

For the purpose of this guide, a DoD C-ITP is a software application or information service implemented (or onboarded) into a DoD  provisionally authorized CSO.

DISA wrote the Best Practices Guide for Department of Defense Cloud Mission Owners who are planning to migrate (or onboard) an existing information system from a physical environment to a virtualized cloud environment. This guide is not DoD policy. Instead, it documents best practices discovered during DoD CIO Cloud implementation efforts. Additionally, the DISA Risk Adjudication and Connection Division’s Mission Partner Training Program (MPTP) provides scheduled live training sessions via Defense Collaborative Service (DCS) and teleconference, 24/7 user-accessible computer based training materials, and education opportunities for cloud onboarding. For additional information about the MPTP contact DISA’s Risk Adjudication and Connection Division’s Mission Partner Training Program (MPTP) or the DISN CAO. Another useful reference is the DoD CIO Enterprise Cloud Community website.

The DoD Component Cloud Migration Offices listed in Appendix L will assist their Mission Owners tasked with initiating a C-ITP and selecting an appropriate CSO.  Mission Owners that do not have a Component Cloud Migration Office listed in Appendix L should contact their DoD Component CIO.  Mission Owners may also contact the DISA Mission Partner Engagement Office for general assistance with DISA Cloud authorization, registration, connection and onboarding processes.  When selecting a CSO, the Mission Owner should also consider the most appropriate Cloud Deployment Model, and the most appropriate Cloud Service Model.  For details, see NIST Special Publication 800-146. 

C.2.Does the selected CSO have an appropriate DoD Provisional Authorization (DoD PA)?

The Mission Owner must determine the Impact Level (IL) of the C-ITP using guidance provided in paragraph 3 of the DoD CC SRG.  After determining the IL of the C-ITP, the Mission Owner must determine if the desired CSO for hosting C-ITP is authorized and registered.  The Mission Owner should review the FedRAMP Marketplace for an approved IL2 CSO and verify if the CSO is registered in the SNAP database.  For IL4, IL5, and IL6 CSOs, a DoD Provisional Authorization is required.  Current and candidate CSOs at IL4, IL5, and IL6 are listed in the DoD Cloud Authorization Services (DCAS) portal and current CSOs are registered in SNAP (IL4 and IL5) or SGS (IL6).  Candidate CSOs will be registered in SNAP or SGS once the DoD PA is issued.  If the CSO is registered in the DISA SNAP or SGS systems, the Mission Owner can proceed to Section C.3 of this Appendix.

If the selected CSO is not listed or is not authorized at the required IL, then the Mission Owner may:

If the desired IL2 CSO is FedRAMP approved but is not registered in SNAP, contact the CAO Cloud Team for assistance.  Download the IL2 Moderate reciprocity memo from the Current CSOs tab on the DCAS portal for use as the CSO authorization.

If the desired IL2 CSO is not FedRAMP approved, contact the DCAS Team.

Proceed to Appendix D and sponsor the CSO for an appropriate DoD PA for IL4, IL5, and IL6 requirements.

Proceed to Appendix A to request DoD CIO approval for an exception to policy

C.3.Mission Owner obtains IP addresses, PPSM ID, Whitelist ID, and aligns with a Cybersecurity Service Provider (CSSP)

The Mission Owner obtains information needed to complete registration and connection of the C-ITP. 

C.3.1. Mission Owner Obtains IP Addresses

If the selected CSO (e.g., milCloud 2.0) is in the DISA SNAP for IL4, IL5 CSOs, or SGS for IL6 CSOs and has the appropriate IL DoD PA, the DoD Mission Owner obtains IP addresses required to use the Provisionally Authorized CSO.

DoDI 8410.01 requires DoD to conduct public and private Internet-based communications (e.g., electronic mail and Web operations) under the “.mil” Top Level Domain.  (Some IL 4 or 5 CSOs are approved to use commercial IP addressing.  A VPN is required to connect with these CSOs[16]).  The Mission Owner is responsible for obtaining required IP addresses for a C-ITP or for a sponsored CSO.  The CC SRG (paragraph 5.10.4) stipulates requirements for IP Addressing and Domain Name Services (DNS) and provides guidance for situations in which DoD Network Information Center (NIC) assigns DoD IP addresses and those situations where the CSP provides commercial IP addresses.  The SCCA Knowledge Center also includes a tab for “Obtaining Cloud IP Space.”

Note that the NIC has allocated IP address space for CSOs to the DoD Component Cloud Migration Offices.  The NIC website identifies DoD Component points of contact (POC) for the assigned IP address.  Access the NIC website as follows:   

a. Log into https://www.nic.mil

b. Select “Whois Search.”

c. Type in:     CLOUD*      

d. Under the column labeled “Network Name,” find the desired CSO aligned with your DoD Component (e.g., “CCSNET-AF-SAAS-ORACLE,” "CCSNET-ARMY-IAAS-AWS_WEST").

e. Double click on the associated “handle” to identify the DoD Component POC to contact for additional direction.

If none of the listed “Network Names” supports your requirement, contact the DoD Component Cloud Migration Office, DISA SCCA PMO, or NIC for guidance to obtain needed IP addresses.

The SCCA Mission Partner Home website contains information Mission Owners may use as a guide when working with their Component and DISA subject matter experts to develop a formal cloud transition plan. ">

The DoD Network Information Center (NIC) Registry Protocol 9802 provides the Mission Owner additional information on assignment and registration of DoD IP address space and IP numbered resources.

C.3.2. Mission Owner obtains a PPSM Tracking Identifier

IAW DoDI 8551.01, Ports, Protocols, and Services Management (PPSM) DISN customers must register their system’s ports and protocols in either the SIPRNet or NIPRNet version of the PPSM Registry as appropriate.  DISN CAO will only approve a connection request that includes a valid PPSM Tracking Identifier.  Customers may collaborate with their DoD Component’s PPSM TAG representative to get ports, protocols, and services (PPS) registered in the PPSM Registry located on SIPRNet or NIPRnet.  A PPSM account is required for access.  Request accounts through your DoD Component PPSM TAG representative. 

For more information on PPSM, please refer to Section 2.7.3 of this guide, the DISA RE4 PPSM home page, the DISA PPSM web page, or contact the DoD PPSM team (DISA RE4). 

C.3.3. Mission Owner Obtains NIPRNet DMZ Whitelist registration ID

A Mission Owner’s C-ITP that requires information to traverse both the NIPRNet and the Internet may need to register this requirement in the NIPRNet DMZ Whitelist located on SIPRNet.  Registration may be required to ensure the DISN Internet Access Points (IAPs) are configured to permit information to flow between the Internet and NIPRNet.  The Mission Owner should consult with their DoD Component’s PPSM TAG representative to determine whether the ports, protocols and services required by the C-ITP must be registered in the NIPRNet DMZ Whitelist.  See “DoD Whitelist” in the CC SRG.

C.3.4. Mission Owner aligns the C-ITP with a Security Operations Center (SOC) supported by a Cybersecurity Service Provider (CSSP)

DoDI 8530.01 and the CC SRG require all DoD Information systems to align with a SOC supported by a CSSP.  The DWCF Rate Book includes billing information for DISA provided CSSP subscription services.  U.S. CYBERCOM maintains a list of DoD certified and accredited CSSPs under the Cybersecurity Service Provider (CSSP) Program.  The Defense Working Capital Fund (DWCF) Rate Book includes billing information for Cybersecurity services provided by the DISA CSSP Office. 

C.4.Mission Owner obtains an Authorization Decision Document (ADD) for the C-ITP to operate within the CSO

“Prior to operational use, all cloud services must have an Authority to Operate granted by the PM/FSM’s Authorizing Official. PMs/FSMs that acquire or use cloud services remain responsible for ensuring that end to end security and computer network defense requirements are met.” DoDI 5000.74">

IAW DoDI 8510.01 and the CC SRG , the Mission Owner must categorize, assess, and authorize the C-ITP to operate within the provisionally authorized CSO.  Section 2.6 of this guide describes this process.  The Mission Owner must obtain an Authorization to Operate (ATO) or Interim Approval to Test (IATT) in order to register and connect the C-ITP to a provisionally authorized CSO via the DISN.  The C-ITP must have an ATO to operate in the cloud before going operational.

C.5.Mission Owner Completes Registration of the C-ITP in DISA SNAP or SGS

DoD uses the DISA SNAP or SGS registration process to initiate, track, and manage C-ITPs connections to CSOs via DISN.  As stated in the CC SRG , a Mission Owner must register an IL2, IL4,or IL5 (unclassified) C-ITP in the DISA SNAP database or an IL6 (secret) C-ITP in the DISA SGS database consistent with DoDI 8010.01, DoDI 5000.74, and CJCSI 6211.02D.[17]  The “Mission Owner (Cloud IT Project)” module in the DISA SNAP database provides workflow status, and a place for the Mission Owner to store required documentation and artifacts. 

C-ITP Naming Convention: • When registering the C-ITP in SNAP or SGS, recommend that the Mission Owner use the same name as the Unique Investment Identifier (UII)/Investment Name used in DITIP, SNaP-IT, DITPR, or SITR and be identified on the Authorization Decision Document for the C-ITP.
• The DoD FY20XX IT-1 Report is a Microsoft Excel spreadsheet listing unclassified UIIs. These reports are hosted on the CAPE web page. IP addresses for the C-ITP SNAP/SGS requires the Mission Owner to enter:
• For an IaaS or PaaS CSO, the Mission Owner enters the IP addresses assigned to the C-ITP by the NIC (see Section C.3 of this guide).
• For a SaaS CSO, the Mission Owner enters the Government enclave IP address ranges the Mission Owner wants DISN to advertise to the SaaS CSO provider.

C.5.1. Mission Owner logs into SNAP or SGS  and enters required information

Section 2.8 of this guide describes the steps for obtaining an account and registering connection information in SNAP or SGS.  When logged into SNAP or SGS, the C-ITP Mission Owner selects the “Mission Owners (Cloud IT Project)”module, enters the required information, and uploads documents as described in Section 2.8.3 of this guide. 

When the Mission Owner has completed all SNAP/SGS information sections and uploaded Security Package documentation, a “SUBMIT” button will appear at the bottom of the screen.  The Mission Owner selects this button to submit the connection request to DISN CAO for review.

C.6.Does DISN CAO approve the connection request submitted in SNAP or SGS?

The DISN CAO reviews the Mission Owner’s request for connection to a provisionally authorized CSO as described in Section 2.9 of this guide and additionally determines whether:

The C-ITP connects to a CSO with an appropriate DoD PA.  (If not, the Mission Owner must upload a DoD CIO approval memo obtained using the process described in Appendix A of this guide)

The C-ITP connects to the CSO via a DoD CIO-approved Cloud Access Point (CAP)

C.6.1. DISN CAO works with the Mission Owner to resolve issues. 

The DISN CAO analyst will not issue a Cloud Permission to Connect (CPTC) for a C-ITP connection request if the Mission Owner’s submission is incomplete, or if there is an issue that the Mission Owner needs to address (see Section 2.9 of this guide for DISN CAO review criteria).  The DISN CAO analyst will identify corrective actions needed for the C-ITP to obtain a CPTC.  SNAP/SGS will notify the Mission Owner POCs identified in the connection request about the needed corrective actions.  The Mission Owner logs into SNAP/SGS, makes the needed updates, and resubmits the connection request to DISN CAO as described in Section C.5 of this guide.

C.6.2. DISN CAO approves the C-ITP connection request and issues a CPTC

C.6.2.1.CPTC for Connections via a DISA Boundary Cloud Access Point (BCAP) or Internal Cloud Access Point (ICAP).  When DISN CAO approves the connection request, SNAP/SGS will issue a CPTC for the C-ITP to the points of contact registered in SNAP or SGS.  The DISN CAO will notify the SCCA PMO when issuing a CPTC for a DISA BCAP or ICAP connection.  The DISA SCCA PMO requires a CPTC for connections to the DISA BCAP or ICAP (serving milCloud 2.0).  (See paragraph 5.10.1 of the CC SRG for the explanation of BCAP, ICAP, and IAP.)

The DISN CAO analyst will also approve a CPTC for a C-ITP that has an Interim Approval To Test (IATT) issued by its AO.  For example, a Mission Owner may need to connect via the DISA BCAP to develop and test interoperability with the Virtual Data Center Security Stack (VDSS).  The CPTC will permit a connection to the DISA BCAP for up to 90-days.  IAW DoDI 8510.01, the IATT issued by the AO will be for testing purposes only and not for operational purposes.  The Mission Owner must obtain an ATO to operate in the cloud before the 90-day CPTC expires.  Otherwise, the DISN CAO will collaborate with the DISA SCCA PMO and the Mission Owner to determine if DISN CAO should allow the CPTC to expire or extend it for an additional 90 days.  If allowed to expire, DISN CAO will notify the Mission Owner and the DISA SCCA PMO will discontinue the C-ITP’s connection to the DISA BCAP.  The DISN CAO will issue a 90-day CPTC for testing purposes if the AO has issued an IATT for the C-ITP.  Proceed to Section C.7.

C.6.2.2. CPTC for Connections to Impact Level 2 CSOs or milCloud 1.0.  The CPTC issued by SNAP/SGS simply acknowledges successful registration of the IL2 C-ITP.  Proceed to Section C.8.

C.6.2.3 CPTC for Connections via a DoD Component (non-DISA) BCAP or ICAP.  A CPTC issued by SNAP/SGS simply acknowledges that the C-ITP has successfully registered in SNAP/SGS.  The CPTC issued by SNAP/SGS does not authorize the C-ITP to connect via a DoD Component BCAP or ICAP.  The owning DoD Component decides whether to permit a
C-ITP to connect via that DoD Component’s BCAP or ICAP.  Proceed to Section C.8.

C.7.Mission Owner submits an SCCA onboarding service request for connections via a DISA BCAP or ICAP (milCloud 2.0)

This step only applies to Mission Owners requesting a connection via a DISA BCAP or
ICAP (serving milCloud 2.0).  (See paragraph 5.10.1 of the CC SRG for the explanation of BCAP, ICAP, and IAP).

There is no separate cost to connect to the DISA BCAP or ICAP. These costs are included in the DISN rates. The cost of optional SCCA services (VDSS, VDMS) is in the Defense Working Capital Fund (DWCF) Rate Book (See CS-ES-10).

Once DISN CAO issues the Cloud Permission to Connect (CPTC) the DISA SCCA PMO works to engineer the connection of an IL4 or IL5 C-ITP to a DISA BCAP or ICAP (serving milCloud 2.0).  To start the process, the Mission Owner uses their browser to access the Secure Cloud Computing Architecture (SCCA) Onboarding web page and completes the SCCA Onboarding service request form.  The SCCA PMO uses this information to manage and implement applicable services for the DISA BCAP or ICAP (milCloud 2.0), Virtual Datacenter Security Stack (VDSS), and Virtual Datacenter Management Services (VDMS).  See the SCCA Knowledge Center for details about the DISA BCAP, ICAP and SCCA onboarding.

C.7.1. DISA Conducts Periodic Deep Dive Meetings for connections via the DISA BCAP

DISA SCCA PMO may host a series of deep dive technical and/or policy centric meetings with the Mission Owner and other stakeholders to exchange detailed information that supports the registration and connection via a DISA BCAP or ICAP.  See the DISA SCCA PMO website for additional information about deep dive meetings.

C.8.Connect a C-ITP to a Provisionally Authorized CSO via an appropriate CAP

Once the Mission owner has registered the C-ITP in the SNAP or SGS databases, and the DISN CAO has issued the a CPTC, the next steps to activate the connection will depend upon the IL of the C-ITP and the CAP (BCAP, ICAP, IAP) the Mission Owner will use to connect to the CSO as illustrated in Figure 8.

C.8.1. An Impact Level 2 C-ITP connection to an off-premises Impact Level 2 CSO via an Internet Access Point (IAP)

DoD CIO Memo - Treatment of Personally Identifiable Information within Impact Level 2 Commercial Cloud Services for the Department of Defense” establishes Cloud Security IL2 as the minimum cybersecurity requirement for DoD applications/systems containing low confidentiality impact level Personally Identifiable Information (PII), as determined IAW NIST SP 800-122. determined in accordance containing low confidentiality impact level Personally Identifiable Information (PII), as determined in accordance with Reference (b).

An IL2 C-ITP connects to an off-premises IL2 CSO via a NIPRNet Internet Access Point (IAP).  Once the DISN CAO issues the CPTC, the Mission Owner in coordination with the DoD Component Cloud Migration Office may contact the CSP to commence onboarding of the C-ITP using the provisionally authorized CSO.  The Mission Owner may need to work with their DoD Component PPSM TAG representative to determine if the C-ITP’s IP addresses, ports, protocols and services used to access the CSO must be registered in the NIPRNet DMZ Whitelist to enable connection between the CSO and C-ITP via the NIPRNet IAP.

C.8.2. DISA Connects a C-ITP to a Provisionally Authorized CSO via a DISA BCAP or ICAP

DISA SCCA PMO uses the information submitted by the Mission Owner via the SCCA Onboarding Service Request and gathered in deep dives meetings (see Section C.7 of this guide) to implement the C-ITP connection to the provisionally authorized CSO via a DISA BCAP or ICAP. 

If the C-ITP will be accessed by users connecting via the Internet, then Mission Owners may need to work with their PPSM TAG representative to determine if the C-ITP’s IP addresses, ports, protocols and services need to be registered in the NIPRNet DMZ Whitelist to enable connections to the C-ITP via the NIPRNet IAP. 

C.8.2.1.  Mission Owner Onboarding a C-ITP to DISA milCloud 2.0.  The DISA milCloud 2.0 portal has instructions for onboarding to this cloud service.  The DWCF Rate Book includes subscription rates for milCloud 2.0 services. 

C.8.2.2.  Mission Owner Onboarding a C-ITP to a Commercial off-premises CSO.  The Mission Owner may contact the CSP to commence onboarding of the C-ITP using the selected CSO in coordination with the DoD Component Cloud Migration Office. 

C.8.3. Mission Owner connects a C-ITP to a DoD Component’s on-premises CSO

A C-ITP connects to a DoD Component’s on-premises CSO via an ICAP (see the CC SRG paragraph 5.10.1.2) owned and operated by the hosting DoD Component and not via a DISA CAP.  The Mission Owner then may contact the owning DoD Component to commence connection and onboarding of the C-ITP using the selected CSO in coordination with the Mission Owner’s DoD Component Cloud Migration Office.

C.8.4. Mission Owner Connects a C-ITP to a Provisionally Authorized CSO via a DoD CIO-approved DoD Component (non-DISA) BCAP[18]  

Normally all IL4 and IL5 CSOs connect to the DISN via a DISA BCAP.  However, a CSO may connect to a DoD CIO-approved DoD Component (non-DISA) BCAP.[19]  The Department of the Navy Commercial Cloud Services Office operates a DoD CIO Approved DoD Component BCAP.  DISN CAO will issue a CPTC for the connection to acknowledge that the C-ITP is registered in SNAP or SGS. 

Requirements for a DoD Mission Owner to Connect a C-ITP to DoD Component (non-DISA) BCAP are:

The Mission Owner obtains concurrence from the DoD Component BCAP office

The C-ITP has an ATO issued by the C-ITP AO

The C-ITP is registered in the DISA SNAP or SGS Databases

The CSO has a DoD PA for the appropriate IL.  See Para C.2 if the DoD PA is not available.

C.8.5. A C-ITP connection to an Impact Level 6 (Secret-level) CSO

C-ITPs must connect to an authorized IL4/IL5 CSO via an appropriate DoD CIO-approved CAP listed in SNAP/SGS. Appendix A of this guide outlines the process for a DoD Component to request DoD CIO approval of a DoD Component BCAP.

DoD authorizes an IL6 CSO to accommodate classified national security information.  The classification determination is pursuant to (i) Executive Order 13526, Classified National Security Information (December 29, 2009), or (ii) pursuant to the Atomic Energy Act of 1954, as amended, (Public Law 83-703)16 to be Restricted Data (RD). 

An on-premises or off-premises IL6 CSO currently connects directly to SIPRNet as explained in the CC SRG (see paragraph 5.10.1.3).  The Mission Owner may contact the CSP to commence implementation of the C-ITP using the selected CSO in coordination with its DoD Component Cloud Migration Office.  DISA's milCloud 1.0 offers a SECRET IaaS/PaaS CSO connected to SIPRNet.  The DISA milCloud website has instructions for registration, connection, and onboarding to this cloud service.

C.8.5.1  Onboarding to an IL6 CSO.  The Mission Owner works with the CSP to onboard the C-ITP to the IL6 CSO.  The IL6 CSO’s entry in the DoD Approved Cloud Service Offerings Catalog includes a link to the CSO’s DoD PA.  The DoD PA provides CSP contact information.

A Mission Owner must register an IL6 (secret) DoD Cloud IT Project in the SIPRNet GIAP System (SGS). CSOs and C-ITPs running at classification levels above SECRET are outside the scope of this guide.

(NOTE:  DISA is currently implementing SIPRNet CAPs.  Once operational, on-premises and off-premises IL6 CSOs must utilize them or another DoD CIO-approved DoD Component SIPRNet CAP.)

C.9.The Mission Owner onboards the C-ITP to a Provisionally Authorized CSO

After DISA makes a CSO accessible to users, a Mission Owner may then work with the CSP to complete activities necessary to onboard a C-ITP onto the Provisionally Authorized CSO.  There are several resources available to help Mission Owners plan the transition to a cloud environment.

C.9.1. Onboarding to DISA milCloud 1.0. 

The DISA milCloud 1.0 is an Infrastructure as a Service (IaaS) solution that leverages a combination of mature Commercial off the Shelf (COTS) and Government developed technology to deliver cloud services tailored to needs of the DoD.  It operates within a DISA DECC that is directly accessible via NIPRNet so a DISA BCAP is not involved in the connection.  Once the CPTC is issued, the Mission Owner may work with their Component Cloud Migration Office and the DISA milCloud 1.0 office to connect and onboard a C-ITP into milCloud 1.0.  Information about connection and onboarding to milCloud 1.0 is available on the DISA milCloud website.  The DWCF Rate Book includes subscription rates for “milCloud” services.

Prior to ordering new or modifying existing milCloud 1.0 services, Mission Partners are encouraged to visit the DISA milCloud 2.0 portal or reach out to the milCloud 2.0 Program Management Office (PMO) to determine their ability to support specific cloud service requirements and implementation timelines. Although customers can still order/modify milCloud 1.0 services, be aware that milCloud 2.0 is the replacement service for milCloud 1.0.

C.9.2. Onboarding guidance for DoD Cloud Mission Owners. 

The following sources provide information helpful for connection and onboarding of a C-ITP to an approved CSO:

Best Practices Guide for Department of Defense Cloud Mission Owners planning to migrate an existing information system from a physical environment to a virtualized cloud environment covering assessment and authorization, IP standards, Domain Name Service availability, and cloud email

· DISA milCloud website milCloud is an Infrastructure as a Service (IaaS) solution that leverages a combination of mature Commercial off the Shelf (COTS) and government developed technology to deliver cloud services tailored to needs of the DoD.

DISA milCloud 2.0 portal: milCloud® 2.0 connects commercial cloud service offerings to Department of Defense (DoD) networks, in a private deployment model to provide DISA mission partners the latest cloud technology at competitive prices without compromising security or performance.

· DISA Mission Partner Engagement Office Website provides access to Reports, available DISA services, service requests, technical support, billing POCs, DWCF Rate Book, and Frequently Asked Questions, and MPEO points of contact for additional information and assistance.

· DISA SCCA PMO website descriptions of CAP, VDSS, VDMS, list of on-premises and off-premises CSOs connected to DISA CAP and SCCA offerings.

· DoD Cloud Acquisition Guidebook (DoD Acquisition University) is a comprehensive online resource with chapters designed to provide specific and tailored information for PMs, Contracting personnel, Engineers/IT Technical personnel, Financial Managers, Attorneys, and Cybersecurity personnel.

· DoD CIO Memo, DoD Cybersecurity Activities Performed for Cloud Service Offerings  expands upon DoDI 8530.01 to address the engagement in Defensive Cyber Operations as DoD networks transition data, applications, capabilities and services to DoD and commercial cloud capabilities and services.

· DoD Cloud Computing Security Requirements Guide (CC SRG)  outlines the security model by which DoD will leverage cloud computing along with the security controls and requirements necessary for using cloud-based solutions

DoD Cloud Computing Security Website the online library of DoD Cloud Computing Security documents and web links.

· DoD Cloud Cyberspace Protection Guide defines a set of reporting and incident handling procedures for the organizations that will protect the DODIN in the cloud as specified in the DoD CC SRG section on cyberspace protection and incident response.

DoD Cloud Strategy  Deputy Secretary of Defense issuance that identifies strategic objectives to address DoD mission requirements through a multi-cloud, multi-vendor strategy that incorporated General Purpose cloud and Fit For Purpose cloud capabilities. 

C.10. Cloud Connection Sustainment and Maintenance

Figure 9 illustrates the requirements for sustaining and maintaining a C-ITP or CSO connection to the DISN via the DISA BCAP and includes: 

C.10.1. Meet all contract requirements. 

A DoD Mission Owner C-ITP using a CSO and the Cloud Service Provider of the CSO must continue to meet all obligations within their contract including those specified in the 80 FR 51739, Defense Federal Acquisition Regulation Supplement: Network Penetration Reporting and Contracting for Cloud Services (DFARS Case 2013-D018).

C.10.2. Comply with requirements in the CC SRG, ADD, or DoD PA.

Mission Owners and CSPs and must continuously monitor their system’s compliance with conditions specified in the CC SRG and the associated DoD PA or ATO.  This includes submitting timely renewal request prior to the expiration date specified in the C-ITP’s ATO and the CSO’s DoD PA, conducting Continuous Monitoring, Cyberspace Defense and Incident response, and Change Control following procedures in the CC SRG paragraph 5.3.

C.10.3. Comply with USCYBERCOM and JFHQ DODIN operational orders (OPORDS). 

In the case that a USCYBERCOM or JFHQ DODIN operational order affects a CSO or C-ITP, the Cybersecurity Services Provider and Contract Officer are responsible for providing the unclassified portion of the OPORD to the CSP and ensuring compliance.  CSPs and DoD Mission Owners must ensure their systems comply with applicable operational orders

C.10.4. Maintain Accurate Information in SNAP or SGS and other repositories. 

Mission Owners update C-ITP information in SNAP and SGS particularly personnel contact information that is vital to timely notification.  DISN CAO assisted by CSPs will ensure that CSO records in SNAP/SGS are kept current. 

Section 2.12 through Section 2.15 of this guide describe the processes for renewing an approval to connect to DISN and for handling temporary disconnections from DISN.  DISA will notify registered Mission Owners and CSPs having dependencies in the event there are issues concerning a CSO’s DoD PA such as issuance of a FedRAMP Corrective Action Plan. 

C.11. Permanent discontinuation of a C-ITP connection from DISN

During the sustainment and maintenance process, the JFHQ DODIN may order DISA to disconnect temporarily a C-ITP or CSO from DISN due to non-compliance. Reasons may include: • The ATO or CPTC for a C-ITP may expire • The FedRAMP PA, DoD PA, or CATC for a CSO may be placed in remediation status, be revoked, or may expire JFHQ DODIN will order DISA to reconnect a C-ITP or CSO after the non-compliance issue is resolved. (See Section 2.15 of this guide for details.)

Sections 2.5 and 2.16 of this guide describe the process for permanently discontinuing a C-ITP connection to the DISN.

The life cycle of the C-ITP connection ends here.

Appendix D Cloud Service Offering (CSO) Authorization, Registration, and Connection

D.1.CSO Authorization, Registration, and Connection Overview

This Section describes processes illustrated in Figure 10 for authorization, registration, and connection of a Cloud Service Provider (CSP) - Cloud Service Offering (CSO) to the DISN, in compliance with DoD policies and standards.

D.1.1. Cloud Service Offering (CSO) Authorization Process  

The DoD Cloud Authorization Services (DCAS) Team provides support to DoD component sponsors through the pre-screening, assessment, coordination with Third Party Assessor Organizations (3PAOs), validation, and Provisional Authorization (PA) process outlined on the DCAS portal for IL4, IL5, and IL6 CSO requirements.

D.1.2. DISA announces DoD PA and updates pertinent repositories with CSO Information 

Once the DISA AO issues the DoD PA, the DCAS Team will work with the DISA Public Affairs Office to issue a public announcement that an IL4 or above CSO has received a DoD PA.  In addition, the CSO will be added to the “Current DoD CSOs” on DCAS.  The DCAS Team will provide information needed by the DISN CAO to register the CSO and any dependencies in DISA SNAP/SGS.  The CSO will then be available in SNAP/SGS for selection by DoD Mission Owners as described starting in
Section C.3 of this guide.  The DISN CAO will upload the following documents into the DISA SNAP or SGS system CSO module:

DoD Provisional Authorization

DoD RMF Authorization Decision Document (ADD) – An ADD is only required for an on-premises CSO IAW the CC SRG (paragraph 4.5)

The DISN CAO will continue to work with the DCAS Team, the CSP and the DoD Component sponsor to update the CSO entry in SNAP or SGS annually or as required. 

D.1.3. CSO Registration

DISN CAO issues a Cloud Approval to Connect (CATC) and registers the CSO in SNAP (IL2-IL5) or SGS (IL6).  The DISN CAO will notify both the DoD Component sponsor and the SCCA PMO when issuing a CATC for a CSO connection to the DISA BCAP or ICAP.

Once a CSO has obtained the requested DoD PA, the DoD Component sponsor may begin the process of registering and connecting a Cloud Information Technology Project (C-ITP)  to the newly Provisionally Authorized CSO as described starting in Section C.3 of this guide. 

D.1.4. CSO Connection

Once registered in the SNAP or SGS, the next steps to implement the CSO connection will depend upon the IL of the CSO and which CAP the CSO will use.  The implementation of the CSO connection to the DISN via an appropriate cloud access point is similar to the manner in which C-ITPs connect to the CSO as described in Section C.8 and illustrated in Figure 8 of this guide. 

DoDI 8010.01 and CJCSI 6211.02D require a DoD Component to sponsor a CSO's connection to the DISN. Consequently, DISA SCCA PMO will only activate the CSO BCAP connection when a DoD Mission Owner receives a CPTC to connect a Cloud IT Project (C-ITP) to the CSO as described starting in Section C.1 of this guide.">

A. Connection via a DISA BCAP or ICAP.  If an off-premises CSO is connecting via the DISA BCAP and is not collocated with a DISA BCAP Meet-Me-Point, then the CSP must obtain, fund, and sustain a connection between CSP enclave hosting the CSO and the DISA BCAP Meet-Me Point.  Figure 11 illustrates the process DISA uses to activate a CSO connection via a DISA BCAP or ICAP. 

B. Connection via a DoD Component CAP (non-DISA CAP).  When connecting an off-premises CSO via a DoD Component BCAP or connecting an on-premises CSO via a DoD Component ICAP, the DoD Sponsor works with the responsible DoD Component to engineer and implement the CSO connection IAW the CC SRG (see paragraph 5.10.1.3).   

C. Connection to an Impact Level 6 (Secret-level) CSO.  At this time, an IL6 CSO connects directly to SIPRNet and not through a DISA BCAP.  However, once DISA’s SIPRNet CAPs are operational, on-premises and off-premises IL6 CSOs must utilize them or another DoD CIO-approved DoD Component SIPRNet CAP.  Once the DISN CAO registers the IL6 CSO in SGS, the DoD Component Sponsor requests the CSO connection to SIPRNet following the procedures in Section 2 of this guide. 

The CSO connection now enters the sustainment and maintenance described in Section C.10 until end of life as described in Sections 2.5, 2.16, and D.2.

D.2.Permanent discontinuation of a CSO connection from DISN

Sections 2.5 and 2.16 of this guide describe the process for permanently discontinuing a connection to the DISN.  However, since permanent discontinuation of a CSO from DISN can affect any Mission Owner using that CSO, the discontinuation process for a CSO involves the following additional actions as illustrated in Figure 12:

D.2.1. DISA Notifies Stakeholders about CSO Service Discontinuation. 

DISA Command Center will issue a DISA TASKORD and DISA Global will permanently discontinue the connection to the CSO.  The DCAS Team and CAO Cloud Team will apprise Mission Owners or CSPs with dependencies on the discontinued CSO so they can take appropriate action (e.g., Mission Owners off-boarding their C-ITP and data).

D.2.2. DISA Closes CSO registrations and Discontinues the CSO Connection 

DISA Global executes the DISA TASKORD by permanently discontinuing the CSO’s DISN connection and revising the NIPRNet DMZ Whitelist as needed.  The DCAS Team marks the entry in DoD Approved Cloud Service Offerings Catalog as "Closed" and notifies the DISN CAO that the CSO is discontinued.  DISN CAO marks the CSO’s SNAP/SGS entry as “Closed” and uploads the DCAS discontinuation notification to SNAP/SGS.  Closing the SNAP/SGS entry removes the CSO from the list of available CSOs on SNAP/SGS and deletes any Whitelist entries in the DISA IAPs.  Mission Owners will no longer be able to select the CSO for a new C-ITP connection.

Appendix E Diagram Requirements

E.1.Topology Diagram/System Design Document

The network topology diagram depicts the physical or logical configuration and security posture of the various elements (links, nodes, etc.) a computer enclave or network connection to DISN.  The topology diagram illustrates the “System Enterprise and Information Security Architecture” cited in the DoD RMF Security Plan.

Figure 13 through Figure 16 in this appendix depict the network configuration and security posture of various types of DoD Component enclave or network connections to DISN. 

As shown in Figure 13 Topology diagrams must:

• Be dated
• Clearly delineate authorization boundaries
• Identify the CCSDs of all connections to the DISN
• Identify equipment inventory (equipment make, model, most recent configuration including any enclave boundary firewalls, Intrusion Detection System (IDS)/Intrusion Protection System (IPS), premise router, routers, switches, backside connections, IP addresses (obtain IP address space from the NIC), encryption devices, CDS, software versions, and IP address ranges of the devices on the diagram; (DISN CAO confirms that equipment and OS version are on the Approved Products List Tracking System or National Information Assurance Partner (NIAP) Evaluated Products)
• Show other NIPRNet or SIPRNet connections (access points); the flow of information to, from, and through all connections, host IP addresses, and CCSD number must be shown
• Identify all cybersecurity or cybersecurity-enabled products deployed in the enclave
• Identify any connections to other systems/networks/enclaves to include:
  • The connection type (e.g., wireless, dedicated point-to-point connection, etc.)
  • IP addresses for all devices within the other enclave (IP addresses may be obtained from the NIC)
  • The organization type (e.g., DoD, federal agency, contractor, etc.)
• Identify the Internetworking Operating System (OS) version
• Show actual and planned interfaces to internal and external Local Area Networks (LANs) or Wide Area Networks (including backside connections)
• Note on the topology if the enclave is protected by a gateway (e.g., Navy Marine Corps Internet or Air Force Block 30)
• Appropriately classify the topology diagram for SIPRNet enclaves, or cloud services using DISA Circular 300-115-3 DISN SIPRNet Security Classification Guide.

The DoD Network Information Center (NIC) Registry Protocol 9802 provides additional information on assignment and registration of DoD IP address space and IP numbered resources. *** DISA Authorizing Official approval is required to use Private IP addresses (non-routable) space (RFC 1918) on SIPRNet. All RFC 1918 requests must be submitted to the DSAWG Secretariat for DISA AO approval. ***

E.2.Customer Network Enclaves Connection via JRSS

The topology diagram for customer network enclaves that connect via the JRSS must include a JRSS topology overlay as shown in the Figure 14.  The JRSS topology overlay also must identify the make/model/IP address/software version of the JRSS equipment in use.

E.3. TDM/IP DSN topologies

All TDM/IP DSN topologies illustrated in Figure 15 and Figure 16 must include:

• Topology date
• Function, vendor, model, and software version of the voice switch (preferably near the voice switch)
• All Customer Edge router or Terminating type equipment used behind the voice switch (Analog, Digital, VoIP, Video Teleconference, NE, etc...)
• The function and location of the DSN source switch providing connection to the DSN backbone (preferably near the DSN cloud)
• Trunk type used for DSN connection (i.e., T1/E1 PRI, T1/E1 Channel Associated Signaling (CAS), Integrated Services Digital Network, etc.)

Addenda for a voice switch connection to an Assured Services Local Area Networks (ASLAN):

• Depict vendor, model and IP address of all Media Gateway (MG) routers used for Ethernet/IP connection
• Depict NIPRNet CCSD(s) providing the Ethernet/IP connection within the enclave (preferably near the ASLAN cloud or Customer Edge Router

Addendum for voice softswitch or session controller connections to the DISN:

• Depict the function and location of the source softswitch or session controller providing connection to the DISN backbone (preferably near the DISN cloud)
• Depict function, vendor, model, software version and IP address of all Session Border Controllers
• Depict NIPRNet CCSD(s) providing the Ethernet/IP connection within the enclave (preferably near the customer edge router)
• Select connection type “backbone” if DISA manages the softswitch or session controller and provides UC services for multiple DoD and Mission Partners.

All Cybersecurity and cybersecurity-enabled products must comply with the evaluation and validation requirements of DoDI 8500.01 and DoDI 8100.04. “DoD Components are required to acquire or operate only UC products listed on the UC APL” IAW DoDI 8100.04, Unified Capabilities. Cloud services are considered UC if they traverse DoDIN. It is important to note that IAW DoD and DISA guidance, firewalls, Intrusion Detection Systems (IDSs), and Wireless-IDSs (where applicable) are required on all partner enclaves. Indicate and label all of the devices, features, or information. The minimum diagram size is 8.5" x 11.

Appendix F Registering Tactical, DSN, and UC Service Requirements

F.1. Supplemental Guidance for Tactical Exercise or Tactical Mission TELEPORT Connection Registration

The customer will submit a connection request using the SIPRNET GIAP module in the SGS system.  The customer completes section 0 of the GIAP record to identify points of contact for the connection and posts a modified connection security package that includes:

• ATO/ADD
• Topology

The customer will then submit the package to the CAO.

The DISN CAO will review the registration information and will issue an ATC for the duration of the ATO upon successful and complete registration.  The ATC will show the Registration ID number for the record.  DISN CAO will post the ATC under section 10.1 of the SGS system, and email the ATC to the POCs in section 0.

For an ATC that expires within the next 30, 60, or 90 days SGS automatically sends email reminders to the registered points of contact reminding them to initiate actions required to renew the ATC.

F.2. Supplemental Guidance for Defense Switched Network (DSN) and UC Connection Registration

Connection of a DSN telecommunication switch or Unified Capabilities (UC) product to the DISN requires procurement of interfacing hardware and/or software elements identified on the DoD UC Approved Products List (UC APL).  DoD UC is “the integration of voice, video, and/or data services delivered ubiquitously across a secure and highly available network infrastructure, independent of technology, to provide increased mission effectiveness to the warfighter and business communities.  DISA’s Joint Interoperability Test Center (JITC) or other authorized Component test center ensures  certifies products on the UC APL for interoperability and tests products for Cybersecurity IAW DoDI 8100.04, Unified Capabilities.  UC products from the UC APL include circuit switched, and IP-based devices that have undergone interoperability and Cybersecurity  assessment.  Addition to the APL  involves end device-to-end device security, authentication, and non-repudiation to support mission assurance objectives.  The customer uses the UC Reference Architecture in conjunction with all relevant DoD security requirements and DoD Security Technical Implementation Guides (STIGs) and Security Requirements Guides (SRGs).  Operational deployment of the UC APL product must be compliant with all Conditions of Fielding and risk mitigations identified in the Cybersecurity recommendation and the APL approval memorandum.

F.2.1. Before purchasing a product not on the UC APL, the customer must:

Work with the JITC to have the product tested and certified for Interoperability and cybersecurity, and placed on the UC APL. 

Alternatively, obtain a DoD CIO review and approval IAW DoDI 8100.04, Unified Capabilities.

F.2.2. The following additional guidance applies:

Voice soft switches or session controllers connected to the DISN shall be registered in SNAP using the DSN module and obtain connection approval as described in
Section 2 of this guide.

IAW DoDI 8010.01 and CJCSI 6211.02D, the user must “register all connections to the DISN” to include all TDM/DSN[20] voice switches and TDM-based video service connected to the DSN as a servicing voice switch using the DSN module as described in Section 2 of this guide.

The user will register all TDM/DSN voice switches (e.g., PBX1, NE-SHOUTS, Switch Multiplex Unit, and Inverse Multiplexer (IMUX)) that connect via a tandem/nodal connection to the Multifunction Switch (MFS) in SNAP using the DSN module.  The user will also obtain a DoD CIO review and approval IAW DoDI 8010.01 and
Appendix A of this guide or have a completed Tailored ISP for connection approval.

New/additional TDM trunk connections to an operational legacy DSN switch for growth requirements will be allowed, but the legacy switch must be registered in SNAP using the DSN module and obtain connection approval, as described in Section 2 of this guide if they have not previously obtained formal connection approval.

If a legacy switch is on the UC APL End of Sale list, or has fallen off the UC End of Sale list, then the Customer must register the voice switch in SNAP using the DSN module.  The customer request must be approved by DoD CIO IAW DoDI 8100.04 in order to obtain a connection approval as described in Section 2 of this guide.

TDM/DSN voice switches or VoIP capable soft switches [e.g., PBX1[21], PBX2, Network Element (NE) SHOUTS, Remote Switching Unit (RSU), Switch Multiplex Unit, Inverse Multiplexer (IMUX)), IP-based video service connected behind the local user’s installation DSN End Office (EO)/Small End Office (SMEO)] must be connected IAW the connection approval process stipulated by the hosting DoD Component.  These connections do not require a SNAP registration or DISA connection approval unless directed as a MAJCOM, Combatant Command, or Theater Command requirement.  Instead, the user must register the hosting installation’s connection to DISN in SNAP using the DSN module and these types of switches and depict them in the topology diagram of the host installation.

For information on UC APL, products and the process for getting equipment added to the UC APL refer to the UC APL website and the DISA UC Approved Products Certification Office.

Appendix G DoD Cross Domain Solution Approval Process

IAW DoDI 8540.01, paragraph 3.g, it is DoD Policy that “the DoD-level risk decision on use of a CDS to access or transfer information between different interconnected security domains must be made by the designated DoD risk executive as a CDS authorization (CDSA) ….” IAW DoDI 8540.01, Enclosure 2, paragraph 8.u.(1) DoD Component Heads shall: ”Require the issuance of a DoD ISMRC [sic] or DSAWG CDSA before allowing a CDS to access or transfer information between different interconnected security domains. A CDSA is required for use of a CDS.”

A Cross Domain Solution (CDS) is a form of controlled interface that provides the ability to manually and/or automatically access and/or transfer information between different security domains.  This appendix provides the steps necessary to obtain a Cross Domain Solution Authorization (CDSA).  A CDSA is the official document authorizing operational use of a CDS.  A CDSA will not be issued for dates beyond the Approval to Connect (ATC) expiration date for the enclave in which it resides.

A customer desiring to implement a CDS must first contact their respective Cross Domain Support Element (CDSE) to discuss the requirement, receive guidance on the CDS process, and receive their recommended way forward.  If you do not know your CDSE point of contact information, you may contact DSAWG Secretariat (CDTAB Support) to receive that contact information.

G.1.DoD CDS Approval Process Scope, Applicability and Exclusions

DISA’s Risk Adjudication and Connection Division’s Mission Partner Training Program (MPTP) provides an overview of DSAWG and CDS processes.

The DoD CDS approval process covers CDS connections to networks classified Top Secret and below, including standalone, isolated, and test networks.  This includes IC-owned CDSs that connect to DoD networks.  CDS devices with connection to networks classified Top Secret– Sensitive Compartmented Information (SCI) and above follow different approval processes as determined by Director of National Intelligence (DNI) policy and guidance.  If an Intelligence Community (IC) approved CDS connects to SIPRNet, an IC Registration needs to be created in the SGS system (see Section G.8 of this guide).  Programs with strict OPSEC requirements needing to utilize a CDS will also go through the CDS approval process.  The process will be adapted to ensure the need to know requirements are met IAW paragraph 7.2.5 in the DSAWG Charter.

G.2.Categories of Cross Domain Solutions

The two main categories of Cross Domain Solutions (CDS) are enterprise CDS and Point-to-Point CDS.  Within these broad categories are an Access CDS, Transfer CDS, or Multi-level CDS types.  An Enterprise CDS is a CDS approved for use by an enterprise cross-domain service provider.  A Point-to-Point CDS is a CDS purchased, implemented, and managed within the authorization boundary of the organization’s own network.  A Point-to-Point CDS is unable to use an ECDSP.  Details of each type of CDS are described below.

G.2.1. Enterprise Cross Domain Solution (Enterprise CDS)

An Enterprise Cross Domain Service (ECDS)provides automated capabilities available to end users and hosted mission applications within an enterprise environment for information sharing across-and-among security domains utilizing one or more CDSs. There are two classes of enterprise CD services:

• General Purpose (GP) enterprise cross domain service is available to all authorized users of connected networks and supports a broad range of data types;
• Mission Specific (MS) enterprise cross domain service is available to a select community [e.g. signals intelligence (SIGINT), geospatial intelligence (GEOINT), Maritime] with a limited set of data types and domains.

An enterprise-CD-service may qualify as one or both types of cross domain service.

a.         Enterprise CDS Candidate: This term refers to an organization with CDS requirements in negotiation with an Enterprise Cross Domain Service Provider (ECDSP) which will be brought through the CDS Phase 1 just as a point-to-point CDS.  Once the DSAWG approves the Phase 1 requirement, the DSAWG Secretariat (CDTAB Support) will document the DSAWG approval of the requirement for ECDSP implementation in SGS and then close the original CDS Request in SGS.  The requirement will be implemented on an Enterprise CDS under an Enterprise CDS Ticket number.

Per DoDI 8540.01, “DoD will employ existing enterprise CD service provider’s (ECDSP’s) enterprise CD service or enterprise-hosted CDS when their use satisfies the CD mission requirements of DoD Components. Leveraging another operational CDS, deployment of a CDS baseline list point-to-point CDS or development of a new CD technology will be considered as alternative solutions only when an enterprise solution cannot meet the CD capability requirements.”

b.         Enterprise CDS Ticket or Request.  An enterprise CDS Ticket or Request is a CDS sponsored by an ECDSP that supports multiple organizations.

G.2.2. Point-to-Point Cross Domain Solution (CDS):

A Cross Domain Solution purchased, implemented, and managed within the authorization boundary of the organization’s own network.  Point-to-Point CDS are CDS that are owned and operated by an organization that cannot use an ECDSP.  A particular P2P CDS may be categorized as an Access CDS, Minimal (Community) Impact CDS, Tactical CDS or a P2P CDS that requires an exemption. 

a. Minimal (Community) Impact CDSs (formerly referred to as “For Tracking Purposes Only (FTPO)”) presents a minimal community risk in terms of DoD information security.  A Minimal (Community) Impact CDS must be registered in SGS, the “designated repository,” in IAW DoDI 8540.01 enclosure 3, paragraph 4.a.  If the CDS meets the Minimal Community Impact Criteria – they do not need to complete the P2P Approval Process (or associated documentation).  The CDTAB determines whether a CDS fits one of the following four cases of Minimal (Community) Impact CDSs:

i. Completely Isolated: The networks connected to the CDS are completely isolated.

ii. A Controlled Interface of Interest is a CDS connected to two networks of the same security classification that have different Administrative Domains.  In such cases, the controlled interface at each network boundary satisfies both parties’ security requirements.

iii. Very Low Risk (VLoR): A VLoR CDS meets VLoR assertions in the VLoR Process Implementation Guide (see paragraph 5).  A VLoR CDS is a transfer CDS architecture/system in which the low side system(s) provide minimal threat to the high side network, and its connected enclaves present minimal risk to the High side enclave(s).  VLoR review process is designed to assess the risk for systems such as Global Positioning Satellites (GPS), Network Time Protocol (NTP) and sensors isolated from general network traffic.

The DoD CIO and USD(A&S) Memorandum, Suspension of new Point-to-Point Cross Domain Solutions issued October 10, 2018 directs use of enterprise cross domain services to the max extent possible and immediately suspends acquisition, procurement, or implementation of new Point-to-Point CDS implementations. The exemption process is outlined in the memo. The P2P CDS Exemption process is illustrated in Figure 19 and detailed in Section G.3.4.c of this guide

iv. Cyber Situational Awareness (SA) Taps: Cyber Situational Awareness Taps are one-way CDS devices that forward network traffic into a closed collection enclave for analysis.  In such cases, the CDSE and DSAWG Secretariat (CDTAB Support) will review the test evidence verifying the one-way-ness of the proposed CDS device and the network architecture and protections of the collection enclave to ensure isolation.

b. Tactical CDS.  A Tactical CDS deployment operates in austere environmental conditions, or, where terrestrial communications are not possible, reliable, or survivable.  Austere environmental conditions include combat and related land, sea, or air vehicles.  If the CDSE’ determines the CDS is tactical, it will not require submission to an ECDSP for review or require a P2P CDS Exemption memorandum as illustrated in Figure 18.  The P2P CDS must meet all of the Tactical Criteria defined in the NCDSMO document available on the P2P CDS supporting documentation web page - select “ECDS P2P Tactical Criteria 20190603 V1.0.”.  Otherwise, the P2P CDS also will require a Plan of Action and Milestones (POA&M) signed by the Program/Project Manager or the individual responsible for maintaining and monitoring overall execution of the POA&M.

c. Other types of Point-to-Point CDS

A P2P CDS that is not an Access/Tactical/MCI CDS must follow the P2P CDS Exemption Process IAW DoD CIO and USD (A&S) Memorandum, Suspension of New P2P CDSs that states that DoD Components must use enterprise CDS services to the maximum extent possible and immediately suspend acquisition, procurement, or implementation of new P2P CDS implementations.  The memo outlines an exemption process clarified in an NCDSMO document available on the P2P CDS supporting documentation web page - select “DoD P2P CDS Memo Impl Guidance 20190603 V1.0.”  Procedures for requesting a P2P CDS exemption review and approval are illustrated in Figure 19 and described in Section G.3.4.c of this guide.

G.2.3. IC Owned Cross Domain Solution. 

An IC Owned CDS is a CDS that an intelligence agency owns, approves, and manages.  Only IC CDSs connected to DoD networks are referenced in this connection process guide for visibility and reciprocity purposes.  (See Section G.8 of this guide for registration procedures.)

G.3.Cross Domain Solution (CDS) Authorization Process

This Section includes the CDS authorization process for all categories except the IC CDS Registration process that is described in Section G.8 of this guide.

Figure 17 cross-references the RMF process steps to the various CDS phases and provides detail for each of the phases. The four phases are:

Phase 1: CDS Categorization and Criticality Determination

Phase 2: CDS Engineering, Security Control Selection and Security Control Implementation

Phase 3: CDS Security Control Assessment & Authorization

Phase 4: Operational CDS Monitoring

Figure 18 illustrates the CDS Connection Process.  In each phase, the DSAWG makes recommendations to the ISRMC regarding CDS requests or makes decisions on CDS requests IAW authorities delegated to the DSAWG by the ISRMC (see Section G.9.1 of this guide).

G.3.1. Phase 1: CDS Categorization and Criticality Determination

Phase 1 of the CDS process is illustrated in Figure 18.  Any exceptions to the CDS process must be coordinated with the DoD Component’s CDSE and the DSAWG Secretariat (CDTAB Support). It will also likely require approval of the CDTAB/DSAWG/DoD ISRMC boards. 

G.3.1.1. The CDS organization must coordinate with their respective CDSE representatives to determine and document the information transfer and mission requirements. This is to support the CDSE’s CDS Categorization and enable him to identify the respective processes and artifacts needed to proceed.  

Please review DoDI 8540.01 Enclosure 5 CD and RMF Roles, paragraph 4, if you would like to review the roles of a CDSE. If you do not know your CDSE POC, the DSAWG Secretariat (CDTAB Support) can assist in providing that information.

Per DoDI 8540.01 Enclosure 5, paragraph 4.g. CDSE provides CD support to Combatant Commands and other organizations IAW DoDD 5100.03, Support of the Headquarters of Combatant and Subordinate Joint Commands.

G.3.1.2. The CDSE logs into the SGS system and opens a new CDS request filling out all applicable database fields, and uploads all of the following Phase 1 required documents:

a) Validation Memorandum, signed by an O-6 or civilian equivalent that has authority to release funds.

b) Cross Domain Appendix (CDA) with section 1.0 completed and with the Designated Command Representative signature required in phase 1 – the CDA template is available on the NIPRNet CDTAB website under the "Shared Documents" tab and the "new_cds-customer-docs" folder.

c) P2P Exemption Memorandum – (Not required for Access, ECDSP Sponsored Systems, or Minimal Community Impact, Access )

i. Required if an ECDSP states they can support and customer does not intend to migrate if NCDSMO determines that an Exemption Memorandum is required or if ECDSP states they cannot support the requirement but the customer also does not meet the P2P criteria (See Figure 19).

d) POA&M  - If a CDS Does not meet the Tactical, P2P or ECDSP criteria (respectively as applicable to the CDS categorization of the request) as defined in Criteria for Determination of Enterprise Cross Domain Service Provider, Point-to-Point Deployment, and Tactical Deployment Status and POA&M must be provided to meet the relevant criteria based on the CDS categorization.

e) Additional Phase 1 Requirements for a VLoR CDS:

i. CDA section 2.0 Completed (section 2.1 not required)

ii. Site Based Security Assessment (SBSA) Plan [22] (detailed procedures not required)

iii. VLoR Assertions Response Completed

f)Additional Phase 1 requirements for Repeatable Accreditation/Authorization CDS are:

i. Complete the DSAWG Criteria for Repeatable Accreditation of CDS checklist (section 2.0)

ii. Planned Repeatable Inventory Template

Per DoDI 8540.01, Enclosure 3, paragraph 4.b.(4) "The DoD Component CDS owner must establish a tracking process approved by the CDSE and must track [repeatable] instantiations to include CDS number; unique CDS identifiers, such as hardware serial number or asset tag; location; deployment dates; local points of contact; and the Command Communications Service Designator. The DoD Component CDS owner or manager will forward this information to the CDSE monthly or when changes occur for uploading the information into the designated repository."

iii. Document the requirement for Repeatable Accreditation/Authorization within section 1.0 of the CDA

G.3.1.3. The organization’s respective CDSE POC reviews the required artifacts and assigns an Operational Impact to the requirement by updating the "Channels" section in the SGS system for the respective request. The CDSE POC then submits an agenda request form to the DSAWG Secretariat (CDTAB Support).  The CDSE ensures all required artifacts are uploaded into SGS prior to requesting the item to be reviewed by the CDTAB.  If the CDSE determines that the CDS request is for an Access CDS, Minimal Community Impact, or ECSDP Sponsor System Ticket, then the respective CDSE must submit an agenda request form (select the "Template" tab on the SIPRNet CDTAB website) to the DSAWG Secretariat (CDTAB Support 14 calendar days prior to the next CDTAB meeting. The CDTAB and DSAWG meet once per month but, after review, DISA RE42 may determine to process your request electronically via an "evote" versus presenting at the CDTAB meeting.  The CDTAB/DSAWG yearly schedule is located on the DSAWG website.  Regarding CDS matters, the DSAWG Secretariat (CDTAB Support) will only accept agenda requests from an organization’s CDSE.  The DSAWG Secretariat (CDTAB Support) will verify receipt of all required items and notify the CDSE if additional items are required.

G.3.1.4. CDTAB Phase 1 Review.  During the CDTAB review, the CDTAB will:

1. Determine if a CDS is required to meet the mission requirement.

   The following abbreviated summary of the requirements described in the DoD CIO and USD(A&S) memo, "Suspension of New P2P CDS Implementations and Changes to Existing Point-to-Point Cross Domain Solutions Implementations,:" October 10, 2018, and described in detail in the DOD ISRMC approved (2 Jun 2019) "NCDSMO Implementation Guidance for Department of Defense (DOD) Suspension of Point-to-Point Cross Domain Solution (CDS) and Migration to Enterprise Cross Domain Services." If the guidance is updated to articulate requirements different than explained below – the Implementation Guidance is the authoritative document defining the requirements and must be followed IAW DoD ISRMC guidance.

2. Recommend a NCDSMO baseline solution to meet the requirement.
3. P2P CDS Exemption Review/Approval Process.  For a P2P CDS that is not an Access CDS[23] or MCI CDS: Ensure the applicable P2P Implementation Guidance Process and Artifacts have been completed (See P2P CDS Exemption Review/Approval Process) and make a recommendation to DSAWG on approval or disapproval of a Point to point solution to meet the mission requirement. The following P2P CDS Exemption Review and Approval Process is illustrated in Figure 19.

i. For a P2P Transfer or Multilevel, Tactical, server-based Access CDS, or Enterprise Candidate P2P CDS the Customer works with the CDSE to complete the CDS questionnaire that includes the P2P and/or Tactical criteria assessments.  The customer (GS15/O6) signs and forwards the P2P CDS questionnaire to the DoD Component’s CDSE POC.

ii. The Component’s CDSE reviews the required documentation including the P2P CDS questionnaire (with P2P and tactical criteria assessments) and signs the questionnaire.

iii. If the CDSE determines the CDS meets the tactical intent, then the CDSE notes this in the comment section of the CDS questionnaire and no additional P2P Implementation Guidance Processes or artifacts are required prior to CDTAB review.  The CDSE emails notification to NCDSMO that tactical questionnaire has been completed and uploaded to SGS two weeks prior to the CDTAB decision request.  The CDSE does not have to wait for a NCDSMO response to proceed.

If however the CDS does not meet all tactical criteria at the present time according to the development & deployment timeline requirements found in the "Cross Domain Solution (CDS) Design and Implementation Requirements: 2018 Raise the Bar (RTB) Baseline Release," then a POA&M to meet those criteria will be required that is signed by the Program/Project Manager or the individual responsible for maintaining and monitoring overall execution of the POA&M.

iv. If the P2P CDS request does not meet tactical criteria intent, the CDSE sends the P2P CDS questionnaire (with the P2P CDS criteria assessment) to the appropriate ECDSPs for review via the ECDSP’s preferred way of receipt. 

v. Each ECDSP completes its portion of the CDS questionnaire indicating if the ECDSP can support the requirement.  The ECDSP emails the updated questionnaire to the CDSE and the customer.

vi. If an ECDSP asserts within their section of the CDS questionnaire that it CAN support the CDS requirement and the Customer CONCURS no additional P2P Implementation Guidance Processes or artifacts are required prior to CDTAB review.

vii. If an ECDSP asserts within their section of the CDS questionnaire that it CANNOT support the CDS requirement, or if an ECDSP states they CAN but the customer NON-CONCURS with utilizing an ECDSP, then the CDSE reviews the P2P Criteria responses in the CDS Questionnaire and determines if the customer meets the P2P Criteria.

If the P2P CDS request does not meet the P2P criteria, the CDSE works with the customer to develop a POA&M that addresses the P2P CDS requirement shortfalls.  The customer may also have to develop a POA&M to migrate to an ECDSP or indicate the customer’s intent to provide a justification to the DoD ISRMC (post CDTAB and DSAWG) for not migrating to an ECDSP.

viii. The CDSE emails to the NCDSMO the CDS Questionnaire (which includes P2P criteria assessment and ECDSP response) as well as the POA&M (if required) with required signatures completed.

ix. NCDSMO reviews the P2P CDS questionnaire, the CDSE’s P2P CDS assessment criteria assessment and the P2P CDS Criteria POA&M (if required).  The NCDSMO will then determine if the P2P CDS request requires a P2P CDS Exemption Memo due to not using an ECDSP or if the P2P CDS criteria shortfall POA&M is not in accordance with the Raise the Bar (RTB) schedule requirements. 

If the NCDSMO notifies the CDSE that a P2P CDS Exemption Memo is NOT required, the CDSE uploads into SGS the P2P CDS questionnaire (with the P2P CDS criteria assessment) and POA&M (if required). After this, no additional P2P Implementation Guidance Processes or artifacts are required prior to CDTAB review.

x. If the NCDSMO notifies the CDSE and customer that a P2P CDS Exemption Memo IS required, the customer develops a P2P CDS Exemption Memo signed by the customer/program manager and submits P2P CDS Exemption Memo, the P2P CDS Questionnaire (with P2P CDS criteria assessment), and any POA&Ms to CDSE for review.

xi. CDSE reviews then emails to the NCDSMO: the P2P CDS questionnaire (with P2P criteria assessment), the P2P Exemption Memo that includes the signed CDSE recommendation, the POA&M to meet P2P criteria if P2P criteria were not met, and/or the POA&M for migrating to an ECDSP (if applicable).

xii. NCDSMO reviews and emails the P2P CDS Exemption Memo with the NCDSMO’s signed recommendation to the CDSE.

xiii. CDSE works with the customer to obtain the Component Head’s (GO/FO/SES) signature on the Exemption Memo before meeting with the DSAWG.  The CDSE uploads into SGS the P2P CDS questionnaire (with the P2P CDS criteria assessment), the signed P2P CDS Exemption Memo, and POA&Ms (if any).  After this, no additional P2P Implementation Guidance Processes or artifacts are required prior to CDTAB review.

1. For an Enterprise CDS Candidate where the Enterprise CD Service Provider (ECDSP) has responded they can meet the requirement and the organization intends to utilize the ECDSP: Ensure there is a valid mission requirement for the proposed solution and that a CDS is required to meet the mission requirements.
2. For an ECDSP System CDS Request: Review the proposed system architecture and the DSAWG approved customer requirements (specific organization requests approved by DSAWG for Enterprise CDS implementation) and make any comments/suggestions regarding the technology selection.
3. For a Minimal Community Impact CDS (non-VLOR) request: Determine if the criteria for a Minimal (Community) Impact CDS has been met.
4. For Minimal Community Impact-VLoR: Conduct a Risk Review of the VLoR assertions and make a determination if the CDTAB determines the requirement meets the intent of VLoR.
5. For a Repeatable Accreditation Candidate CDS: Review the architecture, CDS, and data flows and provide comments to DSAWG.  For a Repeatable Accreditation/Authorization Candidate: Determine if Repeatable Accreditation/Authorization Requirements are met.

G.3.1.5. DSAWG Phase 1 Review: The DSAWG will review the CDTAB’s recommendation and comments and make a decision (or recommendation to DoD ISRMC) based on the following categories of CDS.

The following listed decisions are standard decisions based on the category of CDS listed. The DSAWG may make modified approval decisions or recommendations to the DoD ISRMC as they see fit.

1. For a point-to-point CDS: Approval for ticketing and phase 2 analysis OR direction that an ECDSP must be utilized.
2. For a Minimal Community Impact (non-VLOR) request: Approval for 3 years of operational use. SBSA approval is within AO purview and does not require separate DSAWG approval
3. Minimal Community Impact VLoR: Conduct a Review of the CDTAB’s VLoR determination and approve for SBSA and continued operational use for 3 years contingent upon the CDSE review of the SBSA results
4. For an Enterprise CDS Candidate where the ECDSP has responded that they could meet the requirement and the organization intends to utilize the ECDSP: approval for Enterprise CDS Implementation.

G.3.1.6. DoD ISRMC Phase 1 Review (may not be required - see Section G.9.1 of this guide): The DoD ISRMC will review the DSAWG’s recommendation and comments and make a decision. Per the DoD CIO and USD(A&S) Memorandum, "Suspension of New Point-to-Point Cross Domain Solutions and Changes to Existing Point-to-Point Cross Domain Solutions Implementations" and the DoD P2P CDS Memo Implementation guidance – the DoD ISRMC will need to make the decision on all new P2P guards that require exemptions – that is, a P2P CDS that is not a Tactical CDS, Minimal (Community) Impact CDS, Access CDS, or a scenario where the ECDSP was unable to support).

G.3.2. Phase 2: CDS Engineering, Security Control Selection & Security Control Implementation

This phase applies only to point-to-point CDS and Enterprise CDS that are required to receive a RDAC/Cross Domain Risk Model (CDRM)[24] analysis.  Minimal Community Impact Tickets usually skip this phase.

G.3.2.1. The organization works with their respective CDSE POC (and the ECDSP where applicable) to engineer the CDS, and to complete and upload the following into SGS: 

a) Documentation Requirements

· Phase 2 CDA, section 2.0 completed

· SBSA Plan and Procedures

· CDS Risk Assessment Reports (RAR) template.  The CDS RAR template is located on the SIPRNet CDTAB website

· Note, the designated entities complete the draft risk analysis under RDAC, the CDSE usually provides the Data Risk and all portions of the Attack Risk, except the Partner Type provided by the Defense Intelligence Agency (DIA), and the Grid Connectivity Threat (GCT) provided by the DISA Risk Adjudication.  The CDSE ensures all required artifacts are loaded into SGS prior to requesting the item to be reviewed by the CDTAB.

G.3.2.2. The respective CDSE submits a CDTAB agenda request to the DSAWG Secretariat (CDTAB Support) 14 calendar days prior to the next CDTAB meeting. The DSAWG Secretariat (CDTAB Support) will not accept any late submissions.  The DSAWG Secretariat (CDTAB Support) will only accept agenda requests from an organization’s CDSE.  If the CDSE and DSAWG Secretariat (CDTAB Support) determines the decision will be non-controversial, they can request a CDTAB evote be conducted electronically.

G.3.2.3. CDTAB Phase 2 Review: The voting members will review the information provided from the organization’s CDA and the compiled risk rating, and will provide a vote of concur or non-concur with the risk rating and adjust the assigned risk ratings as necessary.  They will also review and/or provide recommended risk mitigations, if needed.

G.3.2.4. DSAWG Phase 2 Review:  The ticket is then presented to the DSAWG with the CDTAB’s risk rating and recommended risk mitigations, if needed.  The DSAWG will make a decision (or recommendation to the DoD ISRMC) regarding whether or not to approve a CDSA for SBSA based on the following scenarios:

· If the organization intends (or is directed) to apply CDTAB recommended mitigations prior to SBSA or if the technology is being deployed for the first time in DoD then SBSA approval will be granted for 2 weeks within a 90-day window.  Note that organizations may request additional time for SBSA if needed.  After SBSA, the organization will proceed to Phase 3.

· If no additional mitigations need to be applied and if the technology is not being deployed for the first time in DoD: SBSA approval for 2 weeks within a 90 day window and continued operational use upon CDSE review of the SBSA results will be granted.  This process is a compressed process for Phase 3 and does not require a Phase 3 CDTAB or DSAWG review.

· Need for Immediate Operational Use upon SBSA completion.  On occasion, the DSAWG grants approval for 30 days Immediate Operational Use upon conclusion of the SBSA prior to CDSE review of the SBSA results.  This is usually done for tickets that are upgrades or configuration changes to already operational systems so as not to cause a lapse in service.  An example DSAWG approval in this case would be "approval for 2 weeks within 90 days for SBSA with 30 days immediate operational use.  DSAWG also approves 1 year of operational use upon successful review of the SBSA results by the CDSE."

G.3.2.5. DoD ISRMC Phase 2 Review (may not be required):  The ticket is then presented to the DoD ISRMC with the CDTAB’s risk rating and recommended risk mitigations, as well as the DSAWG recommendation. If needed, the DoD ISRMC will make a decision regarding whether or not to approve a CDSA for SBSA and/or CDSA for operational use.

G.3.2.6. Based on the DSAWG (or DoD ISRMC) decision, DISA Risk Adjudication will update SGS milestones and take the following actions based on the approval that was given: (see CDSA Issuance Section G.4 of this guide).

G.3.3. Phase 3:  CDS Security Control Assessment & Authorization

This phase applies only to P2P CDSs and Enterprise CDSs that are required to receive a risk analysis.  Minimal Community Impact Tickets usually skip this phase.

 G.3.3.1. The organization works with their respective CDSE (and ECDSP if applicable) to conduct SBSA, to review the SBSA results, and to complete and upload the following into SGS:

a) Required Documentation

· SBSA results

·  Updated Phase 3 CDA to include identification of IP addresses for the Guards and administrative server on the topology diagram.

G.3.3.2. The respective CDSE will review the SBSA results to verify no changes exist between the Draft Risk Analysis and the actual test results.  If there are no changes and the DSAWG already approved operational use upon CDSE review of the SBSA results, then the CDSE must document this SBSA result in the SGS sections 6.9, 6.10 and 6.11, and notify the DISA Risk Adjudication requesting issuance of the CDSA.  (Proceed to step 4) If the CDSE discovers that the SBSA results differ from the SBSA plan expected results, or if DSAWG otherwise requires the ticket to return to DSAWG for operational use, continue the steps below.  The CDSE will revise the risk rating and request other entities, which provide the risk rating to revise it, based on the SBSA results as necessary. Once the revised ratings are provided, the CDSE will submit an agenda request[25] to the DSAWG Secretariat (CDTAB Support) 14 calendar days prior to the next CDTAB meeting or request an evote.

G.3.3.3. CDTAB Phase 3 Review: CDTAB voting members will review the post SBSA risk ratings and provide a vote of concur or non-concur with the risk rating and comments, if necessary.

G.3.3.4. DSAWG Phase 3 Review: The ticket will be presented to the DSAWG with the CDTAB’s risk rating and comments.  The DSAWG will make a decision (or recommendation to DoD ISRMC) whether or not to approve a CDSA for Operational Use.

G.3.3.5. DoD ISRMC Phase 3 Review (may not be required): The ticket will be presented to the DoD ISRMC with the CDTAB’s risk rating and comments and the DSAWG recommendation.  The DoD ISRMC will make a decision whether or not to approve a CDSA for Operational Use

G.3.3.6. Based on the DSAWG decision, the DISA Risk Adjudication will update SGS milestones and take the actions described in Section G.4 of this guide based on the DSAWG’s approval.

G.3.4. Phase 4: Operational CDS Monitoring

CDSs can receive approval for up to 3 years of operational use from the DSAWG or DoD ISRMC.  This means that they do not need to return to CDTAB/DSAWG/DoD ISRMC for 3 years.  However, the CDS (unless a Minimal Community Impact CDS) still requires an annual review by the CDSE and the DSAWG Secretariat (CDTAB Support).[26] The process described below describes actions necessary for an annual review when CDTAB/DSAWG/DoD ISRMC review is required as well as an annual review where CDTAB/DSAWG review is not required. 

G.3.4.1. The organization contacts CDSE, submits required documentation, and updates SGS as follows:

• CDS Revalidation Memorandum. A CDS revalidation memo from the AO stating that the CDS is still required, the CDS configuration has not changed, and has been tested.  For an Enterprise CDS: the revalidation memorandum is split into multiple revalidation memorandums.  A revalidation memorandum that revalidates the mission requirement for the CDS is required from each organizations’ AO.  The AO of the ECDSP must provide an additional revalidation memorandum that verifies the unchanged configuration and testing of the system.
• CDS Annual Self-Assessment Report. IAW DoDI 8540.01, Enclosure 5, paragraph 8.k the IS owner assesses the protection mechanisms and security controls implemented to protect CD activities. The assessment will:

· Review the security relevant configuration, operation, and administration of the CDS in its operational environment.

· Verify that the CDS is utilized per the approved security relevant configuration and documentation requirements.

· Identify possible security vulnerabilities.

· Document findings in an assessment report and updated IS POA&M to support annual CDSA revalidation.

• Repeatable Accreditation/Authorization. The owner must submit to the CDSE an updated CDS tracking spreadsheet of the repeatable CDS inventory that the organization’s CDSE uploads into SGS.

• POA&M (if required) uploaded to SGS:  If the CDS fits any of the following conditions, the IS Owner must submit via their CDSE a POA&M detailing their schedule to migrate to a new solution or for applying other mitigations within the architecture.

· The IS Owner is using a non-baseline CDS device

· An ECDSP has stated they can meet the requirement

· DSAWG or DoD ISRMC directs improvements to the current system being deployed.

DoDI 8540.01, Enclosure 5 "CD and RMF Roles," paragraph 9 "Information Owner"

e. Coordinates with the IS owner to support the DoD Component CDS risk assessment by providing the level of impact (i.e. harm) to the organization due to a threat event causing an unauthorized disclosure, unauthorized modification, unauthorized destruction, or the loss information in support of DoD Component CDS risk assessment consistent with [NIST 800-30].

G.3.4.2. CDSE must review the updated annual review artifacts and advise if the previously assessed risk assessment has change due to newly discovered threats and/or vulnerabilities.  CDSE must notify the DSAWG Secretariat (CDTAB Support) of these completed actions.  If the DSAWG/DoD ISRMC approved operational period has not expired, the DSAWG Secretariat (CDTAB Support) will proceed to step 5.  If the ticket needs an extended operational approval, the DSAWG Secretariat (CDTAB Support) will schedule the CDS for CDTAB review.  The DSAWG Secretariat (CDTAB Support) will only accept agenda requests from an organization’s CDSE.  The respective CDSE must submit all agenda requests to the DSAWG Secretariat (CDTAB Support) 14 calendar days prior to the next CDTAB meeting.  If the CDSE and DSAWG Secretariat (CDTAB Support) determines the decision will be non-controversial, they can request a CDTAB evote be conducted electronically.

G.3.4.3. CDTAB Phase 4 Review: The CDTAB voting members will review the CDS Annual Review required documents, any additional information provided/extracted from the organization’s CDA, and the previous risk rating prior to providing a concur or non-concur vote with the risk rating and any associated comments/ recommendations to DSAWG.

G.3.4.4. DSAWG Phase 4 Review: The ticket will be presented to the DSAWG with the CDTAB’s risk rating, recommendation, and comments.  The DSAWG will make a decision whether or not to extend the operational approval for the ticket.

G.3.4.5. DoD ISRMC Phase 4 Review (may not be required): The ticket will be presented to the DoD ISRMC with the CDTAB’s risk rating, recommendation, and comments and the DSAWG’s recommendation.  The DoD ISRMC will make a decision whether or not to extend the operational approval for the ticket.

G.3.4.6.  Based on the DSAWG/DoD ISRMC decision, the DSAWG Secretariat (CDTAB Support) will update SGS milestones and take the actions described in Section G.5 of this guide based on the DSAWG’s approval.

G.4.Post DSAWG/DoD ISRMC Actions and Cross Domain Solution Authorization Issuance

G.4.1

Based on the DSAWG decision, the DSAWG Secretariat (CDTAB Support) will update SGS milestones and take the following actions based on the approval that was given:

a) If ticketing was approved for a point-to-point CDS or an enterprise owned system, a CDS ticket number will be assigned

b) If ticketing was approved by the DSAWG and an ECDSP can meet the requirement, the request number will be closed.  The ECDSP will notify the customer of the ticket number for the system they intend to use to meet the customer’s requirement in Phase 2.  The original request number will always be used to reference the customer’s requirement and DSAWG approval of the requirement for the Enterprise CDS implementation.

c) If SBSA was approved, the DISA Risk Adjudication will review the documentation requirements for issuance of a CDSA for SBSA which include:

i. Notification of SBSA dates from CDSE at least 2 weeks prior to the start of SBSA.

ii. A Phase 2 CDA (meaning sections 1.0 and 2.0 completed), which references the CCSD and is signed by the AO.  (If not signed by an AO, then a separate ATO signed by the AO that authorizes the specific CDS ticket numbers will be accepted).  This must show the complete CDS Ticket Number/s.

iii. SBSA Plan and Procedures.

iv. A valid ATC (signed and current) for the CCSD’s connection to the CDS.  (A CDSA for SBSA or Operational Use will not be issued past a CCSD expiration date)

v. An updated Enclave topology with the CDS must be uploaded to the respective CCSD in section 10.2 (topology) of the SGS GIAP module and show the CDS and CDS ticket number to include identification of IP addresses for the Guards and administrative server on the topology diagram.  The CDS Ticket number must be accurate within the first two sections of the ticket number.  Examples of accepted ticket number depictions are 1234-0001-xxx or 1234-0001-001 (Applies to SIPR connected CDSs only)

vi. Section 4 of the SGS GIAP for the hosting CCSD must be updated stating that a CDS resides in the enclave and referencing the CDS Ticket Number/s.  The CDS Ticket number must be accurate within the first two sections of the ticket number.  Examples of accepted ticket number depictions are 1234-0001-xxx or 1234-0001-001 (Applies to SIPR connected CDSs only)

An SGS GIAP record must be unlocked before it can be updated. The owner of the SGS record must first send an email asking DISN CAO to unlock the SGS record. After the owner completes updating the SGS record, the owner must send an email asking DISN CAO to lock the SGS record.

d) If Operational Use was approved, the DISA Risk Adjudication will review the documentation requirements for issuance of a CDSA for Operational Use which include:

i. A Phase 3 CDA (meaning sections 1.0, 2.0, and 3.0 completed), which references the CCSD and is signed by the AO.  (If not signed by an AO, then a separate ATO signed by the AO which authorizes the specific CDS ticket numbers will be accepted)

ii. A valid ATC for the CCSD’s connection to the CDS.  (A CDSA for SBSA or Operational Use will not be issued past a CCSD expiration date)

iii. An updated Enclave topology with the CDS must be uploaded to the respective CCSD in section 10.2 (topology) of the SGS GIAP module and show the CDS and CDS ticket number to include identification of IP addresses for the Guards and administrative server on the topology diagram.  The CDS Ticket number must be accurate within the first two sections of the ticket number.  Examples of accepted ticket number depictions are 1234-0001-xxx or 1234-0001-001 (Applies to SIPR connected CDSs only)

iv. Section 4 of the SGS GIAP for the hosting CCSD must be updated stating that a CDS resides in the enclave and referencing the CDS Ticket Number/s.  The CDS Ticket number must be accurate within the first two sections of the ticket number. 

v. Examples of accepted ticket number depictions are 1234-0001-xxx or 1234-0001-001 (Applies to SIPR connected CDSs only)

vi. SBSA Results (If SBSA was required)

vii. Uploaded verification of CDSE review of the SBSA results (If SBSA was required)

G.4.2

If the documentation requirements are not sufficient for a CDSA to be issued at the time of the DSAWG or DoD ISRMC, decision the DISA Risk Adjudication will notify the CDSE of the missing requirements.  In order to obtain a CDSA once the documentation requirements are completed, a CDSA request form (see the “Template” tab on the SIPRNet CDTAB website) must be submitted to the DISA Risk Adjudication.

G.4.3  

CDSAs for operational use will not be issued which would expire within two weeks of the date the CDSA request form received due to ATO expiration, ATC expiration or DSAWG/DoD ISRMC Approval Window Expiration.

G.4.4  

If the DSAWG or the DoD ISRMC approved more than 1 year of operational use, then a CDSA will be issued for a maximum of 1 year and will be reissued when the annual review is conducted.  (See Operational CDS Monitoring, Section G.3.4).  If the CDS was approved as a Minimal (Community) Impact CDS, then a CDSA can be issued not to exceed three years from the date of the DSAWG or DoD ISRMC review.  CDSAs will not be issued past AO authorization for the CDS.

G.4.5  

If the ticket is a repeatable authorization/accreditation ticket, the CDSA for SBSA and/or “Operational Use” it will specifically reference the number of CDSs authorized by the DSAWG or DoD ISRMC.  If the organization needs to operate additional instantiations, it is necessary to return to DSAWG with mission justification for approval.

G.4.6  

The CDS device is marked operational in SGS upon the initial issuance of a CDSA by the DISA Risk Adjudication) following a DSAWG or DoD ISRMC approval.  It remains operational until the DISA Risk Adjudication receives evidence in the form of either an email or memo from the organization’s respective CDSE that the device is non-operational.

G.5.Configuration Changes to Operational CDSs

Planned changes to the configuration of the CDS including patches and upgrades must be coordinated with the organization’s respective CDSE and entered into the SGS as Phase I requests (unless CDTAB has approved an exception due to patch being minor in which case SGS just needs to be updated and DSAWG Secretariat (CDTAB Support) notified).  If the change is a patch (determined by CDTAB to be applied in the form of a new ticket), software upgrade, or other configuration change such as adding a channel or network, the DSAWG Secretariat (CDTAB Support) will administratively move the request to Phase 2.  The DSAWG Secretariat (CDTAB Support) will then issue a new CDS ticket number provided the phase 1 documentation requirements (including a CDS Questionnaire, exemption memorandum and POA&M if applicable) and SGS updates have been completed.  The CDS ticket will proceed to CDTAB in Phase 2 to complete the normal CDS approval process.

The CDS ticket will not be administratively moved to Phase 2 if the request is for a change in technology.  Instead, the CDS ticket follows the normal Phase 1 process.

G.6.Closure of a CDS Requirement

If for any reason it becomes necessary to discontinue use of a CDS or an organization is no longer continuing their mission, the respective CDSE must submit a closure request in order to stop tracking the CDS ticket in SGS.  The CDS analyst who performs the closure will upload the closure request to SGS under the ticket in question, and close the ticket with the comment “Closed per CDSE request.”  If the CDS device connects to SIPRNet, the related CCSD sections 4 (Classified Network Information) and 10.2 (Topology) of the SGS GIAP module must be updated by the customer as well to remove the CDS.

G.7.Process for Approving an ECDSP System for Streamlined Onboarding of new customer

The DoD ISRMC approved the ECDSP Streamlined Onboarding (SO) Process on 25 Jun 2019.

G.7.1. Criteria

This process allows for an abbreviated A&A process for ECDSPs to onboard customers to ease and expedite DoD Components transition to ECDSPs when the following criteria are met:

1. An ECDSP has brought an initial solution/filter forward for SO to CDTAB for a risk rating and DSAWG/DoD ISRMC for approval
2. Evidence of AO approval for SO required.
3. The filter should be given a unique name/identifier and incremented version number
4. Additional customer(s) deployed to use the solution/filter must be deployed on an operational ECDSP CDS with the same filter that was previously approved by DSAWG/DoD ISRMC

i. SO Channels should represent less than or equal to the amount of risk as the initial approval.

1. The new channel(s) for SO shall be the same as the initially approved channels in the following manner:

i. Transfer data between the same network pairs as the initial approval

ii. Fielded on the same guard

iii. Pass the same data type(S)

iv. Employ the same filter name/version

v. Have the same auditing/logging mechanism in place and send the same information to the ECDSP CNDSP

1. All changes to the solution/filter require a new brief to CDTAB for an updated risk rating and DSAWG/DoD ISRMC for approval for SBSA and operational use.
2. ECDSP must provide Due Diligence to CDTAB/DSAWG/DoD ISRMC monthly or (as requested)
3. ECDSP filter is provided to NCDSMO for the Cross Domain Threat Assessment Enclave. (TAE) (after approval for CDSA for operational use)

G.7.2. Process for on boarding a new customer to an ECDSP approved for Streamlined Onboarding

After an ECDSP system is approved to use the Streamlined Onboarding Process (see Section G.7.1), the process for onboarding a new customer to the approved ECDSP will occur depending on the Phase:

G.7.2.1.           Phase 1:

CDS approval for an ECDSP would proceed as normal

G.7.2.2.           Phase 2:

During the initial approval for the enterprise CDS - In addition to normal phase 2/3 CDS process the  following will occur:

• An ECDSP brings forward a filter for SO with initial customer to phase 2/3 approval
• The CDSE provides SO recommendation (prior to CDTAB)
• CDTAB will make a SO recommendation
• DSAWG or DoD ISRMC would approve the ticket and the use of SO

G.7.2.3            Phase 3:

DISA Risk Adjudication would issue CDSA for SBSA

• ECDSP would review SBSA report and if acceptable request CDSA for operational use

G.7.2.4            Phase 4:

DISA Risk Adjudication would issue the CDSA for operational use that would reference the SO approval.

G.7.2.5.           After the ECDSP system is approved for SO the onboarding process as illustrated in Figure 20 to add a customer channel would be as follows:

1. ECDSP has new customer requirements (customer request has already completed phase 1 of the CDS process as an ECDS candidate and has been approved by DSAWG for ECDSP implementation)
2. ECDSP updates Phase 2/3 for proposed channels
3. ECDSP/ECDSP CDSE enter in process channels to include A/R date in SGS (channels marked as in process)
4. ECDSP CDSE evaluates Phase 2/3 SO requirements
5. ECDSP CDSE determines SO requirements met or not.
6. If not SO process does not apply and ticket number and the filter must be incremented and proceed to standard phase 2/3 process
7. If ECDSP CDSE determines SO requirements were met and the risk rating is equivalent or less the ECDSP uploads the concurrence to the SGS and notifies DISA RE42
8. DISA RE42 would verify the artifacts to include the evidence of ECDSO AO’s approval for SO. If acceptable the secretariat would issue a new updated CDSA and mark the channels approved in SGS under the respective ticket number
9. ECDSP would proceed to add the new flow to the CDS
10. ECDSP tracks configuration management tool
11. ECDSP CDSE receives CM evidence as requested
12. ECDSP/ECDSP CDSE provide Due Diligence brief to the CDTAB/DSAWG monthly or as requested
13. ECDSP/ECDSP CDSE align SO channels with Annual Review
14. New Channels documented annually in the Annual Review slides

G.8.IC CDS Registration Process

As illustrated in Figure 21, the DoD ISRMC requested that all IC owned CDSs that connect to DoD Networks are registered in SGS.  Having all CDSs which connect to DoD Networks registered in one central location aids the CDTAB, DSAWG and DoD ISRMC by maintaining an accurate depiction of DoD network environments and interconnections to facilitate rapid incident response.

G.8.1. Step 1: Obtain and Complete an IC CDS Registration Form

To obtain an IC CDS Registration form template, contact the DSAWG Secretariat (CDTAB Support).  The form is also posted on both the CDTAB website and DSAWG SIPR Intelink Sites.  The IC registration form contains all of the data necessary to complete an SGS database registration.

G.8.2. Step 2: SGS Entry and IC Registration Form Review

Once the IC registration form is completed, the IC Component or CDSE will register the CDS in the SGS database and upload the IC registration form as an attachment.

Access to the SGS database on SIPRNet and select “request an account.”  The CDSE will be required to upload a completed DD 2875.  A template is on the entry page of the website.  Once the registration is complete, the IC component or CDSE will notify the DSAWG Secretariat (CDTAB Support) of a completed registration.  The DSAWG Secretariat (CDTAB Support) will review the registration, generate a CDS Ticket Number, and notify the submitting IC Component and/or CDSE of the CDS Ticket Number.

G.8.3. Step 3: Submission of Requested Documentation for Reciprocity Acceptance

The IC component or CDSE will upload a copy of the signed AO authorization for the CDS and the SBSA evidence for the CDS to the SGS database under the respective SGS record.  Once uploaded, the IC component or CDSE will notify the DSAWG Secretariat (CDTAB Support) that all documents have been submitted.  The DSAWG Secretariat (CDTAB Support) will send notification of a completed IC CDS registration to the DSAWG Chair.

G.8.4. Step 4: CDSA Issuance

Upon review of the notification of IC registration, the DSAWG Chair will authorize the DISA Risk Adjudication to issue a CDSA for operational use for a specified duration.

G.8.5. Step 5: Operational CDS Monitoring

Annually, the DSAWG Secretariat (CDTAB Support) will request the IC POC to verify if the CDS is still operational.  Any time that the devices are modified in a manner that requires the IC registration to be updated, the IC agency should provide that update to the DSAWG Secretariat (CDTAB Support).  If the device is decommissioned, the IC agency provides a signed memo or digitally signed e-mail to the DSAWG Secretariat (CDTAB Support), which will close the registration in SGS. 

G.9.Frequently Asked Questions

G.9.1. Q:  What CDS decisions has the DoD ISRMC delegated to the DSAWG?

A:  The DoD ISRMC Decision Ballot on “Delegation to DSAWG of Decision Authority on CDS Tickets, 24 April 2018 is as follows:

Tickets inside of the RDAC risk range based on tech, data, and mission

Tickets 1 step out of the RDAC risk range with due diligence to DoD ISRMC

Exercise CDS tickets

For Minimal (Community) Impact CDS Tickets [formerly “Tracking Purposes Only (FTPO) Tickets”] which meet on of the following criteria:  completely isolated connecting enclaves, VLoR or controlled interfaces

Cyber TAPS utilizing approved one way solution in DoD ISRMC approve Cyber SA enclave

Annual review of impacted tickets.  If CDS vendor and customer are actively working to resolve the issues, as per DoD CIO policy memo and NSA guidelines

Annual review of previously approved DoD ISRMC CDS ticket, with no change in previous risk rating and complying with DSAWG/DoD ISRMC directed constraints and directives for Contractor Facility CDS & Continued use of a Sunset CDS

Note:  New P2P CDS requests must go to the ISRMC unless they are for an Access CDS or MCI CDS per the Implementation Guidance for Department of Defense (DoD) Suspension of Point-to-Point Cross Domain Solution (CDS) and Migration to Enterprise Cross Domain Services .

G.9.2. Q: Do I need to create a request for every CDS device/distribution console I intend to meet a specific requirement?  What if it is a hot or cold spare or it is being used for load balancing?

A: A separate request/ticket is required for each CDS device/distribution console if there are any configuration differences or if they are deployed at different locations. A separate request is not needed for a cold spare but the cold spare must go through SBSA with the primary and evidence of the SBSA results must be uploaded under the SGS.  In the event the cold spare is utilized, the CDSE and the DSAWG Secretariat (CDTAB Support) must be notified and a new request must be opened.

The example of this is if the ticket is an ECDSP ticket or a Repeatable Accreditation/Authorization ticket.  Another example is if multiple identically configured guards are going to be deployed at the same location at the same time and SBSA will be conducted at the same time.  In these scenarios, the “Instantiations” field of SGS will be updated to reflect the number of instantiations a single CDS ticket represents.  All documentation (CDA/CDSA/Briefing Slides) will be maintained under that single CDS ticket number in SGS and will list the ticket numbers as if they existed in the database (Ex: 1234-1/2/3/4/5-001).

G.9.3. Q: What is the significance of the three partitions of a CDS ticket number?

A:  Once a point-to-point CDS or enterprise owned CDS Request (ex:  R0001111) is approved at DSAWG, it is assigned a ticket number that is formatted in three partitions (ex: 1234-0001-001).  The significance of these partitions is as follows:

First partition (1234-0001-001):  The first partition represents the organization’s configuration.  If this is a new organization configuration, the request will receive a ticket number with a unique first partition.  The second and third partitions will be numbered  ”0001-001”

Second partition (1234-0001-001):  The second partition represents the instantiation of the CDS device.  For example, if three identically configured CDS devices were needed at three different locations the ticket numbers would be 1234-0001-001, 1234-0002-001, and 1234-0003-001.  The configuration and organization requirement is the same, but there are three devices meeting this requirement at three different locations. 

Third partition (1234-0001-001): The third partition of the ticket number represents the iteration of the ticket.  This number is usually created when a CDS Request is approved to change the configuration or upgrade a previous device.  For CDES, this happens often due to the addition of new channels supporting new elements.  For example, if pre-existing ticket 1234-0001-001 were upgrading to the next version of RM, the newly assigned ticket number would be 1234-0001-002.  Once the new ticket is operational, the previous iteration -001 will be closed in SGS.

G.9.4. Q: What is the difference between a CDSA and an ATC?

A: Once a Security Authorization Package is submitted, reviewed, and accepted by the DISN CAO, then an ATC for the CCSD is issued.  The ATC contains the statement, “This ATC does not authorize any Cross Domain Solutions.  A separate Cross Domain Solution Authorization Letter will be issued authorizing Cross Domains.”  A CDSA is issued after DSAWG or DoD ISRMC approval of a CDS contingent upon all required paperwork being submitted to DISA RE42.  A DSAWG or DoD ISRMC Ballot is not community authorization to utilize a CDS.  Per 8540.01, a CDSA is required.

"IAW DoDI 8540.01, paragraph 3.g, it is DoD Policy that “the DoD-level risk decision on use of a CDS to access or transfer information between different interconnected security domains must be made by the designated DoD risk executive as a CDS authorization (CDSA) ….” IAW DoDI 8540.01, Enclosure 2, paragraph 8.u.(1) DoD Component Heads shall: ”Require the issuance of a DoD ISMRC [sic] or DSAWG CDSA before allowing a CDS to access or transfer information between different interconnected security domains. A CDSA is required for use of a CDS.” "

Appendix H Connection to DISN Mission Partner Gateways (MPGW)

H.1.Mission Partner DMZ or Gateway Connections 

This Appendix supplements information provided in Section 2.11 of this guide with additional information on DISN MPGW connections.  DISN MPGWs provide support for DoD Contractors, Federal Partners, and Allied/Coalition Partners with connections approved by DoD CIO as described in Appendix B. 

The NIPRNet Federated Gateway (NFG) supports unclassified Mission Partner connections to NIPRNet, the SIPRNet FED DMZ supports classified U.S. Mission Partner connections to SIPRNet, and the SIPRNet REL DMZ supports classified coalition connections to SIPRNet.

IAW DoDI 8010.01 and CJCSI 6211.02D, DoD Mission Partner (non-DoD organizations) enclave connections (including a contractor’s enclave connection) to DISN-provided transport must be through an established DISN DMZ and will follow DISN DMZ security requirements.  In certain limited special use cases, the DoD CIO has approved some non-DoD Federal Agency direct connections to the NIPRNet and SIPRNet; however, this is not the norm.  DISN DMZs/NFG access connections can be either physical or logical (see Figure 22).  Mission Partners will work with the NIPRNet NFG Office or the SIPRNet FED and REL DMZ Office to initiate their respective MPGW connections. 

All Mission Partner NIPRNet/SIPRNet connections require DoD CIO Approval, a formal agreement (e.g., Contract, MOA, or MOU) and DoD Component sponsor to validate DoD mission need for Mission Partner access to the DISN (See Appendix B for details).  DoD Component sponsors must understand and agree to their responsibilities as summarized in the DoD CIO sponsor Responsibilities Memorandum, applicable issuances, and the Defense Finance and Accounting Regulations (DFAR).  DoD Component sponsors must codify responsibilities for DISN connection in an appropriate agreement (e.g., MOA, MOU, or contract).  The DoD CIO establishes agreements with federal departments and agencies, consistent with DoDI 8010.01 and guidance in National Institute of Standards and Technology (NIST) Special Publication (SP) 800-47.

H.2.NFG

The NFG (aka Mission Partner Gateway (MPG) for JIE) provides a secure, robust, and scalable means for non-DoD Federal Agencies, Mission Partners, and contractor connections to connect to the Unclassified but Sensitive IP Router Network (NIPRNet).  In addition to the requirements listed in this Appendix, DoD Sponsors and Mission Partners must complete a NIPRNet Federated Gateway Policy Spreadsheet and Questionnaire.  The NFG Spreadsheet and Questionnaire provides baseline data for NFG engineering team to work with Mission Partner while the NFG Policy Spreadsheet identifies the firewall posture of the NFG that will support the Mission Partner.  The customer must notify the NIPRNet NFG Office of the PPSM Tracking Identifier, in addition to the above referenced documentation.  The NIPRNet NFG Office works with the DISA Web Content Filtering team provide the applicable firewall rulesets to the DISA Command Center.  The DISA Command Center issues a DISA Task Order (DTO) containing the firewall ruleset.  The DISA Global Operations Center (DGOC) implements the firewall rule set IAW the DTO (See Figure 23 and Figure 24).  The customer must identify PPSMs so DISA can configure the firewall rules to allow the enclave to use the corresponding services.  The NFG supports both logical and physical connections.  Figure 23 illustrates the NFG Connection Process, Use the zoom feature to improve legibility.

H.2.1. NFG Logical Connections 

DISA may extend existing Mission Partner connections to NIPRNet to the NFG point of presence without installing new physical circuits.  DISA accomplishes this by provisioning logical tunnels over the DISN.  These tunnels extend existing Mission Partner connection(s) to the NFG and the traffic will flow to the NFG via the logical connection.  Encryption is also available for logical connections if required by the Mission Partner.  Mission Partners are required to maintain a direct physical connection to a DISN node to be eligible for a logical connection.  DoD policy prohibits logical connections to DISN via DoD Component sponsor enclave (backside connections).  Logical connection use cases are as follows:

1. A commercial circuit extends from the customer to the DISN node.  At the DISN router, the customer logically connects to the NFG via the MPGW/NFG Community of Interest (MPG/NFG COI) Level-3 VPN service (VPN ID DKL300249).

2. Mission Partners currently having a direct connection to a NIPRNet router for NIPRNet access will be re-routed to NIPRNet via the MPG/NFG COI VPN service.

H.2.2. NFG Physical Connections 

Physical connections terminate on the NFG using up to OC-12 SONET 1 Giga Byte (Gb) and 10 Gb Ethernet (copper or fiber) connections.  A non-DoD organization such as a Federal Department/Agency, DoD contractor, or other Mission Partners may connect to the NFG router via third-party leased circuit or DISN transport in consonance with a formal agreement (e.g., contract, MOU, MOA, etc.).  In cases where the Mission Partner equipment is collocated with an NFG site, the Mission Partner Customer Edge router can connect to the NFG using a direct cable connection without a leased circuit and/or DISN transport. 

Physical connection use cases are as follows:

1. A commercial carrier extends a circuit from the Mission Partner service point to the NFG site.

2. A commercial carrier extends a circuit from the Mission Partner service point to DISN physical transport for a dedicated circuit to an NFG site.

3. A Mission Partner plugs directly into DISN transport for a dedicated circuit to an NFG site.

H.2.3. NFG Connection Approval Requirements 

NFG connections whether logical or physical require a modified Connection Approval Process package as illustrated below.  NFG connections will be annotated in SNAP database as “NIPR FED GW.”  Qualified NFG connections will receive an ATC/IATC and be reviewed IAW the established agreement (e.g., MOA/MOU/SLA).  Section 2.8.3 of this guide lists the attachments, documents, and artifacts required for a Non-DoD U.S. Government unclassified enclave or network connection to the NFG.

H.2.4. Ordering NFG Connections 

The customer orders NFG connections via the DSF:

1. Mission Partners must collaborate with their DoD Component sponsoring organization to order a connection to the NFG.  The DoD Component sponsor will use DSF to generate a TSR for connection to the NFG.  Refer to the DSF website for information on the connection ordering process.

a. For logical connections, the VPN Identification (ID) number for the NFG Community of Interest (COI) service is DKL300249

b. DSF assigns the VPN ID to all Mission Partners requesting NFG COI Service

2. The TSR initiates the process in DISA for identifying Mission Partner requirements and provisioning the new NFG connection paths based on the approved engineering design and connection approval package.

3. To revise approved connections, Mission Partners must update the approved connection approval package or submit a new package based on the approved engineering solutions.

4. Mission Partners must obtain and complete the NIPRNet Federated Gateway Policy Spreadsheet and Questionnaire.  The applicable PPSM must be identified so the corresponding services may be made available.  This may require the Mission Partner/sponsor to submit firewall rule requests to support the customer’s requirements as illustrated in Figure 24.

H.3.Mission Partner SIPRNet FED DMZ Connections

Figure 25 illustrates the Mission Partner SIPRNet FED DMZ connection process.  DoD CIO must approve a DoD Component sponsor’s request to connect a Mission Partner to the DISN as described in Appendix B.  Mission Partner connections to SIPRNet are through either the SIPRNet FED-DMZ, or the SIPR REL DMZ.  In rare cases, the DoD CIO may approve Mission Partner direct SIPRNet connection.  Applicable Mission Partner connections must adhere to DoDI 8110.01 applicable A&A standards (See Section 2.6 of this guide) and CJCSI 6290.01, Requirements Management Process for Mission Partner Environmentas part of the MPE and Joining, Membership, and Exiting Instructions (JMEI) policy requirements.  Like Mission Partner NFG connections, Mission Partner SIPRNet FED DMZ and SIPRNet REL DMZ connections can be either physical or logical.  Physical connections are directly homed to the SIPRNet FED DMZ (e.g., point-to-point connections between the DMZ and a Mission Partner's network).  Logical connections are physically homed to a SIPRNet router and connected to the SIPRNet FED DMZ / SIPRNet REL DMZ via an encapsulated tunnel.  SIPRNet FED DMZ and SIPRNet REL DMZ connections require a modified Connection Approval Process package as illustrated below.  Qualified SIPRNet FED DMZ and SIPRNet REL DMZ connections will receive an ATC/IATC and be reviewed IAW the established agreement (e.g., Inter Agency Agreement/MOA/MOU/Service Level Agreement).  Section 2.8.3 of this guide lists the network connection to the SIPRNet FED DMZ and SIPRNet REL DMZ.

Appendix I Consent to Monitor Agreement (Sample)

+++++++++++++++++++++++++ SAMPLE BEGINS HERE ++++++++++++++++++++++

<Date>

SUBJECT: Consent to Monitor for <CCSD, VPN ID, VRF Identifier, Cloud Service Offering name, or Cloud IT Project Name>

1.  IAW the requirements of Chairman Joint Chief of Staff Instruction (CJCSI) 6211.02D, Defense Information System Network (DISN) Responsibilities, 24 January 2012, and Unclassified Connection Approval Office Requirements, I acknowledge that the Defense Information Systems Agency will conduct periodic monitoring of the NIPRNet/IP Core/DATMS-U circuits.  I acknowledge and consent to DISA conducting initial and periodic unannounced vulnerability assessments on our connected host system to determine the security features in place to protect against unauthorized access or attack.

                                                                                    _______________________

                                                                                     Authorizing Official

+++++++++++++++++++++++++++SAMPLE ENDS HERE +++++++++++++++++++++++++++

The DISN customer must submit a signed CTM signed by the Authorizing Official to Defense Information Systems Agency via SNAP or SGS in order to obtain approval to connect to DISN. The CTM may be included within the ADD.

• Copy and paste the sample text above either into the ADD or onto Organization Letterhead.
• Be sure to provide the CCSD, VPN ID, Cloud Service Offering, or C-ITP names as appropriate.
• When complete, upload the CTM statement into the SNAP registration package.

Direct questions about the CTM to the DISN Connection Approval Office.

Appendix J Remote Compliance Monitoring

J.1. Vulnerability Scanning

The DISN Connection Approval Office (CAO) is the point of contact for requesting remote compliance scans.  There are three types of scan requests: 

• IATT scan required for new SIPRNet connection
• Ad Hoc requested by a customer

J.2. Scan Types

J.2.1. Perimeter Defense Test Scans

These scans test the connection’s perimeter defenses in order to assess the perimeter security devices ability to deny intrusion from an unknown source IP

• Performed from a scanning server which uses an unknown IP, to ascertain the defense in depth stance by simulating a probe from an unknown attacker
• The network enclave passes when the scan does not identify any devices within the internal network.  Should any devices be identifiable within the internal network, it will be considered a failure of the perimeter defense test
• DISA will forward results to POCs listed in SNAP/SGS or to stakeholder requesters in the event of a failed penetration test.

J.2.2. Vulnerability Compliance Scans

These scans are coordinated with the CCSD enclave owner to allow a known or “trusted” IP address to scan for vulnerabilities

The POC(s) listed in SNAP/SGS will coordinate with the Scan Team to establish the Access Control Lists on the network security devices in order to allow the IP Address to access the designated CCSD enclave.  A pass rating is attained when no RMF critical/very high/high vulnerabilities are found IAW current DoD STIGs and ACAS\NESSUS vulnerability assessment

Inspectors assign a “failed” rating when finding RMF critical/very high/high vulnerabilities or the vulnerability compliance scan cannot access the connection.  Inspectors will upload results into SNAP/SGS and send them to the POCs listed in SNAP/SGS or stake holder requesters’ for review and mitigation

J.3. Types of Scan Requests

J.3.1. IATT Scans

DISA RE41 initiates these scans for all new SIPRNet enclave connection requests.  The scan begins after the 72- hour burn in or when subsequently requested by the enclave owner.  IATT scans are required to complete the Connection Approval Process:

IATT scans are announced vulnerability compliance scan assessments

IATT Scans are a requirement for an ATC or IATC to SIPRNet

IATT scans are conducted the same as a Vulnerability Compliance Scan

DISA RE4 or DISA SE711 provides a report of results from the vulnerability scan to the SGS POCs on the details of all scan results, and therefore it is crucial for AOs’ and enclave owners to keep POC information in the SGS registration(s) current under their area of responsibility.

8 lists prerequisites for an initial SIPRNet IATT scan.

J.4. Follow-up after a Failed Scan 

Following a failed scan do the following:

For a failed perimeter defense scan, the enclave owner reviews and locks down the boundary protection systems as much as possible 

For a failed vulnerability compliance scan, review the RMF critical/very high/high vulnerability findings and fix/mitigate them 

The enclave owner contacts the Compliance Monitoring Team to schedule a re-scan after resolving issues

Appendix K VPN Registration (Private IP)

This Appendix supplements information provided in Section 2 of this guide with additional information on DISN VPN connection requirements. 

DISN VPN services provide an enterprise-wide solution to all DISN customers who need to segment their IP traffic from that of other customers.  NIPRNet offers these capabilities as transport-only services using Multi-Protocol Label Switching (MPLS) to create VPNs.  As such, the connection process differs slightly from that usually required for connection to NIPRNet/SIPRNet.  For VPN services, the VPN owner is required to register each VPN in the SNAP/SGS systems as described in Section 2.8 of this guide.  The VPN owner is responsible for ensuring that the appropriate Cybersecurity services, capabilities, and measures are in place on the system/network associated with the VPN.

DISN capabilities can be used to isolate Communities of Interest (COIs) as separate enclaves and segregate test traffic from the operational network using MPLS, VPN tunnels, approved Type I encryption devices, and/or other approved solutions as needed. 

For example, the DISN Test and Evaluation Service is hosted as a Layer 3 VPN (L3VPN) across the DISN IP core, providing IP transport-only service for test and evaluation (T&E) and test and development (T&D) COIs. 

U.S. Cyber Command (USCYBERCOM) distributed TASKORD 12-0371 instructing DoD Components to transition all Unrestricted and Restricted public facing applications into a DMZ Extension.  The NIPRNet Internet Access Point (IAP)-DMZ-VPN Community of Interest Network (COIN) improves security posture to protect DoD assets by isolating public facing Internet applications traffic flows from the NIPRNet flows. 

DoD Component network administrators who are responsible for providing the routing policy on the customer premise routers can use the Internet Access Point Demilitarized Zone Virtual Private Network Community of Interest Customer User’s Guide.  The guide supplements the VPN User Guides and Tutorials and provides additional information to assist customers in ordering the IAP-DMZ-VPN service via DSF and ensuring the DMZ extensions are compliant with the DoD Internet-NIPRNet DMZ Security Technical Implementation Guide (STIG) requirements.  For assistance with VPN services, contact the NIPRNet/VPN Service Manager or the DISA IGSD. 

The process for ordering and registering a VPN connection begins at Section 2.4 of this guide.  The DSF website has VPN Tutorials with instructions on how to establish a new VPN and for connection to an existing VPN.   However, fewer documents are required when a VPN Owner registers a new VPN in SNAP/SGS and when a VPN Member registers a VPN connection in SNAP/SGS.  The required documents are described in Section 2.8.3.3 of this guide.  The DISN CAO issues a Permission to Connect (PTC) for Level 3 VPNs.

Appendix L Points of Contact

n

Appendix M Validation Letter for Mission Partner Connections to DISN

DoDD 8000.1 defines a “Mission Partner” as - “Those with whom DoD cooperates to achieve national goals, such as other departments and agencies of the U.S. Government, State and local governments, allies, coalition members, host nations and other nations, multinational organizations, non-governmental organizations, and the private sector.”  DoDI 8010.01 paragraph 2.1.g states that DoD CIO reviews and approves DoD Component [sponsor] requests for mission partner connections to the DISN.

The DoD Component sponsor must submit a Validation Letter for Mission Partner Connections to DISN and a DoD Mission Partner Connection Briefing to request a new Mission Partner connection to DISN.  The DoD Component sponsor staffs the Validation Letter and briefing through the appropriate DISN Service Manager (NIPRNet/VPN Service Manager, or SIPRNet Service Manager) and the DoD Component CISO.[28]  The DoD Component sponsor then emails the validation letter endorsed by the DoD Component CISO and DISA Service Manager to the DoD CIO OPR for final approval. 

The DoD Component sponsor must submit a new validation letter for DoD CIO approval if any of the following significant changes occur:

The date of the DoD CIO Approval letter is past the stated expiration date in the DoD CIO Approval memo or more than 3 years past the last DoD CIO approval

A change in DoD Component sponsor

New Contract Vendor

Change of Location

Change in Mission

Change in topology that affects the cybersecurity posture/authorization of Mission Partner's enclave

This following is the only acceptable template for the Validation letter.  

Click here for a link to templates for the Validation Letter for Mission Partner Connections
to DISN and the DoD Mission Partner Connection Briefing

*****

Validation Letter for Mission Partner (Non-DoD) Connections to DISN (Template)

*****

                                                 Package #_________________

                                                                    [Provided by DISA]

COCOM/Service/Agency/Field Activity Letterhead                          

From: DoD organization sponsor                                     Date: DoD Sponsor Letter signed

Memorandum For:   Defense Information Systems Agency (Attn:  IE1, RE4)

{DoD Component CISO[29] [example:  Department of the Army, Chief Information Security Officer (Attn: Name]}

DoD CIO

SUBJECT: Mission Partner (Non-DoD) DISN Connection Validation for [Name of Mission Partner Entity] located at [City, State]

1.  OPERATIONAL REQUIREMENT: (Must answer all sections/questionnaires)

1. Operational need for connection:

i. State the DoD mission, program, or project to be supported by this connection 

ii. Describe specifically how the connection will support the DoD sponsor organization and contractor or other Mission Partner entity mission tasks

1. Classification/Type of work to be conducted by the contractor or other Mission Partner entity:

i. Specify Classified or Unclassified and/or level, e.g. (Unclassified//for official use only (U//FOUO) – Secret and Top Secret.

ii. Specify type whether command and control, research and development, modeling and simulation, etc. (Specific to Statement of Work (SOW)/Contract)

1. Frequency of use:  Describe how frequently the contractor or other Mission Partner entity will be required to use this connection in support of your DoD mission, program or project

2. MISSION PARTNERS/INFORMATION:

1. DoD Sponsor Unit:
2. DoD Sponsor: (name/title/UNCLASS e-mail/classified e-mail/phone number)
3. Mission Partner’s on-site Cybersecurity Individual responsible for this connection: (name/title/unclass e-mail/classified e-mail/phone number)
4. Cybersecurity Service Provider (CSSP):
5. DoD Sponsor Cybersecurity Representative for Combatant Command/Service/Agency/Field Activity (CC/S/A):
6. Mission Partner Entity/Contractor/Corporate name (no acronyms) including the complete connection location address (street, city, state):
7. Cage Code (if revalidating an existing connection, include the CCSD #):
8. Funding Source: Responsible funding Source (may or may not be a DoD Sponsor):
9. Contractor Info: Contract Number, expiration date, contracting officer name, and phone number
10. DoD Contractor Security FSO:

3. CONNECTION DETAILS:

1. Connection location addresses (Point of Presence):
2. Applications/Databases (What application and Database Connection is required): 
3. What Protocols are being utilized: (if applicable):
4. Specific IP/URL destination addresses: (if applicable):
5. Final Topology diagram and revalidation of connection/enclave:
6. The topology should annotate all devices and connections in the enclave to include routers, IA equipment (firewalls/IDS/etc.), servers/data storage devices/workstations/etc., all connections, to include enclave entry and exit connections, and security classification of environment

As the DoD Sponsor, I must ensure connectivity requirements are properly coordinated, periodic inspections are conducted, and adequate controls are in place in accordance with:

• DoDI 8010.01, Department Of Defense Information Network (DODIN) Transport, 10 September 2018
• DoDI 8510.01, Risk Management Framework (RMF) for DoD Information Technology (IT)
• DoD 5220.22-M, National Industrial Security Program Operating Manual (NISPOM) for connections between DoD and contractor information systems
• DoDI 8551.01, Ports, Protocols, and Services Management (PPSM)
• DoDI 8530.01, Cybersecurity Activities Support to DoD Information Network Operations
• CJCSI 6211.02D, Defense Information Systems Network (DISN) Responsibilities,
  24 January 2012
• DISN Connection Process Guide (https://public.cyber.mil/connect)
• DoD CIO Memorandum, Responsibilities of DoD Components Sponsoring Mission Partner Connections to DISN-Provided Transport Infrastructure, 14 August 2012

Signature      _______________________­­­­­

Print Name    _______________________

Agency         _______________________

Title/Rank     _______________________

(Signed by an O-6 or equivalent)

Attachments: 

1. {Sample of an IT Topology Diagram}
ILAP Domain Configuration @ ABCDEF Systems

2. {Request for Mission Partner Connection Briefing}

Identify equipment (e.g., LARSCOM Access T-1 XXX DSU/CSU; CISCO WC-1DSU-T1-V2-RF; Cisco 3600 Router; Cisco IDS 4210 Sensor, Cisco 4900 Catalyst Switch) and include all IP addresses, etc. Tunneling SIPRNET traffic through NIPRNET/Corporate network requires DSAWG review approval in accordance with CJCSI 6211.02D, Defense Information Systems Network (DISN) Responsibilities, 24 January 2012.)

------------------------------------------------------------------------------------------------------------------------------------------

I reviewed/discussed this connection request with the DoD Component/

Mission Partner‘s sponsor - Concur or non-concur.

1st Endorser                                           _________________________________          Date

SIGNATURE

  DISN Validation Official[30]

I have reviewed the DoD Sponsor’s request for [Mission Partner entity] to have a DISN connection.  Recommend DoD CIO approve this connection.

2nd Endorser                                _________________________________          Date

                                                                        SIGNATURE

                                                                          CC/S/A/FA Validation Official[31]

*************************************************************************************

The Template for the Mission Partner Validation Letter ends here.

Appendix N References

DISA is in the process of reorganizing the “disa.mil” web presence. DISA web pages listed in this Appendix may move to other locations such as “storefront.disa.mil” or “cyber.mil.” DISN CAO will post an Addendum to this Appendix on the Miscellaneous References web page. If you are denied access to a website listed in this Appendix, try a different CAC certificate. DoDI 8170.01 Disclaimer - The appearance of hyperlinks does not constitute endorsement by the Defense Information Systems Agency of non-U.S. Government sites or the information, products, or services contained therein. Although the Defense Information Systems Agency may or may not use these sites as additional distribution channels for Department of Defense information, it does not exercise editorial control over all of the information that you may find at these locations. Such hyperlinks are provided consistent with the stated purpose of this guide.

Appendix O Acronyms

Appendix P Glossary

Notes

Defense Information Systems Agency

Risk Adjudication and Connection (RE 4)

Post Office Box 549

Fort Meade, Maryland 20755-0549

https://cyber.mil/connect/connection-approval/

Footnotes

[1] Underlined text indicates a hyperlink to Appendix L – Points of Contact, Appendix N - References, Appendix P - Glossary.  To navigate the hyperlinks: Position your cursor over the hyperlink, press and hold the “CTRL” key on your keyboard, then click the  left-mouse-button.  To return to the text, press and hold the “ALT” key then press the left-arrow-key on the keyboard...

[2] DIA Directive (DIAD) 8550.500 documents the JWICS connection process.

[3] Mission Partner – “Those with whom DoD cooperates to achieve national goals, such as other departments and agencies of the U.S. Government, State and local governments, allies, coalition members, host nations and other nations, multinational organizations, non-governmental organizations, and the private sector.”  (DoDD 8000.01

[5] IAW DoDI 8510.01, “An ADD/ATO authorization decision must specify an ATD [Authorization Termination Date] that is within 3 years of the authorization date unless the IS or Platform Information Technology has a system-level continuous monitoring program compliant with DoD continuous monitoring policy as issued.”  However, “systems that have been evaluated as having a sufficiently robust system-level continuous monitoring program may operate under a continuous reauthorization.”  If an enclave or network does not have a sufficiently robust system-level continuous monitoring program, it must be reviewed annually and reauthorized once every 3 years.  In addition, the results of an annual review, or a significant change in the cybersecurity posture at any time, may also necessitate reassessment and reauthorization of a system.

[6] IATTs should be granted only when an operational environment with simulated-live data is required to complete specific test objectives (e.g., replicating certain operating conditions in the test environment is impractical), and should expire at the completion of testing (normally for a period of less than 90 days).   IATTs are limited in focus and may require additional security measures for the overarching protection of the DISN or DODIN. Operation of a system under an IATT is for testing purposes only (i.e., the system will not be used for operational purposes during the IATT period) IAW DoDI 8510.01.

[8] Executive Order on Transferring Responsibility for Background Investigations to the Department of Defense, April 24, 2019

[9] The IAPs are boundary protection gateways between the NIPRNet and the Internet.  IAW DoDI 8010.01 paragraph 3.2.d, all traffic between NIPRNet and the Internet must be through a controlled DISN IAP.

[10] Note CCMDS and other DoD Components are participating in the Joint Staff J6 Cyber Integration Workshop.  The goal is to develop a “Partner Nation Systems Connection Process Guide” that integrates DoD policy and procedures to provide warfighters a 4-phased approach using the Risk Management Framework (RMF) to assess, balance mission, cybersecurity risks, and requirements of foreign partner connections to the Department of Defense.

[11] The DISN CAO emails a “Permission to Connect (PTC)” for approved VPN connections.  Save this email, as it is proof of registration for turn- up of the VPN.

[12] For information about provisioning of DISN connections, see DSF and DISA Circular 310-130-001 Communications Requirements, Submission of Telecommunications Service Requests, 19 August 2009.  For information about the DISN billing process see the Defense Working Capital Fund Billing Prices for Fiscal Year 2020 Consolidated Services or contact the DoD Component’s DISN Billing Support Representative.  Billing for a NIPRNet or SIPRNet connection commences within 72 hours after connection delivery whether or not the customer has obtained an ATC/IATC required for connection activation.  To avoid wasteful connection charges, the customer should order the NIPRNet/SIPRNet access connection via DSF only if all required actions described in this guide (including A&A activities) will be completed within the expected connection delivery timelines shown in DISA Circular 310-130-1 (Tables T1.1 through T1.4).

[13] Currently there are no separate customer charges for logical connections (e.g., Multi-Protocol Label Switching (MPLS) VPNs)). 

[15]This version of the DCPG describes the process used by a DoD Mission Owner to register and connect a Cloud Information Technology Project (C-ITP) that is transitioning from a legacy data center environment to a virtual cloud computing environment.  There are ongoing efforts to update the Cloud registration and connection process to include Enterprise General Purpose Cloud computing services delivered under the recently awarded JEDI contract as well as basic use of Cloud computing services that require on-demand-self-service, rapid elasticity, and measured service as defined in NIST 800-145.  Registration and connection procedures for these Cloud services will be included in updates to this guide.

[16]Mission Owners planning to connect to an IL 4 or 5 CSO that uses commercial IP addresses:

· Contact your DoD Component Migration Office for guidance since your DoD Component may have established a VPN for the desired CSO, also DISA established a Cloud VPN Community of Interest (VPN ID: DKL30035)

· Submit a request for a VPN connection to the CSO IAW the process starting at Section 2.4 in this guide as supplemented with information in Appendix K, VPN Registration. In parallel with the VPN request, continue the process in Section C.3.2 for also requesting to use the CSO.

[17]Note:  A single C-ITP registration is sufficient for a family of applications that share the same DoD Component owner, the same Cloud Service Offering, the same Cloud Service Model (i.e., IaaS, PaaS, SaaS), and the same Impact Level.

[18] “Commercial cloud services hosting controlled unclassified information or non-publically releasable information outside of the Department’s security boundary must be connected to the Department of Defense Information Network (DODIN) through a Cloud Access Point that has been approved by the Information Security Risk Management Committee and the DoD CIO, in accordance with connection approvals in the Chairman of the Joint Chiefs of Staff Instruction 6211.02D.”--DoDI 5000.74, Defense Acquisition Services

[19] “Commercial cloud services used for Sensitive Data must be connected to customers through a Cloud Access Point (CAP) provided by DISA or through a CAP provided by another DoD Component.  All CAPs must be approved by DoD CIO.  The current Navy CAP is an example of an approved provisional cloud access point.  In the future, in order to standardize cyber defenses, our goal is that all DoD access to commercial cloud services be via a DISA provided CAP.”-- DoD CIO Memo, Updated Guidance on the Acquisition and Use of Commercial Cloud Computing Services.

[20] Commercial vendors are rapidly phasing out Low Speed Time Division Multiplexing (LSTDM) technologies reaching End of Life and End of Service support.  As a result, the DoD CIO Memo, Circuit Optimization directs efforts to terminate costly legacy network technologies and associated transport infrastructure circuits (e.g., TDM circuits) to align with JIE objectives by optimizing use of Ethernet and IP-based network infrastructure.  DoD CIO Memo, Legacy Networking Technologies tasks all DoD Components to eliminate all non-Internet Protocol network technologies by FY23.  .  Additionally, the DoD UC Master Plan (see section 5.d. (1) (h) and (i); Pg. 28, 29) states that, circuit switch-based services shall begin migrating to IP-based non-assured/assured services over DoD Component ASLAN Intranets and UC transport using products from the DoD UC APL.  Time Division Multiplexing (TDM)/IP hybrid technologies shall provide both converged and non-converged UC during this implementation timeframe.  The Voice-Over-Secure-IP, DVS, Standard Tactical Entry Point/Teleport, and deployable programs shall upgrade respective infrastructures using products from the DoD UC APL. 

DISA hosts quarterly TDM Technical Interchange Meetings to bring the DoD Communications Community together to discuss and exchange information relating to requirements for TDM elimination.  This includes approaches to migrating from TDM to IP-based solutions and meeting requirements in DoD CIO Memo, Legacy Networking Technologies.

Note that Quality of Service (QoS) is not a service but a required feature of DISA's MPLS transport that is applied to defined customers delivery of a service.  Currently, this feature is a manual process accomplished by DISA Engineers through customer engagement. As DISA evolves QoS and the ordering process, DISA will give MPLS customers the ability to specify QoS management requirements according to the customer wishes.  For assistance with MPLS QoS, contact the DISA MPEO. 

[21] PBX1 is a PBX with Multi-Level Precedents and Preemption (MLPP) capability needed for Command and Control applications.  PBX2 designates a PBX without MLPP capability.

[22] A copy of the Site Based Security Assessment (SBSA) Plan template is posted on the CDTAB website.

[23] Note:  Access CDS (e.g. Virtual Data Center, M-DRIVE) used to host multiple domains (e.g. via technologies like Virtualization) need to complete the P2P CDS Exemption Process.  Access CDS used directly by users to access two or more domains from a single workstation and MCI CDS do not have to complete the P2P CDS Exemption Process.  ...

[24] For information about the Cross Domain Risk Model (CDRM), see the Shared Documents folder on the CDTAB website.

[26] DoDI 8540.01, Enclosure 3, paragraph 4.a.(4)

[27] The community is defined as the transport, network management, and network segments of the DISN for the Department of Defense (DoD) Global Information Grid (GIG)

[29] The DoD Component Chief Information Security Officer (CISO) (Click here for the link to the DoD Component CISO List).  Organizations that do not have a DoD Component CISO listed must have the request validated by their DoD Component CIO or senior IT official. 

[31] The DoD Component Chief Information Security Officer (CISO) or designated representative is the “CC/S/A/FA Validation Official” and “2nd Endorser” for this validation letter.  (Click here for the link to the DoD Component CISO List).  Organizations that do not have a DoD Component CISO representative listed must have the request validated by their DoD Component CIO or senior IT official.

What type of declassification process is the review of classified information that has been exempted from automatic declassification?

What type of declassification process is the review of classified information?

What are the authorized places for storing classified information Select all that apply?

What information is listed in the Classification authority block on a document containing classified information quizlet?