How to Apply Defense-in-Depth Without Needing Years of Experience
Thinking Like a Security Architect
Most security beginners think security controls in silos and prioritise one over the other.
You over-rely on one security control and ignore the rest. But security doesn’t work in isolation. And understanding how controls work together is the foundation of real cybersecurity thinking.
That’s how you move from theory to resilient, real-world defence.
There are 7 types of security controls that can be put in place to protect an organisation's assets and information:
Directive - To control the actions of subjects. E.g., Corporate policy.
Deterrent - To discourage violation of policy. E.g., Sign warning that a piece of land is private.
Preventive - To prevent undesired actions or events.
Detective - To identify if an incident has occurred.
Corrective - To minimise the negative impact of an incident.
Recovery - To recover a system or process and return it to normal operations. E.g., A data backup policy allowing restoration of data.
Compensating - Compensating controls are typically deployed in conjunction with other controls to aid in enforcement and support of the other controls.
Detective, corrective and recovery controls are enforced after an incident is present.
Directive, deterrent, preventive, and compensating controls are applicable before an incident takes place.
But let’s cut the fluff.
If you are Cybersecurity beginners learning about cloud security, building cloud security control, assessing security of cloud architecture or preparing for your next interview/certification. This post will save you time and trouble.
By the end, you’ll know
How defence in depth works ?
How does holistic security looks like ?
How to prepare confidently for your next interview ?
How to shift mindset and start to think like “Cloud Security Architect” ?
But Kushal, I am a beginner. Why do I need to think like security architect so early ?
Because the early the mindset you develop, greater the chance of becoming successful story.
Security Architecture is not about the job but the perspective.
It is always better to know how to stop something bad from happening than it is to deal with it after it has happened.
Let’s begin.
The Complete Control
There 3 Controls out of 7 that are often known as “The Complete Control”:
1. Preventive controls - How Could You Prevent Something From Happening ?
2. Detective controls - How Will You Detect Something’s Wrong ?
3. Corrective controls - How Will You Recover or Contain ?
Building these 3 controls can reduce the risk upto 80%.
Let’s explore these in more detail.
How Could You Prevent Something From Happening ?
This is your first line of defence.
Preventive controls can prevent undesired actions or events. For example, a fence that prevents someone from walking onto private property.
Here’s how you can put it in action:
Enabling MFA or SSO for accounts. Not just for CISO. Even for the interns.
Enforcing least privilege using roles, not using wildcards like `*` in IAM policies.
Segment access using security groups, network ACLs or subnets. Not letting your non-prod system talk to the production database.
Encrypting the database at rest and in motion to maintain confidentiality
Once you get the idea of Preventive controls, now pause and ask:
“If this control fails, what alerts will I get?”
That’s where detective controls come in.
Note: There are no perfect preventive control, so detective and corrective controls should also be implemented in conjunction.
How Will You Detect Something’s Wrong ?
This is your second line of defence.
Detective controls are designed to identify if an incident has occurred. An example is a smoke alarm detecting smoke.
They signal you when something suspicious is happening so you can jump in and take control.
Here’s how you can put it in action:
Enable AWS CloudTrail or equivalent logging. Don’t just turn it on, store it centrally and encrypt the logs.
Enable AWS Config to detect the drift in configuration:
Security group modified.
Encryption disabled.
S3 bucket made public.
Set alerts on high-risk actions:
A new IAM user created.
Root login attempt from a new location.
If your org budget allows, you can enable AWS GuardDuty or a SIEM to correlate events and flag anomalies.
Now the next question is Who gets notified? What’s the response? What will I do when this alert fires?
Which leads us to corrective controls.
How Will You Recover or Contain?
Corrective controls are used to minimise the negative impact of an incident. An example is a fire suppression system activating.
Here’s how you can put it in action:
Define rollback plans: If a pipeline deploys a bad policy, how fast can you revert?
Use automation to isolate compromised resources, like auto-tagging and quarantining suspicious EC2 instances.
Build runbooks: If an alert fires for credential theft, what’s the first 3 steps your team must take?
For example:
Let’s say a detection rule fires when a new AWS region is accessed for the first time. A simple Lambda function can immediately revoke access, send an alert, and create a ServiceNow ticket for follow-up.
Tying the controls to work together
Holistic security happens when these 3 controls reinforce each other.
Here’s what that looks like:
You create a preventive policy that blocks public S3 buckets.
You use AWS Config as detective control to alerts if someone tries to make one public.
If that happens, a corrective automation triggers such as Lambda to revert the change and notify the security team.
Use Case
Let’s say: Developers are pushing application to production.
Here’s how to secure it with just the three layers:
Preventive Controls
Use role-based access control for developers and service accounts.
Enforce code review before merge.
Require deployment via CI/CD only.
Prevent manual change to production.
Detective Controls
Alert if developers pushes secret to code repo.
Notify on production config drift.
Corrective Controls
Roll back unauthorised changes using IaC.
Trigger incident workflow in Slack or PagerDuty.
The Interview questions for Complete Controls
Let’s look at some interview questions
IAM & Privilege Escalation
You’re reviewing an AWS account and notice an IAM user without MFA has
AdministratorAccess.
How would you address this using preventive, detective, and corrective controls? Walk me through the specific steps and tools you’d use.
2. Network Exposure
During a security review, you find a security group that allows inbound SSH from
0.0.0.0/0.
What preventive controls should have stopped this?
If it still happens, what detective alerts should fire?
Finally, what corrective action should the system take automatically?
3. Production Pipeline Tampering
A developer bypasses the CI/CD pipeline and manually changes production code.
Describe the preventive safeguards, the detective alerts, and the corrective rollback steps you’d put in place to handle this.
4. Incident Response Readiness
You receive an alert that a new AWS region was accessed for the first time in your account.
Which preventive policy might have avoided this, what detective control should detect it instantly, and what corrective action should happen in the first 5 minutes?
Final Thoughts: Keep It Small, Smart, and Systematic
Understanding the interconnection between 3 controls comes from the shift in mindset.
A mindset that can look from 10,000 ft overview at entire solution, it’s entry and exit points.
This mindset often comes from experience but this mindset can also be cultivated through practice.
Learning to questions the type of controls and how they are interconnect often helps in the bigger picture.
Stop thinking security controls in silos. You need a tight loop of prevention, detection, and correction.
Build one control set at a time. Test it. Break it. Fix it.
Simple. Actionable. Effective.
Now go make your controls work together, before your next breach does it for you.
Chat Soon,
- Kushal