In a nutshell, the current state of the F5 Distributed Cloud WAF considers several factors before making a block/allow decision. The default configuration does the following:
- Operates in a monitoring mode, which logs WAF hits but doesn’t block
- matches requests against high and medium attack signature accuracy classes
- Automatic Attack Signature tuning automatically suppresses likely false positives
- Bot Signature fill drop requests from clients that match known malicious bot signatures
The focus here is that the default is to match based on signature accuracy, an approach that has been leveraged for years until the introduction of the AI-enhanced WAF. This deserves its own article, but to summarize here it pivots to a risk-based enforcement model instead of a pure signature match model. This decision is based on a custom model trained by F5 to identify requests that were riskier regardless of signature accuracy which improves both the block rate while lowering false positives further. But this isn’t why you came here.
Stepping outside of AI functions that have reduced false positives and better blocking, let’s pivot to the challenge that many security teams face in actual businesses: you get stuck with a WAF forever in monitoring mode. Many on the security side of this equation might feel that watching malicious actors walk through the wide open front door has very little utility before the fact. There is a growing stash of events that could have been blocked or maybe get analyzed downstream to enforce a blocking mechanism (perhaps a SOC engineer maintaining a deny list?) in a purely reactive fashion.
What if there was a better way? This is how we recently helped a customer find the best balance:
Enter Malicious User Detection/Mitigation
When Malicious User Detection is enabled, instead of looking at each request in isolation like a WAF or Firewall does, we look at the behavior of a particular client over time. This includes detecting anomalous behavioral changes, failed logins, unauthorized access, and most importantly for this article, all other Distributed Cloud security engine detections including but not limited to a WAF in monitoring mode. Why does this matter?
An Application Firewall looks at the requests in their own context. We can assess risk inside the context of a given request, across all accuracy classes of signatures, but that context exists constrained to the request. Malicious User Detection adds the context of the user behavior over time. For instance, we will look at things that may never trigger a WAF block but because they are anomalous in time we can change the risk level of that user; with Malicious User Mitigation we can make a subtler decision to challenge a user with proportional responses. For instance, when a user transitions from no risk to low risk behavior, we can ensure they are running a browser with a javascript challenge. When they transition from low to medium risk we can present a captcha challenge. When they transition into high risk we can temporarily block that user. We can even identify users with a wide set of criteria than simple source IP. We can use XFF source IP, TLS fingerprints, headers, JWT claims, and other things, in a cascading list, to provide those mitigations in a very targeted way at an individual level. This means that one user that sends a request that triggers a WAF violation through a monitoring policy will be allowed through while another attacker that commits multiple WAF violations (or even just anomalous requests) will have mitigation applied in a progressive manner proportional to their risk. This is more subtle and targeted than a pure WAF block.
An example Malicious User log from an Apache Bench test against an application with WAF monitoring mode and MUM:
-
Configuration:
App Firewall in Monitoring mode -
Enable Malicious User Detection and Mitigation in the HTTP Load Balancer
3. Save the HTTP Load Balancer
Summary and Conclusions
Pros:
- Mitigation are applied per-user instead of per signature
- A true false positive will be allowed through for a well-behaved user because where it might otherwise be blocked with a blocking WAF policy
- A malicious user can be stopped with mitigations based on anomalous behavior before they ever trigger a WAF block
Cons:
- It takes a little more time to come to a decision to mitigate because behavior is a time-dependent variable
- Using behavioral analysis costs more than using WAF alone
Key Point: Malicious User Detection/Mitigation with a monitoring WAF policy means you shift a block decision from a request context to a user-behavioral context which dramatically narrows the scope of impact from an application-related false positive. It is a safer middle ground to start doing something with all that WAF logging when you aren’t allowed to turn on a blocking policy.