Peeling Back the Onion
Before we review the inner workings of our Managed Rules, let’s look at the different layers (pun intended) of the protections in our WAAP. Every layer of the WAAP plays an important role. The information below provides an overview of its functions.Access Control Rules
Access control rules provide the ability to create modular allowlists, denylists, and positive-security access lists to control access to protected sites by IP address, anonymous proxy, country, ASN, geo-region code, user agent, cookie, referrer, URL, HTTP request method, content type, file extension, file size, and request headers.Rate Limiting Rules
Rate limiting rules restrict the flow of HTTP requests to an application protected by the WAAP to prevent malicious or unintentional application DDoS traffic and prevent a customer’s application servers from being overloaded with requests from attacks or unplanned traffic spikes.Bot Manager Rules
Bot manager detects both good and bad bots. It provides multiple options to mitigate unwanted automation or bad bots and prevents them from reaching your applications. This protects your site from malicious bots performing credential stuffing, scraping your content, carding, spamming your forms, launching DDoS attacks, and committing ad fraud.Custom Rules
Custom rules put our powerful WAAP engine in your hands to create your own security rules. Malicious traffic is identified using a combination of variables (i.e., request headers, body, query, method, URL, cookie, etc.). This method provides added flexibility for threat detection and enables you to filter for specific malicious requests and take action to mitigate them. Custom threat identification combined with rapid testing and deployment enables you to quickly address long-term and zero-day vulnerabilities by creating virtual patches.Managed Rules
Edgio’s Managed Rules identify malicious traffic via a proprietary ruleset managed by Edgio. Managed Rules consist of over 500 rules spread across three categories:- Edgio Proprietary Rules.
- Advanced application-specific rules.
- Generic OWASP rules.
Creating Order Out of Chaos
Besides having a powerful homegrown waflz engine specifically designed to scale in a high-performance multi-tenant environment, the key is creating a proper order of operations to run the WAAP most efficiently and effectively. To accomplish this, our WAAP runs its different layers of rule modules in the following sequence:- Access Control Rules: All requests are filtered by a static set of customer configured allow/deny/access lists consisting of the previously mentioned variables. The WAAP drops any request matching the deny list, preventing any unwanted traffic from being processed further.
- Rate Limiting Rules: Requests passing the access control rules are then tracked by the rate-limiting rules, which track the request for each client within a time window specified by the configuration. The WAAP drops requests exceeding a particular request rate threshold, further cutting the request volumes from proceeding to the next step.
- Bot Manager Rules: Each request reaching this step is inspected by our ML platform to determine whether they are bot-based on a combination of request signatures and behaviors. Any malicious bot requests can be mitigated here via various means including browser challenge, custom response, or captcha. Most attacks are made via automated clients, making the bot manager an effective solution to mitigate these attacks and further reduce the volume of requests that need to be processed by subsequent rule modules.
- Custom Rules: At this step, the WAAP inspects the request using various custom filters created by customers to detect and mitigate unwanted requests. This can include any application-specific rules customers can deploy in real time to mitigate zero-day vulnerabilities without waiting for the managed WAAP ruleset to be updated. This is an invaluable tool to gain visibility and control over specific attacks. Because of the specificity of the custom rules, they take precedence over the Edgio-managed rules and will process the requests before passing them to the final layer.
- Managed Rules: Any request reaching this stage is processed by the Managed 500+ rules across Edgio proprietary, advanced application-specific, and generic OWASP categories.
Processing every request in sequence (as shown in Figure 1) ensures multiple layers of filtering are performed. This helps us capture the attacks our customers are looking for (i.e., denylisted IP/countries, application DDoS/HTTP flood, automated clients, and specific custom request signatures) before the requests hit the Managed Rules.
However, this is just part of the security story.
The effectiveness of a WAAP isn’t determined just by its ability to mitigate attacks (true positives) but also by its ability to prevent legitimate traffic from being blocked (false positives). Let’s review how we capture most application attacks while reducing false positives.
A Deeper Dive into Edgio Managed Rules
When a request reaches the Managed Rules, it’s evaluated by our proprietary Edgio Ruleset of more than 500 rules created to mitigate a broad spectrum of application attacks. This presents an additional layer of complexity because there are so many categories of rules [i.e., the generic SQL injections (SQLi), cross-site scripting (XSS), and remote code execution (RCE) rules] and the specific WordPress, Joomla and Apache Struts rules. Careful prioritization is needed to ensure they complement each other to maximize accuracy.
As with the previously mentioned rules modules, the key is the order of operations between each category of the Managed Ruleset.
Within the Managed Rules, the request is processed by different rule categories in this order: Edgio Proprietary Rules > Advanced Application-Specific Rules > Generic OWASP Rules.
The Edgio Proprietary Rules and Application-Specific Rules look for signatures associated with a specific vulnerability of a specific type of application. These rules provide coverage for applications (i.e., Apache Struts, WordPress, Joomla, Drupal, SharePoint, cPanel, and more) and are highly accurate in detecting attacks on these applications. We designed these rules to run in Signature (aka binary) mode, meaning any request triggering these rules causes an action. These rules provide a more surgical approach to matching and filtering specific attack vectors to an application; hence, they are the first layer of the Edgio Ruleset filter. Since requests not matching proprietary and app-specific rules can still present a risk to the customer’s application, we need another approach to detect potential attacks in the next phase.
The Generic OWASP Rules within the Edgio Ruleset look for a combination of signatures associated with different common categories of attacks (i.e., SQLi, XSS, RCE, protocol violation, local file inclusion (LFI), remote file inclusion (RFI), and more). These rules work together to determine whether a request exhibits a combination of signatures that fit an attack category. These generic rules run in anomaly scoring mode that lets customers define rule sensitivity by adjusting the anomaly score threshold to control how many rules need to be triggered for the request to be considered malicious. The lower the anomaly score threshold, the more sensitive or stricter the generic ruleset becomes and the easier for a potentially malicious request to exceed the threshold. Customers have the flexibility to adjust the sensitivity of their WAAP based on the type of application and their risk tolerance. The generic OWASP rules serve as the final catch-all for requests that fit a particular attack characteristic but do not necessarily fit specific application vulnerabilities.
Figure 1: Edgio WAAP workflow
Figure 2: Our Managed Rules run in a specially designed sequence to maximize detection and minimize false positives.
Another important feature that enhances the accuracy of the Managed Rules is the customizability of the rules. Each one of the 500+ Managed rules can be customized to ignore specific request parameters (i.e., request header, cookie, query, and body parameters). This enables customers to quickly remove false positives using a simple user interface or API.
Putting All the Pieces Together
You’ve now taken the journey of an HTTP request through our WAAP. Something that occurs billions of times daily within every Edgio server in all 300 points of presence (PoP) worldwide, as our high-performance WAAP runs natively on the same stack that runs our content delivery services. At the beginning of this blog, I mentioned I get a lot of questions about our WAAP. I hope you now understand what sets it apart from other solutions. We combine an intelligent order of operations with the various WAAP rules modules (from ACL to rate limiting to bot and custom rules), Managed Rules (from specific to generic rules), and the hybrid signature and anomaly scoring mode for security that doesn’t impede performance.
Consider this analogy: Designing and assembling WAAP components is like making a hamburger. It’s not just about having the right ingredients; it’s about combining them in the right way to make a great meal. The same ingredients put together differently can drastically impact taste and the customer’s experience.