Pourquoi chaque entreprise Azure a besoin d'une méthodologie d'analyse WAF

Si vous exécutez des applications web sur Azure, il y a de fortes chances qu’un Web Application Firewall soit déployé devant elles. Azure WAF, qu’il soit déployé sur Application Gateway ou Front Door, est l’un des contrôles de sécurité les plus courants dans les environnements Azure d’entreprise. C’est aussi l’un des plus mal compris.

Trop d’organisations traitent le WAF comme une case à cocher qu’on déploie et qu’on oublie. Les managed rule sets sont activés, le detection mode tourne pendant une semaine, puis quelqu’un bascule en prevention mode. Six mois plus tard, l’équipe sécurité croule sous des alertes qu’elle ne sait pas interpréter, et l’équipe applicative est frustrée par les false positives qui bloquent le trafic légitime.

Il existe une meilleure approche. Une méthodologie d’analyse WAF structurée transforme votre firewall d’un gardien bruyant en une couche de sécurité exploitable.

Le problème du “WAF par défaut”

Azure WAF est livré avec des OWASP Core Rule Set (CRS) managed rules qui couvrent un large éventail de schémas d’attaque : SQL injection, cross-site scripting, remote code execution, et bien d’autres. Ces règles sont bien maintenues et régulièrement mises à jour par Microsoft.

Mais voici le problème : les managed rules sont génériques par conception. Elles protègent contre les vecteurs d’attaque courants sans rien connaître de votre application spécifique. Ce décalage crée deux problèmes :

1. Des false positives qui bloquent les requêtes légitimes. Un système de gestion de contenu qui accepte du HTML en entrée déclenchera les règles XSS. Une API qui reçoit des payloads encodés en Base64 activera la détection de SQL injection. Ce ne sont pas des attaques, ce sont des schémas de trafic normaux qui correspondent à des signatures trop larges.

2. L’alert fatigue qui noie les vraies menaces. Quand votre WAF génère des milliers d’alertes en detection mode par jour, la plupart bénignes, l’équipe sécurité arrête de regarder. La seule véritable tentative de SQL injection se perd dans le bruit.

Les deux problèmes ont la même cause : le WAF n’est pas adapté à votre application, et personne n’a de processus systématique pour y remédier.

Azure docs: Azure WAF overview · CRS managed rule groups

À quoi ressemble une méthodologie d’analyse WAF

Une méthodologie correcte n’est pas compliquée, mais elle exige de la discipline. Voici les phases clés que nous utilisons dans les environnements Azure d’entreprise :

Phase 1 : Baseline et inventaire

Avant de toucher à la moindre règle, vous devez comprendre ce que vous protégez. Cela implique de construire un inventaire de :

• Applications derrière le WAF : leurs stacks technologiques, les schémas de trafic attendus et les niveaux de sensibilité des données
• Configuration WAF actuelle : quelle policy est attachée à quel listener, dans quel mode elle tourne, quels rule groups sont activés ou désactivés
• Volumes et schémas de trafic : heures de pointe, distribution géographique, ratios trafic API vs trafic navigateur

Cette phase réserve souvent des surprises. Nous trouvons régulièrement des WAF policies avec des dizaines d’exclusions par règle que personne ne peut expliquer, ou des applications ajoutées à un Application Gateway des mois plus tôt sans mise à jour de la WAF policy.

Phase 2 : Analyse des logs et profilage des règles

Avec la baseline en place, vous passez aux données. Les Azure WAF logs, qu’ils soient dans Log Analytics, un storage account ou streamés vers Microsoft Sentinel, contiennent tout ce qu’il faut pour comprendre comment les règles interagissent avec votre trafic.

La clé, c’est l’analyse structurée, pas simplement défiler dans les entrées de log. Pour chaque règle déclenchée, vous voulez répondre à :

• Est-ce un true positive, un false positive ou du bruit ? Un true positive est une véritable tentative d’attaque. Un false positive est du trafic légitime incorrectement signalé. Le bruit, c’est du trafic non pertinent (bots, scanners) qui déclenche des règles mais ne pose aucune menace réelle.
• Quelle est la fréquence et le schéma ? Une règle qui se déclenche une fois par mois est différente d’une règle qui se déclenche mille fois par jour. La fréquence aide à prioriser les efforts de tuning.
• Quelle est la source ? Utilisateurs internes, clients externes, partenaires connus ou trafic internet anonyme ? La réponse change le calcul de risque.

Nous construisons généralement des requêtes KQL qui agrègent les WAF logs par rule ID, action, URI et source IP, puis nous croisons les résultats avec les retours des équipes applicatives pour classifier chaque schéma.

Voici un point de départ pour profiler vos règles les plus déclenchées :

AzureDiagnostics
| where Category == "ApplicationGatewayFirewallLog"
| where TimeGenerated > ago(7d)
| summarize
    HitCount = count(),
    DistinctSources = dcount(clientIp_s),
    SampleURIs = make_set(requestUri_s, 3)
  by ruleId_s, action_s, ruleGroup_s
