Cloud security posture management for defense: CSPM in classified environments

Cloud misconfiguration is now the leading cause of data breaches across cloud-hosted infrastructure — and the problem is significantly worse in defense environments, where the consequence of a single exposed resource is not a business disruption but a potential intelligence failure. Defense organizations moving workloads to government cloud — AWS GovCloud, Azure Government, or classified commercial cloud at IL4 and IL5 impact levels — inherit a large and dynamic attack surface that cannot be secured through periodic manual audits alone.

Cloud Security Posture Management (CSPM) provides the continuous visibility layer that defense cloud environments need: automated, policy-driven scanning of cloud configuration state against compliance baselines, with real-time alerting on deviations and integration into the formal remediation and accreditation workflows that govern DoD systems. This article covers how CSPM works in classified environments, what it scans, how drift detection operates, and how CSPM output feeds the ATO evidence packages that Authorizing Officials require.

What CSPM covers and why classified cloud needs it

CSPM tools continuously evaluate the configuration state of cloud resources against a defined policy baseline — assessing IAM roles, network security groups, storage bucket permissions, encryption settings, logging configuration, and hundreds of other resource attributes — and surface deviations as findings that must be remediated or formally accepted. This is fundamentally different from a vulnerability scanner, which looks for software weaknesses (CVEs, missing patches, exploitable code paths); CSPM looks for configuration weaknesses.

The distinction matters enormously in classified cloud. Defense cloud tenants are typically running on hardened, patched infrastructure maintained by the cloud service provider under the shared responsibility model. The workloads themselves may be well-patched. But the configuration of how those workloads are deployed — the IAM policies that control who can access them, the network rules that determine what traffic reaches them, the logging settings that determine what actions are recorded — is the responsibility of the tenant, and it changes continuously as operational requirements evolve.

A point-in-time audit — the traditional approach, in which an assessor reviews configuration at a defined moment during the ATO process — produces a compliance picture that is accurate for that moment and potentially inaccurate the next day. An authorized user making a legitimate change to a security group rule, an administrator creating a new service account with overly broad permissions, a developer enabling a feature that changes storage access settings: any of these can introduce a misconfiguration that creates an exploitable gap. In classified environments, that gap may persist for months between audits.

CSPM replaces the point-in-time picture with continuous visibility. In event-driven CSPM architectures, detection latency for a new misconfiguration can be measured in seconds — a newly-created public S3 bucket or an IAM policy change granting excessive privileges triggers an alert before the misconfiguration can be exploited. This is the central value proposition for military workload cloud security: not eliminating the possibility of misconfiguration (which operational realities make unavoidable) but detecting and correcting it before it becomes an intelligence or operational security incident.

Baseline policy frameworks for defense cloud

CSPM is only as useful as the policy baseline it enforces. For defense cloud environments, the applicable frameworks are well-defined but layered, and getting the mapping right is a prerequisite for CSPM findings to be actionable in the ATO context.

DISA STIG Cloud Computing SRG. The Security Requirements Guide for Cloud Computing is the authoritative DISA document that defines security controls for all DoD cloud deployments. It overlays NIST 800-53 with DoD-specific requirements and assigns control responsibilities across the cloud service provider, the tenant, and their shared boundary. The SRG defines requirements at the virtualization layer, the operating system layer, the application layer, and the cloud service layer — all of which must be addressed in a DoD ATO package. CSPM policy rules must be mapped to SRG control identifiers so that findings can be directly linked to ATO requirements.

NIST SP 800-53 Rev 5. The underlying control catalog for all federal systems. For cloud, the most relevant control families are: Configuration Management (CM) — preventing and detecting unauthorized configuration changes; System and Communications Protection (SC) — encryption in transit and at rest, network segmentation; Audit and Accountability (AU) — logging, log integrity, and log retention; and Access Control (AC) / Identification and Authentication (IA) — IAM policy and privilege management. A well-configured CSPM deployment maps rules to specific control IDs (e.g., CM-6, CM-7, AC-3, AU-2) so that each finding carries its control reference.

