Why do web application firewalls appear so complex?

When we discuss cloud security with prospects and customers, complexity will inevitably come up as a challenge. Many web application attacks have been successful because they targeted improperly configured web application firewalls (WAFs). One of the most popular attacks — SQL Injection (SQLi) — isn’t new, yet many organizations don’t seem to have learned anything since Heartland Payment Systems was successfully hacked in 2008 using SQL injection. Heartland was the sixth-largest payments processor in the U.S. at the time, and the breach compromised millions of business and personal credit/debit accounts.

Heartland did have a web application firewall in place, but the company’s security configuration did not defend against the SQLi attack. The company paid $145 million in compensation, temporarily lost its PCI DSS compliance, and its stock price dropped by nearly 80% over the next three months. Despite the massive cost and negative publicity around this attack, SQLi still accounted for more than 68% of all web application attacks in 2020. That’s up from 44% in 2017.

With SQL injection considered “low-hanging fruit” on the scale of potential web attacks, it quickly becomes clear that there are numerous ways web-facing sites can be attacked and an equally impressive array of solutions to prevent them. Each attack can be a little different and target a single weak point. Therein lies the complexity.

SQL injection is the easy example: “Trust no one” and “Don’t use Dynamic SQL.” That’s easier said than done, especially in a remote world. A web application firewall has specific capabilities to identify suspicious code and injection attempts, but they need to be applied properly.

SQLi is not the only type of successful web application attack. The second most popular is a distributed denial of service or DDoS attack, where a website is essentially swamped with spurious, automated requests causing it to crash. The security and configuration that you need to have in place to prevent DDoS are very different than what you need to defend against SQLi, cross-site scripting, and other attacks.

Reasons so many attacks are successful

Web application firewalls are designed to prevent all of these web-facing attacks, so why are there still so many successful attacks? It turns out that organizations’ web properties and customers together are more unique than they are similar. A WAF needs to be configured to each organization and each set of users. Going back to our SQLi example, if an organization is working with user-provided code, it would be tempted to simply turn off the SQL inspection portion of a WAF. This is the mistake that Heartland made.

Another popular feature is geo-blocking, which blocks all the IP addresses that come from a known hacker hotspot or location. This may be a great idea for companies that do not do business internationally. However, many companies operate on an international basis, either by selling to foreign countries or receiving inventory from abroad. Blocking an entire region may not be an option for these companies.

Configuring a WAF is a balancing act. If you turn on all protections and block all traffic, then you’ll end up getting no traffic to your application. Your online business will not be in business. Many companies will set up their web application firewalls in monitor mode. Certain protections are deployed, but the WAF is also monitoring for specific attacks so that the IT team can harden the security as the need arises.  The other end of the spectrum is to provide some simple “one-size-fits-most” security in a service-delivered WAF. These work to a point but fail when the organization encounters an app or a user that doesn’t fit the “one-size” parameter of these devices and the companies just turn that protection off for everyone. This is an architectural problem; these simple WAFs employ a central rule set (CRS) that governs whether or not data passes through the WAF. A reverse proxy WAF, on the other hand, will intercept the data and inspect each packet in both directions. The WAF then applies customized rules depending on what it finds in the packet.

How Barracuda can help

We realized at Barracuda we could build a web application firewall that offers the best features and benefits of each solutions. We could stand up our WAF in a cloud data center, create a “standard” rule set based on what we’ve seen over the past 10-plus years we’ve been building WAFs, and roll this out as a SaaS solution that has all of the “knobs and dials” of the full-featured WAF. Basic protections that fit most use cases are already enabled, but organizations can make adjustments as they encounter apps and users that the standard protections do not properly protect.

In short, we provide all the power of a traditional web application firewall with the simplicity and ease of a service-delivered WAF.

Barracuda WAF-as-a-Service is a full-featured application security service that can start protecting all your apps in just a few minutes.