# Defence-in-Depth Security Layers

> Chapter 19 of the Courseiva SC-900 curriculum — https://courseiva.com/learn/sc-900/defence-in-depth-sc900

**Official objective:** 1.1 — SCI Concepts

## Introduction

Why is the defence-in-depth security model a foundational concept in the SC-900 exam's Security Concepts domain (Objective 1.1)? You will learn how multiple layers of security controls work together to protect data and systems. Approximately 10-15% of SC-900 questions touch on defence-in-depth principles, layering, and the specific Microsoft security solutions aligned with each layer. Understanding this model is critical for answering scenario-based questions about security architecture.

## Defence-in-Depth: The Castle Analogy

A medieval castle is a fortified stronghold built to guard a kingdom's most valuable treasure. The outermost layer is the kingdom's border—guards patrol and check all incoming travelers (network perimeter firewall). Inside the border, a moat surrounds the castle walls (network segmentation and ACLs). The castle walls themselves are thick stone with arrow slits (host firewalls and intrusion prevention). Once inside the castle, doors to each room have locks (OS hardening and access control lists). The treasure room has a reinforced door with a combination lock (data encryption at rest). The guards inside the castle challenge anyone who looks suspicious (user authentication and MFA). Finally, the treasure itself is in a locked chest (application-level security and data classification). If an attacker breaches the moat, they still face the walls; if they get through the walls, they encounter locked doors; if they pick the lock, they must guess the combination; and even if they open the chest, the treasure is encrypted. Each layer provides independent protection, slowing the attacker and increasing detection chances. In IT, defence-in-depth means using multiple security controls across different layers—physical, network, host, application, data, and identity—so that a failure in one does not compromise the entire system. Just as a castle relies on overlapping defenses, an enterprise network uses firewalls, antivirus, encryption, access controls, and monitoring to create a resilient security posture.

## Core explanation

### What is Defence-in-Depth?
Defence-in-depth is a security strategy that employs multiple layers of defense to protect information and systems. The principle is that if one layer fails, another layer is already in place to thwart the attack. The model originates from military strategy and is formalized in cybersecurity as a layered approach across physical, technical, and administrative controls. The SC-900 exam expects you to understand the seven layers commonly referenced by Microsoft: Physical, Identity & Access, Perimeter, Network, Compute, Application, and Data.

### Why Defence-in-Depth Exists
No single security control is foolproof. Firewalls can be misconfigured, passwords can be stolen, software can have vulnerabilities. Defence-in-depth acknowledges this reality and creates redundancy. For example, even if an attacker bypasses the network firewall, they still face host-based firewalls, antivirus, and application controls. The model also provides defense in breadth—covering different types of threats (malware, unauthorized access, data leakage) with specialized controls.

### The Seven Layers (Microsoft Model)
Microsoft's defence-in-depth model maps to specific products and best practices. The SC-900 exam tests your ability to identify which layer a given control belongs to.

- **Physical Security**: Protects hardware from physical access. Examples: locked server rooms, biometric access, CCTV. In Azure, this includes datacenter security controls like badge access and perimeter fencing.
- **Identity & Access**: Controls who can access resources. Includes Azure Active Directory (now Microsoft Entra ID), Multi-Factor Authentication (MFA), Privileged Identity Management (PIM), and Conditional Access policies.
- **Perimeter**: Protects the network boundary. Includes Azure Firewall, Network Security Groups (NSGs), Azure DDoS Protection, and Web Application Firewall (WAF).
- **Network**: Limits communication between resources. Includes Virtual Network (VNet) segmentation, NSGs, Azure Bastion, and private endpoints.
- **Compute**: Secures virtual machines, containers, and serverless functions. Includes endpoint protection (Microsoft Defender for Cloud), OS hardening, and vulnerability management.
- **Application**: Ensures applications are secure. Includes DevSecOps practices, application security testing, and Azure App Service authentication.
- **Data**: Protects data at rest, in transit, and in use. Includes Azure Storage encryption, Azure SQL Database Transparent Data Encryption (TDE), Azure Information Protection, and Microsoft Purview.

### How Defence-in-Depth Works Internally
Each layer provides a set of controls that enforce security policies. When a request flows from the internet to a resource in Azure, it traverses these layers sequentially:
1. **Perimeter**: The request hits Azure DDoS Protection and Azure Firewall. DDoS scrubs traffic to filter out attack packets. Firewall inspects packet headers and payloads against allow/deny rules.
2. **Network**: The request enters a VNet. NSGs at the subnet and NIC level filter traffic based on source/destination IP, port, and protocol. Only allowed traffic passes.
3. **Compute**: On the VM, the guest OS firewall (Windows Firewall or iptables) filters further. Microsoft Defender for Cloud monitors for malware and anomalies.
4. **Application**: The application itself enforces authentication and authorization. For example, an ASP.NET app validates JWT tokens.
5. **Data**: The application queries a database that requires authentication (SQL authentication or Azure AD) and all data is encrypted at rest using TDE.

