Dans une approche WAAP traditionnelle, une signature correspondante bloque immédiatement la requête. Cela semble rapide, mais dans les déploiements réels cela augmente le risque de faux positifs. Le même pattern peut représenter une attaque dans un contexte et un format de données légitime dans un autre. C'est pourquoi traiter chaque règle avec la même sévérité est rarement la bonne approche.
Un deuxième défi est la complexité de gestion des grands ensembles de règles. Lorsqu'il n'est pas clair quelle règle s'exécute dans quelle portée, à quelle catégorie d'attaque elle appartient, quel score elle produit et sur quels services elle est active, les équipes opérationnelles finissent par exécuter le WAAP soit trop permissivement soit trop agressivement.
La surface d'attaque moderne n'est plus limitée au SQL injection classique et au XSS. Les endpoints API, les champs de corps JSON, les requêtes GraphQL, la manipulation JWT, les requêtes NoSQL, les vulnérabilités des moteurs de templates, la désérialisation et les nouvelles variantes de CVE apparaissent tous dans le même flux de trafic. Si le moteur WAAP ne peut pas séparer cette variété par portée et catégorie, la visibilité en souffre.
La bonne approche consiste à exécuter les signatures via un modèle de décision basé sur le score. Chaque règle doit produire son propre poids, les seuils du service doivent évaluer les scores accumulés, l'état des règles doit être gérable en monitor ou blocage, et les besoins personnalisés doivent être remplaçables au niveau global ou pool.
TR7 Signatures & Scoring WAAP offre ce modèle : il rend 3 000+ règles de production, 32 catégories d'attaques et 7 portées d'inspection gérables via une logique de score, de seuil et de remplacement.
TR7 applique la décision WAAP via la correspondance multi-patterns, des seuils basés sur le score, un modèle de remplacement à deux niveaux et un ensemble de règles d'attaque enrichi.
TR7 exécute de grands ensembles de règles efficacement via une approche de correspondance multi-regex. Les règles peuvent être compilées en shards de sorte que seules les portions modifiées sont reconstruites lors des mises à jour.
Chaque règle peut produire un score — 2, 4, 6 ou 8. Ces scores sont combinés avec une valeur de seuil par service, de sorte que l'image de risque globale est évaluée plutôt qu'un seul signal faible.
Les règles personnalisées globales et les règles personnalisées de pool sont maintenues dans des espaces de noms d'identifiants séparés. Cela permet à la politique organisationnelle partagée et aux exceptions spécifiques au client ou au service de coexister sans conflits.
TR7 ajoute des règles enrichies pour les API, JWT, GraphQL, NoSQL, prompt injection, injection de templates et les variantes d'attaques spécifiques aux CVE au-delà des signatures web classiques. Cette couche élargit la couverture sur la surface applicative moderne.
Signatures & Scoring WAAP rend un large ensemble de règles de production gérable grâce aux contrôles de score, portée et état par service.
TR7 est livré avec 3 000+ règles WAAP préparées pour un usage en production. Les familles d'attaques principales — SQL injection, XSS, path traversal, SSRF, XXE, désérialisation, injection de templates, lecture de fichiers, écriture de fichiers, exécution de commandes et divulgation d'informations — sont couvertes. Les règles sont gérées non pas seulement comme une liste de patterns plats mais avec les métadonnées de catégorie, score, portée et cible. Cette structure combine une protection large avec un contrôle opérationnel.
Les règles sont organisées en 32 catégories d'attaques : contournement du contrôle d'accès, contournement d'authentification, abus de logique métier, empoisonnement du cache, injection CRLF, injection de requêtes de données, évasion d'encodage, inclusion de fichiers, HTTP smuggling, redirection ouverte, pollution de paramètres, prompt injection, pollution de prototype, manipulation de session et plus encore. Cette classification permet aux équipes sécurité de comprendre quelles familles d'attaques se déclenchent le plus souvent. La gestion des règles fonctionne via des rubriques de risque significatives plutôt que des milliers d'entrées brutes.
Les règles TR7 peuvent opérer sur les champs path, query, header, form, JSON, XML et raw. Chaque règle déclare exactement sur quelle portée elle correspond. Une signature rédigée pour le corps JSON ne s'exécute pas inutilement sur le header, et une règle centrée sur le chemin n'est pas appliquée incorrectement au trafic du corps. La séparation des portées importe à la fois pour la précision et les performances.
Chaque règle produit un score spécifique évalué par rapport au seuil du service. Les correspondances à faible risque peuvent ne produire qu'une entrée de log, tandis qu'un score total plus élevé résulte en une décision de blocage. Cette approche considère le comportement de risque global plutôt que de traiter une seule correspondance de signature comme un verdict absolu. L'ajustement du seuil par service permet de protéger différentes applications à différentes sensibilités.
Chaque règle peut s'exécuter en mode enabled, disabled ou monitor. En mode enabled, la règle contribue au scoring et aux décisions de blocage ; en mode disabled, elle est inactive ; en mode monitor, elle ne produit que des sorties log. Les règles nouvelles ou incertaines peuvent d'abord être observées en mode monitor. Cela rend les transitions de politique dans les services de production significativement plus sûres.
Le remplacement global définit la politique WAAP pour l'ensemble de l'organisation, tandis que le remplacement pool définit un comportement différent pour un service ou client spécifique. Une règle peut rester active globalement tout en étant placée en mode monitor pour un pool particulier, ou avoir son score ajusté là. Cette structure équilibre la gestion centralisée avec les exigences réelles par service. Des espaces de noms d'identifiants séparés réduisent les conflits de règles personnalisées.
La couche enrichie TR7 ajoute des familles d'attaques modernes au-delà des signatures web classiques. La manipulation JWT, le DoS imbriqué GraphQL, l'injection de requêtes NoSQL, le prompt injection, les patterns de chaîne d'approvisionnement et les attaques sur la surface des conteneurs et serverless sont adressés comme groupes de règles dédiés. Cette couche cible les architectures API et plateformes modernes — pas seulement les formulaires web legacy. La protection WAAP s'aligne plus étroitement sur la façon dont les applications actuelles sont construites.
TR7 peut inclure des signatures de variantes dédiées pour les attaques axées sur les CVE telles que Log4Shell, Spring4Shell et Shellshock. Les formes encodées, obfusquées ou à syntaxe variée sont capturées par des patterns distincts. Lorsqu'un CVE est publié, l'ajout de règles personnalisées et le hot reload réduisent le temps de réponse. Cette vitesse opérationnelle est critique comme première ligne de défense après une divulgation zero-day.
Pour chaque requête, TR7 peut transporter les identifiants de règles déclenchées, le score et les informations de la partie pertinente à l'intérieur du payload WAAP. Ces données aident les examinateurs d'incidents à comprendre quelle règle s'est déclenchée et pourquoi. L'opérateur voit non seulement un résultat « bloqué » mais la chaîne de scores complète qui a conduit au blocage. Cette visibilité est importante pour l'analyse des faux positifs.
Les événements WAAP peuvent être journalisés en formats CEF et JSON. Les champs d'identifiant de règle, catégorie d'attaque, score, portée et métadonnées sont disponibles côté SIEM. Les équipes sécurité peuvent connecter les événements WAAP aux systèmes centraux d'alertes, de corrélation et de reporting. Le format de log soutient les processus de conformité et de réponse aux incidents.
Les règles peuvent être croisées avec les standards de sécurité et les taxonomies d'attaques. Les liens CWE, CAPEC, MITRE ATT&CK et OWASP Web/API Top 10 connectent un événement WAAP technique au langage d'audit et de risque. Cela permet aux équipes SOC, sécurité applicative et conformité de discuter du même événement dans un cadre commun. Le reporting ne se limite pas à un identifiant de signature brut.
TR7 peut recharger uniquement les portions modifiées du moteur WAAP plutôt que de redémarrer l'ensemble de la pile lors d'une mise à jour de règle. Cela rend l'ajout de nouvelles signatures ou la mise à jour de règles personnalisées plus rapide et moins perturbateur. Les ensembles de règles mis à jour peuvent être mis en vigueur sans redémarrage de conteneur. Cette vitesse opérationnelle est décisive lors de la réponse d'urgence aux CVE.
Le moteur de signatures WAAP est exploité aux côtés des modes de compilation, de la distribution des scores, de la densité des portées, des espaces de noms d'identifiants de règles personnalisées, des statistiques RRD et du comportement hot reload.
La compilation des règles peut s'exécuter en modes de shards all, poly ou mono. Dans l'approche mono shardée, les règles sont divisées en partitions pouvant être compilées en parallèle. Ce modèle aide à réduire le temps de compilation et l'impact des mises à jour pour les grands ensembles de règles.
La factory de règles WAAP TR7 opère avec un modèle ciblant une capacité maximale de 10 000 règles. Ce plafond fournit de la marge d'expansion pour les règles de production, la couche enrichie et les règles personnalisées clients. Les opérateurs doivent surveiller l'équilibre entre performances et couverture à mesure que l'ensemble de règles croît.
Les règles produisent des scores différents selon leur poids. Les scores de 2 et 4 représentent des résultats à signal faible ; 6 et 8 portent des signaux de risque plus forts. Certaines règles critiques sélectionnées peuvent être traitées avec une urgence plus élevée. La décision de seuil est façonnée par l'effet combiné de ces scores accumulés.
Les règles opèrent à des densités variables sur les champs path, query, header, form, JSON, XML et raw. Les champs query et form portent des concentrations plus élevées pour les surfaces d'attaque classiques, tandis que les champs JSON et raw prennent de l'importance pour le trafic API moderne. La distribution des portées aide les équipes à comprendre quelles surfaces de trafic génèrent le plus de signaux de protection.
Les règles personnalisées globales et les règles personnalisées de pool sont générées dans des plages d'identifiants séparées. L'espace de noms global porte les règles partagées à l'échelle de l'organisation ; l'espace de noms pool porte les règles spécifiques au service ou au client. Cette séparation réduit les conflits de règles et facilite l'audit du comportement de remplacement.
Les comptages de déclenchements de règles peuvent être agrégés par catégorie et présentés sous forme de graphiques. Cela permet de voir quelles familles d'attaques apparaissent le plus souvent, quels services produisent le plus de signaux de risque et comment les changements de politique affectent la distribution au fil du temps. Les statistiques transforment le WAAP d'un simple bloqueur en capteur de sécurité apprenant.
Les équipes API financières peuvent étendre la couverture classique alignée OWASP avec des règles d'attaques JWT, GraphQL, NoSQL et API modernes. La couche enrichie TR7 fournit une portée de signatures mieux adaptée à la surface API actuelle.
Les équipes bancaires peuvent observer des règles spécifiques en mode monitor d'abord, puis ajuster les valeurs de seuil par service pool. Cela leur permet d'établir un équilibre plus contrôlé entre l'application agressive de la sécurité et le trafic utilisateur légitime.
Les portails gouvernementaux peuvent ajouter des règles regex personnalisées ciblant les champs form et JSON. Lorsque des patterns de données sensibles ou des entrées inattendues apparaissent, un score et une entrée de log déclenchent un workflow d'investigation.
Les équipes SaaS peuvent appliquer des règles de base globales à tous les tenants tout en définissant des remplacements personnalisés pour des clients ou pools spécifiques. Les espaces de noms d'identifiants séparés garantissent que les règles spécifiques aux clients ne conflictent jamais avec l'ensemble de règles partagé.
3 000+ règles de production, 32 catégories d'attaques et un modèle de décision basé sur le score. Parcourons ensemble son fonctionnement dans votre propre environnement.