Cloud SecurityEP 11
11 Jul 2026
Cloud Management, Compliance, and Providers
Unit 5 of the Cloud Security course in audio form. More observability tools than ever — yet still flying blind. This episode cuts through alert fatigue to expose the critical difference between monitoring and auditing, explains why immutable WORM logs are the only trail a court will trust, and walks through the risk management cycle that keeps the C-suite out of jail. Then the provider showdown: OpenStack gives total control but total liability; Docker containers share a kernel that one escape can compromise entirely; AWS provides scale but the Capital One SSRF breach proved that misconfiguration hands the attacker the keys. Closing with the AWS cross-account enumeration trick that maps your entire IAM structure using nothing but error messages.
0:00 / 0:00
EpochZero Tech Talks: Cloud Management, Compliance, and Providers
Transcript
Conversation between Alex and Maya
Alex (left)Maya (right)
Alex
You know, there is this massive paradox in cloud engineering right now.
Maya
I mean, if you look at modern infrastructure, we have more observability tools than at any point in human history.
Alex
Oh, absolutely.
Maya
We're drowning in tools.
Alex
Right.
Maya
But somehow, we are still flying completely blind.
Alex
For anyone listening who manages cloud deployments, you know the exact feeling.
Maya
The dashboards are just lit up like a Christmas tree.
Alex
The Slack channels are screaming with alerts about CPU spikes, memory leaks, whatever.
Maya
And honestly, it's like driving a car where the check engine, the low tire, and the oil lights are all constantly blinking.
Alex
Which is terrifying.
Maya
Yeah.
Alex
Eventually, you just put tape over the dashboard, the alert fatigue sets in, and it all just becomes white noise.
Maya
It absolutely becomes white noise.
Alex
And that is a really dangerous state to be in when you consider the legal stakes.
Maya
Oh, I'm sure you're going to remind us about the legal stakes.
Alex
You know I am.
Maya
That fatigue is exactly why we are pulling from such a massive stack of sources today.
Alex
We've got recent cloud security postmortems, compliance framework white papers, digital forensics reports, all of it.
Maya
A very light, breezy reading list for our deep dive today.
Alex
Exactly.
Maya
But the mission here is to navigate that treacherous gap between just, you know, spinning up infrastructure and actually surviving a data breach or an audit.
Alex
Right.
Maya
And the very first step is throwing out this huge misconception about what all those blinking dashboard lights actually represent.
Alex
OK, let's unpack this, because from an architect's standpoint, if the lights are green, the app is running.
Maya
If they turn red, something crashed.
Alex
What's the misconception?
Maya
Well, the fatal flaw is treating monitoring and auditing as the exact same thing.
Alex
Oh, they are entirely different operational beasts.
Maya
I mean, monitoring is purely for operational health.
Alex
It looks at the present state — is the server crashing right now?
Maya
Are we out of memory?
Alex
Right.
Maya
Monitoring is what wakes the on-call engineer up at three in the morning to reboot a hung process.
Alex
Exactly.
Maya
Monitoring keeps the business running today.
Alex
But auditing is for forensic accountability.
Maya
Meaning what exactly?
Alex
Auditing is what answers the question: who logged in at 2 a.m. on a Sunday, completely bypassed multi-factor authentication, and deleted the entire customer database?
Maya
Ouch.
Alex
Yeah, that is a brutal distinction.
Maya
Right.
Alex
Monitoring tells your team the database is gone.
Maya
Auditing is the breadcrumb trail that actually reveals whose fingerprints are on it.
Alex
That makes a lot of sense.
Maya
And looking through these forensics reports in our source stack, it's pretty clear that for auditing to actually hold up in court or during a real investigation, standard text logs just sitting on a server aren't going to cut it.
Alex
Not even a little bit.
Maya
Because a hacker can just run a simple rm command or delete the /var/log directory to cover their tracks.
Alex
Which is standard operating procedure for any sophisticated threat actor.
Maya
Once they elevate their privileges, their very first objective is to blind the incident record.
Alex
Just wipe the tapes.
Maya
Exactly.
Alex
That is why your architecture absolutely must utilise immutable log storage.
Maya
We are talking about WORM storage here.
Alex
WORM.
Maya
Write once, read many.
Alex
You got it.
Maya
Immutable logs are records that a hacker absolutely cannot alter to cover their tracks.
Alex
They can't be encrypted by ransomware.
Maya
They can't be deleted, no matter what level of access the attacker gains.
Alex
Wait, really? Even if they compromise the root administrator account?
Maya
Even then.
Alex
The logs remain mathematically and cryptographically intact.
Maya
It functions as the ultimate objective record of truth.
Alex
Okay, but here's where it gets really interesting for me on the deployment side.
Maya
Because setting up immutable, highly available logging architecture is expensive.
Alex
It is.
Maya
It burns through storage budgets.
Alex
It takes processing overhead.
Maya
And frankly, robust logging is never the shiny new feature that the product team actually wants to ship.
Alex
No, it doesn't look great on a marketing brochure.
Maya
Right.
Alex
So, if immutable logs are this ultimate truth serum, who's actually forcing companies to swallow the cost and implement them?
Maya
The driving force is policy and compliance frameworks.
Alex
And I know the word policy makes most engineers instantly want to zone out.
Maya
My eyes just glazed over a little bit.
Alex
Yeah.
Maya
But listen, cloud policy isn't just bureaucratic paperwork.
Alex
It is the literal shield keeping the C-suite out of jail.
Maya
And it all rests on the risk management cycle.
Alex
Ah, the classic textbook cycle.
Maya
Yep.
Alex
Identifying the threats.
Maya
Assessing the impact.
Alex
Prioritising the severity.
Maya
And finally, deciding whether to mitigate, transfer, or accept the risk.
Alex
Management has to execute this loop to legally prove they aren't being negligent.
Maya
Okay, I'm going to jump in there, because I have to push back on how that prioritisation actually happens in the real world.
Alex
Let's hear it.
Maya
Looking at the postmortems we have, that cycle looks beautiful on a slide deck.
Alex
But humans are just incredibly bad at continuously evaluating invisible risks.
Maya
That is entirely fair.
Alex
A company usually only cares about their PCI DSS compliance or GDPR controls the morning after their data is found on the dark web.
Maya
Yep.
Alex
Like, accepting the risk usually just translates to: yeah, we ignored it because we really wanted to ship this feature by Friday.
Maya
I don't disagree with that cynicism at all.
Alex
Human failure in continuous compliance is basically a constant.
Maya
Engineers are rushed.
Alex
Deadlines are super tight.
Maya
And a simple typo in a config file can expose a critical asset.
Alex
Exactly.
Maya
But that exact human friction is exactly why Cloud Security Posture Management — CSPM — tools exist.
Alex
Because we literally can't trust humans to run a compliance checklist every time they push code.
Maya
We really can't.
Alex
A CSPM integrates directly into your environment.
Maya
It continuously and automatically scans your configurations against those policy frameworks in real time.
Alex
So it's basically stepping in to flag or fix issues.
Maya
Like, say someone accidentally leaves a storage bucket publicly accessible.
Alex
The CSPM catches it before it becomes a headline.
Maya
It takes the human error out of the compliance loop.
Alex
So it's an automated babysitter.
Maya
But listen — if public cloud environments require so much automated babysitting just to prevent someone from leaving a digital door wide open, it makes you wonder if maybe the answer is just building the environment from scratch where you actually have total control.
Alex
Oh, boy. Are you pitching what I think you're pitching?
Maya
I am.
Alex
Let's talk about OpenStack.
Maya
Because as an architect, OpenStack is basically the ultimate solution for building private cloud infrastructure as a service.
Alex
It is definitely a choice.
Maya
It's a great choice.
Alex
Yeah.
Maya
You get away from the black boxes of public providers.
Alex
Your engineering team gets total control over every single dial, switch, and hypervisor.
Maya
You dictate exactly how the hardware behaves.
Alex
Okay, let me give you a reality check here.
Maya
It is the ultimate fantasy for an engineer.
Alex
But I have to shut that down.
Maya
Why?
Alex
Because in the cybersecurity and auditing world, the word control is just another word for liability.
Maya
Meaning what?
Alex
Think about it.
Maya
When you use a public cloud provider, you operate under the famous shared responsibility model.
Alex
The provider is legally responsible for the security of the cloud — the physical server racks, the concrete in the data centre, the hypervisor.
Maya
Right.
Alex
And you are just responsible for security in the cloud — the data, the access roles.
Maya
Exactly.
Alex
But in an OpenStack private cloud, that shared responsibility model does not exist.
Maya
You are the provider now.
Alex
You own 100% of the security stack.
Maya
If the underlying hardware or hypervisor is compromised, you are entirely on your own.
Alex
Right.
Maya
If a zero-day exploit hits the hypervisor layer, there is no massive security team in Seattle rolling out a hot fix behind the scenes.
Alex
You have to detect it, patch it, and mitigate it yourself.
Maya
Total control equals total liability.
Alex
Okay, point taken.
Maya
Maintaining bare metal hardware and 100% of the security stack is a literal nightmare.
Alex
So I concede.
Maya
Let's pivot.
Alex
Gladly.
Maya
Where are we pivoting to?
Alex
The developer's absolute favourite toy right now.
Maya
Containerisation, Docker, and the microservice ecosystem.
Alex
A fascinating shift, but one that introduces a completely different threat landscape.
Maya
But from a deployment perspective, it's brilliant.
Alex
I mean, think about it like this. A traditional virtual machine is like hauling an entire mobile home with you wherever you go.
Maya
Heavy, slow?
Alex
Exactly.
Maya
You have to boot up an entire heavy duplicate guest operating system every time.
Alex
But a container is like packing a perfectly organised, ultra-light suitcase.
Maya
That's a good analogy.
Alex
Right.
Maya
It strips away the heavy OS and only packages the exact code and libraries the app needs.
Alex
It is vastly lighter and faster than a VM.
Maya
It is remarkably efficient.
Alex
I'll give you that.
Maya
But from an auditing and forensics perspective, do you know why that container is so lightweight?
Alex
Well, yeah, because it doesn't carry a full OS kernel inside it.
Maya
And that right there is the massive architectural security flaw.
Alex
Every single container running on that host shares the exact same host OS kernel.
Maya
Wait, so instead of hardware-level isolation, they're just isolated processes all sipping from the same core brain?
Alex
Exactly — which introduces the terrifying concept of a container escape vulnerability.
Maya
Oh, man.
Alex
If an attacker compromises a single container — say, through a vulnerability in a web app running inside it — they aren't contained by virtualised hardware.
Maya
They are sitting right on top of the host's shared kernel.
Alex
And if they find a kernel exploit, they can use that shared kernel to break out and compromise the entire host system.
Maya
We've seen real-world examples of this in our source material.
Alex
Malware like WannaCry specifically targeted environments running vulnerable Windows OS images inside Docker.
Maya
Wow.
Alex
So they pop one container, use the shared kernel to escape, and suddenly they own every other container running on that machine.
Maya
The isolation boundaries just evaporate. It's a total domino effect.
Alex
Okay, I am incredibly frustrated now.
Maya
My job here is done.
Alex
Seriously — if building private clouds is a massive liability and containers have these terrifying shared-kernel vulnerabilities, the only logical step is the path of least resistance.
Maya
Which is?
Alex
Swipe the corporate card. Rely on the massive scale of a dominant public cloud.
Maya
I'm talking Amazon Web Services.
Alex
Yeah. AWS.
Maya
Ah yes, the giant.
Alex
It makes sense. AWS provides out-of-the-box infrastructure that would take an internal team literally years to build — global load balancing, serverless compute.
Maya
The massive scale is incredible.
Alex
It is impressive, I won't deny that.
Maya
The only real friction usually comes from the developers themselves trying to navigate the IAM permissions.
Alex
You know how it is. A developer is desperate to get their code working so they can just go to lunch.
Maya
Oh, I know exactly where this is going.
Alex
So they jump into the console and just assign administrator access to every single IAM role just to bypass the error messages.
Maya
Which is the digital equivalent of giving master keys to the entire building.
Alex
And that exact over-permissioning is what made one of the most infamous cloud breaches possible.
Maya
That breach completely shifted how the industry views cloud security.
Alex
It wasn't just a simple hacked password.
Maya
Not at all.
Alex
The AWS infrastructure itself didn't fail — Amazon didn't get breached.
Maya
What happened was a misconfigured web application firewall combined with a highly permissive IAM role on an API endpoint.
Alex
This was a server-side request forgery attack — SSRF.
Maya
Spot on.
Alex
The threat actor found a vulnerability in the WAF. But they didn't just stop there — they used it to execute commands that tricked the WAF into querying the AWS instance metadata service.
Maya
Right. For anyone listening, every EC2 instance has this internal IP address — 169.254.169.254. It's how the server learns about itself and retrieves its temporary IAM credentials.
Alex
Exactly. And the attacker used the SSRF to make the WAF ask that internal IP for credentials.
Maya
The system saw a request coming from inside the house and happily handed over the keys.
Alex
And because the developers had over-permissioned that role, the attacker walked away with a massive trove of sensitive data — tens of millions of credit card applications.
Maya
AWS provided a secure vault. The misconfiguration handed the attacker the keys.
Alex
That perfectly summarises the friction of this whole deep dive.
Maya
Whether you build it yourself with OpenStack, pack it into lightweight Docker containers, or rent it from a massive provider like AWS — the burden of configuration is completely inescapable.
Alex
It really is.
Maya
There is no technology stack that configures itself securely by default.
Alex
We've gone from tuning out dashboard alerts to realising that if the system burns down, the legal liability rests entirely on our shoulders.
Maya
It does.
Alex
And I want to end on a chilling, provocative thought for you to ponder on that exact note.
Maya
Oh, lay it on us.
Alex
A lot of people think their private cloud data is safe just because it isn't explicitly published to the internet.
Maya
But in an interconnected cloud, is any part of your infrastructure truly invisible?
Alex
What do you mean?
Maya
Think about how AWS handles cross-account interaction.
Alex
If a threat actor simply guesses or scrapes your unique 12-digit AWS account ID — no passwords, no access keys, just the ID.
Maya
What can they even do with just a 12-digit number?
Alex
They can trick the system's error messages into revealing exactly which user roles exist in your account.
Maya
Wait, seriously? By just guessing names?
Alex
Yes.
Maya
They run an automated script guessing thousands of role names against your ID.
Alex
If the role doesn't exist, AWS gives one error message.
Maya
If the role does exist, it gives a slightly different error message.
Alex
Oh, wow.
Maya
So just by looking at the errors, they can map your entire internal IAM structure.
Alex
Exactly.
Maya
So the question is: when the cloud itself will politely confirm the names of your secret roles to anyone who runs a script, is it really enough to just tape over the dashboard warning lights and hope for the best?
Alex
I think we both know the answer to that.
Maya
Good luck out there, everyone.
Show Notes
Topics covered in this episode
• Alert fatigue: when every dashboard light is permanently blinking, engineers put tape over them — and that is exactly when a breach becomes invisible
• Monitoring vs auditing: monitoring answers "is the server crashing right now?"; auditing answers "who logged in at 2 a.m., bypassed MFA, and deleted the customer database?" — they are entirely different operational disciplines
• Immutable WORM log storage (Write Once, Read Many): why plain text logs on a server are useless in court — a sophisticated attacker's first move after privilege escalation is to wipe the logs; WORM storage is mathematically and cryptographically intact even if the root administrator account is compromised
• Risk management cycle: identify threats, assess impact, prioritise severity, then decide to mitigate, transfer, or accept — the loop management must run continuously to avoid negligence liability; in reality, most companies only care about PCI DSS and GDPR the morning after their data appears on the dark web
• CSPM as the automated compliance enforcer: because humans cannot reliably run a compliance checklist on every code push, CSPM continuously scans configurations against policy frameworks and catches a publicly exposed storage bucket before it becomes a headline
• OpenStack private cloud: total control over every dial, switch, and hypervisor — but total control equals total liability; when a zero-day hits the hypervisor, there is no AWS security team in Seattle rolling out a hot fix; you detect, patch, and mitigate entirely alone
• Container security and kernel sharing: a container is a lightweight suitcase compared to a full VM mobile home — but it only achieves that lightness because every container on the host shares the exact same OS kernel; one compromised container plus one kernel exploit equals a full container escape that dominates every other container on the machine
• WannaCry and Docker: real-world malware that specifically targeted vulnerable Windows OS images running inside Docker, demonstrating the domino effect of shared-kernel container escapes
• AWS and the IAM over-permission trap: developers under deadline pressure assign administrator access to every IAM role just to bypass error messages — the digital equivalent of giving master keys to the entire building
• Capital One SSRF breach case study: the AWS infrastructure did not fail; a misconfigured WAF combined with an over-permissioned IAM role did — the attacker used SSRF to trick the WAF into querying the EC2 instance metadata service at 169.254.169.254, retrieved temporary credentials, and walked away with tens of millions of credit card applications; the configuration burden is inescapable regardless of which platform you choose
• AWS cross-account role enumeration: with only a 12-digit account ID (no passwords, no access keys), an attacker runs an automated script guessing role names — a non-existent role returns one error message, an existing role returns a subtly different one; by reading errors alone, they map your entire internal IAM structure