### Key Components and Defaults
- **Azure Firewall**: Stateful firewall with built-in high availability. Default deny-all policy; must explicitly allow traffic.
- **NSGs**: Default allow all outbound traffic, deny all inbound traffic. Rules are evaluated in priority order (lowest number first).
- **Azure DDoS Protection**: Basic tier is always on (monitors traffic). Standard tier provides adaptive tuning and cost protection.
- **MFA**: Microsoft Entra ID offers Conditional Access to enforce MFA. Default: no MFA enforced until configured.
- **Encryption at rest**: Azure Storage uses 256-bit AES encryption by default. Azure SQL Database TDE is enabled by default for new databases.

### Configuration and Verification Commands
In Azure CLI, you can view NSG rules:
```bash
az network nsg rule list --nsg-name MyNsg --resource-group MyRG --output table
```
To check Azure Firewall policy:
```bash
az network firewall policy show --name MyFirewallPolicy --resource-group MyRG
```
For Azure DDoS Protection status:
```bash
az network ddos-protection show --resource-group MyRG --name MyDdosPlan
```

### Interaction Between Layers
Layers work together to provide defense. For example, Conditional Access (Identity layer) can block a user even if they have valid credentials if the device is not compliant. The Network layer can enforce that only traffic from certain IPs reaches a VM. The Compute layer can require that the VM has endpoint protection enabled. In Azure Policy, you can enforce that all VMs must use managed disks (encrypted). This creates a chain of enforcement.

### Exam-Relevant Details
- The SC-900 exam focuses on the **seven layers** and the **shared responsibility model** (which is related but separate).
- For each layer, know at least **two Microsoft security solutions** that belong to it.
- Understand that defence-in-depth is **not a product** but a **strategy**.
- The exam may present a scenario and ask which layer a control belongs to. For example, "Azure Firewall belongs to which layer?" Answer: Perimeter.
- Know that **data is the final layer** and encryption is a key control.
- The **principle of least privilege** is applied across all layers but is especially associated with Identity & Access.

## Real-world context

### Enterprise Scenario 1: Financial Services Compliance
A bank must comply with PCI DSS and SOX. They deploy defence-in-depth in Azure: Physical security is handled by Microsoft datacenters. Identity layer uses Azure AD with Conditional Access requiring MFA for all admin accounts. Perimeter layer uses Azure Firewall with explicit deny-all rules, only allowing financial data APIs. Network layer segments the environment into three VNets: web, application, and database. NSGs block all traffic except required ports between tiers. Compute layer uses Microsoft Defender for Cloud to scan VMs for vulnerabilities and enforce that all VMs have endpoint protection. Application layer uses Azure App Service with built-in authentication and WAF to block SQL injection. Data layer uses Azure SQL Database with TDE and Always Encrypted for sensitive columns. Misconfiguration at any layer can lead to audit findings. For example, if an NSG accidentally allows all inbound traffic, the bank could fail a penetration test. Scaling considerations: the bank uses Azure Policy to enforce security controls across hundreds of subscriptions.

### Enterprise Scenario 2: Healthcare and HIPAA
A hospital stores electronic health records (EHR) in Azure. They must protect patient data. Physical layer is Microsoft's responsibility. Identity layer uses Azure AD with Conditional Access that blocks access from non-compliant devices. Perimeter layer uses Azure Firewall and DDoS Protection. Network layer uses private endpoints for Azure SQL Database so data never traverses the internet. Compute layer uses Azure Kubernetes Service (AKS) with Azure Defender for containers. Application layer uses API Management with OAuth2. Data layer uses Azure Information Protection to label records as 'Highly Confidential' and Azure Storage encryption with customer-managed keys. Common mistake: forgetting to enable encryption on backups. The hospital uses Azure Backup with encryption enabled. Performance: encryption adds minimal latency (usually <1ms).

### Enterprise Scenario 3: E-commerce and DDoS Protection
An online retailer faces frequent DDoS attacks during sales events. They deploy Azure DDoS Protection Standard on their virtual network. The perimeter layer also includes Azure Front Door with WAF to filter malicious traffic. Network layer uses NSGs to restrict traffic to only necessary ports. Compute layer uses scale sets with health probes to automatically replace unhealthy instances. Application layer uses ASP.NET Core with anti-forgery tokens and input validation. Data layer uses Azure Cosmos DB with encryption at rest. During an attack, DDoS Protection automatically scrubs traffic and Azure Firewall drops packets based on rate limits. The retailer also uses Azure Monitor to alert on unusual traffic patterns. Misconfiguration: if the WAF policy is not tuned, it may block legitimate traffic, causing false positives. The retailer uses WAF policy in prevention mode after testing in detection mode.

