Capability

WAAP Attack Reporting

TR7 WAAP produces attack reports per host group across 14 correlation axes plus a taxonomy layer bound to a 3000+ rule set and to OWASP / API Top 10 / CWE categories — branded PDFs, deep tables, meaningful category combinations.

TR7 WAAP Attack Reporting reframes modern application attacks as a single enterprise document — not a bare attack count, but where the attack came from, how it landed, which rule set fired, which taxonomy category it violated and at what risk level. The engine slices attacks across 14 correlation axes: source IP, country, city, user-agent, visitor (IP + UA composite), body size, WAAP inspection time (wafTime), hour-of-day, attack ID, attack scope (form / header / query / json / xml / path / raw / cookie), risk score, argument variable name, host header, path, HTTP method. Each axis produces a bar / pie chart paired with a top-N table. On top of those axes sits the TR7 WAAP's taxonomy layer over its 3000+ rule set. Every attack is automatically tagged with the relevant **OWASP Top 10 (2021) Web** category (from A01 Broken Access Control through A10 SSRF), the relevant **OWASP API Security Top 10 (2023)** category (from API1 Broken Object Level Auth through API10 Unsafe Consumption), and applicable **CWE codes**. The report groups by these categories, and **meaningful combinations** (e.g. "OWASP A03 Injection × JSON body scope", "CWE-89 SQLi attempts by ASN") become first-class report sections. The summary section opens with attack intensity rendered as an SVG world heat map, total-request vs blocked-request mini time-series charts, per-host-group attack distribution, and a top-5 attack-ID table. A dedicated section then opens per host group, detailing that group's attacks across the 14 axes and the taxonomy layer. The risk histogram splits attacks into six tiers: **structural**, **very high**, **high**, **medium**, **low**, **very low**. The structural tier covers TR7's own structural anomaly detection (HTTP protocol abuse, bot behaviour, DDoS-IP signatures) that sits outside the OWASP CRS rule range. The result: a TR7 WAAP report serves the technical security team (which rule, which argument, which path) and the executive / regulator reporting need (OWASP category, CWE code, geographic distribution, month-over-month trend) in one document.

3000+
Rule set — labelled with OWASP / API Top 10 / CWE
14
Attack correlation axes
6
Risk tiers — from structural to very low

Can the report tell us which category broke what, and why — not just attack counts?

A typical WAAP report opens with "12,483 attacks blocked this month" and continues with geographic pie charts and top-10 attacker IP lists. That can satisfy a CISO at the headline level, but it doesn't answer the architectural and regulator-level questions: "What percentage of our attack volume hits OWASP A03 Injection?", "Which OWASP API Top 10 categories show the heaviest pressure?", "From which countries, at which hours, on which argument do we see CWE-89 SQLi attempts?"

Those questions need more than a standard WAAP analytics panel. Answering them requires the attack ID to be bound to OWASP categories, CWE codes and risk levels at the source. Common WAAP products treat attack ID as an alphanumeric code; they don't bind it to a curated taxonomy. In their report, "attack id 942100" is what you see — not "OWASP A03".

The second gap is context correlation. Which argument (form field, query parameter, JSON body field) the attack arrived through, which HTTP method, what body size, which user-agent, at what hour — these usually live in separate panels. The operator stitches them together mentally. Composite questions like "OWASP A03 × JSON body scope × given ASN" are not directly answered by the report.

The third gap is the executive and regulator view. When an auditor asks "In the OWASP Top 10 categories, which attack type peaked over the last six months?", the operator must manually map attack IDs to OWASP categories and add column totals by hand.

TR7 WAAP reporting closes all three gaps: rules and attack IDs are pre-labelled into OWASP Web Top 10, OWASP API Top 10 and CWE taxonomies as a first-class report axis; meaningful correlation combinations are built into the report structure; and category-by-category views become standard slides for executive and audit reporting.

Our approach

TR7 designs the WAAP attack report as the enterprise reporting surface where category taxonomy, correlation axes, risk level and geographic intensity converge into one document.

