All posts

Defense In Depth

by Robert Broeckelmann

“Defense in Depth” is the idea that no single security control is trusted to stop an attack. Instead, you stack multiple, independent layers so that if one fails, others still stand in the way.

If you’ve ever seen a breach postmortem, the pattern is almost always the same: one control failed AND there was nothing behind it. Defense in depth exists to prevent exactly that.

“Defense in Depth” actually means “multiple layers of security controls across different parts of the system, each assuming the others may fail.”

This concept is formalized in frameworks like NIST SP 800–53 and aligns closely with Zero Trust Architecture (ZTA). In fact, ZTA and Defense In Depth concepts have many common features, but are distinct.

The Layers of Defense

A practical way to think about it is in layers:

  1. Physical: Data centers, hardware access (locked cabinets) behind locked doors, physical security, key card access tracking who comes & goes, video surveillance, man traps, etc.
  2. Network: Segmentation (macro/micro, VLANs), firewalls, VPNs, IDS / IPS, flow capture capabilities, forward / reverse proxies.
  3. Host: OS hardening, patching, host-based firewall, file system integrity monitoring, malware detection / antivirus.
  4. Application: Secure code, input validation, dependency.
  5. Identity: Authentication, authorization, user repository, IAM governance, token issuance, session management.
  6. Data: Encryption (at rest, inflight), access controls, Data Loss Prevention (DLP).
  7. Public Key Infrastructure (PKI): Proper use of private / public key pairs in encryption, digital signatures, and other cryptographic operations combined with PKI best practices and zone-based certificate-authority-chain trust.
  8. Monitoring & Response: Detection and containment (IDS, IPS, DLP, Reverse / Forward proxies, application monitoring, etc).
  9. Asset Management: Know what is supposed to be attached to your network. If monitoring detects an unknown node (by IP address, MAC address, etc), generate an alert (and investigate).
  10. Centralized Logging & SIEM: All logs from all nodes, OS & application logs, should be poured into centralized logging. Logs of interest to information security should be loaded into the SIEM. These are separate systems. Alerts should be generated from interesting / “out-of-the-norm” events.
  11. Disaster Recovery (DR) / Business Continuity (BC): Starting with basic data store backup and recovery capabilities. But, expanding into the full range of DR / BC capabilities.

Each layer should:

  • Work independently
  • Reinforce the others
  • Assume compromise is possible (or has already occurred)

This takes us up and down the technology stack, but the concept should also apply to each layer of the application architecture: web servers, API Gateways, application servers, databases, etc, etc. We’ll call this side-to-side or end-to-end. All of the protection layers mentioned above should be applied at each component layer of your application architecture.

I considered adding “good / effective IT governance” to this list, but that’s probably getting to abstract for what is otherwise a very concrete list. I mention this capability / concept because a healthy command-and-control of resources within your IT department that are all moving towards the same goals is critical to effectively deploy everything in the list above. This may seem obvious, if not a little cynical, maybe even condescending, but there’s so many shops that trip over themselves in everything they set out to do because good IT governance is missing or something closer “performance art” with no real substance.

This post isn’t going to dig into each layer in detail, but some important points are covered.

Network Security: Defense in Depth

The network layer is where the concept originated — and where people still misunderstand it.

Perimeter Security (North-South)

North-South traffic refers to traffic moving in / out-of your data center.

  • Firewalls (Inner / Outer, different vendors).
  • DDoS prevention service
  • VPN gateways
  • Internet DMZ
  • Vendor DMZ
  • Reverse Proxies (used as security gateways, monitoring probe points)
  • Anti-virus / malware detection (integrated into entry points like API Gateways)

This is your first line of defense, not your only line of defense.

Internal Segmentation (East-West)

East-West traffic refers to traffic moving within your data center.

Modern environments require controlling internal traffic, not just inbound/outbound.

  • Macro / Micro segmentation
  • Internal firewalls
  • VLANs / VPC segmentation

