[WEB SECURITY] WASC Threat Classification vs. OWASP ASVS

robert at webappsec.org robert at webappsec.org
Wed Jul 15 14:27:42 EDT 2009


> My question here is bit off the topic under discussion. As I was reading
> this thread, I browsed to the web page for this project. The table on the
> web page has two columns, one for Attacks and one for Weaknesses. Also at
> the top of the page, the description goes like this:<br><br>
> "The Threat Classification is an effort to classify the weaknesses,
> and attacks that can lead to the compromise of a website, its data, or
> its users."<br><br>
> The web page does not have any definition for a weakness and an attack. I

On the bottom side of the attack column we have this listed at
http://projects.webappsec.org/TC-Glossary

I need to work on the look/feel of the wiki page to better convey this. One
of the reasons we're marking this page as 'working' :).

> while I would think that these two terms are related to each other, where
> a weakness in the web application would lead to an attack. If what I am
> saying is correct, then we should have one column for weaknesses and
> another column for attacks and there should be a mapping which lists
> which weakness would result in which attacks e.g. a server
> misconfiguration may lead to Path traversal or DoS attacks, insufficient
> data validation may lead to injection attacks and insufficient
> authorization may lead to privilege escalation attacks. This mapping
> would tell web developers that securing an application against a weakness
> would protect the web site against all those attacks that may occur as a

Actually we had some very intense debates around cross referencing, 
attacks/weaknesses/vulnerabilities, and it is surprisingly a very complicated 
/context specific subject! :)

The original TCv1 had a tree structure and prevented us from moving forward
due to the limitation of bucketing things into single categories and the lack 
of cross referencing. We spents months debating/reinventing the tcv2 structure 
and found that different consumers had different equirements for how they used 
the document. Instead we opted for indexes of attacks and weaknesses (future versions 
are ?likely to have impact and mitigations indexes?) and decided that introducing 'views'
(different ways to represent the same data for different purposes) in future 
versions was a better approach. his also ddoesn't limit the tc's scope, and how 
it may be used. In your example above this would be considered a possible tc view.
We do however cross reference other applicable attacks and weaknesses in individual
tc sections when applicable, although a more extensive effort will be needed in a future
tc release to enhance this. 
 
Regards,
- Robert Auger