FedRAMP High baseline. Cloud services used by DoD systems at IL4 and IL5 must carry FedRAMP High authorization or equivalent. The FedRAMP High baseline extends 800-53 Rev 4/5 with stricter parameter values — for example, requiring multi-factor authentication for all privileged and non-privileged accounts, not just privileged. CSPM policy packs for FedRAMP High are available for AWS, Azure Government, and GCP, and these form the starting point for tenant-side CSPM configuration in most defense deployments.

The following table illustrates how key CSPM check categories map across the three primary frameworks:

Misconfiguration detection: what CSPM scans

The attack surface that CSPM addresses in defense cloud breaks down into five primary categories. Each represents a class of misconfiguration that has appeared in real DoD ATO findings and that creates exploitable conditions if not caught continuously.

IAM misconfigurations are the most common high-severity finding category. Overly permissive role policies — particularly policies using wildcard resource specifiers (Resource: "*") for sensitive actions, or attaching administrative policies to non-administrative principals — violate the principle of least privilege and create lateral movement paths for an attacker who compromises any principal with those permissions. CSPM IAM checks look for: unused roles and access keys (stale credentials that were never deprovisioned), privilege escalation paths (role policies that allow a principal to modify their own permissions), cross-account trust relationships, and root account activity.

Network exposure checks identify security group rules, network ACLs, or firewall policies that permit inbound access from unrestricted address ranges (0.0.0.0/0 or ::/0) on sensitive ports — SSH (22), RDP (3389), database ports, and management interfaces. In classified cloud, any exposure of management interfaces to broad network ranges is a Category I STIG finding. CSPM network checks also verify that VPC flow logging is enabled, that public IP assignment is not enabled on private-subnet resources, and that network peering relationships are appropriate.

Encryption-at-rest gaps are a FedRAMP High and STIG hard requirement — every volume, database, and object store holding DoD data must be encrypted with a FIPS 140-2 validated algorithm. CSPM encryption checks enumerate storage resources (EBS volumes, RDS instances, S3 buckets, DynamoDB tables) and flag any that are unencrypted or encrypted with a non-validated algorithm. Key management checks verify that encryption keys are customer-managed (CMK) rather than provider-managed where required by the SSP, and that key rotation is enabled.

Logging gaps are a particularly insidious misconfiguration because their absence is invisible until after an incident requires forensic reconstruction. CSPM logging checks verify that CloudTrail (or equivalent) is enabled in every region and account, that log storage has integrity validation enabled (CloudTrail log file validation, for example), that log retention meets the minimum retention period (typically 1–3 years for DoD systems), and that management events — API calls that modify configuration — are specifically captured. Logging gaps directly violate AU control family requirements and can produce ATO findings that are difficult to compensate for architecturally.

Public storage exposure — object storage buckets with public read or write access — remains in CSPM check sets because it continues to appear in real incidents. In defense cloud, a misconfigured S3 bucket or Azure Blob container with public access represents a direct CUI or classified data exposure path. CSPM checks for bucket-level public access block settings, bucket ACLs, bucket policies permitting unauthenticated access, and public access at the account level (AWS S3 Account Public Access Block).

A typical CSPM scan result for a medium-complexity defense cloud environment might look like:

CSPM Scan Summary — GovCloud Account: 123456789012
Scan Date: 2026-06-25T08:14:32Z  |  Framework: FedRAMP-High + STIG-SRG

Category                  Total  PASS   FAIL   WARN   SUPPRESSED
────────────────────────────────────────────────────────────────
IAM                         142   118     17      4          3
Network Security             89    82      5      2          0
Encryption at Rest           54    51      2      1          0
Audit Logging                31    28      3      0          0
Public Exposure              18    18      0      0          0
Key Management               22    20      1      1          0
────────────────────────────────────────────────────────────────
TOTAL                       356   317     28      8          3

