RE: [was] Classification & MECE frameworks

["Dawes, Rogan (ZA - Johannesburg)" <rdawes@deloitte.co.za>]

Hi Andrew,

I think that would be very valuable. I've not been too happy in reporting
web application vulnerabilities according to the OWASP taxonomy, as I've
always thought that there are overlaps and inconsistencies.

A well-thought out classification scheme will be very useful.

Rogan

> -----Original Message-----
> From: Andrew Jaquith [mailto:ajaquith@atstake.com] 
> Sent: 16 July 2003 10:29 PM
> To: was@lists.oasis-open.org
> Subject: [was] Classification & MECE frameworks
> 
> 
> Mark et al --
> 
> Perhaps this is jumping the gun a bit, but I wanted to offer 
> a thought 
> on classification of app security issues.
> 
> With regard to classification of problem spaces generally, it 
> is common 
> practice in the management consulting world to define taxonomies that 
> are mutually exclusive and collectively exhastive (aka MECE 
> frameworks). 
> This is essentially a tree structure, in which the problem at hand is 
> succesively broken down into its component parts as the tree 
> gets 'deeper'.
> 
> MECE frameworks enable summary reporting and roll-ups, while 
> allowing ad 
> hoc deep-dives. A key tenet of MECE design is to ensure that 
> each level 
> does not contain excessive detail. This generally means that at most, 
> levels contain no more than 6-10 subtopics. The other point 
> to remember 
> is that topics can't overlap -- this is the 'ME' part.
> 
> In @stake's case, for app vulnerability classification we 
> started with 
> the OWASP Application Security Attack Components as a straw man MECE 
> framework. We then modified it a bit to give it a bit more 
> 'balance' and 
> topic completeness. We also simplified some of the jargon for the 
> higher-level topics so that executives could better 
> understand them. The 
> resulting MECE framework uses 9 high level categories and 56 
> lower-level 
> ones. In particular, the high-level web app sec categories we 
> used were:
> 
> - Administrative interfaces
> - Authentication & access control
> - Configuration management
> - Cryptography
> - Information gathering
> - Input validation
> - Parameter manipulation
> - Sensitive data handling
> - Session management
> 
> I'd be happy to contribute the framework to the group if folks would 
> find it helpful.
> 
> Best,
> 
> -- 
> Andrew Jaquith
> Program Director
> @stake, Inc.
> 196 Broadway
> Cambridge, MA 02139
> USA
> 
> Direct:  617.768.2711
> Mobile:  617.501.3278
> Fax:     617.621.1478
> Email:   ajaquith@atstake.com
> PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x898CF546
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: was-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: was-help@lists.oasis-open.org
> 

Important Notice: This email is subject to important restrictions, qualifications and disclaimers ("the Disclaimer") that must be accessed and read by clicking here or by copying and pasting the following address into your Internet browser's address bar: http://www.Deloitte.co.za/Disc.htm. The Disclaimer is deemed to form part of the content of this email in terms of Section 11 of the Electronic Communications and Transactions Act, 25 of 2002. If you cannot access the Disclaimer, please obtain a copy thereof from us by sending an email to ClientServiceCentre@Deloitte.co.za.