Azure Firewall : valider le Threat Intelligence avant de bloquer la production

Azure Firewall Threat Intelligence peut transformer un signal de réputation en décision de blocage réseau. C’est utile quand un workload tente de joindre une destination malveillante ou compromise. C’est risqué quand le mode Deny est activé sans preuve suffisante : un flux partenaire, une API SaaS, une dépendance de mise à jour ou une collecte de logs peut être coupé comme s’il s’agissait d’un indicateur hostile.

Le cas d’usage est une plateforme Azure hub-and-spoke où les sorties Internet passent par Azure Firewall. Le mode Threat Intelligence est en Alert, ou l’équipe envisage de le passer en Deny après plusieurs alertes sur des IPs et FQDNs externes. Le but du runbook est de décider si le blocage peut être activé, s’il faut rester en alerte, créer une exception ciblée, corriger un flux applicatif ou rollbacker rapidement après faux positif.

Nommer le changement de sécurité

Commencez par décrire ce qui va réellement changer. Threat Intelligence n’est pas une règle applicative écrite par l’équipe. C’est une décision de filtrage basée sur les indicateurs de réputation utilisés par Azure Firewall. Le passage de Alert à Deny modifie donc le comportement de production même si aucune règle réseau explicite n’a été ajoutée.

change:
firewall: azfw-hub-prod
current_mode: Alert
target_mode: Deny
scope: outbound internet traffic from production spokes
owner: security-and-networking
window: 2026-07-28T20:00:00Z

evidence_required:
- threat_intel_alerts_by_source_and_destination
- application_or_flow_owner
- business_criticality
- known_partner_or_saas_dependency
- firewall_rule_that_currently_allows_the_flow
- validation_probe_after_change
- rollback_command_and_expected_time

Sans ce contrat, l’équipe risque de traiter un blocage Threat Intelligence comme un simple durcissement. En production, c’est un changement de routage et de sécurité qui doit être observable et réversible.

Lire les alertes avant de décider

Le premier réflexe doit être de lire les logs Azure Firewall, pas de changer le mode. Il faut identifier les sources, destinations, protocoles, règles traversées et tendances. Une alerte isolée sur une VM de test n’a pas le même poids qu’une alerte répétée depuis plusieurs subnets de production.

let StartTime = ago(7d);
AZFWThreatIntel
| where TimeGenerated > StartTime
| project TimeGenerated,
        Firewall = Resource,
        SourceIp,
        DestinationIp,
        DestinationPort,
        Protocol,
        Action,
        ThreatIntelDescription,
        ThreatIntelConfidence,
        Fqdn = tostring(Fqdn)
| summarize Events=count(),
          FirstSeen=min(TimeGenerated),
          LastSeen=max(TimeGenerated),
          Actions=make_set(Action),
          Descriptions=make_set(ThreatIntelDescription, 5)
by Firewall, SourceIp, DestinationIp, DestinationPort, Protocol, Fqdn
| order by Events desc, LastSeen desc

Adaptez le nom des tables si votre environnement utilise une table héritée ou une exportation différente. L’objectif reste le même : isoler les flux concernés avant de transformer l’alerte en blocage.

Relier le signal au flux métier

Une destination signalée ne suffit pas à décider. Il faut savoir quel workload sort vers cette destination, quelle règle l’autorise, si le flux est attendu et qui peut en confirmer l’usage. Cette étape évite de bloquer une dépendance légitime mal classée ou un CDN partagé.

Questions de qualification
Quel subnet ou workload porte SourceIp ?
Quelle application ou quel job déclenche le flux ?
Quelle règle Azure Firewall permet actuellement la sortie ?
La destination est-elle un partenaire, un CDN, une API SaaS ou une IP inconnue ?
Le flux existe-t-il dans la documentation applicative ou l'IaC ?
Le même flux apparaît-il depuis préproduction ?
Peut-on remplacer l'accès large par un FQDN ou une règle plus précise ?

Signaux de risque
Destination non documentée
Flux nouveau depuis un déploiement récent
Source multiple sans owner clair
Port inattendu pour le protocole
Contournement NAT ou sortie directe hors firewall

Si le flux n’a pas d’owner, il ne faut pas l’autoriser par habitude. Mais il ne faut pas non plus activer un blocage global sans comprendre l’impact possible.

Séparer faux positif, flux compromis et dette réseau

Les alertes Threat Intelligence aboutissent souvent à trois diagnostics différents. Le premier est le vrai positif : un workload contacte une destination dangereuse et le blocage doit être activé ou renforcé. Le deuxième est le faux positif : une destination partagée ou un service légitime déclenche une réputation contestable. Le troisième est la dette réseau : une application dépend d’une sortie trop large, difficile à défendre.

classification:
likely_malicious:
  evidence:
    - destination_unknown_to_application_owner
    - repeated_attempts_after_failure
    - new_flow_after_suspicious_change
    - no_business_dependency
  action: block_or_isolate_source

likely_false_positive:
  evidence:
    - known_partner_or_saas_endpoint
    - fqdn_documented_and_validated
    - same_destination_used_by_preproduction
    - provider_status_or_contract_confirms_usage
  action: targeted_exception_with_expiry

