Hey everyone, been lurking for a bit but finally have something to ask. I've been tasked with managing our Radware AppWall setup for a few months now, specifically around the SQL injection protection policies.
I'm finding that the default thresholds for SQLi detection are... a bit aggressive for our environment. We have a legacy app that uses some unconventional query-building (don't ask, it's being refactored). I keep getting alerts and blocks on what I'm pretty sure are false positives. It feels like I'm constantly going into the policy, adjusting the "signature severity" thresholds or creating exceptions for specific URL patterns.
For example, we had a case where a parameter value like `user_profile_1` was being flagged because of the underscore and number pattern combined with a certain keyword. I had to add an exception, which feels wrong.
```xml
/api/v1/getProfile
profile_id
user_profile_d+
```
Is this a common experience? How are you all balancing between security and not breaking legitimate traffic? Do you start super strict and whitelist, or start loose and tighten based on attacks? Also, any tips on tuning the "learning" mode effectively? I'm worried my constant tweaks might be training the system to allow something bad 😅
What's your process like?
Learning by breaking
Totally feel your pain on this. The defaults on those WAFs are tuned for the worst-case scenario, and any app with quirky patterns gets hammered.
Your whitelist example is pretty much the standard approach, though I'd suggest using the regex to be as specific as possible, maybe anchor it like `^user_profile_d+$` to avoid accidentally allowing something like `user_profile_1';--`. It feels wrong, but if the app is truly legacy and you can't change it, that's the playbook.
We ended up running the policy in monitor-only for a full business cycle (two weeks) to build a baseline. The logs were noisy, but we could filter for the highest-severity events and create exceptions before flipping to blocking mode. It's a grind, but it beats constant firefighting. Have you tried using the learning mode to suggest exceptions, or are you building them manually from alerts?
I've seen similar issues with aggressive filters in other tools, though not with Radware specifically. In Asana, we had a legacy integration that used odd text patterns and would trip internal security scans.
The monitor-only approach user1213 mentioned seems crucial. How long did you run it for before making changes? I worry about missing actual threats during that learning period.
Your point about exceptions feeling wrong is exactly my hesitation. Once you carve out a path for one pattern, does it make you more likely to add others?