(Enable if required) Subnets should be associated with a network security group

What does the recommendation "(Enable if required) Subnets should be associated with a network security group" check?

Audits each subnet in a virtual network and flags any that has no network security group (NSG) bound to it. The check is presence-only: it looks at the subnet-level association and nothing else. It does not inspect the actual allow and deny rules inside an attached NSG, so an associated but wide-open NSG still passes, and it does not recognise NSGs attached directly to a network interface, so a subnet protected solely at the NIC level still flags. Microsoft excludes the reserved GatewaySubnet, AzureFirewallSubnet and AzureBastionSubnet, where a subnet NSG is unsupported or managed by the service, so those never count as findings.

Why does "(Enable if required) Subnets should be associated with a network security group" matter?

A subnet with no NSG inherits Azure's default rules, which permit all traffic between subnets in the same virtual network and allow outbound access to the internet. That gives an attacker who lands on one workload an open lateral path to every other host on the subnet and a clear route to exfiltrate data. An NSG is the cheapest place to draw a segmentation boundary, which is exactly what MCSB NS-1 asks you to establish, so an unassociated subnet usually signals that east-west and egress filtering was never put in place. The business consequence is a wider blast radius: one compromised virtual machine becomes a foothold into the whole tier rather than a contained incident, and an auditor reviewing your network controls will read the gap as missing segmentation across the environment.

How do I fix "(Enable if required) Subnets should be associated with a network security group"?

1. Associate an existing or new NSG with the subnet. In the portal, open the virtual network, select the subnet and set Network security group. With the CLI: az network vnet subnet update --resource-group <rg> --vnet-name <vnet> --name <subnet> --network-security-group <nsg-name-or-id>.
2. In Bicep or ARM, set the subnet's networkSecurityGroup.id property to the NSG resource ID so the association is declared in code and cannot drift, then tighten the NSG's security rules to deny by default and allow only required flows.
3. To enforce this across the estate, assign the built-in policy by its display name rather than a hardcoded GUID: pid=$(az policy definition list --query "[?displayName=='Subnets should be associated with a Network Security Group'].name" -o tsv); az policy assignment create --name require-subnet-nsg --policy "$pid" --scope <scope>.

# 1. Close the highest-impact exposure first: delete any rule that
#    allows a management port from the whole internet.
for rule in $(az network nsg rule list -g prod-rg --nsg-name prod-nsg \
    --query "[?access=='Allow' && (sourceAddressPrefix=='*' || sourceAddressPrefix=='Internet') && (destinationPortRange=='3389' || destinationPortRange=='22')].name" -o tsv); do
  az network nsg rule delete -g prod-rg --nsg-name prod-nsg -n "$rule"
  echo "$rule: open management-port rule removed"
done

# 2. Add an explicit deny on the management ports as a backstop.
az network nsg rule create -g prod-rg --nsg-name prod-nsg \
  --name deny-mgmt-ports --priority 4000 --access Deny --direction Inbound \
  --protocol Tcp --source-address-prefixes Internet \
  --destination-port-ranges 22 3389

# 3. Gate the ports you still need behind just-in-time access.
#    JIT is configured via PowerShell or the portal; request access with the CLI:
az security jit-policy list -o table   # confirm the JIT policy is in place

# 4. Ratchet it shut: audit any VM left without an NSG (Defender built-in policy).
az policy assignment create \
  --name audit-internet-facing-nsg \
  --policy f6de0be7-9a8a-4b8a-b349-43cf02d22f7c \
  --scope "/subscriptions/00000000-0000-0000-0000-000000000000"