Azure Firewall IDPS: validate a signature before switching it to deny

An Azure Firewall Premium IDPS signature has been firing in alert mode for several days. It targets suspicious behavior, carries a high severity and the security team wants to move it to Alert and Deny. The change looks narrow: one signature ID and one mode. Yet the same signature can match a controlled attack test, an unusual monitoring agent or a legitimate application protocol. Enforcing it without qualifying the flows can turn a useful signal into a production incident.

The running case is an application calling an internal service through an Azure Firewall Premium hub. IDPS logs contain the signature, but no deny action is active yet. The objective is to prove what it detects, bound the affected producers and destinations, run positive and negative canaries, then choose deny, continued alerting, a minimal exception or rollback.

Freeze the contract before changing the policy

Start with the signature ID and one real flow, not the Deny control. Record the policy, any parent policy, the effective IDPS mode, signature, category, direction, severity and last change time. A local override can inherit or replace a mode defined higher in the hierarchy; the diff must capture the effective value, not only the child object.

firewall_policy: fwpol-hub-prod
policy_sku: Premium
signature_id: "2032081"
current_effective_mode: Alert
candidate_mode: AlertAndDeny
traffic_direction: Internal
scope:
- source: 10.24.8.0/24
- destination: 10.31.12.20
- port: 8080
observation_window: 7d
canary_window: 30m
success:
- synthetic malicious probe is denied and logged
- legitimate probes remain successful
- no unexplained reset or timeout appears
rollback: restore the signature override to Alert

Do not change the global IDPS mode, TLS inspection, private IP ranges and the signature override in the same operation. Each setting changes either the inspected population or how traffic direction is classified. One controlled variable keeps the outcome attributable.

Prove the evidence path in structured logs

The resource-specific AZFWIdpsSignature table contains data plane packets that matched one or more IDPS signatures. Confirm that the diagnostic setting routes this category to the intended workspace and that recent events expose SignatureId, Action, SourceIp, DestinationIp, DestinationPort, Protocol, Severity and Category.

let Signature = "2032081";
let Window = 7d;
AZFWIdpsSignature
| where TimeGenerated >= ago(Window)
| where SignatureId == Signature
| summarize
  Hits = count(),
  FirstSeen = min(TimeGenerated),
  LastSeen = max(TimeGenerated)
by Action, Severity, Category, Protocol,
   SourceIp, DestinationIp, DestinationPort
| order by Hits desc

An empty result is not approval to deny. It can mean no traffic, the wrong time range, the wrong workspace, missing resource-specific logs or a path that bypasses the firewall. First produce a controlled hit in alert mode and prove that it reaches the expected table.

Separate the signature from network context

A signature alone does not describe the risk. For the main source-destination pairs, identify the source owner, application, expected protocol, matching network or application rule, TLS inspection state and service-side outcome. On HTTPS traffic, IDPS can inspect encrypted content only when TLS inspection applies to that path. A visible HTTP test and an uninspected HTTPS flow therefore do not validate the same control.

Check the IDPS private IP ranges as well. They determine whether traffic is classified as inbound, outbound or internal. A missing enterprise range can cause a signature to be evaluated in a different direction than expected. Correct that classification separately from the deny rollout.

Flow                  Expected use          Signature hit   TLS inspected   Owner
10.24.8.14 -> 10.31.12.20 health probe          yes             n/a             platform
10.24.8.51 -> 10.31.12.20 order submission      no              n/a             orders
10.24.8.90 -> 10.31.12.20 security canary       yes             n/a             security

Unknown before deny
- unowned source IP
- unexplained destination or port
- encrypted path whose inspection status is not proven
- hit with no matching application trace

A high-severity hit deserves prompt investigation, not automatic enforcement. Tie it to an application trace, deployment, approved scan or demonstrably hostile behavior. Volume alone cannot distinguish a frequent false positive from a repeated attack.

Test both sides of the control

The canary must prove one refusal and one absence of harm. Prepare two reproducible probes from a bounded source: one request that triggers the signature in an authorized environment, and one representative business transaction that must never trigger it. Capture UTC time, source IP, destination, port, client outcome and correlation ID.

Before the change, both probes must reach their expected outcome and the security canary must produce an Alert action. If the signal is not reproducible, do not enable deny; you will have no way to demonstrate that the candidate policy works.

Apply the Alert and Deny override to this signature only, during a short window and on a canary policy when the topology supports it. Azure Firewall treats some signatures as context for later detections; do not force an unsupported mode or work around an override limitation. A completed policy deployment is not yet data plane validation.

Correlate the canary and regressions

Replay the controlled malicious probe first, then the legitimate transaction. The first should fail in the protocol-specific way and produce a deny action; the second must retain its SLO. Query a narrow time range so the canary is not mixed with historical hits.

let Signature = "2032081";
let CanarySource = "10.24.8.90";
let Start = datetime(2026-09-23T06:30:00Z);
let End = datetime(2026-09-23T07:00:00Z);
AZFWIdpsSignature
| where TimeGenerated between (Start .. End)
| where SignatureId == Signature
| extend IsCanary = SourceIp == CanarySource
| summarize Hits = count(), Sources = dcount(SourceIp)
by bin(TimeGenerated, 5m), Action, IsCanary,
   DestinationIp, DestinationPort, Description
| order by TimeGenerated asc

In parallel, monitor timeouts, resets, application errors and latency changes for legitimate sources. An increase without a matching IDPS event can indicate another policy, routing or application issue. Do not attribute it to the signature without correlation.

Prefer the narrowest exception

If a legitimate flow matches the signature, four decisions are available:

1. Fix the client or protocol when the behavior is genuinely unsafe.
2. Keep the signature in alert while uncertainty remains high.
3. Disable this signature only when it is unusable in this context and the risk is otherwise controlled.
4. Use a bypass list only for a precisely justified source or destination.

An IDPS bypass removes the selected traffic from IDPS filtering; it is not an exception to one signature. It can suppress other valuable detections. Do not exclude a whole subnet to preserve one endpoint, and do not use bypass as a performance tuning mechanism.

Promote Alert and Deny
controlled malicious probe is denied and logged
legitimate cohort is clean during the canary window
application and security owners approve the evidence

Hold in Alert
hit ownership or traffic direction remains unclear
positive and negative probes are not reproducible
log coverage is incomplete

Create a targeted exception
legitimate flow is proven and cannot be corrected in the window
excluded IP scope is minimal and time-bound
compensating detection and expiry owner are recorded

Rollback
legitimate errors, resets or unexplained denies increase
restore the signature override to Alert
rerun both probes and confirm recovery

Validate, promote or roll back

Promotion is justified when the controlled hit is denied, legitimate transactions remain stable and every new event is attributable. Then expand scope or observation duration gradually. Retain the KQL query, policy diff, probe results and owner of any exception in the change record.

Roll back at the signature layer instead of disabling IDPS globally. Restore Alert, wait for the policy deployment to finish, replay both probes and verify that the legitimate transaction recovers without losing visibility. If the regression comes from a new private-range classification or TLS inspection change, restore that change separately.

Conclusion

Moving an Azure Firewall IDPS signature to deny is a production decision even when the diff contains only an ID and a mode. The useful evidence unit connects signature, direction, flow, inspection, the action in AZFWIdpsSignature and the application outcome.

The runbook ends with an observable decision: promote Alert and Deny, remain in Alert, repair the flow, create a minimal exception or restore the previous override. Security improves when the control blocks the intended behavior without making the system less explainable.