Most cloud breaches don’t beat every control. They beat the one control everyone trusted.
If you’ve been in cybersecurity for a while you’ve surely already met the term “Defense in Depth”.
The trouble is that a definition doesn’t tell you what the layers look like in a real cloud environment. It doesn’t tell you which question each layer answers either, or what happens when one of them fails.
So I asked someone who deals with this every day.
Kushal | Cloud Security has 12 years in cybersecurity. He has pen-tested 100+ applications, reviewed 50+ cloud architectures, and assessed 200+ SaaS vendors and I have been following his work for a while now.
Impressive record, isn’t it?!
In this guest post, he’ll walk you through:
The 7 layers organisations use to protect cloud infrastructure and data
The one question each layer has to answer
Real attack paths from his offensive security days (including a database he dumped through a hardcoded credential)
His top recommendations for identity, secrets and workload security
Read it with one question in mind: if my organisation’s strongest control failed tomorrow, what would stop the attacker next?
Let’s take a look at what Kushal has to say about that.
Do you write about cybersecurity yourself? If you have hands-on experience and a lesson most people learn the hard way, I’m open to guest posts and collabs. Just let me know!
Layer 1 - Defend Application from Malicious Traffic
An internet facing application cannot distinguish between legitimate user from an attacker.
The attacker use this gap to
Launch DDoS attacks, that overwhelm infrastructure or application resources.
Perform credential stuffing, using leaked credentials to attempt account takeover.
Scan for vulnerabilities by continuously probing applications, APIs, and exposed services.
The first layer is to filter malicious traffic before it reaches the application.
Hence, most organisation use edge controls such as
WAF to stop application level attack.
DDoS protection to mitigate heavy volume request.
Rate limiting to throttle excessive request, and
Bot controls to detect and filter unwanted automated traffic.
But the attack always doesn’t look malicious. A traffic with stolen credential can perfectly be a legitimate request.
And that’s why we need next layer to ask the question -
“Who is making the request and are they authorised ?”
Want more guest posts like this? Hit the ❤️ and leave a comment!
Layer 2 - Protect Identity & Access
In the first half of 2025, identity-based attacks rose by 32%, according to Microsoft’s Digital Defense Report.
More than 97% of the identity attacks Microsoft observed were password attacks.
Today when Identify fails, everything fails. You cannot access anything. And that is why modern attackers no longer start with network. They start with Identity.
And cloud environments rely heavily on non-human identities, including:
Service accounts
Managed identities
CI/CD pipeline identities, etc.,
These identities if compromised or granted excessive permissions, allows attackers to break pipelines, move between workloads, modify infrastructure and access sensitive data.
In my countless review of IAM policy -
My top 3 recommendation has always been
To eliminate unnecessary long lived credentials.
Go for managed identities or workload identities, and
Stop granting excessive permission to resource they don’t need.
A simple identity policy that grants a limited access to specific folder instead of entire S3, can have huge impact to an organisation security posture.
Coz Layer 2 ensures that authentication and authorisation decisions are made before a request reaches protected resources.
But what if a traffic with malicious intention has valid credentials and required privilege ?
This is where next layer of defense becomes important.
Enjoying this? Kushal writes like this every week in Secure Stack!
Layer 3 - Secure the API
In 2017, during my API security testing days, I followed a simple checklist to attack an API endpoint:
Can I send 500+ requests per second?
Can I send malformed request ?
Can I send an unsigned or invalid JWT ?
Can I abuse the API to gain access to other resources ?
Can I send request from any IP or is IP whitelisting enforced ?
The reason for these questions was simple: Layer 2 alone doesn’t make request safe.
Even a valid identity can send a malicious request.
Layer 2 answers: “Alice is authenticated and has permission to use the xyz API.”
Layer 3 asks: “Is Alice’s request valid, expected, and within the rules of this API?”
This layer adds controls such as:
API Gateway, centralizes and enforces API traffic policies.
Rate limiting, throttles excessive requests and API abuse.
Schema validation, rejects malformed or unexpected input.
Signature validation, verifies request integrity and authenticity.
IP restrictions, limits requests to trusted sources where required.
API authorization, checks whether Alice can access the requested resource or action.
The goal is to add another enforcement point before the application, complementing network and identity, other layers that follows it.
Layer 4 - Isolate the Workload
Once I was reviewing an architecture and was surprised to see -
Production and Testing share the same network.
Production data used in testing.
This is typical case of flat network with no boundaries defined.
A flat network gives compromised workload unnecessary network reachability to other workloads, increasing opportunities for lateral movement.
So, how to prevent this ? Network segmentation
It prevents by separating resources into zones with different trust level and access requirement.
In cloud environment, this is achieved though VPC/Vnet, Security Groups or NSGs, NACL(Network Access Control), and private connectivity mechanism.
Consider a typical 3 tier architecture, where
Internet-facing load balancer in public subnets
Application workloads in private subnets, and
Databases in a more restricted data tier.
This creates multiple network boundaries.
If an attacker compromises an internet-facing component, they still need to overcome additional controls before reaching application workloads or sensitive data.
The objective of this is to make unnecessary movement harder, reduce the number of reachable resources, and limit the blast radius of a compromise.
Got a question for Kushal? Drop it in the comments. I'll make sure he sees it.
Layer 5 - Secure the Compute Environment
Assume the traffic successfully
Passes the edge, Layer 1
Is authenticated via Layer 2, 3 and
Follow network access policy via Layer 4
The compute environment can still be compromised.
A vulnerable Lambda, container, or EC2 instance can become the entry point.
Recently, I working on an assessment where team was deploying container pulled directly from Docker Hub.
Our organisation have strict policy:
Production workload must use approved Golden Container Images(GCI).
The policy is enforced via automation and stops deployment if using unknown or unapproved public images.
The reason is simple.
An untrusted or vulnerable image introduces another potential supply-chain attack vector.
Golden images are hardened, scanned and equipped with security endpoint tools that helps organisation maintain strong a security posture.
But hardening alone isn’t enough.
Vulnerable code or a compromised dependency can still compromise the workload.
So don’t assume the workload can never be compromised.
Assume it will be. Then ask: what is the blast radius?
A compromised workload is dangerous because it’s next attack path maybe to look for credentials and secrets so that it can access database connected to workload.
And that brings us to the next question:
What secrets can the workload access?
Layer 6 - Protect Credentials & Sensitive Configuration
Now let’s assume the attacker has
Breached all the above 5 layers.
Gained access to K8 cluster, and
See a connected to database.
But there is a problem.
The workload needs credentials, tokens or secret to access it.
And if those secrets are hardcoded in
Source code
Container images
Configuration files or
Exposed through insecure environment, the attacker job becomes much easier.
In 2019, I was able dump a database because I found hardcoded credential in XML file on a VDI server. The attack was simple -
Access the VDI Desktop.
Escape the VDI to access underlying OS files and folder.
Searched and found the credentials.
Used netstat to figure out the TCP connection to Db IP and Port.
Fired up database manager with IP, Port and credentials and I was in.
Today, I am on the defensive side of security and now recommends treating secrets as another layer that need to be defended aggressively. But how ?
My top 3 recommendation are -
Centralised Secret Management, store credentials outside application code and configuration.
Access Control, allow only authorised workloads to retrieve specific secrets.
Secret/credential rotation, regularly replace credentials to reduce the impact of compromise.
But given that we still find hardcoded in insecure environment, one final questions left at the end of attack path -
Can the attacker actually read or modify the data ?
Layer 7 - Protect the Data
Even after breaching all the above layer, a strong data protection can add another barrier.
And every-time I do a architecture review or vendor SaaS review, I ask following question:
Is data encrypted at rest and algorithm used ?
Is data encrypted in transit ?
Who can access and modify the data ?
Because a data stored internally or externally must be
Stored encrypted in databases, object storage, disks, and backups.
Encrypted while it moves between clients, services, and systems.
Limited to identities which can read or modify specific data.
But there is one problem.
A load balancer can terminate TLS connection, which means the traffic is decrypted at load balancer before being forwarded to the backend.
Meaning the data exists in plaintext at that processing point.
Hence most organizations use end-to-end encryption or application-level encryption so that the intermediary is unable to read the data.
So, the final question in Defense in Depth is therefore not just:
“Can the attacker reach the data?”
It’s:
“If they do, can they read, modify, or use it?”
And that’s a wrap.
To recap:
Layer 1: Should this traffic reach us?
Layer 2: Who is making the request?
Layer 3: Is the request valid and safe?
Layer 4: What can this workload reach?
Layer 5: What happens if it’s compromised?
Layer 6: What secrets can it access?
Layer 7: Can it read or modify the data?
And this is how an organization protects its data and defends its infrastructure, not by treating controls in silos, but by using them strategically to build Defense in Depth.
If cloud security is your direction, his newsletter explains how security reviews work in practice, from someone who does them for a living.
Let’s Connect
If you want to collaborate, discuss, or just geek out over networking and cybersecurity, reach out:
Email: erich.winkler@decodedsecurity.com
LinkedIn: Erich Winkler
Gumroad community: Decoded Security
Start Here: Decoded Security Roadmap
Enjoyed this article? Like it or drop a comment. I’d love to hear your thoughts and questions!
Let’s learn and grow together!