3 Reasons Not to be Dismissive of OWASP Top 10’s “Insufficient Attack Prevention”

Last updated at Tue, 14 May 2019 19:34:01 GMT

In April, OWASP released the draft for the new 2017 OWASP Top 10, and immediately a flurry of indignation, vitriol, and conspiratorial accusations began to fly, mostly around number A7, “Insufficient Attack Prevention.” When I first read it, I thought, “Finally, people were getting it.”

To me, runtime monitoring and protection has been neglected in light of advanced threats, and yet, OWASP’s audacious inclusion of this, I knew, was certainly to provoke a polarizing reaction.  Afterward, I’ve observed the back and forth along the sidelines, and now that the dust has settled a bit, I feel I’m in a better headspace to understand why people have a problem with its inclusion, and also have had time to evolve my thoughts on the subject.

To start, it’s true the name of this item sounds oddly vague and out of place with other items. “Insufficient Attack Prevention.” Does it simply mean, insufficient security? In which case, why not replace the top ten with just that one item? Further, as many immediately pointed out, it doesn’t sound like some other items on the list, such as XSS, or Injection Attacks, which are well-defined vulnerabilities in applications. Then there are the contrarians boldly claiming that any such solution will make people LESS secure, by hindering whitehats and increasing attack surface. Finally, the salacious line of attack against the inclusion of A7 is that it is a co-opting of OWASP by a particular vendor.

Note: For the sake of discussion, I’m going to refer to A7 either as A7, or lack of runtime monitoring and protection. It doesn’t roll off the tongue as concisely, but I feel it is more descriptive.

#1 Vendor Corruption

The last one is a natural suspicion, since every security professional is constantly bombarded by vendors with something that’s supposedly going to make their life easier, and as security professionals, we often seek shelter from that onslaught in conferences and meetups geared towards practitioners. OWASP, being a non-profit foundation to promote AppSec, shouldn’t devolve into an organization driven by profiteers. As security professionals, we’re also trained to have healthy (and sometimes unhealthy) skepticism.

However, as criticisms of A7 goes, this is probably the simplest to dismiss if one scratches below the surface. For anything valuable, there will be a vendor (and often many). But the existence of vendors doesn’t mean something is not valuable. What is more important is to question the level of value and whether A7 is prescriptive of spending money on vendors. As it turns out there is plenty of precedence in OWASP projects themselves, AppSensor and ModSec, being two obvious examples, and many organizations have rolled their own solutions. There are WAF vendors, RASP vendors, and other vendors out there, but that only further supports the argument that there’s value in runtime monitoring and protection.

Further, OWASP as a part of its charter promotes AppSec best if it engages with vendors to encourage solutions that serve the most pressing needs. The focus is best spent on having a vigorous debate on merits, rather than implications of conspiracy.

#2 Makes you LESS Secure

The main objection here is that it makes it much harder for pentester, the assessments will be less reliable or more expensive (or both), and therefore, you are left less secure. This seems on the surface to be an intuitive conclusion, but it hides some assumptions.

First is that a pentester is being hindered by the “real problems” that the runtime protection is “hiding.” However, a strong argument can be made that a pentester should evaluate the defenses holistically, and that should include the runtime monitoring and protection. If the pentester gets weird results because of some protection mechanism, well, that’s what an attacker is going to experience as well. Many bypass techniques have been published for things such as WAFs, and the pentester can also utilize the bypasses like an attacker would, and see how exploitable the app is. As a part of the assessment, it makes sense to consider runtime protection mechanisms.

That being said, pentesters are being paid for their time, and spending time hitting automated responses is arguably not cost-effective, in such a case, there is a simple solution: just turn it off. This will allow for more time in finding inherent vulnerabilities in the application. As an example for ModSec, Christian Folini has an excellent blog on the subject called “An A7 First Aid Kit.”

Second, there is another conflation in general in that A7 implies there is always an active response. There’s a significant value just in runtime monitoring to state the obvious. In fact, running runtime solutions during a bug bounty in monitor-only mode itself has a wealth of value in understanding what tools and techniques are being employed, what areas are being focused on, and why. All of which can educate a team on how to improve security even if few vulnerabilities were actually found. More security!

Third, in regards increasing surface area, anything anyone uses can arguably increase surface area. Pick the cloud service, tool, library du jour, and there’s your surface area. The question is, are those mechanisms built and secured so they don’t add unacceptable risk? And is the net gain that the site is more secure. I would argue that a site with strong runtime monitoring and protection capabilities are more secure than without, all things considered.

It’s work to think these things through, dismissing things outright is much easier, but as responsible security professionals, it’s imperative to not take the easy path. The details are important.

#3 “That is not a vulnerability”

That is an obvious fact. A vulnerability is a flaw with well-defined characteristics, such as data being interpreted as code due to a vulnerability in the application, in the case of injection attacks. However, the OWASP Top Ten, contrary to popular belief, is not merely a list of the more prevalent vulnerabilities. It’s very clear from the website that the OWASP Top Ten is the top ten: “Most Critical Web Application Security Risks.” If it was a catalog of vulnerabilities, it’d say “Vulnerabilities” rather than “Risks.” So there it is.

In fact, there’s already precedence with other items. In OWASP Top Ten 2013, there was A5 “Security Misconfiguration.” That’s not a vulnerability! Nonetheless, a powerful way to ensure security is to properly configure your app. By the same token, something you should consider from a risk perspective is how well you are monitoring your application for attacks and exploits, as well as your capability to have an appropriate (and fast) response. In today’s world of continuous integration/deployment, automation is key to success, and it is no different for security. Today’s threats are automated, and so should defenses.

Concluding Comments

On the whole, the arguments against A7 have their merits, and certainly can and should be debated rigorously. On the whole, given the times we live in of rapidly developing applications, ever-growing libraries, shifting architecture and deployment paradigms, as well as rapidly evolving and rising automated threats, the OWASP Top Ten can’t stay still. It too should adapt to the times. The OWASP Top Ten is not a spec or a standard, it is the start of a very important conversation, and thus, it should highlight the most important things to consider, and not limit itself to only vulnerabilities. The inclusion of A7 is a fitting addition in this light.

Since I can’t improve on the wording, I will close with quoting the purpose of the Top Ten:

The OWASP Top 10 is a powerful awareness document for web application security. It represents a broad consensus about the most critical security risks to web applications. Project members include a variety of security experts from around the world who have shared their expertise to produce this list.

We urge all companies to adopt this awareness document within their organization and start the process of ensuring that their web applications minimize these risks. Adopting the OWASP Top 10 is perhaps the most effective first step towards changing the software development culture within your organization into one that produces secure code.