[Owasp-topten] Structure Of Management Document

Sandeep Godbole sandeep_godbole at yahoo.com
Thu Mar 19 04:49:54 EDT 2009


The individual page for each of the vulnerability in the management document could be structured in the following manner:

a) What is the vulnerability ( a brief description)
b) What causes this vulnerability ( eg weak session management)
c) What is the target (  eg authentication, data base )
d) How is generally it's mitigation.

-Sandeep Godbole




________________________________
From: "owasp-topten-request at lists.owasp.org" <owasp-topten-request at lists.owasp.org>
To: owasp-topten at lists.owasp.org
Sent: Thursday, March 19, 2009 12:15:12 AM
Subject: Owasp-topten Digest, Vol 18, Issue 4

Send Owasp-topten mailing list submissions to
    owasp-topten at lists.owasp.org

To subscribe or unsubscribe via the World Wide Web, visit
    https://lists.owasp.org/mailman/listinfo/owasp-topten
or, via email, send a message with subject or body 'help' to
    owasp-topten-request at lists.owasp.org

You can reach the person managing the list at
    owasp-topten-owner at lists.owasp.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Owasp-topten digest..."


Today's Topics:

  1. Thoughts on OWASP Top 10 2009 - Round 1 (Dave Wichers)
  2. Re: Thoughts on OWASP Top 10 2009 - Round 1 (Ralph Durkee)
  3. Re: Thoughts on OWASP Top 10 2009 - Round 1 (Dave Wichers)


----------------------------------------------------------------------

Message: 1
Date: Wed, 18 Mar 2009 14:00:59 -0400
From: "Dave Wichers" <dave.wichers at aspectsecurity.com>
Subject: [Owasp-topten] Thoughts on OWASP Top 10 2009 - Round 1
To: <owasp-topten at lists.owasp.org>
Message-ID:
    <B9A412898630124ABE8350F4EBD32E84E72C8A at mymail.aspectsecurity.com>
Content-Type: text/plain; charset="us-ascii"

I finally have gotten a chance to start thinking about the organization
and structure of the Top 10 update for 2009 and I wanted to share some
thoughts. So, I have two high level questions/suggestions for you:



1)      Top 10 of what? The 2007 version was mostly the top 10 most
likely to exist vulnerabilities. Previous versions weren't as focused on
that but still indicated it was a list of the Top 10 vulnerabilities.



For this version, I think it should be the Top 10 biggest security risks
to web applications.



This means that we should consider a number of factors when calculating
the risk. OWASP has a risk rating model that I think we should use as a
guide for this
(http://www.owasp.org/index.php/How_to_value_the_real_risk). However,
this model includes a number of factors that are very specific to the
organization evaluating the risk, the threats that organization faces,
and specifics of the actual vulnerability being assessed.



I'm not proposing we include and consider all 16 factors from this
model. But I do think we should consider the following:



a)      Likelihood of existence of vulnerability (What was the primary
factor previously).

b)      Ease of discovery

c)      Ease of exploit (OWASP Term)/attack frequency (Used by MITRE
Top 25 programming flaws) (Do these correlate or are they fundamentally
different?)

d)      Impact (Both Technical and Business)



The MITRE Top 25 doc also includes Awareness of that type of
vulnerability as a factor but I'm thinking if it's in the Top 10,
everyone is aware of it now, so it's generally not worth
including/considering, but I could be talked out of this. I recognize
that this is not always true. CSRF wasn't very well known when we
released it into the Top 10 in 2007, but it's certainly much more well
known now.



2)      Structure of document - This goes to the audience of the
document.



I think the Top 10 items and their brief descriptions is more of a
management document, than a developer doc. However, the existing doc has
lots of details for developers making it less useful as a management
document, but not enough detail to be really useful for developers
either. Jeff Williams has a suggestion that I like:



a)      Lets produce a 'small' Top 10 this year, like max 15-20 pp,
where there are a few pages of intro, 1 page for each item in the Top
10, and a couple concluding pages. This would be primarily an awareness
doc for management and developers.

b)      We should then either produce a larger technical report that
provides the technical meat for the developers, or simply link to 10
articles at OWASP on each of the top 10 items that provide the technical
meant. This would be more detail than what we have in there now.

a.      I think we should do both of these actually. I suggest we write
the 10 articles at OWASP, and then once they are done and the Top 10 for
2009 itself is done, then we can pull all this into a single document.

c)      Both of these docs would be made available as PDFs.



In a later discussion I want to talk about what should be included in
each writeup for each Top 10 item, both the short and long versions.



And also a discussion of the sources of known vulnerabilities we should
look at to help identify the likelihood of existing factor across more
than just the MITRE CVE Repository.



