DISA (Defense Information Systems Agency) provides cloud infrastructure services across DoD — IL2 through IL6 environments — and sets the security baseline requirements that all DoD cloud programs must meet. For subcontractors delivering cloud engineering on DISA-connected programs, understanding and implementing the DISA security stack isn't optional.
Here's how Rutagon implements DISA's required security controls in cloud engineering delivery.
DISA's Security Requirements Framework
DISA security requirements for cloud programs flow from two primary sources:
DISA Cloud Computing Security Requirements Guide (CC SRG): The CC SRG defines IL-specific requirements for cloud systems — what controls are required, which controls the Cloud Service Provider (CSP) is responsible for, which are shared, and which the mission owner must implement. The CC SRG is the foundational document for any cloud authorization at DoD.
DISA STIGs: Security Technical Implementation Guides define specific configuration baselines for operating systems, applications, databases, and cloud services. STIG compliance is required for cloud systems hosting DoD workloads. STIG findings are categorized: - CAT I (High): System must not have open CAT I findings at authorization - CAT II (Medium): Must be remediated or have documented POA&M - CAT III (Low): Should be remediated; acceptable risk for documented exceptions
For a cloud sub implementing DISA-required controls, the work falls into three categories: infrastructure hardening, continuous monitoring, and ATO evidence generation.
Infrastructure Hardening Against DISA STIGs
Container hardening is the first layer. All containers deployed on DoD programs should use Iron Bank images — hardened, STIG-compliant base images maintained by Platform One. Starting from Iron Bank images dramatically reduces the STIG finding burden vs. building from standard public images.
# Enforcing Iron Bank base images in GitLab CI
.ironbank_check:
before_script:
- |
REGISTRY_HOST=$(echo ${IMAGE_NAME} | cut -d'/' -f1)
if [[ "${REGISTRY_HOST}" != "registry1.dso.mil" ]]; then
echo "ERROR: Images must use Iron Bank registry (registry1.dso.mil)"
exit 1
fi
Kubernetes node hardening follows: STIG configurations for worker node OS (RHEL or Ubuntu STIG baseline applied via Ansible or node configuration management), Kubernetes STIG controls (API server audit logging, pod security standards, network policy enforcement).
Infrastructure hardening via Terraform ensures that every deployed environment starts from the same STIG-aligned baseline:
# EKS cluster — STIG-required audit logging
resource "aws_eks_cluster" "mission" {
name = var.cluster_name
enabled_cluster_log_types = [
"api", "audit", "authenticator",
"controllerManager", "scheduler"
]
encryption_config {
resources = ["secrets"]
provider {
key_arn = var.kms_key_arn
}
}
# Force private API endpoint — STIG requirement
kubernetes_network_config {
ip_family = "ipv4"
}
}
Continuous Monitoring Infrastructure
DISA-required ConMon for cloud programs follows NIST RMF Step 6 — ongoing security assessments, status reporting, and POA&M management. Automating ConMon infrastructure eliminates the manual spreadsheet-based processes that historically consumed ISSO time.
Security Hub with NIST 800-53 Standard: AWS Security Hub in GovCloud supports the NIST 800-53 security standard — findings are automatically mapped to specific NIST controls. This provides a continuously updated compliance picture without manual control assessment.
# Automated ConMon daily report generation
import boto3
from datetime import date
def generate_conmon_report():
sh = boto3.client('securityhub', region_name='us-gov-west-1')
findings = sh.get_findings(
Filters={
'ComplianceStatus': [{'Value': 'FAILED', 'Comparison': 'EQUALS'}],
'SeverityLabel': [
{'Value': 'HIGH', 'Comparison': 'EQUALS'},
{'Value': 'CRITICAL', 'Comparison': 'EQUALS'}
]
}
)
report = {
'report_date': str(date.today()),
'open_high_findings': len(findings['Findings']),
'findings_by_control': categorize_by_control(findings['Findings'])
}
# Save to S3 ATO evidence bucket
s3 = boto3.client('s3')
s3.put_object(
Bucket=os.environ['ATO_EVIDENCE_BUCKET'],
Key=f"conmon/{date.today()}/security-hub-report.json",
Body=json.dumps(report)
)
GuardDuty: Enabled in all GovCloud accounts — threat detection findings feed into the ConMon process and trigger incident response procedures per the program's IR plan.
ATO Evidence Generation
The DISA authorization process requires a body of evidence (BoE) that demonstrates security control implementation. Rutagon's pipeline generates ATO evidence artifacts automatically:
- Container image scan report: Trivy SARIF output for every deployed image, tagged to deployment event
- Infrastructure compliance scan: Terraform compliance check results (Checkov or custom OPA policies), recorded per deployment
- STIG scan results: SCAP scan results for OS and application STIG profiles, scheduled weekly and before major deployments
- Access control review: IAM policy export and least-privilege analysis, scheduled quarterly
- ConMon dashboard screenshot + findings export: Automated daily export from Security Hub to the ATO evidence S3 bucket
View Rutagon's engineering capabilities → rutagon.com/government
Frequently Asked Questions
What's the difference between DISA CC SRG and FedRAMP for cloud programs?
FedRAMP is the civilian agency cloud security authorization framework managed by GSA. DISA CC SRG is the DoD-specific framework. Programs on DoD cloud (Defense Enclave, GovCloud under DoD, Azure Government DoD) use CC SRG. Civilian agency programs use FedRAMP. There is significant overlap — DISA has granted FedRAMP Moderate baseline reciprocity for IL2 DoD programs — but higher IL environments (IL4/IL5/IL6) have DoD-specific requirements beyond FedRAMP Moderate.
Is Platform One Iron Bank required for all DoD programs?
Platform One Iron Bank is the preferred DoD hardened container registry, and many programs mandate its use. For programs not yet on Platform One, DISA-compliant alternative hardening processes exist (build from minimal STIG-compliant base images, apply container hardening playbooks). The goal is identical: containers deployed to DoD environments must have documented STIG compliance, regardless of whether the image originated from Iron Bank.
How do DISA STIG updates affect running systems?
DISA releases STIG updates periodically. Programs must assess new STIG versions against their current configuration and remediate new findings within the program's ConMon timeline (typically 30 days for CAT I/High after discovery, 90 days for CAT II/Medium). Automating STIG scanning in the CI/CD pipeline means new STIG versions can be incorporated into the scan profile, and new findings surface immediately without manual audit cycles.
What clearance level is required for DISA cloud engineering work?
It depends on the IL environment. IL2 work (DoD non-CUI data) typically doesn't require a security clearance. IL4 (CUI) and IL5 (higher sensitivity) require cleared personnel for accessing the classified infrastructure. IL6 (SAP/classified national security systems) requires personnel cleared to the system's classification level. Rutagon's clearance posture for specific programs is discussed in teaming negotiation, not disclosed publicly.
How does Rutagon handle zero-day vulnerabilities in DISA-connected environments?
Zero-day CVEs affecting container base images or cloud infrastructure components trigger an emergency patching process: severity assessment against affected components → Iron Bank or alternative patched image pull → pipeline rebuild with patched image → compliance scan to confirm remediation → expedited deployment. Rutagon maintains a software bill of materials (SBOM) for all deployed components using CycloneDX format, which enables rapid assessment of zero-day exposure scope.