[Owasp-topten] Common numbering scheme/convention (formerly "top 10 & testing guide" thread)

Boberski, Michael [USA] boberski_michael at bah.com
Wed Jan 6 12:30:11 EST 2010


Ok, I see what you've done with the examples, thanks for forwarding those.

Let me review further and think this for a little bit, and I'll come up with a next proposal, based on these inputs. 

I think we can work this out without too much fuss over email and using the wikis. If anyone on these CC'd lists wants to jump in as we go, please feel free.
 
Mike B.

-----Original Message-----
From: Brad Causey [mailto:bradcausey at gmail.com] 
Sent: Wednesday, January 06, 2010 10:37 AM
To: Boberski, Michael [USA]; dinis cruz
Cc: Dave Wichers; owasp-testing at lists.owasp.org; owasp-topten at lists.owasp.org; owasp-application-security-verification-standard at lists.owasp.org; owasp-guide at lists.owasp.org
Subject: Re: Common numbering scheme/convention (formerly "top 10 & testing guide" thread)

Mike and Dave,

Great stuff!
Actually I think your first stab is a great starting point, and would provide a great cross mapping between documentation. We use these ID numbers for a number of purposes, but primarily in communication with vendors/developers. We require a simple way to communicate details of a vulnerability and also to summarize them. The testing guide ID numbers lend themselves well to this because they can be summarized, while still providing detail about the specific finding. For example, I can tell a vendor that we found 19 Data Validation issues, and then break it down into DV-001, DV-002, etc

Now, the testing guide numbering system isn't all gravy. =)

Some of the failures we have noticed is that there is little reference that these number provide to help developers resolve the issue.
Obviously, lots of these devs have never seen OWASP, nor WAS for that matter. Also, there are some finding types that are very verbose, such as the DV-001 and DV-002, whereas other types such as CM-003 and
CM-004 are massive catch-alls for us because of their vagueness. I think think  the process of syncing and mapping will identify and resolve these in itself.

Our organization's WAS effort isn't quite mature enough to fully utilize the ASVS yet, but having this as part of a central, standard Identification system for findings would make it that much easier to integrate it at a sooner date.

One of the items that Dinis mentioned at the DC summit was that he wanted OWASP to sponsor a group of crazies such as ourselves to fly to a neutral location for a weekend and hammer something out that would provide great value to the organization. Slap me if I'm wrong, but this sure seems like a massive return for OWASP should be do it correctly. Thoughts?

I've attached some sanitized reports to assist in my explanation. I don't expect to tailor any of this to me or my organization, but hopefully seeing how these projects are used in production can assist in some way.


-Brad
--