network_debt:
  evidence:
    - broad_application_rule
    - missing_owner
    - dependency_only_known_by_ip
    - no_synthetic_probe
  action: keep_alert_then_reduce_scope

Cette classification évite une décision binaire trop pauvre. Le bon résultat peut être un blocage, une exception temporaire, une réduction de règle ou une enquête applicative.

Préparer une exception sans affaiblir le firewall

Si une exception est nécessaire, elle doit être plus précise que le flux existant. Une exception large sur une IP ou un domaine parent peut neutraliser le bénéfice du Threat Intelligence. La bonne exception porte un owner, une justification, une date d’expiration et une validation applicative.

{
"exception": "threat-intel-partner-api-prod",
"firewall": "azfw-hub-prod",
"source": "subnet-app-prod",
"destinationFqdn": "api.partner.example",
"ports": ["443"],
"owner": "platform-payments",
"reason": "documented partner API used by payment reconciliation",
"expiresAt": "2026-08-28T00:00:00Z",
"validation": [
  "partner contract checked",
  "application probe passes",
  "no broader destination allowed"
]
}

Une exception sans expiration devient une règle permanente déguisée. Si l’équipe ne sait pas la retirer, elle ne devrait pas l’ajouter.

Valider le mode Deny sur les chemins critiques

Avant bascule, testez les flux critiques depuis les subnets concernés : API partenaires, mises à jour système, collecte de logs, dépôts de paquets, sauvegardes, monitoring, webhooks, pipelines privés et accès d’administration bornés. Le test doit prouver que le mode Deny bloque ce qui doit l’être sans casser les chemins attendus.

Validation avant Deny
Liste des flux critiques revue avec les owners
Alertes Threat Intelligence classées par application
Exceptions temporaires limitées et datées
Probes synthétiques prêtes sur les API externes importantes
Dashboard Azure Firewall prêt pendant la fenêtre
Action Groups actifs pour erreurs applicatives et firewall denies
Commande de rollback testée ou relue

Bloquer la bascule
SourceIp non attribuée à un workload
Destination critique non testable
Exception proposée trop large
Logs Azure Firewall incomplets
Aucune mesure applicative après changement

Le point important n’est pas de garantir zéro faux positif. C’est de savoir détecter rapidement un faux positif, réduire son périmètre et revenir en arrière.

Surveiller le changement en KQL

Pendant et après le passage en Deny, surveillez les denies Threat Intelligence avec les erreurs applicatives. Une hausse de blocages sans symptôme utilisateur peut être acceptable. Une hausse corrélée à un parcours métier doit déclencher rollback ou exception ciblée.

let ChangeTime = datetime(2026-07-28T20:00:00Z);
AZFWThreatIntel
| where TimeGenerated between (ChangeTime .. ChangeTime + 2h)
| where Action has "Deny"
| summarize Denies=count(),
          Sources=make_set(SourceIp, 20),
          Ports=make_set(DestinationPort, 10),
          Descriptions=make_set(ThreatIntelDescription, 5)
by bin(TimeGenerated, 5m), DestinationIp, Fqdn
| order by TimeGenerated asc

Complétez avec les logs applicatifs. Azure Firewall peut montrer le blocage, mais seule l’application indique si un parcours métier est touché.

Décider maintien, exception ou rollback

La décision doit rester lisible après l’incident. Gardez le mode Deny si les blocages sont attendus et que les applications critiques restent stables. Créez une exception ciblée si un flux légitime est affecté et correctement justifié. Revenez en Alert si l’équipe perd la visibilité ou si le blocage casse un chemin critique non compris.

Maintenir Deny
Les blocages correspondent aux flux classés dangereux
Aucun parcours critique ne régresse
Les exceptions sont limitées, datées et validées
Les owners confirment les flux restants

Créer une exception ciblée
Flux métier légitime confirmé
Destination précise et testable
Expiration et owner définis
Probe applicative disponible

Revenir en Alert
Blocages corrélés à un incident applicatif
Logs insuffisants pour qualifier les denies
Plusieurs owners incapables d'expliquer leurs flux
Exception nécessaire trop large

Isoler un workload
Source inconnue ou compromise probable
Tentatives répétées vers destinations risquées
Aucun besoin métier confirmé

Un rollback de sécurité n’est pas un échec si la décision est documentée. L’échec serait de rester en Deny sans comprendre ce qui est cassé, ou de revenir en Alert sans plan de reprise.

Conclusion

Azure Firewall Threat Intelligence doit être traité comme un contrôle de production, pas comme un simple interrupteur de sécurité. Le bon runbook relie les alertes aux workloads, classe les flux, prépare les exceptions minimales, valide les chemins critiques et surveille le changement avec des preuves applicatives.

La décision finale doit être explicite : maintenir Deny, rester en Alert, créer une exception temporaire, isoler une source ou rollbacker. C’est cette discipline qui permet d’améliorer la posture réseau sans transformer un signal de réputation en interruption de production difficile à expliquer.