[Owasp-board] On the Top 10 and what it should be

Jeff Williams jeff.williams at owasp.org
Sun Nov 5 15:40:23 UTC 2006


Let's work on it together.

 

We're going to have to hurry if we want to get something out with the T10
AppSec Vulnerabilities.

 

I think limiting to 10 challenges would be a good idea.  We can include a
list of the ones that didn't make the list too.

 

I have time tomorrow to write.

 

--Jeff

 

  _____  

From: Dinis Cruz [mailto:dinis at ddplus.net] 
Sent: Saturday, November 04, 2006 6:11 AM
To: jeff.williams at owasp.org
Cc: Dave Wichers; Andrew van der Stock
Subject: Re: On the Top 10 and what it should be

 

Great stuff Jeff,

So why don't we compromize (for this edition): 

 - Owasp Top 10 Vulnerabilities 2007
 - Owasp Top 12 AppSec Challenges 2007 

I am happy to take the lead on the T12 and point for a joint release with
T10

Dinis

On 10/26/06, Jeff Williams < <mailto:jeff.williams at owasp.org>
jeff.williams at owasp.org> wrote:

This is really interesting - as usual Dinis is thinking a few moves ahead.

 

We really should have a document that identifies the FUTURE things people
need to be thinking and doing.  I think you're right that was the idea in
2002 when we wrote the initial T10.  I suggest we do the following 3 things.

 

1) The T10 should stay focused on vulnerabilities, and not expand into SDLC,
etc....  The direction of the Top Ten project is to emphasize EXISTING
vulnerabilities, based on the Mitre results.  There is a real need for this
level of justification of the T10, as so much has been built on top of it.
I believe that a radical change to the T10 would be foolish for OWASP, as
we'll lose a lot of folks who have invested in that document.

 

2) We should add 2 or 3 items to the end of the T10 and clearly state that
they are not supported by the data, but we believe that these are becoming
quite important.  This could include CSRF, new types of injection (XML,
XPath, XQuery), DOM based XSS, Worms).  Phishing is a bit weird, as it's
really an attack that takes advantage of a number of different
vulnerabilities, so I think we should mention it where appropriate.

 

3) We should also create a "T10 AppSec Challenges" document that looks
beyond just vulnerabilities and focuses on what organizations need to DO.  A
forward looking document is extremely important, especially as people get
their hands around simple problems like XSS and SQL injection. Here are what
I see as the key challenges for folks in the next few years (in no
particular order).

 

1) Establish Intrusion Detection - It's an incredibly rare application that
identifies attacks and handles them appropriately.  I would discuss error
handling and logging concerns under this.

 

2) Manage Trust Relationships - Getting web services to talk to each other
is simple. Figuring out who should be able to talk about what is real real
hard.

 

3) Handle Rich Client Security - Environments like GWT make the
client-server boundary invisible to developers, but it's critical for
security. Ajax, applets, flash all have some new challenges

 

4) Perform Threat Modeling - I think pushing the entire SDLC is too vague.
But threat modeling is a nice way to get a handle on the security
requirements and will encourage architecture review and testing as well.

 

5) Establish AppSec Team - The only successful organizational model I've
seen is to form an application security team that does app reviews, helps
with standards, supports projects, and works on enterprise security
mechanisms

 

6) Standardize Access Control - Getting a handle on access control at
multiple layers (business logic, data layer, presentation layer, backend) is
way beyond most organizations.  Many books and papers on this topic
completely suck.

 

7) Assure Data Protection - Still a serious challenge to verify that
sensitive data is properly protected throughout an enterprise's
applications.

 

8) Build Education Program - Mike Howard calls this out as the first and
most effective step. Clearly a critical piece.  But it's difficult to roll
out an enterprise wide education program.

 

9) Create Enterprise Security API - Companies need to establish a common way
to do certain security things, like authentication, access control, input
validation, encoding, encryption, logging, etc.  Building this library takes
time and focus.

 

10) Integrate AppSec Tools - Running a scanner or static analysis tool is
one thing, tailoring it, integrating it into the process, and handling
findings is another.

 

