Studying for the AZ-500: What is defense in depth (DiD)?

Studying for the AZ-500 exam? Understanding defense in depth (DiD) best practices will go a long way in preparing for the certification and shoring up your organization’s defenses against common attack vectors.

• What is a defense in depth strategy?
• Why is defense in depth important?
• The seven layers of defense in depth

A defense in depth strategy leverages multiple security measures to protect an organization's assets. This ensures that when one control fails, another is ready to defend an IT system. There are seven layers involved in a security posture focused on DiD best practices: 

• Physical security
• Identity and access
• Perimeter
• ​​Network
• Compute
• Applications
• Data

Each DiD layer is important and should be independently secure. For example, identity and access should be managed separately and securely to prevent identity exploitation. This is especially important today with the shift in focus to identity-centric security: If identities are secure, so are the resources they can access.

This shift to identity-centric security comes as organizations move from private to public cloud environments. In the past, orgs had an on-premises environment with identities that existed in a private cloud with a network perimeter at the outer edge. The focus was on that network perimeter—its location made it the largest surface area of attack. 

With the move to a public cloud, identity becomes the new outer edge. Our public cloud-based identity services span our network perimeters and other public cloud-based resources we access over the web. This makes identity the new largest surface area of attack.

Think about surface area using this DiD analogy:

If you were to lay siege to a medieval city, would you first attack the heavily fortified defenses at the center or the less guarded outer perimeter and slowly advance your attack toward the heart of the city? I’m no military strategy buff, but I think historical data would indicate that most invaders would attack the outer perimeter first. Why? Because they can use the resources from each layer they defeat in sequential attacks as they move towards the city center. 

This is where defense in depth comes in. With this approach, we shore up our defenses from outside in, knowing that most threats will start with those outer layers as their primary attack vector. At the same time, we fortify every layer to its maximum functional state. When we secure each layer, we can prevent most bad actors and slow down attackers when they are successful to give us time to mount a proper response.

Because DiD can be a daunting concept to unpack, let's break down each of the seven layers in the context of implementing a DiD strategy in an organization.

Layer 1: Physical security

Physical security is the real-world outer edge, because even with all the advances in public cloud technology, we still have data centers. We haven’t yet figured out how to run our environments in zero-dimensional spaces. So even though we’ve moved from the private cloud (we manage the data center) to the public cloud (vendor manages the data center), we’re still at the mercy of physical controls to secure these real-world data centers. 

We’re talking about controls like security guards, cameras, biometrics, RFID cards, mantraps, gates, two-person switches, keys, and hardware encryption, such as FIPS 140-X. Those physical controls can start to add up—and that’s where the public cloud really shines. In Azure, we don’t have to worry about those physical controls (well, we still worry, but we don’t have to worry about being responsible for them). Microsoft’s got it covered, which alleviates a major strategic and financial burden for an organization.

Physical security doesn’t really relate to the AZ-500. We have to trust that our vendor is implementing physical security controls. But we should perform due diligence and review service contracts and terms of service to ensure they meet organizational needs. 

Layer 2: Identity and access

In the public cloud, specifically Azure, identity and access management (IAM) comes from the heart of Microsoft cloud-based services known as Microsoft Entra ID. Entra ID is the IAM-based service that ensures the security of our identities. It also provides security functionalities such as:

• Group-based access control to resources
• Identity protection to detect risks
• Control over external identity collaborations
• Multi-factor authentication (MFA)
• Single sign-on (SSO)
• Conditional access policies to control access to resources based on various policy conditions
• Privileged identity management (PIM) to allow for privilege escalation to resources in a controlled and documented manner
• Role-based access control segmented by identity resource access and compute, network, and storage resource access

How does this look in an organization where we want to implement a defense in depth strategy? The focus of this article is the public cloud, so we’ll discuss this from an identity-centric perspective. 

Let’s talk about Microsoft Entra ID

Entra ID is the identity provider where we create identity resources such as user, resource/application, and group. It’s also the service that provides access management for these identity resources and the security features to protect them from exploitation. On our Entra ID instances (aka tenants), we can create cloud-native users. Or we can integrate with the existing directory services in our on-prem environments, such as the industry's golden standard, Active Directory Domain Services (AD DS). 

No matter which we choose, we can implement security features at the tenant level to protect identities and provide access to resources using role assignments. With these features, we can:

• Protect authentication attempts using MFA
• Use identity protection to detect risky sign-ins or user behaviors
• Enforce authentication requirements for users using conditional access policies
• Control external collaborations from external organizations

Microsoft Entra ID roles

For authorization, we can use conditional access policies to control access to resources based on specific conditions. We also have two role-based authorization engines, known as Entra ID roles, that grant access to identity resources based on assigned roles—for example, a user administrator who needs access to manage a group of users.

Microsoft Azure roles

For resource access to our public cloud resources running in Azure subscriptions, we have Azure roles. Azure roles provide role assignments for users who need to access resources such as virtual machines (VMs), storage accounts, Azure SQL instances, and virtual networks.

The principle of least privilege

The most important thing to focus on is the principle of least privilege (PoLP): granting users the minimum permissions needed to perform their role.* We want to enable security controls that challenge and monitor identities so we can prevent an attack or, at minimum, quickly recognize one so we can immediately disable access for compromised users and perform an access review to determine the incident’s impact.

*Access is implicitly denied in Azure. You have to explicitly allow it . . . and that’s a good thing.

Layer 3: Perimeter

“It won’t happen to us.” —Your org's final words just before the inevitable

DDoS (distributed denial-of-service) attacks first hit in the mid to late 1970s, and they’ve been a constant threat since then. Do a quick search for “DDoS attack statistics” and you’ll find there were roughly 13 million attacks in 2022. And the numbers continue to trend upward as more devices come online. This leaves us only one choice: protect our perimeters, or publicly accessible resources. 

