[Owasp-topten] Re: OWASP Top Ten - My Case For Updating It

[Jeff Williams]

Absolutely.  It's high time that we put together a real standard for web 
application security.  As Mark points out, the Top Ten really doesn't serve 
purposes beyond awareness very well.  The first thing is to identify a 
project leader and some key contributors.  I hope that Mark will consider 
leading the effort.  I suggest we take the discussion to the 
owasp-topten at lists.sourceforge.net mailing list.  You can sign up at 
http://lists.sourceforge.net/lists/listinfo/owasp-topten.

--Jeff

----- Original Message ----- 
From: "Mark Curphey" <mark at curphey.com>
To: <webappsec at securityfocus.com>
Cc: "'Jeff Williams'" <jeff.williams at owasp.org>
Sent: Saturday, July 09, 2005 4:42 PM
Subject: OWASP Top Ten - My Case For Updating It


>I think the OWASP Top Ten needs a serious re-think. Here is my simple case
> for discussion / consideration.
>
> No one will dispute the fact that the Top Ten has been a phenomenal 
> success.
> It has raised awareness and brought web application security to the desks 
> of
> CIO's across the world. It has touched the payment card industry, Federal
> Trade Commission and the US gov to name a few. But it has also been and is
> continuing to be adopted (and abused) for purposes that were far beyond 
> its
> original intent. These uses and  misuse that are not "fit for purpose" are
> in my opinion leading to a significant degree of FUD, false sense of
> security and mis-information in the market. I therefore propose through 
> this
> mail a re-write to ensure that the OWASP Top Ten is an effective and 
> useful
> standard.
>
> I break this proposal down into a discussion of the;
>
> current format of the top ten
> current uses of the top ten
> issues as the result of the format and uses of the top ten
> proposal for improvement
>
> Current format of the top ten
>
> Todays OWASP Top 10 consists of;
>
> Unvalidated Input
> Broken Access Control
> Broken Authentication and Session Management
> Cross Site Scripting (XSS) Flaws
> Buffer Overflows
> Injection Flaws
> Improper Error Handling
> Insecure Storage
> Denial of Service
> Insecure Configuration Management
>
> If you examine the overall picture you will see that the list is actually 
> a
> mix of 1, Security Mechanisms, 2, Attack Patterns and 3, Vulnerabilities.
>
> Security Mechanisms
> -Broken Access Control
> -Broken Authentication and Session Management
> -Insecure Configuration Management
> -Improper Error Handling
> -Insecure Storage
>
> Attack Patterns
> -Injection Flaws
> -Denial of Service
>
> Vulnerabilities
> -Cross Site Scripting (XSS) Flaws
> -Buffer Overflows
>
> Current Uses of the Top Ten
> As well as awareness, the popularity of the OWASP Top Ten has lead to 
> people
> adopting it as a;
>
> -Criteria for evaluating technology (web app scanners, firewalls)
> -Metrics and comparison for software security programs
> -Education outline
> -Assessment framework
>
> Issues as the result of the format and uses of the top ten
> The OWASP Top ten is an awareness document but in my humble opinion not
> suitable for any of the current uses for the top ten listed above. As we
> have already seen by the FUD from many vendors especially web application
> firewall vendors, to say you protect from broken authentication is a
> meaningless statement. To say you find broken authorization issues is also 
> a
> meaningless statement from an assessment vendor. As formal evaluation
> criteria has long known you have to define a protection or assessment
> profile. The OWASP Top Ten is not a protection or an assessment profile. A
> vendor could accurately say that they find Insecure storage if they parsed
> data stream and found a clear-text account value in a cookie header. 
> However
> they would have likely missed a web application whose developer used a
> predictable random seed for a low key length symmetric cipher. This leads 
> to
> a significant sense of false security and hyped marketing FUD.
>
> In order to develop any useable metrics or comparison programs you must be
> comparing apples to apples and oranges to oranges. If you mix attack
> patterns, security mechanisms and attacks you can not.
>
> While teaching developers about a small pragmatic list of issues is 
> clearly
> a good thing, many companies are missing big issues by focusing on a 
> subset
> of the symptoms of software security and the not the causes. In order to
> provide pragmatic and effective education you have to teach developers how
> to address the root causes of issues to prevent them from re-occurring.
>
> Many companies are looking to test sites against the top ten. I recently
> looked at a site that passed the OWASP Top Ten but was 100% open to an
> adversary to completely take it over. While statements explain that this 
> is
> not a complete list are in place, without a testing criteria uneducated or
> novice companies will use the Top Ten as a testing yard stick. The PCI
> adoption is a dangerous issue that demonstrates this point. When 
> MasterCard
> were hacked the first thing the company did was to say they passed the PCI
> tests. This will be the case with the OWASP Top Ten.
>
> If the problem of web application security is poor software quality, it is 
> a
> natural conclusion that the solution is to build better software. Not once
> in the top ten does the list address the fact that the majority of 
> software
> is built without a design, security requirements or a repeatable software
> security development process.
>
> Proposal for improvement
>
> Create a set of T10's that are fit for purpose;
>
> T10 - Attack Patterns
> T10 - Common Vulnerabilities
> T10 - Root Causes of Insecure Web Applications
> T10 - Things a company should have as part of its software security 
> program
> T10 - Things to look for in a protection system
> T10 - Things to look for in an assessment system
>
> The FUD in the application security marketing is continuing to increase at
> an alarming rate and measures like this in my humble opinion are urgently
> needed to recover some credibility and prevent a pandemic.
>
> Cheers,
>
>
>
> Mark
>
>