The Signals Series, Part 3: Signals at the Edge

In Part 1 of this series, we introduced you to what’s possible with our next-gen WAF’s custom signals, using a couple of examples that focused on blocking suspected bad or unwanted behavior. Part 2 covered system signals, which allow security and DevOps teams to enjoy web app and API protection with zero custom configurations.

In Part 3 of the Signals Series, we’ll look at two additional use cases – identifying known actors and response tracking – and see how signals help in these areas to strengthen your security posture. We’ll also look at how moving some of the security decisioning to Fastly’s edge can further protect downstream systems through the use of custom response codes.

Identifying Known Actors

There is a constant drumbeat around preventing web threats, and for good reason: code injection attacks, customer data exfiltration and API abuse are constant threats to service delivery on the web. 

There is, however, another side to this coin that’s often not addressed during threat modeling:  reducing noise and alert fatigue for overburdened teams. When security teams are chasing false positives instead of actual threats, they’re operating with reduced effectiveness. 

According to a report by ESG, 23% of security leaders think that keeping up with the volume of security alerts is their organization’s primary challenge. One way to combat cybersecurity alert fatigue is by using your WAF to automatically identify known actors. By tagging traffic or requests with metadata that marks them as “good,” more mental room is left for teams to maximize efficiency in their threat mitigation. Using the Fastly Next-Gen WAF, you can add a specific signal to this category of traffic. This is done using an IP address or any other distinguishing identifier in the HTTP request. 

Here is how you might configure your site rules to add a custom signal to identify a popular scanner based on a list of IP addresses. Once a list is created, the site rule itself is very straightforward. Let’s outline the basic steps in the UI. First, let’s create a list that we’ll use in the rule itself. In this example, we know the list of IP addresses to identify:

In the above screenshot, we’ve added three fictitious IP addresses representing known vulnerability scanners. Once the list is created, we can attach a signal to this category of traffic. This can be done by creating a new request rule as follows:

With this rule, we are allowing traffic from the IP addresses in this specific list and then tagging that request with the signal known-scanner for future reference. Without this rule, the Fastly Next-Gen WAF would perform attack detection on this traffic and block the scanner from doing its job, creating unnecessary alerts for your security team. With the signal known-scanner attached to the request, you can also confirm and visualize the activity you expect from the scanner. 

Next, we’ll discuss a more complex way of tracking attacks, by looking not only at the incoming payload, but also at the effect the request had (or didn’t have) on a downstream application.

Response Tracking

Basic approaches to web security threat modeling often appear to follow a simplistic storyline about a would-be attacker. First, they’re wearing a dark hoodie (of course), and second, they possess a single, well-crafted payload that, if sent at the right part of the application (URL), will wreak havoc on your system -- likely in the form of data exfiltration, denial of service or other form of abuse.

The second part of this story goes like this: If only we had a perfect way to catch this attack (expressed as a malicious HTTP request) and stop it before it did damage, we’d achieve some sort of web security bliss. 

This thought process is the common first layer of defense for web application security. The consequence of this line of thinking is a model based on known threats or signatures. It’s no wonder companies  end up with the hundreds (or potentially thousands) of rules commonly found in legacy WAFs. How do we improve on this? 

With custom signals, we can extrapolate this logic and go even further. In the Fastly Next-Gen WAF, both the request and response are used to determine whether an attack or anomaly signal is added to a request/response pair. For example, a good handful of our system signals (such as forceful browsing) rely on knowledge of the request and response before tagging a request with the signal.

This extends the protection from “fire and forget” types of attacks towards gaining visibility and insights into more sophisticated attacks. What if we could determine how attackers are probing for weaknesses in an authentication endpoint? Authentication APIs are a common target for attacks because, by default, they need to be widely exposed to work properly. A custom signal to track authentication failures (in this case HTTP 302) can inform you of excessive login failures which could indicate an attempted credential stuffing attack. What follows is a basic template for how you would create a site rule for this:

In the previous example, we’re tagging authentication failures with a signal AuthFailure. It’s not clear that something bad has happened yet, but too many failures when you are not expecting them could indicate an attack in progress. This type of leading indicator could alert you to add additional security controls to other parts of the application that handle authentication; it could indicate a potential coordinated attack. The signal can be graphed as follows with a custom dashboard:

In this example, we’ve mocked up a dashboard to track incidences of this signal over the last hour. You can see a higher concentration of signal activity between 10:30 and 10:45, which may indicate an attempted attack, especially if your known baseline is much lower.

Extending Protection to the Edge

Tracking responses is great, but what about enforcement actions such as blocking or rate limiting? What if you want to perform these actions upstream? At this point it seems like the opportunity has passed because the agent has already completed processing and the response is heading back to the client. 

Well, this is where extending your security perimeter to the edge can help further. Signals on the response can be passed back to the edge using custom response codes, which allows the additional intelligence generated by the next-gen WAF to turn into additional enforcement actions in Fastly’s Deliver (Varnish) or Compute environments. For Varnish customers, this is as simple as adding logic around the beresp.status variable. Compute customers could do something similar based on relevant variables for the response (which would be language dependent).

The  beresp.status  contains the HTTP status code of the response received from your origin. If, for example, if your site rule returned a 550 instead of a 401, your edge security decisions at this stage could include blocking, edge rate limiting or tarpitting the client – all of which would have the effect of slowing the attacker down and keeping traffic and load away from your origin during an attack. You can enable the additional protection by updating the rule to change the rule to block and altering the response code as follows:

Once the rule is changed in the Next-Gen WAF, additional security logic can be added to Varnish to take action when the value of beresp.status has a value of 550. The benefit of security enforcement at the edge increases as the sophistication and scale of the threat to your application increases. 

Fastly’s Next-Gen WAF can distribute security decisions in multiple places throughout your environment -- providing protection and decisioning in more places whether at the Edge, inside your applications themselves (Core deployment) or as a standalone reverse proxy (Cloud WAF). 

Tune in for what’s next

Now that we’ve covered some additional use cases for custom signals, we hope you can build on these ideas for your organization. If you want other ideas or examples, you can reach out to your technical account manager to explore more. And make sure to follow our blog for the next update. See you soon!

Not yet a Fastly Next-Gen WAF customer? Reach out and we’ll get in touch.