This prevents attackers from moving laterally after initial access. At least, not without significant effort. The goal is to slow them down, frustrate them, and make them move on to something easier.

Although, it doesn’t directly contribute to segmentation of the internal network, you should have an IDS / IPS capability here as well.

If your entire network security architecture is based around an externally-facing firewall and then a large, flat-internal network, you’ve gone to the bad place and need to come back to us. 1995 called and it wants its network architecture back.

Between internal network firewalls, host-based firewalls, network macro / micro-segmentation, and supporting concepts, there should be a deny-by-default connectivity policy that requires specific connectivity to be requested. This can become complex and annoying to configure. Especially if there is an inflexible beauracracy that has developed around it — I’ve seen firewall rule request spreadsheets with 1000s of lines for large projects that are about to move into production. If a single field in a single line had a typo or was wrong, the entire thing would be rejected and they’d have to start over with a multi-week SLA. The entire organization needs to be a bit more flexible than that.

Secure Transport

All inflight communication (data in flight, data in motion, pick a name) should be encrypted to maintain confidentiality. This means:

  • TLS everywhere
  • mTLS for service-to-service communication
  • Possible use of VPN
  • Physical layer encryption support.

This protects against interception and tampering.

Just because part of the network path has physical / link-level or VPN with encryption does not mean that you are protected end-to-end. It isn’t good enough. Use TLS v1.2 or better as well to cover the entire network path.

I had a developer once spend a good hour arguing with me over the need for TLS anywhere. The basic argument was that if a bad actor was already on the internal network, then they could compromise anything and it didn’t matter if TLS was being used. That guy stopped being invited to design meetings.

Network Monitoring

One should have insight into what is happening on their network. This should include:

  • IDS/IPS systems (mentioned above) should have insight into every network segment.
  • Flow logs and anomaly detection. The ability to gather network traces is also an invaluable diagnostic tool.

This Detects suspicious behavior including:

  • Lateral movement
  • Known exploit attempts
  • Unknown IP address, network nodes.

These tools can be rather expensive. At the same time, there are opensource tools that are not perfect, but can accomplish much in this space.

Zero Trust Networking

Using principles from Zero Trust Architecture:

  • Never trust based on network location.
  • Always verify identity and context at every network node / hop of the architecture.
  • Enforce least privilege access

With these principles, the network stops being “trusted” and becomes just another transport layer.

As I’ve mentioned before, there is no such thing as a secure network or a trusted network.

Application Security: Defense in Depth

This is where many organizations are weakest, probably, because they assume the network will protect them.

Secure Coding Practices

  • Input validation
  • Output encoding
  • Avoiding common vulnerabilities (OWASP Top 10).
  • Peer code reviews before promotion to production (with a focus on security).
  • Run your code through a Static Application Security Testing (SAST) tool on every build. Address items found in the report.

Identity

Definitely one of my favorite topics. I’m written about Identity concepts extensively. The following must be addressed:

  • Authentication
  • Authorization: RBAC, ABAC, etc
  • MFA
  • User Repository
  • Session Management
  • Identity Tokens
  • Reverse Proxy acting as an Authentication Gateway (another example of Security Gateways).
  • Least privilege access
  • Short-lived credentials
  • Continuous verification (every layer of architecture that sees an identity credential should validate it before relying upon it)

In many modern contexts, SaaS applications, some cloud computing scenarios, Identity becomes the primary security boundary and the only thing you really have control over.

Application Layer Protections

Your application should be protected with:

These act as a buffer between users and your application logic.

Secrets Management

Secrets (API keys, OAuth2 Client Credentials, username + password, TOTP seeds, X509 private / public key pairs, etc, etc) must be properly secured, including:

  • No hard-coded credentials
  • Use secure secrets storage (such as Hashicorp Vault or CyberArk).
  • Rotate credentials regularly

Dependencies and Software Supply Chain Security

Since the SolarWinds attack in 2020, Software Supply Chain Security has been an ongoing discussion. You must:

  • Scan third-party libraries
  • Validate software integrity
  • Monitor for vulnerabilities

