Original source: Edgecast
My day is filled with questions from current and potential customers. One that I love answering is what makes our web application firewall (WAF) and our security rulesets so accurate. Accuracy is critical when considering the onslaught of new attack vectors and vulnerabilities occurring over the last couple of years. In fact, the Cybersecurity and Infrastructure Security Agency (CISA) recently added 66 new vulnerabilities to its Known Exploited Vulnerabilities Catalog. CISA isn’t the only one concerned about security and performance. According to a recent WAF survey, businesses want a reduction in false positives, false negatives, alert fatigue, and to see an improvement in WAF management. For a richer understanding of how businesses are adapting their application security practices, read our WAF Benchmark Report.
So what makes Edgecast Managed WAF Rules more effective? At a high level, it has to do with the special order in which we run our WAF rules and our hybrid signature and anomaly scoring mode with the Managed WAF 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 WAF Rules, let’s take a look at the different layers (pun intended) of the protections in our WAF. Every layer of the WAF rule module plays an important role. The information below provides an overview of its functions.
Access control rules provide the ability to create allowlists, denylists and positive-security access lists to filter traffic by IP address, country, ASN, 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 behind the WAF to prevent malicious or accidental application DDoS traffic and prevent a customer origin server from being overloaded with requests.
Bot manager rules mitigate automated traffic by requiring a client (e.g., a web browser) to solve a challenge before allowing the request to proceed. The WAF prevents the requests from reaching the application when the client cannot solve this challenge. Basic bots typically cannot solve this type of challenge, and therefore their traffic is mitigated. This protects your site from bots scraping your content, carding, spamming your forms, launching DDoS attacks and committing ad fraud.
Custom WAF rules put our powerful WAF engine in your hands to create your own WAF rules. Malicious traffic is identified by 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.
Edgecast Managed WAF Rules identifies malicious traffic via a predefined ruleset we created. Managed WAF Rules consist of more than 500 rules spread across three categories: 1. Edgecast Proprietary Rules. 2. Advanced application-specific rules. 3. Generic OWASP rules. This provides a comprehensive collection of various security policies and rules for different attack categories and applications. When performing a threat assessment, each Managed WAF 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 WAF rules have a lot of layers, and within each layer, there could be anywhere from dozens to hundreds of rules and conditions our WAF has to run. Each rule presents a probability of introducing false positives and impacting performance. Complicating matters is the fact that the Edgecast WAF provides unique abilities to run in Dual WAF mode where you can run two versions of the security configurations for your production traffic concurrently for access control rules, custom WAF rules and managed WAF rules. As we continue to enhance our security solutions, we will add additional protection layers. Which raises the question, how do we ensure our WAF processes millions of requests accurately and efficiently amidst the chaos of all these capabilities and rules?
Besides having a powerful homegrown WAF engine (waflz) specifically designed to scale in a high-performance multi-tenant environment, the key is creating a proper order of operations to run the WAF most efficiently and effectively. To accomplish this, our WAF 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. Any request matching the denylist is dropped by the WAF, 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 tracks the request for each client within a time window specified by the configuration. The WAF 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 served a browser challenge to detect automated clients or primitive bots. All requests failing to solve the challenge are prevented from proceeding. Most attacks are made via automated clients, making this an effective solution to reduce further the volume of requests from being processed by subsequent, more computationally intensive processes.
Custom WAF Rules: At this step, the WAF inspects the request using various custom filters created by customers to detect and mitigate the requests deemed unwanted. This can include any application-specific rules customers can deploy in real time to mitigate zero-day vulnerabilities without waiting for the managed WAF ruleset to be updated. This is an invaluable tool to gain visibility and control over specific attacks. Because of the specificity of the custom WAF rules, they take precedence over the Edgecast-provided managed WAF rules and will process the requests before passing them to the final layer.
Managed WAF Rules: Any request reaching this stage is processed by the Managed WAF’s 500+ rules across Edgecast proprietary, advanced application-specific and generic OWASP categories.
Figure 1: Edgecast 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 WAF Rules. However, this is just part of the security story.
The effectiveness of a WAF 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 of the application attacks while reducing false positives.
When a request reaches the Managed WAF Rules, it’s evaluated by our proprietary Edgecast Ruleset (ECRS) of more than 500 rules specifically 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 WAF rules modules, the key is the order of operations between each category of the ECRS. Within the ECRS, the request is processed by different rules categories in this order: Edgecast Proprietary Rules > Advanced Application-Specific Rules > Generic OWASP CRS Rules.
The Edgecast 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 ECRS filter. Since requests not matching any 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 CRS Rules within the ECRS 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 WAF based on the type of application and their risk tolerance. The generic OWASP CRS 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 WAF Rules run in a specially designed sequence to maximize detection and minimize false positives.
Another important feature that enhances the accuracy of the Managed WAF Rules is the customizability of the rules. Each one of the 500+ Managed WAF rules can be customized to ignore specific request parameters (i.e., request header, cookie, query and body parameters). This enables customers to quickly remove any false positives using a simple user interface or API.
You’ve now taken the journey of an HTTP request through our WAF. Something that occurs billions of times every day within every Edgecast server in all 180+ points of presence (PoP) worldwide, as our high-performance WAF 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 WAF. I hope you now understand what sets it apart from other solutions. We combine an intelligent order of operations with the various WAF rules modules (from ACL to rate limiting to bot and custom rules), Managed WAF 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 WAF components and rulesets is like making a hamburger. It's not just about having the right ingredients, it's about how they are combined to make a great meal. The same ingredients put together differently can have a drastic impact on taste and the experience for the consumer.
Let’s connect to learn how Edgio can improve the security and performance of your web applications.
Get the information you need. When you’re ready, chat with us, get an assessment or start your free trial.