Un rapport WAAP typique s'ouvre avec «12 483 attaques bloquées ce mois» et continue avec des graphiques camembert géographiques et des listes des 10 principales IPs d'attaquants. Cela peut satisfaire un CISO au niveau des titres, mais ne répond pas aux questions architecturales et réglementaires : «Quel pourcentage de notre volume d'attaques frappe OWASP A03 Injection ?», «Quelles catégories OWASP API Top 10 montrent la pression la plus forte ?», «De quels pays, à quelles heures, sur quel argument observe-t-on des tentatives CWE-89 SQLi ?»
Ces questions nécessitent plus qu'un panneau d'analyse WAAP standard. Y répondre exige que l'ID d'attaque soit lié aux catégories OWASP, aux codes CWE et aux niveaux de risque à la source. Les produits WAAP courants traitent l'ID d'attaque comme un code alphanumérique ; ils ne le lient pas à une taxonomie organisée. Dans leur rapport, «attack id 942100» est ce qu'on voit — pas «OWASP A03».
Le deuxième manque est la corrélation de contexte. Par quel argument (champ de formulaire, paramètre de requête, champ de corps JSON) l'attaque est arrivée, quelle méthode HTTP, quelle taille de corps, quel user-agent, à quelle heure — ceux-ci vivent généralement dans des panneaux séparés. L'opérateur les recompose mentalement. Les questions composites comme «OWASP A03 × portée JSON body × ASN donné» ne reçoivent pas de réponse directe du rapport.
Le troisième manque est la vue direction et régulateur. Quand un auditeur demande «Dans les catégories OWASP Top 10, quel type d'attaque a culminé sur les six derniers mois ?», l'opérateur doit manuellement mapper les IDs d'attaque aux catégories OWASP et additionner les totaux de colonnes à la main.
Le reporting WAAP TR7 comble ces trois manques : les règles et IDs d'attaque sont pré-étiquetés dans les taxonomies OWASP Web Top 10, OWASP API Top 10 et CWE comme axe de rapport de premier niveau ; les combinaisons de corrélation signifiantes sont intégrées dans la structure du rapport ; et les vues par catégorie deviennent des slides standard pour le reporting direction et audit.
TR7 conçoit le rapport d'attaques WAAP comme la surface de reporting enterprise où la taxonomie de catégories, les axes de corrélation, le niveau de risque et l'intensité géographique convergent en un seul document.
L'ensemble de règles WAAP TR7 de 3 000+ règles est pré-mappé à OWASP Top 10 (2021) Web, OWASP API Security Top 10 (2023) et les codes CWE applicables. Quand un ID d'attaque arrive, le système sait déjà quelles catégories s'appliquent — les opérateurs ne les mappent pas manuellement.
Les attaques se rendent sous forme de sections séparées bar / camembert + tableau top-N sur 14 axes de corrélation. Les questions composites comme «catégorie X × argument Y × pays Z» reçoivent une réponse en lisant entre les sections du rapport, pas en recomposant des panneaux mentalement.
Au-delà des axes principaux, les combinaisons signifiantes (OWASP A03 × portée JSON body, OWASP A01 × host header spécifique, CWE-89 × distribution ASN, API4 × méthode HTTP) sont livrées comme slides standard du rapport. La plupart des questions d'audit et de direction reçoivent une réponse directe de ces combinaisons.
Le reporting WAAP TR7 s'exécute à l'intérieur de la même appliance qui sert le trafic. Le pipeline complet, des logs d'attaque à la génération PDF, vit sur l'équipement. Les produits WAAP courants nécessitent une plateforme de gestion séparée avec sa propre licence, capacité et coût opérationnel.
Rapports d'attaques WAAP avec 14 axes de corrélation, taxonomie OWASP / API / CWE, histogramme de risque à six niveaux, détail par host-group et PDF enterprise brandé.
Le rapport groupe les attaques par catégories OWASP Top 10 (2021) Web : A01 Broken Access Control, A02 Cryptographic Failures, A03 Injection, A04 Insecure Design, A05 Security Misconfiguration, A06 Vulnerable Components, A07 Authentication Failures, A08 Software & Data Integrity, A09 Logging Failures, A10 SSRF. Pour chaque catégorie, le nombre d'attaques, la distribution par niveau de risque, le top-N des paths et le top-N des pays se rendent sous forme de sections séparées.
Les attaques API se rendent selon OWASP API Security Top 10 (2023) : API1 Broken Object Level Authorization, API2 Broken Authentication, API3 Broken Object Property Level Authorization, API4 Unrestricted Resource Consumption, API5 Broken Function Level Authorization, API6 Unrestricted Access to Sensitive Business Flows, API7 Server-Side Request Forgery, API8 Security Misconfiguration, API9 Improper Inventory Management, API10 Unsafe Consumption of APIs.
Chaque attaque est étiquetée aux codes CWE applicables ; CWE-89 (SQL Injection), CWE-79 (XSS), CWE-77 (Command Injection), CWE-22 (Path Traversal), CWE-352 (CSRF), CWE-918 (SSRF) et d'autres apparaissent comme sections du rapport. Les chercheurs en sécurité et les équipes d'audit parlent dans des taxonomies standard.
Les attaques se rendent sous forme de sections séparées sur : IP source, pays, ville, user-agent, visiteur (IP + UA), taille du corps, temps d'inspection WAAP (wafTime), heure de la journée, ID d'attaque, portée de l'attaque (form / header / query / json / xml / path / raw / cookie), score de risque, nom de variable argument (arg), host header, path, méthode HTTP. Chaque axe : graphique en barres / camembert associé à un tableau top-N.
Les attaques se divisent en six niveaux de risque : structural, très élevé, élevé, moyen, faible, très faible. Le niveau structural couvre la détection d'anomalies structurelles propre à TR7 (abus de protocole HTTP, comportement bot, signatures DDoS-IP) qui se trouve en dehors de la plage de règles OWASP CRS.
Quand un vService porte plusieurs host groups, une section de rapport d'attaques dédiée s'ouvre par host group, et une section de résumé cross-group présente les host groups côte à côte. L'opérateur voit à la fois la pression globale de l'organisation et la vue par host-group dans le même rapport.
Le rapport PDF s'ouvre avec une couverture brandée contenant le logo de l'organisation, le nom du vService et la plage de dates. La section résumé s'ouvre avec l'intensité des attaques sur une carte thermique mondiale SVG complète, suivie de mini-graphiques de séries temporelles requêtes totales vs requêtes bloquées.
Au-delà des axes principaux, les combinaisons de catégories (OWASP A03 × portée JSON body, API4 × méthode HTTP, CWE-89 × ASN, structural × pays) se génèrent automatiquement comme sections standard du rapport. La plupart des questions d'audit et de régulateur reçoivent une réponse directe de ces combinaisons.
Le rapport WAAP est conçu conjointement avec le traitement des logs bruts, l'étiquetage taxonomique, la distribution par host-group, la génération multi-format et le comportement en cluster.
Les logs WAAP sont résumés en agrégats horaires par le moteur WafLogReporter à la fin de chaque heure. Les rapports à la demande et planifiés assemblent ces résumés pré-traités ; même les longues plages maintiennent le temps de génération de rapport borné.
Les étiquettes OWASP Top 10, OWASP API Top 10 et CWE sont attachées aux règles elles-mêmes, de sorte que quand une attaque atteint le rapport la catégorisation est déjà connue. Quand OWASP publie une nouvelle révision, les étiquettes se mettent à jour avec l'ensemble de règles.
Le rapport suit une hiérarchie numérotée : 1. Résumé, 2. Rapport WAAP [nom du host group], 2.1, 2.2 sous-sections pour chaque dimension. Plusieurs host groups continuent en 3., 4., etc. L'ordre des sections donne la priorité à argument → pays → path, puis alphabétique.
PDF (A4, couverture brandée, sections de catégories et axes, carte thermique mondiale), XLSX (un onglet par section), HTML (s'ouvre depuis la console opérateur). Le même moteur produit les trois formats en parallèle ; le choix du format ne modifie pas le contenu du rapport.
Dans un cluster haute disponibilité, un rapport WAAP planifié donné est généré et envoyé une seule fois, depuis le nœud actif uniquement. Pas de livraison en double ; les rapports ad hoc s'exécutent sur les données visibles par le nœud auquel l'opérateur est connecté.
Depuis un ID d'attaque ou un path dans le rapport, les opérateurs sautent directement à la règle WAAP qui s'est déclenchée, aux suggestions d'apprentissage associées, et à la vue de trafic en direct. Le rapport agit comme point de départ d'un workflow opérationnel, pas comme un document statique.
Le bureau du CISO peut répondre «Quelle catégorie OWASP Top 10 a montré la plus forte pression ce mois, et sur quel path ?» directement depuis le rapport. Les comptages d'attaques par catégorie, la distribution des risques et l'intensité géographique sont livrés en PDF brandé au conseil d'administration.
Dans les audits bancaires, gouvernementaux et d'infrastructures critiques, l'auditeur demande l'historique des attaques découpé par catégorie OWASP et code CWE. Le rapport TR7 présente ces éléments comme sections standard — le dossier d'audit n'est pas préparé à la main.
Les chercheurs en sécurité enquêtent sur quel argument, quels ASNs et quelles heures un type d'attaque spécifique (ex. tentatives SQLi) frappe. Les sections de combinaisons cross-axis (CWE-89 × argument × ASN × heure) sont livrées directement dans le rapport.
Les fournisseurs de services exécutent un vService séparé par client final et livrent le rapport mensuel d'attaques WAAP de chaque tenant avec leur propre logo, plage de dates et langue. Le même moteur produit des rapports pour des dizaines de tenants en parallèle.
Taxonomie de 3 000+ règles, 14 axes de corrélation, 6 niveaux de risque, combinaisons de catégories signifiantes et couverture PDF brandée. Laissez-nous vous guider dans une démo en direct sur votre propre profil WAAP.