Rules are pre-labelled into OWASP / API / CWE taxonomies

The 3000+ rule TR7 WAAP rule set is pre-mapped to OWASP Top 10 (2021) Web, OWASP API Security Top 10 (2023) and the applicable CWE codes. When an attack ID arrives, the system already knows which categories apply — operators don't manually map them.

Correlation axes are built into the report structure

Attacks render as separate bar / pie + top-N table sections across 14 correlation axes. Composite questions like "category X × argument Y × country Z" are answered by reading between report sections, not by stitching panels in the operator's head.

Meaningful category combinations are first-class report sections

Beyond the primary axes, meaningful combinations (OWASP A03 × JSON body scope, OWASP A01 × specific host header, CWE-89 × ASN distribution, API4 × HTTP method) ship as standard report slides. Most audit and executive questions are answered directly by these combinations.

No second management VM or analytics platform required

TR7 WAAP reporting runs inside the same appliance that serves the traffic. The full pipeline from attack logs to PDF generation lives on-device. Common WAAP products require a separate management platform with its own license, capacity and operations cost.

Capabilities

WAAP attack reporting with 14 correlation axes, OWASP / API / CWE taxonomy, a six-tier risk histogram, per-host-group detail and branded enterprise PDF.

OWASP Top 10 Web category breakdown

The report groups attacks by OWASP Top 10 (2021) Web categories: 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. For each category, attack count, risk-level distribution, top-N path and top-N country render as separate sections.

OWASP API Security Top 10 category breakdown

API attacks render against 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.

CWE code-level slicing

Every attack is tagged to applicable CWE codes; CWE-89 (SQL Injection), CWE-79 (XSS), CWE-77 (Command Injection), CWE-22 (Path Traversal), CWE-352 (CSRF), CWE-918 (SSRF) and others appear as report sections. Security researchers and audit teams speak in standard taxonomies.

14 attack correlation axes

Attacks render as separate sections across: source IP, country, city, user-agent, visitor (IP + UA), body size, WAAP inspection time (wafTime), hour-of-day, attack ID, attack scope (form / header / query / json / xml / path / raw / cookie), risk score, argument variable name (arg), host header, path, HTTP method. Each axis: bar / pie chart paired with a top-N table.

Six-tier risk histogram

Attacks split into six risk tiers: structural, very high, high, medium, low, very low. The structural tier covers TR7-specific structural anomaly detection (HTTP protocol abuse, bot behaviour, DDoS-IP signatures) that sits outside the OWASP CRS rule range.

Per-host-group + cross-group rollup

When a vService carries multiple host groups, a dedicated attack-report section opens per host group, and a cross-group summary section presents host groups side by side. The operator sees both the organization-wide pressure and the per-host-group view in the same report.

Branded PDF cover + geographic heat map

The PDF report opens with a branded cover containing organization logo, vService name and date range. The summary section opens with attack intensity on a full SVG world heat map, followed by total-request vs blocked-request mini time-series charts.

Meaningful category combinations as standard sections

Beyond the primary axes, category combinations (OWASP A03 × JSON body scope, API4 × HTTP method, CWE-89 × ASN, structural × country) generate automatically as standard report sections. Most audit and regulator questions get a direct answer from these combinations.

Operational depth

The WAAP report is designed alongside raw-log processing, taxonomy tagging, host-group distribution, multi-format generation and cluster behaviour.

01

Hourly summary generation

WAAP logs are summarized into hourly aggregates by the WafLogReporter engine at the end of each hour. On-demand and scheduled reports stitch these pre-processed summaries; even long ranges keep report generation time bounded.

02

Taxonomy layer defined on the rules themselves

OWASP Top 10, OWASP API Top 10 and CWE tags are attached to the rules themselves, so when an attack reaches the report the categorization is already known. When OWASP publishes a new revision the tags update with the rule set.

03

Host-group section hierarchy

