Compliance — DoD Impact Level 4 / Impact Level 5¶

Scope: Department of Defense cloud deployments at Impact Level 4 (Controlled Unclassified Information) and Impact Level 5 (CUI + mission-critical / National Security Systems). This guide covers the DISA Cloud Computing SRG requirements and how CSA-in-a-Box maps to them on Azure Government.

Overview¶

The Defense Information Systems Agency (DISA) Cloud Computing Security Requirements Guide (CC SRG) defines six Impact Levels that govern where DoD data can reside in the cloud:

CSA-in-a-Box targets IL4 and IL5 deployments. The CC SRG builds on NIST SP 800-53 Rev 5 and layers DoD-specific overlays for network isolation, personnel vetting, physical location, and encryption. A valid FedRAMP High Provisional Authorization (PA) is a prerequisite for IL4; IL5 adds further isolation and key-management requirements.

IL4 vs IL5 comparison¶

IL5 encryption keys must be isolated from IL4 infrastructure. Azure Government meets this via dedicated IL5 compute stamps, but your Key Vault deployment must also use a separate subscription and HSM pool from any IL4 workloads.

Azure deployment targets¶

IL4 — Azure Government¶

Azure Government holds FedRAMP High and DISA IL4 PA for these regions. Deploy CSA-in-a-Box using the Gov Bicep variant at deploy/bicep/gov/.

IL5 — Azure Government (dedicated infrastructure)¶

IL5 workloads run on dedicated Azure Government infrastructure physically separated from IL4 compute, in the US DoD Central and US DoD East regions.

IL6 — Azure Government Secret (air-gapped)¶

IL6 is out of scope for CSA-in-a-Box. It requires air-gapped networks, SECRET clearances, and SCIF-level physical security.

CSA-in-a-Box IL4 / IL5 configuration¶

Landing zone¶

Deploy into an Azure Government subscription with the Gov Bicep modules (deploy/bicep/gov/). The landing zone implements isolated VNets per workload tier, SCCA-compliant network architecture, dedicated resource groups with DoD tagging, and Azure Policy for the CC SRG baseline.

SCCA — Secure Cloud Computing Architecture¶

DISA's SCCA mandates three boundary-protection components (Internet -> BCAP -> VDSS -> VDMS -> Mission VNets):

The Hub-Spoke Topology maps directly to the SCCA model: the hub VNet hosts BCAP/VDSS/VDMS, and spoke VNets host mission workloads.

Identity¶

• Entra ID Government (US Gov cloud instance) for all authentication
• CAC/PIV via Entra certificate-based authentication (CBA); Conditional Access enforcing CAC/PIV for privileged ops
• PIM for just-in-time role activation

Configure Entra ID certificate-based authentication to accept DoD PKI root CAs. Map the certificate SAN:RFC822Name or Subject fields to Entra user attributes for seamless CAC login.

Encryption¶

• FIPS 140-2 Level 2 minimum; CMK via Key Vault Premium (HSM-backed) for Storage, SQL, Cosmos, Synapse
• Double encryption on storage (requireInfrastructureEncryption: true)
• IL5 key isolation — separate Key Vault subscription from IL4 workloads

Logging and monitoring¶

• All diagnostic logs to Azure Monitor (Log Analytics in Gov region); Sentinel for SIEM/SOAR
• Retention: 1-year hot + 6-year cold archive in immutable blob storage
• STIG-aligned audit events per LOG_SCHEMA.md

Network¶

• Private endpoints everywhere; Azure Firewall Premium with IDPS; no public IPs on data plane
• NSG flow logs retained 1 year with Traffic Analytics; no internet egress without explicit rule

Architecture — SCCA boundary model¶

graph TB
    subgraph BCAP["BCAP — Boundary"]
        FW[Azure Firewall Premium]
    end
    subgraph VDMS["VDMS — Management"]
        KV[Key Vault HSM] --- LOG[Log Analytics + Sentinel]
        DEF[Defender for Cloud] --- UPD[Update Mgmt]
    end
    subgraph VDSS["VDSS — Security"]
        WAF[App Gateway + WAF v2]
    end
    subgraph APP_ZONE["Mission — App"]
        APP[App Service / AKS] --- API[API Management]
    end
    subgraph DATA["Mission — Data"]
        SQL[Azure SQL] --- STOR[Storage] --- SYN[Synapse]
    end
    INET((NIPRNet)) --> FW --> WAF --> APP --> API --> SQL
    FW --> KV & LOG
    DEF -.-> LOG

STIGs — Security Technical Implementation Guides¶

DISA STIGs apply to every component in the authorization boundary:

Azure Policy for STIG compliance¶

Assign the built-in DoD DISA STIG policy initiative at subscription scope:

resource stigAssignment 'Microsoft.Authorization/policyAssignments@2024-04-01' = {
  name: 'dod-disa-stig'
  properties: {
    policyDefinitionId: '/providers/Microsoft.Authorization/policySetDefinitions/d379c8d7-4e0e-4e4a-a914-1a2de9a67c6b'
    displayName: 'DoD DISA STIG - Azure Government'
  }
}

Enable Defender for Cloud regulatory compliance with the DISA STIG initiative. This provides continuous assessment with a compliance score and per-resource remediation guidance viewable in the Azure Government portal.

Authorization process¶

DoD cloud authorization follows the Risk Management Framework (RMF) per DoDI 8510.01:

1. Categorize — System categorization using CNSSI 1253 (maps to FIPS 199)
2. Select — Apply CC SRG baseline controls for the target IL + NIST 800-53 overlay
3. Implement — Deploy CSA-in-a-Box with Gov Bicep modules; document in SSP
4. Assess — DISA or authorized 3PAO performs Security Assessment Report (SAR)
5. Authorize — Authorizing Official issues Provisional Authorization at target IL
6. Monitor — Continuous monitoring per DISA ConMon (monthly scans, POA&M, annual reassessment)

The CSP (Microsoft Azure Government) holds the infrastructure PA. Your system inherits that PA and must obtain its own system-level ATO from the sponsoring DoD component.

Common gaps and mitigations¶

Related¶

• NIST 800-53 Rev 5 — underlying control framework
• CMMC 2.0 Level 2 — DoD contractor CUI requirements
• FedRAMP Moderate — prerequisite authorization baseline
• Hub-Spoke Topology — SCCA network mapping
• Identity & Secrets Flow — Entra ID + PIM + CBA
• Security & Compliance
• Government Service Matrix — service availability per Gov region
• DISA CC SRG: https://public.cyber.mil/dccs/
• Azure Government: https://learn.microsoft.com/azure/azure-government/compliance/azure-services-in-fedramp-auditscope