The evolution of blocking

The false positives dilemma and regex’s role

To understand the false positives dilemma, it’s important to note how other WAFs create most of their blocking decisions: regular expression (regex) rules. Regex rules are riddled with complexities but are the primary detection method used by other WAFs, thus limiting their utilization in most organizations. The crux of regex’s problem is that the rules must be nearly perfect to ensure legitimate traffic isn’t impacted. Moreover, new common vulnerabilities and exposures (CVEs) and other lesser vulnerabilities come out regularly, so even if the rules are perfect now, they’ll likely need regular and timely updates to maintain their efficacy over time.

For many teams striving to reach this level of perfection, it may never come. Their legacy WAF will create false positives and endless work for security teams to tune them out, continually exceeding the budgeted cost they were sold on. The reality for modern security practitioners is that to be effective against the slew of attackers on their applications, they need flexibility. This is where threshold-based blocking comes into play.

Embracing flexibility with threshold-based blocking

As business requirements and overall traffic ebb and flow, flexibility is required for confident blocking decisions that impact as little legitimate traffic as possible. Think of instances when traffic spikes during the holiday season or when big sales or deals are offered. Business needs may dictate the easing of blocking where possible. In these scenarios, threshold blocking’s flexibility enables organizations to maximize opportunities for revenue with the protection they deem appropriate.

Think of threshold-based blocking like rate limiting on only validated attacks. When combined with rules tailored to your organization’s environment, this capability fills the gaps between binary decisions and the established rate-limiting capabilities many vendors offer. In doing so, organizations gain additional confidence before making blocking decisions. 

How threshold-based blocking works

Threshold-based blocking is a feature that’s unique to Fastly and available to all customers using our Next-Gen WAF. This approach starts with Fastly’s proprietary detection engine, SmartParse. We have a comprehensive list of the default attacks SmartParse flags here, but they’re typically the types of attacks you’d find in OWASP’s Top 10 Web Application Security Risks. When SmartParse detects a request with an attack payload, it flags the request with the attack type. Think of it like a highly accurate thumbs up or thumbs down -  it’s a major reason why about 90% of our customers run us in full-blocking mode instead of the 35% that legacy WAFs achieve.

Flagged attacks are counted, and teams can easily decide how many requests can be flagged before blocking the IP from submitting additional attack payloads. Where other WAFs force organizations to operate under binary terms (allow or block a request) or crudely attempt to implement thresholds by scoring a potentially flawed rule, threshold-based blocking leverages SmartParse’s highly accurate contextual decisions to enable teams to flexibly adjust how quickly they block the IPs launching attacks on their applications, APIs, or microservices.

Here’s how it's set up:

Security teams can quickly jump into instant blocking mode via the immediate-block toggle or adjust the thresholds from the Attack Thresholds account settings for 1-minute, 10-minute, and 1-hour intervals.

While each interval has a declared default threshold, teams can easily increase the threshold to increase their confidence before making decisions or decrease the threshold to 1 (or use the toggle) to create instant blocking decisions. The power is put into their hands to reach the confidence level they deem necessary before making traffic-impacting decisions.

The benefits of threshold blocking

Threshold-based blocking enables lower false positives, increased flexibility, and faster time to blocking mode.

Lower false positives

Likely the biggest concern from WAF skeptics is the false positives they produce. Threshold blocking lowers the risk of false positives by forcing attack trends to emerge before blocking requests. Doing so increases security practitioners' confidence that their WAF is not impacting legitimate traffic or the transactions and revenue they produce while ensuring that bad actors are stopped.

Increase flexibility

Every organization experiences unique traffic patterns they would consider normal. Fastly’s threshold-based blocking gives security teams tools to adjust thresholds at multiple time intervals quickly. In doing so, they reduce time spent triaging false positives and tuning rules. Teams using other WAFs to protect their environments often require multiple, dedicated resources to refine and maintain their regex rules for blocking continually. Thresholding allows teams to reduce internal resourcing and lower the WAF’s total cost of ownership.

Move faster to blocking mode

Moving a WAF from monitoring mode to blocking mode is a massive decision that can create a world of problems if done improperly. Therefore, other WAFs never get moved into blocking mode or only do so after months of tuning and refinement. Threshold-based decisions allow for a level of grace, and as a result, users are enabled to flip the switch to blocking mode sooner. This results in teams realizing the value of their WAF investment far sooner.

Add a threshold approach to your arsenal

Legacy WAF approaches are riddled with false positives and directly impact your organization’s bottom line when put into blocking mode. An attack threshold-based approach is the evolution of blocking and one of many features unique to Fastly’s Next-Gen WAF. Contact us to learn more about this feature and how we help you confidently protect your applications, APIs, and microservices.