The OWASP Top Ten and Beyond

The past decade shows only trivial progress in improving web app security, according to new vulnerability guidelines in the OWASP Top Ten 2013.

Application security problems are not only the most common type of vulnerability, they also lead to the majority of breaches. In 2003, I wrote the first Top Ten Application Security Risks for the Open Web Application Security Project (OWASP). Our goal at the time was to raise awareness and improve software security through the establishment of free and open industry standards.

In case you are wondering, OWASP is an open-source community comprised of software developers from corporations, educational organizations, and other interested individuals from around the world.

The first Top Ten was based primarily on our members' experiences -- we didn’t have much data to support our choices back then. Today, there’s serious analysis backing the standard in the OWASP Top Ten 2013. The data comes from eight leading security firms specializing in application testing and verification. Collectively, the data is comprised of over half a million vulnerabilities, across hundreds of organizations, and thousands of applications.

The Top 10 items are selected and prioritized according to their prevalence and consensus estimates of exploitability, detectability, and impact. It’s been translated into dozens of languages and is implemented in most application security tools. There are three major updates this year:

• Using Known Vulnerable Components. Modern applications frequently leverage hundreds of libraries. All of this code runs with the full privilege of the application, so vulnerabilities can be devastating. A recent study by Aspect Security of over 113 million library downloads by developers in 60,000 organizations, showed that 26 percent of those downloads contain known vulnerabilities. The new OWASP Top Ten has suggestions for finding and eliminating these problems.
  
  
• Missing Function Level Access Control. When developers create web interfaces, they have to restrict which users can see various links, buttons, forms, and pages. Developers usually get this right because it is very visible. Unfortunately, making it pretty doesn’t make it secure. Developers often forget that they also have to put access controls in the business logic that actually performs business functions. The new OWASP Top Ten expands this category and provides helpful guidance.
  
  
• Sensitive Data Exposure. The importance of encrypting both web traffic and sensitive data in storage cannot be underestimated. This new combined Top Ten item is intended to focus development teams on creating a unified strategy to identify sensitive data and encrypt it wherever it goes. You can refer to the new OWASP Top Ten for guidance on storing credentials safely, encrypting backups, caching, auto complete and other often overlooked topics.

Important work is still ahead

Over the last 10 years, the OWASP Top Ten has been used by millions of people, referenced by the Federal Trade Commission, and the OWASP Foundation has grown immensely. We’re very proud of our efforts to date, but we still have a long way to go.

Initially, our principal goal was to raise the floor every few years, but we haven’t been able to do that, as evidenced by what I consider to be essentially trivial results in improving application security. In the decade between the 2003 and 2013 editions, we haven’t been able to stamp out even one category of application security problem. For example, SQL Injection appeared in 1998 and is still a huge problem that accounted for 83 percent of breaches over the last 15 years and resulted in the compromise of hundreds of millions of people’s credit card numbers, financial information, and healthcare information.

One reason for these disappointing results is because the OWASP Top Ten is only an awareness document -- just one tiny first step towards cultivating a culture that generates application security. To be sure, there’s no better first step for raising IT industry awareness of the application security issues that drive security managers to focus on cost-effective defense strategies.

To that end, I encourage you to pick just one of the Top Ten, create sensors in your development and test organizations, and establish a real-time dashboard across your application portfolio. Then expand your program to cover other risks. There is no "right" way to create an application security program, so don’t measure yourself against what others are doing.

If you know a developer, take a second and send them a copy of the OWASP Top Ten. It’s time to eliminate simple vulnerabilities like Cross-Site Scripting and SQL Injection forever.

Now it’s your turn.

Developing a robust application security program does not need to be a daunting task...

Perhaps, all it takes is rethinking your existing program and moving to one that leverages a continuous application security (CAS) approach. Organizations practicing CAS quickly determine how a new risk affects them, design a defense strategy, and measure their progress to 100% coverage. By implementing eight functions within an enterprise you can assemble an effective application security program. 

A version of this article originally appeared in InformationWeek in November 2013.