On Wed, Jan 6, 2010 at 9:03 AM, Boberski, Michael [USA] <boberski_michael at bah.com> wrote:
> (resend -- including dev guide group this time, let's keep all these 
> projects in the loop)
>
> Mike B.
>
> ________________________________
> From: Boberski, Michael [USA]
> Sent: Wednesday, January 06, 2010 10:01 AM
> To: 'Dave Wichers'; Brad Causey; owasp-testing at lists.owasp.org; 
> owasp-topten at lists.owasp.org
> Cc: 'owasp-application-security-verification-standard at lists.owasp.org'
> Subject: Common numbering scheme/convention (formerly "top 10 & 
> testing guide" thread)
>
> Hi Brad. I'm game for figuring out a common identifier 
> scheme/convention, ideally before the end of the month or so, which is 
> the current ETA to putting out a call for contributors to work on the 
> next rev of the dev guide, which as Dave mentioned will be reorganized according to ASVS.
>
> Maybe a first step is to take a look at this:
> http://code.google.com/p/owasp-development-guide/wiki/Introduction?tm=
> 6  I just replaced the ASVS' "A#" with "D#" but kept the title.  The 
> "D#" is a Mike-ism/first cut at a dev guide numbering scheme, so 100% 
> open to working with you on this, since obviously the thought crossed 
> my mind something had to be figured out. We're also in the early 
> stages of planning a next release of ASVS as Dave alludes to below as 
> well, so now's a good time to talk about this, i.e. we could 
> potentially also markup
> http://code.google.com/p/owasp-asvs/wiki/ASVS?tm=6  in a similar fashion.
>
> Based on your email below, I generally think we should have a 
> major/minor kinda scheme that starts with ASVS and goes to whatever:
>
> OWASP-V[1-14]-[1-n,A,D,T,other]-[1-m,A,D,T,other]
>
> i.e., as if one were expanding a tree control that when one got to a 
> detailed verification requirement, would then have children nodes for e.g.
> development guide, testing guide, perhaps threats that the 
> requirements map to like T10/CWE/WASC.
>
> Let me know your thoughts, the above is just a first proposal, I may 
> not be understanding what you need. We can use the above dev guide 
> wiki to flesh this out, see how much things make sense as we go, thing 
> look different from email/paper to clickable trees/widgets.
>
> Best,
>
> Mike B.
>
> ________________________________
> From: owasp-topten-bounces at lists.owasp.org
> [mailto:owasp-topten-bounces at lists.owasp.org] On Behalf Of Dave 
> Wichers
> Sent: Wednesday, January 06, 2010 12:34 AM
> To: Brad Causey; owasp-testing at lists.owasp.org; 
> owasp-topten at lists.owasp.org
> Cc: mike.boberski at gmail.com
> Subject: Re: [Owasp-topten] top 10 & testing guide
>
> Brad,
>
>
>
> OWASP is just starting a synchronization effort between the Top 10, 
> ASVS, and all the Guides. We are trying to use the ASVS requirements 
> as the baseline and then developing the dev guide and testing guide 
> and code review against that outline.  However, we don't want to wreck 
> what you guys have been doing with the testing guide #'s
>
>
>
> Mike Boberski is working with Andrew van der Stock to launch an update 
> effort to the Dev Guide. Can you work with Mike so he understands how 
> you are using the OWASP finding #'s to see if we can move forward in a 
> way that is not massively disruptive? Mike may not even be aware of 
> the testing guide numbering scheme.
>
>
>
> And we can also make sure that the dev guide covers everything you 
> think needs to be covered (which hopefully already is covered in 
> ASVS), and if not, maybe it needs to be updated too.
>
>
>
> -Dave
>
>
>
> From: owasp-topten-bounces at lists.owasp.org
> [mailto:owasp-topten-bounces at lists.owasp.org] On Behalf Of Brad Causey
> Sent: Tuesday, January 05, 2010 8:59 PM
> To: owasp-testing at lists.owasp.org; owasp-topten at lists.owasp.org
> Subject: [Owasp-topten] top 10 & testing guide
>
>
>
> First of all, sorry for the x-posting, but it seemed appropriate.
>
> For those of you that don't know, I work in the financial sector and 
> developed our organization's WAS testing procedures, documentation, 
> and probably 80% of our whole WAS program from OWASP materials. Great stuff.
>
> As matter of fact, each of our analysts has a LULU printed copy of the 
> testing guide on their desks. When we write reports up, we use the 
> OWASP-XX-XX as our classification mapping. For example:
>
> Finding 1 - rXSS - OWASP-DV-001 - hxxp://www.vulnsite.com?msg=<blah 
> blah, you get it> - screenshot1.png
>
> When we write our long form reports, we use the text from the testing guide.
> It has really proven great for us and we've been doing this since v2 
> came out. In addition, we have previously used the top ten literature 
> as supplementary in proving higher risk, higher priority items. That 
> has worked great until now.....
>
> A8 on the RC version of the Top Ten throws a nice shiny wrench into it all.
> Reason being, there isn't a corresponding OWASP-xx-xx classification 
> that matches up to A8. Now I've been writing A8 up for some time, but 
> it never had a nice-neat home in any of the Testing guide classifications.
>
> Now that I've gotten past all that. I'd like to maybe discuss how, 
> possibly in the future, the two projects could be somewhat more in 
> sync. I'm not sure there is a good way to do that today, but it sure 
> makes sense in my mind that all owaspy stuff have some overlap, and 
> should avoid gaps such as the
> A8 vs OWASP-XX-XX situation.
>
> Also I see some gaps here:
>
> http://2.bp.blogspot.com/_JdybrokZBAk/S0Nt5DVYHWI/AAAAAAAABvU/HXQSzzoR
> Ju0/s1600-h/WASC.png
>
> That aren't covered in any OWASP documentation, and should be. I'd 
> like to get everyones' thoughts, and probably flames, on this stuff.
>
>
>
> -Brad Causey
> CISSP, MCSE, C|EH, CIFI, CGSP
>
> http://www.owasp.org
> --
> Never underestimate the time, expense, and effort an opponent will 
> expend to break a code. (Robert Morris)
> --


More information about the Owasp-topten mailing list