## Exam focus

### What SC-900 Tests on Defence-in-Depth
The SC-900 exam (Objective 1.1) expects you to:
- Define defence-in-depth and its purpose.
- Identify the seven layers (Physical, Identity, Perimeter, Network, Compute, Application, Data).
- Match Microsoft security solutions to the correct layer.
- Understand that defence-in-depth is a strategy, not a product.

### Common Wrong Answers and Why Candidates Choose Them
1. **"Defence-in-depth means having multiple firewalls."** This is wrong because defence-in-depth includes multiple types of controls across all layers, not just multiple instances of the same control. Candidates choose this because they think 'depth' means multiple copies.
2. **"The perimeter layer includes encryption."** Encryption belongs to the data layer. Candidates confuse perimeter (network boundary) with data protection.
3. **"Identity is the only layer that matters because of zero trust."** While identity is critical, defence-in-depth still requires all layers. Zero trust complements but does not replace layered defense.
4. **"Azure Security Center (now Defender for Cloud) is a perimeter layer solution."** It is a compute layer solution because it protects VMs, containers, and serverless workloads.

### Specific Numbers and Terms on the Exam
- The number of layers: **seven**.
- Exact layer names: Physical, Identity & Access, Perimeter, Network, Compute, Application, Data.
- Microsoft solutions: Azure Firewall (Perimeter), NSGs (Network), Azure AD (Identity), Microsoft Defender for Cloud (Compute), Azure Information Protection (Data).
- The principle of **least privilege** is associated with the Identity layer.
- **DDoS Protection** is part of the perimeter layer.

### Edge Cases and Exceptions
- The exam may ask: "Which layer does Azure Bastion belong to?" It is a network layer solution because it provides secure RDP/SSH access without exposing public IPs.
- "Which layer does Conditional Access belong to?" Identity layer.
- "Which layer does Azure Policy belong to?" It is not tied to a single layer; it enforces rules across multiple layers. The exam may not ask this directly, but understand it spans layers.

### How to Eliminate Wrong Answers
- If a question asks about a control that protects the network boundary (firewall, DDoS), it is perimeter layer.
- If it controls access to resources (MFA, roles), it is identity layer.
- If it protects the VM or OS (antimalware, patching), it is compute layer.
- If it encrypts data (TDE, Azure Storage encryption), it is data layer.
- Always read the scenario: look for clues like "blocks traffic" (network/perimeter), "authenticates user" (identity), "scans for vulnerabilities" (compute).

## Step by step

1. **Define Security Requirements** — Begin by identifying what needs protection: data, applications, and infrastructure. Classify data by sensitivity (public, internal, confidential, restricted). Determine compliance requirements (e.g., GDPR, HIPAA). This step is not technical but sets the scope for all subsequent layers. In Azure, you can use Microsoft Purview to classify data. The output is a security baseline document that defines which controls are needed at each layer.
2. **Implement Physical Security** — Secure the physical hardware. In on-premises, this means locked server rooms, access logs, and cameras. In Azure, Microsoft handles physical security at datacenters—you don't configure it. However, you must trust Microsoft's controls. For hybrid scenarios, you may have on-premises servers that need physical protection. This is the outermost layer and is often overlooked in cloud discussions because it's abstracted.
3. **Configure Identity and Access Controls** — Use Microsoft Entra ID to manage identities. Enforce MFA via Conditional Access policies. Implement Privileged Identity Management (PIM) for just-in-time admin access. Apply least privilege by assigning roles with the minimum permissions needed. For example, assign the 'Reader' role instead of 'Contributor' if a user only needs to view resources. This layer is critical because identity is the new perimeter.
4. **Harden the Perimeter** — Deploy Azure Firewall to filter inbound and outbound traffic. Enable Azure DDoS Protection Standard to mitigate volumetric attacks. Use Web Application Firewall (WAF) on Application Gateway or Azure Front Door to protect web apps from SQL injection and XSS. Configure Network Security Groups (NSGs) to restrict traffic between subnets. For example, deny all inbound traffic except from a jump box.
5. **Segment the Network** — Create separate VNets for different environments (prod, dev, test). Use NSGs and Azure Firewall to control traffic between VNets. Implement private endpoints for Azure services to keep traffic within Microsoft backbone. Use Azure Bastion to manage VMs without exposing RDP/SSH ports. This limits lateral movement if an attacker gains access to one resource.
6. **Secure Compute Resources** — Apply OS-level hardening: disable unused ports, apply security updates, use antimalware. Enable Microsoft Defender for Cloud to assess vulnerabilities and provide security recommendations. Use Azure Policy to enforce that VMs must be from approved images. For containers, use Azure Defender for Kubernetes. This layer ensures that even if an attacker reaches a VM, it is hardened.
7. **Protect Applications and Data** — At the application layer, implement authentication and authorization (e.g., OAuth, OpenID Connect). Use Azure App Service authentication to offload identity. For data, enable encryption at rest (Azure Storage encryption, SQL TDE) and in transit (TLS 1.2+). Use Azure Information Protection to classify and label sensitive documents. Finally, monitor using Microsoft Sentinel for SIEM and SOAR. This is the innermost layer—if all else fails, data is still encrypted.