Severity Breakdown (FAIL):
  Critical / Cat-I:   3  ← SLA: 15 days
  High     / Cat-II: 14  ← SLA: 30 days
  Medium   / Cat-III: 11  ← SLA: 90 days

Drift detection and policy enforcement

A CSPM scan captures posture at a point in time; drift detection captures posture change. In operational defense cloud environments, configuration changes are frequent — infrastructure-as-code deployments, administrator actions, service account provisioning, feature flag updates, and cloud provider maintenance can all alter resource configurations. Drift detection identifies when the current state diverges from the approved baseline, and it does so with latency appropriate to the risk.

The two primary scanning architectures are scheduled scanning and event-driven scanning. Scheduled scanning runs a full configuration sweep on a defined interval — hourly, every four hours, or daily — and is the baseline approach for most CSPM deployments. It is simple, comprehensive, and works well for lower-velocity environments. Its limitation is latency: a misconfiguration introduced immediately after a scan cycle may not be detected for nearly the full interval.

Event-driven scanning reduces this latency to seconds by triggering targeted checks when configuration change events are detected. AWS EventBridge can route CloudTrail events for specific API calls (CreateBucket, PutBucketAcl, AuthorizeSecurityGroupIngress, AttachRolePolicy) to a CSPM evaluation function that checks only the affected resource immediately after the change. This architecture is essential for the highest-risk check categories — IAM and network exposure — where the window between misconfiguration creation and exploitation may be hours rather than days.

Automated remediation guardrails take event-driven detection one step further: upon detecting a misconfiguration, the CSPM system automatically corrects it without waiting for human action. A guardrail against public bucket creation, for example, would detect a new bucket with public access enabled and immediately set the public access block, then alert the security team and create a ticket documenting what happened. Guardrails are powerful but require careful scoping. In defense environments, conservative guardrail design is warranted:

• Apply auto-remediation only to controls where the corrective action is unambiguous and the risk of disrupting legitimate operations is near-zero (disabling public access on storage, enforcing MFA token requirements)
• Never auto-remediate IAM policy changes or network rule modifications without dependency validation — applications may depend on the configuration being corrected
• Every automated remediation action must be logged and generate an alert — guardrails must not create invisible configuration state
• Maintain a break-glass suppression mechanism so that an authorized administrator can block auto-remediation for a specific resource during planned maintenance windows

Break-glass exception handling is the complementary process for situations where remediation cannot occur immediately. If a CSPM finding cannot be corrected within SLA due to a technical constraint or operational dependency, the ISSO initiates a formal risk acceptance workflow: document the finding, identify compensating controls, obtain AO signature on a time-bounded acceptance, and record the exception in eMASS as an open POA&M item. The CSPM tool should reflect accepted exceptions by suppressing the finding from active dashboards while retaining it in audit history, and should automatically re-surface the finding when the acceptance period expires.

CSPM in air-gapped and IL4/IL5 environments

The standard commercial CSPM deployment model — a SaaS platform that connects to cloud APIs, aggregates findings in a vendor-hosted backend, and provides a web dashboard — is fundamentally incompatible with IL5 and classified cloud requirements. Data about classified cloud configurations, resource inventories, IAM structures, and security findings cannot leave the classification boundary to a vendor's commercial cloud. Even at IL4 (Controlled Unclassified Information), many programs apply conservative data handling that precludes SaaS CSPM.

This creates an architectural constraint that defense CSPM deployments must solve explicitly. The viable approaches are:

On-premises CSPM engine deployment. Open-source CSPM engines — Prowler (AWS), Steampipe with compliance mods, Checkov (IaC static analysis), or Scout Suite — can be deployed entirely within the classified enclave. The tool runs inside the boundary, queries cloud APIs from within the boundary, stores findings in an internal database, and generates reports that never leave the classification boundary. This approach requires operational ownership of the CSPM tool itself (updates, signature maintenance, rule pack management) but provides full control and no data egress risk.

