Zero Trust with Azure Firewall, DDoS Protection, and WAF

Zero Trust has become one of the most overused terms in enterprise IT. Every vendor claims their product is "Zero Trust ready." Every security framework references it. And yet, for a business actually trying to implement it in Azure, the question of which services to use, in what order, and configured how, is rarely answered clearly.

This post is about three specific Azure services, Azure Firewall, Azure DDoS Protection, and Azure Web Application Firewall, and how they fit together to create a genuine layered defence, core to what we deliver through our cloud security practice. Not in theory. In practice, with real attack scenarios and configuration guidance that applies to businesses operating in Germany and the broader EU.

What Zero Trust actually requires at the network layer

The Zero Trust model, as originally defined by John Kindervag at Forrester Research, starts from a single assumption: the network perimeter does not exist. Any device, on any network, could be compromised. Therefore, every access request must be verified, and no traffic should be implicitly trusted because it originates inside your infrastructure.

At the network layer, this translates into three concrete requirements:

1. Inspect all traffic, including traffic between internal services, not just traffic entering from the internet.
2. Apply least-privilege access at the network level, so a compromised VM in one subnet cannot freely communicate with a database in another.
3. Assume breach, design your architecture so that a successful intrusion in one layer does not automatically give an attacker access to everything else.

This is where Azure Firewall, WAF, and DDoS Protection each play a specific role. They are not redundant: they operate at different layers of the OSI model and protect against fundamentally different attack classes.

Azure DDoS Protection: defence at the edge

A Distributed Denial of Service attack floods your infrastructure with traffic volume that legitimate users cannot compete with. Azure DDoS Protection operates at Layer 3 and Layer 4, the network and transport layers, absorbing and scrubbing attack traffic before it reaches your Virtual Network.

Azure DDoS infrastructure protection covers every Azure service at no additional cost. The two paid tiers, DDoS Network Protection and DDoS IP Protection, add adaptive tuning, the system learns your application's normal traffic patterns and adjusts mitigation thresholds automatically. It also provides attack telemetry and post-attack reports useful for incident documentation.

For most DACH businesses, the question is whether a paid tier is necessary. The answer depends on what you expose publicly. If you run public-facing web applications, APIs, or customer portals in Azure, Network Protection is worth considering. The cost is significant, roughly €2,500 per month for the first 100 protected resources, so it needs to be weighed against the actual risk profile of your applications. Below 15 protected public IP resources, DDoS IP Protection is the cheaper of the two tiers and is billed per protected IP address. Most small businesses do not need either paid tier; the WAF and Firewall combination already removes the bulk of risk. A paid tier becomes relevant when you are running something that would genuinely fail under a sustained volumetric attack and cannot afford the downtime.

Azure Web Application Firewall: protecting your applications at layer 7

WAF operates at the application layer, Layer 7, inspecting HTTP and HTTPS request content rather than just IP addresses and ports. It sits in front of your web applications via Azure Application Gateway or Azure Front Door and blocks attacks that a network firewall simply cannot see.

What WAF Blocks

• SQL Injection: An attacker appends SQL syntax to a form field or URL parameter to manipulate your database. WAF detects the payload pattern and blocks the request before it reaches the application.
• Cross-Site Scripting (XSS): Malicious scripts injected into your web pages to steal session tokens or redirect users to phishing sites.
• Remote File Inclusion and Path Traversal: Attacks that attempt to access files outside the web root, a common vector against PHP applications and content management systems.
• Bot traffic: Azure WAF includes bot management rules that distinguish between legitimate crawlers (like Googlebot) and malicious scrapers or credential-stuffing bots.

Core Rule Sets and Custom Rules

Azure WAF uses the Microsoft Default Rule Set (DRS) as its foundation. The version recommended for new policies is DRS 2.2, which is baselined on OWASP Core Rule Set 3.3.4 and so still maps to the OWASP Top 10 vulnerabilities, with additional Microsoft threat intelligence rules layered on top. You can run WAF in Detection mode first, logging rule matches without blocking, to identify false positives before switching to Prevention mode.

Custom rules let you add business-specific logic: blocking requests from specific geographic regions, requiring specific headers, or rate-limiting aggressive IPs. For a German B2B application that has no legitimate reason to receive traffic from certain regions, geo-blocking via WAF custom rules is an effective first line of defence.

Azure Firewall Premium: deep inspection and outbound control

Azure Firewall is the central inspection point for all traffic flowing through your Virtual Network. The Premium tier adds capabilities that are essential for a genuine Zero Trust implementation:

• TLS inspection: Decrypts outbound HTTPS traffic to inspect it for malware and data exfiltration before re-encrypting. Without this, encrypted traffic bypasses all content inspection.
• IDPS (Intrusion Detection and Prevention System): Uses Microsoft's threat intelligence feed to identify and block known malicious patterns in network traffic, including command-and-control traffic from malware that has already gotten past endpoint defences.
• URL filtering: Blocks access to known malicious sites and allows you to enforce an allowlist approach for outbound web access from servers.
• East-west traffic control: Enforces segmentation between subnets. A compromised application server cannot reach your database subnet unless explicitly permitted by a Firewall rule.

BSI IT-Grundschutz Alignment

The BSI IT-Grundschutz building blocks NET.3.2 (Firewall) and NET.1.1 (Netz-Architektur und -design) both apply to Azure Firewall deployments. Specifically, NET.3.2.A2 requires an allowlist approach to the rule base, only explicitly permitted connections should flow and everything else must be blocked. Azure Firewall's default-deny approach satisfies this requirement, but the rule base needs to be designed and documented to demonstrate compliance. Using Azure Firewall Policy and Azure Policy assignments provides the audit trail the BSI expects.

How the three services work together: a reference architecture

A complete Azure network security architecture positions these services in a specific order:

1. Internet traffic arrives and is first processed by Azure DDoS Protection at the Virtual Network level, volumetric attacks are absorbed before reaching any service.
2. HTTP/HTTPS application traffic then hits Azure Application Gateway with WAF enabled: SQL injection, XSS, and bot traffic are blocked at Layer 7.
3. All remaining traffic, including outbound traffic from VMs and east-west traffic between subnets, is inspected by Azure Firewall Premium, which enforces segmentation, blocks known bad IPs, and inspects encrypted outbound traffic.

This is the Hub-and-Spoke or Azure Virtual WAN topology recommended by Microsoft for enterprise Azure deployments. The Firewall sits in a central hub Virtual Network and all spoke VNets route through it. This means you get centrally logged, centrally enforced network security policy rather than managing security groups on every individual subnet.