Episode 4 · Module 1 · Foundations

Defence in Depth

18 May 2026 · 9:24 · Security for Legal SaaS

0:00 9:24

Medieval castle builders understood that a single wall eventually falls. In this episode, Alice and Dan translate the castle model into modern security architecture — six independent layers from network perimeter through audit logging. They examine the Okta breach to show why delegating an entire layer to one provider is a single point of failure, and walk through a SQL injection cascade that demonstrates the difference between architecture with depth and architecture without it.

Today’s Lesson

One Wall Is Never Enough

NIST defines defence in depth² as “an information security strategy integrating people, technology, and operations capabilities to establish variable barriers across multiple layers.” The principle: no single control is trusted to hold.

The Castle Model

Castle Layer	Modern Equivalent	Function
Geographic position	Network architecture & segmentation	Slows attackers, makes approach visible
Town walls	Network perimeter (firewall, WAF)	Filters obvious threats
Moat & drawbridge	Authentication layer	Controls who crosses into trusted space
Outer wall	Application-level controls	Stops common application attacks
Inner wall	Authorization & access control	Ensures users see only their data
Keep (the vault)	Encryption + audit logging	Last-resort protection after full compromise

The critical insight: each layer is designed assuming the layer in front has already fallen.⁴

Key principle: Each layer must function independently. If your authorisation check depends on authentication being correct, and authentication depends on the WAF blocking forged tokens, you have one layer pretending to be three. Microsoft’s Zero Trust framework⁶ formalises this as “verify explicitly” — every layer authenticates and authorises independently.

The Single-Provider Trap

In October 2023, attackers compromised Okta’s customer support system⁷ by stealing session tokens from uploaded HAR files. The breach cascaded to 134 customers⁸ including 1Password, BeyondTrust, and Cloudflare.

Single-Provider Risk	Defence-in-Depth Mitigation
Auth provider breached → all tenants exposed	Independent authorization checks at data layer
WAF bypassed → application defenceless	Application-level input validation regardless of WAF
Cloud KMS compromised → all data readable	Application-layer encryption with separate keys
Logging service tampered → no audit trail	Local hash-chained copies + out-of-band verification

Case Study: SQL Injection Meets Plaintext Keys

CloudSEK documented a case¹⁰ where a single SQL injection exposed 45 databases, 240+ S3 buckets, and an entire AWS infrastructure because IAM credentials were stored as plaintext in the database. In the Accellion FTA breach (2021),¹¹ attackers used SQL injection to retrieve encryption tokens, transforming a web vulnerability into full access to encrypted file transfers. Law firms were among the victims.¹²

Design test: Take any single component in your architecture and assume an attacker has full control of it. If that single compromise gives access to all client data, you lack depth. Re-architect until single-component compromise yields only partial access, detectable anomalies, and recoverable state.

Conclusion

Defence in depth is not about buying more security products. It is about architectural discipline: ensuring that the failure of any single layer does not cascade to total compromise. ISACA’s 2025 guidance¹³ emphasises that the medieval castle model has evolved but the principle endures: heterogeneous, independent layers, each designed to function when the layer above has fallen.

Alice: Welcome back to Security for Legal SaaS. I’m Alice.

Dan: And I’m Dan. Episode 4 — Defence in Depth. Alice, I want to start with castles.

Alice: Medieval castles. Not a metaphor I’m forcing — this is literally where the concept comes from. Castle builders understood that a single wall, no matter how thick, eventually falls. So they built five or six layers. The hill slowed the approach. The town walls forced a fight. The moat stopped siege engines. The outer wall caught the first wave. The inner wall — taller, with archers looking down — caught whoever made it through. And the keep, the innermost vault, had its own barred doors even when the courtyard was secure.

Dan: Each layer assumes the one before it has already been breached.

Alice: That’s the key insight. The inner wall isn’t redundant — it’s designed to function when the outer wall has fallen. In cybersecurity, NIST defines defence in depth the same way: variable barriers across multiple layers, each operating independently. CISA published an advisory in July 2024 after their red team compromised a federal agency specifically because the organisation lacked layered defences beyond the perimeter.

Dan: So what does this look like translated into a legal SaaS application?

