azure firewall manager
47 TopicsHow 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-hub83Views0likes0CommentsIntroducing 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 Learn1.6KViews1like0CommentsEnhancements to the Azure Firewall User Experience
This blog was co-authored by Abhinav Sriram, with contributions from Gopikrishna Kannan. Introduction Everyday, IT administrators face the challenge of securing networks while maintaining application uptime and performance. With a constantly evolving threat landscape and an influx of new vulnerabilities, staying ahead is no easy task. Cloud applications are increasingly leveraging AI to access critical data with reliability, and new applications are rapidly being onboarded. At the same time, organizational security requirements continue to expand in response to government regulations and customer expectations. CIOs are demanding that IT teams do more with less, and the demands can feel daunting. To meet these challenges, IT administrators need modern tools and resources that simplify operations, maintain security, and ensure application performance and compliance. The Azure Firewall team understands these operational needs and the proactive measures administrators require to minimize risk. We're excited to introduce new experiences and capabilities that streamline firewall management, making it easier to monitor, diagnose, and resolve issues quickly. Improved governance and compliance: Through Azure Policies and Azure Advisor recommendations, IT teams can maintain alignment with product and organizational standards, minimizing risk through proactive guidance. Optimized management and diagnostics: Through Azure Firewall Policy Change Tracking and the Diagnose and Solve Blade, administrators can monitor configuration changes and identify solutions to resolve issues quickly. In addition, the new user experiences for setting up a Management NIC and upcoming features like Packet Capture and Maintenance Configuration provide users with the kind of enhanced control and visibility they need for critical services like Firewall. Stay Updated with New Capabilities: The "What's New" experience in Azure Firewall Manager and the Private Preview Program keep administrators informed about updates and provide early access to new features. In this blog, we'll walk through each of these features more in-depth and explore how they assist administrators with tasks at different stages of firewall management beginning with features that bring enhanced governance and compliance to Azure Firewall. Built-In Azure Policies Azure Firewall now includes support for Azure Policy, designed to enhance governance and enforce security best practices. When administrators are initially configuring their firewalls or shortly after deployment, managing configurations across multiple firewalls to meet organizational standards can be complex and prone to oversight or error. These built-in policies simplify this process by automatically applying rules across your firewall resources and ensuring compliance with essential security and operational requirements. For example, administrators can enforce policies requiring Threat Intelligence to be enabled on all firewalls for added protection or mandating that only encrypted traffic is allowed into the environment. These policies offer a streamlined way to maintain consistent security practices, aligning firewall settings with organizational and regulatory standards. For detailed information on configuration and enforcement of these policies, see this blog. Image: Built-in Azure Policies Image: Azure Policy compliance enforcement across Firewall resources Built-In Azure Advisor Recommendations After deploying a firewall, it's essential to monitor any limitations that could impact its performance, particularly in large or complex environments with high traffic volumes. Azure Advisor, a personalized service, offers recommendations to help users optimize Azure resources across five key areas: reliability, security, operational excellence, performance, and cost. With this integration, Azure Advisor can proactively notify you if your Azure Firewall deployment is reaching any limitations, experiencing performance impacts, or has potential misconfigurations. This means you’ll be able to receive timely recommendations to address issues before they affect your network security, ensuring a seamless and secure experience. The current Azure Advisor recommendations include the following: Exceeding rule limitations on Firewall policy: Get notified if your firewall policy is reaching the maximum allowed rules, which may impact performance. Exceeding IP Group limitations on Firewall policy: Alerts for when IP groups used in your firewall policies exceed their defined limits. Exceeding Firewall Policy or Rule Collection Group size: Suggestions to optimize or restructure policies when they grow too large, potentially affecting management or performance. By leveraging these recommendations, you can maintain optimal firewall performance, address potential security risks, and reduce unnecessary costs. Stay tuned for more enhancements as we continue to add more recommendations into Azure Advisor for Azure Firewall. Policy Analytics is another Firewall capability that provides you with insights and recommendations for your environment. Image: Azure Advisor recommendation for “Firewall policy is reaching network rule limitations” Next, let’s dive into the capabilities that help with optimized management and diagnostics. Change Tracking (Preview) Azure Resource Graph (ARG) is an Azure service designed to provide efficient and performant resource exploration at scale. Azure Resource Graph (ARG) provides change analysis data for various management and troubleshooting scenarios. Users can find when changes were detected on an Azure Resource Manager (ARM) property, view property change details and query changes at scale across their subscription, management group, or tenant. ARG change analysis recently added support for RuleCollectionGroups. You can now track changes to Azure Firewall Rule Collection Groups using an Azure Resource Graph query from the Azure Portal ResourceGraphExplorer page using a query like this: Below is a sample change output. This capability can help you track changes made to your Firewall rules helping ensure accountability for a sensitive resource like a Firewall. Diagnose and Solve Blade The Diagnose and Solve problems blade is a feature in Azure that helps customers troubleshoot and solve Azure issues. It helps you explore the most common problems for your Azure Firewalls by providing quick access to service/resource health insights, automated troubleshooters, curated do-it-yourself troubleshooting guides, and additional troubleshooting tools that are all part of the self-help experience designed to help customers solve their problems even before bringing it to Microsoft support teams. To use this feature, you need to navigate to your Firewall in the Azure portal and select Diagnose and solve problems. Image: The Diagnose and Solve blade in Azure Firewall Portal This feature allows you to troubleshoot failures without needing to go through the standard process of filing a support ticket and also provides you with a summarized view of resource health and changes made to the resource in the last 72 hours. Management NIC Changes An Azure Firewall Management NIC separates Firewall management traffic from customer traffic. The firewall routes its management traffic via the dedicated AzureFirewallManagementSubnet (minimum subnet size /26) and its associated public IP address. This feature was previously called Forced Tunneling, as originally, a Management NIC was required only for Forced Tunneling. However, upcoming Firewall features will also require a Management NIC. To support any of these capabilities, you must create an Azure Firewall with the Firewall Management NIC enabled or enable it on an existing Azure Firewall. This is a mandatory requirement to avoid service disruption. To learn more, see Azure Firewall Management NIC | Microsoft Learn. Image: The updated Firewall Management Portal UX in the Create Azure Firewall workflow Lastly, let’s take a look at some of the ways in which you can stay updated with the latest going on with Azure Firewall. Updates to What’s new in Firewall Manager The “What’s new” page in Firewall Manager is kept updated with the most recent product releases across the Network Security portfolio and now easily links to the Copilot for Security integration for Azure Firewall. The Azure Firewall Plugin has four capabilities that help analysts perform detailed investigations of the malicious traffic intercepted by the IDPS feature of their firewalls across their entire fleet using natural language questions in the Copilot for Security standalone experience. To learn more about the user journey and value that Copilot can deliver, see the Azure blog. To see these capabilities in action, take a look at this Tech Community blog, and to get started, see the documentation. Image: Snapshot of the What's New user experience in Azure Firewall Manager Azure Connection Program The Azure Connection Program is an engineering feedback community for Azure customers and partners allowing you to directly engage with the product team of Azure Firewall and get early access to upcoming features like Packet Capture and Maintenance Configurations. This is an avenue where the product team actively engages with customers to get valuable feedback that can help impact the product roadmap. If you’re interested in joining and trying out new features early, please sign up here.2.3KViews2likes4CommentsOptimize 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 Learn1.6KViews1like0CommentsMaximizing 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!1KViews2likes1CommentProtecting the Public IPs of Secured Virtual Hub Azure Firewalls against DDoS Attacks
As discussed previously in the blog post “Fortify Your Azure Firewall: Custom Public IP Configuration on Secured Virtual Hub Deployments”, in the current cloud-focused environment, the management of network security has become increasingly important. Azure Firewall has long been an effective solution for securing virtual networks and virtual hubs, but recent updates have further enhanced its capabilities. The ability to specify your own Azure public IP to be used by your Azure Firewall within an Azure Virtual WAN Secured Virtual Hub, rather than relying on Azure to automatically assign one is a great feature that provides enhanced control over your network's public-facing IPs, enabling alignment with organizational security policies and compliance standards. In this blog, we'll discuss enhancing your secured virtual hub Azure firewall security by configuring Azure DDoS IP Protection for a comprehensive solution. Recap of the key benefits of using specific Public IPs for your Secured Virtual Hub Azure Firewalls Full Control: Gain complete ownership and management over the lifecycle of your firewall's public IP address. This means you can assign, reassign, and retire IP addresses as needed, ensuring that your network infrastructure remains agile and responsive to changing demands. By having full control, you can also implement custom configurations and policies that align with your specific security and operational requirements. Enhanced Security: Strengthen your network's defenses by enabling Distributed Denial of Service (DDoS) mitigation. This advanced security feature helps protect your infrastructure from malicious attacks that aim to overwhelm your network with excessive traffic. By proactively identifying and neutralizing potential threats, DDoS mitigation ensures that your services remain available and secure, providing peace of mind and uninterrupted access for your users. IP Address Flexibility: Enjoy the flexibility of allocating public IP addresses from a predefined IP prefix pool. This allows you to efficiently manage your IP resources, ensuring that you have the right number of addresses available for your current and future needs. With this flexibility, you can easily scale your network, accommodate new devices, and optimize IP address usage, all while maintaining a streamlined and organized IP address management system. How-to enable Azure DDoS IP Protection In this section we’ll configure Azure DDoS Protection to prevent DDoS attacks against the deployment. This is a key benefit that comes with the ability to configure your own public IPs on the Azure Firewall with Secured Virtual Hub. Select any of the public IPs you have associated with the firewall, this should bring you to the Overview blade of that resource. From the Overview blade, select the Protect button under Get Started. This will be how we enable the protection level for the public IP today, since the SKU that can be used for the protection will be Azure DDoS IP Protection, not Azure DDoS Network Protection. Since the virtual network used for the Virtual Hub is a managed virtual network, we cannot use the DDoS Network Protection SKU. You do have the option to enable this level of protection via Azure PowerShell or Azure CLI. From this view, we can see the various ways to configure DDoS protection for a public IP in Azure. As mentioned before, public IPs associated with an Azure Firewall in Secured Virtual Hub must use IP protection. In case you already have a DDoS Protection Plan, you will have the option to link it to the DDoS IP SKU when enabling the IP protection. When a DDoS IP SKU is linked to a plan, you will only be charged by your DDoS Protection Plan, instead of being charged for both. Once DDoS IP Protection is enabled, you can check the following 3 metrics, under the public IP resource, to validate the threshold levels applied to the public IP. Inbound SYN packet to trigger DDoS mitigation Inbound UDP packets to trigger DDoS mitigation Inbound TCP packet to trigger DDoS mitigation This indicates that the Azure DDoS IP Protection is on and protecting the workload behind the public endpoint. Conclusion Configuring specific public IP addresses for your Azure Firewall within a secured virtual hub represents a major leap forward in network security management. This feature not only offers enhanced control over your firewall's public-facing IPs but also significantly bolsters your security posture by incorporating Azure DDoS IP Protection. By utilizing this capability, you can safeguard your firewall against potential DDoS attacks, ensuring a more resilient and secure environment for your applications and services.897Views2likes0CommentsFortify Your Azure Firewall: Custom Public IP Configuration on Secured Virtual Hub Deployments
Written in collaboration with davidfrazee and gusmodena. In today's cloud-centric world, managing network security is more critical than ever. Azure Firewall has always been a robust solution for protecting your virtual networks, but recent updates have made it even more powerful. One of the latest enhancements allows you to configure which public IP addresses are used on your Azure Firewall in an Azure Virtual WAN Secured Virtual Hub, rather than having Azure automatically assign one for you. This new feature provides greater control over your network's public-facing IPs, enabling you to align them with your organization's security policies and compliance requirements. Moreover, this capability opens the door to leveraging Azure DDoS IP Protection. By selecting specific public IPs for your firewall, you can ensure that these addresses are shielded from distributed denial-of-service (DDoS) attacks, enhancing the overall security posture of your Azure environment. This integration not only fortifies your defenses but also simplifies the management of your network security infrastructure. In this blog, we will discuss our newly announced feature for Azure Firewall, detailing how to configure public IP addresses from your own subscription and highlighting the benefits of this enhancement. Key Benefits Full control – Own and manage the lifecycle of your firewall’s public IP. Enhanced security – Enable DDoS mitigation for better protection. IP address flexibility – Allocate public IPs from an IP prefix pool. How-To To get started with configuring public IP addresses on your Azure Firewall, you'll need to follow a few straightforward steps. This guide will walk you through the process, ensuring that you can take full advantage of this new feature. By the end of this section, you'll have a clear understanding of how to assign specific public IPs to your firewall, enhancing your control over network security and enabling the integration of Azure DDoS IP Protection. You’ve created an Azure Virtual WAN and now need to deploy secured virtual hubs. A great place to start with building out the environment in the Azure Portal will be in the Azure Firewall Manager. Here you’ll be able to have a centralized management portal to view your Azure Firewalls, firewall policies, Azure DDoS Protection plans, and more. Once you’re in Azure Firewall Manager, select Virtual Hubs to build a new secured virtual hub. Once you’ve configured the basic configurations for the secured virtual hub, you’ll have the option to start creating the Azure Firewall. You’ll notice a new option called Select source of public IP. Here we will select Customer provided (Preview) to define which public IPs will be used for the new secured virtual hub. You’ll have the option to choose a pre-created public IP or to create new from the firewall manager blade. With the secured virtual hub created, we can navigate back to Azure Firewall Manager and manage the new deployment from there. Under Virtual Hubs, select on the Firewall name to manage the public IP addresses. To add more public IPs to your Azure Firewall, you can either create new public IP resources or select from pre-created ones. This feature ensures that Azure won't just assign an IP for you; instead, you have the flexibility to choose or create the specific public IPs that align with your network requirements. This approach provides greater control and customization for your firewall's public-facing IP addresses. Now that we’ve added public IPs to the Azure Firewall, we can configure Azure DDoS Protection to prevent DDoS attacks against the deployment. This is a key benefit that comes with the ability to configure your own public IPs on the Azure Firewall with Secured Virtual Hub. Stay tuned for our next blog post where we’ll go through the steps needed to protect the Public IP associated to your secured virtual hub Azure Firewall. Conclusion The ability to configure specific public IP addresses for your Azure Firewall in a secured virtual hub marks a significant advancement in network security management. This feature not only grants you greater control over your firewall's public-facing IPs but also enhances your security posture by enabling the integration of Azure DDoS IP Protection. As we continue to navigate the complexities of cloud security, features like these empower organizations to tailor their security strategies to meet their unique needs and compliance requirements. Stay tuned for more updates and best practices on optimizing your Azure Firewall and protecting your network infrastructure.1.3KViews1like2CommentsAzure Firewall NAT Behaviors
NAT, or Network Address Translation, is a method of remapping an IP address into another by modifying network address information in the IP header of packets. When traffic passes through an Azure Firewall, the firewall can perform NAT to translate the source or destination IP addresses and ports of the packets. The specific NAT behavior will depend on the firewall’s configuration and the type of NAT being used. In this blog, we cover what behaviors to expect when traffic flows for inbound traffic, through DNAT rules, and for outbound traffic through the Network, and Application rules of the Azure Firewall.42KViews9likes15Comments