Vous êtes-vous déjà demandé quelle est réellement l’efficacité de votre WAF (Firewall d’applications web) ? Vous êtes-vous demandé s’il arrête vraiment les attaques ? Combien de faux positifs produit-il ? Un changement récent a-t-il amélioré ou nui aux capacités de détection existantes ?
La plupart des technologies WAF sont assez difficiles à gérer, avec de longues listes d’expressions régulières que personne n’aime vraiment maintenir. Ainsi, lorsque vous partez d’une position négative, il est naturel que ce genre de questions vous amène à envisager de ne pas utiliser de WAF du tout.
Nous avons décidé d’aborder ces questions avec un framework d’efficacité du WAF, qui fait l’objet de cet article. Le framework fournit un moyen standardisé de mesurer l’efficacité des capacités de détection d’un WAF grâce à une vérification et une validation continues. Cela aide à identifier les lacunes et fournit une boucle de feedback pour les améliorations et la maintenance. Il intègre des évaluations d’attaques simulées pour tester différents types d’attaque et condense les résultats en scores globaux. Ces scores alimentent un flux de travail d’amélioration continue qui peut être utilisé comme vérification ponctuelle de l’efficacité actuelle ou pour analyser les tendances de l’efficacité à mesure qu’elle évolue au fil du temps.
Notre approche
Un WAF inspecte le trafic HTTP/S avant qu’il n’atteigne un serveur d’application. Vous pouvez considérer un WAF comme l’intermédiaire entre une application et un client qui analyse toute la communication entre eux. Il surveille le trafic suspect et anormal et protège contre les attaques en bloquant les requêtes selon des règles spécifiques afin que le trafic indésirable n’atteigne jamais votre application.
Une requête HTTP/S comprend :
Un domaine (comme fastly.com)
Une ressource (comme /cat.png)
Une méthode (GET, POST, PUT, etc.)
En-têtes (informations supplémentaires envoyées au serveur, également un endroit où les hackers peuvent mettre des éléments malveillants)
Il existe également un corps de requête facultatif ; les requêtes GET n’ont généralement pas de corps, tandis que les requêtes POST — qui peuvent envoyer des informations légitimes ou injecter des éléments indésirables — ont tendance à contenir un corps.
Pour visualiser cela, voici une requête GET HTTP 1.1 pour fastly.com/FR/cat.png:
Et voici un exemple de requête POST avec un corps JSON :
Qu’il s’agisse de l’URL, du corps, des cookies ou d’autres en-têtes HTTP, les hackers cherchent toujours des endroits dans une requête pour préparer le terrain à l’exploitation. C’est pourquoi l’un des principes fondamentaux du framework consiste à tester si les charges utiles sont détectées à différentes positions dans une requête.
Comme pour toutes les technologies de sécurité, lorsque les méthodes de détection se renforcent, les hackers cherchent des moyens de contourner les détections afin de continuer à atteindre leurs objectifs. Avec les WAF, une méthode d’évasion populaire consiste à encoder une charge utile de manière à contourner la détection. C’est pourquoi nous incluons également des tests qui intègrent un mélange de techniques d’encodage. Nous injectons chaque charge utile prédéfinie dans chaque position de charge utile, et les versions brutes et encodées de la requête sont toutes deux envoyées à la cible, offrant ainsi un moyen précieux de tester la couverture de détection, même en présence de techniques d’évasion.
Mais, bien sûr, une fée magique des charges utiles ne fait pas simplement tomber des charges utiles du ciel — et les charges utiles pertinentes peuvent évoluer au fil du temps à mesure que les méthodes d’attaque évoluent. Nous vous recommandons PayloadsAllTheThings, PortSwigger, Nuclei, exploit-db et Twitter comme point de départ pour constituer une liste de charges utiles, ainsi que pour mettre régulièrement à jour vos listes de charges utiles.
Vous n’avez pas besoin d’une application vulnérable pour tester l’efficacité d’un WAF. L’objectif est de mesurer l’efficacité des capacités de détection d’un WAF, et non de tester si des vulnérabilités sont présentes dans les applications elles-mêmes. Après tout, l’état final idéal avec un WAF est que les vulnérabilités de vos applications ne conduisent plus à des incidents ; valider que votre WAF protège contre des classes d’attaques signifie que vous n’avez plus à vous soucier de détails mineurs comme des vulnérabilités spécifiques. Par conséquent, l’utilisation d’un simple service de requête et de réponse HTTP comme https://httpbin.org est suffisante à cette fin.
Pour chaque type d’attaque, nous testons deux cas différents pour évaluer l’efficacité du WAF : les vrais positifs et les faux positifs. Un test de vrai positif permet de déterminer si les charges utiles d’attaque sont correctement identifiées. Un test de faux positif permet de déterminer si des charges utiles acceptables sont identifiées à tort.
Pour déterminer si le WAF identifie correctement une requête, nous examinons le code d’état de la réponse. La plupart des solutions WAF devraient permettre de créer un code d’état de réponse personnalisé pour les requêtes bloquées (pour un exemple, consultez notre documentation à ce sujet). Si votre solution WAF n’est pas capable de définir des codes de réponse personnalisés, il vaut la peine de reconsidérer cet investissement.
Dans le contexte de notre framework d’efficacité du WAF, nous recherchons spécifiquement la réception d’un code de réponse 406 Not Acceptable lorsqu’une requête est bloquée. Dans un cas de test de vrai positif, la réception d’un code de réponse autre que 406 est considérée comme un faux négatif. À l’inverse, dans un cas de test de faux positif, la réception d’un code de réponse autre que 406 est considérée comme un vrai négatif. Ces résultats sont utilisés pour calculer un score d’efficacité par type d’attaque ; ces scores sont ensuite agrégés en un score global de l’efficacité du WAF pour tous les types d’attaques.
Évaluation des résultats
Une fois que vous avez généré des scores d’efficacité individuels et agrégés, comment transformer ces métriques en connaissances pouvant éclairer un plan d’action ? Un prisme important à travers lequel vous devez évaluer ces résultats est celui des priorités de votre organisation. Votre organisation préfère-t-elle maximiser le trafic vers son application, même si certaines attaques passent entre les mailles du filet, ou préfère-t-elle bloquer autant d’attaques que possible, même si cela entraîne une réduction du trafic ? D’après ce que nous avons observé dans l’ensemble de notre clientèle, la préférence est généralement de maximiser le trafic : une réduction du trafic peut avoir un impact sur les revenus, ce qui constitue la pire conséquence du point de vue de l’entreprise.
En pratique, une protection infaillible contre les attaques web est impossible — à moins de bloquer littéralement chaque requête, ce qui va à l’encontre de l’objectif fondamental d’exploiter une application sur Internet. C’est pourquoi trouver le juste équilibre entre les faux positifs et les faux négatifs est un facteur clé pour déterminer l’efficacité d’une solution WAF. Chaque outil de sécurité génère des faux positifs et des faux négatifs. S’il était possible d’être certain à 100 % dans tous les cas, la sécurité serait un problème résolu.
Plus le taux de faux positifs est élevé, plus vous êtes susceptible de détecter une attaque — mais le trafic légitime sera incorrectement identifié comme une attaque, un problème qui ne fera que s’aggraver en mode de blocage. De plus, un faux positif s’apparente à une fausse alerte. Par nature, les humains commencent à ne plus prêter attention aux alertes après un nombre suffisant de faux positifs, ce qui augmente non seulement la probabilité qu’un véritable trafic d’attaque reste sans réponse, mais érode également le retour sur investissement de votre WAF. Il y a aussi un coût cognitif à payer : gérer de fausses alertes conduit à l’épuisement professionnel, ce qui rend plus difficile le fait de bien travailler et peut entraîner un turnover plus important au sein des équipes.
À l’inverse, un taux plus élevé de faux négatifs signifie une probabilité plus faible de faux positifs, ce qui se traduit par des alertes de haute fidélité — mais signifie également qu’il y a plus de chances que le trafic d’attaque réel ne soit pas détecté.
Pour tenir compte de l’écart entre ces classes de résultats négatifs et positifs, notre framework d’efficacité du WAF intègre un indicateur appelé balanced accuracy. La balanced accuracy tient compte du déséquilibre entre les classes et constitue une bonne mesure lorsque vous accordez la même importance à la prédiction correcte des cas négatifs et positifs. Votre rôle consiste à utiliser ces métriques de manière judicieuse en fonction de votre activité et des systèmes que vous protégez. Nous verrons comment la balanced accuracy est calculée dans une section suivante.
Automatiser les tâches pénibles
Les tests manuels sont loin d’être faciles et peuvent rapidement devenir une tâche irréalisable lorsque vous essayez de prendre en compte toutes les façons de tester et de mesurer les résultats. C’est particulièrement vrai lorsque vous travaillez avec de grands ensembles de données de charges utiles d’attaque. Les tests doivent être reproductibles et flexibles, afin de vous permettre de vous concentrer sur les résultats pour adapter votre stratégie AppSec web sur la base de preuves tangibles.
À cette fin, nous avons choisi un projet open source appelé Nuclei comme base du framework. Nuclei prend en charge nombre des tâches de test manuelles, répétitives et fastidieuses grâce à l’utilisation de modèles basés sur YAML. Les modèles Nuclei définissent la manière dont les requêtes seront envoyées et traitées. Ils sont également entièrement configurables, ce qui vous permet de configurer et de définir chaque aspect des requêtes qui seront envoyées.
Étant donné qu’il est essentiel d’acquérir de nouvelles connaissances pour alimenter les boucles de feedback, chaque requête est enregistrée et journalisée au format JSON. Les logs incluent des paires requête/réponse et des métadonnées supplémentaires. Vous pouvez utiliser ces logs pour les tableaux de bord, les comparaisons historiques et d’autres informations qui vous aident à améliorer votre stratégie WAF. Par exemple, nous avons importé les résultats dans un bucket Google Cloud Storage (GCS), qui sert de jeu de données pour créer une table dans BigQuery ; à partir de là, nous avons connecté les données à Data Studio pour générer des rapports informatifs avec des scores.
Puisque l’automatisation permet la scalabilité et la répétabilité — et vous évite, à vous et à votre équipe, des tâches fastidieuses —, nous vous recommandons d’assembler ces étapes pour créer un pipeline CI/CD afin d’effectuer des tests d’efficacité du WAF. Vous pouvez définir un flux de travail avec les étapes suivantes :
Créez votre cible de test
Exécuter des tests d’efficacité
Enregistrez les résultats dans le back-end de votre choix
Générer des rapports
Répétez l’opération à la cadence de votre choix
Lancez-vous
Pour partager cette capacité avec l’ensemble de la communauté de la sécurité, l’équipe Fastly recherche dans le domaine de la sécurité a créé un projet open source appelé wafefficacy, qui comprend le code initial et les modèles dont vous avez besoin pour démarrer. Le projet fournit des exemples standard pour l’exécution de commandes (cmdexe), l’injection SQL (sqli), la traversée (traversal) et le cross-site scripting (xss) — vous permettant de lancer immédiatement des tests d’efficacité pour les principaux types d’attaques.
Il y a deux exigences à vérifier avant d’effectuer un test d’efficacité :
Le WAF que vous testez doit être configuré pour bloquer les attaques
Un code d’état de réponse doit être défini lorsqu’une requête est bloquée. Par défaut, wafefficacy vérifie la réception de 406 Not Acceptable.
Une fois la configuration initiale terminée, vous pouvez exécuter le binaire exécutable depuis le répertoire du projet en fournissant une URL ou un hôte cible :./wafefficacy run -u https://example.com
Une fois l’évaluation terminée, le script affichera les résultats du score dans la sortie standard suivante :
Score d'efficacité
Voyons comment nous calculons les scores d’efficacité en utilisant l’accuracy équilibrée comme métrique.
Nous commençons par une matrice de confusion:
Dans ce qui précède, le « positif » ou le « négatif » dans TP/FP/TN/FN fait référence à la prédiction effectuée, et non à la classe réelle. (Par conséquent, un « faux positif » est un cas où nous avons prédit à tort un résultat positif.)
L’exactitude équilibrée repose sur deux métriques couramment utilisées :
La sensibilité (également appelée taux de vrais positifs) répond à la question : « Combien de cas positifs ai-je détectés ? »
La spécificité (également appelée taux de vrais négatifs ou 1 - taux de faux positifs) répond à la même question : « Combien de cas négatifs ai-je détectés ? »
Prenons un exemple pour illustrer comment la précision équilibrée peut être un meilleur indicateur des détections dans un contexte de classes déséquilibrées. Supposons que nous simulions des attaques par injection SQL contre un WAF et que nous obtenions les résultats présentés dans la matrice de confusion ci-dessous :
Cette matrice de confusion illustre que, sur 750 cas de test vrais positifs, 700 ont été signalés comme vrais positifs, tandis que 50 ont été signalés comme faux négatifs. Par ailleurs, sur 105 cas de test faux positifs, 5 ont été signalés comme faux positifs, tandis que 100 ont été signalés comme vrais négatifs.
À l’aide de ces informations, voici le calcul de l’exactitude équilibrée :
D’après le calcul de la précision équilibrée, le WAF est efficace à environ 94,3 % pour assurer une protection contre les attaques par injection SQL.
À des fins de comparaison, supposons que nous ayons testé un autre WAF et que les résultats de faux positifs aient été inversés. Par exemple, sur 105 cas de test de faux positifs, 100 ont été signalés comme des faux positifs, tandis que 5 ont été signalés comme de vrais négatifs.
Cela modifierait le pourcentage de spécificité comme suit :
Ce qui modifierait également le pourcentage de précision équilibrée comme suit :
Sur la base de l’exactitude équilibrée, nous pouvons affirmer avec confiance que le premier WAF offre une meilleure protection contre les attaques par injection SQL (94,3 %) que le second (49,1 %).
Résumé
Il est préférable de tester votre sécurité avant que quelqu’un d’autre ne le fasse. Notre framework d’efficacité du WAF adopte le principe de la vérification et de la validation continues. Grâce à l’utilisation de simulations d’attaque automatisées, il valide les contrôles de sécurité techniques, identifie les lacunes et fournit un moyen de rendre compte et de mesurer l’efficacité des outils. En fait, la même méthodologie peut être appliquée à tout outil de sécurité pertinent pour votre entreprise ou vos systèmes.
Effectuer des tests d’efficacité de cette manière permet d’introduire des tests contrôlés et sûrs qui vous permettent d’observer dans quelle mesure vos contrôles réagiront dans des conditions réelles. Cela peut être un outil extrêmement précieux pour introduire une boucle de rétroaction afin de vous aider à comprendre si un contrôle a été mis en œuvre correctement et efficacement.
Nous vous encourageons à tirer parti de notre processus et de nos outils afin de mieux comprendre et, nous l’espérons, d’améliorer l’efficacité de votre WAF.
Si vous souhaitez en savoir plus sur la manière dont nous pouvons répondre à vos besoins en matière de sécurité des applications web, consultez notre présentation des produits de sécurité. Et si vous souhaitez travailler avec nous, découvrez nos offres d'emploi.
Le livret de sécurité des applications natives cloud
Comprenez les techniques de plus en plus sophistiquées que les hackers utilisent pour cibler les applications web d’entreprise et comment les prévenir. Ce guide aide les équipes d’ingénierie, d’opérations et de sécurité à comprendre le « comment » et le « pourquoi » de la sécurité des applications cloud natives. Télécharger l’e-book