-Dave





-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/owasp-topten/attachments/20090318/1b09461a/attachment-0001.html 

------------------------------

Message: 2
Date: Wed, 18 Mar 2009 14:23:00 -0400 (EDT)
From: "Ralph Durkee" <rd at rd1.net>
Subject: Re: [Owasp-topten] Thoughts on OWASP Top 10 2009 - Round 1
To: "Dave Wichers" <dave.wichers at aspectsecurity.com>
Cc: owasp-topten at lists.owasp.org
Message-ID: <55542.13.13.137.1.1237400580.squirrel at ssl.durkee.us>
Content-Type: text/plain;charset=iso-8859-1

Sounds like a good approach. one small nit, on the impact it would seem we
could discuss much of the technical impact, but I can't think of any
business impact that would be independent of the business. ;->

I really like the idea of having a smaller document and referencing the
OWASP web site for details for the developers.

-- Ralph Durkee


> I finally have gotten a chance to start thinking about the organization
> and structure of the Top 10 update for 2009 and I wanted to share some
> thoughts. So, I have two high level questions/suggestions for you:
>
>
>
> 1)      Top 10 of what? The 2007 version was mostly the top 10 most
> likely to exist vulnerabilities. Previous versions weren't as focused on
> that but still indicated it was a list of the Top 10 vulnerabilities.
>
>
>
> For this version, I think it should be the Top 10 biggest security risks
> to web applications.
>
>
>
> This means that we should consider a number of factors when calculating
> the risk. OWASP has a risk rating model that I think we should use as a
> guide for this
> (http://www.owasp.org/index.php/How_to_value_the_real_risk). However,
> this model includes a number of factors that are very specific to the
> organization evaluating the risk, the threats that organization faces,
> and specifics of the actual vulnerability being assessed.
>
>
>
> I'm not proposing we include and consider all 16 factors from this
> model. But I do think we should consider the following:
>
>
>
> a)      Likelihood of existence of vulnerability (What was the primary
> factor previously).
>
> b)      Ease of discovery
>
> c)      Ease of exploit (OWASP Term)/attack frequency (Used by MITRE
> Top 25 programming flaws) (Do these correlate or are they fundamentally
> different?)
>
> d)      Impact (Both Technical and Business)
>
>
>
> The MITRE Top 25 doc also includes Awareness of that type of
> vulnerability as a factor but I'm thinking if it's in the Top 10,
> everyone is aware of it now, so it's generally not worth
> including/considering, but I could be talked out of this. I recognize
> that this is not always true. CSRF wasn't very well known when we
> released it into the Top 10 in 2007, but it's certainly much more well
> known now.
>
>
>
> 2)      Structure of document - This goes to the audience of the
> document.
>
>
>
> I think the Top 10 items and their brief descriptions is more of a
> management document, than a developer doc. However, the existing doc has
> lots of details for developers making it less useful as a management
> document, but not enough detail to be really useful for developers
> either. Jeff Williams has a suggestion that I like:
>
>
>
> a)      Lets produce a 'small' Top 10 this year, like max 15-20 pp,
> where there are a few pages of intro, 1 page for each item in the Top
> 10, and a couple concluding pages. This would be primarily an awareness
> doc for management and developers.
>
> b)      We should then either produce a larger technical report that
> provides the technical meat for the developers, or simply link to 10
> articles at OWASP on each of the top 10 items that provide the technical
> meant. This would be more detail than what we have in there now.
>
> a.      I think we should do both of these actually. I suggest we write
> the 10 articles at OWASP, and then once they are done and the Top 10 for
> 2009 itself is done, then we can pull all this into a single document.
>
> c)      Both of these docs would be made available as PDFs.
>
>
>
> In a later discussion I want to talk about what should be included in
> each writeup for each Top 10 item, both the short and long versions.
>
>
>
> And also a discussion of the sources of known vulnerabilities we should
> look at to help identify the likelihood of existing factor across more
> than just the MITRE CVE Repository.
>
>
>
> -Dave
>
>
>
>
>
> _______________________________________________
> Owasp-topten mailing list
> Owasp-topten at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-topten
>




------------------------------

Message: 3
Date: Wed, 18 Mar 2009 14:50:05 -0400
From: "Dave Wichers" <dave.wichers at aspectsecurity.com>
Subject: Re: [Owasp-topten] Thoughts on OWASP Top 10 2009 - Round 1
To: "Ralph Durkee" <rd at rd1.net>
Cc: owasp-topten at lists.owasp.org
Message-ID:
    <B9A412898630124ABE8350F4EBD32E84E72CA9 at mymail.aspectsecurity.com>
Content-Type: text/plain;    charset="us-ascii"

