I've been running Imperva's WAF (specifically the Cloud WAF component) in front of a suite of microservices for about 18 months now. While the platform provides a wealth of data, I've grown increasingly skeptical of the default "security events" dashboard as a true measure of value. The sheer volume of "blocked" requests is often touted as a success metric, but this conflates noise with signal. To get a clearer picture, I built a custom dashboard that correlates Imperva threat logs with actual business-level incidents and internal application monitoring.
The core issue is that a blocked request does not necessarily equate to a mitigated threat. Many blocked requests are simply automated scanners, misconfigured legacy clients, or benign bots. The real metric of efficacy is the reduction in *actual* threats that reach your application logic or cause operational impact. My dashboard attempts to quantify this by joining datasets.
Here’s the high-level architecture of the correlation:
1. **Imperva Logs:** Streamed to a dedicated analytics bucket (using their SIEM integration).
2. **Application Logs (OpenTelemetry traces & errors):** From our Grafana Tempo/ Loki stack.
3. **Incident Records:** Pulled from our PagerDuty incidents, tagged with `origin: security`.
The key query looks for temporal proximity and source IP correlation between a high-severity Imperva event (e.g., SQLi attempt, RCE signature) and an internal application error or triggered incident. The results were illuminating.
**Findings from a 90-day analysis period:**
* **Total Requests Blocked by Imperva:** ~4.2 million
* **Requests flagged with high-severity signatures:** ~12,000
* **Correlated events:** Incidents where a high-severity Imperva event was followed (within 2 minutes) by an application error/incident from the same source IP.
* **Correlated count:** 47
This suggests that for our workload, approximately 0.0011% of blocked requests represented a potential threat that also triggered something in the app layer. The vast majority of blocks are background noise. The 47 correlated events, however, were critical—these were targeted, aggressive probes that exploited application quirks Imperva didn't fully cover.
The dashboard itself is built in Grafana. The most useful panel is a time-series graph overlaying:
* Imperva High-Severity Blocks (per hour)
* App 5xx Errors from External IPs (per hour)
* Markers for declared security incidents
This visual correlation quickly shows if blocks are preceding errors, or if errors occur without a preceding block (indicating a potential false negative/wAF bypass).
```sql
-- Example of a simplified correlation query (BigQuery)
SELECT
TIMESTAMP_TRUNC(i.date, HOUR) as time_window,
COUNT(DISTINCT i.client_ip) as distinct_attacker_ips,
COUNT(DISTINCT a.trace_id) as correlated_app_errors
FROM
`project.imperva_logs.threats` i
LEFT JOIN
`project.app_logs.errors` a
ON
i.client_ip = a.client_ip
AND a.timestamp BETWEEN i.timestamp AND TIMESTAMP_ADD(i.timestamp, INTERVAL 120 SECOND)
WHERE
i.severity = 'HIGH'
AND i.date >= DATE_SUB(CURRENT_DATE(), INTERVAL 30 DAY)
GROUP BY
time_window
ORDER BY
time_window DESC
```
**Takeaway:** The value of Imperva isn't in the raw block count, which is often inflated by low-effort scanning. It's in the *specificity* and *efficacy* against the few hundred truly malicious attempts that happen annually. My recommendation is to invest time in correlating WAF data with your internal observability stack. Tune your rules aggressively to reduce false positives, focusing on the signatures that actually map to your application's vulnerability profile. This moves the conversation from "we blocked millions of requests" to "we prevented 47 confirmed attempted breaches," which is a far more meaningful and cost-justifiable metric.
-- alex