| order by HitCount desc
| take 20

Azure docs: WAF log fields and categories · Log Analytics overview · KQL reference

Phase 3 : Tuning et ingénierie des exclusions

Armé de données, vous pouvez maintenant prendre des décisions de tuning éclairées :

• Désactiver des règles fondamentalement incompatibles avec votre application et qui ne peuvent pas être traitées par des exclusions. Cela devrait être rare et toujours documenté.
• Créer des exclusions ciblées pour des champs de requête spécifiques (headers, cookies, query parameters) qui déclenchent des false positives. Le mot clé est ciblé : excluez le périmètre minimum nécessaire.
• Implémenter des custom rules là où les managed rules ne couvrent pas les menaces spécifiques à votre application. Le rate limiting, le geo-blocking et le contrôle d’accès basé sur les URI sont des exemples courants.

Chaque modification doit être documentée avec sa justification. Dans six mois, quelqu’un demandera pourquoi la règle 942130 est exclue pour l’endpoint /api/content. Si la réponse est “je ne sais pas, c’était déjà comme ça,” vous avez un problème de gouvernance.

Azure docs: WAF exclusion lists · Custom WAF rules

Phase 4 : Validation et promotion

Après le tuning en detection mode, vous validez les changements :

• Exécutez la policy ajustée en detection mode en parallèle du trafic de production pendant une période définie
• Vérifiez que le nombre de false positives a diminué jusqu’à un niveau acceptable
• Confirmez qu’aucun nouvel angle mort n’a été introduit en vérifiant que les schémas d’attaque connus déclenchent toujours des alertes
• Promouvez en prevention mode en toute confiance

Phase 5 : Gouvernance continue

L’analyse WAF n’est pas un projet ponctuel. Les applications évoluent, de nouveaux endpoints sont déployés, Microsoft met à jour les managed rule sets, et les schémas de menaces changent. Une méthodologie durable comprend :

• Une cadence de revue régulière : analyse mensuelle ou trimestrielle des logs pour détecter de nouveaux schémas de false positives ou des dérives de configuration
• L’intégration des changements : revues de WAF policy dans le pipeline de déploiement applicatif, pas après coup
• Des métriques et du reporting : suivez les taux de false positives, la couverture des règles et le délai moyen de tuning comme KPIs

Pourquoi c’est important au-delà de la sécurité

Un WAF bien ajusté fait plus que bloquer des attaques. Il vous donne une confiance opérationnelle.

Les équipes applicatives font confiance au WAF au lieu de le combattre. Les équipes sécurité peuvent se concentrer sur les menaces réelles au lieu de trier du bruit. Les auditeurs de conformité voient des contrôles documentés et justifiés au lieu de configurations par défaut avec des exceptions inexpliquées.

Pour les organisations soumises à NIS2 ou à des cadres réglementaires similaires, une méthodologie WAF documentée est exactement le type de mesure technique “appropriée et proportionnée” que les auditeurs veulent voir. Elle démontre que les contrôles de sécurité ne sont pas simplement déployés, mais qu’ils sont compris, maintenus et continuellement améliorés.

Azure docs: WAF best practices · Microsoft Sentinel overview

Par où commencer

Vous n’avez pas besoin de construire cette méthodologie de zéro. Commencez avec ce que vous avez :

1. Exportez vos WAF logs actuels depuis Log Analytics. Même une semaine de données vous donne un point de départ.
2. Identifiez les 10 règles les plus fréquemment déclenchées. Pour chacune, déterminez s’il s’agit d’un true positive, d’un false positive ou de bruit.
3. Documentez votre configuration WAF actuelle. Quelles règles sont activées ? Lesquelles sont exclues ? Quelqu’un sait-il pourquoi ?
4. Établissez une cadence de revue. Même des revues mensuelles représentent une amélioration massive par rapport à l’approche “déployer et oublier.”

L’objectif n’est pas la perfection, c’est un processus répétable qui s’améliore avec le temps. Chaque entreprise avec laquelle nous travaillons et qui adopte une approche structurée constate des améliorations mesurables : moins de false positives, des cycles de tuning plus rapides, et des WAF policies que l’équipe comprend et en qui elle a confiance.

Votre WAF n’est aussi bon que la méthodologie qui le soutient. Faites en sorte que ça compte.

Plus sur le blog

5 septembre 2024 | 6 min de lecture

Terraform AzureRM 4.0 : ce qui casse et comment migrer

Azure Terraform DevOps

15 février 2024 | 9 min de lecture

Bicep vs Terraform, pourquoi Terraform est notre choix par défaut (et quand Bicep l'emporte)

Azure Terraform Bicep

1 juin 2022 | 11 min de lecture

Container Apps vs AKS vs App Service : un cadre de decision

Azure Containers AKS