## Comparisons

### Defence-in-Depth vs Zero Trust

**Defence-in-Depth:**
- Uses multiple layers of defense (physical, network, identity, etc.)
- Assumes some layers may fail, so redundancy is built in
- Focuses on protecting the perimeter and internal network
- Controls are often static (e.g., firewall rules)
- Originated from military strategy

**Zero Trust:**
- Assumes no implicit trust; verify every request
- Treats every access attempt as a potential breach
- Focuses on identity, device health, and least privilege
- Controls are dynamic (e.g., Conditional Access policies)
- Modern model for cloud and remote work

## Common misconceptions

- **Misconception:** Defence-in-depth means using multiple firewalls in series. **Reality:** True defence-in-depth uses different types of controls across layers (physical, identity, network, etc.), not just multiple instances of the same control. A firewall is only one layer (perimeter).
- **Misconception:** Encryption at rest belongs to the application layer. **Reality:** Encryption at rest is a data layer control. The application layer deals with authentication, authorization, and input validation.
- **Misconception:** Defence-in-depth is only about network security. **Reality:** It encompasses all layers including physical, identity, compute, application, and data. Network is just one of seven layers.
- **Misconception:** Azure DDoS Protection is a compute layer solution. **Reality:** DDoS Protection is a perimeter layer solution because it protects the network boundary from volumetric attacks.
- **Misconception:** The shared responsibility model is the same as defence-in-depth. **Reality:** The shared responsibility model defines who is responsible for security (Microsoft vs. customer), while defence-in-depth defines how security controls are layered. They are complementary but distinct.

## Key takeaways

- Defence-in-depth is a layered security strategy with seven layers: Physical, Identity & Access, Perimeter, Network, Compute, Application, Data.
- Microsoft solutions: Azure Firewall (Perimeter), NSGs (Network), Azure AD (Identity), Defender for Cloud (Compute), Azure Information Protection (Data).
- No single layer is sufficient; layers provide redundancy and breadth of protection.
- The data layer is the innermost layer; encryption at rest and in transit are key controls.
- The principle of least privilege applies primarily to the Identity & Access layer.
- Azure DDoS Protection is a perimeter layer solution.
- Defence-in-depth is a strategy, not a product; it guides how to combine security controls.

## FAQ

**What is defence-in-depth in cybersecurity?**

Defence-in-depth is a security strategy that uses multiple layers of defense to protect information and systems. If one layer fails, another layer is in place to stop the attack. The layers include physical, identity, perimeter, network, compute, application, and data. Each layer uses different types of controls (e.g., firewalls, encryption, access controls) to provide redundancy and breadth of protection.

**What are the seven layers of defence-in-depth according to Microsoft?**

The seven layers are: Physical Security, Identity & Access, Perimeter, Network, Compute, Application, and Data. These layers cover everything from datacenter security to data encryption. The SC-900 exam expects you to know these layers and match Microsoft security solutions to them.

**How does defence-in-depth differ from zero trust?**

Defence-in-depth is a layered approach that assumes some layers may fail and provides redundancy. Zero trust assumes no implicit trust and verifies every access attempt. Defence-in-depth often focuses on perimeter and network controls, while zero trust focuses on identity, device health, and least privilege. Both can be used together: defence-in-depth provides the overall architecture, and zero trust guides access decisions.

**Which Azure service belongs to the perimeter layer?**

Azure Firewall belongs to the perimeter layer. Other perimeter layer services include Azure DDoS Protection and Web Application Firewall (WAF). These services protect the network boundary from external threats.

**Is encryption a part of defence-in-depth?**

Yes, encryption is a key control in the data layer of defence-in-depth. It protects data at rest (e.g., Azure Storage encryption, SQL TDE) and in transit (e.g., TLS). Even if an attacker bypasses other layers, encrypted data remains unreadable without the decryption key.

**What is the purpose of the compute layer?**

The compute layer secures virtual machines, containers, and serverless functions. Controls include OS hardening, antimalware, vulnerability management (Microsoft Defender for Cloud), and ensuring only approved images are used. This layer protects the workload itself.

**How do Network Security Groups (NSGs) fit into defence-in-depth?**

NSGs are part of the network layer. They act as a distributed firewall that filters traffic between subnets and VMs based on source/destination IP, port, and protocol. They help segment the network and limit lateral movement.

---

Interactive version with quiz and diagrams: https://courseiva.com/learn/sc-900/defence-in-depth-sc900