Web Application Firewall OWASP Core Rule Sets and Custom Managed Rules

This blog provides a simple explanation on updating the OWASP Core Rule Sets on your WAF (Web Application Firewall) as well managing your custom managed rules as part of the Cloud Shared Responsibility Model.

The blog is broken down into the following sections for easier reading:

Web Application Firewall

For internet-facing applications, Microsoft recommends that you enable a web application firewall (WAF) and configure the managed rules. When you use a WAF with the Microsoft-managed rules, your application is protected from a range of attacks.

Tuning your WAF as per your environment

The rules in your WAF should be tuned according to the workloads deployed in your bespoke environment. You need to fine tune your WAF, to prevent accidentally blocking requests that should be allowed and thus result in false positive detections.

When you tune your WAF for your application workloads, you typically create a set of rule exclusions to reduce false positive detections. If you manually configure these exclusions by using the Azure portal, then when you need to upgrade your WAF to use a newer ruleset version, you will need to reconfigure the same exceptions against the new ruleset version. This process can be time-consuming and error-prone. Instead, consider defining your WAF rule exclusions and other configuration via code, such as Azure CLI, Azure PowerShell, Bicep or Terraform. Thus, when you need to update your WAF ruleset version, you can easily reuse the same exclusions.

Enable core rule sets

Microsoft’s core rule sets are designed to protect your application by detecting and blocking common attacks. The rules are based on a various sources including the OWASP top 10 attack types and information from Microsoft Threat Intelligence.

Microsoft regularly updates the managed rules to take account of the current threat landscape. Ensure that you regularly check for updates to Azure-managed rule sets.

The benefits and advantages of the OWASP_3.2 can be found here.

Upgrading the Core Rule Set (CRS) to version 3.2 on a Web Application Firewall (WAF) should not cause the service disruption. The upgrade process is designed to be non-disruptive.

When you upgrade the CRS to version 3.2, the new rules are deployed next to the existing rule set and do not overwrite the current rules. The old rules wil not be removed and will continue to be used until the new rules are selected.

It is also important to note that upgrading the CRS to version 3.2 may cause some false positives or false negatives. Thus you may need to monitor the WAF logs after the upgrade to ensure that the WAF is still effectively protecting your application.

Additionally, please ensure that your application is compatible with each new CRS version before upgrading. You can review the CRS release notes to see if there are any breaking changes or compatibility issues that may affect your application here.

The latest CRS versions can be found and upgraded by going to the Application Gateway WAF policy > Managed rules > Assign and selecting the latest OWASP_x.x version.

If for some unexpected reason, you need to revert back to an earlier version, you will need to log a Microsoft call, although this would be in the event that you have some very technically complex bespoke rule that gets altered in some way.

Verification after upgrade to the new CRS

To verify that the newly upgraded CRS version managed rule is not causing false negatives, you can enable and review logging generated by the Azure Web Application Firewall (WAF) on the Application Gateway.

To enable logging for the WAF, you can follow these steps:

1. Open the Azure portal > go to the Application Gateway that has the WAF enabled.
2. Diagnostic settings > Add diagnostic setting > name >
3. Send and select your destination Log Analytics Workspace >
4. Logs > ApplicationGatewayFirewallLog > Save

Run your Kusto query and interrogate the results.

1. Go to Log Analytics workspace  > Logs
2. Enter the following query to view the WAF logs:

AzureDiagnostics
| where Category == “ApplicationGatewayFirewallLog”

4. Click on the Run >  Review the logs to see if any false negatives are being generated by the managed rule.

Creating Alerts

You can also use the Log Analytics workspace to enable proactive alerting based on specific log events, which can help you proactively monitor and remediate any issues with the WAF policy CRS. One option is to enable an alert which will be delivered to your distribution group members outlook inbox for example.

When you are satisfied with the result > select New alert rule from the Logs KQL and configure the Azure Monitor Alert rule and Action Group accordingly.

How do I backup and export my CRS?

Remember that as per the SRM (Shared Responsibility Model) the responsibility of backing up custom configurations on client firewalls and WAFs falls within the clients space (this also applies to the FWaaS resources) and is not the responsiblity of the cloud provider!

Setup a business schedule to backup the WAF policies. (Simply setup a reminder in your calendar until you configure an automation process).

Go to your Application Gateway WAF policy > Export the Template.

How do I create reusable WAF managed rules via powershell?

The guide on creating custom waf rules via powershell can be found here.

Best Practices

Best practices for Web Application Firewall on Application Gateway can be found here

Azure Updates

Subscribe to Azure WAF updates here.