Note, most modern breaches exploit dependencies, not your code. Most applications rely on a large number of Opensource libraries / modules that have source code readily available.

For an in-depth analysis of this topic, check out my post about software supply chain security.

Runtime Protection

Your environment / platform should have the following capabilities:

  • Application monitoring
  • Behavior-based detection
  • Container/runtime security tools

Data

Address the following:

  • Encryption at rest and in transit
  • Data classification assigned.
  • Data owners assigned.
  • Access auditing

Even if everything else fails, data should still be protected.

In the name of all that is good and holy in this world, disable any public-internet-facing listeners that your cloud-hosed database service has enabled by default.

Detection and Response (The Layer People Forget)

No defense is perfect.

So you need:

  • Centralized logging
  • SIEM or monitoring platform
  • Incident response plans

The goal shifts from “prevent everything” to “Detect quickly and contain damage”.

Your information security department should have:

  • Security standards and policies published.
  • Risk Management person / team / process.
  • Someone available that can work with application / project teams so that good security decisions are made.
  • Incident Response team / plan ready to go at a moment’s notice.

Ideally, that Incident Response team is a dedicated function or, at least, isn’t penalized for project work not being completed because they were dealing with a critical security incident.

Common Failures in Defense in Depth

Organizations / individuals frequently make the same mistakes when planning their layered defenses.

Over-reliance on perimeter security

  • “We have a firewall, we’re good”
  • Meanwhile, internal systems are wide open

Layers that aren’t independent

  • Same IdP everywhere

You can securely have an IdP’s trust realm include your whole network, but additional identity concepts such token audience claim, resource claim, or AppliesTo Address attribute must be utilized. Check out OAUTH 2 ACCESS TOKEN USAGE STRATEGIES FOR MULTIPLE RESOURCES SERIES blog posts. If the same identity token allows a request to proceed deep into the network without any additional checks, token swaps, or other actions, the defense layers are not really independent.

  • Same misconfiguration replicated across layers

If the layers of defense are not independent, one failure can cascade through everything and defeat the entire point.

Complexity without visibility

  • Too many tools
  • Too many redundant tools (once you have three or more tools / products / libraries that do the same thing, you’ve gone to the bad place and need to come back to us).
  • No centralized monitoring

Ignoring east-west traffic

  • No controls on internal communication
  • Easy lateral movement for attackers

The Modern Interpretation

Traditional defense in depth was about layered perimeter defenses primarily at the network level.

Modern defense in depth is:

  • Identity-centric
  • Data-centric
  • Continuous verification

It aligns heavily with Zero Trust Architecture:

Assume breach, verify everything, trust nothing implicitly (just like Agent Mulder).

Real-World Example

A well-designed system might include:

  • Perimeter firewalls (inner / outer in a DMZ)
  • Internal segmentation
  • MASSL/MATLS between services
  • Strong IAM controls
  • WAF in front of applications
  • Encrypted databases
  • Centralized logging and alerting

You can see many of these components in play in the Vendor DMZ architecture blog post:

An attacker would need to:

  1. Get past the perimeter
  2. Compromise identity
  3. Bypass segmentation
  4. Compromise the API Gateway
  5. Exploit application logic
  6. Access encrypted data.
  7. Exfiltrate data past the DLP system.

That’s the point: multiple independent hurdles.

With a little luck, the attacker will become frustrated and go look for an easier target.

Summary

Defense in depth is about layering independent security controls so that no single failure leads to total compromise. It takes time and an iterative approach for an organization to develop competencies in all of the capabilities mentioned here. So, get started today.

Notes

  • AI / GenAI / ChatGPT / etc were not used to generate the text of this article.
  • I used em dashes in my writing before the current GenAI wave was a thing. Not planning on changing now.
  • Names have been changed to protect the guilty.
  • None of the hostnames or users used in examples actually exist.
  • Feel free to post any comments or suggestions below.

Originally published on Medium.

More articles