✓ Human-authored analysis; AI used for formatting and proofreading.
The Cloud Security Alliance and Cisco recently published Preparing Your Networks for the AI Storm, a paper by Rich Mogull arguing that AI-accelerated attacks have collapsed the timelines defenders relied on. The recommendations are practical: harden what's exposed, segment what's flat, build toward Zero Trust.
The paper is right. But it describes what to do, not how to verify you did it.
That gap is filled by configuration verification. Every recommendation in the paper that maps to a cloud configuration property can be checked automatically, continuously, and without credentials. This article maps the paper's three phases to specific automated checks and shows what coverage looks like when every in-scope recommendation has a corresponding verification.
The Paper's Argument
AI has shifted the economics of offense. Exploit development that took months now takes hours. The defensive response is to increase attacker costs through security boundaries — network segmentation, patching cadence, and serial defensive layers. The paper lays out three phases: harden what you have (Phase 1), add segmentation boundaries (Phase 2), and drive toward microsegmentation and Zero Trust (Phase 3).
Every phase contains actionable recommendations. Most of them map to AWS configuration properties that either exist or don't.
Phase 1: Seven Immediate Actions — All Verified
Phase 1 is "outside in, key assets first." Identify what's internet-facing, harden management interfaces, enforce MFA, filter egress, add WAFs, audit automation secrets, and keep everything current.
External Attack Surface
The paper recommends identifying every internet-reachable device and service. In AWS, this means security groups with 0.0.0.0/0 inbound rules, public subnets with auto-assign public IP, internet gateways, public-facing load balancers, API gateways, CloudFront distributions, and S3 buckets with public access.
This is the most deeply covered area in the catalog. Across S3, EC2, RDS, ELB, CloudFront, API Gateway, and a dozen other services, there are hundreds of controls checking for unintended public exposure. Every major AWS service that can be internet-facing has dedicated exposure checks.
The depth matters. It's not just "is this security group open". It's "is this security group open AND is the resource behind it in a public subnet AND does it have a public IP AND is there no WAF in front of it." Component checks find individual misconfigurations. Compound checks find the combination that makes them exploitable.
Management Interface Exposure
The paper says to disable management interfaces exposed to the internet or DMZ. In AWS: SSH and RDP ports open to the world, serial console access enabled, key pair governance, and IMDS hardening.
The catalog checks all of these. SSH/RDP port restriction, SSM-preferred-over-SSH controls, serial console disabled, IMDS v2 enforcement (18 controls covering EC2, ECS, and EKS), and ECS exec controls. If Systems Manager is available, direct SSH access is unnecessary attack surface.
MFA, Egress, WAF, Secrets
These four recommendations each have strong coverage:
MFA enforcement spans root account hardware MFA, IAM user console MFA, Cognito MFA configuration, S3 MFA delete, and SSO MFA settings.
Egress filtering covers security group egress rules, Route53 DNS Firewall association, DNS exfiltration patterns, VPC endpoint force-routing (to keep traffic off the public internet), and NAT Gateway monitoring.
WAF checks verify association with ALBs and CloudFront distributions, logging enablement, bypass detection (can traffic reach the origin without passing through the WAF?), and consistency across deployments.
Secrets in automation checks cover Lambda environment variable encryption, CodeBuild environment secrets, EC2 userdata credential scanning, access key governance, and Secrets Manager rotation policies.
Version Currency
The paper recommends keeping everything current and patchable. In AWS managed services, this translates to runtime and engine version checks. Lambda runtime deprecation, RDS engine end-of-life, EKS cluster version, ElastiCache engine currency, and OpenSearch engine version all have dedicated controls. Each checking the running version against AWS's deprecation schedule.
Physical hardware patching is out of scope. A cloud configuration verifier checks cloud services, not router firmware.
Phase 2: Three Segmentation Actions — All Verified
Phase 2 adds security boundaries. The paper describes macrosegmentation (isolate stacks from each other), east-west isolation (prevent lateral movement within a stack), and inline tier boundaries (each application tier talks only to its neighbors).
Macrosegmentation
The paper recommends isolating application stacks so that a compromise of less-valuable resources doesn't become the easy path to critical assets.
VPC-level segmentation is covered across multiple layers: default VPC detection, VPC peering controls (10 controls covering routes, DNS resolution, and CIDR overlap), subnet tiering, and bastion host placement.
Transit Gateway — the standard hub-and-spoke architecture for multi-account AWS has dedicated controls for route table isolation, auto-accept attachment, default route table association, and propagation scope. Route table isolation is the critical check: a Transit Gateway where all attachments share a single route table is a flat network with extra steps. The control verifies that segments are actually isolated, not just labeled.
East-West Isolation
The paper says to isolate from east-west attacks. In AWS, this is security group rules between tiers, NACL rules, flow logs for visibility, and network boundary enforcement.
Security group east-west controls check for unrestricted internal traffic patterns — self-referencing rules, broad RFC 1918 CIDR sources, and the specific case where security group source CIDRs don't cover all subnets in the VPC. This gap only appears after VPC CIDR expansion, when new subnets fall outside existing security group rules.
Transit Gateway segmented routing verifies that route propagation doesn't leak across segments — preventing the case where a compromised workload in one segment can route to resources in another through the hub.
Flow logs provide the visibility layer: 13 controls verify VPC flow log enablement, format, destination, and encryption.
Inline Tier Boundaries
The paper recommends that each tier of an application should only communicate with the tier above and below it, on expected ports only. In AWS, this is VPC segment tiering controls, private subnet enforcement, NACL port restriction, and VPC endpoint policies that scope S3 and DynamoDB access per subnet.
This includes an ECS-specific control that verifies service security groups only allow traffic from the load balancer — a tier boundary enforcement at the container level.
Phase 3: Three Strategic Actions — All Verified
Phase 3 is microsegmentation and Zero Trust. The paper frames this as the long-term destination: identity-based access per connection, fine-grained resource policies, and continuous visibility.
Least Privilege and Resource Policies
IAM least-privilege checks span admin policy detection, wildcard action usage, and separation of duties. Service Control Policies add organization-level guardrails. Resource policies on S3, KMS, SNS, SQS, and other services verify per-resource access controls.
A Lambda-specific control checks whether execution roles are shared across functions — the microsegmentation principle applied to serverless compute.
Visibility
The paper emphasizes that visibility underpins everything. CloudTrail (management and data events, organization trails, integrity validation), GuardDuty (enabled with all protection features), AWS Config (recording all resource types), SecurityHub, CloudWatch alarms for security events, and access logging on S3, ALB, CloudFront, and NAT Gateways — all have dedicated controls.
The detection-absence chains add compound verification: escalation paths that exist alongside absent detection produce critical findings. An IAM escalation path with no CloudWatch alarm is worse than either condition alone — the compound chain catches the combination.
Identity Providers as High-Value Targets
The paper's most interesting point: as you move toward Zero Trust, identity providers become the highest-value targets precisely because everything trusts them. They "earn more scrutiny and more boundaries."
This is the deepest coverage area in the catalog after IAM itself. Cognito alone has 113 controls covering MFA, ghost triggers, advanced security features, federation configuration, and orphan resource detection. IAM Identity Center, OIDC providers (with subject and audience restriction checks for GitHub, GitLab, and Terraform Cloud specifically), SAML federation (audience, certificate rotation, session duration), and cross-account trust all have dedicated control families.
The Datalog-based federation reachability model goes further: it computes transitive paths from external identity providers through role chains to resources, answering questions like "can an external OIDC provider reach this S3 bucket through a chain of role assumptions?" That's not a single control firing. It's a graph traversal across the identity trust boundary.
The Scorecard
| Phase | Recommendations (in scope) | Covered |
|---|---|---|
| Phase 1 — Harden | 7 | 7 |
| Phase 2 — Segment | 3 | 3 |
| Phase 3 — Zero Trust | 3 | 3 |
| Total | 13 | 13 |
Out of Scope
The paper is about physical network hardening — routers, switches, firewalls, hardware patching, data diodes for OT networks. Cloud configuration verification covers the cloud side of the same recommendations. If your network modernization program includes replacing end-of-life switches and adding data diodes to OT networks, no cloud tool checks that for you.
What a cloud tool checks is whether the cloud side of the same principles — segmentation, least-privilege access, egress filtering, visibility is configured the way you intended. The paper says to do these things. Automated verification confirms they're done and catches drift when they stop being done.
The Drift
Mapping recommendations to checks is the easy part. The harder problem is drift.
A security group that was correctly restricted last week may have been widened by a deployment today. A VPC endpoint policy that scoped S3 access to specific subnets may have been broadened during a CIDR expansion. A Transit Gateway that enforced route isolation may have had propagation enabled during a migration and never disabled.
The paper's Phase 2 recommendation to "add boundaries" is only as durable as the verification that confirms boundaries still exist. Most organizations implemented the boundary, verified it once during the project, and never checked again. Continuous verification against a defined specification — like the 13 recommendations in this paper, each mapped to specific checks makes boundaries persistent rather than aspirational.
The paper ends with a choice: "Zero Trust or zero days." Configuration verification adds a third option: verify continuously, so the boundaries you built hold when the storm arrives.
The coverage scorecard is re-verified when controls are added or modified, and monthly via automated regression against the control catalog.
The CSA paper, "Preparing Your Networks for the AI Storm" by Rich Mogull, is available at cloudsecurityalliance.org.
Top comments (0)