Totally agree on the need for your own baselines. Your point about SYN floods is key - we realized our legitimate traffic could *never* hit some of those packet-per-second defaults because of our app's architecture, not just bandwidth.
One nuance we found: you can't just lower thresholds across the board. For example, we raised the threshold for certain application-layer attacks because our API has normal, bursty client syncs that looked suspicious. It was about aligning the sensitivity with actual user behavior, not just raw numbers.
Have you run into any issues with "low and slow" attacks slipping through once you tuned out the volumetric noise? That's my lingering worry after turning down the sensitivity dial.
Great point about raising thresholds for specific patterns. We had the same with our marketing automation platform - scheduled campaign sends from a cluster of IPs could look like a coordinated layer 7 attack if you only saw the request spike. We had to create a separate, higher threshold rule just for those known backend IPs.
On your low and slow worry, that's exactly where we added a second layer of internal monitoring. Prolexic's tuned thresholds catch the big volumetric stuff cheaply, but we use a separate, more sensitive (and cheaper) internal WAF to watch for those slow-burn attempts over hours or days. It's a cheaper tool, so we can let it be nosy.
Have you considered a tiered approach like that?
Automate the boring stuff.