The Signals Series, Part 1: Exploring Custom Signals
When Fastly acquired Signal Sciences in 2020, there was a lot of fanfare around its award-winning security and the potential in integrating into Fastly’s delivery and network services.
But there’s something that we haven’t really explored in-depth. Something which provides a key role in surfacing amazing insights and customizing the types of protection modern organizations need.
The Fastly Next-Gen WAF is powered by Signal Sciences. But what does the “signal” in Signal Sciences refer to?
A signal is a tag or label that can be assigned to a request. Combining signals with our rules allows for our next-gen WAF to create more precise and customized responses to requests. In this multi-part series, we will provide a brief primer on the various types of signals our platform provides, along with real-world use cases from our customers. Today we will be going over the use of custom signals and how this powerful feature can really transform the way you utilize incoming requests.
The Power of Custom Signals
Traditional web application firewalls (WAFs) were created to stop malicious traffic from reaching your origin servers, which served its purpose well during an internet age of HTML and PNGs. But Layer 7 traffic has exploded over the past decade, with dynamic content spanning applications, APIs, microservices, and more. Coupled with modern DevOps practices and CI/CD it becomes very difficult for a traditional WAF to keep up.
When a traditional WAF detects a bad request, the security team is presented with only two options: block or allow. Like mail sorting at the post office, you want to let envelopes and packages through, and keep out the damaged or torn items that can break your machinery.
But sometimes you want to do more than that - like track how many envelopes are coming from San Francisco, or how many packages have biohazard warnings. Once this information is tagged correctly, it can be used to inform the policies that sort and route items through your warehouse. By tracking how many packages are biohazardous, you can direct them to a safer part of the warehouse.
Custom signals are a powerful way to tag interesting or anomalous traffic requests to inform more precise blocking/allow decisions. To make it a little less abstract, let’s dive into two examples of how an organization can use custom signals for its application.
Signals in Two Ways
The owner of acmecorp.com has noticed an uptick in vulnerability scans coming from a variety of internet sources. One thing they all seem to have in common is that they are sending web requests to the IP of their website and not the proper hostname "acmecorp.com". We know that the users and customers browsing "acmecorp.com" are coming to the hostname and not its IP address "192.168.1.10". These malicious web crawlers cause unnecessary noise, data transfers, and resource consumption, which can ultimately result in a higher cloud spend. Additionally, they noticed that fraudulent accounts were being created using disposable/anonymous email generators.
As a member of the security team, can create custom signals and use them to block and tag traffic in two different ways:
Custom Signal: Blocking web crawlers
First I create a rule that tags any traffic that contains the domain acmecorp.com or acmecorp.net with the signal called Organization Domains.
Next, I add a rule that states that any request that does not contain the signal Organization Domains would be blocked.
Now that the signal and rules are in place, I can go ahead and inspect the incoming traffic to see progress. On the dashboard, I can see that requests coming from a random bot crawler that doesn’t know the name of the site are being blocked.
Custom Signal: Tagging Anonymous Email Domains
To track how many accounts are being created from anonymous email addresses, first I generate a rule that targets requests that successfully registers and logs into our sign-up form using a specific domain. I add a signal to those requests called Disposable Email. Just like the example above, I can create another rule that blocks any request that contains the Disposable Email signal.
Now when I look up the traffic containing the Disposable Email signal, I see that it’s blocked. This reduces fraudulent account registration and reduces resource consumption.
Read on for For Part 2
Now that I’ve covered the power of custom signals, I hope that you are able to see how you can utilize it for your own organization! If you want other ideas or examples, you can reach out to your technical account manager to explore more.
To continue learning more about signals, head here where we dive into system signals and how the Next-Gen WAF delivers out of the box protection.
Not yet a Fastly Next-Gen WAF customer? Reach out and we’ll get in touch.
