Skip to content

Securing External Data Connections

Securing data exchange is essential for applications deploying in both Commercial and DoW Impact Level (IL) environments. Every External Data Connection (EDC) must be carefully planned, documented, and reviewed to ensure compliance with DoW security standards.

This guide outlines the requirements and security practices for safely establishing EDCs in the Game Warden platform.

Why securing EDCs matters

Improperly configured external connections can lead to data spills, unauthorized access, and CtF/Software Approval delays. For example:

  • An IL4 application cannot send Controlled Unclassified Information (CUI) to an IL2 system or public internet endpoint.
  • All data moving over external connections must be encrypted using FIPS-compliant standards.
  • Game Warden must verify that connections don’t bypass IL segmentation rules.

Key security requirements

  • Data Flow Documentation – Diagrams and written descriptions of all inbound, outbound, and bidirectional data flows.
  • Encryption In Transit – All data must be protected with TLS 1.2+ (e.g., mTLS).
  • Encryption At Rest – External systems must use FIPS 140-2 validated encryption modules or equivalent.
  • Impact Level Segmentation – Data must remain within its assigned IL unless explicitly approved.

Security guidelines for Impact Levels

Impact Level Requirement
IL2 – Public or Non-Critical Mission Data
  • Enforce basic access controls and authentication
  • Use TLS 1.2+ encryption for all data in transit
  • Maintain activity logging and monitoring to detect misuse
  • Avoid exposing non-public DoW data despite lower sensitivity
IL4 – Controlled Unclassified Information (CUI)
  • Strictly enforce IL segmentation—CUI must remain within IL4 or higher
  • Do not process or store National Security System (NSS) CUI
  • Apply encryption at rest using FIPS 140-2 validated modules
  • Maintain role-based access control (RBAC) and audit logging
  • Mission Owner Attestation may be required before approving EDCs
IL5 – Higher Sensitivity CUI / Mission-Critical
  • Enforce least privilege for all users and services
  • Segment workloads to isolate sensitive functions
  • Apply continuous monitoring (e.g., IDS/IPS, SIEM)
  • Encrypt all external data at rest and in transit
  • Document and justify all boundary-crossing data flows
  • Cross-IL data movement requires formal security review
IL6 – Classified Systems
  • Continuous monitoring and active threat detection
  • Apply the strongest possible encryption for all data
  • Enforce restricted physical and logical access
  • Follow NSA/DoW-defined cross-domain control protocols
  • External connections must use approved cross-domain solutions and are rarely permitted

EDC and Sponsoring Agency approval

Second Front customers can leverage an authorizing agency sponsor to extend their application’s capabilities beyond the Game Warden boundary. This allows for the integration of external services and data sources while maintaining a robust security posture.

Key guidance

  • Authorizing Official (AO) Authority: Your application’s risk-owning AO has the authority to approve External Data Connections (EDCs) residing outside the approved Game Warden boundary. This includes connections to other ATO’d environments or API-extensible managed services, provided they meet your application’s required IL.

  • Documentation & Compliance: To facilitate the approval process, all EDCs-including external managed services-must provide the information outlined in the EDC Checklist. This documentation is vital for the AO’s risk assessment and ensures the connection adheres to platform security standards.

  • Customer Licensing & Access: For all EDCs to external APIs, customers are responsible for procuring necessary licenses and managing API credentials as required for their specific mission use case.

Commercial connection rules

Commercial data connections entering a DoW-IL environment must follow a strict ingress-only policy—this includes IL2 environments. Outbound or bidirectional communication is not allowed unless explicitly approved through the EDC request process.

Following these security requirements—and taking a proactive approach to risk management—helps teams maintain secure data flows, protect critical systems, and ensure mission continuity. A documented incident response plan is also essential for addressing potential security events swiftly and effectively.

EDCs checklist

If your application includes any EDCs, you must submit an EDC request package to Second Front for review and approval. Use the checklist below to validate your setup before assembling the required artifacts for your submission.

Category Checklist Items
Impact Level Segmentation
  • Are data flows confined to their respective ILs?
  • Do systems only communicate with others at the same IL?
Data Protection
  • Is data encrypted in transit (mTLS 1.2+)?
  • Is data encrypted at rest (FIPS 140-2 validated modules)?
Connection Documentation
  • Have you included a complete network diagram?
  • Have you described the data types, purpose, and justification for each connection?
IL-Specific Requirements
  • IL2: Are external connections limited to essential, public-facing services?
  • IL4: Has a Mission Owner Attestation been signed (if applicable)? No NSS CUI processed?
  • IL5: Are encryption, logging, and access controls in place?
  • IL6: Are strongest encryption and continuous monitoring in place?
CTI Containment
Data Traversal Between ILs
  • If data must traverse between different Impact Levels (ILs), has a formal security review and approval been completed?
Commercial-to-DoW Connections
  • Does your commercial connection follow the ingress-only rule (unless explicitly approved)?
Security Posture
  • Are vulnerability scans conducted regularly?
  • Are IDS/IPS systems in place?
  • Is the principle of least privilege enforced?
  • Is continuous monitoring active?
  • Is there an incident response plan?

Required artifacts

Include the following with your EDC request:

  • List of all IPs, ports, and protocols
  • Direction of data flow for each connection
  • Description of transmitted data types
  • Diagram showing data flow and boundary crossings, similar to the already existing Authorization Boundary Diagram provided as part of the Body of Evidence (BoE)
  • Justification and purpose for each connection

Need help?

For questions or to submit your request package, contact your Technical Implementation Manager or Mission Success Manager.