Original source: Edgecast
As more application development teams integrate security into their workflows, they’re looking at the impact of security on their application — from an application pipeline, workflow and performance perspective.
Web application firewalls (WAF) are commonly deployed in an application stack due to compliance requirements. But as organizations move their workloads to the cloud and begin to embed security into the fabric of their application, the role of the WAF is evolving. Organizations need WAF platforms that can scale and adapt to the changing cloud architectures and growing security threats.
In this article, we’ll review how the WAF engine — and more specifically, a ruleset built specifically for use with that engine — can be adapted to scale into cloud workflows and improve the performance of your web application while maintaining strong protection from online threats.
The WAF should be an important part of your application stack and network security program. Traditionally WAFs were disconnected from application development and were viewed as a security layer that sat outside the application. But modern WAF architectures and tools have helped SecOps collaborate with DevOps along the CI/CD process, including WAF rule creation and testing as an application is developed. When used properly to analyze the traffic traversing your application infrastructure, the WAF engine and its ruleset play an important role in how fast the analysis is completed and how well the resulting audit and block decisions perform as a part of the overall application architecture.
Similar to a car’s engine, computer, and drivetrain, a WAF engine, its rulesets and the application it protects should be designed and optimized to work together. A car manufacturer doesn’t design an engine in a bubble. It must be optimized for the rest of the car’s frame and components to reach peak performance and efficiency across the board. The same should hold true for the WAF engine and its ruleset. A WAF that doesn't account for these variables can get overworked, overloaded, and ultimately degrade the performance and user experience of the web application.
The Edgecast WAF uses a combination of open source, industry and proprietary signatures to inform its ruleset. We carefully evaluate each signature’s impact on the performance of the overall ruleset.
As we designed and optimized our WAF engine, we saw that by collecting and consuming the open-source and industry rulesets without any modifications, (nearly) every rule would need to be analyzed as the traffic crosses the wire. This model is fairly common amongst WAFs and makes it “easy” to see what happens to the traffic. But it also forces the WAF to run through every rule to evaluate the risk associated with the traffic. This puts an unnecessarily heavy workload on the WAF that is further exacerbated as the ruleset grows.
Of course, it’s not always about speed. A key element in a WAF is its ability to determine the risk (compromise) versus reward (successful transactions) associated with the traffic and decide whether to flag the traffic as malicious, suspicious, or benign. The WAF would then either send an alert to the team (audit/alert mode) and block or re-route the traffic if it is deemed too risky to let through (production/block mode).
This analysis becomes an even bigger challenge when looking at the open source and industry rulesets being ingested. It’s unlikely they’ve been created with speed and efficiency in mind for every possible WAF engine in the market. This doesn’t mean they’re bad, it just means they focus on risk first leaving performance as an afterthought. In other words, there’s room for improvement.
With rulesets created for completeness and accuracy first, many WAFs find they can’t handle the traffic being analyzed in both modes (audit and block), forcing InfoSec teams to pick a mode: start with audit mode and moving it to production mode, or going straight into production mode with little to no real-world testing, which leaves them open to missed threats and false positives.
The open-source OWASP ModSecurity model for rulesets provides a standard, consistent manner through which WAF rulesets can be developed and implemented. To complement this, OWASP offers an industry generic ruleset that can be ingested by a WAF that follows this model.
However, as our team was implementing the ruleset they realized that the rulesets being ingested — while complete and accurate—were indeed holding back the WAF engine. So, the team decided to take a deeper look at how rulesets are structured and processed. What we found, which should not be a surprise to any WAF admin, is that a lot of rules go through the same data over and over to cycle through the checks necessary to determine the riskiness of the traffic passing through the WAF.
Some of the protocol enforcement rules are fairly straightforward and don't actually have to “live” inside the ruleset ecosystem. To address this, we first developed the ruleset in a way that effectively trimmed down the OWASP ruleset by implementing them directly into the WAF engine in a non-ModSecurity format. This results in early execution and faster detection.
Next, we targeted rules that analyze request bodies. We built a caching layer which mitigates the performance overhead of recalculating the same expressions in the rules. Taking an example of XML format bodies, we searched how many times the expression “XML:/*” appears in the OWASP CRS ruleset to see how many times an XPath could be recomputed in the processing of a single request without a caching layer, the number is significant.
Finally, where a lot of macro expansions/string substitutions and explicit searches take place, we identified and removed those rules out of the ruleset and implemented them in the engine with better lookup and search algorithms such as HashMap lookups and phrase match (pm) operator instead of a regex (rx) operator wherever possible.
By doing things differently with the structure of the rulesets, our WAF engine uses faster data structures and open standard formats like JSON, which are easier to configure and run faster. This results in better performance, not only in terms of speed, but also in terms of accuracy:
Low false positives: Edgecast arranges and controls the ruleset in a way that ensures accuracy is maintained
Enhanced engine performance: The Edgecast WAF engine runs the rulesets in a manner that avoids overtaxing the engine
For example, for the OWASP IP blocklist policy rule, the ModSecurity engine uses its own “msc_tree” algorithm that looks at a bad IP’s list. Alternatively, the Edgecast WAF engine uses a different algorithm that is quite a bit faster. The following test results shows how Edgecast WAF performs against ModSecurity. ModSecurity adds about 200ms to 500ms latency when performing a million queries on big IP lists. Edgecast WAF handles around 10B requests per day across its network. These small numbers matter a lot on such a large scale.
A better WAF engine and ruleset combination also means organizations get faster performance and the ability to run WAFs in dual mode (in both block mode and audit mode). This allows security operations teams to experiment with new rules against production traffic in audit/alert mode, giving them a chance to fine-tune the rules before promoting the ruleset to block mode on the WAF.
The highly customized Edgecast WAF rulesets give admins the ability to slice and dice everywhere and run the rulesets in dual mode. With the same rules applied to different settings, admins can run them twice while not impacting performance—thanks, in part, to the intelligent engine and ruleset implementation.
The value here extends beyond the WAF management team. In fact, many Edgecast customers integrate this option in their DevOps lifecycle, giving the business, the engineering team, and the IT security team the ability to collaborate and test the rules in audit mode before applying them to production blocking mode.
This two-step process allows the IT security team to vet firewall configuration changes before they are activated, equipping the team with data to test changes on real production traffic, thereby reducing false positives once the ruleset is placed into production. Once the ruleset has been validated, updated configurations are deployed within seconds. And rollbacks, if necessary, are possible within a few minutes. This makes meaningful ruleset trials much more realistic, dynamic, impactful, effective—and in support of the business objectives.
The Edgecast Dual WAF Mode approach also improves performance even further as the intelligent ruleset ensures known malicious traffic is blocked quickly to give some breathing room to the WAF so it can handle the rest of the traffic it is constantly being presented. This, in turn, gives admins more time to focus on gaining predictive visibility; in other words, they can see things in the applications via audit mode before the applications are deployed to production sites.
If your business needs an application stack that can adapt to unpredictable workloads and still deliver a highly secure architecture, consider the WAF engine and ruleset design. When optimized, these factors can enhance the performance of your web applications.
For more information on how the Edgecast WAF intelligent engine and rulesets can protect your web applications with speed and accuracy, let’s connect today.
Get the information you need. When you’re ready, chat with us, get an assessment or start your free trial.