We kept our titles when we moved to the cloud. Security Analyst. Network Engineer. SysAdmin. The titles stayed. The physics changed. Every assumption baked into those roles, where trust comes from, how you fix things, what you harden, where truth lives was a property of physical machines in physical rooms. The cloud has none of those properties.
Five mental models from the data center era are still in the heads of the people who secure it. Each one creates a gap. The attacker doesn't have these mental models. The attacker sees the cloud as it is: software-defined everything, where the API is the control plane, identity is the perimeter, and the observed state is the only state that matters.
1. Trust is based on location
Data center model: If I know your IP is 10.0.1.5, I know who you are and which rack you're in. Trust comes from the network segment. Inside the perimeter is trusted. Outside is untrusted.
Cloud reality: IPs are ephemeral. A Lambda function might have a different IP every invocation. An ECS task gets a new ENI when it starts. Trust comes from identity such as IAM roles, service accounts, OIDC tokens. The network segment tells you nothing about the caller.
The gap: Security teams spend 80% of their effort on security groups, NACLs (stateless network filters at the subnet level), and firewall rules. Location-based controls. Meanwhile, the attacker ignores the network entirely. They steal an IAM credential often through the Instance Metadata Service (IMDS), the endpoint every EC2 instance exposes at 169.254.169.254. An SSRF vulnerability in the application code lets the attacker reach IMDS, extract the instance role's temporary credentials, and use them from anywhere.
AWS has mitigated the simplest form of this by defaulting newer instances to IMDSv2, which requires a PUT request to obtain a session token before credential retrieval. That blocks trivial SSRF. But the structural argument remains: more complex SSRF (where the attacker controls request headers) can still obtain credentials, and credentials stolen through any path such as SSRF, leaked environment variables, exposed .aws/credentials files, social engineering can work from any network location the IAM policy permits. The network boundary is irrelevant to the credential's scope.
What it produces: Organizations build Zero Trust networks and leave Infinite Trust IAM roles attached to the resources inside them. The network is segmented. The identity is not segmented. An IAM role with s3:* on * renders every network boundary irrelevant. The role can reach every bucket regardless of which subnet the compute sits in.
Network segmentation still provides defense-in-depth such as VPC endpoints, security groups, and NACLs constrain the blast radius of a compromised workload at the network layer. But teams systematically over-invest in network controls while under-investing in IAM. The current industry imbalance is the gap, not the existence of network controls.
What security reasoning requires: Evaluate identity paths, not just network paths. The question isn't only "can traffic reach this subnet?". It's "can this identity reach this resource through any combination of role assumptions, policy attachments, and trust relationships?" That question is about IAM. The privilege escalation controls in tools like Stave exist because the identity path is the primary attack surface. The network path is defense-in-depth, not the perimeter.
2. Fixing means patching
Data center model: Fixing a vulnerability means logging into a server and running yum update. The server is a pet that is long-lived, manually maintained and unique.
Cloud reality: Fixing a vulnerability means updating a Dockerfile and triggering a redeploy. The server is cattle that is short-lived, immutable and replaced not repaired. If you patch a running EC2 instance, that patch disappears the moment the Auto Scaling Group replaces the instance with a fresh image.
The gap: Vulnerability management teams scan running instances and send spreadsheets of missing patches to developers. The developers ignore them because they don't patch servers. They update a base image, push to the registry, and redeploy. The scan reports on hosts that will be replaced in hours. The images remain vulnerable in the registry where nobody scans them.
What it produces: A Scan-and-Patch cycle that's too slow for the Build-and-Deploy cycle. The organization has passing scans on hosts that are already dead while the images that will create the NEXT generation of hosts carry the same vulnerabilities.
What security reasoning requires: Shift the scan target from the running instance to the image in the registry. The image is the source of truth. The running instance is a derivative. Patching the derivative is wasted effort. Patch the source.
3. Hardening targets the operating system
Data center model: Hardening means disabling unused services on Linux, tuning the kernel, locking down SSH, running CIS benchmarks against the OS.
Cloud reality: The attacker doesn't exploit your Linux kernel. They phish a console password. They find a leaked ACCESS_KEY in a public GitHub repo. They call the AWS API to snapshot a database disk, copy the snapshot to their own account, and restore it. The OS never saw a login. The EDR agent never fired. The data is gone.
The gap: Companies spend millions on Endpoint Detection and Response (EDR) and OS hardening. They have zero monitoring on their CloudTrail logs. They watch the front door (the OS) while the attacker walks through the industrial control room (the Cloud API console).
What it produces: An attacker who uses aws rds create-db-snapshot followed by aws rds modify-db-snapshot-attribute to share the snapshot with an external account. The database is exfiltrated without touching the OS, the network, or the application. Every OS-level security control is irrelevant. The attack happened entirely through the cloud API.
What security reasoning requires: Treat the cloud API as the primary attack surface. IAM is the new kernel. Just as we used to audit /etc/sudoers to understand who could run privileged commands on a server, we now need to audit AssumeRolePolicyDocument to understand who can assume privileged roles in the account. Monitor CloudTrail the way you monitor SSH logs. Evaluate IAM policies the way you evaluate OS permissions. The rds:CreateDBSnapshot permission on an IAM role is the cloud equivalent of sudo access on a server and it's far less monitored.
4. Resilience means redundant hardware
Data center model: Disaster recovery means a second set of hardware in a bunker in another city. The warm site. Physical redundancy for physical failures.
Cloud reality: Hardware is an abstraction. Disaster recovery means the Terraform state file can provision the entire stack in another region. Resilience is a configuration property, not a physical one.
The gap: Organizations perform DR drills where they fail over to another region manually. But because the infrastructure-as-code isn't unified, the DR region has different IAM roles, secrets and DNS settings. The Terraform in the DR region references ARNs from the primary region where ARNs that don't exist when the primary is down.
What it produces: The DR site fails to spin up during a real outage because a hardcoded ARN points to a resource in the dead region. The DR plan was a physical plan for a logic problem. The hardware failed over. The configuration didn't.
What security reasoning requires: Detect ghost references. The resources that point to dependencies that no longer exist or exist in a different region. An ARN referencing a KMS key in us-east-1 from a role in eu-west-1 is a ghost reference. It works until us-east-1 is unavailable. Then the role can't decrypt anything. Ghost reference detection catches these before the outage reveals them.
5. Documentation is the source of truth
Data center model: If a technician changed a cable, they updated a spreadsheet. The spreadsheet was the record of the infrastructure. Audits checked the spreadsheet.
Cloud reality: The Terraform repository is the intended state. The actual cloud environment is the observed state. They are not the same. Someone clicked Modify in the AWS Console at 2 AM to fix a production bug. The Terraform was never updated. The desired state says the bucket is private. The observed state says the public access block was manually disabled three weeks ago.
The gap: Security audits evaluate the Terraform repository which is the desired state. The breach happens against the cloud environment which is the observed state. The audit passes the code. The cloud is leaking.
What it produces: Configuration drift. The security team certifies the infrastructure as compliant based on the IaC source. The infrastructure has drifted from the source because a human made a manual change. The compliance certificate describes a system that doesn't exist. The system that exists wasn't audited.
What security reasoning requires: Evaluate the OBSERVED state, not the desired state. Snapshot the live cloud environment via API calls. Evaluate the snapshot. The snapshot captures observed state, including manual changes, console modifications, and API calls that bypassed the deployment pipeline. If the Terraform says public_access_block = true but the snapshot shows it's disabled, the snapshot is right. The Terraform is a historical document.
This is a fundamental architectural decision for security tooling. Tools that evaluate Terraform source (Checkov, tfsec, Sentinel) answer: "does the intended configuration meet policy?" Tools that evaluate live snapshots answer: "does the ACTUAL configuration meet policy?" Both are useful questions. Only the second catches drift. Breaches hide in the drift because the drifted configuration was never reviewed, approved and tested.
The common pattern
All five models share one structural property: they assume a physical constraint that the cloud removed.
Data center constraint: Cloud equivalent:
─────────────────────── ─────────────────────────────
Physical network perimeter → Software-defined identity (IAM)
Physical server → Immutable image in a registry
Physical OS on bare metal → API-accessible control plane
Physical hardware in bunker → Configuration state in code
Physical cable + spreadsheet→ API call + observed state
Each physical constraint provided a security property for free. The network perimeter provided trust without IAM. The physical server provided persistence without image management. The OS provided the attack surface without API monitoring. The hardware provided redundancy without configuration unification. The spreadsheet provided truth without drift detection.
The cloud removed the physical constraint. The security property it provided didn't get replaced, it just disappeared. The mental model persists ("we have a firewall, we're segmented") while the reality changed ("identity ignores the firewall entirely").
The Su-Field structure
The pattern is the same across all five:
Before (data center):
F (physical constraint) produces TWO outputs:
Output 1: Operational function (networking, patching, hardening, DR, auditing)
Output 2: Security property (isolation, integrity, surface reduction, resilience, truth)
After (cloud):
F' (software-defined) replaces F
Output 1: Operational function preserved (faster, more flexible)
Output 2: Security property LOST (no physical constraint to provide it)
Resolution:
Keep F' (the operational benefits are real)
Add F2 (explicit security mechanism that provides the lost property)
F2 for identity: IAM path analysis, privilege escalation detection
F2 for patching: Image scanning at the registry, not the instance
F2 for hardening: CloudTrail monitoring, API permission evaluation
F2 for DR: Ghost reference detection, cross-region config validation
F2 for truth: Live snapshot evaluation, drift detection
The physical constraint was one field that produced both operational and security outputs. The cloud split them. The operational output survived (faster deployment, elastic scaling, multi-region). The security output didn't. Each F2 above is a specific mechanism that restores the specific security property that the corresponding physical constraint used to provide for free.
What this means for practitioners
The next time you evaluate your cloud security posture, ask five questions:
1. Am I auditing identity or location? If your security review focuses on security groups and NACLs but doesn't trace IAM role assumption chains, you're auditing the screen door, not the control room.
2. Am I scanning the source or the derivative? If your vulnerability scans target running instances but not the container images in the registry, you're patching cattle that will be replaced tomorrow.
3. Am I hardening the OS or the API? If you have EDR on every EC2 instance but no alerts on CloudTrail for rds:CreateDBSnapshot or iam:CreateAccessKey, you're watching the front door while the data walks out through the API.
4. Am I testing hardware failover or configuration failover? If your DR drill tests "can the hardware come up in another region" but not "do the IAM roles, secrets, and ARN references work in another region," your DR plan is physical in a world that's logical.
5. Am I auditing the code or the cloud? If your compliance assessment evaluates the Terraform repository but not a live snapshot of the actual environment, your certificate describes a system that may not exist. The 2 AM console change isn't in Terraform. It's in the cloud. Only the snapshot sees it.
Five questions. Each reveals whether your security model has been updated for the cloud or whether you're still running data center assumptions against software-defined infrastructure.
Three of these five gaps are addressed directly by Stave: identity path analysis (Problem 1 — privilege escalation controls trace IAM chains through four policy layers), API control plane evaluation (Problem 3 — 4,400+ controls covering cloud API permissions with 670+ compound chains composing cross-resource risk), and observed-state snapshot evaluation (Problem 5 — evaluates live cloud configuration, not IaC source). Ghost reference detection (Problem 4) is a core differentiator — detecting resources that reference deleted dependencies. Apache 2.0.
