My day is filled with questions from current and potential customers. One that I love answering is what makes our web application and API protection (WAAP) and our security rulesets so accurate. Accuracy is critical when considering the onslaught of new attack vectors and vulnerabilities occurring over the last few years. In fact, the Cybersecurity and Infrastructure Security Agency (CISA) recently added 66 new vulnerabilities to its Known Exploited Vulnerabilities Catalog, and new CVEs have grown over 25% YoY in 2022. CISA isn’t the only one concerned about security and performance. According to a recent survey, businesses want a reduction in false positives, false negatives, alert fatigue, and improved security management.
So what makes Edgio WAAP Rules more effective? At a high level, it has to do with the special order in which we run our WAAP rules and our hybrid signature and anomaly scoring mode with the Managed Rules. We perform these processes within milliseconds via our homegrown waflz engine to provide security without sacrificing performance. Let’s dive into this in greater detail.
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 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 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 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 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.
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.
This comprehensively collects various security policies and rules for different attack categories and applications. When performing a threat assessment, each Managed Rule can be customized to prevent false positives by excluding certain variables (i.e., cookies, headers, and request parameter/query string).
As you can see, our WAAP rules have many layers, and within each layer, there could be anywhere from dozens to hundreds of rules and conditions our WAAP has to run. Each rule presents a probability of introducing false positives and impacting performance. Complicating matters is that the Edgio WAAP provides unique abilities to run in Dual WAAP mode, where you can run two versions of the security configurations for your production traffic concurrently for access control rules, custom rules, and managed rules. We will add additional protection layers as we continue to enhance our security solutions. Which raises the question, how do we ensure our WAAP processes millions of requests accurately and efficiently amidst the chaos of all these capabilities and rules?
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 denylist, 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.
Figure 1: Edgio WAAP workflow.
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.
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 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.
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.
Let’s connect to learn how Edgio can improve the security and performance of your web applications.