Prescaling in Azure Firewall is now generally available
Azure Firewall protects your applications and workloads with cloud-native network security that automatically scales based on your traffic needs. Today, we’re excited to announce the general availability of prescaling in Azure Firewall – a new capability that gives you more control and predictability over how your firewall scales. Why pre-scaling? Today, Azure Firewall automatically scales in response to real-time traffic demand. For organizations with predictable traffic patterns – such as seasonal events, business campaigns, holidays, or planned migrations – the ability to plan capacity in advance can provide greater confidence and control. That’s where prescaling comes in. With prescaling, you can: Plan ahead– Set a baseline number of firewall capacity units to ensure capacity is already in place before demand rises. Stay flexible – Define both minimum and maximum capacity unit values, so your firewall always has room to grow while staying within your chosen bounds. See clearly – Monitor capacity trends with a new observed capacity metric and configure alerts to know when scaling events occur. You can think of it as adding extra checkout counters before a holiday rush – when the customers arrive, you’re already prepared to serve them without delays or bottlenecks. Example scenarios E-commerce sales events – Scale up before a holiday shopping promotion to handle the surge in online buyers. Workload migrations – Ensure sufficient capacity is ready during a large data or VM migration window. Seasonal usage – For industries like education, gaming, or media streaming, pre-scale ahead of known peak seasons. Getting started in Azure Portal Navigate to your Azure Firewall resource in the Azure Portal. Select Scaling options in settings. By default, every Azure Firewall starts in autoscaling mode. To enable prescaling, simply switch to pre-scaling mode in the Azure Portal and configure your desired capacity range: Minimum capacity: 2 or higher. Maximum capacity: up to 50, depending on your needs. Monitor the scaling behavior with the observed capacity metric. Billing and availability Pre-scaling uses a new Capacity Unit Hour meter. Charges apply based on the number of firewall instances you configure. Standard: $0.07 per capacity unit hour Premium: $0.11 per capacity unit hour ✨ Next steps Prescaling gives you predictable performance and proactive control over your firewall, helping you confidently handle the traffic patterns that matter most to your business. 🚀 Try prescaling today and share your feedback with the team. Learn more about how to configure and monitor this feature in the Azure Firewall prescaling documentation.How Azure network security can help you meet NIS2 compliance
With the adoption of the NIS2 Directive EU 2022 2555, cybersecurity obligations for both public and private sector organizations have become more strict and far reaching. NIS2 aims to establish a higher common level of cybersecurity across the European Union by enforcing stronger requirements on risk management, incident reporting, supply chain protection, and governance. If your organization runs on Microsoft Azure, you already have powerful services to support your NIS2 journey. In particular Azure network security products such as Azure Firewall, Azure Web Application Firewall WAF, and Azure DDoS Protection provide foundational controls. The key is to configure and operate them in a way that aligns with the directive’s expectations. Important note This article is a technical guide based on the NIS2 Directive EU 2022 2555 and Microsoft product documentation. It is not legal advice. For formal interpretations, consult your legal or regulatory experts. What is NIS2? NIS2 replaces the original NIS Directive 2016 and entered into force on 16 January 2023. Member states must transpose it into national law by 17 October 2024. Its goals are to: Expand the scope of covered entities essential and important entities Harmonize cybersecurity standards across member states Introduce stricter supervisory and enforcement measures Strengthen supply chain security and reporting obligations Key provisions include: Article 20 management responsibility and governance Article 21 cybersecurity risk management measures Article 23 incident notification obligations These articles require organizations to implement technical, operational, and organizational measures to manage risks, respond to incidents, and ensure leadership accountability. Where Azure network security fits The table below maps common NIS2 focus areas to Azure network security capabilities and how they support compliance outcomes. NIS2 focus area Azure services and capabilities How this supports compliance Incident handling and detection Azure Firewall Premium IDPS and TLS inspection, Threat Intelligence mode, Azure WAF managed rule sets and custom rules, Azure DDoS Protection, Azure Bastion diagnostic logs Detect, block, and log threats across layers three to seven. Provide telemetry for triage and enable response workflows that are auditable. Business continuity and resilience Azure Firewall availability zones and autoscale, Azure Front Door or Application Gateway WAF with zone redundant deployments, Azure Monitor with Log Analytics, Traffic Manager or Front Door for failover Improve service availability and provide data for resilience reviews and disaster recovery scenarios. Access control and segmentation Azure Firewall policy with DNAT, network, and application rules, NSGs and ASGs, Azure Bastion for browser based RDP SSH without public IPs, Private Link Enforce segmentation and isolation of critical assets. Support Zero Trust and least privilege for inbound and egress. Vulnerability and misconfiguration defense Azure WAF Microsoft managed rule set based on OWASP CRS. Azure Firewall Premium IDPS signatures Reduce exposure to common web exploits and misconfigurations for public facing apps and APIs. Encryption and secure communications TLS policy: Application Gateway SSL policy; Front Door TLS policy; App Service/PaaS minimum TLS. Inspection: Azure Firewall Premium TLS inspection Inspect and enforce encrypted communication policies and block traffic that violates TLS requirements. Inspect decrypted traffic for threats. Incident reporting and evidence Azure Network Security diagnostics, Log Analytics, Microsoft Sentinel incidents, workbooks, and playbooks Capture and retain telemetry. Correlate events, create incident timelines, and export reports to meet regulator timelines. NIS2 articles in practice Article 21 cybersecurity risk management measures Azure network controls contribute to several required measures: Prevention and detection. Azure Firewall blocks unauthorized access and inspects traffic with IDPS. Azure DDoS Protection mitigates volumetric and protocol attacks. Azure WAF prevents common web exploits based on OWASP guidance. Logging and monitoring. Azure Firewall, WAF, DDoS, and Bastion resources produce detailed resource logs and metrics in Azure Monitor. Ingest these into Microsoft Sentinel for correlation, analytics rules, and automation. Control of encrypted communications. Azure Firewall Premium provides TLS inspection to reveal malicious payloads inside encrypted sessions. Supply chain and service provider management. Use Azure Policy and Defender for Cloud to continuously assess configuration and require approved network security baselines across subscriptions and landing zones. Article 23 incident notification Build an evidence friendly workflow with Sentinel: Early warning within twenty four hours. Use Sentinel analytics rules on Firewall, WAF, DDoS, and Bastion logs to generate incidents and trigger playbooks that assemble an initial advisory. Incident notification within seventy two hours. Enrich the incident with additional context such as mitigation actions from DDoS, Firewall and WAF. Final report within one month. Produce a summary that includes root cause, impact, and corrective actions. Use Workbooks to export charts and tables that back up your narrative. Article 20 governance and accountability Management accountability. Track policy compliance with Azure Policy initiatives for Firewall, DDoS and WAF. Use exemptions rarely and record justification. Centralized visibility. Defender for Cloud’s network security posture views and recommendations give executives and owners a quick view of exposure and misconfigurations. Change control and drift prevention. Manage Firewall, WAF, and DDoS through Network Security Hub and Infrastructure as Code with Bicep or Terraform. Require pull requests and approvals to enforce four eyes on changes. Network security baseline Use this blueprint as a starting point. Adapt to your landing zone architecture and regulator guidance. Topology and control plane Hub and spoke architecture with a centralized Azure Firewall Premium in the hub. Enable availability zones. Deploy Azure Bastion Premium in the hub or a dedicated management VNet; peer to spokes. Remove public IPs from management NICs and disable public RDP SSH on VMs. Use Network Security Hub for at-scale management. Require Infrastructure as Code for all network security resources. Web application protection Protect public apps with Azure Front Door Premium WAF where edge inspection is required. Use Application Gateway WAF v2 for regional scenarios. Enable the Microsoft managed rule set and the latest version. Add custom rules for geo based allow or deny and bot management. enable rate limiting when appropriate. DDoS strategy Enable DDoS Network Protection on virtual networks that contain internet facing resources. Use IP Protection for single public IP scenarios. Configure DDoS diagnostics and alerts. Stream to Sentinel. Define runbooks for escalation and service team engagement. Firewall policy Enable IDPS in alert and then in alert and deny for high confidence signatures. Enable TLS inspection for outbound and inbound where supported. Enforce FQDN and URL filtering for egress. Require explicit allow lists for critical segments. Deny inbound RDP SSH from the internet. Allow management traffic only from Bastion subnets or approved management jump segments. Logging, retention, and access Turn on diagnostic settings for Firewall, WAF, DDoS, and Application Gateway or Front Door. Send to Log Analytics and an archive storage account for long term retention. Set retention per national law and internal policy. Azure Monitor Log Analytics supports table-level retention and archive for up to 12 years, many teams keep a shorter interactive window and multi-year archive for audits. Restrict access with Azure RBAC and Customer Managed Keys where applicable. Automation and playbooks Build Sentinel playbooks for regulator notifications, ticket creation, and evidence collection. Maintain dry run versions for exercises. Add analytics for Bastion session starts to sensitive VMs, excessive failed connection attempts, and out of hours access. Conclusion Azure network security services provide the technical controls most organizations need in order to align with NIS2. When combined with policy enforcement, centralized logging, and automated detection and response, they create a defensible and auditable posture. Focus on layered protection, secure connectivity, and real time response so that you can reduce exposure to evolving threats, accelerate incident response, and meet NIS2 obligations with confidence. References NIS2 primary source Directive (EU) 2022/2555 (NIS2). https://eur-lex.europa.eu/eli/dir/2022/2555/oj/eng Azure Firewall Premium features (TLS inspection, IDPS, URL filtering). https://learn.microsoft.com/en-us/azure/firewall/premium-features Deploy & configure Azure Firewall Premium. https://learn.microsoft.com/en-us/azure/firewall/premium-deploy IDPS signature categories reference. https://learn.microsoft.com/en-us/azure/firewall/idps-signature-categories Monitoring & diagnostic logs reference. https://learn.microsoft.com/en-us/azure/firewall/monitor-firewall-reference Web Application Firewall WAF on Azure Front Door overview & features. https://learn.microsoft.com/en-us/azure/frontdoor/web-application-firewall WAF on Application Gateway overview. https://learn.microsoft.com/en-us/azure/web-application-firewall/overview Examine WAF logs with Log Analytics. https://learn.microsoft.com/en-us/azure/application-gateway/log-analytics Rate limiting with Front Door WAF. https://learn.microsoft.com/en-us/azure/web-application-firewall/afds/waf-front-door-rate-limit Azure DDoS Protection Service overview & SKUs (Network Protection, IP Protection). https://learn.microsoft.com/en-us/azure/ddos-protection/ddos-protection-overview Quickstart: Enable DDoS IP Protection. https://learn.microsoft.com/en-us/azure/ddos-protection/manage-ddos-ip-protection-portal View DDoS diagnostic logs (Notifications, Mitigation Reports/Flows). https://learn.microsoft.com/en-us/azure/ddos-protection/ddos-view-diagnostic-logs Azure Bastion Azure Bastion overview and SKUs. https://learn.microsoft.com/en-us/azure/bastion/bastion-overview Deploy and configure Azure Bastion. https://learn.microsoft.com/en-us/azure/bastion/tutorial-create-host-portal Disable public RDP and SSH on Azure VMs. https://learn.microsoft.com/en-us/azure/virtual-machines/security-baseline Azure Bastion diagnostic logs and metrics. https://learn.microsoft.com/en-us/azure/bastion/bastion-diagnostic-logs Microsoft Sentinel Sentinel documentation (onboard, analytics, automation). https://learn.microsoft.com/en-us/azure/sentinel/ Azure Firewall solution for Microsoft Sentinel. https://learn.microsoft.com/en-us/azure/firewall/firewall-sentinel-overview Use Microsoft Sentinel with Azure WAF. https://learn.microsoft.com/en-us/azure/web-application-firewall/waf-sentinel Architecture & routing Hub‑spoke network topology (reference). https://learn.microsoft.com/en-us/azure/architecture/networking/architecture/hub-spoke Azure Firewall Manager & secured virtual hub. https://learn.microsoft.com/en-us/azure/firewall-manager/secured-virtual-hubIntroducing the new Network Security Hub in Azure
Background: Since its launch in 2020, Azure Firewall Manager has supported customers in securing their networks. But the role of network security has since evolved, from a foundational requirement to a strategic priority for organizations. Today, organizations must protect every endpoint, server, and workload, as attackers continually search for the weakest link. Over the years, we’ve heard consistent feedback about the importance of centralized management, easier service discovery, and streamlined monitoring across their network security tools. These capabilities can make the difference between a minor incident and a major breach. That’s why we’re excited to introduce a new, unified Network Security hub experience. This updated hub brings together Azure Firewall, Web Application Firewall, and DDoS Protection—enabling you to manage, configure, and monitor all your network security services in one place. While Azure Firewall Manager offered some of this functionality, the name didn’t reflect the broader scope of protection and control that customers need. With this new experience, Firewall Manager has expanded into the Network Security Hub, making it easier to discover, configure, and monitor the right security services with just a few clicks. The result: less time navigating, more time securing your environment. What you’ll notice: Streamlined navigation: Whether you search for Azure Firewall, Web Application Firewall, DDoS Protection, or Firewall Manager, you’ll now be directed to the new Network Security hub. This unified entry point presents all relevant services in context—helping you stay focused and quickly find what you need, without feeling overwhelmed. Overview of services: The hub’s landing page provides a high-level view of each recommended solution, including key use cases, documentation links, and pricing details—so you can make informed decisions faster. Common scenarios: Explore typical deployment architectures and step-by-step guidance for getting started, right from the overview page. Related services: We’ve consolidated overlapping or closely related services to reduce noise and make your options clearer. The result? Fewer, more meaningful choices that are easier to evaluate and implement. New insights: We've enhanced the security coverage interface to show how many of your key resources are protected by Azure Firewall, DDoS Protection, and Web Application Firewall. Additionally, our integration with Azure Advisor now provides tailored recommendations to help you strengthen your security posture, reduce costs, and optimize Azure Firewall performance. What this means for you: No changes to Firewall Manager pricing or support: This is a user experience update only for Firewall Manager. You can continue to deploy Firewall policies and create Hub Virtual Network or Secured Virtual Hub deployments —now within the streamlined Network Security hub experience. Aligned marketing and documentation: We’ve updated our marketing pages and documentation to reflect this new experience, making it easier to find the right guidance and stay aligned with the latest best practices. Faster decision-making: With a clearer, more intuitive layout, it’s easier to discover the right service and act with confidence. Better product experience: This update brings greater cohesion to the Azure Networking portfolio, helping you get started quickly and unlock more value from day one Before: The original landing page was primarily focused on setting up Firewall Policies and Secured Virtual Hub, offering a limited view of Azure’s broader network security capabilities. After: The updated landing page delivers a more comprehensive and intuitive experience, with clear guidance on how to get started with each product—alongside common deployment scenarios to help you configure and operationalize your network security stack with ease. Before: The previous monitoring and security coverage experience was cluttered and difficult to navigate, making it harder to get a quick sense of your environment’s protection status. After: The updated Security Coverage view is cleaner and more intuitive. We've streamlined the layout and added Azure Advisor integration, so you can now quickly assess protection status across key services and receive actionable recommendations in one place. The expansion of Firewall Manager into the Network Security hub is part of a greater strategic effort to simplify and enhance the Azure Networking portfolio, ensuring better alignment with customer needs and industry best practices. You can learn more about this initiative in this blog. This shift is designed to better align with customer needs and industry best practices—by emphasizing core services, consolidating related offerings, and phasing out legacy experiences. The result is a more cohesive, intuitive, and efficient product experience across Azure Networking. 📣 If you have any thoughts or suggestions about the user interface, feel free to drop them in the feedback form available in the Network Security hub on the Azure Portal. Documentation links: Azure Networking hub page: Azure networking documentation | Microsoft Learn Scenario Hub pages: Azure load balancing and content delivery | Microsoft Learn Azure network foundation documentation | Microsoft Learn Azure hybrid connectivity documentation | Microsoft Learn Azure network security documentation | Microsoft Learn Scenario Overview pages What is load balancing and content delivery? | Microsoft Learn Azure Network Foundation Services Overview | Microsoft Learn What is hybrid connectivity? | Microsoft Learn What is Azure network security? | Microsoft Learn
Protect against SharePoint CVE-2025-53770 with Azure Web Application Firewall (WAF)
Summary Microsoft recently disclosed CVE-2025-53770, a critical vulnerability affecting on-premises SharePoint Server versions 2016, 2019, 2010, 2013, and Subscription Edition (SE). The vulnerability allows unauthenticated remote code execution (RCE) by chaining two separate CVEs: CVE-2025-49706 – Authentication Bypass CVE-2025-49704 – Deserialization Vulnerability Microsoft has released security updates for SharePoint Server 2016, 2019, and SE. Versions 2010 and 2013 are out of support and will not receive patches, leaving them exposed. If exploited, this vulnerability could allow an attacker to bypass authentication, extract cryptographic keys, and execute arbitrary C# code on the server. Technical details On-premises SharePoint Servers are enterprise-grade collaboration platforms that organizations install and manage on their own infrastructure, typically in their data centers. The attack chain for CVE-2025-53770 involves the following steps: CVE-2025-49706 – Authentication Bypass The attacker sends a crafted POST request targeting the endpoint:/_layouts/15/ToolPane.aspx?DisplayMode=Edit&a=/ToolPane.aspx with a malicious Referer value:/_layouts/SignOut.aspxThis manipulates SharePoint into trusting the request and its payload. CVE-2025-49704 – Deserialization Vulnerability The attacker then sends a POST request with a serialized spinstall0.aspx payload, designed to extract MachineKey values from web.config. These keys are then used to craft a serialized C# code payload embedded in a valid __VIEWSTATE, which SharePoint trusts and executes. Microsoft guidance We strongly recommend following Microsoft's official mitigation steps outlined in the MSRC blog: Customer guidance for SharePoint vulnerability CVE-2025-53770 | Microsoft Security Response Center See the “How to protect your environment” section for patching guidance, configuration updates, and additional mitigation strategies. Protecting with Azure Web Application Firewall You can create a custom rule to help detect and block suspicious requests matching known indicators of this attack. Example WAF custom rule: Condition 1: URI contains / _layouts/15/ToolPane.aspx or / _layouts/15/spinstall0.aspx Condition 2: Referer header contains / _layouts/SignOut.aspx or / _layouts/15/SignOut.aspx JSON view "customRules": [ { "name": "CVE202553770", "priority": 100, "ruleType": "MatchRule", "action": "Block", "matchConditions": [ { "matchVariables": [ { "variableName": "RequestUri" } ], "operator": "Regex", "negationConditon": false, "matchValues": [ "(?i)/_layouts(?:/\\d+)?/(SignOut|spinstall0|ToolPane)\\.aspx" ], "transforms": [] }, { "matchVariables": [ { "variableName": "RequestHeaders", "selector": "Referer" } ], "operator": "Regex", "negationConditon": false, "matchValues": [ "(?i)/_layouts(?:/\\d+)?/(SignOut|spinstall0|ToolPane)\\.aspx" ], "transforms": [] } ], "skippedManagedRuleSets": [], "state": "Enabled" } ] Next steps Patch immediately: Apply Microsoft’s updates for SharePoint 2016, 2019, and SE. Isolate legacy systems: SharePoint 2010 and 2013 remain vulnerable—consider restricting network access or migrating to supported versions. Deploy WAF protections: Add the custom rule above to monitor and block suspicious traffic targeting vulnerable endpoints. You can find more information about Custom Rules on Azure WAF for Application Gateway here or for Azure Front Door here. For more on Azure WAF, see: Azure Web Application Firewall documentationOptimize Azure Firewall logs with selective logging
A common question from customers is whether Azure Firewall supports filtering or selecting which logs are sent to a Log Analytics workspace. This concern usually stems from the high cost of storing large volumes of data — especially in environments where the firewall inspects substantial amounts of network traffic. Azure Firewall now supports ingestion-time transformation of logs in Azure Log Analytics. This capability introduces selective and advanced filtering, giving customers more control over what data is collected and analyzed. In this blog post, we’ll explore a major new capability: Azure Firewall now supports ingestion-time transformations in Log Analytics — enabling flexible, cost-efficient logging through selective data collection. Why does it matter? For many enterprise customers, the cost of ingesting Azure Firewall logs into Log Analytics — especially at scale — can be significant. Depending on the logging mode (Basic or Analytics), ingestion costs can be substantial, potentially making it challenging to expand logging coverage across additional workloads. With ingestion-time transformations, users can filter logs by rows, columns, timestamps, and more — and apply transformations before ingestion. This ensures that only relevant and critical data is stored, helping reduce costs while retaining the necessary telemetry for analysis, threat detection, and compliance. Customer benefits Security monitoring: Log only suspicious traffic for more targeted threat detection. Cost optimization: Avoid ingesting and storing unnecessary data. Compliance: Use DCR (data collection rules) to filter and route logs to meet audit/reporting needs. Incident response: Focus on logs that matter, accelerating investigation time. Custom alerts: Build insights on top of curated, high-value logs. What are transformations in Azure Monitor? Ingestion-time transformations in Azure Monitor allow you to filter or modify incoming telemetry before it reaches your Log Analytics workspace. This happens in the cloud pipeline — after the data source (such as Azure Firewall) sends its logs, but before those logs are ingested and stored. Transformations are defined using DCR and written in Kusto Query Language (KQL). Each transformation runs against incoming records individually, letting you precisely control what gets stored – and what doesn’t. For example, you might collect only entries where the action column contains the word “deny”. That filter can be applied at ingestion time, so only those critical logs are stored. The diagram below shows how this works end-to-end, from data source to filtered ingestion. To learn more and estimate potential processing charges, refer to the official documentation. Transforming Azure Firewall logging In this section, we’ll walk through a few real-world use cases shared by customers — including how to create a DCR based on specific filtering criteria. Important: Ingestion-time transformations for Azure Firewall logs are supported only when using resource-specific logs. If you’re using legacy diagnostic settings, this capability is not available. To enable transformations, ensure your firewall is configured to send logs using the Azure Firewall resource-specific log schema. First, navigate to your Log Analytics workspace and locate the table where your Azure Firewall logs are stored (e.g., AZFWApplicationRule). Click the three-dot menu (…) on the right and select “Create transformation”. Creating a transformation is a 3 steps-process. Step 1 – Basics: Create a DCR to define how incoming data is processed and specify where it should be stored. Step 2 – Schema and transformation: Use the Transformation Editor to write a KQL query that filters the incoming data based on your criteria. Step 3 – Review: Review the table name, DCR name, and KQL query before clicking “Create”. This summary ensures everything is configured correctly. For more information on how to create a DCR, refer to the official documentation. Use case 1: Excluding alerts from low priority IDPS signatures This DCR transformation filters and reshapes incoming Azure Firewall IDPS logs before they're ingested into a Log Analytics workspace. source | where Action !contains "alert" and Severity != 3 | project TimeGenerated, Protocol, SourceIp, SourcePort, DestinationIp, DestinationPort, Action, SignatureId, Description, Severity Here's a breakdown of what it does: source: This refers to the incoming data stream — in this case, the AZFWIdpsSignature table (intrusion detection/prevention logs from Azure Firewall). | where Action !contains "alert" and Severity != 3: This line filters out any log entries where the Action contains "alert" (non-blocking detection events). Any entries where Severity equals 3 (which represents low severity events). The result: We’re keeping only more actionable or higher-severity entries that don’t just raise alerts but may involve blocks or higher-severity behaviors (e.g., deny actions, critical or warning severities). | project ...: The project statement selects and forwards only the specified columns to the Log Analytics workspace. When you run a query in your Log Analytics workspace, you’ll notice that only the specific columns defined in your transformation’s project statement are available — and they appear in the exact order specified in the query. Use case 2: Filtering out unnecessary logs (trusted or testing networks) This DCR transformation filters out log entries from specific source IP address ranges before they're ingested into Azure Monitor. In this scenario, the 10.0.200.x and 10.0.300.x ranges might represent trusted or test network segments that generate high volumes of traffic — traffic that don’t need to be logged. By excluding these IPs at ingestion time, you can significantly reduce unnecessary log volume and associated costs. source | where not( SourceIp startswith "10.0.200." or SourceIp startswith "10.0.300." ) | project TimeGenerated, Protocol, SourceIp, SourcePort, DestinationIp, DestinationPort, Action, ActionReason, Policy, RuleCollection, Rule Here's a breakdown of what it does: source: This refers to the incoming data stream — in this case, the AZFWNetworkRule table. | where not (…): Applies a filter to exclude logs that match the criteria inside. SourceIp startswith "10.0.200." and SourceIp startswith "10.0.300.": These conditions match any log where the SourceIp address falls within the 10.0.200.0/24 or 10.0.300.0/24 subnets (i.e., IPs like 10.0.200.1, 10.0.200.45, etc.). | project ...: The project statement selects and forwards only the specified columns to the Log Analytics workspace. Conclusion By leveraging ingestion-time transformations through DCR, organizations gain full control over which Azure Firewall logs are ingested in Log Analytics. This selective logging capability helps reduce noise, cut costs, and retain only high-value data for security, compliance, and operational insights. As Azure Firewall evolves these enhancements offer greater flexibility and efficiency for managing cloud-native network telemetry. Resources Azure updates | Microsoft Azure Monitoring data reference for Azure Firewall | Microsoft Learn Transformations Azure Monitor - Azure Monitor | Microsoft Learn Create a transformation in Azure Monitor - Azure Monitor | Microsoft Learn
Automating Enriched DDoS Alerts Using Logic Apps
In today’s digital world, Distributed Denial of Service (DDoS) attacks have become one of the most common and disruptive threats facing online applications and services. These attacks aim to overwhelm a target, typically a website, API, or server, by flooding it with massive volumes of traffic, rendering it slow or completely inaccessible. Azure DDoS Protection is Microsoft's cloud-native defense that helps safeguard public-facing endpoints hosted in Azure. It works by continuously monitoring traffic patterns at the network layer (L3 and L4) and applying mitigation techniques in real time when suspicious or anomalous activity is detected. Azure DDoS Protection is tightly integrated with the Azure platform and provides always-on traffic scrubbing without requiring any manual intervention. While Azure mitigates these attacks in the background, understanding who is attacking, which resources are targeted, and how often these events occur is helpful. This is where Azure Logic Apps shines. Azure Logic Apps is a powerful platform to simplify the integration and automation of multiple services that help you run your business workflows. You can run your custom code or use no code at all to get your workflows running. When combined with Log Analytics & KQL queries, Logic Apps can help you extract critical insights from DDoS logs, including: Attack starts and end times Affected public IPs Top attacking IPs, countries, and ASNs Volume of traffic and packets dropped Attack patterns and frequency Application availability The result of the process is an email alert with details about the resource associated with the Public IP as detailed above. The owner of the resource is added as a recipient of the email, along with the security team who get alerted when the Attack occurs. Whether you're a security engineer, a product owner, or part of a cloud operations team, this solution can help you improve visibility and enhance coordination during DDoS incidents. Let’s dive into how this automation works. Here is the link to this template. Note: This template is an updated version of the same template discussed in this Blog- Enriching DDoS Protection Alerts with Logic Apps What this template contains: Log Search Alert rule Action Group Logic App Office 365 API Connector Azure Monitor Logs API Connector Parameters to Input when deploying: Security team's Email Address Company Domain (In the form of abc@domain.com) Workspace name (Name of the Log Analytics workspace being used) Prerequisites: A Public IP Address with DDoS Protection enabled either via IP Protection or Network Protection A Log Analytics Workspace to which the above Public IP Address should be sending Diagnostic logs, specifically all of the below categories: DDoS protection notifications Flow logs of DDoS mitigation decisions Reports of DDoS mitigations Note: The Log Analytics Workspace must reside in the same Resource Group as the one where this template is being deployed. 🔐Authentication Prerequisites: Azure Resource Graph The Logic App uses a Managed Identity to authenticate with Azure Resource Graph and query metadata about Azure resources Required Role: Logic App's Managed Identity will need Reader or higher access on the subscription (or resource group) that contains the Public IP address under DDoS protection Log Analytics Workspace To run Kusto queries and retrieve DDoS mitigation logs, the Logic App connects to Azure Log Analytics Workspace using the same Managed Identity Required Role: Logic App's Managed Identity will need Log Analytics Reader on the target workspace Office 365 (Email Notifications) API Connection For sending enriched alert emails, the Logic App uses an API connection to Office 365. This connection must be authorized to send emails on behalf of the configured account, specifically Mail.Send & User.Read permissions You must sign in and authorize this connection once during setup using the outlook credentials that you need it to use to send the emails If your tenant has admin consent policies, a Global Admin might need to approve use of the connectors (especially Office 365) for the Logic App Azure Monitor Logs API Connection This script queries Flow logs of DDoS mitigation decisions & Reports of DDoS mitigations To do this it needs AzureMonitorLogs API Connection and therefore, authorizing this is necessary for it to work as expected You must sign in and authorize this connection once during setup Firewall & Network Rules Ensure that: No IP restrictions block access from Logic App to the target services or public test URL in the HTTP step. You can find the outgoing IP Addresses here: Go to your Logic App Select Properties Look for the "Runtime outgoing IP addresses" section—these are your runtime IPs Now, let’s look at what each of the items in the Template does and their workings below in detail: Log Search Alert rule Monitors log data: It continuously scans the Azure Diagnostics logs, specifically targeting entries where the Category is DDoSProtectionNotifications and the type_s field indicates a Mitigation started event Runs on a schedule: The rule runs every 5 minutes and looks back at the last 30 minutes of logs. This ensures near-real-time detection of mitigation activity. (This can be modified as needed to increase the look back time if needed) Triggers on first sign of mitigation: If even one matching log entry is found (i.e., one mitigation event has started), the alert fires. This makes it extremely responsive Alerts through an Action Group: Once triggered, the rule calls a pre-defined Action Group, which will Invoke a webhook to notify a Logic App Why It’s Useful: While Azure DDoS Protection automatically mitigates volumetric and protocol attacks at the network edge, getting alerted when an event occurs requires user configuration. This is done by: Notifying your team the moment mitigation begins Adding observability, so you can correlate mitigation with service behavior or performance dips Action Group: Enrich-DDoSAlert — Connecting detection to automation When a DDoS attack is detected through an Azure Monitor alert, the response needs to be fast and efficient. That’s where Action Groups come in. In this case, the Enrich-DDoSAlert action group acts as the automation trigger for our DDoS response pipeline This action group is configured to call a webhook tied to an Azure Logic App using a secure HTTP POST request instantly when the alert fires. Then the Logic App carries out a series of enrichment and response steps based on the DDoS alert Why This Matters: The action group acts as a real-time bridge between detection and automation, triggering the Logic App instantly when an alert fires. The Action Group ensures that: The alert is captured Automation is triggered The investigation process starts without delay Logic App: Enrich-DDoSAlert Step-by-Step Breakdown Triggered via HTTP request Accepts a payload containing alert metadata such as: o Target resource ID o DDoS alert details o Search links and interval data Extracts impacted public IP and performs enrichment Using Azure Resource Graph, it queries the target IP to determine: o Associated Azure resource (VM, App Gateway, etc.) o DNS name, tags, region, resource group, and owner (from tags) Connectivity Check (Optional Validation) It performs an HTTP GET request to the DNS/IP of the attacked resource — checking if it’s still up or responding Generates an HTML-formatted email Using all this context, it builds a clean, readable email body that includes: o Top source IPs o IP under attack o Resource name/type o DNS name o Region o Tag info (owner, environment, etc.) o Link to Log Analytics search results o Status of connectivity test (code, headers, body) Queries Azure Monitor logs again (This time allows it to build a thorough DDoS Post Mitigation Report) After a 50-minute delay, it runs a query on the DDoS mitigation logs to extract: o Top source IPs o Top countries, ASNs, and continents o Time of mitigation o Traffic overview Note: This Delay is required but can be changed subtly. During this time, the post mitigation reports will be accumulated so it can be sent as an email in the next steps. Without this delay the reports will not populate correctly. Send a second email, titled "Post Mitigation DDoS Report", containing the above data. Post Mitigation Report plays a vital role in strengthening your defense strategy. By reviewing patterns in traffic origin, volume, and behavior, teams can: o Identify recurring attack sources or suspicious geographies o Correlate DDoS activity with other system anomalies o Fine-tune firewall and WAF rules based on attacker fingerprints In short, this enriched reporting not only enhances visibility but also enables teams to proactively adapt their security posture and reduce the impact of future attacks. Who gets notified? Office 365 API connector Both emails are sent using an authenticated Office 365 connector, delivered to the security team and tagged owner (which will be inputted during deployment). The high-priority email ensures visibility, while the second report gives retrospective clarity. Why this is useful: Reduces manual effort: No more pivoting across multiple tools to gather context Speeds up response: Teams get instant details Bridges Alert to Action: Combines signal (alert) with enrichment (resource graph + logs) and delivery (email) Customizable: You can adjust queries, recipients, or even trigger conditions Azure Monitor Logs API Connector The Azure Monitor Logs API Connector allows Logic Apps to query data from Log Analytics using Kusto Query Language (KQL). In this solution, it's essential for extracting DDoS-specific insights—such as top attacking IPs, countries, ASNs, and traffic volume—from diagnostic logs. What It Does in This Template: Executes KQL queries against your Log Analytics Workspace Retrieves: Flow logs from DDoSMitigationFlowLogs Mitigation reports from DDoSMitigationReports Delivers summarized data such as: Top attacker IPs Source ASNs and countries Mitigation start/end time Traffic patterns Here are some examples of the Automated & Enriched DDoS E-Mails: Potential Attack, First Email, as soon as an attack event is identified: Post Mitigation Summary Email: Conclusion: This Logic App doesn’t just automate alerting—it empowers your team with actionable context. By stitching together signals from Azure Monitor and Resource Graph, and packaging them into enriched, structured emails, it transforms raw alerts into informed decisions. Whether you're triaging incidents or conducting post-attack analysis, this setup ensures you're not starting from scratch each time. As attacks grow more complex, automation like this isn’t just nice to have—it’s essential. Start simple, adapt to your needs, and let your defenses work smarter.
Azure WAF Integration in Security Copilot is Now Generally Available
We’re excited to announce the general availability (GA) of Azure Web Application Firewall (WAF) integration with Microsoft Security Copilot. This marks a significant advancement in web application protection, bringing together Azure WAF’s industry-leading defense with the AI-powered capabilities of Security Copilot to transform how security teams detect, investigate, and respond to threats. Why This Integration Is a Game-Changer Modern web applications face relentless threats - from SQL injections and cross-site scripting (XSS) to bot attacks and sophisticated Layer 7 DDoS attempts. Defending against these threats requires more than just reactive measures; it demands intelligent, scalable solutions. With Azure WAF now integrated into Security Copilot, security teams can gain: Proactive threat analysis: Quickly uncover attack patterns and identify emerging threats. Optimized WAF configurations: Use AI insights to fine-tune rules and policies. Accelerated investigations: Leverage Copilot’s generative AI to streamline incident triage and response. This integration enables teams to work smarter and faster - turning raw data into actionable intelligence with the help of natural language prompts and AI-guided workflows. Seamless Protection Across Azure Platforms Azure WAF protects applications behind Azure Front Door and Azure Application Gateway, offering centralized, cloud-native security at scale. Now, with Security Copilot, analyzing WAF diagnostic logs no longer requires manual parsing or deep scripting expertise. Instead, AI delivers contextual insights directly to your SOC teams, cloud admins, and DevSecOps engineers. Whether you're investigating blocked requests or tuning security policies, this integration helps reduce operational overhead while strengthening your overall security posture. What Can You Do with Azure WAF in Security Copilot Let’s explore some of the core capabilities now available: SQL Injection (SQLi) Attack Analysis Understand why Azure WAF blocked specific SQLi attempts through detailed summaries of diagnostic logs and correlation of related events over time. Cross-Site Scripting (XSS) Attack Insights Get clear explanations for WAF’s enforcement actions against XSS attacks, with trend analysis across your environment. Top Offending IPs Analysis Identify the most malicious IPs triggering WAF rules, along with insights into the behaviors and rule patterns that led to their blocking. Most Triggered Rules and Actions Gain visibility into your most active WAF rules - helping prioritize tuning efforts and enhance threat detection effectiveness. These capabilities are designed to turn WAF data into actionable knowledge - without the need for custom queries or extensive log review. Built for the Future of Intelligent Security As threats continue to evolve, so must our defenses. The Azure WAF and Security Copilot integration represents the next generation of web application protection - combining automation, AI reasoning, and expert knowledge to deliver adaptive security at cloud scale. By augmenting your team with AI, you can stay ahead of attackers, protect critical apps, and respond faster than ever before. Learn More and Get Started The GA of Azure WAF integration in Microsoft Security Copilot is more than just a feature release - it’s a new paradigm for web application security. Explore the capabilities today by visiting the Azure WAF documentation. Want to talk to us? Reach out to the Azure WAF product team to share feedback or request a demo. Let’s build a more secure web, together.Maximizing savings with Azure Firewall and Azure Monitor basic table plan
The Azure Firewall Product Team has recently announced support for the new Log Analytics Basic table plan for all resource-specific logging tables, offering a potential reduction in logging costs by up to 80%. This new mode complements the existing 80% cost reduction achieved through structured/resource-specific logging, providing even greater savings. To learn more about the cost optimization introduced by resource-specific logs, check out the blog post Optimizing Azure Firewall logging costs | Microsoft Community Hub. While the new Basic table plan is beneficial for cost-conscious customers, it's important to note that Policy Analytics and Security Copilot integrations are not compatible with the Basic table plan. For more information on Basic tables, refer to the Azure Monitor Logs documentation. Customers have long expressed concerns about high logging costs, so we listened and have developed a new Basic table plan to meet those needs. The Basic table plan provides a more economical solution without sacrificing essential functionalities. This initiative highlights Azure Firewall's commitment to delivering value and efficiency, making it easier for customers to manage their logging needs affordably. When querying Basic tables, the cost is determined by the volume of data scanned, which depends on both the size of the table and the query's specified time range. Essentially, the data scanned refers to the amount of data ingested within the time frame set by the query for the targeted table. For example, if a query scans data over a three-day period in a table that ingests 100 GB daily, the charge would be based on 300 GB of data. Enabling the basic table plan The basic table plan is enhanced by resource-specific tables. To learn more about using structured/resource-specific logs, review the following documentation: Monitor Azure Firewall | Microsoft Learn. To enable the basic table plan, locate the tables under your Log Analytics Workspace, click on “Manage table,” and adjust the configuration as shown below. Note: The table plan can be updated only once every 7 days. Security Copilot and Policy Analytics To use the Security Copilot integration with Azure Firewall, ensure your IDPS log table (AZFWIdpsSignature) is configured in Analytics mode. The same applies to Policy Analytics on the following tables: AZFWApplicationRuleAggregation AZFWIdpsSignature AZFWNatRuleAggregation AZFWNetworkRuleAggregation AZFWThreatIntel If you are using both features, your configuration will look like this: In summary, the new Log Analytics Basic table plan offers significant cost savings for Azure Firewall users, while maintaining essential functionality. By configuring your tables correctly, you can take full advantage of these savings and optimize your logging strategy. Explore the documentation and start saving today!
Best Practices for Securing Access to VMs
Azure Bastion and Microsoft Entra PIM work together to secure VM access by eliminating the need for public IPs, enabling identity-based authentication, and enforcing Just-In-Time (JIT) access. Bastion provides secure RDP/SSH connections through Entra ID without local credentials, while Entra PIM ensures that users only receive time-limited, approved access. This combination supports a Zero Trust model by minimizing persistent privileges and reducing the overall attack surface.
