Skip to main content
emnode
Compliance Low severity MCSB LT-4

Microsoft Defender for Cloud · Azure Network Watcher

Network Watcher should be enabled

Written and reviewed by Emnode · Last reviewed

What does the recommendation "Network Watcher should be enabled" check?

Flags any subscription region that hosts virtual networks but has no Network Watcher instance provisioned for it. Network Watcher is a regional service, so the check looks for a Network Watcher instance in each region you actually use, not once per subscription. By default Azure auto-creates that instance the first time you build a virtual network in a region, so a flag usually means the auto-create was suppressed at the subscription level or the instance was deleted. The control only confirms the service exists in the region; it does not verify that NSG flow logs, packet capture, connection monitors or traffic analytics are switched on, so a region can satisfy this control while still collecting no diagnostic data at all. It also says nothing about the quality, retention or destination of any logs you do capture.

Why does "Network Watcher should be enabled" matter?

When a network incident happens, lateral movement, data exfiltration over an unexpected port, a broken route, the questions are about traffic that has already flowed. Without Network Watcher provisioned in the affected region beforehand, you cannot run a packet capture, replay NSG flow logs or trace the next hop after the fact, because there is nothing recording or able to observe that path. The practical consequence is a security investigation or outage that drags on for hours with no authoritative network evidence, weakening forensic conclusions and any regulatory account you have to give. Provisioning is free and near-instant, so the only cost of leaving it disabled is paid during the incident you were least prepared for.

How do I fix "Network Watcher should be enabled"?

  1. Enable Network Watcher in every region you use with 'az network watcher configure --resource-group NetworkWatcherRG --locations <region> --enabled true', which creates the instance in the named resource group (the group must already exist). The instance name is set automatically: '{region}-watcher' when created via the CLI, for example 'eastus-watcher'. List your in-use regions first so you cover each one, not just the subscription default.
  2. Assign the built-in policy so new regions self-provision: pid=$(az policy definition list --query "[?displayName=='Network Watcher should be enabled'].name" -o tsv); az policy assignment create --name nw-enabled --policy "$pid" --scope /subscriptions/<sub-id>.
  3. Bake it into your network landing zone module (Bicep 'Microsoft.Network/networkWatchers@2023-09-01' deployed per region, or the equivalent Terraform 'azurerm_network_watcher'), then layer NSG flow logs and traffic analytics on top so the region is genuinely observable, not merely compliant.

Remediation script · bash

# Turn on the security-relevant App Service logs and send them to a workspace.
WS=$(az monitor log-analytics workspace show \
  -g central-logging -n estate-logs --query id -o tsv)

for id in $(az webapp list --query "[].id" -o tsv); do
  has=$(az monitor diagnostic-settings list --resource "$id" \
        --query "length(value)" -o tsv)
  if [ "$has" = "0" ]; then
    az monitor diagnostic-settings create \
      --name to-log-analytics \
      --resource "$id" \
      --workspace "$WS" \
      --logs '[{"category":"AppServiceHTTPLogs","enabled":true},
               {"category":"AppServiceAuditLogs","enabled":true},
               {"category":"AppServiceConsoleLogs","enabled":true}]'
    echo "$(basename "$id"): diagnostic logging enabled to estate-logs"
  fi
done

# Ratchet it shut: built-in policy adds the setting to any new App Service.
az policy assignment create \
  --name deploy-appservice-diag \
  --policy 0c6cd767-1a1d-484b-a897-68e398c03aeb \
  --location uksouth \
  --mi-system-assigned \
  --scope "/subscriptions/00000000-0000-0000-0000-000000000000"

Full walkthrough (console steps, edge cases and verification) in the lesson Turn on diagnostic logging for Azure resources.

Is "Network Watcher should be enabled" a false positive?

A region you provision resources in but deliberately keep free of virtual networks, for example one used only for storage, a global service endpoint or a paired disaster-recovery target with no active networking, does not need its own Network Watcher and can be excepted. Likewise, a sandbox subscription that is torn down weekly gains little from per-region provisioning. Document the exemption in your policy exclusions so a reviewer recognises the region was assessed and consciously left out, rather than simply missed.