Defence in depth combines people, processes and technical safeguards so one missed attack has further opportunities to be blocked, detected or contained. It also prepares for recovery when damage occurs. A ransomware incident can begin before every layer fails: one laptop losing files is already harm. The aim is to reduce the likelihood and impact of compromise, rather than promise that enough products will prevent every breach.
In this briefing
- 01Layers perform different jobs: prevent entry, detect activity, limit access, contain damage and support recovery.
- 02A compromised standard user can still lose accessible files and may allow malware to persist.
- 03Segmentation protects only the connections that its rules actually control and enforce.
- 04Protected backups support restoration, but cannot undo stolen data or guarantee a recovery deadline.
What defence in depth actually means
NIST describes defence in depth as a security strategy that brings people, technology and operations together across multiple barriers. An email filter, an employee reporting a suspicious message, restricted access and an incident-response plan can all contribute. They do not need to be products from different vendors to perform different jobs. [1]
Picture several overlapping barriers, each with gaps. That picture is useful until it suggests that nothing bad happens unless every gap lines up. An attacker may already have stolen one document, compromised an account or encrypted a laptop while other controls continue working.
Once an attacker gets in, ask what they can reach, what defenders can see and how quickly the organisation can regain trusted operations. Those answers determine the scale of the incident.
One hypothetical attack, seven opportunities to intervene
This is an illustrative scenario, not a report of an observed attack. Imagine a small organisation whose staff use shared project folders. Finance systems and backup administration have separate access rules. The sequence deliberately lets some controls miss so we can see what later controls contribute. Real attacks can enter elsewhere, skip stages or take a different order.
1. Email filtering misses the message
A fake supplier invoice reaches an employee's inbox. Its link leads to an attacker-controlled download. In this example the filter does not recognise the message as malicious. A similar-looking domain alone does not determine whether a filter will catch it; reputation, content, policy and other checks also matter.
2. The employee opens the downloaded file
The invoice fits a current project, so the employee opens it. Malicious code runs. The useful response now is prompt reporting and technical intervention. Training should give people a clear reporting route and encourage them to use it after a mistake.
3. Endpoint detection produces a signal
The endpoint detection and response tool, or EDR, records suspicious process activity and unusual file changes. Here it alerts without automatically blocking. That is an assumption for this scenario, not a universal EDR behaviour. What happens next depends on the product, its configuration and the response attached to that alert.
4. Least privilege limits authority
The employee has no administrator rights. Attempts to change protected system settings fail, but ransomware starts encrypting local documents and a project share the employee can write to. Standard-user malware can also establish user-level persistence. Restricted privileges reduce authority; they do not make the account harmless. MITRE documents persistence that runs with the affected user's permissions. [7]
5. Enforced segmentation blocks selected routes
The workstation cannot directly contact the finance servers or backup management service because tested rules deny those paths. The project share remains reachable because work requires it. Segmentation therefore limits this attack's reach without protecting every file. Permitted routes and systems inside the same zone still need controls. CISA warns that segmentation can be undermined by paths that bypass it. [6]
6. Response turns the alert into containment
The nominated responder investigates, isolates the affected device and checks for compromised accounts and other affected systems. Some files have already been encrypted. Earlier isolation would have helped; an unattended alert would not contain anything. No fixed response time or damage limit is assumed.
7. Protected backups provide a recovery option
The team identifies a suitable restore point and rebuilds the affected environment before restoring and validating files. Recovery takes as long as investigation, rebuilding and business checks require. The scenario ends with a tested recovery path, not a promise of normal operations tomorrow. The Essential Eight maturity model treats restoration testing and resilient backup access as explicit requirements. [4]
The first compromise was an incident even though later barriers worked. Those barriers changed the amount of damage and the organisation's options afterwards.
Compare the jobs, not just the products
Use this table to examine the scenario. A control can contribute to several jobs, but a successful result in one column does not prove the others are covered.
| Job | Example | Question to test |
|---|---|---|
| Prevent | Email filtering and application restrictions | Will the attempted delivery or execution be blocked? |
| Detect | Endpoint alerts and central logs | Does a useful signal reach a responsible person? |
| Limit | Permissions and enforced network rules | Which files and services remain reachable? |
| Respond | Investigated alerts and device isolation | Can authorised responders act promptly? |
| Recover | Protected copies and restoration exercises | Can a trusted business service be restored? |
Where the layers can share the same weakness
Count dependencies as carefully as controls. Suppose one administrator account can disable endpoint protection, change network policy and delete backups. Three named layers now share one powerful failure point. Likewise, an alerting service and its escalation contact are less useful if both depend on the email system currently unavailable.
These are reasons to test combinations. Ask what remains available after an identity, device or service is compromised. Check access from the affected system's position, rather than assuming a diagram proves isolation.
Backups also have a specific limit: restoring files does not retrieve copies an attacker has stolen. Threats to publish data, disrupted services and investigation work can remain after restoration. The NCSC includes both data-theft threats and potentially lengthy recovery in its ransomware guidance. A working backup therefore cannot establish that there is nothing left to extort. [5]
For the same reason, buying an extra tool is not evidence of a stronger outcome. Check whether it closes a real gap, has an owner and can still function when a neighbouring control fails.
Use established guidance to find missing coverage
Australia's Essential Eight provides concrete mitigation strategies: patch applications, patch operating systems, use multi-factor authentication, restrict administrative privileges, control applications, restrict Microsoft Office macros, harden user applications and make regular backups. It was designed for internet-connected IT networks, so other environments may need different measures. [3]
Its maturity model recommends progressing across all eight strategies at a suitable level, with additional measures where the environment requires them. It does not claim to address every threat. [4]
NIST CSF 2.0 organises cybersecurity outcomes into Govern, Identify, Protect, Detect, Respond and Recover. These functions are concurrent areas of work, not six sequential products to buy. Use them to ask whether ownership, asset knowledge and response preparation receive the same attention as prevention. The framework describes outcomes and leaves implementation choices to the organisation. [2]
Make the next improvement something you can demonstrate
Choose a business service and walk through an authorised exercise with the people who run it. You do not need to run ransomware to find missing owners, unchecked access or a restore procedure that nobody has tried.
- Write down the service dependenciesRecord the data, identities, devices and suppliers it needs. Define acceptable downtime and data loss with its owner. This gives recovery testing a business target.
- Check the existing barriersReview patching, application restrictions, MFA and administrator access against the chosen baseline. Record exceptions and who will revisit them.
- Test one boundaryConfirm that an ordinary workstation cannot administer backups or reach a restricted management service. Test the approved route too, so necessary work still functions.
- Follow one alert through to actionUse a safe test signal. Confirm who receives it, who can isolate a device and how those people communicate if normal systems fail.
- Restore and validateRecover representative data and its application in a controlled environment. Check usability and record the time taken, dependencies and missing steps.
The NCSC recommends practising incident plans and testing restoration. CISA's response checklist includes isolation, evidence preservation and investigation before recovery. Use those guides to develop the exercise with your IT provider or security team. [5] [6]
Practise the defensive decisions
Explore the themes through DirtyPhish's games. These are learning games, not security tools or substitutes for testing a real environment.
BUILD THE LAYERS
CONTAIN THE OUTBREAK
TEST THE JUDGEMENTQuestions people ask
Does every security layer have to fail for ransomware to cause harm?
No. One compromised account or encrypted device can already cause harm. Later controls may still prevent wider access, reveal the activity or support recovery. Defence in depth gives defenders more opportunities to change the outcome after the first failure.
Can ransomware run without administrator rights?
Yes. Code running as a standard user can affect files that account can modify, including accessible shared files. Some persistence methods also work in the user's context. Removing unnecessary administrator rights remains useful because it limits additional actions and access.
How many layers of defence are enough?
There is no universal count. Start with the assets and attack paths that matter to your organisation. Look for complementary coverage and shared dependencies, then test whether the controls work together. Seven labels on a diagram do not establish seven effective barriers.
Are isolated or immutable backups enough on their own?
No. Protected copies need suitable retention, access controls and successful restoration tests. They support recovery from damaged data but do not prevent initial access or erase stolen copies. Recovery also depends on rebuilding trusted systems and addressing the attacker's access.
Do small businesses need a security operations centre?
They need a workable way to notice and respond to important signals. That may involve an IT provider or managed security service rather than an internal centre. Agree responsibilities and availability, then test the reporting and response route instead of assuming a subscription covers it.
Does defence in depth mean buying more security products?
No. Clear ownership, restricted permissions, maintained systems, enforced boundaries and rehearsed recovery all contribute. A new product is useful when it closes a relevant gap and the organisation can operate it. Product count alone does not show how much risk has been reduced.
Sources and further reading
- NIST CSRC Glossary: Defense-in-depth. Definition covering people, technology and operations. Paraphrased, with no long quotation.
- NIST: The Cybersecurity Framework 2.0. The six functions describe concurrent cybersecurity outcomes, not a prescribed sequence of tools.
- Australian Signals Directorate: Essential Eight explained. The eight mitigation strategies and their intended IT-network scope.
- Australian Signals Directorate: Essential Eight maturity model. Risk-based implementation, complementary coverage, protected backups and restoration testing.
- UK NCSC: Mitigating malware and ransomware attacks. Layered mitigation, restoration exercises, recovery limits and threats to publish stolen data.
- CISA, MS-ISAC, NSA and FBI: #StopRansomware Guide. October 2023 joint guide, read through the FBI's official copy. Covers segmentation and response, including isolation and evidence preservation.
- MITRE ATT&CK: Registry Run Keys / Startup Folder. Documents persistence that executes in the user's context with that account's permissions.
General educational guidance. Production security changes should follow your organisation's authorised change and incident-response processes. Illustrations are conceptual, not proof of a secure design.