Adding "A7: Insufficient Attack Protection" to the OWASP Top 10

We know there are some very strong feelings about both the recent Top Ten Release Candidate and my involvement in the project. Steve Ragan does a nice job summarizing the issue in CSO: "Contrast Security Responds to OWASP Top 10 Controversy."  While it's uncomfortable for us to be targeted, the discussion online has been quite interesting, and there are respected members of the community on both sides of the issue. 

If you feel strongly about these issues, please join in and get involved. The Top Ten Project appreciates your constructive feedback and needs your help.  This release candidate is being updated to address a lot of the feedback already received.  Given the mixed reaction of many in the security community, we’ve scheduled an open session at the OWASP Summit.  Further, we’re planning to create a task force with a series of online working meetings.  If the conclusion is that these new items don’t make sense, let’s get something better figured out -- together.

Below is my detailed response that was published in CSO.
Read CSO's article "Contrast Security Responds to OWASP Top 10 Controversy" 

I encourage everyone interested in the OWASP Top 10 to participate in the process. The "T10" that was released earlier this month is a list of are "proposed candidates." OWASP plans to release the final version of the OWASP Top 10 - 2017 in July or August 2017 after a public comment period ending June 30, 2017. 

JEFF WILLIAMS RESPONDS
An excerpt from CSO's article "Contrast Security Responds to OWASP Top 10 Controversy"

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 under appreciated 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.