> result of that weakness.<br><br>
> I might have missed something here, but any comments are
> welcome.<br><br>
> Vishal<br><br>
> <br><br>
> At 17:23 13/07/2009 -0700, Arian J. Evans wrote:<br>
> <blockquote type=3Dcite class=3Dcite cite=3D"">The guy asked "which do =
> you
> use for a blackbox test?" I said WASC/TC because WASC/TC is
> blackbox.<br><br>
> "XSS" and "SQLi" are blackbox tests. You review code
> for errors of commission, largely. If you look in source you are
> typically looking for document.write and/or no escaping or lack of output
> encoding.  Verifying an exploitable runtime condition is a blackbox
> test by definition.<br><br>
> OWASP ASVS is largely oriented around verification process and leverages
> whitebox concepts and terms quite heavily.<br><br>
> Not a a bad thing at all.<br><br>
> So it is obvious that WASC/TC is the blackbox answer, and you could wrap
> up in an an ASVS process and simply replace their verification terms with
> ones more appropriate for blackbox, thus removing the OWASP whitebox and
> ESAPI bias in ASVS.<br>
> <br>
> Just trying to stay On Topic. <br><br>
> <br>
> -- <br>
> Arian Evans<br><br>
> <br><br>
> <br>
> On Mon, Jul 13, 2009 at 12:16 PM, Jim Manico
> <<a href=3D"mailto:jim at manico.net">jim at manico.net</a>> wrote:<br>
> 
> <dl>
> <dd>I'm a huge fan of OWASP ASVS because it leads us out of the
> neverending rat race of finding and fixing flaws. It focuses only on
> critical software controls needed to build a "secure"
> application. I tried adding in a few best practices that were rejected
> because they only wish to include =95necessary=95 controls, a good thing, I
> think.<br><br>
> 
> <dd>I approach AppSec from a defensive coder perspecive; I just want to
> know what features to add to my software. ASVS helps me measure my
> software in that regard very well.<br><br>
> 
> <dd>To put it a other way, if I focus on vulnerablity assessment, I know
> what vulns I have and can fix those. Reminds me of blacklisting.<br><br>
> 
> <dd>If I focus on controls (ASVS + ESAPI) I tend to be able to build an
> app that can stand the test of time.<br><br>
> 
> <dd>Now, the WASC folks are super smart, and the threat classification is
> a solid body of work. Control based AppSec is not something I hear about
> often on these lists.<br>
> <font color=3D"#888888"><br>
> 
> <dd>Jim Manico</font><br><br>
> <br>
> 
> <dd>On Jul 13, 2009, at 1:01 PM,
> <a href=3D"mailto:robert at webappsec.org">robert at webappsec.org</a>
> wrote:<br><br>
> 
> <dl>
> <dd>Hello Roger,<br><br>
> 
> <dd>I lead the WASC TCv2 project and will be able to answer your
> questions, albeit with a bias towards the TC.<br>
> 
> <dd>For starters I am not the best person to speak on behalf of the OWASP
> ASVS project (maybe they will respond?)<br>
> 
> <dd>so I simply won't speak on it other than to say it appears to focus
> more on process and maturity levels.<br><br>
> 
> <dd>Second please take a peek at
> <a href=3D"http://projects.webappsec.org/Using-the-Threat-Classification">
> http://projects.webappsec.org/Using-the-Threat-Classification</a> as it
> outlines<br>
> 
> <dd>ways people use the TC (myself included). Speaking on my own personal
> experience (and others that I know)<br>
> 
> <dd>I use the TC as<br><br>
> 
> <dd>A checklist:<br>
> 
> <dd>I use the TC as a checklist of potential security issues (the TC
> breaks this up into attacks and weaknesses)<br>
> 
> <dd>that my application/site is likely to be affected by. I evaluate
> which functionality my application offers from<br>
> 
> <dd>a business and technical perspective and map that functionality to
> possible weaknesses and attacks that will need<br>
> 
> <dd>to be evaluated during a security review. For example if my
> application uses XML and XQUERY I'd add XML Injection<br>
> 
> <dd>(<a href=3D"http://projects.webappsec.org/XML-Injection">
> http://projects.webappsec.org/XML-Injection</a>) and XQuery Injection
> (<a href=3D"http://projects.webappsec.org/XQuery-Injection">
> http://projects.webappsec.org/XQuery-Injection</a>)<br>
> 
> <dd>to a list of security concerns, effectively creating a minimum
> security test plan/threat model. I then ensure my<br>
> 
> <dd>security evaluations/testing is checking (at the least) for the
> attacks and weaknesses against this list. I've<br>
> 
> <dd>personally had a situation where I've used the TC on a pen test with
> a 3rd party and asked if they performed 'x'<br>
> 
> <dd>testing which they responded no. Shortly after they performed the
> testing and found an 'x' issue. In this situation<br>
> 
> <dd>I used the TC as a checklist and it resulted in a finding that may or
> may not have been discovered had I not asked.<br><br>
> 
> <dd>Reference Material<br>
> 
> <dd>When I file a security defect I provide a URl to the appropriate TC
> section for additional reading by development<br>
> 
> <dd>and/or QA. This saves me time rewriting/explaining the issue and
> being to brief. The TCv2 sub sections are all group<br>
> 
> <dd>peer reviewed in multiple phases and once they are completed are
> locked (random website visitors cannot modify them<br>
> 
> <dd>as with a traditional wiki).<br><br>
> 
> <dd>Security Metrics<br>
> 
> <dd>In particular the ability to flag defects with a certain attack or
> weakness flag allowing me to gain better insight into<br>
> 
> <dd>the more prevalent issues. This has been useful in developing better
> security training, enhancing security testing/finding<br>
> 
> <dd>gaps, and evaluating priority for security component
> development.<br><br>
> 
> <dd>Chances are you'd probably utilize both for different aspects in your
> security program.<br>
> 
> <dd>Based on your email I will likely write an in depth article on using
> the TC beyond the light wiki page above<br>
> 
> <dd>as we near publication.<br><br>
> 
> <dd>Regards,<br>
> 
> <dd>- Robert Auger<br>
> 
> <dd>WASC Co Founder and Threat Classification v2 Project Leader<br>
> 
> <dd><a href=3D"http://www.webappsec.org/">http://www.webappsec.org/</a><br>
> <br>
> 
> <dl><br>
> 
> <dd>I'm putting together a requirements list for black box web pen
> testing<br>
> 
> <dd>and want to include a standards requirement. I've looked intothe
> WASC<br>
> 
> <dd>Threat Classification and OWASP's ASVS. The former seems to focus
> on<br>
> 
> <dd>high level threats, while the latter on testing controls present
> in<br>
> 
> <dd>the app. With the release of version two of the threat
> classification,<br>
> 
> <dd>which standard is more appropriate to use for web app pen testing
> and<br>
> 
> <dd>why?<br><br>
> 
> <dd>Thanks,<br>
> 
> <dd> Roger<br><br>
> 
> </dl><br>
> 
> <dd>
> ----------------------------------------------------------------------------=
> <br>
> 
> <dd>Join us on IRC:
> <a href=3D"http://irc.freenode.net">irc.freenode.net</a>
> #webappsec<br><br>
> 
> <dd>Have a question? Search The Web Security Mailing List Archives:<br>
> 
> <dd><a href=3D"http://www.webappsec.org/lists/websecurity/archive/">
> http://www.webappsec.org/lists/websecurity/archive/</a><br><br>
> 
> <dd>Subscribe via RSS:<br>
> 
> <dd><a href=3D"http://www.webappsec.org/rss/websecurity.rss">
> http://www.webappsec.org/rss/websecurity.rss</a> [RSS Feed]<br><br>
> 
> <dd>Join WASC on LinkedIn<br>
> 
> <dd><a href=3D"http://www.linkedin.com/e/gis/83336/4B20E4374DBA">
> http://www.linkedin.com/e/gis/83336/4B20E4374DBA</a><br><br>
> 
> </dl><br>
> 
> <dd>
> ----------------------------------------------------------------------------=
> <br>
> 
> <dd>Join us on IRC:
> <a href=3D"http://irc.freenode.net">irc.freenode.net</a>
> #webappsec<br><br>
> 
> <dd>Have a question? Search The Web Security Mailing List
> Archives:<a href=3D"http://www.webappsec.org/lists/websecurity/archive/">
> http://www.webappsec.org/lists/websecurity/archive/</a><br><br>
> 
> <dd>Subscribe via
> RSS:<a href=3D"http://www.webappsec.org/rss/websecurity.rss">
> http://www.webappsec.org/rss/websecurity.rss</a> [RSS Feed]<br><br>
> 
> <dd>Join WASC on LinkedIn<br>
> 
> <dd><a href=3D"http://www.linkedin.com/e/gis/83336/4B20E4374DBA">
> http://www.linkedin.com/e/gis/83336/4B20E4374DBA</a><br><br>
> 
> </dl></blockquote></body>
> </html>
> 


----------------------------------------------------------------------------
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