Author: Todd Becker, PCI QSA, ISO 27001 Auditor
OWASP just released a new Top 10 for 2013, updating the list of key web application security weaknesses to reflect the evolution of the highest risk vulnerabilities. While everyone loves a good top 10 list, the fundamental question I wrestle with is, has the OWASP Top 10 been effective?
The OWASP Top Ten has been around since 2003, however, only the last two iterations, 2010 and 2013, have been prioritized by risk. While top of mind as a topic in security circles, the OWASP Top 10, and secure coding practices in general, don’t seem to be top of mind in many development shops.
Since the release of the 2010, risk-based top 10 list, there is very little direct evidence that web applications have become more secure.
The 2013 Verizon Data Breach Investigations Report (DBIR) shows decreases in threat action via hacking and malware and increases via social engineering and physical access. Can decreases in hacking and malware that might exploit vulnerabilities in web applications be attributed to increased security in web applications, as a result of secure coding practices inspired by the OWASP Top 10 of 2010?
The OWASP website provides a list of the companies and organizations that participate in developing the OWASP Top 10 as well as a listing of companies that utilize the OWASP Top 10. While this is not an exhaustive list, and there are certainly some significant companies identified, the application development community as a whole has not necessarily embraced the OWASP Top 10, or application security in general.
A 2012 Ponemon Institute study indicates that over 70% of developers feel that security is not adequately addressed in their SDLC, and over 50% indicated that their organizations do not have a training program on application security.
Adoption of secure development practices will continue to struggle as organization management focuses on low hanging fruit for risk management. When secure application development becomes one of the top priorities for management, the long development cycles of complex applications will ensure that real security is still a ways off in the future.
Application developers, designers and architects need to embrace secure development practices, regardless of organizational mandate. A grass roots effort to begin incorporating secure development concepts like the OWASP Top 10 can help to prohibit security breaches in the future; why wait for management to mandate that you follow guidelines that clearly make sense now?
What do you think, can the development community change the tide to do the right thing?
6 Comments
The problem with this is that organisations tend to have auto-correction for people who disregard their mandates. They have an expectation that mandates are that….mandatory. The Boolean logic in “Go big or go home” is as likely to be an && as an ||
Show the organisation that developing securely reduces follow on fixes, at the same time as delivering expected functionality on time. That’s not flying in the face of an organisational mandate (no company mandates insecure code) but working within it whilst trying to push the envelope. Key IMHO is to start small & try to quantitatively assess improvement in quality.
Learning to code securely will help with eradicating a lot of the OWASP top 10, even if you’ve never seen it before. A program should start with the basics of good coding, then bring in OWASP as the outcomes of not following those principles. Focusing on specific bugs encourages whack-a-mole practices. Again though, IMHO you need to work within the mandate not disregard it.
Fl1bbl3
@Gary, thanks for the comments, I wholeheartedly agree. Starting small and learning to code securely are great steps to making change; the quantitative assessment in quality improvement is what will sell the organization on a larger initiative.
I believe there are many developers, designers, and architects out there that weren’t taught how to code securely. It is in the best interest of the development community that they embrace those lessons as part of personal development and growth.
I agree that “Learning to code securely will help with eradicating a lot of the OWASP top 10, even if you’ve never seen it before. A program should start with the basics of good coding, then bring in OWASP as the outcomes of not following those principles.”
In my experience dealing with large and smalll companies (even in the PCI space, where OWASP training is regulated) do alot of hand waving around secure coding practices. It is often look at as hampering creativity and a bottle neck to getting code out quickly so it is typlically not included in the SDLC process.
Even companies that have dedicate security officers, do not include security in their development process. Until these dynamics change and security gets more of a corporate focus we will continue to see web applications be vulnerable and OWASP guidelines only making a minimal impact when they should be doing more.
The work that OWASP is doing is highly benificial and should be incorporated in web application development. It is up to us as security professionals to keep insisting that we are included in the process and in the end we will all benefit in a positive way.
@Michael, first of all, as you mentioned, the work that OWASP is doing is extremely beneficial, and as you noted, it is our responsibility as security professionals to push the process forward.
As the OWASP Top 10 is more of a guideline for design approach, rather than a development methodology, I believe these principles could be incorporated in any environment as good design, without requiring organization mandate, just personal accountability.
As developers, we don’t look to our organizations to tell us the best practice approach for solving various technical issues, that is our area of expertise, and it is expected that we bring that best practice to bear when designing solutions. Organizations shouldn’t have to mandate use of the OWASP Top 10 any more than they mandate use of specific design patterns.
Developers, designers and architects should recognize the long term impact of not adopting solid secure development design practices. Just because it is easier and more cost efficient to store 2 digit years doesn’t mean it is the right thing to do… we know that now.
“50% indicated that their organizations do not have a training program on application security.”
For many developers security is an after thought. They are asked to do more with less and are under pressure to deliver sooner and sooner. That means something has to get left behind and usually it’s the security process.
@Jessica, you are absolutely right. The underlying value of a security training program is to infuse security into the core design capability of developers/designers. Certainly, it might be more time intensive to ensure levels of security, however, with a core knowledge of secure development practices, developers/designers can make explicit decisions where risk is appropriate, rather than wholly disregarding security and risk concerns.