How OWASP changed the security rules overnight

Companies become increasingly aware of business risks related to application vulnerabilities. However, application security is a very difficult field. As a result, most companies have little or no expertise with it. Unfortunately, if you have little or no expertise with any given topic, it's difficult to define a sufficient set of test cases. As a result, companies tend to use "Top X" vulnerability lists of platforms like OWASP, WASC, The SANS Institute and others. One advantage of this approach is that those lists appear to be best practice as they are publicly made available by independent organisations that are dedicated to this area. And they are a best practice, since those vulnerabilities are so common they are the absolute minimum requirement for testing. Unfortunately, hackers don't care which attacks are listed and which are not.

Therefore, if companies focus too much or only on publicly approved top issues, they run inevitable into trouble, because they will miss risks that are slightly below the radar. You might now argue if companies violate their due diligence by only focusing on the most widespread risks. But in any way, ignoring certain supposedly lower priority attacks does certainly not make applications sufficiently safe. In turn, this invites hackers to focus on those "lower priority" attacks.

Focusing on top vulnerabilities only has another adverse effect. What if the security organisation suddenly changes the attacks on the list you chose as a benchmark? OWASP did this in May 2007 by putting Cross Site Request Forgery (XSRF) on their Top Ten vulnerability list. All your past assessments and security guidelines become more or less invalid over night and your applications have to be re-tested for the most current list of top vulnerabilities. This is a reactive process and definitely not a best practice.

But how should companies address such a seemingly moving target?

In our experience, it's better to have security testers to prioritize testing activities by risks rather than by vulnerabilities. What matters to business, is that one supplier should not be able to see the prices of another (that is a business risk). If he gains this information through forceful browsing or command injection attacks is of little relevance. The risk is that confidential information is disclosed and not any specific method of attack. Therefore, companies should rely on a more general practice, both for external testing and for internal security guidelines. For external testing, they should define "risk cases" rather than test cases and focus their tests on them. No matter what and how attacks are ranked at any given time, the risks to the company usually remain the same. Testing according to a risk profile assures the security of your assets in a sustainable way.

For development guidelines, companies should focus on root causes rather than specific instances of attacks. Understanding root causes helps identifying attack variations and countering attack patterns in other contexts.

The key take away for you:
Of course, companies are well advised to make sure all attacks listed in the top ranks are covered by their risk mitigation approach. However, focusing solely on these is not enough!

In one of the next issues, we will talk about how to apply a risk profile driven approach for security testing.