Authorized commercial CSPM at impact level. Several commercial CSPM products hold FedRAMP High authorizations and offer deployment modes in AWS GovCloud or Azure Government regions. These can be acceptable for IL4 workloads when the CSPM tool's data handling is within the authorized boundary. Programs should verify that the specific CSPM product's FedRAMP authorization covers the data types being assessed and that the product operates in a GovCloud-resident deployment, not a commercial-region backend that receives GovCloud data.

The agentless vs. agent-based scanning trade-off is significant in classified environments:

Agentless CSPM queries cloud provider APIs (AWS Config, Azure Resource Graph, GCP Asset Inventory) to enumerate and assess cloud-native resources. It requires no software installed on compute instances, has zero performance impact on workloads, and is straightforward to authorize because the attack surface is limited to the read-only API credentials. However, it is blind to OS-level configuration state — it can verify that an EC2 instance has the correct security group attached but cannot verify whether the OS firewall is correctly configured or whether a prohibited service is running inside the instance.

Agent-based CSPM installs a lightweight sensor on each compute instance that provides OS-level visibility: running processes, installed packages, file integrity monitoring, OS-level configuration settings that correspond to STIG host controls. This provides coverage for controls that cloud APIs cannot assess. The trade-off is that the agent software itself must be authorized at the applicable classification level, deployed through the accreditation process, and maintained (updates, signature changes) within the classification boundary. For classified environments, the agent authorization process is often the primary constraint on agent-based CSPM adoption.

Most mature IL4/IL5 CSPM deployments use agentless scanning for cloud-API-visible controls and a separate HBSS (Host-Based Security System) or endpoint agent solution — often the DoD-standard McAfee HIP/HBSS — for host-level STIG compliance, integrating both data sources into a unified compliance dashboard. This DevSecOps for defense pipelines posture, where CSPM feeds into the same compliance record as pipeline security controls, provides the most complete ATO evidence picture.

Remediation workflow integration

CSPM findings that exist only in the CSPM tool's dashboard have limited value for a defense program. The institutional process for tracking security findings is the POA&M in eMASS — and CSPM findings must flow into that process automatically, not through manual transcription by an ISSO who checks the CSPM dashboard and manually copies findings into eMASS records.

The integration architecture for classified programs typically involves two stages. First, CSPM findings are exported to the program's authorized ticketing or issue-tracking system — ServiceNow Government Cloud, Jira on a classified instance, or a custom tool — where they become actionable work items assigned to the cloud platform team or application team responsible for the affected resource. Each ticket carries the CSPM finding identifier, affected resource ARN or equivalent, severity, applicable compliance control references, recommended remediation procedure, and SLA due date calculated from the finding creation timestamp and severity-based SLA policy.

SLA tracking must be explicit and visible to program leadership. A finding that ages past its SLA without closure should trigger automatic escalation: first to the team lead, then to the ISSO, then to the system owner. Programs should publish a weekly SLA compliance metric — percentage of findings closed within SLA by severity — as a program health indicator that feeds into the continuous monitoring reporting the AO receives.

For classified infrastructure, ticketing integration carries additional constraints. Tickets containing specific finding details (resource names, IP addresses, configuration specifics) may need to exist on classified systems if the information itself is classified. Programs should evaluate whether CSPM finding details rise to CUI or above — often they do, particularly when findings describe network exposure of resources with classified hostnames — and route tickets accordingly. Unclassified summary metrics (finding counts, SLA performance) can be reported on unclassified systems.

Risk acceptance workflows formalize the handling of findings that cannot be immediately remediated. The workflow is:

1. ISSO submits a risk acceptance request documenting: the specific finding, the technical or operational reason remediation is not immediately feasible, identified compensating controls that reduce risk in the interim, and the proposed acceptance period (not to exceed 90 days for High-severity findings)
2. Security team reviews and validates the compensating control claims
3. AO reviews and signs the risk acceptance memo, formally accepting residual risk
4. Finding is entered as an open POA&M item in eMASS with the signed memo attached
5. CSPM suppresses the active finding alert while retaining it in audit history, tagged with the acceptance record number
6. A calendar reminder is set for 30 days before acceptance expiry to initiate renewal or remediation

