Updating Azure WAF from OWASP CRS to Microsoft Default Rule Set

If you're running Azure WAF with OWASP CRS 3.2, you've probably seen recommendations to update to Microsoft's Default Rule Set (DRS). Here's how to do it without breaking your applications.

Why Update?

Microsoft's Default Rule Set 2.1 offers:

• Better detection rates with fewer false positives
• Faster updates for new threats
• Better integration with Azure-specific features
• Continued support (OWASP CRS updates are less frequent)

The Terraform Change

# Old configuration
resource "azurerm_web_application_firewall_policy" "this" {
  name                = "waf-policy"
  resource_group_name = azurerm_resource_group.this.name
  location            = azurerm_resource_group.this.location

  managed_rules {
    managed_rule_set {
      type    = "OWASP"
      version = "3.2"
    }
  }
}

# New configuration
resource "azurerm_web_application_firewall_policy" "this" {
  name                = "waf-policy"
  resource_group_name = azurerm_resource_group.this.name
  location            = azurerm_resource_group.this.location

  managed_rules {
    managed_rule_set {
      type    = "Microsoft_DefaultRuleSet"
      version = "2.1"
    }

    managed_rule_set {
      type    = "Microsoft_BotManagerRuleSet"
      version = "1.0"
    }
  }
}

Common Error

If you get this error:

Error: expected managed_rules.0.managed_rule_set.0.type to be one of
["OWASP" "Microsoft_DefaultRuleSet" "Microsoft_BotManagerRuleSet"]

Check your provider version. DRS support was added in azurerm 3.x.

Migration Strategy

Don't switch in production without testing. The rule sets have different detection logic.

1. Create a new WAF policy with DRS in detection mode
2. Apply to a test environment or non-critical path
3. Run for 1-2 weeks, review logs for false positives
4. Tune rule exclusions as needed
5. Switch to prevention mode
6. Apply to production

Checking for False Positives

AzureDiagnostics
| where ResourceType == "APPLICATIONGATEWAYS"
| where Category == "ApplicationGatewayFirewallLog"
| where action_s == "Blocked" or action_s == "Detected"
| where TimeGenerated > ago(7d)
| summarize Count = count() by ruleId_s, ruleGroup_s, requestUri_s
| order by Count desc

Look for legitimate requests being blocked. Common culprits:

• File uploads triggering body inspection rules
• API endpoints with JSON payloads
• Admin panels with complex forms

Rule Exclusions

If a rule causes false positives, exclude it for specific paths:

managed_rules {
  managed_rule_set {
    type    = "Microsoft_DefaultRuleSet"
    version = "2.1"

    rule_group_override {
      rule_group_name = "REQUEST-942-APPLICATION-ATTACK-SQLI"

      rule {
        id      = "942430"
        enabled = true
        action  = "Log"  # Log instead of block
      }
    }
  }

  exclusion {
    match_variable          = "RequestBodyPostArgNames"
    selector                = "content"
    selector_match_operator = "Equals"
  }
}

Bot Manager

DRS 2.1 works well with Bot Manager Rule Set:

managed_rule_set {
  type    = "Microsoft_BotManagerRuleSet"
  version = "1.0"
}

This adds protection against malicious bots while allowing legitimate crawlers (Googlebot, Bingbot, etc.).

Need help with WAF configuration or security assessments? Get in touch - we help organisations protect their web applications.