Alice: Six layers. Layer one — network perimeter. Your WAF filters known attack patterns, SQL injection signatures, XSS payloads. Layer two — application-level input validation. Even if the WAF passes something novel, parameterised queries and strict type checking reject it. Layer three — authentication. Multi-factor, session rotation, modern password hashing. Layer four — authorisation enforced at the data layer, not just the API route. Matter-scoped isolation so lawyers only see their assigned cases. Layer five — encryption. Data at rest, data in transit, and for privileged documents, application-layer encryption with keys the infrastructure provider cannot access. Layer six — immutable audit logging that records every access and failed attempt.

Dan: And the critical point is each of those has to work independently.

Alice: If your authorisation depends on authentication being correct, and authentication depends on the WAF blocking forged tokens, you have one layer pretending to be three. Microsoft’s Zero Trust framework calls this “verify explicitly” — every layer authenticates and authorises on its own. Assume the layer above you has been completely compromised. Can you still protect the data?

Dan: Which brings us to an uncomfortable question. A lot of SaaS products delegate entire layers to a single provider. Authentication to Okta, encryption to AWS KMS, monitoring to one vendor. What happens when the provider itself gets breached?

Alice: October 2023. Attackers stole session tokens from Okta’s customer support system — they were in uploaded diagnostic files. Because Okta handled authentication for thousands of organisations, the breach cascaded downstream. 1Password, BeyondTrust, Cloudflare — 134 customers affected. If your entire authentication layer is that one provider with nothing behind it, their breach is your breach.

Dan: So what’s the mitigation? You can’t not use managed services.

Alice: You can use them — but you layer behind them. Even after Okta confirms identity, your authorisation layer independently verifies that user should access that specific matter. Even after AWS KMS decrypts at the infrastructure level, your application-layer encryption protects the most sensitive documents with separately managed keys. A compromised provider gives the attacker one layer, not all of them.

Dan: This is the “assume breach” mentality I’ve been hearing about.

Alice: Core tenet of Zero Trust. You design every component assuming adjacent components are compromised. The question isn’t “can this be breached?” — everything can be breached. The question is “when this component is breached, what else falls?” If the answer is everything, you have a depth problem.

Dan: Let’s make this concrete. You mentioned a case study — plaintext API keys in a database.

Alice: Classic scenario. A legal document management system stores API keys for court e-filing services, cloud storage providers, maybe an AI service — all in a database table as plaintext strings. CloudSEK documented a real case where a single SQL injection exposed not just the application database but 45 other databases, 240 S3 buckets, and an entire AWS cloud setup. The SQL injection gave access to IAM credentials stored in the database, which gave access to everything else.

Dan: So a web application bug becomes full cloud account takeover.

Alice: Because there was no depth. The Accellion FTA breach in 2021 — same pattern. Attackers used SQL injection to retrieve encryption tokens from the database. A web vulnerability became a decryption capability. Law firms were among the victims. If those tokens had been in a hardware security module instead of a queryable table, the SQL injection would have yielded ciphertext. Useless without physical HSM access.

Dan: Walk me through the difference. Same initial attack — SQL injection hits the search endpoint. Without depth versus with depth.

Alice: Without depth: attacker queries the keys table, gets plaintext credentials, authenticates to cloud storage, downloads the entire client document corpus. One vulnerability, total compromise. With depth: attacker hits the same injection, queries the keys table — but gets encrypted blobs because keys are HSM-wrapped. Can’t use them. Meanwhile, the anomalous query pattern triggers an audit alert. Security team catches it in hours, patches the injection, rotates credentials. Same entry point. Radically different blast radius.

Dan: Because the encryption layer didn’t trust the application layer to be secure.

Alice: And the audit layer didn’t trust any of the other layers to prevent the breach. Each one assumed everything above it had already failed and asked — given that assumption, what can I still protect? That’s defence in depth. Not three products from the same vendor checking the same thing three times. Independent layers, different trust assumptions, heterogeneous controls.

Dan: For a legal SaaS team hearing this — what’s the one thing they should do tomorrow morning?

Alice: Pick your most sensitive data asset. Probably privileged client communications. Trace the path from the internet to that data. Count the independent layers an attacker must defeat — not bypass, defeat independently — to reach it. If the number is less than three, you have work to do. If any single component compromise gives access to everything, you have urgent work to do.

Dan: Defence in depth — the principle that kept crown jewels safe for centuries, applied to the data your clients trust you to protect. Next episode, we’re covering the CIA Triad Meets Legal Privilege — confidentiality, integrity, and availability through the lens of professional duty.

Alice: Until then, I’m Alice.

Dan: And I’m Dan.

Security for Legal SaaS is a series written with AI assistance. Alice and Dan are AI-generated voices — no professional advice here, just education.