This process ensures that accepted exceptions are visible to the AO, time-bounded, and not silently accumulating. Zero trust microsegmentation defense architectures benefit directly from this workflow because microsegmentation policy changes that affect CSPM findings must be tracked through the same formal exception process to maintain ATO continuity.

Continuous compliance reporting

The ATO process for DoD systems under the Risk Management Framework (RMF) requires a comprehensive Body of Evidence (BOE) demonstrating that security controls are implemented and effective. For cloud infrastructure controls, this evidence traditionally consisted of manually-generated STIG scan reports and configuration screenshots produced at assessment time. CSPM enables a fundamentally different model: evidence generated continuously and available on demand, rather than produced during an intensive evidence-gathering sprint before each assessment.

A CSPM continuous compliance reporting architecture produces three categories of output:

Automated ATO evidence packages. CSPM compliance reports, exported on a weekly cadence and before every assessment event, provide structured evidence of control implementation status. Reports are mapped to eMASS control identifiers — a CSPM report filtered to AU-2 findings demonstrates the state of audit event configuration; a CM-6 report demonstrates configuration baseline enforcement. These can be pushed to eMASS via the REST API or uploaded as evidence artifacts. The ISSO's role shifts from generating evidence to reviewing and certifying evidence that the system generates automatically.

Control inheritance mapping. In cloud environments using the shared responsibility model, many controls are inherited from the CSP (Cloud Service Provider) rather than implemented by the tenant. CSPM must be configured to reflect this inheritance: checks for physical access controls, hypervisor patching, and data center physical security map to CSP-inherited controls and should not appear as tenant findings. Tenant-responsible controls — IAM, network, encryption, logging — are the CSPM scope. A properly configured CSPM system produces an inheritance map that matches the system security plan, avoiding both false findings on inherited controls and gaps on tenant-responsible controls.

Automated POA&M updates. Open CSPM findings should flow automatically into the eMASS POA&M as open items. As findings are remediated and CSPM verifies the corrected configuration, the corresponding POA&M items should be updated with closure evidence. This closes the loop between the security tool and the authoritative record of control implementation — the ISSO no longer needs to manually transfer information between systems, and the AO always has an accurate picture of open findings and their remediation status.

A sample CSPM-to-eMASS integration flow illustrates the data movement:

# CSPM → eMASS integration (illustrative)

CSPM Finding:
  id: CSPM-2026-06-25-0041
  check: aws-s3-bucket-encryption-enabled
  resource: arn:aws:s3:::dod-app-data-prod
  severity: High
  controls: [SC-28, SC-28(1), SRG-APP-000428]
  status: FAIL
  detected: 2026-06-25T09:14:22Z
  sla_due: 2026-07-25T09:14:22Z

eMASS POA&M Entry (auto-created):
  weakness_name: S3 bucket without encryption at rest
  control: SC-28(1) / SRG-APP-000428
  scheduled_completion: 2026-07-25
  milestone: Enable SSE-KMS with CMK on bucket dod-app-data-prod
  resources_required: Cloud platform team, 2h estimated
  status: Ongoing
  evidence_artifact: cspm-finding-CSPM-2026-06-25-0041.json

The long-term payoff of this integration is a transformation in how ATO renewals work. Instead of an intensive pre-assessment evidence collection period — which in traditional programs consumes weeks of security team time and introduces the risk of evidence gaps — a program with mature CSPM integration can generate a current, complete evidence package in hours. The continuous monitoring data is the evidence. This is the operational model that DoD's move toward ongoing authorization (continuous ATO) envisions, and CSPM is the foundational tool that makes it achievable for cloud-hosted defense workloads.