Azure Firewall Manager

Azure Firewall Policy

This is a new resource type that is generally available today. Azure Firewall Policy outsources the configuration and management of the firewall to a policy resource; that means that the usual settings in the Azure Firewall for things like rules and Threat Intelligence move from the firewall resource to a policy when a policy is associated with the firewall.

Policies can be created in a hierarchy. You can create a parent/global policy that will contain configurations and rules that will apply to all/a number of firewall instances. Then you create a child policy that inherits from the parent; note that rules changes in the parent instantly appear in the child. The child is associated with a firewall and applies configurations/rules from the parent policy and the child policy instantly to the firewall.

Problem

I’ve deployed and configured multiple customers where we have virtual data centers (VDCs, which are governed & secured hub and spoke architectures) across multiple regions. Creating rules configurations to allow flows from a spoke/service in one region to another spoke/service in another region is a royal pain in the tushie. Here’s the network flow (as I documented with routing here):

Source device

Outbound NSG rules in source spoke

Firewall in source hub

Firewall in destination hub

Inbound NSG rules at destination spoke

Destination device

There are potentially 4 sets of rules to configure for a simple service running on a single protocol/port. Today I configured Microsoft Identity Management for this scenario and there were dozens of protocol/port combinations across three spokes. The work took hours to complete – which I did in code and it provided a working result for the identity consulting team.

I minimise the work by controlling outbound flows in the local hub firewall, not in the NSG. So the NSGs do not control outbound flows at all. I could allow all via the firewall, even to other private networks, but that goes against the idea of compartmentalisation or micro-segmentation to combat modern network threats – so I need to configure both firewalls for a flow.

Solution

Re-think the firewall for a moment. Imagine you had one virtual firewall that spanned all of your Azure regional deployments. You can control all global flows with one configuration in that global virtual firewall. The global virtual firewall has instances in each Azure region. Any local flows can be configured just in that instance. That’s what Firewall Policy allows.

Parent Policy: Place all your global configurations in here. Some configurations will be company-wide, such as Threat Intelligence. Some rules, like allowing access to Microsoft URIs or Azure services (service tags) will be global too. And this is where you put the rules to allow flows between one regional deployment and another. This global management takes all your local Azure Firewall resources and treats them as a single security service.

Child Policies: A child policy will be created for each Azure Firewall instance. This policy will inherit the above from the parent applying the global configuration. Local rules, to allow north-south access to/from local services (Internet or on-prem) or east-west (spoke-to-spoke in the same regional deployment) will be configured here. RBAC can be enabled to allow local network admins to do their own thing, but unable to undo what the parent has done.

I haven’t had a chance to test Azure Firewall Policy out yet since the GA announcement, but I’m hoping that the third tier in rules (Rules Groups) made it from preview to GA. I do have groupings of rules collections based on buckets of priorities. This organisation would be awesome in my vision of Azure Firewall management.

Speaker: Sinead O’Donvan (Irish, by the accent)

Zero Trust Architecture document

7 pillars:

Identity
Devices
Data
Apps
Infrastructure
Networking – the focus here

Verify explicitly every access control

Being on the network is not enough

Use least privilege access

IP address is not enough

Assume breach

No one is perfectly secure. Identify the breach. Contain the breach. Do your best to stop breaches in the first place.

You cannot claim success:

It requires constant improvement.

Network Maturity Model

Traditional (most customers)
- Few network security perimeters and flat open network
- Minimal threat protection and static filtering
- Internal traffic is not encrypted
Advanced
- Many ingress/egress cloud micro-perimeters with some micro-segmentation
- Cloud native filtering and protection for known threats
- User to app internal traffic is encrypted
Optimal
- Fully distributed ingress/egress cloud micro-perimeters and deeper micro-segmentation
- ML-based threat protection and filtering with context-based signals
- All traffic is encrypted

Three Cores of Azure Network Security

Segment – prevent lateral movement and data exfiltration
Protect – secure network with threat intelligence
Connect – embrace distributed connectivity … or face revolt from the users/devs

Deploy securely across DevOps process

Azure Features

Azure Firewall
Azure WAF
Azure Private Link
Azure DD0S Protection

Plus:

VNets
NSGs
UDRs
Load Balancer

Network Segmentation

3 approaches:

Host-based: an agent on the VM implements it
Hypervisor: Example, VMware SNX
Network controls

Azure Network Segmentation Controls

Subscription: RABC, logic isolation for all resources
Virtual network: An isolated and highly secure environment to run your VMs and apps. “This is the hero of segmentation”
NSG: Enforce and control network traffic security rules that allow or deny network traffic for a VNet or a VM.
WAF: Define application specific policies to protect web workloads.
Azure Firewall: Create and enforce connectivity policies using application, network and threat intelligence filtering across subscription(s) and VNet(s).

Multi-Level Segmentation

Connectivity:
- Use both public or private IP. Public app interface is public, backend is private.
- Choose cloud transit approach VNet peering or Virtual WAN.
- Carefully control routing
Infrastructure
- Segment across subscription, vnet, and subnet boundaries
- Managed at an org level
Application
- Enable application aware segmentation
- Easily create micro perimeters
- Managed at an application level