Azure DDoS Protection & Azure WAF: A Layered Defense for Modern DDoS Attacks
Introduction: The Need for Layered DDoS Defense Organizations today operate in an environment where Distributed Denial of Service (DDoS) attacks continue to evolve across both network and application layers. To help organizations build resilient, internet-facing applications and services, Microsoft Azure provides a comprehensive and layered set of protections designed to address different types of DDoS threats. These capabilities range from platform-level defenses through Azure Infrastructure Protection, dedicated Layer 3/4 DDoS mitigation through Azure DDOS Protection and application-layer protections through Azure Web Application Protection (WAF). Together, these services form a defense-in-depth strategy that helps organizations strengthen availability, improve resilience, and protect critical applications from both large-scale network attacks and sophisticated application-layer threats. This blog explores how these services work together to deliver comprehensive DDoS protection across modern cloud environments. Understanding DDoS at Different Layers: Network vs. Application Not all DDoS attacks are alike. Broadly speaking, network-layer (Layer 3/4) DDoS attacks try to flood a network or transport layer with traffic – for example, overwhelming a server or network connection with a massive volume of packets (think UDP floods, SYN floods, or amplification attacks). These aim to saturate the available bandwidth or crash network devices, knocking entire services offline. On the other hand, application-layer (Layer 7) DDoS attacks strike at the application itself – typically using HTTP(S) requests that appear legitimate but are maliciously crafted. For instance, a botnet might repeatedly hit a search API or login page with valid-looking requests that each trigger expensive operations (database queries, authentication processes, etc.). In short, network-layer DDoS attacks target the plumbing of your infrastructure (bandwidth, network connectivity), whereas application-layer DDoS attacks target the brains of your application (the code and logic handling requests). Because these attack vectors are different, defending against them requires different tools and tactics. Azure’s approach to DDoS defense embraces this reality with a layered model, where each security layer specializes in stopping certain types of attacks and complements the others. Azure’s multi-layered DDoS Protection Strategy Azure provides three main layers of DDoS protection: Azure’s Infrastructure DDoS Protection (Platform Protection) Azure DDoS Protection (Network Protection for customers’ resources) Azure Web Application Firewall (WAF) (App Protection) Let’s explore each layer and how they work together. Azure DDoS Infrastructure Protection (Always-On Baseline) All of the Azure Platform and shared services, automatically benefit from Azure’s built-in DDoS infrastructure protection. Think of this as Azure’s global, always-on “baseline” DDoS defense. It continuously monitors traffic across the Azure network, and if a massive DDoS campaign tries to bring down Azure’s infrastructure or a customer’s public endpoint, Azure will detect and absorb the malicious traffic at the platform level. This baseline protection uses Azure’s global network capacity to scrub much of the unwanted traffic before it ever reaches your resources. There’s no extra cost or configuration needed for this default protection. It’s a fundamental safety net that ensures Azure services (including multi-tenant services like Azure DNS) are not easily taken offline by large-scale DDoS events. However, the platform-level protection is designed primarily to protect Azure’s overall infrastructure and does not provide fine-grained controls or visibility for individual customers. That’s where Azure’s next layer comes in. Azure DDoS Protection: Shielding the Network (L3/L4) To safeguard your own internet-facing resources and workloads against network-layer DDoS attacks beyond the default baseline, Azure offers L3/L4 DDoS Protection (DDoS Network Protection and DDoS IP Protection) against volumetric floods. This is an opt-in service you configure for your Virtual Network or specific Public IP resources. Azure DDoS Protection is purpose-built to handle the classic L3/L4 DDoS scenarios: large volumetric floods, protocol attacks, and other network-level exploits like reflection or amplification attacks. A key benefit of Azure DDoS Protection is its adaptive tuning feature alongside the telemetry it provides. During peacetime, the service establishes a baseline of normal traffic behavior for your services and continuously updates that baseline to reflect changing patterns. When traffic deviates from that baseline and an attack is detected, mitigation is triggered automatically to block or absorb malicious traffic while minimizing false positives. Another important aspect of Azure DDoS Protection is visibility and response capabilities. The service provides detailed metrics, alerts, and attack analytics during and after an event, so your teams can understand what happened. Azure DDoS Network Protection plan also includes support from Azure’s DDoS Rapid Response (DRR) team and offers a cost protection guarantee – credits to offset any unexpected Azure scale-out costs that result from a documented DDoS attack. In short, Azure DDoS Protection is your dedicated shield at the network layer. It's worthwhile to note that Azure DDOS Protection goes beyond just blunt filtering; it employs multiple mitigation techniques like dropping illegitimate packets (for instance, filtering out spoofed source IPs or malformed packets), DDoS booters (e.g. DDoS-for-hire services), protocol compliance checks, and intelligent rate limiting as a last resort. It further employs multiple policies with varied thresholds each for UDP, TCP and TCP SYN due to the nature of attacks for these protocols. The goal is to scrub out the attack traffic while letting legitimate users continue to reach your services with minimal disruption. Azure WAF: Guarding Applications at the HTTP Layer (L7) Azure DDoS Protection defends against network-level floods and protocol exploits, but application-layer attacks like HTTP request floods require separate L7 protection with WAF. Azure WAF is deployed on services like Azure Application Gateway, Azure Front Door and Azure Gateway for Containers to inspect incoming HTTP(S) requests to your web applications. WAF’s primary role is to block common web exploits (e.g., SQL injections, cross-site scripting) via managed rule sets, rate Limit traffic using its Custom Rules as well as providing protection from malicious bots using its Bot Ruleset. Now, Azure WAF also includes the HTTP DDOS Ruleset to protect against application-level DDoS attacks. HTTP DDOS Ruleset is a new adaptive ruleset (currently in public preview for Application Gateway and Front Door services) that uses machine learning to dynamically learn normal HTTP traffic patterns for your application and automatically identify unusual surges in requests. If a burst of traffic appears malicious (for example, a sudden wave of requests to an expensive API call), the WAF can selectively block offending clients by placing them in a temporary “penalty box” without manual intervention. This dynamic approach goes beyond static thresholds, adjusting to your app’s normal load profiles. Along with that, adding the existing approaches such as custom rate limiting that lets you define granular thresholds for incoming requests on specific paths or for specific clients will further enhance the protection against DDOS attacks. For instance, you might limit a single IP to a certain number of login attempts per minute or cap the request rate to an expensive search endpoint. Rate limiting ensures that even if an attacker tries to slowly overwhelm your application with a moderate stream of requests (under the radar of network DDoS detection), WAF can throttle or block them at the application entry point. JavaScript challenges and CAPTCHA-based validation can also serve as effective protection mechanisms against automated bot traffic. These techniques help distinguish legitimate users from non-human clients by requiring the requester to successfully execute browser-based checks or complete a human verification step, making them useful for reducing unwanted bot activity such as scraping, credential stuffing, and abusive request automation. Further, the Bot Protection ruleset that includes integration of Microsoft’s threat intelligence to identify known malicious bot networks automatically block bad bots. Microsoft Threat Intelligence feeds continuously update the list of dangerous bot IPs and prevents these bots from consuming your application’s resources. This is especially useful against DDoS scenarios carried out by automated botnets that have known fingerprints. Together these capabilities enable Azure WAF to act as a critical inner layer of DDoS defense in front of your applications (via an Application Gateway or Front Door). Azure WAF focuses on application-specific attacks, and it can discern whether a burst of requests to your app is likely malicious based on patterns and behavior, not just volume. Combined with network-level DDoS protection, WAF ensures that even low-bandwidth but high-impact attacks (like repeated login attempts or bot-driven scraping) are mitigated. Layered DDOS Protection: Azure’s DDoS strategy is best imagined as a series of concentric rings around your application. The outermost ring is the platform’s infrastructure DDoS protection (automatically absorbing massive network floods aimed at Azure at large). The next ring is Azure DDoS Protection for your environment, which provides dedicated L3/L4 defenses with tuning and telemetry – it will handle the heavy lifting against volumetric and protocol attacks targeted at your specific resources. The next ring inward is your Azure WAF (with its HTTP DDoS ruleset, rate limiting, and bot controls enabled) catching the application-layer anomalies that network defenses can’t see. And finally, the innermost ring might be endpoint-specific configurations or app-level controls (like strict rate limits on crucial API operations or even adaptive app logic) that protect the most sensitive parts of your application from abuse. This layered approach is essential. Each layer addresses different threat vectors and failure modes; together they fill the gaps and provide a robust, end-to-end DDoS mitigation strategy. Quick Comparison: Azure DDoS Protection vs Azure WAF Note: This comparison focuses on Azure DDoS Protection and Azure WAF because they are the paid offerings; Azure DDoS Infrastructure Protection is included by default. To crystallize the differences and synergy between these services, here’s a quick side-by-side comparison of Azure DDoS Protection (Network level) and Azure WAF (Application level) in the context of DDoS defense: Service Azure DDoS Protection (Network-Level) Azure WAF – Application (Layer 7) DDoS Protection Protection Layer Network (OSI Layers 3 & 4): Protects Internet facing resources in virtual networks. Application (OSI Layer 7): Protects web apps and APIs at the HTTP request layer. Protected Resource Internet facing resources in virtual networks. Web apps and API endpoints. Primary Purpose Shield against high-volume network floods (e.g. UDP/TCP floods, SYN floods, amplification attacks) that aim to overwhelm bandwidth or network resources. Ensures your Azure services stay reachable during massive DDoS assaults. Filter and stop malicious HTTP(S) traffic (e.g. HTTP GET/POST floods, bot-driven requests, slowloris attacks) that could exhaust your application’s compute resources. Keeps your web applications responsive even under targeted L7 attack patterns. How It Works Always-on network monitoring. Uses Azure’s global network to absorb and scrub malicious traffic before it reaches your resources. No per-app manual tuning needed – it profiles traffic and triggers mitigation when volumes exceed safe baselines. Employs adaptive techniques (drops spoofed packets, protocol checks, limits rate as last resort) to block attacks while letting legitimate traffic flow. Policy-driven rules integrated at the application edge (via Application Gateway or Front Door). Can rate-limit or block suspicious clients based on IP, behavior, or patterns. Includes managed rule sets for common web threats and a new adaptive HTTP DDoS managed ruleset that auto-learns normal behavior per app and blocks abnormal request surges (reducing need for manual emergency configuration). When to Use Ideal for any Azure resource exposed to the public internet. Especially critical for high-bandwidth endpoints (gaming servers, large websites, etc.) or anything that can’t risk downtime due to massive traffic floods. Typically enabled on Virtual Networks or specific public IP addresses. Essential for any internet-facing web application (websites, web services, REST APIs). Particularly important for applications with resource-intensive operations (e.g., login pages, search functionality) where even moderate traffic spikes can degrade service. Deployed via a WAF Policy on an Application Gateway or Front Door that fronts your app. Role in Defense-in-Depth Handles the “heavy lifting” against bulk traffic attacks at the network edge – drastically reduces attacking traffic volume before it can hit your servers. Prevents upstream network pipe saturation or crashes, ensuring your application gets a chance to handle legitimate user traffic. Provides a fine-grained, application-aware filter for attacks that get past network defenses. Targets “surgical” low-bandwidth attacks that hide within normal traffic patterns. Together with Azure DDoS Protection, WAF completes a full-stack DDoS defense, covering gaps that pure network protection would miss. Conclusion: The key takeaway is that modern DDoS defense is no longer about relying on a single control, but about applying defense-in-depth, the right protection at the right layer. With a layered approach that spans infrastructure, network, and application security, organizations are better positioned to preserve availability, protect user experience, and maintain business continuity even as DDoS attacks grow more sophisticated.Azure WAF Tuning for Web Applications
False positives occur when a Web Application Firewall (WAF) erroneously detects legitimate web traffic as malicious and subsequently denies access. For instance, an HTTP request that poses no threat may trigger WAF to classify it as an SQL injection attack due to how characters are passed through the request body, thereby causing the request to be rejected and denying access to the user. Find out in this post some examples to help reduce false positives in your Azure WAF environment.Public Preview: Managed Identity support for graphical session recording
Overview Azure Bastion provides secure RDP and SSH access to Azure virtual machines directly via the Azure portal or via the native SSH/RDP client already installed on your local computer. Today, we are introducing public preview for managed identity support for session recording, giving administrators a seamless, identity-based way to authenticate Bastion when writing recordings to a designated storage account. Why Managed Identities? With managed identity support, Bastion authenticates directly to your storage account using an Azure identity, no additional credentials to configure or manage. You can use either a system-assigned or user-assigned managed identity depending on your needs. Authentication is handled automatically through Microsoft Entra ID, which means setup is straightforward: enable the identity, assign a role, and point Bastion at your storage container. For organizations operating at scale across many Bastion deployments and regions, this identity-based approach removes the need to manage credentials, aligns with Zero Trust principles, and lets you control access centrally through Azure RBAC. Getting Started in Azure Portal Prerequisites Ensure that Azure Bastion is deployed with the Premium SKU Ensure that a storage account with a dedicated container for session recordings is created Ensure that the storage account has the required CORS policy configured. Click here to set up the storage account for session recordings Ensure that users who need to view recordings have the Storage Blob Data Reader role on the storage account Steps Navigate to your Bastion resource in the Azure portal. Select Identity (Preview) in the left pane and turn the Status to On to enable a system-assigned managed identity. Wait for the configuration to complete. Select Azure role assignments, then select Add role assignment (Preview). Assign the Storage Blob Data Contributor role scoped to your storage account. Select Save, then navigate to the Configuration blade. Under Session Recording Configuration, select System Assigned Managed Identity and enter the Blob Container URI for your storage container. Navigate to the Session recordings blade to view and play back recorded sessions. Next Steps Learn more about configuring session recording with managed identities here and keep up to date with all things Azure Bastion in our What's New page.General availability of Default Ruleset (DRS) 2.2 for Web Application Firewall
Introduction As attackers continue to evolve their techniques, organizations require web application security that keeps pace with emerging threats without disrupting legitimate traffic. Azure Web Application Firewall (WAF) continues to evolve to meet these demands and now supports Default Rule Set (DRS) 2.2 across both Azure Front Door and Azure Application Gateway. The latest recommended Azure WAF ruleset, based on OWASP Core Rule Set (CRS) 3.3.4., DRS 2.2 combines OWASP CRS protections with Microsoft-authored rules developed with the Microsoft Threat Intelligence team, delivering broader coverage, updated signatures, reduced false positives, and a more modern security baseline for your internet-facing applications. What is new in DRS 2.2? DRS 2.2 builds on earlier rule sets with improvements focused on three areas: breadth of coverage, quality of detections, and false positive reductions. Broader security coverage DRS 2.2 is based on the OWASP Core Rule Set 3.3.4, delivering improvements in rule accuracy and new protections for common web vulnerabilities. DRS 2.2 contains 18 rule groups, organizing protections across SQL injections, XSS, protocol violations, remote code execution, and more, making it easier to understand and manage the scope of coverage. Notable improvements include: Detection of mismatched content types, where the declared content-type header does not match the actual payload format. This is a common tactic in evasion and obfuscation attacks. Improved Remote Code Execution (RCE) detections to catch increasingly sophisticated payloads used by threat actors. Microsoft Threat Intelligence rules In addition to the OWASP improvements, DRS 2.2 introduces new Microsoft Threat Intelligence rules. These rules expand coverage for: SQL Injection. Cross-Site Scripting (XSS). Advanced application security attack patterns. Improved false positive reduction with paranoia levels One of the standout features of DRS 2.2 is its paranoia level (PL) configuration, which allows you to balance security and usability. Paranoia levels (PL) determine how aggressively rules in the OWASP Core Rule Set (CRS) detect and block potential threats in a Web Application Firewall (WAF). OWASP CRS defines four paranoia levels (PL1–PL4), each offering progressively stricter security controls: PL1 (Default): Offers baseline protection against common web attacks, minimizes false positives, and is appropriate for most applications. PL2: Adds additional rules targeting more sophisticated threats, which may result in more false positives. PL3: Strict detection rules aimed at high-security environments. PL4: Implements the most aggressive security rules, suitable for highly secure environments, requiring extensive management and tuning efforts. Azure WAF currently does not support rules from paranoia levels 3 and 4. For more information on Azure WAF paranoia levels refer to Paranoia Levels. DRS 2.2 ships with paranoia level 1 (PL1) enabled by default. This gives customers the strongest baseline protection with minimal tuning overhead. DRS 2.2 rules configured in paranoia level 2 are disabled by default. Customers can leave PL2 disabled or selectively enable individual PL2 rules based on their threat model and application behavior. Enabling and upgrading to DRS 2.2 Upgrading to DRS 2.2 is straightforward, but there is an important planning consideration: when you assign a new managed ruleset version through the Azure portal, previous managed-ruleset customizations such as rule state overrides, rule action overrides, and rule-level exclusions are reset to the new defaults. Due to this, it is recommended to use PowerShell, CLI, REST API, or templates when you want to preserve overrides and exclusions, and validating changes in a test environment before production rollout. Please refer to Upgrade CRS or DRS Ruleset Version - Azure Web Application Firewall. To use DRS 2.2: Open your WAF policy (associated with your Azure Front Door or Application Gateway). Navigate to Managed Rules. Select “Assign”. Choose DRS 2.2 from the ruleset dropdown. Review enabled rule groups and optionally configure the rule actions. After upgrading, monitor your logs and metrics to understand traffic behavior and fine-tune as required. Figure 1: Enabling DRS 2.2 in Azure Front Door WAF Figure 2: Enabling DRS 2.2 in Azure Front Door WAF Conclusion Default Rule Set 2.2 marks a significant advancement for Azure Web Application Firewall, providing stronger security coverage, improved detection accuracy, and better control over false positives. By bringing the same modern ruleset experience to both Azure Front Door WAF and Application Gateway WAF, customers can apply a consistent web security baseline across global, regional, and internal application architectures. For customers already using Azure WAF, upgrading to DRS 2.2 is the simplest way to benefit from the latest protections while maintaining operational flexibility. References Web Application Firewall (WAF) on Azure Front Door | Microsoft Learn Web Application Firewall on Azure Application Gateway | Microsoft Learn Azure Front Door WAF - DRS and CRS rule groups and rules | Microsoft Learn Azure Application Gateway WAF - DRS and CRS rule groups and rules Azure Front Door WAF - Default Ruleset 2.2 | Microsoft Learn Application Gateway WAF – Default Ruleset 2.2 | Microsoft Learn Upgrade CRS or DRS Ruleset Version - Azure Web Application Firewall | Microsoft LearnOrchestrating Intrusion Detection and Prevention Signature overrides in Azure Firewall Premium
Introduction: Azure Firewall Premium provides strong protection with a built-in Intrusion Detection and Prevention System (IDPS). It inspects inbound, outbound, and east-west traffic against Microsoft’s continuously updated signature set and can block threats before they reach your workloads. IDPS works out of the box without manual intervention. However, in many environments administrators need the flexibility to override specific signatures to better align with operational or security requirements. Common reasons include: Compliance enforcement – enforcing policies that require certain threats (such as High severity signatures) to always be blocked, directional tuning or protocol/category-based tuning. Incident response – reacting quickly to emerging vulnerabilities by enabling blocking for newly relevant signatures. Noise reduction – keeping informational signatures in alert mode to avoid false positives while still maintaining visibility. In many environments, signature overrides are typically managed in one of two ways: Using the global IDPS mode Using the Azure portal to apply per-signature overrides individually While these approaches work, managing overrides manually becomes difficult when thousands of signatures are involved. The Azure portal also limits the number of changes that can be applied at once, which makes large tuning operations time-consuming. To simplify this process, this blog introduces an automation approach that allows you to export, filter, and apply IDPS signature overrides in bulk using PowerShell scripts. A Common Operational Scenario: Consider the following scenario frequently encountered by security teams: Scenario A security team wants to move their firewall from Alert → Alert + Deny globally to strengthen threat prevention. However, they do not want Low severity signatures to Deny traffic, because these signatures are primarily informational and may create unnecessary noise or false positives. Example: Signature ID: 2014906 Severity: Low Description: INFO – .exe File requested over FTP This signature is classified as informational because requesting an .exe file over FTP indicates contextual risk, not necessarily confirmed malicious activity. If the global mode is switched to Alert + Deny, this signature may start blocking traffic unnecessarily. The goal therefore becomes: Enable Alert + Deny globally Keep Low severity signatures in Alert mode The workflow described in this blog demonstrates how to achieve this outcome using the IDPS Override script. Automation Workflow: The automation process uses two scripts to export and update signatures. Workflow overview Azure Firewall Policy │ ▼ Export Signatures (ipssigs.ps1) │ ▼ CSV Review / Edit │ ▼ Bulk Update (ipssigupdate.ps1) │ ▼ Updated Firewall Policy Before implementing the workflow, it’s helpful to review the available IDPS modes and severity as seen below, very briefly. IDPS Modes: Severity: Prerequisites: Now that we understand Azure Firewall IDPS concepts and have the context for this script, let's get started with the workings of the script itself. First of all, let us ensure that you are connected to your Azure account and have selected the correct subscription. You can do so by running the following command: Connect-AzAccount -Subscription "<your-subscription-id>" Ensure the following modules are installed which are required for this operation: Az.Accounts Az.Network 💡 Tip: You can check if the above modules are installed by running the following command: Get-Module -ListAvailable Az* or check specific modules using this following commands: Get-module Az.Network | select Name, Version, Path Get-module Az.Accounts | select Name, Version, Path If you need to install/import them, run the following command which downloads all generally available Azure service modules from the PowerShell Gallery, overwriting existing versions without prompting: Import-Module Az.Network Import-Module Az.Accounts Restart PowerShell after installation. Configure ipsconfig.json Now, let's configure the ipsconfig.json file and ensure the configuration file contains your target environment details i.e., target subscription, target firewall policy resource group name, firewall name, firewall policy name, location and rule collection group name. Example: { "subs": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx", "rg": "TEST-RG", "fw": "fw", "fwp": "fw-policy", "location": "CentralUS", "rcg": "DefaultNetworkRuleCollectionGroup" } Note: Your account must have permissions to read and update firewall policy and IDPS settings. Running the Script: 1. Export Signatures Now that we have all the prerequisites ready, it's time to run the script. Run the following command in PS in the directory where the script exists: .\ipssigs.ps1 Now, the script should prompt for filtering criteria as shown below and you can input the values as per your requirements: For the example scenario that we considered, we will give the following inputs as shown above in the snapshot: Mode: Alert Severity: Low 💡 Tip: When specifying multiple values, ensure there is space between the 2 values but no comma, otherwise the script may return no results. The script now exports the results to ipssignatures_results.csv file by default (or a custom filename if specified). The exported CSV includes metadata such as severity, direction, group, and protocol, which can help inform tuning decisions. 2. Prepare the CSV Now, we do not need all of these columns when inputting the CSV file to update the Firewall Policy. We only need the following columns. Signature Id Mode Therefore, we will need to remove all other columns while keeping the SignatureId and mode columns along with their headers as seen below: 3. Update the Firewall Policy Now, it's time to update the Firewall Policy with the signature/mode overrides that we need using the above CSV file. However, please note that the script supports two operations: Changing the global IDPS mode Applying bulk signature overrides using the CSV file You can use either option independently or both together. Let's understand this further by looking at these 2 examples. Example 1: Change Global Mode and Override Low Severity Signatures Goal: Set global mode to Alert + Deny Keep Low severity signatures in Alert Command: .\ipssigupdate.ps1 -GlobalMode Deny -InputFile Lowseveritysignatures.csv Result: High and Medium signatures → Alert + Deny Low signatures → Alert Example 2: Override Signatures Only If the global mode should remain unchanged, then run the following command only. .\ipssigupdate.ps1 The script will then prompt for the input CSV file in the next step as seen below: As seen the changed were made to the Azure Firewall in just a few seconds. After the script completes, updated signature actions should appear in the firewall policy. 4. Monitoring Script Execution Please use the following commands to track and monitor the background processes, to verify the status, check for any error and remove completed jobs as seen below: You can check background job status using: Get-Job -Id <#> View results: Receive-Job -Id <#> -Keep Remove completed jobs: Remove-Job -Id <#> Note: Up to 10,000 IDPS rules can be customized at a time 5. Validate the Changes: Now that we finished running the script, it's time to verify the update by confirming: Global IDPS mode in the firewall policy Signature override state Alert or block events in your logging destination (Log Analytics or Microsoft Sentinel) Note: Please note that, while most signatures support Off, Alert, or Deny actions, there are some context-setting signatures, that have fixed actions and cannot be overridden. Conclusion: Azure Firewall Premium makes it straightforward to apply broad IDPS configuration changes through the Azure portal. However, as environments scale, administrators often require more precise and repeatable ways to manage signature tuning. The automation approach described in this blog allows administrators to query, review, and update thousands of signatures in minutes. This enables repeatable tuning workflows, improves operational efficiency, and simplifies large-scale security configuration changes. References: Github Repository for the IDPS scripts Azure Firewall IDPS Azure Firewall IDPS signature rule categoriesAssess Azure DDoS Protection Status Across Your Environment
Introduction Distributed Denial of Service (DDoS) attacks continue to be one of the most prevalent threats facing organizations with internet-facing workloads. Azure DDoS Protection provides cloud-scale protection against L3/4 volumetric attacks, helping ensure your applications remain available during an attack. However, as Azure environments grow, maintaining visibility into which resources are protected and whether diagnostic logging is properly configured becomes increasingly challenging. Security teams often struggle to answer basic questions: Which Public IP addresses are protected by Azure DDoS Protection? Are we using IP Protection or Network Protection (DDoS Protection Plan)? Is diagnostic logging enabled for protected resources? To address these questions at scale, we’ve developed a PowerShell script that assesses your Azure DDoS Protection posture across all subscriptions. Understanding Azure DDoS Protection SKUs Azure offers three DDoS Protection tiers: Protection Type Description Scope Network Protection Enterprise-grade protection via a DDoS Protection Plan attached to VNETs All Public IPs in protected VNETs IP Protection Per-IP protection for individual Public IP addresses Individual Public IP For more details, see Azure DDoS Protection overview. The Assessment Script The Check-DDoSProtection.ps1 script provides a full view of DDoS Protection status across your Azure environment. This section covers the script’s key capabilities and the resource types it supports. Key Features Multi-subscription support: Scan a single subscription or all subscriptions you have access to DDoS Protection status: Identifies which Public IPs are protected and which SKU is being used VNET correlation: Automatically determines the VNET associated with each Public IP to assess Network Protection inheritance Diagnostic logging check: Verifies if DDoS diagnostic logs are configured for protected resources CSV export: Export results for further analysis or reporting Prerequisites Before running the script, ensure you have: Azure PowerShell modules installed: Run the following commands in PowerShell (version 5.1+) or PowerShell Core to install the required Azure modules. No special permissions are needed, these will install in your user profile. Install-Module -Name Az.Accounts -Scope CurrentUser -Force Install-Module -Name Az.Network -Scope CurrentUser -Force Install-Module -Name Az.Monitor -Scope CurrentUser -Force Appropriate Azure permissions: o Reader role on subscriptions you want to scan o Microsoft.Network/publicIPAddresses/read o Microsoft.Network/virtualNetworks/read o Microsoft.Insights/diagnosticSettings/read Azure login: Authenticate to Azure before running the script. This opens a browser window for interactive sign-in. Connect-AzAccount How to Use the Script Run the script from a PowerShell session where you’ve already authenticated with Connect-AzAccount. The account must have Reader role on the subscriptions you want to scan. Download the Script You can download the script from: - GitHub: Check-DDoSProtection.ps1 Basic Usage: Scan Current Subscription Scans only the subscription currently selected in your Azure context. .\Check-DDoSProtection.ps1 Scan a Specific Subscription Scans a single subscription by its ID. .\Check-DDoSProtection.ps1 -SubscriptionId "12345678-1234-1234-1234-123456789012" Scan All Subscriptions Scans every subscription your account has Reader access to. .\Check-DDoSProtection.ps1 -AllSubscriptions Export Results to CSV Exports the assessment results to a CSV file for reporting or further analysis. .\Check-DDoSProtection.ps1 -AllSubscriptions -ExportPath "C:\Reports\DDoS-Report.csv" Large Environment Options For organizations with many subscriptions or thousands of Public IPs, use the following parameters to handle errors gracefully and avoid API throttling. .\Check-DDoSProtection.ps1 -AllSubscriptions ` -ContinueOnError ` -SavePerSubscription ` -ExportPath "C:\Reports\DDoS-Report.csv" ` -ThrottleDelayMs 200 Parameters for large environments: Parameter Description -ContinueOnError Continue scanning even if a subscription fails (e.g., access denied) -SavePerSubscription Save a separate CSV file for each subscription -ThrottleDelayMs Delay between API calls to avoid throttling (default: 100ms) Understanding the Output The script provides both console output and optional CSV export. This section covers what each output type contains. Console Output The script displays a summary table for each subscription: Summary Statistics At the end of each subscription scan: CSV Export Columns Column Description Subscription Name of the Azure subscription Public IP Name Name of the Public IP resource Resource Group Resource group containing the Public IP Location Azure region IP Address Actual IP address (or “Dynamic” if not allocated) IP SKU Basic or Standard DDoS Protected Yes/No Risk Level High (unprotected) / Low (protected) DDoS SKU Network Protection, IP Protection, or None DDoS Plan Name Name of the DDoS Protection Plan (if applicable) VNET Name Associated Virtual Network name Associated Resource Resource the Public IP is attached to Resource Type Type of associated resource (VM, AppGw, LB, etc.) Diagnostic Logging Configured/Not Configured/N/A Log Destination Log Analytics, Storage, Event Hub, or None Recommendation Suggested action for unprotected resources Sample Scenarios Scenario 1: Protected Application Gateway Public IP Name: appgw-frontend-pip DDoS Protected: Yes DDoS SKU: Network Protection DDoS Plan Name: contoso-ddos-plan VNET Name: production-vnet Diagnostic Logging: Configured (Log Analytics) Risk Level: Low Explanation: The Application Gateway’s Public IP inherits protection from the VNET which has a DDoS Protection Plan attached. Diagnostic logging is properly configured. Scenario 2: Unprotected External Load Balancer Public IP Name: external-lb-pip DDoS Protected: No DDoS SKU: VNET not protected VNET Name: (External LB) Diagnostic Logging: N/A Risk Level: High Recommendation: Enable DDoS Protection on associated VNET or enable IP Protection Explanation: This external Load Balancer’s Public IP is not in a protected VNET. The script flags this as high risk. Scenario 3: IP Protection Without Logging Public IP Name: standalone-api-pip DDoS Protected: Yes DDoS SKU: IP Protection VNET Name: - Diagnostic Logging: Not Configured Risk Level: Low Recommendation: Configure diagnostic logging for DDoS-protected resources Explanation: The IP has IP Protection enabled, but diagnostic logging is not configured. While protected, you won’t have visibility into attack telemetry. Troubleshooting Script Doesn’t Find All Subscriptions Use the following command to list your Azure role assignments and verify you have Reader access to the target subscriptions. Run this from Azure Cloud Shell or a local PowerShell session after authenticating with Connect-AzAccount. # Check your role assignments Get-AzRoleAssignment -SignInName (Get-AzContext).Account.Id | Select-Object Scope, RoleDefinitionName API Throttling The script includes built-in retry logic for API throttling. If you still experience rate limit errors, increase the delay between API calls. Run this from the directory containing the script. .\Check-DDoSProtection.ps1 -AllSubscriptions -ThrottleDelayMs 500 Access Denied for Specific Resources The script displays “(Access Denied)” for VNETs or resources you don’t have permission to read. This doesn’t affect the overall assessment but may result in incomplete VNET information. Summary This guide covered how to use the Check-DDoSProtection.ps1 script to identify unprotected Public IP addresses, determine which DDoS SKU (Network Protection vs. IP Protection) is in use, verify diagnostic logging configuration, and assess risk levels across all subscriptions. Running this script periodically helps security teams track protection coverage as their Azure environment evolves. Related Resources Azure DDoS Protection Overview Azure DDoS Protection SKU Comparison Configure DDoS Protection Diagnostic Logging Best Practices for Azure DDoS Protection Zero Trust with Azure DDoS Protection
Detect, correlate, contain: New Azure Firewall IDPS detections in Microsoft Sentinel and XDR
As threat actors continue to blend reconnaissance, exploitation, and post-compromise activity, network-level signals remain critical for early detection and correlated response. To strengthen this layer, we're introducing five new Azure Firewall IDPS detections, now available out of the box in the Azure Firewall solution for Microsoft Sentinel and Microsoft Defender XDR. See It in Action This short demo walks through Azure Firewall's IDPS capabilities, the new Sentinel detections, and the automated response playbook — from malicious traffic hitting the firewall to the threat being contained without manual intervention. Watch the demo → Azure Firewall integration with Microsoft Sentinel and Defender XDR Read on for the full details on each detection, customization options, and a step-by-step walkthrough of the automated response workflow. What’s new The Azure Firewall solution now includes five new analytic detections built on Azure Firewall. Detection name What it detects (network signal) MITRE ATT&CK tactic(s) Example ATT&CK techniques (representative) SOC impact High severity malicious activity Repeated high confidence IDPS hits such as exploit kits, malware C2, credential theft, trojans, shellcode delivery Initial access (TA0001) execution (TA0002) Command and Control (TA0011) Exploit public facing application (T1190) command and control over web protocols (T1071.001) Ingress Tool Transfer (T1105) Highlights active exploitation or post compromise behavior at the network layer; strong pivot point into XDR investigations Elevation of privilege attempt Repeated attempts or success gaining user or administrator privileges Privilege escalation (TA0004) Exploitation for privilege escalation (T1068) Flags critical inflection points where attackers move from foothold to higher impact control Web application attack Probing or exploitation attempts against web applications Initial access (TA0001) Exploit public facing application (T1190) Surfaces external attack pressure against internet facing apps protected by Azure Firewall Medium severity malicious activity Potentially unwanted programs, crypto mining, social engineering indicators, suspicious filenames/system calls Initial access (TA0001) execution (TA0002) impact (TA0040) User Execution (T1204) Resource Hijacking (T1496) Early stage or lower confidence signals that help teams hunt, monitor, and tune response before escalation Denial of Service (DoS) attack Attempted or sustained denial of service traffic patterns Impact (TA0040) Network Denial of Service (T1498) Enables faster DoS identification and escalation, reducing time to mitigation Where these detections apply These detections are available through the Azure Firewall solution in: Microsoft Sentinel, enabling SOC centric investigation, hunting, and automation Microsoft Defender XDR, allowing network level signals to participate in end-to-end attack correlation across identity, endpoint, cloud, and email They are powered by the AZFWIdpsSignature log table and require Azure Firewall with IDPS enabled (preferably with TLS inspection). Customizing the detections to fit your environment The Azure Firewall IDPS detections included in the Microsoft Sentinel solution are designed to be fully adaptable to customer environments, allowing SOC teams to tune sensitivity, scope, and signal fidelity based on their risk tolerance and operational maturity. Each detection is built on the AZFWIdpsSignature log table and exposes several clearly defined parameters that customers can modify without rewriting the analytic logic. 1. Tune alert sensitivity and time horizon Customers can adjust the lookback period (TimeWindow) and minimum hit count (HitThreshold) to control how aggressively the detection triggers. Shorter windows and lower thresholds surface faster alerts for high-risk environments, while longer windows and higher thresholds help reduce noise in high volume networks. 2. Align severity with internal risk models Each analytic rule includes a configurable minimum severity (MinSeverity) aligned to Azure Firewall IDPS severity scoring. Organizations can raise or lower this value to match internal incident classification standards and escalation policies. 3. Focus on relevant threat categories and behaviors Optional filters allow detections to be scoped to specific threat categories, descriptions, or enforcement actions. Customers can enable or disable: Category filtering to focus on specific attack classes (for example, command and control, exploit kits, denial of service, or privilege escalation). Description filtering to target specific behavioral patterns. Action filtering to alert only on denied or alerted traffic versus purely observed activity. This flexibility makes it easy to tailor detections for different deployment scenarios such as internet facing workloads, internal east-west traffic monitoring, or regulated environments with stricter alerting requirements. 4. Preserve structure while customizing output Even with customization, the detections retain consistent enrichment fields including source IP, threat category, hit count, severity, actions taken, and signature IDs ensuring alerts remain actionable and easy to correlate across Microsoft Sentinel and Microsoft Defender XDR workflows. By allowing customers to tune thresholds, scope, and focus areas while preserving analytic intent, these Azure Firewall IDPS detections provide a strong out of the box baseline that can evolve alongside an organization’s threat landscape and SOC maturity. Automated detection and response for Azure Firewall using Microsoft Sentinel In this walkthrough, we’ll follow a real-world attack simulation and see how Azure Firewall, Microsoft Sentinel, and an automated playbook work together to detect, respond to, and contain malicious activity, without manual intervention. Step 1: Malicious traffic originates from a compromised source A source IP address 10.0.100.20, hosted within a virtual network, attempts to reach a web application protected by Azure Firewall. To validate the scenario, we intentionally generate malicious outbound traffic from this source, such as payloads that match known attack patterns. This is an outbound flow, meaning the traffic is leaving the internal network and attempting to reach an external destination through Azure Firewall. At this stage: Azure Firewall is acting as the central enforcement point Traffic is still allowed, but deep packet inspection is in effect Step 2: Azure Firewall IDPS detects malicious behavior Azure Firewall's intrusion detection and prevention system (IDPS) is enabled and inspects traffic as it passes through the firewall. When IDPS detects patterns that match known malicious signatures, the action taken depends on the signature's configured mode: Alert mode: IDPS generates a detailed security log for the matched signature but allows the traffic to continue. This is useful for monitoring and tuning before enforcing blocks. Alert and Deny mode: IDPS blocks the matching traffic and generates a detailed security log. The threat is stopped at the network layer while full telemetry is preserved for investigation. In both cases, IDPS records rich metadata including source IP, destination, protocol, signature name, severity, and threat category. These logs are what power the downstream detections in Microsoft Sentinel. In this walkthrough, the signature is configured in Alert and Deny mode, meaning the malicious traffic from 10.0.100.20 is blocked immediately at the firewall while the corresponding log is forwarded for analysis. Step 3: Firewall logs are sent to Log Analytics All Azure Firewall logs, including IDPS logs, are sent to a Log Analytics workspace named law-cxeinstance. At this point: Firewall logs are centralized Logs are normalized and can be queried No alerting has happened yet, only data collection This workspace becomes the single source of truth for downstream analytics and detections. Step 4: Microsoft Sentinel ingests and analyzes the Firewall logs The Log Analytics workspace is connected to Microsoft Sentinel, which continuously analyzes incoming data. Using the Azure Firewall solution from the Sentinel Content Hub, we previously deployed a set of built-in analytic rule templates designed specifically for Firewall telemetry. One of these rules is: “High severity malicious activity detected”. This rule evaluates IDPS logs and looks for: High-confidence signatures, known exploit techniques and malicious categories identified by Firewall IDPS. Step 5: Sentinel creates an incident When the analytic rules are met, Microsoft Sentinel automatically: Raises an alert Groups related alerts into an incident Extracts entities such as IP addresses, severity, and evidence In this case, the source IP 10.0.100.20 is clearly identified as the malicious actor and attached as an IP entity to the incident. This marks the transition from detection to response. Step 6: An automation rule triggers the playbook To avoid manual response, we configured a Sentinel automation rule that triggers whenever: An incident is created The analytic rule name matches any of the analytic rules we configured The automation rule immediately triggers a Logic App playbook named AzureFirewallBlockIPaddToIPGroup. This playbook is available as part of the Azure Firewall solution and can be deployed directly from the solution package. In addition, a simplified version of the playbook is published in our GitHub repository, allowing you to deploy it directly to your resource group using the provided ARM template. This is where automated containment begins. Step 7: The playbook aggregates and updates the IP Group The playbook performs several critical actions in sequence: Extracts IP entities from the Sentinel incident Retrieves the existing Azure Firewall IP Group named MaliciousIPs Checks for duplicates to avoid unnecessary updates Aggregates new IPs into a single array/list Updates the IP Group in a single operation. It is important to note that the playbook managed identity should have contributor access on the IP Group or its resource group to perform this action. In our scenario, the IP 10.0.100.20 is added to the MaliciousIPs IP Group. Step 8: Firewall policy enforces the block immediately Azure Firewall already has a network rule named BlockMaliciousTraffic configured with: Source: MaliciousIPs IP Group Destination: Any Protocol: Any Action: Deny Because the rule references the IP Group dynamically, the moment the playbook updates MaliciousIPs, the firewall enforcement takes effect instantly — without modifying the rule itself. Traffic originating from 10.0.100.20 is now fully blocked, preventing any further probing or communication with the destination. The threat has been effectively contained. When a SOC analyst opens the Sentinel incident, they see that containment has already occurred: the malicious IP was identified, the IP Group was updated, and the firewall block is in effect — all with a full audit trail of every automated action taken, from detection through response. No manual intervention was required. Conclusion With these five new IDPS detections, Azure Firewall closes the gap between network-level signal and SOC-level action. Raw signature telemetry is automatically transformed into severity-aware, MITRE ATT&CK-mapped alerts inside Microsoft Sentinel and Microsoft Defender XDR — giving security teams correlated, investigation-ready incidents instead of isolated log entries. Combined with automation playbooks, the result is a fully integrated detect-and-respond workflow: Azure Firewall identifies malicious behavior, Sentinel raises and enriches the incident, and a Logic App playbook contains the threat by updating firewall policy in real time — all without manual intervention. These detections are included at no additional cost. Simply install the Azure Firewall solution from the Microsoft Sentinel Content Hub, and the analytic rules automatically appear in your Sentinel workspace — ready to enable, customize, and operationalize. Get started today: Azure Firewall with Microsoft Sentinel overview Automate Threat Response with Playbooks in Microsoft Sentinel Azure Firewall Premium features implementation guide Recent real‑world breaches underscore why these detections matter. Over the past year, attackers have repeatedly gained initial access by exploiting public‑facing applications, followed by command‑and‑control activity, web shell deployment, cryptomining, and denial‑of‑service attacks. Incidents such as the GoAnywhere MFT exploitation, widespread web‑application intrusions observed by Cisco Talos, and large‑scale cryptomining campaigns against exposed cloud services demonstrate the value of correlating repeated network‑level malicious signals. The new Azure Firewall IDPS detections are designed to surface these patterns early, reduce alert noise, and feed high‑confidence network signals directly into Microsoft Sentinel and Microsoft Defender XDR for faster investigation and response. Your network telemetry is a first-class security signal - let it work for you! Visit us at RSA 2026 to see the full detection-to-containment workflow live.Azure Bastion: Enterprise-grade secure access made simple
Managing secure remote access to virtual machines traditionally means juggling public IP addresses, configuring jump boxes, deploying VPN infrastructure, and managing complex firewall rules. Each layer adds cost, complexity, and potential security vulnerabilities. Azure Bastion changes everything. It's a fully managed PaaS service that provides secure RDP/SSH connectivity to Azure VMs directly through the Azure portal, without exposing VMs to the public internet. No public IPs, no jump boxes, no VPN clients. Azure Bastion isn't one-size-fits-all. Whether you're running a development sandbox, managing production workloads at scale, or operating in regulated industries with strict compliance requirements, there's a Bastion SKU designed for your specific needs. Basic SKU for small production workloads with browser-based access. Ideal for small businesses, startups, or single-application environments with limited concurrent users (up to 2 instances). Standard SKU for scalable production environments requiring VNet peering, native client and shareable links for non-portal access. Supports up to 50 scale units, perfect for growing organizations and multi-VNET architectures. Premium SKU for regulated industries requiring session recording for compliance (HIPAA, SOX, PCI-DSS, FDA), private-only deployment for zero internet exposure. Essential for healthcare, finance, pharmaceuticals, government, and air-gapped environments. Let's dive into real-world scenarios that showcase how Azure Bastion simplifies enterprise-grade secure access. Real-World Scenarios: Azure Bastion features are best understood through real-world application. In the scenarios below, we'll tackle three common enterprise challenges with remote secure access. Let's see Azure Bastion in action. Scenario 1: Instant Vendor Access Without the Hassle The Challenge: It's 3 PM on Friday when your production database experiences critical performance issues. An external DBA consultant needs immediate access to investigate, but your organization faces a familiar dilemma. The traditional provisioning process requires creating a temporary Azure AD account, configuring VPN access and credentials, coordinating with the security team for approvals, and ensuring timely revocation after the engagement concludes. Even with expedited processes, this takes 2-3 hours—and there's always the risk of lingering permissions if revocation is overlooked. By the time access is provisioned, it's often too late to resolve the issue before the weekend, leaving your production environment vulnerable and your team working overtime. The Solution: Shareable Links: Generate a secure URL for instant VM access: no Azure credentials, no VPN, no account creation is required. Implementation: Step 1: Enable Shareable Links Navigate to Bastion → Configuration → Toggle Shareable Link to Enabled → Click Apply Step 2: Generate Link Go to Bastion → Select Shareable Links → Add → Choose VM→ Apply →Copy generated URL Step 3: Share & Monitor Share URL securely with vendor → Vendor connects via browser using VM credentials Monitor active sessions in Bastion → Shareable Links Real World Impact: A global financial services firm now grants emergency vendor access in under 5 minutes instead of 2-3 hours, with zero IT overhead for account provisioning or VPN setup. Links can be revoked after the set duration, eliminating lingering access risks. Every vendor session is logged, providing complete audit trails that satisfy SOX and PCI-DSS compliance requirements without additional administrative effort. Scenario 2: Comprehensive Compliance with Session Recording The Challenge: Your healthcare organization operates under HIPAA regulations, which mandate comprehensive audit trails of all administrative access to systems containing Protected Health Information (PHI). Traditional text logs capture what was accessed, but not what actions were performed—and they're difficult to analyze during audits. You need indisputable video evidence of administrative activities with secure 7-year retention. The Solution: Graphical Session Recording: Azure Bastion Premium's Session Recording feature automatically captures every RDP and SSH session as a video recording, stored securely in Azure Storage with immutable retention policies. Implementation: Step 1: Prepare Storage Account Create a dedicated storage account with blob versioning, lifecycle management (7 years for HIPAA), soft delete (90 days), and RBAC restricted to security/compliance team. Also make sure there is a dedicated container created for Bastion Sessions and CORS policy configured on the storage account to allow your bastion. Step 2: Enable Session Recording Navigate to Bastion → Configuration → Toggle Session Recording to Enabled → Apply Add/Update the SAS URL of the storage account in the Session Recordings blade of Bastion for the recordings to be stored in the specified storage account. Step 3: Connect as Usual Administrators connect through Azure portal normally: VM → Connect → Bastion → Enter credentials → Connect Every session is automatically recorded—no extra steps for users. Step 4: Review Recordings Security teams access recordings from the Session Recordings blade on Azure Bastion which will retrieve data from the configured Storage Account. Real World Impact: A healthcare provider with 50+ hospitals now maintains 100% HIPAA-compliant audit trails of all administrative access to PHI systems through automated video recordings. The organization reduced audit preparation time by 75%, as compliance teams can quickly review specific sessions instead of analyzing thousands of text log entries. Session recordings have enabled post-incident investigations to identify unauthorized configuration changes and provide indisputable video evidence for security reviews and regulatory audits. Scenario 3: Zero Internet Exposure with Private-Only Deployment The Challenge: A global pharmaceutical company developing cancer treatments operates under FDA regulations requiring zero internet exposure for drug development systems. Their security mandate: no public IP addresses on production infrastructure, complete air-gapped connectivity to protect intellectual property, and administrative access from corporate network only. Traditional Azure Bastion requires a public IP address—violating their zero-trust security policy. The Solution: Private-Only Bastion: Azure Bastion Premium's private-only deployment eliminates the public IP address entirely. All connectivity flows through your org’s configured Express Route, S2S or P2S connectivity for complete air-gapped operations. Implementation: Select Azure Bastion Premium SKU and Deploy Private-Only Bastion Configure Private Connectivity from On Prem using your orgs preferred way of connectivity Connect from Corporate Network using Private IP address of the Bastion Deployment Real-World Impact A pharmaceutical company with 20+ research facilities deploys private-only Bastion for FDA-regulated drug development systems. The company now achieves complete air-gapped operations with zero internet endpoints while maintaining centralized access management for 200+ researchers across global facilities. Research teams connect securely via ExpressRoute with all administrative sessions network-isolated, FDA compliance audits confirm 100% of connections originate from corporate private networks, and the organization eliminated $2M in annual costs by decommissioning internet-isolated jump boxes. Conclusion: Azure Bastion transforms the traditional trade-off between security and operational efficiency into a unified solution. Whether you're granting emergency access or preparing for your next HIPAA audit, Azure Bastion delivers what enterprises need: secure temporary access as and when needed, complete audit trails with zero administrator overhead, and comprehensive compliance without compromising productivity, bringing a fundamental shift in how organizations approach secure remote access in the cloud. Resources: https://learn.microsoft.com/azure/bastion/ https://learn.microsoft.com/azure/bastion/shareable-link https://learn.microsoft.com/azure/bastion/session-recording https://azure.microsoft.com/pricing/details/azure-bastion/
Looking for a Microsoft FTE Co-Owner — New AVM Terraform Module: Network Security Perimeter
🔍 Looking for a Microsoft FTE Co-Owner — New AVM Terraform Module: Network Security Perimeter Hi EveryOne, I've just submitted a module proposal to the Azure Verified Modules (AVM) program for a Terraform resource module covering Azure Network Security Perimeter (Microsoft.Network/networkSecurityPerimeters). Module name: avm-res-network-networksecurityperimeter As a community contributor (non-FTE), I'm looking for a Microsoft FTE who is willing to take on the formal module owner role so we can move this forward together. I'm fully committed to doing the development work — building, testing, and maintaining the module to AVM specification — and I'm familiar with AVM standards, Terraform module structure, and the contribution flow. This module covers: - Network Security Perimeter resource lifecycle - Profile and access rule management (inbound/outbound) - PaaS resource associations - Diagnostic settings, locks, RBAC, and tags per AVM interface specs NSP is increasingly being mandated in enterprise Landing Zone deployments — especially in regulated industries — and there's currently no AVM Terraform representation for it. This is a great opportunity to fill a real gap in the ecosystem. If you're a Microsoft FTE interested in co-owning this module, please reply here or reach out directly. Happy to share the GitHub proposal link and discuss further. Thanks! #AzureVerifiedModules #Terraform #Azure #IaC #AzureLandingZones
