The Cloud Migration Security Debt Nobody's Counting

We moved to the cloud faster than we knew how to secure it. The bill for that is still sitting there, unopened, in nearly every environment I see.

I do a fair bit of cloud security assessment work, and I see the same thing over and over. It's not that people don't care. They do. The cloud just moves faster than security programs can, and the gap between the two has a name.

Standing up infrastructure in the cloud is fast. Spin up a VM, mint an identity, open a port, put a database in prod — you can do all of it in an afternoon. Doing it properly takes longer than an afternoon. So in a lot of shops the proper part just doesn't happen. Or it happens later, when there's time. Which there never really is.

That gap is security debt. The distance between the security posture you think you have and the one you actually have. The thing about cloud debt is it doesn't grow the way on-prem debt grew. It compounds. Every new workload adds a little to the pile, and most of the pile never gets looked at again.

Where the Debt Accumulates

The debt piles up in three places, mostly: identity, network, and data. Identity is the worst of them by a fair margin.

Old-school IAM was built for a world where you onboarded a few hundred employees a year and that was about it. Cloud doesn't work that way. You get users, sure, but you also get service accounts, API keys, IAM roles, cross-account trusts, and a long tail of short-lived credentials that aren't always as short-lived as advertised. First time we run the actual inventory for a client, the number is usually two or three times what they were guessing. Then we look at what those identities can do, and that's a different conversation again. Most of them can do far more than the job calls for. They're unlocked doors, basically, and nobody's been counting the doors.

Network is the next one. Defaults in most cloud platforms are more permissive than people assume, and during a migration the priority is always "just get it working." Whatever got stood up to make day one work tends to stay that way. Nothing's blocking, so nobody touches it. Works fine until it doesn't.

What's different about cloud debt is the blast radius. One bad bucket policy, one over-permissioned service account, and you can expose a volume of data that wasn't physically possible on-prem. The mistake takes ten seconds. The cleanup takes months.

Why It Is Harder to See

On-prem, at least you could feel the debt. You could walk through the data centre and see the rack of gear that should have been retired two years ago. It was just there.

In the cloud the debt is invisible. It lives in JSON policies and routing rules and config files nobody opens unless something has already gone wrong. The native dashboards are fine for what they are, but they show you what you have, not what is risky. There's a difference.

So nothing gets done about it until something makes it impossible to ignore. An incident. An auditor. A customer security questionnaire that goes from polite to insistent. By then what could've been a tidy bit of cleanup is a project with a budget and a steering committee.

How to Start Counting

The start of a fix is just to start counting. If you don't know how big the debt is, you can't make a case to anyone about paying it down. There are three exercises I keep coming back to because the effort-to-insight ratio is good.

First, an identity audit. List every identity in the environment, people and non-people, and look at what they can actually do — the effective permissions, after the role chaining and inherited grants get worked out. That report tends to land hard. It's hard to argue with a list of admin accounts that haven't been logged into in eight months.

Second, a network config review. What's actually deployed versus what the architecture diagrams claim is deployed. They almost never match. You'll find a security group open to 0.0.0.0/0 because someone needed to test something a couple of years ago and never closed it, and you'll find at least one bucket or service that's public for a reason nobody on the call can quite remember.

Third, data discovery. Where is sensitive data actually living right now, not where the data map says it's living. Those two drift apart fast, and the drift is where most of the bad news comes from.

None of that pays the debt down. It puts a number on it. But that's the whole thing, really — once there's a number, somebody can make a decision. Up to that point you're just hoping nothing bad happens, and hope is not a control.

These three activities will not eliminate cloud security debt. But they will make it visible, which is the prerequisite for managing it.