Contrast Security has addressed the recent backlash over section A7 of the OWASP Top 10 list for 2017. The company issued a statement on the matter after industry professionals suggested the A7 addition was an example of a vendor pushing their agenda on the OWASP Top 10 project.
The OWASP Top 10 for 2017 was released earlier this month in draft format, so some changes could take place before the final, official release.
However, when the public started looking at the draft, sections A7 and A10 stood out. Most of those commenting on the changes agree that A10 is a good addition, as API security is important these days, while dismissing A7 as a vendor pitch.
A7: Insufficient Attack Protection
According to Contrast Security, this new addition to the OWASP Top 10 means that applications will need to detect, prevent, and respond to both manual attacks, as well as automated ones. The idea is to remove, "invalid input" messages with actions, such as blocking the attempts and flagging the account in question.
As it happens, Contrast Security offers a product called Contrast Protect, which could deal with the situations covered by A7. In addition, Contrast Security was one of the vendors who made suggestions leading to the creation of A7 (the others were Shape Security and Network Test Labs Inc.). The outline of A7 even mentions Runtime Application Self Protection (RASP) directly, which is what Contrast Security offers.
The mention of RASP caught some flack as well, with many people referencing a Dark reading article from 2015 calling the solution a false sense of security.
An outline of some of the complaints against OWASP, the addition of A7, and Contrast Security can be viewed with just a few searches of social media, including Twitter, where most of the complaints originated (archive link).
Outside of Twitter, some professionals took to their personal blogs to offer their opinions on the matter.
"…addressing any other entry in the top 10 provides a clear net positive to a webapp’s security posture, whereas complying with A7 can easily cause a net harm. Complying with A7 makes it extremely awkward to run an accessible bug bounty program, since it will hinder researchers trying to help you out. It also increases your attack surface (much like antivirus software) and introduces the risk of denial of service attacks by spoofing attacks from other users…," wrote James Kettle on his blog, Skeleton Scribe.
On Medium, Josh Grossman, weighed in and noted that the latest draft of the OWASP Top 10 does not have the appearance of independence, and it isn't clear if it can demonstrate actual independence, due to the way the raw data is presented, as it isn't clear how that data resulted in the current list.
He also stressed that more companies need to be involved in contributing to efforts like the OWASP Top 10, noting that only eleven companies had "contributed the vast majority" of the data in this newest draft.
On the nVisium blog, the company posted their thoughts on the latest OWASP Top 10 draft, paying close attention to the raw data and what could be learned from it.
On the OWASP mailing list, comments on A7 were rather blunt, including one that it was "a solution looking for a problem, rather than a distinct development issue that programmers should become aware of."
Another email thread on the topic had those on both sides of the argument weighing in. The COO and co-founder of Aspect Security, Dave Wichers, also commented on the topic.
Considering all the comments, Salted Hash reached out to Contrast Security and asked them to comment on the situation. Jeff Williams, the company's CTO and co-founder offered a detailed response, which we have posted below, with no editing or corrections:
The Top Ten project is the most open and process driven project at OWASP. There is an open data call, notice and comment process (which we are in), mailing list, etc... Over the years it has become more and more scientific. The first one in 2003 was just anecdotal, but now the data call goes out for anyone to contribute data. The project is open for anyone to participate in. Unfortunately, like most OWASP projects, it is a huge amount of work and very very few contribute.
The project uses the open data call data to select and prioritize issues, but has also always looked to experts for ideas on what we could include that would drive the appsec community to get in front of problems instead of being reactive. In 2007 it was CSRF, which is still a top ten item supported by tons of data. In 2013 it was use of libraries with known vulnerabilities, again an obvious yet serious and underappreciated problem, and the T10 helped to refocus the industry on it.
And similar accusations were floated last time, that Aspect somehow benefited from the addition of items to the T10. It's true, Aspect (and now Contrast) benefit from everyone knowing more about appsec. And so does everyone else. To suggest that any of these additions is motivated by anything other than concern for the security of apps everywhere is misguided. Frankly, both Aspect and Contrast benefit far more from the other items in the T10, like SQL injection, XSS, access control, and authentication.
This time, the project added a new item, suggesting the sort of obvious idea that applications should detect when they are under attack and have the capability do something about it. This step towards operational concerns is a new direction for the T10. But why not try the experiment? Certainly publishing a list of the same stuff won't change anything. And with DevOps rising, the difference between securing Dev and securing Ops is shrinking. Depending on where you observe the problem from, isn't the lack of a defense a security vulnerability? It just depends on what we expect from our code, our vantage point on security.
The fact that anyone can attack the vast majority of applications undetected, and continue until they find a weakness is scary and unnecessary. I've personally been speaking about this and teaching it in my classes for at least 15 years. Much of the appsec industry is focused on creating clean code, rather than protecting against attacks. But clearly we need both, as all the focus on hygiene hasn't worked. Developers can take measures right away, such as identifying impossible requests. There are also a variety of open source projects that focus on this, like AppSensor, ESAPI, and AuthTables.
While the new T10 item isn't focused exclusively on RASP, that seems to be the focus of many comments about Contrast, so let's talk about it. There are 20+ vendors, spanning the full range from startup to giant, that are building and selling RASP. It's worth considering whether this too indicates a real problem shared by application owners. I assure you that the vendors and their investors are doing their diligence on the space. The analysts too have been writing about RASP, and more broadly attacks, for years.
It makes some sense that a community focused on finding vulnerabilities and eliminating them is a bit allergic to the idea that blocking attacks might be a valuable approach. Some who have made their living attacking apps may really hate the idea. But I hope that the conclusion is that we recognize it takes both belt and suspenders. In a world of DevOps, cloud, containers, and elastic apps, there's a need for a way to detect and block attacks and provide patches. Not that this is a silver bullet, but an important part of a well-balanced appsec breakfast.
I hope everyone interested in helping with the OWASP T10 will participate in the process, and discuss the pros and cons of this latest release candidate.