Do You Need a WAF, or Something Better than a WAF?

“The king is dead! Long live the king!” The jarring conflict embodied in this timeless hoorah is about to apply to the application security space. Subjects are giving up on the old king—the web application firewall (WAF) technology—as their primary appsec tool, for several reasons. First, because WAFs are too complicated. Second, because attackers have changed their attack vector to target credentials at scale (credential stuffing) before hacking. Third, and most important, because the market has evolved to offer an approach superior to WAF in efficacy, value, and worker hours invested.

While we at Shape Security have been predicting the shift away from WAF for years, others have been taking note. The PCI DSS specification had previously mandated a WAF, and that drove WAF sales for a decade. However, the language of PCI DSS has changed in 6.6, and other solutions can be used to fulfill the requirement. Even Gartner, the analyst firm most closely associated with late-adopter pragmatist buyers, is changing their WAF magic quadrant to the Web Application and API Protection (WAAP) market. Because Gartner lags visionaries by several years, this should be the final signal a buyer needs to decide it’s time to look beyond WAF.

The new approach is a distributed, cloud-based, machine-learning TURING service backed by anti-automation specialist operators. Let’s call it “anti-automation” for short until a clever analyst comes up with a better name.

WAFs are Too Complicated

Consider the statement that WAFs are too complicated. In our experience working with customers over the last decade, we’ve rarely, if ever, seen complete WAF protection cover even a tenth of critical applications. Frequently, the WAF has just a single dedicated (and expensive) administrator, and the ruleset for the WAF must be updated under the following conditions:

1. When attackers evolve an attack to get around existing signatures.
2. When content has been added (which is constantly in today’s agile web paradigm).
3. When a web vulnerability is detected in the application or any supporting infrastructure (2018 had 900 critical CVEs — six for every working day).

These factors, which are all external to the WAF, quickly overwhelm the administrator and end up protecting only a handful of applications (or a single application). And usually not well.

Credential Stuffing and Retooling are the New Threat Vectors

Even if WAFs had done their job properly, it wouldn’t really matter because attackers have radically changed their approach. Gone are the days of attackers manually hacking websites. Today, they focus first on taking over the accounts of legitimate users. From there, they perpetrate their blight or escalate their privilege.

Today it’s all about credential stuffing. Attackers test millions of breached credentials using automated tools like Sentry MBA, PhantomJS, or automated headless browsers to gain their initial beachhead. Between 0.2% and 3% of credential-stuffing attempts are successful—a piteously low rate, which is why attackers try millions of credentials at a time. Even a 0.5% success rate using one million breached credentials will yield 5,000 accounts.

WAF technology was designed to stop SQL injections, not credential stuffing. An on-premises WAF managed by a single or part-time resource has no hope of defeating sophisticated credential-stuffing campaigns.

When a defender concocts a rule to stop a credential-stuffing campaign, the attacker pauses, retools to get around it, and then resumes the campaign. We at Shape see this all day, every day, with up to ten different levels of retooling. No single resource can keep up with that degree of sophistication, and the world is coming around to admit the problem.

The New Paradigm for Application Protection

If we all admit that the WAF is too long in the tooth, and that attackers have changed their approach anyway, the obvious question is: What is the right approach?

There are only a handful of highly skilled specialists with the right combination of technologies to consistently defeat and deter attacker automation. The key technologies of the best approach are:

1. Artificial Intelligence (AI). Each attacker is launching millions of login tests, from millions of different IP addresses around the world. Only an AI-assisted SOC can see through the tidal wave and pick out real users.
2. Expert-Assisted Mitigation. As useful as AI is, no vendor has machine-learning models that can detect and block all automation without also blocking real users (false positives). AI must be used to detect and flag campaigns to real human operators who make the final determination and remediation.
3. Collective Defense. Most attackers launch credential-stuffing campaigns against multiple defenders in a serial fashion. The right approach must include defending a plurality of targets in each vertical market, so attacks seen against one company can be used to inoculate all the other companies before the attack can get to them.

Shape Security pioneered all these technologies for the Fortune 500 and Global 2000, and we’re now bringing them to everyone else to take the burden off WAF admins.

Looking Beyond the WAF

The OWASP Top Ten is the Open Web Application Security Project’s top-ten application security risk list. The legacy WAF technology was the only tool specifically designed to speak to the OWASP Top Ten, but at the end of the day, it was poorly suited to solve the list’s issues. Table 1 shows a breakdown of how well a WAF executes against an anti-automation service like Shape for each entry of the Top Ten.

Let’s dive a little deeper into some of the Top Ten.

#1: Injection, #3: Sensitive Data Exposure

One could argue that the number-one job of a WAF is to prevent SQL injection. Modern organizations have learned to use identity as perimeter to keep unauthenticated users from causing any kind of SQL query, and that in itself is a commendable first line of defense. To get around the perimeter, attackers must gain control of an account. To do that, they use credential stuffing or brute force, both techniques that are much better blocked by an anti-automation service than a WAF.

#2: Broken Authentication, #5: Broken Access Control

Authentication systems are difficult to perfect. When they fail, they increase risk disproportionately to other systems, which is why OWASP keeps them high on their list. With sufficient tweaking, a properly configured WAF can assist broken authentication or access control system. But wouldn’t the knowledge to create the necessary defensive WAF configs be better utilized fixing the original misconfigurations? The anti-automation service simply detects that systems probing for these vulnerabilities are not human, and blocks them—which is a much simpler and broader approach than trying to make sure every knob is at the right level.

#10: Logging and Monitoring

Insufficient logging and monitoring of the application weaken   incident response. WAFs can help by flagging attacks before other systems do, but an anti-automation service comes with its own highly trained, specialized SOC. There is no contest here.

Conclusion

The final defense for WAF apologists used to lie in the PCI DSS WAF requirement, but even those have been relaxed to allow for a more flexible solution, and that’s a good thing. Shape Security has additional documentation on how cloud-based services can meet the requirement here.

Given all these factors—the deprecation of PCI DSS, the decreasing emphasis on WAF (and its magic quadrant), the evolution of credential stuffing, and the strategy of identity as perimeter—the market has been casting about for a new solution. Shape’s distributed anti-automation service, fronted by machine learning and backed by specialist operators, is rising to meet the challenge.

*** This is a Security Bloggers Network syndicated blog from Shape Security Blog authored by David Holmes. Read the original post at: https://blog.shapesecurity.com/2019/05/01/do-you-need-a-waf-or-something-better-than-a-waf/

Comments are closed.