Skip to main content
INS // Insights

DISA STIG Compliance for Cloud Deployments

Updated April 2026 · 7 min read

DISA Security Technical Implementation Guides (STIGs) are the DoD's prescriptive security configuration standards for operating systems, applications, network devices, and increasingly, cloud services and containers. For defense contractors running cloud workloads on DoD programs, STIGs are often contractually required — not just compliance guidance.

Here's how Rutagon implements DISA STIG compliance in cloud deployments, including automated scanning and the specific configuration controls that satisfy the most commonly tested requirements.

What STIGs Are and Why They Matter for Cloud

STIGs are published by the Defense Information Systems Agency (DISA) and prescribe specific technical configuration settings for hardening systems. A STIG for a specific OS or application includes hundreds of individual checks — each with a severity level (CAT I / II / III), a test procedure, and a fix procedure.

STIGs exist for:

  • Operating systems (Red Hat Enterprise Linux, Windows Server, Ubuntu)
  • Container platforms (Kubernetes, Docker)
  • Cloud services (AWS Foundations STIG, Kubernetes STIG)
  • Applications (web servers, databases, browsers)
  • Network devices

For cloud deployments, the relevant STIG set includes:

  • AWS Foundations STIG: Account-level AWS configuration (CloudTrail, GuardDuty, IAM settings, S3 bucket policies)
  • Kubernetes STIG V1: Kubernetes cluster hardening (API server flags, RBAC, network policies, audit logging)
  • Container Platform SRG / Docker STIG: Container runtime configuration, image requirements
  • RHEL STIG (or equivalent): For EC2 instances or container base images

AWS Foundations STIG: Account-Level Configuration

The AWS Foundations STIG covers IAM, logging, monitoring, and account configuration. Key controls that represent the highest-frequency findings:

CloudTrail Multi-Region Logging (CAT II)

CloudTrail must log management events in all regions, including GovCloud:

resource "aws_cloudtrail" "main" {
  name                          = "main-cloudtrail"
  s3_bucket_name                = aws_s3_bucket.cloudtrail.id
  s3_key_prefix                 = "cloudtrail"
  include_global_service_events = true
  is_multi_region_trail         = true  # STIG requirement
  enable_log_file_validation    = true  # Tamper detection
  
  cloud_watch_logs_group_arn = "${aws_cloudwatch_log_group.cloudtrail.arn}:*"
  cloud_watch_logs_role_arn  = aws_iam_role.cloudtrail_cloudwatch.arn
  
  event_selector {
    read_write_type           = "All"
    include_management_events = true
    
    data_resource {
      type   = "AWS::S3::Object"
      values = ["arn:aws-us-gov:s3:::${var.sensitive_bucket_name}/"]
    }
  }
}

Root Account MFA (CAT I)

The AWS root account must have MFA enabled — this is CAT I (highest severity) in the AWS Foundations STIG. Root account usage should also be monitored and alerted:

resource "aws_cloudwatch_metric_alarm" "root_account_usage" {
  alarm_name          = "root-account-usage-alarm"
  alarm_description   = "STIG CAT I: Alert on root account API calls"
  comparison_operator = "GreaterThanOrEqualToThreshold"
  evaluation_periods  = 1
  metric_name         = "RootAccountUsage"
  namespace           = "CloudTrailMetrics"
  period              = 300
  statistic           = "Sum"
  threshold           = 1
  alarm_actions       = [aws_sns_topic.security_alerts.arn]
}

S3 Bucket Public Access (CAT II)

All S3 buckets must have public access blocked at the account level:

resource "aws_s3_account_public_access_block" "main" {
  block_public_acls       = true
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
}

Kubernetes STIG: Cluster Hardening

The Kubernetes STIG covers API server configuration, etcd security, network policies, RBAC, and audit logging. Key controls:

API Server Audit Logging (CAT II)

Kubernetes audit logging must be configured with appropriate event coverage:

# /etc/kubernetes/audit-policy.yaml
apiVersion: audit.k8s.io/v1
kind: Policy
rules:
  # CAT II: Log all requests at the metadata level
  - level: Metadata
    resources:
      - group: ""
        resources: ["secrets", "configmaps"]
  
  # Log all exec/attach/portforward events
  - level: Request
    verbs: ["exec", "attach", "port-forward"]
    resources:
      - group: ""
        resources: ["pods"]
  
  # Log all changes to RBAC objects
  - level: RequestResponse
    resources:
      - group: "rbac.authorization.k8s.io"
        resources: ["clusterroles", "clusterrolebindings", "roles", "rolebindings"]
  
  # Default: metadata level for everything else
  - level: Metadata

Network Policies (CAT II)

Default-deny network policies with explicit allow rules for required traffic:

# Default deny all ingress and egress
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: production
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress
---
# Explicit allow for API service ingress from load balancer
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-api-ingress
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: api-service
  policyTypes:
    - Ingress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: ingress-nginx
      ports:
        - port: 8080
          protocol: TCP

Privileged Container Restriction (CAT I)

No production containers should run as privileged. Enforce via PodSecurity admission or OPA Gatekeeper:

# OPA Gatekeeper constraint — deny privileged containers
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sNoPrilegedContainers
metadata:
  name: no-privileged-containers
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Pod"]
    namespaces:
      - "production"
      - "staging"
  parameters:
    exemptImages: []  # No exemptions in production

Automated STIG Scanning in CI/CD

Manual STIG assessment is impractical at scale — hundreds of checks across multiple system components, on every deployment. Automated scanning integrated into CI/CD provides continuous compliance evidence.

Tools for automated STIG scanning:

OpenSCAP / SCAP Workbench: NIST's Security Content Automation Protocol tooling, used for OS-level STIG scanning. Can run in CI/CD against AMIs or during build validation.

Trivy + custom STIG policies: Trivy's misconfiguration scanning supports custom Rego policies that encode STIG requirements.

Anchore Enterprise: Commercial tool with STIG content for container image scanning, used heavily in DoD environments.

AWS Security Hub: Aggregates findings from AWS Config rules (which can encode AWS Foundations STIG checks) and provides a compliance score across your account.

The CI/CD integration pattern:

# GitLab CI STIG validation stage
stig-scan-k8s:
  stage: compliance-check
  image: aquasec/trivy:latest
  script:
    - trivy config --severity HIGH,CRITICAL 
        --tf-vars terraform.tfvars.json 
        kubernetes/
    - trivy k8s --report summary cluster
  allow_failure: false  # Block deployment on CAT I/II findings
  artifacts:
    reports:
      junit: trivy-stig-results.xml
    expire_in: 90 days

The expire_in: 90 days is intentional — FedRAMP ConMon requires maintaining scan evidence for 90 days minimum. Artifacts committed as CI/CD reports satisfy this requirement automatically.

Discuss STIG compliance for your cloud program →

Frequently Asked Questions

Are DISA STIGs required for all DoD cloud programs?

STIG compliance is required for DoD information systems under DODI 8500.01 and the Risk Management Framework. The specific STIGs applicable to a given system are determined during the categorization and control selection phase of the RMF process. Most DoD cloud programs running on AWS GovCloud or Azure Government will have AWS Foundations STIG, Kubernetes STIG (if containerized), and OS STIGs applicable. The Authorizing Official specifies which STIGs apply in the Security Assessment Plan.

What is a STIG CAT I vs CAT II vs CAT III finding?

STIG findings are categorized by severity: CAT I (Critical) — exploiting the vulnerability results in direct, immediate harm to the confidentiality, integrity, or availability of the system. CAT II (High) — exploiting the vulnerability may result in significant harm. CAT III (Medium) — degraded security but less immediate risk. CAT I and CAT II findings must be addressed before Authorization in most DoD RMF processes; CAT III findings are documented in the POA&M.

How do Iron Bank containers relate to STIG compliance?

Platform One's Iron Bank (now DI2E Iron Bank) is DISA's approved container registry for DoD programs, containing hardened container images that have been scanned against applicable STIGs. Using Iron Bank images as base images in containerized applications provides a STIG-compliant starting point, reducing the number of CAT I/II findings a 3PAO or RMF assessor will identify in container scanning. If your program is on Platform One or requires IL4/IL5 container provenance, Iron Bank images are the baseline.

Can AWS Config rules replace STIG manual checks?

AWS Config rules can automate a significant portion of the AWS Foundations STIG checks — CloudTrail configuration, root MFA, S3 public access blocking, IAM password policy, GuardDuty enablement. AWS Security Hub provides a consolidated compliance score against these Config rules. However, Config rules don't cover OS-level or application-level STIGs — those require separate scanning tooling. Think of AWS Config/Security Hub as covering the cloud account layer, while OpenSCAP/Trivy/Anchore cover the OS and container layers.

What's the difference between STIG compliance and FedRAMP compliance?

They're complementary but separate frameworks. FedRAMP is built on NIST 800-53 Rev 5 and covers the complete security control set for federal cloud systems — access control, configuration management, incident response, etc. DISA STIGs are prescriptive technical configuration guides for specific products. On DoD programs, both apply: FedRAMP (or FISMA/RMF) covers the overall security posture; STIGs provide the specific "how" for configuring each component to DoD standards. A system can be FedRAMP High authorized without STIG compliance; DoD ATO typically requires both.

Discuss your project with Rutagon

Contact Us →

Ready to discuss your project?

We deliver production-grade software for government, defense, and commercial clients. Let's talk about what you need.

Initiate Contact