[WEB SECURITY] WASC Threat Classification vs. OWASP ASVS]

robert at webappsec.org robert at webappsec.org
Thu Jul 16 14:29:15 EDT 2009


> It is good to see that we have brought all three major documents into
> discussion (WASC-TCv2, ASVS and OWASP-TGv3). This is no criticism to
> WASC-TCv2, but I can really understand the real purpose of ASVS and
> TGv3 and know exactly how to use them. But I fail to understand the
> real purpose of TCv2, while TCv1 made much more sense by classifying
> threats in different categories 

I was waiting for someone to bring this up/ask a question about it but was 
expecting it around the time the tcv2 was completed (it is still in a working 
state). Prepare for a lengthy answer :) 


The TCv1 had a few problems as outlined below.


Problem #1: Parent to child mappings
Parent to child mappings where not clearly defined resulting in further 
confusion/ambiguity when we tried adding addition items (additional comments
at http://projects.webappsec.org/Challenges). 

Examples: 
- SQL Injection parent is 'command execution'. This implies sql injection is a form of command execution
- XSS is under client-side. This implies XSS affects/impacts the client/is a client side threat/attack.
- Session Fixation is under Authorization. This implies the child (session fixation) impacts the authorization 
  of the application.

As you can see this isn't very consistent or clearly defined. Our options where changing it prior to tcv2
going live, or continue to build on a confusing structure that would eventually need to change. We decided
to take the 'hit' in changing it in 2.0 rather than continue with our sins :) (more info below on structure),


Problem #2: The single tree structure
Assuming #1 was addressed we still would have situations where a child could fall under multiple parents, or
under sub parents (we experimented with this too). Would CSRF be listed under 'client side' since it impacts 
the user/client side, or somewhere else since it is a server side vuln? Suddenly we started to have a flurry 
of questions such as

- Should the TC outline who/what was affected or where the problem lies?  
- Should we have a tree structure where an item shows up multiple times?
- Should we have a dominant parent for an item and ignore the other possible locations/cross references?

In order to make sense of these questions we found ourselves testing multiple classic tree structure concepts 
and things started to blur very quickly due to an individual item ONLY being under 1 parent. 


Problem #3: Who was our audience and should we expand this scope?

After taking over the tc project I started asking people how they used it, and we pretty much had 4 use cases.
A. As a checklist of issues to test for (30%+)
B. As a reference for developers/folks to read more info on a given issue (55%+)
C. In academia to teach web security concepts (10%)
D. In bug tracking systems to gather metrics on vulnerability types. (5%)

We found that speaking with people that A,B,D users didn't really care about a single tree structure and cared
more about the individual items/content within them. C on the otherhand found the structure to be extremely
important (understandably) in order to teach relationships. By addressing #1 and #2 and selecting a single 
structure we'd be locked into one concept limiting ways this information could be used. 

After extensive discussions (for 3-4 months in a hundred+ emails, and several phone calls) we found ourselves 
at a crossroad where we had to change it in a way that would create a firm, non changeable foundation we could
extend and not reduce the scope. We decided that we'd instead create a base view of indexes (attacks and weaknesses
in tcv2), and that we'd create 'views' or ways to represent that data in future releases. This allowed us
to solve the challenges of #1 and #2, as well as expand the scope beyond the 4 use cases in #3. 

> TCv2 appears to to have lost its purpose by listing
> different attacks and weaknesses without actually classifying them as
> such 

We are classifying the threats (http://projects.webappsec.org/TC-Glossary) 
that face a into attacks and weaknesses indexes, and within each item 
cross referencing when applicable. My above rants address the rest of this. 

Regards,
- Robert Auger
http://www.webappsec.org/
http://www.cgisecurity.com/
http://www.qasec.com/

----------------------------------------------------------------------------
Join us on IRC: irc.freenode.net #webappsec

Have a question? Search The Web Security Mailing List Archives: 
http://www.webappsec.org/lists/websecurity/archive/

Subscribe via RSS: 
http://www.webappsec.org/rss/websecurity.rss [RSS Feed]

Join WASC on LinkedIn
http://www.linkedin.com/e/gis/83336/4B20E4374DBA



More information about the websecurity mailing list