[Owasp-leaders] OWASP Top 10 2012

Juan Carlos Calderon Rojas juan.calderon at softtek.com
Tue Oct 11 10:07:05 EDT 2011

IMHO OWASP Top 10 has well defined objective and have served it well in these years: "To spot Top 10 risks for applications". The model worked and proof of it is that it is a very well know document now. Changing its objective so drastically will break it and harm OWASP as well.

It is misused as standard... that is true, but is lack of (other) better consumable documentation the one to blame, Top 10 is so straight forward that it is easy to point to it.

Take ASVS for example is a great document and it is intended to test for security controls to be in place. Why not making ASVS as well know as Top10 instead of changing a well established document. ASVS + ESAPI has most of the items listed below. What about doing a parallel "OWASP Top 10 Security Controls" based on what portions of existing documentation to implement? It sobjetive will be "with this 20% of controls you will be protected agains 80% of vulnerabilities and that is the minimum you should consider", just as current top 10 is the least list of risk to consider.

Let's build upon what we have, build more, rather than take down something that (IMO) is already solid. I am in for that Top 10...


Juan Carlos Calderon

De: owasp-leaders-bounces at lists.owasp.org [owasp-leaders-bounces at lists.owasp.org] En nombre de Andrew van der Stock [vanderaj at owasp.org]
Enviado el: martes, 11 de octubre de 2011 06:13 a.m.
Para: Chris Schmidt; Tony UcedaVelez; Dave Wichers
CC: OWASP Leaders
Asunto: Re: [Owasp-leaders] OWASP Top 10 2012

One of the things I'd really like for the Top 10 2012 is to stop focusing on the things that went wrong in the previous 12 months, and start to concentrate on the Top 10 things to get right for the next five years. The existing Top 10 regularly gets incorporated without permission into various other standards, and it's 100% the wrong way around for that purpose. The Top 10 was never designed to be a standard.

To address this, here's my short list (in order):

 1.  Security Architecture (including incorporating agile ideas)
 2.  Use a (more) secure development frameworks and leverage enterprise frameworks (UAG, etc)
 3.  Input validation
 4.  Output Encoding
 5.  Identity: Authentication and Session Management
 6.  Access Control (service / controller, data, URL, function / CSRF, presentation, etc)
 7.  Data Protection (Data at rest, including in cloud)
 8.  Audit, Logging and Error Handling
 9.  Secure Configuration
 10. Secure Communications (Data in transit)

All of the items must be testable. All items must be positively framed and eliminate entire CWE classes in their own right.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/owasp-leaders/attachments/20111011/a2e6a807/attachment.html 

More information about the OWASP-Leaders mailing list