Connection Process Guide Banner

CONNECTION PROCESS GUIDE APPENDICES

These DISN Service Appendices supplement the detailed information provided in the Mission Partner Connection Requirements of this guide. Any deviations from those steps and/or additional requirements for Non-DOD Mission Partners are identified in each appendix.

This appendix provides the necessary steps and information to process a Non-DoD Connection. It is intended to supplement the detailed information provided in Section 3.4 of this guide with Non-DoD Connection specific information. Any Variations from those steps or additional requirements are identified in this appendix.

Circuit Order Questionnaire A.1

Prior to a sponsor ordering a circuit, the below circuit order questionnaire/checklist should be used:

CIRCUIT ORDER QUESTIONAIRE

Cleared Contractor/Non-DoD SIPRNet Circuit Sponsors:

1. DoD Sponsor Unit:

DoD Sponsor POC (Name, NIPR e-mail, SIPR e-mail, Phone #):

Alternate DoD Sponsor POC (Name, NIPR e-mail, SIPR e-mail, Phone #)

2. Cleared Contractor/Non-DoD Location:

a. Facility CAGE Code:

b. Facility Clearance Level (must be at least Secret):

c. COMSEC Custodian:

d. SITE POC (Name, NIPR e-mail, SIPR e-mail, Phone #):

3. Please Answer the following:

a. Cybersecurity Service Provider (MOU/Service Agreement & Funds secured: YES or NO

b. State how Host Based Security System (HBSS) will be implemented (e.g. provided by sponsor or Cybersecurity Service Provider):

4. Please provide order dates for the following required equipment:

a. Crypto (e.g. KIV-7, HAIPE):

b. Perimeter Router (list make/model):

c. Firewall (list make/model):

d. Internal IDS/IPS (list make model):

5. Circuit Order Questionnaire are to be turned into the DISN Validation Official at: disa.meade.ns.mbx.siprnet-management-office@mail.mil

References and Helpful Links:

1. DISN Connection Process Guide (ref am)

2. Non-DoD Connection Process: http://www.disa.mil/Network-Services/Enterprise-Connections/Connection-Approval

3. DISN customer training; http://iase.disa.mil/connect

4. DISA Approved Products Listing (APL): https://aplits.disa.mil/processAPList.do

5. National Information Assurance Partner (NIAP) Evaluated Products (ref ak): https://www.niap-ccevs.org/CCEVS_Products/pcl.cfm?tech_name=ALL&CFID=17562266&CFTOKEN=d6d9fec5f6ead8d6-91AE90D6-FD36-EBE6-47E2D9D4D8217EB9

A.2  Complete and Submit Non-DoD Connection Request Letter

The sponsor may download the Non-DoD Connection Validation Letter from the DISA Connection Library at: http://disa.mil/network-services/enterprise-connections/references. An example is located in paragraph A.1 above. The sponsor sends the completed letter, with an attached conceptual network topology diagram, to the appropriate DISN Validation Officials. The purpose of the conceptual network topology diagram is to provide the DISN Validation Official enough information to determine if their network/service is appropriate for the customer’s mission. A detailed topology diagram is required in the CAP package.

A.3  DISN Validation Official Review

The DISN Validation Official reviews the Non-DoD Connection Validation Letter and network topology to determine the appropriate DISN solution.

A.3.1  Concurs with Solution 

If the DISN Validation Official concurs with the request, the DISN Validation Official will sign the letter as validator and return it to the validating CC/S/A.

A.3.2  Non-Concurs with Solution A.3.2

If the DISN Validation Official non-concurs with the proposed solution, the request will be returned to the sponsor with comment, or routed to another Validation Official (after notifying the sponsor) if a different network/service solution is more appropriate for the mission.

A.4  CC/S/A/ Review A.4

The CC/S/A will review the sponsor’s request letter and either validate or reject the request.

A.4.1  CC/S/A Validated Request

If the CC/S/A/ validates the request, the representative will sign the letter and submit it to the Cybersecurity Architecture and Engineering Office in the DoD CIO, Cybersecurity Directorate for DISN access approval (with a copy to the sponsor).

A.4.2  CC/S/A Rejected Request A.4.2

If the CC/S/A POC rejects the request, it will be returned to the sponsor without action (with a copy to the appropriate Validation Official) and the connection request process ends at this point.

A.5  DoD CIO Review A.5

Cybersecurity Architecture and Engineering Office in the DoD CIO, Cybersecurity Directorate will evaluate the connection request and either approve or deny access to the DISN in support of the sponsor’s mission.

A.5.1  Approved Request

If DoD CIO approves the request to access the DISN, the representative will sign and forward the request letter to the DoD sponsor (with a copy to the CC/S/A POC, DSS and DISN Validation Official).

A.5.2  Denied Request A.5.2

If DoD CIO does not approve the request, the representative will return the request letter to the DoD sponsor without action (with a copy to the CC/S/A POC and DISN validation official) and the connection, as proposed, will not be allowed.

This appendix provides the template for the Non-DoD DISN Connection Validation Letter. This is the only acceptable template for this letter. Once completed, submit the letter according to the instructions identified in the Customer Connection Process Section 3.

Note: A full validation is required for all new circuit requests and significant events to existing DoD CIO Validated requirements. Validation letters are staffed, approved, and validated through the CC/S/A HQ Element and sent to the DoD CIO for final approval. Validation/Revalidation letters remain in-effect indefinitely unless any of the following events occur, which will require a full validation through the DoD CIO:

  • New Sponsor
  • New Contract Vendor
  • Change of Location
  • Change in Mission 

Template begins below:

Package #

[Provided by DISA]

CCMD/Service/Agency/Field Activity Letterhead

From: DoD organization sponsor Date: DoD Sponsor Letter signed

Memorandum For: DISA/RE

Appointed Validation Official (2nd Endorser)

DoD CIO

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

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

a. Operational need for connection:

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

c. Describe specifically how the connection will support the DoD sponsor organization and contractor or other non-DoD entity mission tasks

d. Classification/Type of work to be conducted by the contractor or other non-DoD entity:

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

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

g.  Frequency of use: Describe how frequently the contractor or other non-DoD entity will be required to use this connection in support of the DoD mission, program or project

2. MISSION PARTNERS/INFORMATION:

a. DoD Sponsor Unit:

b. DoD Sponsor: (name/title/unclass e-mail/classified e-mail/phone number)

c. DoD Security Individual: (name/title/unclass e-mail/classified e-mail/phone number from the sponsoring organization that will be assuming responsibility for this circuit)

d. Cybersecurity Service Provider:

e. DoD Sponsor Cybersecurity/IA Representative for Combatant Command/Service/Agency/Field Activity (CC/S/A):

f. Non-DoD Entity/Contractor/Corporate (no acronyms) including the complete connection location address (street, city, state):

g. Cage Code

h. CCSD (if revalidating an existing connection)

i. Funding Source: Responsible funding Source (may or may not be a DoD Sponsor):

j. If Contractor Info: Contract Number, expiration date, contracting officer name, and phone number

k. Non-DoD Security DODIN Readiness and Security Inspections (DRSI):

3. CONNECTION DETAILS:

a. Connection location addresses (Point of Presence):

b. Applications/Databases (What application and Database Connection is required):

c. What Protocols are being utilized: (if applicable):

d. Specific IP/URL destination addresses: (if applicable):

e. Final Topology diagram and revalidation of connection/enclave:

f. The topology should annotate all devices and connections in the enclave to include routers, cybersecurity 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 8510.01, Risk Management Framework (RMF) for DoD Information Technology (IT) (ref d)

 DoD 5220.22-M, National Industrial Security Program Operating Manual (NISPOM) (ref s) for connections between DoD and contractor information systems

 DoDI 8551.01, Ports, Protocols, and Services Management (PPSM) (ref e)

 DoDI 8530.01, Cybersecurity Activities Support to DoD Information Network Operations (ref k)

 CJCSI 6211.02D, Defense Information Systems Network (DISN) Responsibilities (ref b)

 DISN Connection Process Guide (ref am)

DoD CIO Office Sponsor Memorandum (ref m)

Signature 

Print Name 

Agency

Title/Rank

(Signed by an O-6 or equivalent)

Template ends

Sample of an IT Topology Diagram

ILAP Domain Configuration @ ABCDEF Systems

Identify equipment (e.g., XXX DSU/CSU; CISCO WC-1DSU-T1-V2-RF; Cisco 3600 Router; Cisco IDS 4210 Sensor, Cisco 4900 Catalyst Switch) and include all IP address ranges, equipment make/model and software versions. Tunneling SIPRNet traffic through NIPRNet/Corporate network requires DSAWG review approval in accordance with CJCSI 6211.02D, Defense Information Systems Network (DISN) Responsibilities (ref b).

The letter must include signature pages below. All sections in red must be filled out by the Sponsor. Signatures will be obtained within the respective offices.

Template begins below:

1st Endorser Date

We have reviewed/discussed this connection request with the DoD Component/

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

DISN Validation Official

2nd Endorser (Appointed Validation Official) Date

We have reviewed the DoD Sponsor’s request for [Non-DoD Entity/Contractor] to have a DISN connection. Recommend DoD CIO approve this connection.

SIGNATURE

CC/S/A Validation Official

Template ends

This appendix provides the template for the Non-DoD DISN Connection Revalidation Letter. This is the only acceptable template for this letter. Once completed, submit the letter according to the instructions identified in Section 3.

A revalidation review is only required if there is a new contract with the same contract vendor/mission. Revalidations are not required for contractor option years or contract extensions.

Template begins below:

Package #

[provided by DISA]

Combatant Commands/Services/Agency’s Letterhead

From: DoD organization sponsor Date: DoD Sponsor Letter sign

Memorandum For DISA/RE

SUBJECT: Non-DoD DISN Connection Revalidation for [Name of Non-DoD Agency or Contractor] located at [City, State]

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

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

b. Describe specifically how the connection will support the DoD sponsor organization and contractor or agency mission tasks

c. State whether there has been any change to the mission, contract, location, or sponsor. Any one single change will require a full evaluation through DISA to the CC/S/A CIO to DoD CIO

[If revalidating an existing connection, do not short change this section. It must be completed in full detail]

d. Classification/Type of work to be conducted by the contractor or agency:

e. Specify Classified or Unclassified

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

g. Frequency of use: Describe how frequently the contractor or agency will be required to use this connection in support of the DoD mission, program or project

2. Mission Partners/INFORMATION:

a. DoD Sponsor Unit:

b. DoD Sponsor: (name/unclass e-mail/classified e-mail/phone number)

c. DoD Security Individual: (name/unclassified e-mail/classified e-mail/phone number from the sponsoring organization that will be assuming responsibility for this circuit)

d. Cybersecurity Service Provider

e. Non-DoD Agency/Contractor/Corporate (no acronyms) including the complete connection location address (street, city, state):

f. DoD Contract Name/Number/Expiration Date:

g. Cage Code:

h. CCSD #:

3. CONNECTION DETAILS:

a. Complete Connection location addresses (Point of Presence):

b. Applications/Databases (What application and Database Connection is required):

c. What Protocols are being utilized (if applicable):

d. Specific IP/URL destination addresses (if applicable):

e. Final Topology diagram and revalidation of connection/enclave:

f. The topology should annotate all devices and connections in the enclave to include routers, cybersecurity 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 8510.01, Risk Management Framework (RMF) for DoD Information Technology (IT) (ref d)

 DoD 5220.22-M, National Industrial Security Program Operating Manual (NISPOM) (ref s) for connections between DoD and contractor information systems

 DoDI 8551.01, Ports, Protocols, and Services Management (PPSM) (ref e)

 DoDI 8530.01, Cybersecurity Activities Support to DoD Information Network Operations (ref k)

 CJCSI 6211.02D, Defense Information Systems Network (DISN) Responsibilities (ref b)

 DISN Connection Process Guide; http://www.disa.mil/~/media/Files/DISA/Services/DISN-Connect/References/DISN_CPG.pdf

DoD CIO Office Sponsor Memorandum (ref m)

Signature 

Print Name

Agency

Title/Rank

(Signed by an O-6 or equivalent)

Template Ends

Endorsement:

Note: Page break to remain between the main body and Endorsement template below. All information in red below is to be completed. The completed document is to be e-mailed back to: disa.meade.ns.mbx.siprnet-managment-office@mail.mil 

1. The DISA IE 11 Division has reviewed the supporting documentation for this request and acknowledges SIPRNet is still the appropriate DISN solution for CCSD XXX in support of Non-DoD agency located at City, State to the classified DoD enclave SIPRNet through the end of the contract or end of the ATO, whichever comes first.

2. A revalidation review is required on a reauthorization connection when the DoD CIO approval has expired. In the event any one item changes, a full DoD CIO revalidation will be required.

The DoD sponsor must also ensure connectivity requirements are properly coordinated, periodic inspections are conducted, and adequate controls are in place IAW:

 DoDI 8510.01, Risk Management Framework (RMF) for DoD Information Technology (IT) (ref d)

 DoD 5220.22-M, National Industrial Security Program Operating Manual (NISPOM (ref s) for connections between DoD and contractor information systems

 DoDI 8551.01, Ports, Protocols, and Services Management (PPSM) (ref e)

 DoDI 8530.01, Cybersecurity Activities Support to DoD Information network Operations (ref k)

 CJCSI 6211.02D, Defense Information Systems Network (DISN) Responsibilities (ref b)

 DISN Connection Process Guide (ref am)

DoD policy requires that partners register their IS information in the DoD Information Technology Portfolio Repository (DITPR) at: https://ditpr.dod.mil. An enclave/network may also be registered in the SIPRNet IT Registry, by first requesting an account to the application at https://arm.osd.smil.mil.

Note: A customer with an account can access the SIPR IT Registry at: http://osdext.osd.smil.mil/sites/dodcio/itregistry/default.aspx 

Failure to comply with the conditions of this endorsement could result in a recommendation for immediate termination of the connection.

For additional information contact the DCCC at: (844) 347-2457, Option 2; CML: (614) 692-0032, Option 2; DSN: (312) 850-0032, Option 2; disa.dccc@mail.mi; disa.scott.conus.mbx.dccc@mail.smil.mil.

DISN Validation Official

D.1 Vulnerability Scanning

The Defense Information Systems Agency Risk Adjudication and Connection Division performs remote compliance scanning for all new DISN connections, for reauthorized connections, and on a on a case-by-case basis when requested for DISN connected enclave owners. RE 4 provides vulnerability scan result letters to the SGS POCs on the details of all scan results, and therefore it is crucial for AOs’ and enclave owners to keep their information in SGS current. All RE 4 scans are currently uncredentialed.

D.1.1 Scan Types

  • Unannounced scans, test the CCSD’s circuit perimeter with penetration tools in order to assess its ability to deny intrusion from an unknown source
  • Announced scans are coordinated with the CCSD owner to allow a known or "trusted" IP address to scan for vulnerabilities
  • Interim Authority To Test (IATT) scans complete the Connection Approval Process for all new connection requests by conducting a vulnerability assessment (similar to an Announced scan)
  • Ad Hoc scans are requested by customer organizations and can be either a perimeter defense scan and/or vulnerability assessment

D.1.2 Unabnnounced Scan

  • Performed from a server which uses an unknown IP, to ascertain the defense in depth stance by simulating a probe from an unknown attacker
  • A pass rating is attained when none of the devices on the inside of the network can be identified. Should any devices be identifiable within the internal network, it will be considered a failure of the perimeter’s defense
  • Only in the event of a failed penetration test will the results be forwarded to the POCs listed in SGS. Otherwise, a vulnerability scan (Announced) will commence

D.1.3 Announced Scan

  • After a site passes the Unannounced scan, the Announced Scan portion is conducted
  • The POC(s) listed in SGS will coordinate with the Scan Team for the IP Address to permit access to the CCSD. A passed rating is attained when no RMF critical/very high/high vulnerabilities, or DIACAP Category (CAT) I vulnerabilities are found IAW current STIGs
  • A failed rating is assigned when RMF critical/very high/high vulnerabilities, or DIACAP Category (CAT) I vulnerabilities are found, or the announced scan was unable to access the circuit. Results will be uploaded into SGS and sent to the POCs listed in SGS for review and mitigation

D.1.4 IATT Scan

  • IATT Scans are performed on all new SIPR circuit requests as a requirement for an Authority to Connect/Interim Authority to Connect (ATC/IATC)
  • IATT scans are conducted the same as an Announced Scan
  • Please reference the IATT Process Checklist below

D.1.5 Ad Hoc Scan

  • Ad Hoc scans are conducted on request, usually as a rescan to confirm remediation of initial failed scans. Sites that fail any type of scan may request a rescan
  • (A rescan for a failed Announced Scan would not be subject to an Unannounced scan)
  • The requirements for pass/fail remain the same as the original scan
  • An Ad Hoc Scan typically takes up to 8 business days to complete, but may require more time depending on network size

D.1.6 Cyber Hygiene Analysis (CHA)

The overall objective of the Cyber Hygiene Analysis (CHA) is to aid enclave owners in their ability to improve their respective cybersecurity posture. The Risk Adjudication and Connection Division’s CHA efforts are focused in three areas: assisting enclave owners and DISA DODIN Readiness and Security Inspections (DRSI/RS) in preparing for or conducting Command Cyber Readiness Inspections (CCRIs), fulfilling individual AO (formerly DAA) CHA requests, and performing CHAs in support of requesting enclaves on the DODIN.

The CHA capability combines results of passive DISN backbone sensors and active tools,7 which when employed effectively, can present a more holistic and accurate picture of the health of a perspective enclave. In particular, CHA analysts look for evidence of compliance with DoDI 8551.01, Ports, Protocols, and Services Management (ref e) requirements, proper boundary configurations, Operational System (OS) fingerprinting, vulnerability analysis, and evidence of proper CDS configuration. Effectively using this expanded CHA information will potentially allow the Compliance Monitoring Team (CMT) to provide perspective enclave owners a more in depth and accurate input to better prepare for upcoming CCRIs, cross validate Continuous Monitoring and Risk Scoring (CMRS) results, and assist enclave owners in improving their own effective cybersecurity decisions. In addition to CHAs providing useful vulnerability information in preparation for CCRIs, CHAs may also provide valuable CCRI follow-on analysis information. Ultimately, the CHA effort is designed to help, not penalize, DoD and its mission partners to improve the overall cybersecurity of the DODIN. If interested in participating in the CHA, please contact the CMT POC found in paragraph E3 below.

D.2 Frequently Asked Questions (FAQs)

Q: I received results from a scan, but some of the recipients no longer work for/with my site. What do I need to do to get this changed?

A: When the POCs or site information for the CCSD change, please log on the SGS database at https://giap.disa.smil.mil/gcap/home.cfm and update the POCs for the perspective CCSD.

Q: I received a failed Unannounced/Announced IATT scan. What steps do I need to take now?

A: For Unannounced scans, review the boundary protection systems to ensure they are locked down as much as possible. For Announced scans, review the RMF critical/very high/high findings or DIACAP Category (CAT) I findings and fix/mitigate them. Once these items have been addressed, contact the CAO CMT to schedule an Ad Hoc scan.

D.3 IATT Process Checklist

Steps To be Completed PRIOR to an Initial Scan for ATC/IATC Issuance: 

Equipment installed, configured, and turned on. 
72 hour burn-in completed by IT&A. 
At least one (1) server, workstation, or laptop with at least one (1) port, protocol or service enabled. (Please refer to PPSM for allowed ports and protocols dod.ppsm@mail.mil.
HBSS disabled for initial scan or Compliance Monitoring Team (CMT) "Announced" IP Address added to the HBSS allowed IP's. 
Windows firewall disabled for the target system(s) initial scan.

Compliance Monitoring Team (CMT) Contact Information 

NIPR Scan E-mail  disa.meade.re.mbx.caoscans@mail.mil 
SIPR Scan E-mail  disa.meade.re.mbx.caoscans@mail.smil.mil 
Phone (Commercial)  301-225-2902 
Phone (DSN)  312-375-2902 

Implementation Test and Activation (IT&A) Contact Information 

Phone (Commercial)  618-220-8627 

DISN Customer Contact Center (DCCC) 

Unclassified E-mail  disa.dccc@mail.mil 
Classified E-mail  disa.scott.conus.mbx.dccc@mail.smil.mil
Phone (Commercial)  844-347-2457, Option 2 or 614-692-0032, Option 2 
Phone (DSN)  312-850-0032, Option 2 

This appendix provides the necessary steps and information to process a Defense Switched Network (DSN) telecommunication switch and Unified Capabilities (UC) product connection to the DISN provided transport (including data, voice and video). This appendix is intended to supplement the detailed information provided in Section 3.6 of this guide with DSN unclassified voice switch specific information. Any variations from those steps or additional requirements are identified in this appendix.

E.1 DSN Connection Process

Follow steps in the Customer Connection Process (Section 3) of this guide.

E.2 Process Variations and/or Additional Requirements

All DSN telecommunication switches and UC Products that connect to the DISN provided transport, to include data, voice and video, must be registered in SNAP to include the upload of the RMF/DIACAP executive package artifacts in order to obtain connection approval in accordance with CJCSI 6211.02D (ref b).

Connection of a DSN telecommunication switch or UC product to the DISN requires procurement of interfacing hardware and/or software components that are identified on the DoD UC Approved Products List (APL). All items on the UC APL are required to be certified for interoperability and cybersecurity in accordance with DoDI 8100.04, Unified Capabilities (ref g). If the intended product is not on the UC APL, it will either need to be JITC Interoperability IO and cybersecurity/IA tested and certified and placed on the UC APL, or authorized for purchase via DoD CIO temporary exception to policy before the product can be purchased and connected to the DISN in accordance with DoDI 8100.04, Unified Capabilities (ref g).

For information on UC APL products and the UC APL process for getting equipment added to that list, refer to the links below:

Criteria for determining connection approval requirement of an UC APL approved DSN telecommunication switch and/or UC product connected to the DISN:

  • Voice softswitches connected to the DISN shall be registered in SNAP DSN and obtain connection approval. (i.e., Local Session Controller (LSC), SoftSwitch (SS), Enterprise Session Controller (ESC))
Note: IAW DoD Unified Capabilities Master Plan (UC MP); Section 5.d. (1) (h) and (i); Pg. 28, 29 (ref u). 

Circuit switched based services shall begin migrating to IP-based non-assured/assured services over DoD Component Assured Services Local Area Networks (ASLANs)/Intranets and UC transport using products from the DoD UC APL. During this implementation timeframe, both converged and non-converged UC shall be provided by Time Division Multiplexing (TDM)/Internet Protocol (IP) hybrid technologies.8 The Voice over Secure Internet Protocol (VoSIP), Digital Video Services (DVS), Standard Tactical Entry Point (STEP)/Teleport, and deployable programs shall upgrade respective infrastructures using products from the DoD UC APL. The phase out of circuit-switched technologies shall be based on the following individual conditions:

  • New TDM Circuit Switched Products. New TDM circuit switched products shall no longer be tested and certified for placement on the UC APL as of January 2011.
  • Existing UC APL Circuit Switched Products. Existing circuit switched products on the UC APL may be purchased until certification/assessment expires and removed from the APL.
  • Installed UC Circuit Switched Products. Existing circuit switched products already installed, UC APL products procured before the UC APL expiration date, or on the Retired UC APL List may remain until business case or mission need dictates replacement, or vendor is no longer willing to support. Continued testing and certification for software patches is allowed for these components while in use, however this testing and certification/assessment shall not result in renewed UC APL status.
Note: DoD CIO is leading efforts to terminate costly legacy network technologies and associated transport circuits (e.g., TDM circuits) to align with Joint Information Environment (JIE) objectives by optimizing use of IP based network infrastructure. Legacy circuits should transition to existing IP bandwidth at DISN Subscriber Service (DSS) locations, or to a readily available commercial IP network at non-DSS locations. Continued use of TDM and other legacy circuits should only be used as a last resort. (ref ah) 

DISA shall deploy SoftSwitch (SS), allowing DoD Components to implement UC employing IP while maintaining backward interoperability with the remaining circuit-switch/TDM technologies. DISA’s enterprise voice and video services, with collaboration capabilities (Instant Messaging (IM), presence, and chat), shall be evaluated during UC Pilot Spiral 2 and shall begin operations in select geographic regions during this timeframe.

  • VoIP capable softswitches that are configured to function as a Private Branch Exchange (PBX1) and connected behind the local user’s installation DSN End Office (EO)/Small End Office (SMEO) do not require a SNAP registration or connection approval; unless, directed as a MAJCOM, CCMD or Theater Command requirement. The PBX1 voice switch shall be identified on the customer’s host installation enclave topology for the associated DSN EO/SMEO voice switch RMF/DIACAP package
  • All TDM/DSN voice switches connected to the DSN as a servicing voice switch in accordance with CJCI 6211.02D (ref b) will be registered in SNAP DSN and obtain connection approval
  • ALL TDM/DSN voice switches connected behind the local user’s installation DSN EO/SMEO do not require a SNAP registration or connection approval; unless; directed as a MAJCOM, CCMD or Theater Command requirement (e.g., PBX1, PBX2, Network Element (NE) SHOUTS, Remote Switching Unit (RSU)). These type of switches will be identified and depict the interconnection to the host installation DSN EO/SMEO in the enclave topology diagram
  • ALL TDM/DSN voice switches that connect via a tandem/nodal connection to the Multifunction Switch (MFS) will be registered in SNAP and obtain a DoD CIO temporary exception to policy in accordance with DoDI 8100.04 (ref g) or have a completed Tailored Internet Service Provider (ISP) for connection approval (e.g., PBX1, NE-SHOUTS, Switch Multiplex Unit (SMU), Inverse Multiplexer (IMUX))
  • 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 and obtain connection approval, if they have not previously obtained formal connection approval
  • Customers requesting connection approval for a legacy switch that has fallen off the UC End of Sale list must register the voice switch in SNAP DSN and obtain a DoD CIO temporary exception to policy
  • Customers that procure a legacy voice switch that is on the UC APL End of Sale list are required to register the voice switch in SNAP DSN and obtain a DoD CIO temporary exception to policy
  • PBX2 switches can only be procured or implemented after obtaining a DoD CIO temporary exception to policy waiver for Military Unique Feature (MUF) requirements by the DoD CIO’s office in accordance with DoDI 8100.04, Unified Capabilities (ref g).

E.3 DSN CONNECTION PROCESS CHECKLIST

This checklist provides the key activities that must be performed by the Mission Partner/sponsor during the DSN connection approval process:

Item  DoD Component  Mission Partner 
  New  Existing  New  Existing 
Obtain DoD CIO approval for Non-DoD connection     

*

Obtain APL approval for voice equipment not currently on the APL list 

X

 

X

 
Provision the connection 

X

 

X

*

Perform the A&A process 

X

X

X

X

Obtain an Authorization to Operate (ATO) 

X

X

X

X

Register the connection 

X

**

X

*

Register in the SNAP database 

X

**

X

*

Register in the PPSM database 

X

** 

X

*

Register in the DITPR database 

X

**

X

*

Complete the CAP Package 

X

X

X

X

DIACAP Executive Package/RMF Security Authorization Package (or equivalent) 

X

X

X

X

DIACAP Scorecard/RMF Security Assessment Report 

X

X

X

X

System Identification Profile (include switching equipment - i.e., vendor model and software)/System's Security Plan 

X

X

X

X

Plan of Actions and Milestones, if applicable 

X

X

X

X

AO Appointment current in database 

X

X

X

X

Network/Enclave Topology Diagram 

X

X

X

X

Consent to Monitor 

X

X

X

X

Proof of Contract     

X

X

DoD CIO Approval Letter     

X

X

Complete ATC Submittal form (see 1.4) 

X

X

X

Submit the CAP Package to the CAO 

X

X

X

X

Receive DSN ATC/IATC 

X

X

X

* - This step is not required for existing mission partner connections unless there has been a change in Sponsor, mission requirement, contract, location, or the connection has not been registered.

** - This step is not required for existing connections that are already registered and where all information is current.

E.4 Points of Contact

Unified Capabilities Certification Office (UCCO) 

Unclassified E-mail 

disa.meade.ns.list.unified-capabilities-certification-office@mail.mil

Connection Approval Office (CAO) 

Connection Approval Office for DSN Connections 

disa.meade.re.mbx.ucao@mail.mil

disa.meade.re.mbx.ucao@mail.smil.mil 

Phone (Commercial)  301-225-2900, 301-225-2901 
Phone (DSN)  312-375-2900, 312-375-2901 
Address 

Defense Information Systems Agency

ATTN: RE41

PO Box 549

Fort Meade, MD 20755-0549 

E.5 Topology Diagram Requirements

Network Topology Diagram/SDD – this diagram depicts the network topology and security posture of the customer enclave that will be connecting to the DISN.

The Network Topology Diagram should:

  • Be dated
  • Clearly delineate authorization boundaries
  • Identify the CCSDs of all connections to the DISN
  • Identify equipment inventory (to include the most recent configuration including any enclave boundary firewalls, Intrusion Detection Systems (IDS), premise router, routers, switches, backside connections, Internet Protocol (IP) addresses, encryption devices, Cross Domain Solutions (CDS)
  • Other SIPRNet connections (access points) must be shown; the flow of information to, from, and through all connections, host IP addresses, and CCSD number, if known must be shown
  • Identify any other cybersecurity or cybersecurity-enabled products deployed in the enclave
  • Identify any connections to other systems/networks
  • Identification of other connected enclaves must include:
  • o The name of the organization that owns the IS/enclave
  • o The connection type (e.g., wireless, dedicated point-to-point, etc.)
  • o IP addresses for all devices within the enclave
  • o The organization type (e.g., DoD, federal agency, contractor, etc.)
  • Identify Internetworking Operating System (IOS) version
  • Include the model number(s) and IP’s of the devices on the diagram; diagram must show actual and planned interfaces to internal and external LANs or WANs (including backside connections)
Note: It is important to note that in accordance with DoD and DISA guidance, firewalls, IDSs and Wireless-IDS (where applicable) are required on all partner enclaves. Private IP addresses (non-routable) are not permitted on SIPRNet enclaves. Indicate and label all of the devices, features, or information; minimum diagram size: 8.5" X 11". 

All TDM/IP DSN topologies must include:

  • Topology date
  • Function, vendor, model, and software version of the voice switch (preferably near the voice switch)
  • All Customer Provider Edge (CPE) or Terminating type equipment used behind the voice switch (Analog, Digital, VoIP, Video Tele-Conference (VTC), 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 (ISDN), etc...)
  • VTC and Network Elements (NE) as applicable

Addendum for voice switches connecting to ASLAN or Assured Services Virtual Local Area Network (ASVLAN):

  • 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 (CER)

Addendum for voice softswitch and Enterprise Session Controller connections to the DISN:

  • Depict the function and location of the source softswitch 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 SBC)
  • Depict NIPRNet CCSD(s) providing the Ethernet/IP connection within the enclave (preferably near the CER)
  • Select connection type "backbone" if the softswitch or Enterprise Session Controller is managed by DISA and provides UC services for multiple DoD and mission partners.

E.6 SNAP DSN Switch Registration and RMF/DIACAP Submittal Process:

  • Create SNAP DSN profile: https://snap.dod.mil/gcap/request-account.cfm
  • Upload of the completed DD Form 2875 System Authorization Access Request (SAAR). The 2875 can be downloaded from the SNAP website
  • Complete the profile data; asterisked items are required fields
  • Submit the account for approval

Once the account is approved, proceed with the creation/registration of the voice switch to include the submittal/upload of the RMF/DIACAP executive package artifacts once the local RMF A&A/DIACAP C&A is completed:

  • Logon to SNAP DSN: https://snap.dod.mil/gcap/home.cfm
  • Hover the mouse over :Defense Switched Network" and select "New Registration"
  • Complete all sections (e.g., Sections 0-10) and required fields identified by an asterisks
  • Upload Attachments for the RMF/DIACAP executive package artifacts in Section 11.1 through 11.12
Note: Only Sections 11.1 through 11.5 require the upload of the respective attachment; thus, Sections 11.6 through 11.2 do not require attachment upload of document (s) in order to complete the registration. 
  • Once all sections are completed, with the exception of Section 10 and Section 11.12; A Submit button at the bottom of the screen will be available in order to submit the entire registration for "Validator Approval"
  • SNAP DSN Validator Role
  • The SNAP DSN validator reviews the contents of all submitted connection requests within his or her agency or sub-agency and either approves or rejects the registration based on conformity, completeness, and correctness
  • If the validator rejects a request, the reason is captured in the comment and the POCs identified in the registration are notified via an automated e-mail. The requestor or one of the POCs in the registration must update and complete the rejected sections and resubmit the registration

Once all individual applicable sections of the registration are approved, the validator may "Validate Approve" the entire registration for the next step of the approval process, CAO review. The validator may also reject the request even though all sections of the request are approved.

Note: For 24/7 SNAP assistance; contact DCCC at 844-347-2457. 

E.7 Sample Topology Diagram

Sample DSN Topology

E.8 Example Installation Configuration

Example Installation Configurations

DISN VPN services provide an enterprise-wide solution to all DISN customers who need to segment their IP traffic from that of other customers using MPLS to create VPNs. These services are offered as capabilities provided on the Sensitive but Unclassified (SBU) data network and are transport services only. As such, the connection process differs slightly from that usually required for connection to NIPRNet/SIPRNet. For VPN services, the customer is required to register each VPN and connections to the VPN are tracked in the SNAP/SGS database. The customer is responsible for ensuring that the appropriate Cybersecurity services, capabilities and measures are in place on the system/network associated with the VPN.

The DISN Test and Evaluation Service (DTES) is hosted as a Layer 3 VPN (L3VPN) across the DISN Internet Protocol (IP) core, providing IP transport-only service for test and evaluation (T&E) and test and development (T&D) Communities of Interest (COIs). VPN solutions isolate COIs as separate enclaves and segregate test traffic from the operational network using Multi-Protocol Label Switching (MPLS), VPN tunnels, network encryption, approved Type I encryption devices, and/or other approved solutions as needed.

USCYBERCOM) distributed TASKORD 12-0371 instructing all CCSAs to transition all Unrestricted and Restricted public facing applications into a DMZ Extension. The NIPRNet Internet Access Point (IAP) Demilitarized Zone (DMZ) Virtual Private Network (VPN) Community of Interest Network (COIN) (IAP DMZ VPN) is designed to improve security posture to protect DoD assets by isolating public facing Internet applications traffic flows from the NIPRNet flows. CCSAs network administrators who are responsible for providing the routing policy on the customer premise routers will use the "Internet Access Point Demilitarized Zone Virtual Private Network Community of Interest Customer User’s Guide" which supplements the VPN Customer Ordering Guide 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 NIPRNet DoD DMZ Security Technical Implementation Guidance (STIG) requirements.

The VPN customer guides are located in the ‘Policy User Guide’ modules of the SNAP and SGS databases.

https://snap.dod.mil/gcap/user-guide.do

https://giap.disa.smil.mil/gcap/user-guide.do

For assistance contact the DISN Customer Contact Center (DCCC).

DISN Customer Contact Center (DCCC) 

Unclassified E-mail  disa.dccc@mail.mil 
Classified E-mail  disa.scott.conus.mbx.dccc@mail.smil.mil
Phone (Commercial)  844-347-2457, Option 2 or 614-692-0032, Option 2 
Phone (DSN)  312-850-0032, Option 2 

The DoD CIO is revising the DODIN Waiver Process. Please contact osd.pentagon.dod-cio.mbx.dcio-cs-ae@mail.mil for further information.

G.1 Point of Contact

POC For the DoD CIO Temporary Exception to Policy Process 

DoD CIO, Security Architect/Engineer  osd.pentagon.dod-cio.mbx.dcio-cs-ae@mail.mil 

H.1 Cross Domain Solution: Definition

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. (ref ad)

H.2 DoD CDS Approval Process Scope, Applicability and Exclusions

The DoD CDS process covers CDSs connecting to networks classified Top Secret (TS) and below, including standalone, isolated, and test networks. This includes Intelligence Community (IC)-owned CDSs which connect to DoD networks (but not to TS-SCI). CDS devices connecting to networks classified TS – Sensitive Compartmented Information (SCI) and above follow different approval processes as determined by DNI policy and guidance.

This process is separate from the review and approval of the ATC for the Command Communications Service Designators (CCSD). However, a Cross Domain Solution Authorization (CDSA) will not be issued beyond the connection approval date granted for the enclave in which it resides. This appendix provides the steps necessary to obtain a CDSA which is the official document authorizing operational use of a Cross Domain (CD) device per DoDI 8540.01 3.g "It is DoD Policy that the DoD level risk decision on use of a CDS to access or transfer information between different interconnected security domains must be made by the designated DoD risk executive as a CDS authorization (CDSA) in accordance with this instruction."

H.3 Categories of Cross Domain Solutions

The two main categories of CDSs are Point to Point CDSs and Enterprise Cross Domain Solutions (ECDS). A Point to Point Solution is purchased, implemented and managed by a component within the authorization boundary of the components own network. An Enterprise Solution is centrally managed and provides CD Services to multiple components.

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

1. Point to Point CDSs:

a. Standard Point to Point

i. Includes access, transfer and multi-level solutions

b. For Tracking Purposes Only (FTPO) CDS: Four Cases of Transfer CDSs:

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

ii. Controlled Interfaces of Interest: The CDS is connected to two networks of the same security classification which 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 (VLoR assertions) (ref aa) and VLoR Implementation Guide (ref z) is a transfer CDS architecture/system which implies that the low side system(s) provide very minimal threat to the high side network and the solution and its connected enclaves present minimal risk to the High side enclave(s). VLoR 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 which forward network traffic into a closed collection enclave for analysis. In such cases the CDSE and CDTAB 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.

2. Enterprise Cross Domain Solutions

a. ECDS Candidate:

i. This term refers to a component with CDS requirements in negotiation with a CDS Enterprise Service Provider which will be brought through the CDS Phase 1 just as any other point-to-point CDS. Once ECDS implementation is approved at the DSAWG in Phase 1 the DSAWG Secretariat will close the original CDS Request in SGS. The requirement will be implemented on an ECDS System under an ECDS Ticket number

b. ECDS CDS System Ticket or Request

i. An ECDS System Ticket or Request is a CDS which represents a centrally managed service which supports multiple components

3. IC Owned Cross Domain Solutions

a. This is a cross domain solution which is owned, approved, and managed by an intelligence agency. Only IC devices connecting to DoD networks that do not also connect to a TS-SCI network are referenced in this connection process guide for visibility and reciprocity purposes

The CDS Authorization process for all categories except the IC CDS Registration process is included in section H.4. The IC CDS Registration Process is described in Section H.10.

H.4 CDS Authorization Process

The CDS Authorization Process consists of four distinct phases, however depending on the classification of CDS as described in Section H.3 some of the phases may be compressed. The figures below cross reference the different RMF steps to the various CDS phases and provide greater detail for each of the phases. The four phases are:

  • Phase 1: CDS Categorization and Operational Impact Determination
  • Phase 2: CDS Engineering, Security Control Selection and Security Control Implementation
  • Phase 3: CDS Security Control Assessment & Authorization
  • Phase 4: Operational CDS Monitoring

RMF Lifecycle

CDS Categorization and Criticality Determination

H.5 Phase 1: CDS Categorization and Criticality Determination

Phase 1 of the CDS process consists of five specific actions. Any exceptions to the CDS process must be coordinated with the Cross Domain Support Element (CDSE) and Cross Domain Technical Advisory Board (CDTAB) Charter (ref ac) Chair.

1. The CDS component must coordinate with their respective CDSE representatives to determine and document the information transfer and mission requirements. If uncertain about whom the respective CDSE is, would like information on standing up a CDSE, or would like to utilize the services of another CDSE, please review 8540.01 Enclosure 5 CD and RMF Roles paragraph 4. CDSE (ref ad).

Note: Per DoDI 8540.01 Enclosure 5.4.g. "Support to Combatant Commands will be in accordance with DoDD 5100.03." Support of the Headquarters of Combatant and Subordinate Joint Commands" (ref ad)   

a. DoD component’s respective CDSE obtains access to SGS, opens a new CDS request filling out all required database fields, and uploads all required documents as stated in item c below.

b. Access to the SGS database: To obtain access to the SGS database CDSEs go to https://giap.disa.smil.mil and select "request an account." The CDSE will be required to upload a completed DD2875. A template is provided on the entry page of the website.

c. Phase 1 Documentation Requirements: (must be uploaded in SGS)

i. Validation Memorandum, Authorization Official O-6 or civilian equivalent signature required

ii. Cross Domain Appendix with Section 1.0 Completed, Designated Command Representative signature required in phase 1

iii. DISA Cross Domain Enterprise Service Response Memorandum

 This will be provided by DISA Cross Domain Enterprise Services (CDES) once the component submits a CDES Questionnaire to DISA CDES.

 A CDES Memorandum is not required if the CDS Configuration meets a requirement specifically called out in the CDES Non-Consideration Memorandum or if the DSAWG or DoD ISRMC have designated the requestor as a mission specific enterprise service.

iv. VLoR Additional Phase 1 Requirements:

 CD Appendix (CDA) Section 2.0 Completed (Section 2.1 not required)

 Site Based Security Assessment (SBSA) Plan (detailed procedures not required)

 VLoR Assertions Response Completed

d. Repeatable Accreditation/Authorization Additional Phase 1 Requirements:

i. Repeatable CDS Entrance Criteria Checklist (ref af)

ii. Planned Repeatable Inventory Template

iii. The requirement for Repeatable Accreditation/Authorization should also be documented within section 1.0 of the CDA

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

2. The DoD mission partner’s respective CDSE validates and prioritizes the request by completing the SGS Validation Section including the Validation and Operational Impact Determination sections 6.3 and 6.5 for the respective request and submits an agenda request form (ref aj) to the DSAWG Secretariat. All agenda requests must be submitted by the respective CDSE to the DSAWG Secretariat 14 calendar days prior to the next CDTAB meeting. Agenda requests will not be accepted by the DSAWG Secretariat directly from the Component. The DSAWG Secretariat will verify that all required items have been submitted and notify the CDSE of the CDTAB date or if additional items are needed.

3. CDTAB Phase 1 Review. During the CDTAB review, the CDTAB will review the requirement and determine if a CDS is required to meet the mission requirement. CDTAB will also :

a. For a Standard Point to Point: Recommend a baseline solution to meet the transfer or access requirement and review the CDES response or grounds for CDES exclusion as to why CDES is not being used.

b. For a FTPO (non-VLOR) request: Determine if the criteria for a "tracking purposes only" CDS have been met.

c. ECDS Candidate where the Enterprise CD Service Provider (ECDSP) has responded they can meet the requirement and the Component intends to utilize CDES services: ensure there is a valid mission requirement for the proposed solution.

d. ECDS CDS Request: review the proposed system architecture and the DSAWG approved component requirements (specific component requests approved by DSAWG for ECDS implementation) and make any comments/suggestions regarding the technology selection.

e. For FTPO VLoR: Conduct a Risk Review of the VLoR assertions and make a determination if the CDTAB determines the requirement meets the intent of VLoR.

f. For Repeatable Accreditation Candidate CDS: Review the architecture, CDS and data flows and provide comments to DSAWG For Repeatable Accreditation/Authorization Candidate: Determine if Repeatable Accreditation/Authorization Requirements are met.

4. DSAWG Phase 1 Review: The DSAWG will review the CDTAB’s recommendation and comments and make a decision based on the following categories of CDS.

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

a. For a Standard Point to Point: Approval for ticketing and phase 2 analysis OR direction that ECDS must be utilized.

b. For a "FTPO" (non-VLOR) request: Approval for 3 years of operational use. SBSA approval is within AO purview and does not require separate DSAWG approval)

c. For an ECDS Candidate where the ECDSP has responded that they could meet the requirement and the Component intends to utilize CDES services: approval for ECDS implementation.

d. For FTPO 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.

5. Based on the DSAWG decision, the DSAWG Secretariat will update SGS milestones and also take the following actions based on the approval which was given: (see Section H.9)

H.6 Phase 2: CDS Security Control Assessment & Authorization

This phase applies only to Standard Point to Point solutions and ECDS Systems which are required to receive a Risk Decision Authority Criteria (RDAC) (ref ag) analysis. FTPO Tickets usually skip this phase.

1. The component or ECDSP works with their respective CDSE to engineer the CDS, and to complete and upload the following into SGS:

a. Documentation Requirements

i. Phase 2 CDA, Section 2.0 completed

ii. SBSA Plan and Procedures

iii. Draft Risk Assessments

 Draft risk analysis results are completed by designated entities. Usually the Data Risk and all portions of the Attack Risk are provided by the CDSE, except the Partner Type, which is provided by Defense Intelligence Agency (DIA) and the Grid Connectivity Threat (GCT) which is provided by the DISA Risk Adjudication Branch. The CDSE ensures the results are uploaded into SGS. The respective CDSE reviews the data and contacts the necessary entities which will assist in conducting portions of the RDAC risk analysis

2. The respective CDSE submits a CDTAB agenda request (ref ai) to the DSAWG Secretariat. Agenda requests will not be accepted by the DSAWG Secretariat directly from the component and all agenda requests must be submitted by the respective CDSE to the DSAWG Secretariat 14 calendar days prior to the next CDTAB meeting. Any late submissions beyond the 14 days will not be accepted.

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

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

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

a. If the component 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: SBSA approval for 2 weeks within a 90 day window will be granted. Note: Components may request additional time for SBSA if needed. After SBSA, the component will proceed to Phase 3.

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

Note: The duration of the operational use is dependent upon many factors. Based on the risk analysis results, the DSAWG is authorized by the DoD ISRMC to authorize a CDS to operate for up to 3 years if the risk rating is 2 steps within the RDAC "shot group," 2 years if 1 step within the shot group/on the edge, or 1 year if 1 step out of the shot group.  

c. 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 which 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 a 1 year CDSA upon successful review of the SBSA results by the CDSE."

5.Based on the DSAWG decision, the DISA Risk Adjudication Branch will update SGS milestones and also take the following actions based on the approval which was given: (see CDSA Issuance Section H.9)

H.7 Phase 3: CDS Security Control Assessment & Authorization

This phase applies only to Standard Point to Point solutions and ECDS Systems which are required to receive a Risk Decision Authority Criteria (RDAC) (ref ag) analysis. FTPO Tickets usually skip this phase.

1. The Component or ECDSP works with their respective CDSE to conduct SBSA, to review the SBSA results, and to complete and upload the following into SGS:

a. Required Documentation

Required Documentation

i. Upon completion of SBSA, the component must submit the SBSA results and updated Phase 3 CDA to their CDSE for upload to SGS.

ii. The respective CDSE will review the SBSA results to verify no changes exist between the Draft Risk Analysis and the actual test results.

iii. If there are no changes and the DSAWG already approved operational use upon CDSE review of the SBSA results, then the CDSE must notify the DISA CDS team and request issuance of the CDSA. (Proceed to step 4)

b. If the CDSE discovers that the SBSA results differ from the SBSA plan, if recommended mitigations were applied between phase 2 and phase 3, or if DSAWG otherwise requires the ticket to return to DSAWG for operational use, continue the steps below.

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

2. Once the revised ratings are provided, the CDSE will submit an agenda request to the DSAWG Secretariat. Agenda requests will not be accepted by the DSAWG Secretariat directly from the Component. All agenda requests must be submitted by the respective CDSE to the DSAWG Secretariat 14 calendar days prior to the next CDTAB meeting and any late submissions after the 14 days will not be accepted.

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.

4. DSAWG Phase 3 Review: The ticket will then be presented to the DSAWG with the CDTAB’s risk rating and comments. The DSAWG will make a decision whether or not to approve a CDSA for Operational Use.

5. Based on the DSAWG decision, the DISA Risk Adjudication Branch will update SGS milestones and also take the following actions based on the approval which was given: (see CDSA Issuance Section H.9)

H.8 Phase 4: Operational CDS Monitoring

CDSs can receive up to 3 years operational approval from DSAWG. This means that they do not need to return to DSAWG for 3 years. However, the CDS (unless a FTPO CDS) still requires an annual review by the CDSE and the DISA Risk Adjudication Branch. The process described below describes actions necessary for an annual review when CDTAB/DSAWG review is required as well as an annual review where CDTAB/DSAWG review is not required.

Note: DISA CDES will conduct annual reviews IAW the Annual Review Schedule for CDES Systems.   

1. Component contacts CDSE and submits required paperwork and updates SGS as required

a. Required Documentation

b. Revalidation Memorandum: A revalidation memo from the AO stating that the CDS is still required, the CDS configuration has not changed, and that it has been tested. CDES: For DISA CDES, the revalidation memorandum is split into multiple revalidation memorandums. A revalidation memorandum which revalidates the mission requirement for the CDS is required for each component AO supported by CDES. This revalidation memorandum which verifies the unchanged configuration and testing of the system is required from the DISA AO.

c. CDS Annual Self-Assessment Report

Note: DoDI 8540.01 (ref ad), Enclosure 2 (CD and RMF Roles) Section 8 (IS Owner)

k. Directs a periodic self-assessment be conducted to assess the protection mechanisms and security controls implemented to protect CD activities. The assessment will:

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

(2) Verify that the CDS is utilized per the approved security relevant configuration and documentation requirements.

(3) Identify possible security vulnerabilities.

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

d. DISA CDES Enterprise Response Memorandum (uploaded to SGS): If the CDS is not an Enterprise system and does not meet the exclusions listed in the CDES Non-Consideration Memorandum, a CDES response memorandum is required.

e. Repeatable Accreditation/Authorization: An updated CDS tracking spreadsheet of the repeatable CDS inventory is also required to be submitted to the CDSE and uploaded into SGS.

f. POA&M (if required) uploaded to SGS: If the Information System Owner is using a non-baseline CDS device or an ECDSP has stated they can meet the requirement or if the current system being deployed has been directed by DSAWG or DoD ISRMC to be improved, the Information System Owner must submit a POA&M detailing their schedule to migrate to a new solution, to CDES or to apply other mitigations within the architecture.

Note: DoDI 8540.01 (ref ad), Enclosure 2 (CD and RMF Roles) Section 9 (Information Owner)

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

2. CDSE must notify the DISA Risk Adjudication Branch the DISA Risk Adjudication Branch of these completed actions. If the DSAWG operational period has not expired, the DISA Risk Adjudication Branch the DISA Risk Adjudication Branch will proceed to step 5. If the ticket needs an extended operational approval, the DSAWG Secretariat will schedule the CDS for CDTAB review. Agenda requests will not be accepted by the DSAWG Secretariat directly from the Component. All agenda requests must be submitted by the respective CDSE to the CDTAB Secretariat 14 calendar days prior to the next CDTAB meeting. Any late submissions will not be accepted.

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

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

5. Based on the DSAWG decision, the DISA Risk Adjudication Branch will update SGS milestones and also take the following actions based on the approval which was given: (see CDSA Issuance Section H.9)

H.9 Post DSAWG/DoD ISRMC Actions and Cross Domain Solution Authorization Issuance

1. Based on the DSAWG decision, the DSAWG Secretariat will update SGS milestones and also take the following actions based on the approval which was given:

a. If ticketing was approved for a standard point to point 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 and the requirement will be given an ECDSP ticket number. The ECDSP will notify the mission partner of the ticket number for the system they intend to use to meet their requirement. The original request number will always be used to reference the component requirement and DSAWG approval of the requirement for ECDS implementation.

c. If SBSA was approved, the DISA Risk Adjudication Branch 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 which 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 CCSDs connecting 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 SGS Section 10.2 and show the CDS and CDS ticket number. 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 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 Branch 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 CCSDs connecting 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 SGS Section 10.2 and show the CDS and CDS ticket number. 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 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)

v. SBSA Results (If SBSA was required)

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

Note:If the documentation requirements are not sufficient for a CDSA to be issued at the time of the DSAWG/ DoD ISRMC decision the DISA Risk Adjudication Branch will notify the CDSE of the missing requirements. In order to obtain a CDSA once the documentation requirements are completed, a CDSA request form must be submitted to the DISA Risk Adjudication Branch   
Note: CDSA’s 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  
Note: If more than 1 year of operational use was approved by DSAWG or the DoD ISRMC, 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 H.8) If the CDS was approved FTPO then a 3 year CDSA can be issued not to exceed three years from the date of the DSAWG or DoD ISRMC review. CDSA’s will not be issued past AO authorization for the CDS.  
Note: If the ticket is a repeatable authorization/accreditation ticket, the CDSA for SBSA and/or Operational Use will specifically reference the number of CDS’s authorized by the DSAWG or DoD ISRMC. If the Component needs to operate additional instantiations, it is necessary to return to DSAWG with mission justification for approval.  
Note: The CDS device is marked operational in SGS upon the initial issuance of a CDSA by the DISA Risk Adjudication Branch following a DSAWG or DoD ISRMC approval. It remains operational until the DISA Risk Adjudication Branch receives evidence from the Component’s respective CDSE that the device is non-operational.   

H.9.1 Configuration Changes to Operational CDSs

Planned changes to the configuration of the CDS including patches and upgrades must be coordinated with the Component’s respective CDSE and entered into the SGS as Phase I requests. If the change is a patch, software upgrade or other configuration change such as adding a channel or network, the DISA Risk Adjudication Branch will administratively move the request to Phase 2 and issue a new CDS ticket number provided the normal phase 1 documentation requirements and SGS updates have been completed. The CDS ticket will return to DSAWG once the Phase 2 risk rating has been concurred upon by CDTAB.

If the request is for a change in technology, the CDS ticket will not be administratively moved to Phase 2 and should follow the normal Phase 1 process.

H.9.2 Closure of a CDS Requirement

If for any reason it becomes necessary to discontinue use of a CDS or a component is no longer continuing their mission, the respective CDSE must submit a closure request in order to stop tracking of 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) should be updated as well to remove the CDS.

H.10 IC CDS Registration Process

The DoD ISRMC requested that all IC owned, UCDSMO baseline CDSs which 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 and maintaining an accurate depiction of DoD network environments and interconnections and facilitate rapid incident response.

H.10.1 Step 1: Obtain and Complete an IC CDS Registration Form

To obtain an IC CDS Registration form template, contact the DISA Risk Adjudication Branch at 301-225-2903 or via e-mail at: disa.meade.ns.mbx.cdtab@mail.smil.mil. The form is also posted on both the CDTAB and DSAWG SIPR Intelink Sites. The IC registration form contains all of the data necessary to complete an SGS database registration. .

H.10.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: To obtain access to the SGS database components, go to: https://giap.disa.smil.mil and select "request an account." The CDSE will be required to upload a completed DD2875. A template is provided on the entry page of the website. Once the registration is complete, the IC component or CDSE will notify the CDTAB Secretariat of a completed registration. the DISA Risk Adjudication Branch will review the registration, generate a CDS Ticket Number, and notify the submitting IC Component and/or CDSE of the CDS Ticket Number.

H.10.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 DISA Risk Adjudication Branch that all documents have been submitted. the DISA Risk Adjudication Branch will send notification of a completed IC CDS registration to the DSAWG Chair.

H.10.4 Step 4: CDSA Issuance

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

H.10.5 Step 4: Operational CDS Monitoring

Annually, the DISA Risk Adjudication Branch will request the IC POC to verify if the CDS is still operational. Any time that the devices are modified in a manner which requires the IC registration to be updated, the IC agency should provide that update to the DISA Risk Adjudication Branch. If the device is decommissioned, the IC agency is requested to provide notification via a signed memo or digitally signed e-mail to the DISA Risk Adjudication Branch and they will close the registration in SGS.

IC CDS Registration Process

H.11 Frequently Asked Questions (FAQs)

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 being used for load balancing?

A: A separate request/ticket is required for each CDS device/distribution console if the device is used as a hot spare or load balancing. 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 DISA Risk Adjudication Branch must be notified and a new request must be opened.

The exception to this is if the ticket is a DISA CDES ticket or a Repeatable Accreditation/Authorization ticket. In this case, the "Instantiations" field of SGS will be updated to reflect the number of instantiations a single CDS ticket represents. All documentation will be maintained under that single CDS ticket number in SGS.

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

A: Once a 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 listed below:

Once a 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 listed below:
  • First partition (1234-0001-001): The first partition represents the component requirement. If this is a new component requirement, the Request will receive a ticket number with a unique first partition. The second and third partitions will be 1.
  • Second partition (1234-0001-001): The second partition represents the instantiation of the CDS device. For example, if three CDS devices were needed for load balancing, the ticket numbers would be 1234-0001-001, 1234-0002-001, and 1234-0003-001. The configuration and Component requirement is the same, but there are three devices meeting this requirement. These devices could be the same configuration at the same location or they could be the same configuration at three different locations.
  • The exception to this is if the ticket is a DISA CDES ticket or a Repeatable Accreditation ticket. In this case the "Instantiations" field of SGS will be updated to reflect the number of instantiations a single CDS ticket represents. All documentation will be maintained under that single CDS ticket number in SGS.
  • 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 components. 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.

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

A: Once a Security Authorization Package (SAP) is submitted, reviewed, and accepted by the CAO, 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 approval of a CDS contingent upon a current ATC for the CCSD and the ATO, and Topology properly referencing the CDS ticket number. Also, the CDSA expiration date will not exceed the ATC expiration date if the ATC expires prior to the DSAWG approval expiration. Once a new ATC is issued, another CDSA will be issued for the remainder of the DSAWG approval window.

H.12 Points of Contact

Cross Domain Solutions (CDS) 

DSAWG Secretariat - CDTAB Support

301-225-2903 (commercial), 312-375-2903 (DSN)

disa.meade.re.mbx.cdtab@mail.mil (NIPR)

disa.meade.re.mbx.cdtab@mail.smil.mil (SIPR)

http://intelshare.intelink.sgov.gov/sites/cdtab (SIPR) 

DSAWG Secretariat - DSAWG Support 

301-225-2905 (commercial), 312-375-2905 (DSN)

disa.meade.re.mbx.dsawg@mail.mil (NIPR)

disa.meade.re.mbx.dsawg@mail.smil.mil (SIPR)

https://intelshare.intelink.gov/sites/dsawg (NIPR)

http://intelshare.intelink.sgov.gov/sites/dsawg (SIPR)

DISA Cross Domain Enterprise Services 

disa.meade.peo-ma.list.peo-ma-IA32.cdescna@mail.mil

UCDSMO 

http://intelshare.intelink.sgov.gov/sites/ucdsmo/default1.aspx

H.13 Additional Policy and Guidance Documents

Policy  Title 
CJCSI.6211.02D  Defense Information Systems Network (DISN): Policy and Responsibilities (ref b) 
CDTAB Charter  Cross Domain Technical Advisory Board (ref ac) 
DSAWG Charter  DSAWG Charter (ref x) 
RDAC 2.3, NSA  Risk Decision Authority Criteria (ref ag) 
DoDD 5100.3  Support of the Headquarters of Combatant and Subordinate Joint Commands (ref ae) 
VLoR IG 

Very Low Risk Implentation Guide (ref z)

http://intelshare.intelink.sgov.gov/sites/dsawg/shared/CDS/risk_rating_methodologies/VLOR

VLoR Assertions  Very Low Risk Assertrions (ref aa) 
DoD CDSE Memorandum  Cross Domain Support Element Responsibilities (ref ab) 
DISA CDES  DISA CDES Non Consideration Memorandum (ref ad) 
DoD CIO and IC CIO Memorandum  Establishment of the Unified Cross Domain Service Management Office as the Cross Domain Requirements and Engineering Services Manager 
Repeatable CDA Authorization  Repeatable CDS Entrance Criteria (ref ad)
DoDI 8510.01  Risk Management Framework for DoD Information Technology (IT) (ref d)