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

Dinis Cruz dinis at ddplus.net
Mon Nov 6 08:15:18 UTC 2006


I like T12  or T11 since that is a 'branding' difference from the Top 10 :)

Dinis

On 11/5/06, Jeff Williams <jeff.williams at owasp.org> wrote:
>
>  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* < 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:* jeff.williams at owasp .org <jeff.williams at 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
>
>
>
> _______________________________________________
> Owasp-board mailing list
> Owasp-board at lists.owasp.org
> http://lists.owasp.org/mailman/listinfo/owasp-board
>
>
>


-- 
Best regards

Dinis Cruz
OWASP Autumn of Code 2006, http://www.owasp.org/index.php/OAC
OWASP .Net Project, http://www.owasp.org/index.php/.Net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/owasp-board/attachments/20061106/aa48dd5e/attachment-0002.html>


More information about the Owasp-board mailing list