The report follows a numbered hierarchy: 1. Summary, 2. [Host group name] WAAP report, 2.1, 2.2 sub-sections for every dimension. Multiple host groups continue 3., 4., and so on. Section order prioritizes argument → country → path, then alphabetical.

04

Three formats from the same data source

PDF (A4, branded cover, category and axis sections, world heat map), XLSX (one tab per section), HTML (opens from the operator console). The same engine produces all three formats in parallel; format choice does not change the report's content.

05

Cluster-wide single generation

In a high-availability cluster, a given scheduled WAAP report is generated and sent once, from the active node only. No duplicate delivery; ad-hoc reports run against the data visible to the node the operator is connected to.

06

One-click from attack to rule, in the operator console

From an attack ID or path in the report, operators jump straight to the WAAP rule that triggered, the related learning suggestions, and the live traffic view. The report acts as the starting point for an operational workflow, not as a static document.

Where it fits

OWASP Top 10 category-level executive report

The CISO office can answer "Which OWASP Top 10 category showed the heaviest pressure this month, and on which path?" directly from the report. Per-category attack counts, risk distribution and geographic intensity ship as a branded PDF to the board.

Regulator and audit dossier

In banking, government and critical-infrastructure audits, the auditor asks for attack history sliced by OWASP category and CWE code. TR7's report presents these as standard sections — the audit dossier is not hand-prepared.

Attack pattern deep dive

Security researchers investigate which argument, which ASNs and which hours a specific attack type (e.g. SQLi attempts) hits. Cross-axis combination sections (CWE-89 × argument × ASN × hour) ship directly in the report.

Service provider (MSP) tenant attack dossier

Service providers run a separate vService per end customer and ship each tenant's monthly WAAP attack report with their own logo, date range and language. The same engine produces reports for tens of tenants in parallel.

Frequently asked

How are OWASP Top 10 and CWE tags bound to the rules?
Every rule in the 3000+ rule TR7 WAAP rule set is pre-mapped to OWASP Top 10 (2021) Web, OWASP API Security Top 10 (2023) and applicable CWE codes. When an attack log reaches the report, its category set is already known — operators don't manually map.
Which correlation axes are in the report?
Fourteen axes: source IP, country, city, user-agent, visitor (IP + UA), body size, WAAP inspection time (wafTime), hour-of-day, attack ID, attack scope (form / header / query / json / xml / path / raw / cookie), risk score, argument variable name, host header, path, HTTP method. Each axis: bar / pie chart paired with a top-N table.
How are risk tiers defined?
Six tiers: structural (TR7-specific structural anomalies), very high, high, medium, low, very low. The structural tier covers HTTP protocol abuse, bot behaviour and DDoS-IP signatures; OWASP CRS rules distribute across the other five tiers.
Are meaningful category combinations included as standard?
Yes. In addition to the primary axes, meaningful combinations (e.g. OWASP A03 × JSON body scope, CWE-89 × ASN distribution, API4 × HTTP method, structural × country) ship as standard report sections. Most audit questions get a direct answer from these combinations.
When a vService has multiple host groups, how does the report split?
A dedicated attack-report section opens per host group (numbered 2., 3., 4., …) with sub-sections for the 14 dimensions. Alongside, the summary section presents a cross-group rollup that places host groups side by side.
Can I click an attack ID in the report and see the underlying rule?
Yes. In the operator-console view, attack IDs and paths are clickable; you jump to the triggering WAAP rule, related learning suggestions and the live traffic view. In the PDF report these jumps render as links.
Do we need a separate management VM for this depth of reporting?
No. TR7 WAAP reporting runs inside the same appliance that serves the traffic. From log processing to PDF generation, the full pipeline lives on-device. Common WAAP products require a separate management platform with its own license and operational footprint.

Turn your attack reports into an OWASP / API / CWE-tagged category dossier

3000+ rule taxonomy, 14 correlation axes, 6 risk tiers, meaningful category combinations and a branded PDF cover. Let us walk you through a live demo on your own WAAP profile.