DDoS attacks: What’s at risk

In Azure, a publicly accessible resource refers to a publicly routable resource, such as an organization’s e-commerce website, partner portal, or streaming platform. If you can access it over the internet, it’s at risk of a DDoS attack. DDoS attacks are especially damaging because they take down critical services, resulting in financial losses. They’re also hard to stop because they come from a bot network of infected devices that acts as a proxy and carries out nefarious actions from a controller device. 

Because this attack is almost indistinguishable from real traffic, we find ourselves in a paradoxical situation. We want to allow traffic from those who use our public resources and we want to block traffic from nefarious devices. This is where DDoS protection comes into play.

DDoS protection in Azure

DDoS protection in Azure is a platform-managed security feature that’s on by default. DDoS protection uses AI and bot network traffic monitoring to determine when a DDoS attack is happening. An organization with an on-prem environment would have to manage its own solution. But Azure Basic protection is built in. In Azure, we can purchase a higher level of protection, with a dedicated response team, for our virtual networks—something to keep in mind when securing perimeters.

Layer 4: Network

Creative service names aside, we seriously need to protect our networks. In on-prem environments, networks are the private cloud resources. Azure is similar, but the networks are virtual, and we protect these virtual networks the same way we do on-prem networks. How? With security rules implemented via network virtual appliances (NVAs) and routing configurations that force traffic through NVAs where it’s inspected and sent to its final approved destination or blocked and reported for auditing.

Network protection in Azure

In Azure, this protection comes in the form of user-defined routes, network security groups (NSGs), and Azure Firewall. (You can also use next-gen third-party firewalls, but we won’t discuss those here.) 

If your organization has a hub-and-spoke network topology, or a variation of one, it can implement a firewall to provide a centralized resource for filtering traffic. You would inject a user-defined route into the virtual router running behind the virtual networks to force traffic to the firewall and create rules on the firewall to control that traffic. Additionally, you can use NSGs, which work as stateful network access controls (NACLs), to control traffic at the virtual network interface card (vNIC) or subnet scope via security rules. 

Layer 5: Compute

In the public cloud, we have compute resources (VMs, container instances, Kubernetes workloads, app services, functions) doing things like . . . well . . . computing. These resources provide computing power for workloads to allow applications to function and perform tasks. How we go about securing compute resources and our responsibility implementing that security depends on the anything as a service (XaaS) type we select when we set up the resources. 

Example: Securing a virtual machine

For example, securing a VM’s operating system, applications, and any code underneath those applications requires more responsibility than securing app services. You don’t manage an application’s underlying OS—Microsoft patches and hardens it. 

Let’s say you have a two-tier monolithic application running on Azure VM and Azure SQL. With the Azure VM, you manage the patching and OS hardening to secure the VM, the encryption configuration for the VM’s disks, and how these resources are accessed (usually with a hardened jump box, but preferably with Azure Bastion). 

Again, this can change based on the computing service. Just be diligent when you shore up your compute resources and outline your responsibilities and capabilities when implementing security on those services.

Layer 6: Applications

Securing applications can be a daunting task because they’re usually accessed publicly. But good news: Protecting them in the public cloud is similar to protecting them in a private cloud. 

Securing applications in a public cloud

You can encrypt data in transit using TLS/SSL, which protects applications by encrypting the traffic between the apps and their clients. In Azure, you can engage services like Key Vault to manage encryption certificates so they can be used with your applications, preventing things like man-in-the-middle (MITM) attacks. With applications in Azure, you can even provide network integrations to allow traffic to flow over private networks. 

For example, let’s say we have an application in Azure that users on-prem want to access. They can do so over the private network connectivity between on-prem and Azure virtual networks using private endpoints. If this application accesses a database running outside Azure, we could use hybrid connections to provide secure access to our database over the public internet. 

At the end of the day, it comes down to understanding the application’s outbound and inbound traffic and implementing encryption and secure paths for that traffic.

Layer 7: Data

Data is the real asset. It’s the reason organizations set up all this infrastructure in the first place. Whether you realize it or not, you’re in the data business. It’s your job to secure the data and ensure packets of data arrive at their destination without being sniffed. And don’t forget making sure one bad configuration on a singular key component doesn’t leave your org open to exploitation. 

How to secure data in Azure

In Azure, you secure data by doing things like data classification, database auditing, and data masking and implementing data encryption standards for sensitive data. For example, if your organization has a database storing sensitive data that contains personally identifiable information (PII), you’ll want to implement database classification to designate which data is sensitive so you know exactly what to protect. 

Data masking and data audits

Once you identify the sensitive data, you can set up data masking to mask portions of that data or implement encryption to ensure that data is always encrypted if necessary. Finally, you can perform database audits to ensure everything functions as intended. We can do all of this with our Azure SQL databases. Additionally, on these platform as a service (PaaS) models in Azure, we can use data plane-focused Azure roles to provide access to data and separate data permissions from the control plane. 

With a network-focused perspective, we can control how data is accessed—public internet, private network, etc. You need to consider all of the above when protecting your data. If you’re developing defense in depth for the first time, I recommend classifying your data (so you know what needs protection) and then following that data to see where it flows (so you can identify where it might be at risk).

You can see just how overwhelming it can be to tackle defense in depth. I promise, if you break it down into individual layers, it will be easier to implement these defense in depth strategies in your organization. And that brings us full circle to the AZ-500 certification. The AZ-500 certification prep courses teach you:

• Defense in depth strategies
• How to prepare for the certification
• How to implement defense in depth as a proper security engineer

 Thanks for reading. See you on the platform.