Hey everyone, I've been deep in the weeds of our AWS WAF configuration for the last quarter, and something kept nagging at me. We were seeing a high volume of blocks in the logs, which initially felt like our rules were doing a great job. But after a few conversations with our security team and correlating with other data sources, I started to wonder: how many of these WAF blocks were actually stopping *targeted, malicious attacks* versus just catching background noise, false positives, or automated scrapers?
It’s a crucial distinction for resource allocation and tuning. You don't want to be lulled into a false sense of security by a big block number, nor do you want to over-tune and let something real slip through.
So, I spent the last couple of weeks building an internal dashboard to try and separate the signal from the noise. The goal was to visualize the relationship between WAF blocks and what we're classifying as "actual attacks." Here's a simplified breakdown of the logic flow we're using:
* **Data Source 1: AWS WAF Logs (via S3/Athena)**
* The raw count of ALL `BLOCK` actions.
* We break this down by rule ID and managed rule set group.
* **Data Source 2: AWS Shield Advanced Metrics & DRT Contacts**
* This gives us a (somewhat) curated view of events AWS identifies as more sophisticated or volumetric (e.g., known attacker IPs, larger-scale probing).
* We also log any manual engagements with the AWS DRT during a suspected incident.
* **Data Source 3: Our Application's Own Auth/Intrusion Logs**
* We cross-reference failed login attempts, SQL error triggers, and suspicious API parameter patterns that *we* flag internally.
The dashboard then tries to correlate these streams on a timeline. The key metric we're watching now is: **"Shield-Identified Events Resulting in WAF Blocks."** It's been eye-opening.
**Initial Findings & Pitfalls:**
* A huge portion of our daily WAF blocks are against a small set of IPs scanning for common WordPress vulnerabilities (we're not on WordPress). These are "noise."
* The more targeted stuff, like credential stuffing attempts on our login endpoint or specific parameter injection probes, often aligns with Shield notifications and correlates with spikes in our own auth logs.
* The biggest challenge is tuning without breaking things. We found one managed rule was blocking a legitimate but oddly-formatted API call from a legacy partner integration. The dashboard helped us spot that anomaly (a sustained block count on one endpoint with zero correlation to other attack signals) and create a precise scope-down exception.
Has anyone else tried to build this kind of layered visibility? I'm particularly curious about how you might be defining an "actual attack" operationally, or if you've found other AWS data sources (GuardDuty? Security Hub?) useful for this kind of correlation.
I can share more about the architecture (we used QuickSight, but Grafana would work too) if there's interest. It's really helped us move from a reactive "lots of blocks = good" stance to a more nuanced understanding of our threat landscape.
~Jane
Stay connected