Azure Firewall IDPS : valider une signature avant de la passer en blocage

Une signature IDPS Azure Firewall Premium remonte depuis plusieurs jours en mode alerte. Elle vise un comportement à risque, sa sévérité est élevée et l’équipe sécurité veut la passer en Alert and Deny. Le changement semble précis : un identifiant de signature, un nouveau mode. Pourtant, la même signature peut apparaître sur un test d’attaque, un agent de supervision atypique ou un protocole métier légitime. La bloquer sans qualifier les flux transforme un signal utile en incident de production.

Le cas fil rouge concerne une application qui appelle un service interne à travers un hub Azure Firewall Premium. La signature est visible dans les logs IDPS, mais aucun blocage n’est encore actif. L’objectif est de prouver ce qu’elle détecte, de borner les producteurs et destinations concernés, d’exécuter un canari positif et négatif, puis de choisir entre blocage, maintien en alerte, exception minimale ou rollback.

Figer le contrat avant de modifier la policy

Commencez par l’identifiant de signature et un flux réel, pas par le bouton Deny. Enregistrez la policy, son éventuelle parent policy, le mode IDPS effectif, la signature, sa catégorie, sa direction, sa sévérité et la date du dernier changement. Une surcharge locale peut hériter ou remplacer un mode défini plus haut : le diff doit montrer la valeur effective, pas seulement l’objet enfant.

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

Ne changez pas simultanément le mode global IDPS, l’inspection TLS, les plages IP privées et la surcharge de signature. Chacun de ces réglages modifie la population inspectée ou la façon dont sa direction est interprétée. Un seul changement permet d’attribuer le résultat.

Vérifier que la preuve existe dans les logs structurés

La table structurée AZFWIdpsSignature contient les paquets ayant correspondu à une ou plusieurs signatures. Confirmez que la diagnostic setting envoie bien cette catégorie vers le workspace attendu et que les événements récents portent SignatureId, Action, SourceIp, DestinationIp, DestinationPort, Protocol, Severity et 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

Un résultat vide n’autorise pas le blocage. Il peut signifier absence de trafic, mauvaise période, mauvais workspace, logs structurés non activés ou chemin qui ne traverse pas le firewall. Prouvez d’abord un hit contrôlé en mode alerte et son arrivée dans la bonne table.

Séparer la signature du contexte réseau

Une signature ne décrit pas seule le risque. Reconstituez pour les principaux couples source-destination : propriétaire de la source, application, protocole attendu, règle réseau ou applicative correspondante, présence d’inspection TLS et résultat côté service. Pour le trafic HTTPS, l’IDPS ne voit le contenu chiffré que lorsque l’inspection TLS est appliquée au chemin concerné. Un test HTTP visible et un flux HTTPS non inspecté ne valident donc pas le même contrôle.

Vérifiez aussi les plages IP privées de l’IDPS. Elles déterminent si un flux est traité comme inbound, outbound ou internal. Une plage d’entreprise absente peut faire évaluer une signature dans une direction différente de celle attendue. Corrigez cette classification séparément du passage en blocage.

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

Un hit à haute sévérité mérite une investigation rapide, pas un automatisme aveugle. Reliez-le à une trace applicative, un déploiement, un scan approuvé ou un comportement réellement hostile. Le volume seul ne distingue pas un faux positif fréquent d’une tentative répétée.

Tester les deux côtés du contrôle

Le canari doit prouver un refus et une absence de dommage. Préparez deux probes reproductibles depuis une source bornée : une requête qui déclenche la signature dans un environnement autorisé, et une transaction métier représentative qui ne doit jamais la déclencher. Capturez horodatage UTC, IP source, destination, port, résultat client et identifiant de corrélation.

Avant le changement, les deux probes doivent atteindre leur résultat attendu et le canari de sécurité doit produire une action Alert. Si le signal n’est pas reproductible, ne basculez pas en blocage : vous ne pourrez pas démontrer que la policy candidate fonctionne.

Appliquez ensuite la surcharge Alert and Deny à la seule signature, pendant une fenêtre courte et sur une policy canari lorsque la topologie le permet. Azure Firewall gère certaines signatures comme éléments de contexte pour des détections suivantes ; ne forcez pas un mode non supporté et ne contournez pas une limitation de surcharge. Le déploiement de policy terminé ne constitue pas encore une validation data plane.

Corréler le canari et les régressions

Rejouez d’abord la probe malveillante contrôlée, puis la transaction légitime. La première doit échouer selon le protocole observé et produire une action de blocage ; la seconde doit conserver son SLO. Interrogez une fenêtre étroite pour éviter de mélanger le canari avec les hits historiques.

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

Surveillez en parallèle les timeouts, resets, erreurs applicatives et changements de latence pour les sources légitimes. Une hausse sans log IDPS correspondant peut signaler un autre problème de policy, de routage ou d’application. Ne l’attribuez pas à la signature sans corrélation.

Préférer l’exception la plus étroite

Si un flux légitime déclenche la signature, quatre décisions sont possibles :

1. Corriger le client ou le protocole si le comportement est réellement dangereux.
2. Maintenir la signature en alerte pendant l’analyse lorsque l’incertitude reste forte.
3. Désactiver seulement cette signature si elle est inexploitable dans ce contexte et que le risque est compensé.
4. Utiliser une bypass list uniquement pour une source ou destination précisément justifiée.

Une bypass list retire le trafic concerné du filtrage IDPS ; ce n’est pas une simple exception à une signature. Elle peut donc supprimer d’autres détections utiles. N’excluez pas un subnet entier pour sauver un seul endpoint et ne l’utilisez pas comme réglage de performance.

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

Valider, promouvoir ou rollbacker

La promotion est justifiée lorsque le hit contrôlé est bloqué, les transactions légitimes restent stables et chaque nouvel événement est attribuable. Étendez alors progressivement le scope ou la durée d’observation. Conservez la requête KQL, le diff de policy, les résultats de probes et le propriétaire de l’exception éventuelle dans le dossier de changement.

Rollbackez au niveau de la signature, pas en désactivant tout l’IDPS. Revenez à Alert, attendez la fin du déploiement de policy, rejouez les deux probes et vérifiez que la transaction légitime récupère sans perdre la visibilité. Si la régression vient d’une nouvelle classification de plages privées ou de l’inspection TLS, restaurez ce changement séparément.

Conclusion

Passer une signature Azure Firewall IDPS en blocage est une décision de production, même si le diff ne contient qu’un identifiant et un mode. La bonne unité de preuve relie signature, direction, flux, inspection, action dans AZFWIdpsSignature et résultat applicatif.

Le runbook se termine par une décision observable : promouvoir Alert and Deny, rester en Alert, corriger le flux, créer une exception minimale ou revenir à l’override précédent. La sécurité progresse quand le contrôle bloque le comportement visé sans rendre le système moins explicable.