OWASP Top Ten for 20133 Major Updates to Application Security Risks
Back in 2003, I often made the case that application security was just as important as network security. By creating the OWASP Top Ten list of risks more than a decade ago with the Open Web Application Security Project, my hope was that it might be the start of an industry standard that could bootstrap the legal system into encouraging more secure software.
See Also: What is next-generation AML?
Negligence law comes into play when a party owes a duty of "reasonable care" to another party, such as a duty to comply with professional standards in an industry. But without a standard, making the case for what is reasonable is considerably more difficult. The introduction of the OWASP Top Ten was, by design, setting a relatively low bar to encourage organizations to get organized and make progress toward stamping out their application vulnerabilities.
It's disappointing to note that, a decade later, we haven't really stamped out any of the major vulnerabilities - quite the opposite.
At the outset, we didn't have much in the way of data to support the OWASP Top Ten, but we did have a lot of experience analyzing complex, critical applications and made some good guesses. Today, the OWASP Top 10 is based on risk data from eight firms that specialize in application security; those include four consulting companies and four tool vendors. Collectively, this data spans more than 500,000 vulnerabilities across hundreds of organizations and thousands of applications. The Top 10 items are selected and prioritized according to prevalence, combined with consensus estimates of exploitability, detectability and impact.
There are three major updates to the OWASP Top Ten 2013:
- Using Known Vulnerable Components (Lock Down Your Software Supply Chain). Just a few years ago, applications would include just a handful of libraries. But today, applications frequently have more than 200 frameworks, utilities and other components. As software development moves toward component assembly rather than writing custom code, the research shows that many of these libraries have known vulnerabilities. So the gains that come from this revolution bear a cost - ensuring that the components you use are up-to-date and secure. Unfortunately, it's not trivial to figure out what components your applications are using, and it's even harder to figure out which vulnerabilities apply to those components. The new OWASP Top Ten has suggestions for dealing with this problem.
- Missing Function-Level Access Control (Pretty Doesn't Mean Secure). While people always focus on protecting data, they oftentimes forget the fact that the functions that operate on that data are just as critical. When developers create their user interface in the presentation layer, 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. They often forget that they also have to put access controls in front of the functions. And that means an attacker can simply forge the required HTTP requests needed to invoke them. The new OWASP Top Ten expands this category and provides developers with helpful guidance.
- Sensitive Data Exposure (Encrypt Everything). Finally, the items pertaining to encryption in transit and encrypted data storage in the old OWASP Top Ten were combined. The new sensitive data exposure item is intended to focus development teams on a unified strategy to identify sensitive data and ensure that it is encrypted wherever it goes. See the new OWASP Top Ten for guidance on storing credentials safely, encrypting backups, caching, autocomplete and other often overlooked topics.
Since 2003, the OWASP Top Ten has been used by millions of people, and the OWASP Foundation has grown immensely. The FTC has even referenced the OWASP Top Ten in several of its actions. That being said, it's disappointing to note that a decade later, we haven't really stamped out any of the major vulnerabilities - quite the opposite. For example, SQL Injection appeared in 1998 and remains prevalent, accounting for 83% of breaches since then that compromised hundreds of millions of records. So I'm disappointed to report that the OWASP Top Ten for 2013 hasn't evolved much from the 2003 edition.
Despite the apparent lack of progress, there's no faster first step than using the OWASP Top Ten to make developers aware of basic application security issues and keep them on track for defending against attacks. The Top Ten is only an awareness document - one tiny first step toward cultivating a culture that generates application security. We have to recognize that we need to do an awful lot more if we want code we can trust. Remember, we rely on software for virtually every aspect of our lives - our businesses, communication, healthcare, finances and national defense. Our increasing reliance deserves a commensurate effort by software producers.
So, what's next? First, please help us get the OWASP Top Ten into the hands of every single developer on the planet. It's a brief document that provides clear guidance on the most important issues in application security. Second, don't stop with the OWASP Top Ten. There is no "right" way to create your application security program, so don't measure yourself against what others are doing. Instead, think about your organization's culture and choose tools and techniques that you believe will actually work. Then measure whether those things are helping you improve the security of your application portfolio. That's the only metric that matters.
Jeff Williams has more than 20 years of experience in software development and security. In 2002, he founded Aspect Security to provide application security consulting, verification and educational services. He is also an OWASP founder and has created many open-source standards, tools, libraries and guidelines - including the OWASP Top Ten.