I agree in general. I think we can discuss potential business impacts in
the document, because that's interesting to know and discuss, but
couldn't really factor that in much when weighing business impact as
part of deciding what order to place the top 10 items in.

I think we probably want to include and discuss other items like
Remediation Cost (Low, Med, High) that is a factor when people look at
what to deal with in what order, but Remediation Cost doesn't affect the
relative risk of the vulnerability itself, but that's a different topic
that I wanted to bring up later.

-Dave

-----Original Message-----
From: Ralph Durkee [mailto:rd at rd1.net] 
Sent: Wednesday, March 18, 2009 2:23 PM
To: Dave Wichers
Cc: owasp-topten at lists.owasp.org
Subject: Re: [Owasp-topten] Thoughts on OWASP Top 10 2009 - Round 1

Sounds like a good approach. one small nit, on the impact it would seem
we
could discuss much of the technical impact, but I can't think of any
business impact that would be independent of the business. ;->

I really like the idea of having a smaller document and referencing the
OWASP web site for details for the developers.

-- Ralph Durkee


> I finally have gotten a chance to start thinking about the
organization
> and structure of the Top 10 update for 2009 and I wanted to share some
> thoughts. So, I have two high level questions/suggestions for you:
>
>
>
> 1)      Top 10 of what? The 2007 version was mostly the top 10 most
> likely to exist vulnerabilities. Previous versions weren't as focused
on
> that but still indicated it was a list of the Top 10 vulnerabilities.
>
>
>
> For this version, I think it should be the Top 10 biggest security
risks
> to web applications.
>
>
>
> This means that we should consider a number of factors when
calculating
> the risk. OWASP has a risk rating model that I think we should use as
a
> guide for this
> (http://www.owasp.org/index.php/How_to_value_the_real_risk). However,
> this model includes a number of factors that are very specific to the
> organization evaluating the risk, the threats that organization faces,
> and specifics of the actual vulnerability being assessed.
>
>
>
> I'm not proposing we include and consider all 16 factors from this
> model. But I do think we should consider the following:
>
>
>
> a)      Likelihood of existence of vulnerability (What was the primary
> factor previously).
>
> b)      Ease of discovery
>
> c)      Ease of exploit (OWASP Term)/attack frequency (Used by MITRE
> Top 25 programming flaws) (Do these correlate or are they
fundamentally
> different?)
>
> d)      Impact (Both Technical and Business)
>
>
>
> The MITRE Top 25 doc also includes Awareness of that type of
> vulnerability as a factor but I'm thinking if it's in the Top 10,
> everyone is aware of it now, so it's generally not worth
> including/considering, but I could be talked out of this. I recognize
> that this is not always true. CSRF wasn't very well known when we
> released it into the Top 10 in 2007, but it's certainly much more well
> known now.
>
>
>
> 2)      Structure of document - This goes to the audience of the
> document.
>
>
>
> I think the Top 10 items and their brief descriptions is more of a
> management document, than a developer doc. However, the existing doc
has
> lots of details for developers making it less useful as a management
> document, but not enough detail to be really useful for developers
> either. Jeff Williams has a suggestion that I like:
>
>
>
> a)      Lets produce a 'small' Top 10 this year, like max 15-20 pp,
> where there are a few pages of intro, 1 page for each item in the Top
> 10, and a couple concluding pages. This would be primarily an
awareness
> doc for management and developers.
>
> b)      We should then either produce a larger technical report that
> provides the technical meat for the developers, or simply link to 10
> articles at OWASP on each of the top 10 items that provide the
technical
> meant. This would be more detail than what we have in there now.
>
> a.      I think we should do both of these actually. I suggest we
write
> the 10 articles at OWASP, and then once they are done and the Top 10
for
> 2009 itself is done, then we can pull all this into a single document.
>
> c)      Both of these docs would be made available as PDFs.
>
>
>
> In a later discussion I want to talk about what should be included in
> each writeup for each Top 10 item, both the short and long versions.
>
>
>
> And also a discussion of the sources of known vulnerabilities we
should
> look at to help identify the likelihood of existing factor across more
> than just the MITRE CVE Repository.
>
>
>
> -Dave
>
>
>
>
>
> _______________________________________________
> Owasp-topten mailing list
> Owasp-topten at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-topten
>




------------------------------

_______________________________________________
Owasp-topten mailing list
Owasp-topten at lists.owasp.org
https://lists.owasp.org/mailman/listinfo/owasp-topten


End of Owasp-topten Digest, Vol 18, Issue 4
*******************************************



      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/owasp-topten/attachments/20090319/a5748594/attachment-0001.html 


More information about the Owasp-topten mailing list