11) Create AppSec Metrics - You can't improve what you can't measure.
Organizations need to establish some metrics to know how they're doing.
Either directly measuring the software or indirect measures of people,
process, and supporting technology.

 

Yeah, that's 11 I know.  ;-)  But we can haggle this out on the website and
lists (transparently and openly)!  There are other areas, like strong
authentication, etc.

 

--Jeff

 

  _____  

From: Dinis Cruz [mailto:dinis at ddplus.net] 
Sent: Wednesday, October 25, 2006 6:59 PM
To: [email protected] <mailto:jeff.williams at owasp.org> owasp .org
Cc: Dave Wichers; Andrew van der Stock
Subject: On the Top 10 and what it should be

 

Ok, here are some ideas and thoughts

After the last conference in Seattle, me Dave and xyz (can remember his
name) sat down for a couple drinks and started talking about the top 10. 

I started to throw some ideas to the table and after much debate (note that
Dave was not 100% happy with all the ideas bellow) I arrived in the
following ideas/concepts. 

1. The Owasp top 10 should be a 'positioning document' i.e. 'setting the
agenda' - The value of listing the most common vulnerabilities that have
been exploited in the last 12 months is very limited, the value of saying '
HERE are the issues that we believe Web Apps should be addressing today, so
that they are resilient to attack in the next 12/24/36 months' IS very
valuable. 

1.a) The Owasp Top 10 should be a visionary document, one pointing to the
future and not the past. 

1.b) I would argue that the first Owasp Top 10 was exactly that: A visionary
document that in 2004 alerted for the issues that we are still dealing in
2006. It set the agenda of the discussion (as in 'Are you aware of this?' ,
'are you able to handle them?') and it positioned Owasp in the center of the
Web App World 

2. With the above in mind, I would call the new version simply: 'the OWASP
Top 10' since my proposed list contains more than vulnerabilities (I also
like the branding simplicity of just saying 'the OWASP Top 10' :)

3. Based on the discussion we had that night, here is my proposed Owasp Top
10: 

 A1) Unvalidatated Data - Section containing issues like: XSS, SQL
Injections, Buffer Overflows,  (which contrary to what most believe will
still be very relevant in Web Apps), directory transversal, etc... Here is
where (in my opinion) it would make all sense to look at the last 12 months
and list the most common issues.Note: We should talk about 'Data' (as in
'Unvalidated Data') not not in 'Input' (as in 'Unvalidated Input')

 A2) Session Management and Authorization

 A3) Authentication and Access Control

 A4) Business Logic Exploitation - this is when the attacker makes perfectly
valid requests which exploit a lack of checks in the application business
logic (I think that this is is very, very, very important since this is
where the new wave of attacks are going to go). Depending on the website
funcionality, these issues can be as dangerous as SQL Injections 

 A5) Exception Management and Race Conditions

 A6) Denial of Services

 A7) Wormable conditions - this issue was very debated because it is not a
normal 'vulnerability' but a situation that occurs in 'perfect storm'
scenarios, for example an XSS that exploits a business Logic flaw. But
before you say no, think of the MySpace worm! That was clearly an issue that
affects web applications, and one that will become more and more a problem
in the future 

 A8) Phishing and User Assets compromise - This one is all about how the
user is affected by web based vulnerabilities or insecure   architectures
(for example the current javascript DOM). At the end of the day what matters
are the Assets ( i.e. what has value) and if the user's assets are being
compromized via Web Applications, then that warrants a Top 10 inclusion :)

A9) Host and Client Integrity - This is all about the fact that either a
server or a client compromised computer could disable all other security
measures implemented in the targeted web application 

 A10) Secure Development LifeCicle (SDLC), I think that by now we are all
converted to the idea of the SDLC (which clearly makes a difference in the
security and quality of the built applications). We should make it official
and add it as an entry to the Top 10 

So what do you think?

I like this Top 10 because it looks forward and because it will help the
organizations to be aware of the issues they need to address in the web
world of 2007 (which is very different from the one in 2004)

Dinis

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/owasp-board/attachments/20061105/5371cf85/attachment-0002.html>


More information about the Owasp-board mailing list