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

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

For an approved Cloud Information Technology Project (C-ITP), the Mission Owner will upload the approval notification when registering the C-ITP in the SNAP Cloud C-ITP module as described in Section 2.8 of this guide.

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.

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

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.

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

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

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 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)

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

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.

(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

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. 

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.

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.

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

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

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)

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.

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.

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

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

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.

4. 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.
5. 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.
6. For a Minimal Community Impact CDS (non-VLOR) request: Determine if the criteria for a Minimal (Community) Impact CDS has been met.
7. 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.
8. 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 decide (or recommendation to DoD ISRMC) based on the following categories of CDS.

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 decide. 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 decide (or recommendation to the DoD ISRMC) regarding whether 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 decide regarding whether 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 decide (or recommendation to DoD ISRMC) whether 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 decide whether 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.

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 decide whether 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 decide whether 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)

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

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

6. 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.
7. ECDSP must provide Due Diligence to CDTAB/DSAWG/DoD ISRMC monthly or (as requested)
8. 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 are 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.

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 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 Environment as 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 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 +++++++++++++++++++++++++++

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 to assess the perimeter security device's 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 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 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

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

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

3. 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}

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

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

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

1^st 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.

2^nd Endorser                                _________________________________          Date

                                                                        SIGNATURE

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

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

The Template for the Mission Partner Validation Letter ends here.

Appendix N References

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/