Skip to content

MCSB v2 - Network Security

Control ID Implementation ID Control Name Control Type Core Pillar Azure Policy Security Principle Risk to mitigate MITRE ATT&CK Implementation example Criticality NIST SP 800-53 Rev.5 PCI-DSS v4 CIS Controls v8.1 NIST CSF v2.0 ISO 27001:2022 SOC 2
NS-1 nan Establish network segmentation boundaries Parent Apply network isolation All network ports should be restricted on network security groups associated to your virtual machine Network segmentation involves dividing a network into smaller, isolated segments to control and limit the flow of traffic between cloud resources to reduce blast radius. Design your network segmentation to ensure that your virtual network deployment aligns with your enterprise segmentation strategy and different risk levels. Common segmentation strategy includes: Separate Corpnet with Application networksSeparate Application networksSeparate Production and Test Environment networks Refer to Azure Well-Architected Framework to learn more about key strategies for network segmentation: Azure segmentation strategy Without network segmentation boundaries, organizations face unrestricted lateral movement enabling attackers to traverse network infrastructures and compromise high-value assets. Initial Access (TA0001):unauthorized access to networks and exposed services (e.g., T1190 - Exploit Public-Facing Application). An organization needed to secure a multi-tier application with separate production, development, and testing environments while preventing unauthorized lateral movement and external access. Must have SC-7, SC-32, AC-4, CM-7 1.2.1, 1.3.1, 1.4.1 12.1, 12.2, 12.6 PR.IR-01, PR.AC-05 A.8.20, A.8.21 CC6.1, CC6.6
Internet-facing virtual machines should be protected with network security groups
Non-internet-facing virtual machines should be protected with network security groups Flat network exposure:Absence of segmentation enables unrestricted lateral movement, allowing adversaries to compromise high-value assets by traversing a non-partitioned network topology.Privilege escalation pathways:Inadequate boundaries permit unauthorized access vectors, facilitating escalation of user privileges through access to sensitive subnetworks and workloads.Malware propagation:Insufficient segmentation allows rapid spread of malicious code such as ransomware across interconnected nodes, amplifying the attack surface and operational impact.East-west traffic blindness:Unrestricted inter-segment traffic hampers anomaly detection and incident response, reducing visibility into internal threat movements and complicating forensic analysis. Lateral Movement (TA0008):attack pivoting by VNets and non-restricted inter-subnet traffic (e.g., T1021 - Remote Services). Challenge:The organization had a three-tier application (web, application, database) with all resources in a single large network segment, allowing unrestricted communication between all tiers and environments.
Subnets should be associated with a Network Security Group
Exfiltration (TA0010):data exfiltration by non-restricted outbound traffic for unauthorized data transfers to external servers (e.g., T1041 - Exfiltration Over C2 Channel). Command and Control (TA0011):malware propagation by communication with malicious IPs or domains via firewall rules and threat intelligence (e.g., T1071 - Application Layer Protocol). This created significant security risks including potential lateral movement between production and non-production, unrestricted internet access from database servers, and inability to isolate high-risk workloads.
Solution approach: VNet segmentation by environment:Created separate virtual networks for production (10.0.0.0/16), development (10.1.0.0/16), and testing (10.2.0.0/16) environments, establishing network isolation boundaries that prevent cross-environment access and limit blast radius of potential breaches.Subnet segmentation by tier:Within the production VNet, created distinct non-overlapping subnets for each application tier - web tier (10.0.1.0/24), application tier (10.0.2.0/24), and database tier (10.0.3.0/24) - enabling granular traffic control between tiers.NSG rules for north-south traffic control:Configured NSG rules to deny all inbound traffic from internet (0.0.0.0/0) to internal subnets and restrict outbound internet access to only trusted destinations, with specific rules allowing only necessary external connections for web tier while blocking all internet access from database tier.NSG rules for east-west traffic control:Implemented deny-by-default policies with explicit allow rules between tiers - web tier allowed outbound to application tier on required ports only, application tier allowed outbound to database tier on port 1433 (SQL) only, and database tier denied all other inbound traffic except from application tier subnet.Remote management access:Restricted remote management ports (RDP 3389/TCP, SSH 22/TCP) to accept connections only from trusted bastion host subnet (10.0.0.0/26), eliminating direct internet access to management interfaces.
NS-1 NS-1.1 Create segmentation using VNet and subnets Child Apply network isolation All network ports should be restricted on network security groups associated to your virtual machine Network segmentation involves dividing a network into smaller, isolated segments to control and limit the flow of traffic between cloud resources to reduce blast radius. Design your network segmentation to ensure that your virtual network deployment aligns with your enterprise segmentation strategy and different risk levels. Common segmentation strategy includes: Separate Corpnet with Application networksSeparate Application networksSeparate Production and Test Environment networks Refer to Azure Well-Architected Framework to learn more about key strategies for network segmentation: Azure segmentation strategy nan nan Virtual network isolation establishes fundamental security boundaries within cloud environments, enabling organizations to separate workloads by trust level, organizational unit, or application grouping. This approach prevents unrestricted lateral movement and reduces blast radius when breaches occur, aligning network architecture with enterprise segmentation strategies and zero-trust principles. Implement virtual network segmentation by creating isolated network boundaries and subdivisions: Design VNet topology based on segmentation strategy:Createvirtual networksaligned with trust zones, organizational units, or application groupings defined in your enterprise segmentation strategy, ensuring each VNet represents a distinct security boundary.Isolate high-risk workloads:Identify workloads requiring strict isolation (e.g., production databases, payment processing systems) and deploy them into dedicated, isolated VNets to minimize exposure and prevent cross-contamination.Create subnets for granular segmentation:Within each VNet,create distinct non-overlapping subnetsto further segment the network based on application tiers (e.g., web tier, application tier, database tier) or functional requirements, enabling more precise traffic control and micro-segmentation. nan nan nan nan nan nan nan
Internet-facing virtual machines should be protected with network security groups
Non-internet-facing virtual machines should be protected with network security groups
Subnets should be associated with a Network Security Group
NS-1 NS-1.2 Restrict network traffic using NSG Child Apply network isolation All network ports should be restricted on network security groups associated to your virtual machine Network segmentation involves dividing a network into smaller, isolated segments to control and limit the flow of traffic between cloud resources to reduce blast radius. Design your network segmentation to ensure that your virtual network deployment aligns with your enterprise segmentation strategy and different risk levels. Common segmentation strategy includes: Separate Corpnet with Application networksSeparate Application networksSeparate Production and Test Environment networks Refer to Azure Well-Architected Framework to learn more about key strategies for network segmentation: Azure segmentation strategy nan nan Network security groups enforce traffic filtering at the subnet and network interface level, enabling precise control over communication flows between network segments and external networks. By implementing deny-by-default policies with explicit allow rules, organizations ensure only authorized traffic traverses network boundaries, preventing unauthorized access and reducing attack surface. Implement network traffic restriction using NSG rules: Identify communication requirements:Analyze resources in each VNet to understand their north-south (external) and east-west (internal) traffic communication needs, documenting required ports, protocols, source addresses, and destination addresses for legitimate business functions.Define explicit allow and deny rules:For well-defined applications (e.g., three-tier architectures), use the "deny by default, permit by exception" approach tocreate NSG rulesbased on port, protocol, source IP address, and destination IP address, explicitly allowing only necessary traffic while denying all other communications.Use application security groups for complex scenarios:When many applications and endpoints interact, simplify NSG rule management by using application security groups (ASGs) to group resources logically (e.g., web servers, database servers), then define NSG rules based on these groups rather than explicit IP addresses, improving maintainability and reducing configuration complexity.Monitor and optimize with flow logs:Enablevirtual networ nan nan nan nan nan nan nan
Internet-facing virtual machines should be protected with network security groups
Non-internet-facing virtual machines should be protected with network security groups
Subnets should be associated with a Network Security Group
NS-2 nan Secure cloud native services with network controls Parent Secure network boundaries API Management services should use a virtual network Use service native features to secure network access to the resources to avoid and reduce the exposure of the resources to the untrusted network. These features include: Establish private access points for resources to avoid the exposure of network traffic going through the public network.Deploy the resource into virtual networks where you can restrict the VNet to establish a private access point for the service.Configure service native firewalls to restrict the inbound traffic or disable the public network access. Note: In addition to the basic network access control and traffic filtering, you should also use threat detection capabilities to monitor services such as DNS (NS-10) to detect the possible data exfiltration. Threat actors exploit publicly exposed cloud services to conduct data exfiltration, application-layer attacks, and traffic interception. Initial Access (TA0001):unauthorized access by public internet exposure of cloud services (e.g., cloud storage services, database services), exploit targeting public endpoints (e.g., T1190 - Exploit Public-Facing Application). An organization needed to secure backend database and storage resources while enabling access from application services without exposing resources to the public internet. Must have SC-7(4), SC-7(5), AC-4(21) 1.3.1, 1.3.2, 1.4.2 12.4, 12.7 PR.AC-05, PR.DS-05 A.8.20, A.8.22 CC6.1, CC6.6
API Management should disable public network access to the service configuration endpoints
App Configuration should disable public network access Data exfiltration through public endpoints:Attackers exploit publicly accessible storage accounts, databases, or APIs to exfiltrate sensitive data by establishing unauthorized connections to exposed endpoints, bypassing network segmentation controls and enabling large-scale data theft.Application-layer attacks against public endpoints:Distributed Denial of Service (DDoS) attacks, SQL injection, and other application exploits target publicly exposed web services, APIs, and databases, overwhelming resources or exploiting vulnerabilities to cause service disruption or data compromise.Man-in-the-middle attacks:Attackers intercept traffic flowing over public networks to publicly exposed services, capturing credentials, session tokens, or sensitive data transmitted without adequate encryption or private connectivity, enabling account takeover or data theft. Exfiltration (TA0010):data exfiltration by routing traffic over private virtual network connections, reducing the risk of data leakage to external servers (e.g., T1041 - Exfiltration Over C2 Channel). Challenge:The organization had Azure SQL Database and Azure Storage accounts with default public endpoints, making them accessible from the internet and creating significant data exfiltration risks.
App Configuration should use a SKU that supports private link
App Configuration should use private link Lateral Movement (TA0008):attacker pivoting services within virtual networks, unauthorized access between cloud resources (e.g., T1021 - Remote Services). Application services were deployed with public IPs and lacked VNet integration, preventing private network-based access controls. Service-level firewalls were not configured, allowing unrestricted access from any source once authentication succeeded.
App Service Environment apps should not be reachable over public internet
App Service app slots should disable public network access Solution approach: Private Link endpoints for PaaS services:Deployedprivate endpointsfor Azure SQL Database (assigned private IP 10.0.2.4) and Azure Storage account (assigned private IP 10.0.2.5) within a dedicated private endpoint subnet (10.0.2.0/24), establishing private connectivity that routes traffic over the Azure backbone network without internet exposure.Private DNS zones for name resolution:CreatedAzure Private DNS zonesto override public DNS resolution, ensuring application FQDNs (e.g., mysqldb.database.windows.net, mystorageaccount.blob.core.windows.net) resolve to private IPs within the VNet rather than public endpoints, maintaining seamless connectivity for applications using FQDN-based access.VNet integration for application services:ConfiguredVNet integrationfor Azure App Service, deploying the application into an application subnet (10.0.1.0/24) to enable direct communication with private endpoints without requiring public IP addresses or internet routing.Service native firewalls:Enabledservice-level firewallson Azure Storage to restrict access to specific VNet subnets (application subnet 10.0.1.0/24) and trusted Microsoft services, while completely disabling public network access at the service level for Azure SQL Database to enforce private-only connectivity.NSG rules for defense-in-depth:Applied NSG rules to the application subnet allowing outbound traffic only to the private endpoint subnet (10.0.2.0/24) on required ports (443 for Storage, 1433 for SQL), implementing least-privilege access control that complements service-level protections.
App Service apps should disable public network access
App Service apps should use a SKU that supports private link
App Service apps should use private link
Application Insights components should block log ingestion and querying from public networks
Authorized IP ranges should be defined on Kubernetes Services
Automation accounts should disable public network access
Azure AI Search service should use a SKU that supports private link
Azure AI Search services should disable public network access
Azure AI Services resources should restrict network access
Azure AI Services resources should use Azure Private Link
Azure API for FHIR should use private link
Azure Arc Private Link Scopes should be configured with a private endpoint
Azure Arc Private Link Scopes should disable public network access
Azure Arc-enabled kubernetes clusters should be configured with an Azure Arc Private Link Scope
Azure Arc-enabled servers should be configured with an Azure Arc Private Link Scope
Azure Attestation providers should disable public network access
Azure Cache for Redis Enterprise should use private link
Azure Cache for Redis should disable public network access
Azure Cache for Redis should use private link
Azure Cosmos DB accounts should have firewall rules
Azure Cosmos DB should disable public network access
Azure Data Explorer cluster should use private link
Azure Data Explorer should use a SKU that supports private link
Azure Data Factory should use private link
Azure Databricks Clusters should disable public IP
Azure Databricks Workspaces should be in a virtual network
Azure Databricks Workspaces should disable public network access
Azure Databricks Workspaces should use private link
Azure Databricks workspaces should be Premium SKU that supports features like private link, customer-managed key for encryption
Azure Device Update for IoT Hub accounts should use private link
Azure Event Grid domains should disable public network access
Azure Event Grid domains should use private link
Azure Event Grid namespace MQTT broker should use private link
Azure Event Grid namespace topic broker should use private link
Azure Event Grid namespaces should disable public network access
Azure Event Grid topics should disable public network access
Azure Event Grid topics should use private link
Azure File Sync should use private link
Azure Front Door profiles should use Premium tier that supports managed WAF rules and private link
Azure HDInsight should use private link
Azure Health Data Services de-identification service should disable public network access
Azure Health Data Services de-identification service should use private link
Azure Health Data Services workspace should use private link
Azure Key Vault should disable public network access
Azure Key Vault should have firewall enabled or public network access disabled
Azure Key Vaults should use private link
Azure Machine Learning Computes should be in a virtual network
Azure Machine Learning Workspaces should disable public network access
Azure Machine Learning and Ai Studio should use Allow Only Approved Outbound Managed Vnet mode
Azure Machine Learning workspaces should use private link
Azure Managed Grafana workspaces should disable public network access
Azure Managed Grafana workspaces should use private link
Azure Monitor Private Link Scope should block access to non private link resources
Azure Monitor Private Link Scope should use private link
Azure Purview accounts should use private link
Azure SQL Managed Instances should disable public network access
Azure Service Bus namespaces should use private link
Azure SignalR Service should disable public network access
Azure SignalR Service should use a Private Link enabled SKU
Azure SignalR Service should use private link
Azure Spring Cloud should use network injection
Azure Synapse workspaces should disable public network access
Azure Synapse workspaces should use private link
Azure Virtual Desktop hostpools should disable public network access
Azure Virtual Desktop hostpools should disable public network access only on session hosts
Azure Virtual Desktop service should use private link
Azure Virtual Desktop workspaces should disable public network access
Azure Web PubSub Service should disable public network access
Azure Web PubSub Service should use a SKU that supports private link
Azure Web PubSub Service should use private link
Bot Service should have public network access disabled
BotService resources should use private link
Container Apps environment should disable public network access
Container registries should have SKUs that support Private Links
Container registries should not allow unrestricted network access
Container registries should use private link
CosmosDB accounts should use private link
Disk access resources should use private link
ElasticSan should disable public network access
Event Hub Namespaces should disable public network access
Event Hub namespaces should use private link
Function app slots should disable public network access
Function apps should disable public network access
IoT Central should use private link
IoT Hub device provisioning service instances should disable public network access
IoT Hub device provisioning service instances should use private link
Log Analytics workspaces should block log ingestion and querying from public networks
Managed disks should disable public network access
Private endpoint connections on Azure SQL Database should be enabled
Private endpoint should be enabled for MariaDB servers
Private endpoint should be enabled for MySQL servers
Private endpoint should be enabled for PostgreSQL servers
Public network access for Azure Device Update for IoT Hub accounts should be disabled
Public network access on Azure Data Explorer should be disabled
Public network access on Azure Data Factory should be disabled
Public network access on Azure IoT Hub should be disabled
Public network access on Azure SQL Database should be disabled
Public network access should be disabled for Azure File Sync
Public network access should be disabled for Batch accounts
Public network access should be disabled for Container registries
Public network access should be disabled for IoT Central
Public network access should be disabled for MariaDB servers
Public network access should be disabled for MariaDB servers
Public network access should be disabled for MySQL flexible servers
Public network access should be disabled for MySQL servers
Public network access should be disabled for PostgreSQL flexible servers
Public network access should be disabled for PostgreSQL servers
Service Bus Namespaces should disable public network access
Storage account public access should be disallowed
Storage accounts should disable public network access
Storage accounts should restrict network access
Storage accounts should restrict network access using virtual network rules
Storage accounts should restrict network access using virtual network rules (excluding storage accounts created by Databricks)
Storage accounts should use private link
Storage accounts should use private link (excluding storage accounts created by Databricks)
VM Image Builder templates should use private link
[Preview]: Azure Key Vault Managed HSM should disable public network access
[Preview]: Azure Key Vault Managed HSM should use private link
[Preview]: Azure Recovery Services vaults should use private link for backup
[Preview]: Recovery Services vaults should use private link
NS-2 NS-2.1 Use Private Link for service connection Child Secure network boundaries API Management services should use a virtual network Use service native features to secure network access to the resources to avoid and reduce the exposure of the resources to the untrusted network. These features include: Establish private access points for resources to avoid the exposure of network traffic going through the public network.Deploy the resource into virtual networks where you can restrict the VNet to establish a private access point for the service.Configure service native firewalls to restrict the inbound traffic or disable the public network access. Note: In addition to the basic network access control and traffic filtering, you should also use threat detection capabilities to monitor services such as DNS (NS-10) to detect the possible data exfiltration. nan nan Private connectivity eliminates public internet exposure for cloud services by establishing direct network paths within your virtual infrastructure. Private Link creates private endpoints with dedicated IP addresses inside your virtual networks, ensuring traffic to cloud services never traverses the public internet while maintaining DNS-based access patterns. This approach significantly reduces attack surface and prevents data exfiltration through publicly accessible endpoints. Implement private connectivity for cloud services through these steps: Deploy private endpoints for supported services:Createprivate endpointswithin your virtual network for Azure resourcessupporting Private Link(e.g., Azure Storage, Azure SQL Database, Azure Key Vault), establishing private IP addresses (e.g., 10.0.2.4) accessible only from your VNet.Configure private DNS zones:Create Azure Private DNS zones to override public DNS resolution, ensuring fully qualified domain names (FQDNs) like mystorageaccount1.blob.core.windows.net resolve to private IP addresses within your VNet rather than public endpoints, maintaining seamless connectivity for applications using FQDN-based access.Disable public access:Configure service-level settings to disable public network access entirely once private endpoints are deployed, ensuring all traffic flows exclusively through private connectivity without fallback to public endpoints. Note:Certain Azure services may also allow private communication through theservice nan nan nan nan nan nan nan
API Management should disable public network access to the service configuration endpoints
App Configuration should disable public network access
App Configuration should use a SKU that supports private link
App Configuration should use private link
App Service Environment apps should not be reachable over public internet
App Service app slots should disable public network access
App Service apps should disable public network access
App Service apps should use a SKU that supports private link
App Service apps should use private link
Application Insights components should block log ingestion and querying from public networks
Authorized IP ranges should be defined on Kubernetes Services
Automation accounts should disable public network access
Azure AI Search service should use a SKU that supports private link
Azure AI Search services should disable public network access
Azure AI Services resources should restrict network access
Azure AI Services resources should use Azure Private Link
Azure API for FHIR should use private link
Azure Arc Private Link Scopes should be configured with a private endpoint
Azure Arc Private Link Scopes should disable public network access
Azure Arc-enabled kubernetes clusters should be configured with an Azure Arc Private Link Scope
Azure Arc-enabled servers should be configured with an Azure Arc Private Link Scope
Azure Attestation providers should disable public network access
Azure Cache for Redis Enterprise should use private link
Azure Cache for Redis should disable public network access
Azure Cache for Redis should use private link
Azure Cosmos DB accounts should have firewall rules
Azure Cosmos DB should disable public network access
Azure Data Explorer cluster should use private link
Azure Data Explorer should use a SKU that supports private link
Azure Data Factory should use private link
Azure Databricks Clusters should disable public IP
Azure Databricks Workspaces should be in a virtual network
Azure Databricks Workspaces should disable public network access
Azure Databricks Workspaces should use private link
Azure Databricks workspaces should be Premium SKU that supports features like private link, customer-managed key for encryption
Azure Device Update for IoT Hub accounts should use private link
Azure Event Grid domains should disable public network access
Azure Event Grid domains should use private link
Azure Event Grid namespace MQTT broker should use private link
Azure Event Grid namespace topic broker should use private link
Azure Event Grid namespaces should disable public network access
Azure Event Grid topics should disable public network access
Azure Event Grid topics should use private link
Azure File Sync should use private link
Azure Front Door profiles should use Premium tier that supports managed WAF rules and private link
Azure HDInsight should use private link
Azure Health Data Services de-identification service should disable public network access
Azure Health Data Services de-identification service should use private link
Azure Health Data Services workspace should use private link
Azure Key Vault should disable public network access
Azure Key Vault should have firewall enabled or public network access disabled
Azure Key Vaults should use private link
Azure Machine Learning Computes should be in a virtual network
Azure Machine Learning Workspaces should disable public network access
Azure Machine Learning and Ai Studio should use Allow Only Approved Outbound Managed Vnet mode
Azure Machine Learning workspaces should use private link
Azure Managed Grafana workspaces should disable public network access
Azure Managed Grafana workspaces should use private link
Azure Monitor Private Link Scope should block access to non private link resources
Azure Monitor Private Link Scope should use private link
Azure Purview accounts should use private link
Azure SQL Managed Instances should disable public network access
Azure Service Bus namespaces should use private link
Azure SignalR Service should disable public network access
Azure SignalR Service should use a Private Link enabled SKU
Azure SignalR Service should use private link
Azure Spring Cloud should use network injection
Azure Synapse workspaces should disable public network access
Azure Synapse workspaces should use private link
Azure Virtual Desktop hostpools should disable public network access
Azure Virtual Desktop hostpools should disable public network access only on session hosts
Azure Virtual Desktop service should use private link
Azure Virtual Desktop workspaces should disable public network access
Azure Web PubSub Service should disable public network access
Azure Web PubSub Service should use a SKU that supports private link
Azure Web PubSub Service should use private link
Bot Service should have public network access disabled
BotService resources should use private link
Container Apps environment should disable public network access
Container registries should have SKUs that support Private Links
Container registries should not allow unrestricted network access
Container registries should use private link
CosmosDB accounts should use private link
Disk access resources should use private link
ElasticSan should disable public network access
Event Hub Namespaces should disable public network access
Event Hub namespaces should use private link
Function app slots should disable public network access
Function apps should disable public network access
IoT Central should use private link
IoT Hub device provisioning service instances should disable public network access
IoT Hub device provisioning service instances should use private link
Log Analytics workspaces should block log ingestion and querying from public networks
Managed disks should disable public network access
Private endpoint connections on Azure SQL Database should be enabled
Private endpoint should be enabled for MariaDB servers
Private endpoint should be enabled for MySQL servers
Private endpoint should be enabled for PostgreSQL servers
Public network access for Azure Device Update for IoT Hub accounts should be disabled
Public network access on Azure Data Explorer should be disabled
Public network access on Azure Data Factory should be disabled
Public network access on Azure IoT Hub should be disabled
Public network access on Azure SQL Database should be disabled
Public network access should be disabled for Azure File Sync
Public network access should be disabled for Batch accounts
Public network access should be disabled for Container registries
Public network access should be disabled for IoT Central
Public network access should be disabled for MariaDB servers
Public network access should be disabled for MariaDB servers
Public network access should be disabled for MySQL flexible servers
Public network access should be disabled for MySQL servers
Public network access should be disabled for PostgreSQL flexible servers
Public network access should be disabled for PostgreSQL servers
Service Bus Namespaces should disable public network access
Storage account public access should be disallowed
Storage accounts should disable public network access
Storage accounts should restrict network access
Storage accounts should restrict network access using virtual network rules
Storage accounts should restrict network access using virtual network rules (excluding storage accounts created by Databricks)
Storage accounts should use private link
Storage accounts should use private link (excluding storage accounts created by Databricks)
VM Image Builder templates should use private link
[Preview]: Azure Key Vault Managed HSM should disable public network access
[Preview]: Azure Key Vault Managed HSM should use private link
[Preview]: Azure Recovery Services vaults should use private link for backup
[Preview]: Recovery Services vaults should use private link
NS-2 NS-2.2 Deploy service into VNet Child Secure network boundaries API Management services should use a virtual network Use service native features to secure network access to the resources to avoid and reduce the exposure of the resources to the untrusted network. These features include: Establish private access points for resources to avoid the exposure of network traffic going through the public network.Deploy the resource into virtual networks where you can restrict the VNet to establish a private access point for the service.Configure service native firewalls to restrict the inbound traffic or disable the public network access. Note: In addition to the basic network access control and traffic filtering, you should also use threat detection capabilities to monitor services such as DNS (NS-10) to detect the possible data exfiltration. nan nan Virtual network integration enables cloud services to operate within private network boundaries, establishing direct connectivity to VNet-hosted resources without public internet exposure. By deploying services into virtual networks, organizations gain granular control over network traffic through security groups and route tables while maintaining service isolation from external threats. Deploy services with VNet integration where supported: Deploy services into virtual networks:For services supporting VNet integration (e.g., Azure App Service, Azure Functions, Azure Container Instances), configure deployment into new or existing virtual networks, specifying appropriate subnets aligned with your segmentation strategy and enabling private communication with other VNet resources.Configure network security controls:Apply network security group (NSG) rules to the service's subnet to restrict inbound and outbound traffic, implementing least-privilege access by allowing only necessary communication to specific destinations (e.g., database subnets, storage endpoints) while denying all other traffic. nan nan nan nan nan nan nan
API Management should disable public network access to the service configuration endpoints
App Configuration should disable public network access
App Configuration should use a SKU that supports private link
App Configuration should use private link
App Service Environment apps should not be reachable over public internet
App Service app slots should disable public network access
App Service apps should disable public network access
App Service apps should use a SKU that supports private link
App Service apps should use private link
Application Insights components should block log ingestion and querying from public networks
Authorized IP ranges should be defined on Kubernetes Services
Automation accounts should disable public network access
Azure AI Search service should use a SKU that supports private link
Azure AI Search services should disable public network access
Azure AI Services resources should restrict network access
Azure AI Services resources should use Azure Private Link
Azure API for FHIR should use private link
Azure Arc Private Link Scopes should be configured with a private endpoint
Azure Arc Private Link Scopes should disable public network access
Azure Arc-enabled kubernetes clusters should be configured with an Azure Arc Private Link Scope
Azure Arc-enabled servers should be configured with an Azure Arc Private Link Scope
Azure Attestation providers should disable public network access
Azure Cache for Redis Enterprise should use private link
Azure Cache for Redis should disable public network access
Azure Cache for Redis should use private link
Azure Cosmos DB accounts should have firewall rules
Azure Cosmos DB should disable public network access
Azure Data Explorer cluster should use private link
Azure Data Explorer should use a SKU that supports private link
Azure Data Factory should use private link
Azure Databricks Clusters should disable public IP
Azure Databricks Workspaces should be in a virtual network
Azure Databricks Workspaces should disable public network access
Azure Databricks Workspaces should use private link
Azure Databricks workspaces should be Premium SKU that supports features like private link, customer-managed key for encryption
Azure Device Update for IoT Hub accounts should use private link
Azure Event Grid domains should disable public network access
Azure Event Grid domains should use private link
Azure Event Grid namespace MQTT broker should use private link
Azure Event Grid namespace topic broker should use private link
Azure Event Grid namespaces should disable public network access
Azure Event Grid topics should disable public network access
Azure Event Grid topics should use private link
Azure File Sync should use private link
Azure Front Door profiles should use Premium tier that supports managed WAF rules and private link
Azure HDInsight should use private link
Azure Health Data Services de-identification service should disable public network access
Azure Health Data Services de-identification service should use private link
Azure Health Data Services workspace should use private link
Azure Key Vault should disable public network access
Azure Key Vault should have firewall enabled or public network access disabled
Azure Key Vaults should use private link
Azure Machine Learning Computes should be in a virtual network
Azure Machine Learning Workspaces should disable public network access
Azure Machine Learning and Ai Studio should use Allow Only Approved Outbound Managed Vnet mode
Azure Machine Learning workspaces should use private link
Azure Managed Grafana workspaces should disable public network access
Azure Managed Grafana workspaces should use private link
Azure Monitor Private Link Scope should block access to non private link resources
Azure Monitor Private Link Scope should use private link
Azure Purview accounts should use private link
Azure SQL Managed Instances should disable public network access
Azure Service Bus namespaces should use private link
Azure SignalR Service should disable public network access
Azure SignalR Service should use a Private Link enabled SKU
Azure SignalR Service should use private link
Azure Spring Cloud should use network injection
Azure Synapse workspaces should disable public network access
Azure Synapse workspaces should use private link
Azure Virtual Desktop hostpools should disable public network access
Azure Virtual Desktop hostpools should disable public network access only on session hosts
Azure Virtual Desktop service should use private link
Azure Virtual Desktop workspaces should disable public network access
Azure Web PubSub Service should disable public network access
Azure Web PubSub Service should use a SKU that supports private link
Azure Web PubSub Service should use private link
Bot Service should have public network access disabled
BotService resources should use private link
Container Apps environment should disable public network access
Container registries should have SKUs that support Private Links
Container registries should not allow unrestricted network access
Container registries should use private link
CosmosDB accounts should use private link
Disk access resources should use private link
ElasticSan should disable public network access
Event Hub Namespaces should disable public network access
Event Hub namespaces should use private link
Function app slots should disable public network access
Function apps should disable public network access
IoT Central should use private link
IoT Hub device provisioning service instances should disable public network access
IoT Hub device provisioning service instances should use private link
Log Analytics workspaces should block log ingestion and querying from public networks
Managed disks should disable public network access
Private endpoint connections on Azure SQL Database should be enabled
Private endpoint should be enabled for MariaDB servers
Private endpoint should be enabled for MySQL servers
Private endpoint should be enabled for PostgreSQL servers
Public network access for Azure Device Update for IoT Hub accounts should be disabled
Public network access on Azure Data Explorer should be disabled
Public network access on Azure Data Factory should be disabled
Public network access on Azure IoT Hub should be disabled
Public network access on Azure SQL Database should be disabled
Public network access should be disabled for Azure File Sync
Public network access should be disabled for Batch accounts
Public network access should be disabled for Container registries
Public network access should be disabled for IoT Central
Public network access should be disabled for MariaDB servers
Public network access should be disabled for MariaDB servers
Public network access should be disabled for MySQL flexible servers
Public network access should be disabled for MySQL servers
Public network access should be disabled for PostgreSQL flexible servers
Public network access should be disabled for PostgreSQL servers
Service Bus Namespaces should disable public network access
Storage account public access should be disallowed
Storage accounts should disable public network access
Storage accounts should restrict network access
Storage accounts should restrict network access using virtual network rules
Storage accounts should restrict network access using virtual network rules (excluding storage accounts created by Databricks)
Storage accounts should use private link
Storage accounts should use private link (excluding storage accounts created by Databricks)
VM Image Builder templates should use private link
[Preview]: Azure Key Vault Managed HSM should disable public network access
[Preview]: Azure Key Vault Managed HSM should use private link
[Preview]: Azure Recovery Services vaults should use private link for backup
[Preview]: Recovery Services vaults should use private link
NS-2 NS-2.3 Configure service native firewall Child Secure network boundaries API Management services should use a virtual network Use service native features to secure network access to the resources to avoid and reduce the exposure of the resources to the untrusted network. These features include: Establish private access points for resources to avoid the exposure of network traffic going through the public network.Deploy the resource into virtual networks where you can restrict the VNet to establish a private access point for the service.Configure service native firewalls to restrict the inbound traffic or disable the public network access. Note: In addition to the basic network access control and traffic filtering, you should also use threat detection capabilities to monitor services such as DNS (NS-10) to detect the possible data exfiltration. nan nan Service-level firewalls provide defense-in-depth protection by restricting network access at the resource level, complementing network-layer controls with application-specific security boundaries. These native firewall capabilities enable organizations to limit exposure to specific IP ranges or virtual networks while completely disabling public access when appropriate, reducing attack surface without requiring complex network topology changes. Configure service firewalls to restrict access: Enable service firewall features:For services supporting native firewalls (e.g., Azure Storage, Azure SQL Database, Azure Key Vault), enable firewall functionality either during resource creation or on existing resources to control which networks can access the service.Define IP-based or VNet-based rules:Configure firewall rules to allow access only from specific public IP ranges (e.g., corporate office networks) or specific Azure virtual network subnets, implementing least-privilege access by denying all other sources.Disable public access when possible:When services require access only from private networks, use the toggle option to completely disable public network access, ensuring the service is unreachable from the internet regardless of IP-based rules. nan nan nan nan nan nan nan
API Management should disable public network access to the service configuration endpoints
App Configuration should disable public network access
App Configuration should use a SKU that supports private link
App Configuration should use private link
App Service Environment apps should not be reachable over public internet
App Service app slots should disable public network access
App Service apps should disable public network access
App Service apps should use a SKU that supports private link
App Service apps should use private link
Application Insights components should block log ingestion and querying from public networks
Authorized IP ranges should be defined on Kubernetes Services
Automation accounts should disable public network access
Azure AI Search service should use a SKU that supports private link
Azure AI Search services should disable public network access
Azure AI Services resources should restrict network access
Azure AI Services resources should use Azure Private Link
Azure API for FHIR should use private link
Azure Arc Private Link Scopes should be configured with a private endpoint
Azure Arc Private Link Scopes should disable public network access
Azure Arc-enabled kubernetes clusters should be configured with an Azure Arc Private Link Scope
Azure Arc-enabled servers should be configured with an Azure Arc Private Link Scope
Azure Attestation providers should disable public network access
Azure Cache for Redis Enterprise should use private link
Azure Cache for Redis should disable public network access
Azure Cache for Redis should use private link
Azure Cosmos DB accounts should have firewall rules
Azure Cosmos DB should disable public network access
Azure Data Explorer cluster should use private link
Azure Data Explorer should use a SKU that supports private link
Azure Data Factory should use private link
Azure Databricks Clusters should disable public IP
Azure Databricks Workspaces should be in a virtual network
Azure Databricks Workspaces should disable public network access
Azure Databricks Workspaces should use private link
Azure Databricks workspaces should be Premium SKU that supports features like private link, customer-managed key for encryption
Azure Device Update for IoT Hub accounts should use private link
Azure Event Grid domains should disable public network access
Azure Event Grid domains should use private link
Azure Event Grid namespace MQTT broker should use private link
Azure Event Grid namespace topic broker should use private link
Azure Event Grid namespaces should disable public network access
Azure Event Grid topics should disable public network access
Azure Event Grid topics should use private link
Azure File Sync should use private link
Azure Front Door profiles should use Premium tier that supports managed WAF rules and private link
Azure HDInsight should use private link
Azure Health Data Services de-identification service should disable public network access
Azure Health Data Services de-identification service should use private link
Azure Health Data Services workspace should use private link
Azure Key Vault should disable public network access
Azure Key Vault should have firewall enabled or public network access disabled
Azure Key Vaults should use private link
Azure Machine Learning Computes should be in a virtual network
Azure Machine Learning Workspaces should disable public network access
Azure Machine Learning and Ai Studio should use Allow Only Approved Outbound Managed Vnet mode
Azure Machine Learning workspaces should use private link
Azure Managed Grafana workspaces should disable public network access
Azure Managed Grafana workspaces should use private link
Azure Monitor Private Link Scope should block access to non private link resources
Azure Monitor Private Link Scope should use private link
Azure Purview accounts should use private link
Azure SQL Managed Instances should disable public network access
Azure Service Bus namespaces should use private link
Azure SignalR Service should disable public network access
Azure SignalR Service should use a Private Link enabled SKU
Azure SignalR Service should use private link
Azure Spring Cloud should use network injection
Azure Synapse workspaces should disable public network access
Azure Synapse workspaces should use private link
Azure Virtual Desktop hostpools should disable public network access
Azure Virtual Desktop hostpools should disable public network access only on session hosts
Azure Virtual Desktop service should use private link
Azure Virtual Desktop workspaces should disable public network access
Azure Web PubSub Service should disable public network access
Azure Web PubSub Service should use a SKU that supports private link
Azure Web PubSub Service should use private link
Bot Service should have public network access disabled
BotService resources should use private link
Container Apps environment should disable public network access
Container registries should have SKUs that support Private Links
Container registries should not allow unrestricted network access
Container registries should use private link
CosmosDB accounts should use private link
Disk access resources should use private link
ElasticSan should disable public network access
Event Hub Namespaces should disable public network access
Event Hub namespaces should use private link
Function app slots should disable public network access
Function apps should disable public network access
IoT Central should use private link
IoT Hub device provisioning service instances should disable public network access
IoT Hub device provisioning service instances should use private link
Log Analytics workspaces should block log ingestion and querying from public networks
Managed disks should disable public network access
Private endpoint connections on Azure SQL Database should be enabled
Private endpoint should be enabled for MariaDB servers
Private endpoint should be enabled for MySQL servers
Private endpoint should be enabled for PostgreSQL servers
Public network access for Azure Device Update for IoT Hub accounts should be disabled
Public network access on Azure Data Explorer should be disabled
Public network access on Azure Data Factory should be disabled
Public network access on Azure IoT Hub should be disabled
Public network access on Azure SQL Database should be disabled
Public network access should be disabled for Azure File Sync
Public network access should be disabled for Batch accounts
Public network access should be disabled for Container registries
Public network access should be disabled for IoT Central
Public network access should be disabled for MariaDB servers
Public network access should be disabled for MariaDB servers
Public network access should be disabled for MySQL flexible servers
Public network access should be disabled for MySQL servers
Public network access should be disabled for PostgreSQL flexible servers
Public network access should be disabled for PostgreSQL servers
Service Bus Namespaces should disable public network access
Storage account public access should be disallowed
Storage accounts should disable public network access
Storage accounts should restrict network access
Storage accounts should restrict network access using virtual network rules
Storage accounts should restrict network access using virtual network rules (excluding storage accounts created by Databricks)
Storage accounts should use private link
Storage accounts should use private link (excluding storage accounts created by Databricks)
VM Image Builder templates should use private link
[Preview]: Azure Key Vault Managed HSM should disable public network access
[Preview]: Azure Key Vault Managed HSM should use private link
[Preview]: Azure Recovery Services vaults should use private link for backup
[Preview]: Recovery Services vaults should use private link
NS-2 NS-2.4 Use Network Security Perimeter for PaaS resource isolation Child Secure network boundaries API Management services should use a virtual network Use service native features to secure network access to the resources to avoid and reduce the exposure of the resources to the untrusted network. These features include: Establish private access points for resources to avoid the exposure of network traffic going through the public network.Deploy the resource into virtual networks where you can restrict the VNet to establish a private access point for the service.Configure service native firewalls to restrict the inbound traffic or disable the public network access. Note: In addition to the basic network access control and traffic filtering, you should also use threat detection capabilities to monitor services such as DNS (NS-10) to detect the possible data exfiltration. nan nan Network Security Perimeter establishes a logical network boundary around multiple PaaS resources, enabling secure service-to-service communication within an explicit trusted perimeter while preventing unauthorized data exfiltration. Unlike per-resource controls, Network Security Perimeter provides a unified security boundary allowing intra-perimeter communication without individual access rules while blocking external access by default. Implement Network Security Perimeter to secure PaaS resources: Create and associate resources:Establish anetwork security perimeterand addsupported PaaS resources(Azure Storage, SQL Database, Key Vault, Event Hubs, Cosmos DB) through resource associations, enabling intra-perimeter communication where associated resources can freely communicate.Configure access modes and rules:Start with Transition mode to understand access patterns before transitioning to Enforced mode for maximum protection. Define explicit inbound and outbound access rules using IP addresses, subscriptions, or FQDNs to control traffic outside the perimeter while maintaining default-deny posture.Enable monitoring and Private Link integration:Configurediagnostic logsto capture access attempts and policy violations. Private endpoint traffic is automatically allowed into the perimeter, complementing VNet-to-PaaS connectivity with perimeter-level data exfiltration controls. nan nan nan nan nan nan nan
API Management should disable public network access to the service configuration endpoints
App Configuration should disable public network access
App Configuration should use a SKU that supports private link
App Configuration should use private link
App Service Environment apps should not be reachable over public internet
App Service app slots should disable public network access
App Service apps should disable public network access
App Service apps should use a SKU that supports private link
App Service apps should use private link
Application Insights components should block log ingestion and querying from public networks
Authorized IP ranges should be defined on Kubernetes Services
Automation accounts should disable public network access
Azure AI Search service should use a SKU that supports private link
Azure AI Search services should disable public network access
Azure AI Services resources should restrict network access
Azure AI Services resources should use Azure Private Link
Azure API for FHIR should use private link
Azure Arc Private Link Scopes should be configured with a private endpoint
Azure Arc Private Link Scopes should disable public network access
Azure Arc-enabled kubernetes clusters should be configured with an Azure Arc Private Link Scope
Azure Arc-enabled servers should be configured with an Azure Arc Private Link Scope
Azure Attestation providers should disable public network access
Azure Cache for Redis Enterprise should use private link
Azure Cache for Redis should disable public network access
Azure Cache for Redis should use private link
Azure Cosmos DB accounts should have firewall rules
Azure Cosmos DB should disable public network access
Azure Data Explorer cluster should use private link
Azure Data Explorer should use a SKU that supports private link
Azure Data Factory should use private link
Azure Databricks Clusters should disable public IP
Azure Databricks Workspaces should be in a virtual network
Azure Databricks Workspaces should disable public network access
Azure Databricks Workspaces should use private link
Azure Databricks workspaces should be Premium SKU that supports features like private link, customer-managed key for encryption
Azure Device Update for IoT Hub accounts should use private link
Azure Event Grid domains should disable public network access
Azure Event Grid domains should use private link
Azure Event Grid namespace MQTT broker should use private link
Azure Event Grid namespace topic broker should use private link
Azure Event Grid namespaces should disable public network access
Azure Event Grid topics should disable public network access
Azure Event Grid topics should use private link
Azure File Sync should use private link
Azure Front Door profiles should use Premium tier that supports managed WAF rules and private link
Azure HDInsight should use private link
Azure Health Data Services de-identification service should disable public network access
Azure Health Data Services de-identification service should use private link
Azure Health Data Services workspace should use private link
Azure Key Vault should disable public network access
Azure Key Vault should have firewall enabled or public network access disabled
Azure Key Vaults should use private link
Azure Machine Learning Computes should be in a virtual network
Azure Machine Learning Workspaces should disable public network access
Azure Machine Learning and Ai Studio should use Allow Only Approved Outbound Managed Vnet mode
Azure Machine Learning workspaces should use private link
Azure Managed Grafana workspaces should disable public network access
Azure Managed Grafana workspaces should use private link
Azure Monitor Private Link Scope should block access to non private link resources
Azure Monitor Private Link Scope should use private link
Azure Purview accounts should use private link
Azure SQL Managed Instances should disable public network access
Azure Service Bus namespaces should use private link
Azure SignalR Service should disable public network access
Azure SignalR Service should use a Private Link enabled SKU
Azure SignalR Service should use private link
Azure Spring Cloud should use network injection
Azure Synapse workspaces should disable public network access
Azure Synapse workspaces should use private link
Azure Virtual Desktop hostpools should disable public network access
Azure Virtual Desktop hostpools should disable public network access only on session hosts
Azure Virtual Desktop service should use private link
Azure Virtual Desktop workspaces should disable public network access
Azure Web PubSub Service should disable public network access
Azure Web PubSub Service should use a SKU that supports private link
Azure Web PubSub Service should use private link
Bot Service should have public network access disabled
BotService resources should use private link
Container Apps environment should disable public network access
Container registries should have SKUs that support Private Links
Container registries should not allow unrestricted network access
Container registries should use private link
CosmosDB accounts should use private link
Disk access resources should use private link
ElasticSan should disable public network access
Event Hub Namespaces should disable public network access
Event Hub namespaces should use private link
Function app slots should disable public network access
Function apps should disable public network access
IoT Central should use private link
IoT Hub device provisioning service instances should disable public network access
IoT Hub device provisioning service instances should use private link
Log Analytics workspaces should block log ingestion and querying from public networks
Managed disks should disable public network access
Private endpoint connections on Azure SQL Database should be enabled
Private endpoint should be enabled for MariaDB servers
Private endpoint should be enabled for MySQL servers
Private endpoint should be enabled for PostgreSQL servers
Public network access for Azure Device Update for IoT Hub accounts should be disabled
Public network access on Azure Data Explorer should be disabled
Public network access on Azure Data Factory should be disabled
Public network access on Azure IoT Hub should be disabled
Public network access on Azure SQL Database should be disabled
Public network access should be disabled for Azure File Sync
Public network access should be disabled for Batch accounts
Public network access should be disabled for Container registries
Public network access should be disabled for IoT Central
Public network access should be disabled for MariaDB servers
Public network access should be disabled for MariaDB servers
Public network access should be disabled for MySQL flexible servers
Public network access should be disabled for MySQL servers
Public network access should be disabled for PostgreSQL flexible servers
Public network access should be disabled for PostgreSQL servers
Service Bus Namespaces should disable public network access
Storage account public access should be disallowed
Storage accounts should disable public network access
Storage accounts should restrict network access
Storage accounts should restrict network access using virtual network rules
Storage accounts should restrict network access using virtual network rules (excluding storage accounts created by Databricks)
Storage accounts should use private link
Storage accounts should use private link (excluding storage accounts created by Databricks)
VM Image Builder templates should use private link
[Preview]: Azure Key Vault Managed HSM should disable public network access
[Preview]: Azure Key Vault Managed HSM should use private link
[Preview]: Azure Recovery Services vaults should use private link for backup
[Preview]: Recovery Services vaults should use private link
NS-3 nan Deploy firewall at the edge of enterprise network Parent Secure network boundaries IP Forwarding on your virtual machine should be disabled Use firewall at the network edge to perform advanced filtering on network traffic to and from external networks, such as the internet, and between internal network segments. At a minimum, firewall policy should include: Block known bad IP addresses and sites.Restrict high-risk protocols, such as remote management protocols and intranet protocols at edge networks to prevent unauthorized access or lateral movement.Enforce application rules to allow only approved external destinations and block unauthorized or risky sites. Adversaries exploit vulnerabilities exposed to public or untrusted networks through accessible protocols, malicious domains, and weak network controls. Initial Access (TA0001):unauthorized access to high-risk protocols (e.g., RDP/TCP 3389, SSH/TCP 22) or malicious domains (e.g., T1190 - Exploit Public-Facing Application). Command and Control (TA0011):malware connecting to malicious IPs/domains (e.g., T1071 - Application Layer Protocol). An organization with multiple application workloads across different spoke VNets needed centralized network security inspection for all internet-bound traffic and inter-spoke communications while preventing access to malicious domains and unauthorized website categories. Must have SC-7, SC-7(5), AC-4, SI-4(4) 1.2.1, 1.3.1, 1.4.1, 1.4.2 9.2, 9.3, 13.1 PR.AC-05, PR.PT-04, DE.CM-01 A.8.20, A.8.22 CC6.1, CC6.6, CC7.2
Management ports of virtual machines should be protected with just-in-time network access control
Management ports should be closed on your virtual machines Unauthorized access via exposed protocols:Publicly accessible protocols like RDP (TCP 3389) or SMB (TCP 445) enable attackers to gain unauthorized entry, compromising system integrity through exploits such as brute-force or CVE-targeted attacks.Malware and phishing via malicious domains/IPs:Malicious domains and IPs facilitate malware delivery or phishing campaigns, endangering endpoints and sensitive data through command-and-control or social engineering attacks.Data exfiltration through unrestricted outbound traffic:Uncontrolled egress to unapproved destinations allows adversaries to exfiltrate sensitive data, risking breaches and compliance violations via covert channels like HTTPS POSTs.Lateral movement due to poor segmentation:Insufficient network segmentation permits attackers to pivot internally, exploiting inter-segment traffic (e.g., SMB, Kerberos) to propagate from compromised systems.Vulnerabilities from untrusted applications/URLs:Access to risky or untrusted URLs and applications increases exposure to exploits, elevatin Exfiltration (TA0010):unauthorized data transfers via outbound traffic to unapproved destinations (e.g., T1041 - Exfiltration Over C2 Channel). Challenge:The organization had workloads deployed in separate spoke VNets with direct internet access, creating inconsistent security policies and inability to centrally inspect traffic.
[Preview]: All Internet traffic should be routed via your deployed Azure Firewall
Lateral Movement (TA0008):inhibits internal pivoting through unfiltered inter-segment traffic (e.g., SMB/TCP 445, Kerberos/TCP 88) (e.g., T1021 - Remote Services). Each spoke had its own NSG rules, leading to policy drift and security gaps.
There was no visibility into outbound connections to potentially malicious domains, no ability to block risky website categories (social media, file sharing), and no inspection of HTTPS traffic content. Inter-spoke traffic flowed freely without inspection, enabling potential lateral movement after compromise.
Solution approach: Hub-and-spoke topology with centralized firewall:DeployedAzure Firewall Premiumin a hub VNet (10.0.0.0/16) with dedicated AzureFirewallSubnet (10.0.1.0/26, firewall private IP 10.0.1.4), establishing a single enforcement point for all network traffic inspection and policy management.VNet peering for spoke connectivity:UsedVNet peeringto connect application spoke VNet (10.1.0.0/16) and database spoke VNet (10.2.0.0/16) to the hub VNet, enabling centralized traffic routing through the firewall.User-defined routes for traffic steering:Createdroute tablesin each spoke VNet redirecting all internet-bound traffic (0.0.0.0/0) and inter-spoke traffic to the Azure Firewall private IP (10.0.1.4), forcing all egress through the central inspection point.Firewall policies with multi-layer filtering:Defined comprehensiveAzure Firewall policiesincluding network rules (allow DNS UDP/53 to Azure DNS, deny all other protocols by default), application rules (allow business-critical FQDNs like .microsoft.com, deny file-sharing domains like .torrent), and threat intelligence rules (block known malicious IPs from Microsoft Defender threat feeds).URL filtering and category-based blocking:ImplementedFQDN-based application rulesfor precise domain control andcategory-based filteringto block entire website categories (Hacking, Social Media, Gambling) while allowing work-related categories (Business/Economy, Technology/Internet), enforcing acceptable use policies at the network edge.TLS inspection for HTTPS traffic:EnabledTLS inspectionwith certificates stored in Azure Key Vault, allowing the firewall to decrypt, inspect, and re-enc
NS-3 NS-3.1 Prepare for Azure Firewall Deployment Child Secure network boundaries IP Forwarding on your virtual machine should be disabled Use firewall at the network edge to perform advanced filtering on network traffic to and from external networks, such as the internet, and between internal network segments. At a minimum, firewall policy should include: Block known bad IP addresses and sites.Restrict high-risk protocols, such as remote management protocols and intranet protocols at edge networks to prevent unauthorized access or lateral movement.Enforce application rules to allow only approved external destinations and block unauthorized or risky sites. nan nan Azure Firewall deployment requires proper network topology enabling centralized traffic inspection across network boundaries. Hub-and-spoke architectures position the firewall at the network core, routing all spoke traffic through a central inspection point while user-defined routes ensure traffic flow follows intended paths. This preparation establishes the foundation for comprehensive edge protection and inter-segment filtering. Prepare network infrastructure for Azure Firewall deployment: Set up hub/spoke virtual network topology:Deploy Azure Firewall in ahub VNetto centrally manage and secure traffic across multiple spoke VNets hosting application workloads, establishing a single enforcement point for network security policies.Join spoke virtual networks:UseVNet peeringto connect each spoke VNet to the hub VNet where Azure Firewall is deployed, enabling communication between spokes through the hub while maintaining network isolation.Configure user-defined routes (UDRs):Createroute tablesdirecting network traffic from spoke VNets through Azure Firewall in the hub network, including routes for internet egress (0.0.0.0/0) and optionally inter-spoke traffic if spoke-to-spoke communication requires inspection. nan nan nan nan nan nan nan
Management ports of virtual machines should be protected with just-in-time network access control
Management ports should be closed on your virtual machines
[Preview]: All Internet traffic should be routed via your deployed Azure Firewall
NS-3 NS-3.2 Deploy Azure Firewall with appropriate policies Child Secure network boundaries IP Forwarding on your virtual machine should be disabled Use firewall at the network edge to perform advanced filtering on network traffic to and from external networks, such as the internet, and between internal network segments. At a minimum, firewall policy should include: Block known bad IP addresses and sites.Restrict high-risk protocols, such as remote management protocols and intranet protocols at edge networks to prevent unauthorized access or lateral movement.Enforce application rules to allow only approved external destinations and block unauthorized or risky sites. nan nan Azure Firewall provides stateful application-layer traffic filtering with centralized policy management across enterprise network segments. By combining network rules, application rules, and threat intelligence, firewalls inspect traffic flows at multiple layers while URL filtering and TLS inspection enable granular control over HTTP/HTTPS communications. Proper policy design balances security requirements with operational needs through structured rule hierarchies and category-based filtering. Deploy and configure Azure Firewall with comprehensive policies: Deploy Azure Firewall in hub VNet:Deploy Azure Firewall (Standard or Premium tier based on features needed) in the hub VNet, assigning both public IP addresses for internet-bound traffic and private IP addresses for internal routing from spoke VNets.Create firewall policies with filtering rules:DefineAzure Firewall policiescontaining network rules (IP/port-based filtering), application rules (FQDN-based filtering), and threat intelligence rules, organizing rules into collections based on security requirements (e.g., allow business-critical services, block malicious IPs, deny risky categories).Configure URL filtering for HTTP/HTTPS traffic:ImplementFQDN-based application rulesto allow or deny specific domains (e.g., allow .microsoft.com, deny .torrent) and configurecategory-based filteringto block entire website categories (e.g., Hacking, Social Media) while allowing work-related categories.Enable TLS inspection for advan nan nan nan nan nan nan nan
Management ports of virtual machines should be protected with just-in-time network access control
Management ports should be closed on your virtual machines
[Preview]: All Internet traffic should be routed via your deployed Azure Firewall
NS-4 nan Deploy intrusion detection/intrusion prevention systems (IDS/IPS) Parent Monitor and respond No Azure Policy available Use network intrusion detection and intrusion prevention systems (IDS/IPS) to inspect the network and payload traffic to and from your workload or virtual networks. Ensure that IDS/IPS is always tuned to provide high-quality alerts to your SIEM solution. Note: For more in-depth host level detection and prevention capability, use host-based IDS/IPS or a host-based endpoint detection and response (EDR) solution in conjunction with the network IDS/IPS. Adversaries exploit vulnerabilities in protocols, applications, and internal traffic to execute malicious activities. Initial Access (TA0001):unauthorized intrusions via exploits targeting network vulnerabilities (e.g., T1190 - Exploit Public-Facing Application). An organization needed to protect critical infrastructure from known exploits and zero-day attacks while maintaining visibility into threat activity without disrupting legitimate business operations. Must have SI-4, SI-4(4), SI-4(5), SC-7(5) 11.4.1, 11.4.2, 1.4.1 13.2, 13.6, 13.7 DE.CM-01, DE.CM-04, DE.CM-07 A.8.16, A.8.22, A.5.24 CC6.1, CC7.2
Protocol exploits:Vulnerabilities in protocols like RDP (TCP 3389) or HTTP/HTTPS (TCP 80/443) enable unauthorized access or system compromise through exploits such as CVE-targeted attacks.Command-and-control (C2) communications:Malicious servers establish control over compromised devices via DNS queries or IP-based callbacks, facilitating persistent exploitation or malware propagation.Application exploits:Attacks like SQL injection, cross-site scripting (XSS), or buffer overflows target application vulnerabilities to steal data or execute arbitrary code.Lateral movement:Anomalous internal traffic, such as SMB (TCP 445) enumeration or Kerberos (TCP 88) ticket abuse, signals attacker pivoting within the network.Data exfiltration:Unauthorized data transfers occur over encrypted channels (e.g., HTTPS POSTs) or high-volume egress, using obfuscation to evade detection. Execution (TA0002):malicious code execution from vulnerability exploits or C2 payloads (e.g., T1059 - Command and Scripting Interpreter). Command and Control (TA0011):malware C2 communications by utilizing DNS queries or IP-based callbacks (e.g., T1071 - Application Layer Protocol). Challenge:The organization operated a multi-tier web application processing financial transactions with no signature-based threat detection beyond basic firewall rules.
Lateral Movement (TA0008):anomalous internal traffic (e.g., SMB enumeration) indicative of pivoting (e.g., T1021 - Remote Services). Security teams lacked visibility into exploit attempts targeting application servers, had no capability to detect command-and-control communications, and experienced false positive alerts from generic IDS solutions requiring extensive tuning.
Exfiltration (TA0010):unauthorized data transfers over encrypted or obfuscated channels (e.g., T1041 - Exfiltration Over C2 Channel). Solution: Azure Firewall Premium with IDPS:DeployedAzure Firewall Premiumin hub VNet enabling IDPS capabilities alongside TLS inspection and URL filtering, establishing centralized signature-based threat detection for all spoke VNet traffic.Signature rule selection:Selected high-severityIDPS signaturesfrom critical categories including Malware (Cobalt Strike, Metasploit, ransomware C2), Exploits (PaperCut CVE-2023-27350, Log4Shell, ProxyShell), Phishing (credential harvesting), and Command-and-Control patterns.Alert mode and tuning:Configured IDPS in Alert mode for initial testing to observe signature matches without blocking traffic, analyzing alerts to identify false positives from legitimate DevOps tools and partner API calls, then created signature exceptions for known-good scenarios while keeping high-priority CVE signatures active.Prevention mode transition:Transitioned IDPS to Alert and Deny mode for production after validation, actively blocking detected threats including PaperCut exploitation attempts, Log4Shell attacks, and C2 communications.Sentinel integration:Configureddiagnostic logsto Log Analytics, created Sentinel analytics rules correlating IDPS detections with authentication events, and established automated incident creation for high-severity alerts.
Outcome:Exploitation attempts were successfully blocked preventing remote code execution.
Critical vulnerability exploitation was eliminated before compromise occurred.
False positive rates decreased substantially while maintaining comprehensive CVE coverage.
Security teams achieved rapid alert review and incident response, establishing continuous threat visibility with actionable intelligence for proactive defense.
NS-4 NS-4.1 Deploy Azure Firewall Premium for IDPS Child Monitor and respond No Azure Policy available Use network intrusion detection and intrusion prevention systems (IDS/IPS) to inspect the network and payload traffic to and from your workload or virtual networks. Ensure that IDS/IPS is always tuned to provide high-quality alerts to your SIEM solution. Note: For more in-depth host level detection and prevention capability, use host-based IDS/IPS or a host-based endpoint detection and response (EDR) solution in conjunction with the network IDS/IPS. nan nan Intrusion detection and prevention systems provide signature-based threat identification by matching network traffic patterns against known attack signatures, enabling real-time blocking of exploit attempts and malicious communications. Azure Firewall Premium's IDPS capability offers continuously updated signature libraries covering exploits, malware, command-and-control, and phishing categories while supporting both alert-only and prevention modes. Proper signature selection and tuning ensures high-fidelity detection while minimizing false positives. Deploy and configure IDPS through Azure Firewall Premium: Deploy Azure Firewall Premium:DeployAzure Firewall Premiumwith Premium Policy in your hub VNet to enable IDPS capabilities alongside other advanced features like TLS inspection and URL filtering.Select IDPS signature rules:ChooseIDPS signature rulesfrom the signature library based on threat priorities, starting with high-severity signatures in critical categories like "Malware," "Exploits," and "Phishing" that align with your organization's threat profile and risk tolerance.Configure IDPS mode:Set the IDPS mode to Alert mode initially for testing and tuning to observe signature matches without blocking traffic, then transition to Alert and Deny mode for production environments to actively prevent detected threats while maintaining alerting for security monitoring.Fine-tune signatures:Adjust individual signature rules based on operational experience, disabling or lowering nan nan nan nan nan nan nan
NS-5 nan Deploy DDOS protection Parent Secure network boundaries Azure DDoS Protection should be enabled Deploy DDoS protection across various tiers to effectively mitigate attacks targeting different services and protocols at both the network and application layers. Threat actors attack networks, servers, or applications using overwhelming malicious traffic to cause service disruption. Impact (TA0040):disrupts service availability through volumetric floods (e.g., UDP/ICMP) or resource overloads (e.g., HTTP floods) to deny access (e.g., T1498 - Network Denial of Service). An e-commerce organization needed comprehensive DDoS protection for customer-facing applications experiencing increasing volumetric and application-layer attack attempts during peak shopping seasons. Must have SC-5, SC-5(1), SC-5(2), SI-4(4) 6.4.2, 11.4.7 13.3 PR.PT-05, DE.CM-01 A.8.13, A.8.24 CC6.1, CC7.2
Virtual networks should be protected by Azure DDoS Protection
Volumetric attacks (network flooding):Attackers flood network interfaces with massive traffic volumes (e.g., millions of packets per second) to exhaust bandwidth, router processing capacity, or load balancer resources, causing service unavailability. Resource Development (TA0042):leverages compromised systems for amplification attacks (e.g., DNS/NTP reflection) to scale attack impact (e.g., T1584 - Compromise Infrastructure). Challenge:The organization operated a global e-commerce platform with public-facing web applications, APIs, and content delivery infrastructure exposed to the internet.
Examples include UDP floods, ICMP floods, or amplified DNS reflection attacks leveraging protocols like NTP or SSDP.Protocol attacks (state exhaustion):Attackers exploit Layer 3/4 protocol vulnerabilities to deplete stateful resources, such as TCP connection tables or firewall session states. During peak events, the platform experienced multiple DDoS attacks including UDP floods, TCP SYN floods exhausting load balancer connection tables, HTTP floods targeting checkout APIs, and DNS amplification attacks.
Common techniques include TCP SYN floods, which overwhelm servers with half-open connections, or ACK floods targeting stateful devices.Resource layer attacks (application overload):Limited Layer 7 attacks, such as HTTP GET/POST floods, target application resources (e.g., CPU, memory, or database connections) to overwhelm web servers or APIs. Without dedicated DDoS protection, these attacks caused service outages, resulting in lost revenue and customer dissatisfaction.
These attacks aim to exhaust compute resources, causing latency spikes or outages.Amplification attacks:Attackers exploit misconfigured servers (e.g., DNS, NTP, or Plex Media servers on UDP Solution: DDoS Network Protection:EnabledAzure DDoS Network Protectionon production virtual networks hosting customer-facing applications, providing comprehensive VNet-level protection with adaptive tuning, automatic attack detection at Layers 3 and 4, and real-time mitigation.Application layer protection:DeployedAzure Application Gateway with WAFfor regional applications andAzure Front Door with WAFfor global edge delivery, enabling Layer 7 DDoS protection with rate limiting, HTTP flood detection, and bot protection rules.Protection policy configuration:CreatedDDoS protection planassociating all production VNets, configured adaptive tuning learning baseline traffic patterns, enabled always-on traffic monitoring, and defined protection policies covering UDP floods, TCP SYN floods, ICMP floods, and protocol attacks.Monitoring and alerting:ConfiguredDDoS diagnostic logssending attack telemetry to Log Analytics workspace, created Azure Monitor alerts triggering immediate notifications when attacks detected, established Sentinel workbook correlating DDoS attacks with application performance metrics, and configured Application Insights monitoring application health during mitigation.Rapid Response engagement:ActivatedDDoS Rapid Responseproviding direct access to DDoS protection experts during active attacks for real-time attack analysis, custom mitigation strategy development, and post-attack forensics.
NS-5 NS-5.1 Implement DDOS protection in the appropriate network tier Child Secure network boundaries Azure DDoS Protection should be enabled Deploy DDoS protection across various tiers to effectively mitigate attacks targeting different services and protocols at both the network and application layers. nan nan Deploy DDoS protection at both network and application layers to defend against volumetric and application-specific attacks. Azure provides multiple tiers of protection: DDoS Network Protection for comprehensive VNet coverage with rapid response support, DDoS IP Protection for cost-effective protection of individual IPs, and application layer protection through WAF. Configure monitoring and alerts to validate protection effectiveness and ensure application resilience during attacks: Deploy network layer DDoS protection:Choose between DDoS Network Protection for workload deployments requiring comprehensive VNet coverage and rapid response support for attack investigation and post-attack analysis, or DDoS IP Protection for cost-effective protection of a limited number of IPs without rapid response support.Deploy application layer DDoS protection:Enable DDoS protection on Azure Web Application Firewall (WAF), Application Gateway, or Azure Front Door to defend against application layer (Layer 7) attacks.Configure monitoring and alerts:Configure alerts and monitor metrics and logs from the DDoS protection service and your applications to ensure protection effectiveness, application resilience, and desired performance during and after attacks. NoteEven without using the above DDoS protection service, Azure offers DDoS infrastructure protection, a default platform-level protection at the network infrastructure level. This protection is provided free of charge and does not require an nan nan nan nan nan nan nan
Virtual networks should be protected by Azure DDoS Protection
NS-6 nan Deploy web application firewall Parent Secure network boundaries Azure Web Application Firewall should be enabled for Azure Front Door entry-points Deploy a web application firewall (WAF) and configure rules to safeguard web applications and APIs from application-specific attacks by inspecting, detecting, and filtering malicious HTTP/HTTPS traffic. Attackers exploit web application vulnerabilities to gain unauthorized access, execute malicious code, steal credentials, or exfiltrate data. Initial Access (TA0001):Exploits SQL injection, XSS, or remote file inclusion to gain entry (e.g., T1190 - Exploit Public-Facing Application). An organization needed to protect customer-facing web applications and APIs from SQL injection, XSS attacks, and bot-driven credential stuffing while maintaining performance for legitimate users. Must have SC-7, SC-7(5), SI-10, SI-10(1), SI-11 6.4.1, 6.4.2, 11.4.7 13.2, 13.9 PR.AC-05, PR.PT-05, DE.CM-04 A.8.20, A.8.22, A.8.25 CC6.1, CC6.6, CC7.2
Web Application Firewall (WAF) should be enabled for Application Gateway
Injection attacks (e.g., SQL injection, command injection):Attackers exploit input validation vulnerabilities to inject malicious code into web application queries or commands, enabling unauthorized database access, data exfiltration, or system compromise. Execution (TA0002):Executes malicious code via command injection, RFI, or XSS (e.g., T1059 - Command and Scripting Interpreter). Challenge:The organization had web applications deployed globally with no protection against OWASP Top 10 vulnerabilities, resulting in multiple SQL injection attempts, bot-driven attacks overwhelming login endpoints, and no visibility into malicious traffic patterns.
SQL injection (SQLi) manipulates backend queries (e.g., appending ' OR '1'='1 to a login form), while command injection executes arbitrary OS commands (e.g., ; rm -rf / via a form field).HTTP protocol violations and malformed requests:Attackers send malformed HTTP requests (e.g., invalid headers, oversized payloads, or non-standard methods like TRACE) to exploit vulnerabilities in web servers or applications, potentially causing crashes or unauthorized access. Credential Access (TA0006):Steals credentials through XSS or credential stuffing (e.g., T1539 - Steal Web Session Cookie, T1110 - Brute Force). Applications lacked rate-limiting controls, allowing API abuse and credential stuffing attacks, and there was no mechanism to distinguish legitimate users from malicious bots.
These attacks target misconfigured servers or unpatched frameworks.Bot-driven attacks (e.g., credential stuffing, scraping): Automated bots launch credential stuffing attacks (e.g., brute-forcing login endpoints with stolen credentials) or scrape sensitive content (e.g., pricing data), overloading servers or compromising user accounts Collection (TA0009):Gathers data via SQL injection or scraping (e.g., T1213 - Data from Information Repositories). Solution approach: WAF service selection:DeployedAzure Application Gateway with WAFfor VNet-hosted applications andAzure Front Door with WAFfor globally distributed applications requiring edge protection and low-latency access.Built-in protection rulesets:EnabledOWASP Core Rule Set (CRS) 3.2to protect against SQL injection, cross-site scripting (XSS), remote file inclusion, and other common web vulnerabilities, and activatedMicrosoft Bot Manager rulesto identify and block malicious bots while allowing legitimate search engine crawlers and monitoring services.Custom rules for specific threats:Implemented rate-limiting rules blocking clients exceeding 100 requests per minute to prevent API abuse and credential stuffing, geo-filtering rules blocking traffic from high-risk regions where services are unavailable, and IP reputation-based rules blocking requests from known malicious IP ranges identified through threat intelligence feeds.Exclusion management:Created targeted exclusions for legitimate business scenarios such as /checkout endpoints with complex form inputs that triggered false positives in OWASP rules, /upload endpoints handling large file submissions, and /api endpoints with unusual but valid header patterns from mobile applications.Detection to prevention transition:Started WAF in detection mode for two weeks to identify false positives, refined rules and exclusions based on legitimate traffic patterns, then transitioned to prevention mode for production applications to actively block threats while maintaining business continuity.
NS-6 NS-6.1 Configure Azure WAF with appropriate rules Child Secure network boundaries Azure Web Application Firewall should be enabled for Azure Front Door entry-points Deploy a web application firewall (WAF) and configure rules to safeguard web applications and APIs from application-specific attacks by inspecting, detecting, and filtering malicious HTTP/HTTPS traffic. nan nan Enable web application firewall (WAF) capabilities in Azure Application Gateway, Azure Front Door, or Azure Content Delivery Network (CDN) to protect applications and APIs from web-based attacks. Select the appropriate service based on application requirements, configure WAF policies with built-in and custom rules, set the policy mode based on security posture, and associate the policy with the service endpoint: Select the appropriate WAF service:Choose Azure Application Gateway for VNet-hosted applications, Azure Front Door for global edge delivery, or Azure CDN for content-heavy workloads based on application requirements and architecture.Configure WAF policies with built-in and custom rules:Start with common built-in rulesets such as OWASP Core Rule Set (CRS 3.2) and bot protection (Microsoft Bot Manager) rules. Add custom rules (e.g., rate-limiting for >100 requests/min) and exclusions to reduce false positives based on threat landscape and application security profile.Set WAF policy mode:Use detection mode initially or for non-critical applications to avoid disrupting legitimate traffic during setup and rule optimization. Switch to prevention mode for critical applications once rules are validated to block malicious requests.Associate WAF policy with service endpoint:Associate the WAF policy with the Application Gateway, Front Door, or CDN endpoint to ensure all HTTP/HTTPS traffic is routed through WAF for inspection. nan nan nan nan nan nan nan
Web Application Firewall (WAF) should be enabled for Application Gateway
NS-7 nan Manage network security centrally and effectively Parent nan No Azure Policy available To reduce operational risk and misconfiguration in complex and fragmented network environment, use cloud native network management features to centralize, simplify, and enforce consistent network-security configurations. Lack of centralized control results in overlooked or outdated security settings, increasing the risk of exploitation. Initial Access (TA0001):Exploitation of misconfigurations or outdated security settings to gain unauthorized access (e.g., T1190 - Exploit Public-Facing Application, T1133 - External Remote Services). Use case:Multi-region payment platform consolidates network security at scale Context:A mid-size payment processor operating in East US and West Europe with 4 subscriptions (Prod, Non-Prod, Shared Services, SecOps) under one tenant needs PCI-DSS segmentation, fewer incidents from rule drift, and centralized monitoring. Must have CM-2, CM-3, CM-6, CA-7, SI-4 1.4.5, 11.5.1, 12.4.1 4.1, 4.2, 12.4, 13.6 PR.IP-01, DE.CM-01, DE.CM-07 A.8.9, A.8.32, A.5.37 CC6.6, CC7.2, CC8.1
Inconsistent policy enforcement and misconfigurations:Decentralized management often leads to fragmented rule sets and policy gaps, making it easier for attackers to discover and exploit weak points. Defense Evasion (TA0005):Taking advantage of fragmented rule sets and lack of centralized monitoring to avoid detection (e.g., T1562 - Impair Defenses). Centralized policy enforcement with Azure Virtual Network Manager: Design:Create AVNM at the management group level.
Misconfigurations are more likely, increasing the chances of accidental exposure or unintended access.Reduced visibility and delayed response:Without a unified management approach, monitoring and incident response become slower and less effective. Lateral Movement (TA0008):Moving laterally through the network by exploiting policy gaps or outdated segmentation (e.g., T1021 - Remote Services). Command and Control (TA0011):Using unmonitored or misconfigured network paths to establish and maintain C2 channels (e.g., T1071 - Application Layer Protocol). Define two Network Groups: ng-prod and ng-nonprod with dynamic membership by subscriptionId tag. Author Security Admin Rules (SARs) to enforce organizational guardrails that evaluate before NSGs: Deny-Inbound-Internet-to-Spokes (blocks unsolicited inbound from Internet to all spoke subnets), Allow-Hub-Infra (permits hub services - Firewall/Bastion - into spokes), Allow-Platform-DNS (permits DNS from hub resolvers to spokes).App team boundaries:Workloads keep NSGs for micro-segmentation (e.g., web to api :443, api to db :1433) within each spoke. NSG changes are owned by app teams; SARs are owned by the platform security team.Result:Guardrails are consistent across both regions; app teams can't accidentally create direct internet access even if an NSG is misconfigured.
This can delay the detection of malicious activity, allowing attackers more time to escalate attacks or exfiltrate data.Difficulty maintaining compliance:Inadequate central management complicates efforts to consistently meet regulatory and industry standards, risking non-compliance and potential penalties. Firewall and routing management with Firewall Manager and Virtual WAN: Design:Deploy Virtual WAN secure hubs in each region (East US, West Europe).
Attach spokes to the nearest hub and enable routing intent so all Internet egress is inspected. Use Firewall Manager with a global Firewall Policy (Tier: Premium) and two child policies (Prod/Non-Prod) for environment overrides.Policy structure:Base (global) policy includes Threat Intelligence set to Alert + Deny, TLS inspection enabled for outbound HTTPS, IDPS on in balanced mode, and outbound allow rules using Service Tags (Storage, KeyVault, AzureMonitor) and IP Groups for partner endpoints.
Prod child policy has stricter URL filtering (block uncategorized) and allow list for payment gateways via IP Groups. Non-Prod child policy has broader dev tooling access via Service Tags (AzureDevOps, AzureContainerRegistry).Result:Single pane to manage rules with changes propagating to both hubs.
Routing is consistent, and all egress is inspected with TLS decryption where allowed.
NS-7 NS-7.1 Manage network security centrally and effectively Child nan No Azure Policy available To reduce operational risk and misconfiguration in complex and fragmented network environment, use cloud native network management features to centralize, simplify, and enforce consistent network-security configurations. nan nan Use Azure's centralized tools and standardized practices to simplify and scale network-security management, ensuring consistent enforcement, reduced misconfiguration, and improved monitoring. Implement centralized policy enforcement, standardize firewall and routing management, enable comprehensive monitoring and analytics, and maintain resource consistency through governance practices: Implement centralized policy enforcement:Use Azure Virtual Network Manager (AVNM) to define Security Admin Rules that apply consistently across subscriptions and regions. Retain NSGs for workload-level micro-segmentation. Apply policies through network groups (e.g., by environment: prod, non-prod).Standardize firewall and routing management:Manage Azure Firewall rules through Firewall Manager with Firewall Policy objects. Standardize on IP Groups and Service Tags instead of raw IPs. Use Azure Firewall Premium where TLS inspection, IDPS, and URL filtering are required. Prefer Virtual WAN secure hubs or a shared hub-and-spoke topology to enforce routing intent consistently.Enable comprehensive monitoring and analytics:Use virtual network flow logs v2 (to replace NSG flow logs). Enable Azure Firewall diagnostic logs and integrate with Traffic Analytics, Log Analytics, and Microsoft Sentinel. Use Firewall Policy Analytics and rule hit counts to eliminate unused or duplicate rules.Maintain resource consistency and governance:Apply CAF naming conventions and mandatory resource tags to all VNets, NSG nan nan nan nan nan nan nan
NS-8 nan Detect and disable insecure services and protocols Parent Monitor and respond App Service apps should use the latest TLS version Discover and disable insecure services and protocols at the OS, application, or software package layer. Deploy compensating controls if disabling insecure services and protocols is not possible. Threat actors exploit insecure and vulnerable services and protocols to compromise systems and data. Initial Access (TA0001):Exploitation of insecure protocols like SSL/TLSv1 or SSHv1, which are vulnerable to protocol downgrade attacks or known exploits, blocking unauthorized entry (e.g., T1190 - Exploit Public-Facing Application). A healthcare organization needed to eliminate insecure protocols across their Azure environment to meet HIPAA compliance requirements and reduce attack surface for protected health information. Must have SC-8, SC-8(1), SC-13, IA-5(1) 2.2.4, 4.2.1, 6.2.4 4.8, 9.3, 13.4 PR.DS-02, PR.IP-01, DE.CM-04 A.8.24, A.8.26, A.5.14 CC6.1, CC6.7, CC7.1
Function apps should use the latest TLS version
Cryptographic Weakness Exploitation: SSL/TLSv1 and weak ciphers (e.g., RC4, DES) are vulnerable to MITM attacks (e.g., POODLE, BEAST), enabling adversaries to decrypt sensitive data like session tokens via padding oracle or chosen-ciphertext attacks.Unauthorized Access via Protocol Exploits:SSHv1 and SMBv1 vulnerabilities (e.g., CVE-2001-1473, CVE-2017-0144/EternalBlue) allow remote code execution or unauthenticated access, enabling initial footholds.Credential Theft:LM/NTLMv1 and wDigest store weak hashes or plaintext credentials, vulnerable to pass-the-hash or memory scraping (e.g., Mimikatz extracting LSASS data).Lateral Movement:SMBv1's unencrypted sessions and exploits (e.g., EternalBlue) enable malware propagation or credential relay across networks. Credential Access (TA0006):Credential theft by exploiting LM/NTLMv1 and wDigest, which store credentials in reversible formats or weak hashes, thwarting pass-the-hash or memory scraping (e.g., T1003 - OS Credential Dumping). Challenge:The organization operated a hybrid infrastructure with legacy applications requiring connectivity to Azure-hosted resources.
Lateral Movement (TA0008):Inhibits attacker pivoting SMBv1 which is vulnerable to exploits like EternalBlue, preventing propagation across networks (e.g., T1021 - Remote Services). Security assessment revealed widespread usage of insecure protocols including SSL/TLSv1.0 on web servers serving patient portals, SMBv1 enabled on file servers for legacy medical imaging software, LM/NTLMv1 authentication on domain controllers and application servers, wDigest authentication storing credentials in reversible format, unsigned LDAP binds on Active Directory controllers, and weak Kerberos encryption on service accounts.
The organization lacked visibility into protocol usage and faced potential HIPAA compliance violations.
Solution: Sentinel Insecure Protocol Workbook deployment:DeployedMicrosoft Sentineland installedInsecure Protocol Workbookfrom content hub, connected data sources including Windows Security Event logs, Azure Monitor logs, Active Directory logs, and network flow logs, establishing comprehensive baseline of insecure protocol usage across hybrid environment.Protocol discovery:Used Insecure Protocol Workbook to identify SSL/TLSv1.0 usage on web servers, SMBv1 traffic from legacy medical imaging workstations, LM/NTLMv1 authentication patterns, wDigest enabled on Windows servers, unsigned LDAP binds from legacy applications, and weak RC4 Kerberos encryption on service accounts.Systematic protocol disabling:Created phased remediation plan validated through change advisory board, disabled TLSv1.0/1.1 on web servers after confirming patient portal users operated modern browsers supporting TLS 1.2+, disabled SMBv1 after coordinating with medical imaging vendor software upgrades, transitioned domain controllers from NTLMv1 to NTLMv2 authentication, disabled wDigest via Group Policy, enforced LDAP signing on domain controllers, and upgraded service account Kerberos encryption to AES256.Compensating controls for exceptions:Implemented network-based compensating controls for systems requiring temporary insecure protocol support including isolated VLAN for legacy medical imaging workstations requiring SMBv1, NSG rules restricting SMBv1 traffic exclusively to isolated VLAN, Azure Firewall denying outbound SMBv1 from production subnets, dedicated jump host for legacy HR applications, and enhanced monitoring through Defe
NS-8 NS-8.1 Detect and disable insecure services and protocols Child Monitor and respond App Service apps should use the latest TLS version Discover and disable insecure services and protocols at the OS, application, or software package layer. Deploy compensating controls if disabling insecure services and protocols is not possible. nan nan Use Microsoft Sentinel's built-in Insecure Protocol Workbook to discover and mitigate insecure services and protocols across your Azure environment. This workbook identifies usage of protocols and services that do not meet appropriate security standards, such as SSL/TLSv1, SSHv1, SMBv1, LM/NTLMv1, wDigest, weak ciphers in Kerberos, and unsigned LDAP binds. After identification, disable these insecure protocols and services. When disabling is not feasible, implement compensating controls to reduce the attack surface. Discover insecure protocols:Use Microsoft Sentinel's Insecure Protocol Workbook to identify usage of SSL/TLSv1, SSHv1, SMBv1, LM/NTLMv1, wDigest, weak Kerberos ciphers, and unsigned LDAP binds across your environment. Disable insecure services and protocols:Disable identified insecure services and protocols that do not meet appropriate security standards to eliminate vulnerabilities. Implement compensating controls:If disabling insecure services or protocols is not possible due to business requirements or technical constraints, use compensating controls such as blocking access to resources through network security groups, Azure Firewall, or Azure Web Application Firewall to reduce the attack surface. nan nan nan nan nan nan nan
Function apps should use the latest TLS version
NS-9 nan Connect on-premises or cloud network privately Parent Secure network boundaries No Azure Policy available Use private connections for secure communication between different networks, such as cloud service provider datacenters and on-premises infrastructure in a colocation environment. When data travels over public networks, it is vulnerable to interception, unauthorized access, and tampering. Initial Access (TA0001):Exploitation of unencrypted or weakly encrypted protocols (e.g., HTTP or outdated TLS versions) vulnerable to packet sniffing or MitM attacks, enabling unauthorized entry into systems (e.g., T1190 - Exploit Public-Facing Application). A multinational financial services organization needed secure, high-performance connectivity between on-premises data centers, branch offices, and Azure cloud resources while eliminating public internet exposure for sensitive financial transactions. Must have SC-7, SC-7(4), SC-8 1.2.1, 2.2.7, 4.2.1 12.8, 13.8 PR.AC-05, PR.DS-02 A.8.21, A.8.22, A.5.14 CC6.6, CC6.7
Data interception:When data travels over public networks like the internet, it passes through multiple routers, switches, and service providers, any of which could be compromised or monitored by malicious actors. Credential Access (TA0006):Theft of credentials via intercepted network traffic, exploiting cleartext protocols (e.g., Telnet or FTP) or weak encryption susceptible to decryption, facilitating unauthorized access (e.g., T1040 - Network Sniffing). Challenge:The organization operated multiple on-premises data centers with branch offices globally, requiring connectivity to Azure-hosted applications processing financial transactions and customer data.
Attackers can deploy packet sniffing tools (e.g., Wireshark) to capture data packets. Lateral Movement (TA0008):Propagation within networks by exploiting misconfigured or exposed services (e.g., unpatched RDP or SMB), allowing attackers to pivot using stolen credentials or vulnerabilities (e.g., T1021 - Remote Services). Initial architecture used site-to-site VPN over the internet, experiencing unpredictable latency, bandwidth limitations during peak trading hours, security concerns about financial data traversing public internet despite encryption, and compliance requirements mandating private connectivity for PCI-DSS and GDPR.
If the data is unencrypted or weakly encrypted, sensitive information - such as login credentials, financial details, or proprietary business data - can be exposed.Man-in-the-Middle (MitM) Attacks:In a MitM attack, an attacker secretly intercepts and potentially alters the communication between two parties who believe they are directly communicating with each other. Remote employees connecting via point-to-site VPN experienced inconsistent performance and authentication issues.
This poses a severe threat to sensitive operations like financial transactions or authentication processes.Unauthorized access:Public or inadequately secured networks increase the likelihood of unauthorized users gaining access or tampering to private systems or resources. Applications in different Azure regions required low-latency inter-region communication without routing through on-premises hubs.
Attackers can exploit network weaknesses to reach internal infrastructure that should remain inaccessible from the outside. Solution: ExpressRoute for primary data center connectivity:DeployedAzure ExpressRoutecircuits at primary data centers through co-location facilities with ExpressRoute connectivity providers, establishing private Layer 3 connectivity to Azure backbone network with consistent low latency, configured ExpressRoute with Microsoft peering for Azure PaaS services and private peering for VNet-hosted resources, implemented BGP routing with active-active configuration for high availability and automatic failover.Site-to-site VPN for branch office connectivity:Deployedsite-to-site VPNfor branch offices lacking co-location facility access, creating VPN Gateway in hub VNet with active-active configuration for high availability, configured IPsec/IKE tunnels with strong cryptography meeting financial sector security standards, implemented BGP routing for dynamic path selection allowing branches to connect to nearest regional hub, established redundant tunnels ensuring connectivity during maintenance windows.Point-to-site VPN for remote employees:Configuredpoint-to-site VPNwith Azure Active Directory authentication for remote employees requiring secure access to Azure-hosted applications, enabled certificate-based authentication as fallback for scenarios without internet access to Azure AD, assigned client IP addresses from dedicated pool routed to Azure VNet resources via user-defined routes, implemented OpenVPN protocol for macOS/Linux clients and IKEv2/SSTP for Windows clien
NS-9 NS-9.1 Use Azure virtual private network (VPN) for lightweight site-to-site or point-to-site connectivity Child Secure network boundaries No Azure Policy available Use private connections for secure communication between different networks, such as cloud service provider datacenters and on-premises infrastructure in a colocation environment. nan nan Use Azure virtual private network (VPN) to create secure, encrypted connections between on-premises sites or end-user devices and Azure virtual networks for lightweight connectivity scenarios. Azure VPN provides a cost-effective solution for site-to-site connectivity (connecting entire networks) or point-to-site connectivity (connecting individual devices) without requiring dedicated infrastructure: Deploy site-to-site VPN:Use site-to-site VPN to securely connect your on-premises network to Azure virtual network, enabling seamless communication between on-premises resources and Azure workloads.Deploy point-to-site VPN:Use point-to-site VPN to enable individual end-user devices (laptops, workstations) to securely connect to Azure virtual network from remote locations. nan nan nan nan nan nan nan
NS-9 NS-9.2 Use Azure ExpressRoute (or Virtual WAN) for enterprise-level high performance connections Child Secure network boundaries No Azure Policy available Use private connections for secure communication between different networks, such as cloud service provider datacenters and on-premises infrastructure in a colocation environment. nan nan Use Azure ExpressRoute or Azure Virtual WAN to establish private, high-performance, low-latency connections between Azure datacenters and on-premises infrastructure in colocation environments. These enterprise-grade solutions bypass the public internet, providing dedicated bandwidth, predictable performance, and enhanced security for mission-critical workloads requiring consistent connectivity: Deploy ExpressRoute for dedicated private connectivity:Use Azure ExpressRoute to create a private connection between your on-premises infrastructure and Azure datacenters through a connectivity provider, ensuring dedicated bandwidth and predictable latency for enterprise workloads.Deploy Virtual WAN for global connectivity:Use Azure Virtual WAN to build a global network connecting multiple sites, branches, and Azure regions through a unified hub-and-spoke architecture with integrated security and routing capabilities. nan nan nan nan nan nan nan
NS-9 NS-9.3 Use VNet or subnet peering to join virtual networks Child Secure network boundaries No Azure Policy available Use private connections for secure communication between different networks, such as cloud service provider datacenters and on-premises infrastructure in a colocation environment. nan nan Use virtual network peering or subnet peering to establish private connectivity between Azure virtual networks without routing traffic over the public internet. Network traffic between peered virtual networks remains on the Azure backbone network, providing low-latency, high-bandwidth connections with no encryption overhead. Choose subnet peering when full virtual network connectivity is unnecessary, limiting exposure to only specific subnets: Deploy virtual network peering:Use virtual network peering to connect entire Azure virtual networks, enabling resources in different VNets to communicate privately as if they were in the same network. nan nan nan nan nan nan nan
NS-10 nan Ensure Domain Name System (DNS) security Parent Monitor and respond No Azure Policy available Ensure that Domain Name System (DNS) security configuration protects against known risks: Use trusted authoritative and recursive DNS services across your cloud environment to ensure the client (such as operating systems and applications) receives the correct resolution result.Separate the public and private DNS resolution so the DNS resolution process for the private network can be isolated from the public network.Ensure your DNS security strategy also includes mitigations against common attacks, such as dangling DNS, DNS amplifications attacks, DNS poisoning and spoofing, and so on. Threat actors attack DNS services or exploit vulnerable DNS services to compromise applications and redirect traffic. Command and Control (TA0011):Use DNS tunneling to encode C2 commands in queries (e.g., data.exfil.evil.com) or spoof resolutions to connect to malicious servers (e.g., T1071.004 - Application Layer Protocol: DNS). Challenge:An enterprise needed comprehensive DNS security covering trusted resolution services, private network DNS for internal resources, and advanced threat detection across hybrid cloud infrastructure. Must have SC-7, SI-4, SI-4(4), SI-4(5) 11.5.1, 12.10.1 8.5, 13.6, 13.8 DE.CM-01, DE.CM-04, DE.AE-02 A.8.16, A.8.22, A.5.24 CC6.1, CC7.2, CC7.3
DNS spoofing/poisoning:Adversaries forge DNS responses or corrupt resolver caches (e.g., Kaminsky attack) to redirect clients to malicious servers, enabling phishing or data interception.DNS amplification attacks:Attackers exploit misconfigured DNS servers to amplify DDoS traffic (e.g., 60-byte query yielding 4,000-byte response), overwhelming target networks.Dangling DNS exploitation:Dangling records (e.g., stale CNAMEs) allow adversaries to hijack decommissioned resources, redirecting traffic to malicious endpoints for phishing or malware.Data exfiltration via DNS tunneling:Malicious actors encode data in DNS queries (e.g., data.exfil.evil.com) to covertly exfiltrate sensitive information, bypassing firewalls.Phishing/malware delivery:Compromised resolvers redirect legitimate domains to attacker-controlled IPs, delivering phishing pages or malware to unsuspecting clients. Collection (TA0009):Collect data by spoofing DNS to redirect users to phishing sites or exfiltrating data via tunneling (e.g., T1040 - Network Sniffing). Solution approach: DeployedAzure recursive DNS (168.63.129.16)for all Azure VM workloads with NSG rules allowing DNS trafficHosted authoritative zones onAzure DNSfor public domain resolution with geo-distributionImplementedAzure Private DNS zonesfor private endpoint resolution (privatelink.database.windows.net, privatelink.blob.core.windows.net) linked to production VNetsConfiguredPrivate DNS integrationensuring private endpoint FQDNs resolve to private IPs (e.g., sqlserver.database.windows.net → 10.0.2.4)EnabledMicrosoft Defender for DNSthrough Defender for Servers Plan to monitor DNS tunneling, C2 communication, and malicious domain interactionsDeployedDefender for App Serviceto detect dangling DNS records during website decommissioning
Impact (TA0040):DNS amplification attacks, sending small queries to generate large responses, disrupting service availability (e.g., T1498.002 - Network Denial of Service: Reflection Amplification). Outcome:The DNS security implementation ensured reliable name resolution for cloud workloads while maintaining privacy for internal resources. Private DNS zones prevented sensitive queries from traversing public networks, while Defender for DNS provided visibility into DNS-based threats including data exfiltration attempts and command-and-control activity.
Initial Access (TA0001):Exploit dangling DNS records or spoofed resolutions to deliver malware/phishing, gaining entry to systems (e.g., T1190 - Exploit Public-Facing Application). The solution eliminated subdomain takeover risks through automated dangling DNS detection during resource lifecycle changes.
NS-10 NS-10.1 Use trusted DNS service Child Monitor and respond No Azure Policy available Ensure that Domain Name System (DNS) security configuration protects against known risks: Use trusted authoritative and recursive DNS services across your cloud environment to ensure the client (such as operating systems and applications) receives the correct resolution result.Separate the public and private DNS resolution so the DNS resolution process for the private network can be isolated from the public network.Ensure your DNS security strategy also includes mitigations against common attacks, such as dangling DNS, DNS amplifications attacks, DNS poisoning and spoofing, and so on. nan nan Use trusted DNS services to ensure clients receive correct resolution results and protect against DNS-based attacks. Azure provides the recursive DNS service at 168.63.129.16 (typically assigned via DHCP or preconfigured) for workload DNS resolution at the operating system or application level. Alternatively, use trusted external DNS servers. For organizations hosting their own domains, Azure DNS provides reliable authoritative DNS hosting. Organizations building custom DNS servers should follow NIST SP 800-81 Rev. 3 secure deployment guidelines: Use Azure recursive DNS or trusted external DNS:Configure workloads to use Azure recursive DNS (168.63.129.16) or trusted external DNS servers in VM operating systems or application DNS settings to ensure reliable name resolution.Allow Azure DNS in firewall rules:Add 168.63.129.16 to firewall and NSG allow lists to ensure proper DNS functionality for Azure resources.Host domains on Azure DNS:Use Azure DNS to host domain resolution for authoritative DNS needs, providing reliable and scalable DNS hosting (note: Azure DNS does not provide domain registration service).Follow secure DNS deployment guidelines:If building custom DNS servers, follow NIST SP 800-81 Rev. 3 Secure Domain Name System (DNS) Deployment Guide to implement security best practices. nan nan nan nan nan nan nan
NS-10 NS-10.2 Use Private DNS in virtual network Child Monitor and respond No Azure Policy available Ensure that Domain Name System (DNS) security configuration protects against known risks: Use trusted authoritative and recursive DNS services across your cloud environment to ensure the client (such as operating systems and applications) receives the correct resolution result.Separate the public and private DNS resolution so the DNS resolution process for the private network can be isolated from the public network.Ensure your DNS security strategy also includes mitigations against common attacks, such as dangling DNS, DNS amplifications attacks, DNS poisoning and spoofing, and so on. nan nan Use Azure Private DNS to establish private DNS zones where DNS resolution remains within the virtual network, preventing DNS queries from traversing public networks. This is essential for private endpoint configurations, where private DNS zones override public DNS resolution to route traffic privately to Azure services. Custom DNS solutions can further restrict resolution to only trusted sources, enhancing security for private workloads: Deploy Azure Private DNS for private resolution:Use Azure Private DNS to create private DNS zones that keep DNS resolution within the virtual network, ensuring queries never leave your network boundary.Configure private DNS for private endpoints:Configure private DNS zones for private endpoints to override public DNS resolution and ensure clients resolve private endpoint FQDNs to private IP addresses within the virtual network.Implement custom DNS for restricted resolution:Use custom DNS servers to restrict DNS resolution to only allow trusted resolution sources for your clients, providing additional control over name resolution security. nan nan nan nan nan nan nan
NS-10 NS-10.3 Use Defender for DNS for advanced protection Child Monitor and respond No Azure Policy available Ensure that Domain Name System (DNS) security configuration protects against known risks: Use trusted authoritative and recursive DNS services across your cloud environment to ensure the client (such as operating systems and applications) receives the correct resolution result.Separate the public and private DNS resolution so the DNS resolution process for the private network can be isolated from the public network.Ensure your DNS security strategy also includes mitigations against common attacks, such as dangling DNS, DNS amplifications attacks, DNS poisoning and spoofing, and so on. nan nan Use Microsoft Defender for DNS to detect and alert on advanced DNS-based security threats including data exfiltration via DNS tunneling, command-and-control communication, malicious domain interactions (phishing, crypto mining), and DNS attacks involving malicious resolvers. Defender for DNS protection is now included in Defender for Servers Plan. Additionally, use Microsoft Defender for App Service to detect dangling DNS records that could enable subdomain takeover attacks when decommissioning websites: Enable Defender for DNS protection:Use Microsoft Defender for DNS (included in Defender for Servers Plan) to monitor and alert on suspicious DNS activity including data exfiltration via DNS tunneling, malware command-and-control communication, and interactions with malicious domains.Monitor for malicious DNS activity:Configure alerts to detect communication with malicious DNS resolvers and DNS attacks that could compromise workload security or DNS service availability.Detect dangling DNS records:Use Microsoft Defender for App Service to identify dangling DNS records when decommissioning App Service websites, preventing subdomain takeover attacks by ensuring custom domains are removed from DNS registrars. nan nan nan nan nan nan nan