<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML dir=ltr><HEAD>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.6000.16414" name=GENERATOR></HEAD>
<BODY>
<DIV dir=ltr align=left><FONT face=Arial color=#0000ff 
size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><SPAN class=566402114-11062007><FONT face=Arial 
color=#0000ff size=2>I should have supplied more explanation behind the graphic 
that I sent to Mark because it is a bit more complex than just automated static 
is better than a questionaire and automated dynamic is better than automated 
static and so on.&nbsp; Each analysis technique has a subset of all 
vulnerability classes that it can even attempt to detect.&nbsp; Try finding 
authorization bypass with an automated tool for instance. More generally, each 
analysis technique has a false negative rate for each vulnerability class.&nbsp; 
</FONT></SPAN><SPAN class=566402114-11062007><FONT face=Arial color=#0000ff 
size=2>Measuring the false negative rates by vulnerability class for each 
analysis technique is a significant effort but a valuable one.&nbsp; At Veracode 
we are "analysis technique neutral".&nbsp; We want to combine multiple 
techniques to give the best possible analysis for the amount of money 
appropriate for the assurance requirements. Security must make economic sense 
after all.&nbsp;&nbsp;</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=566402114-11062007><FONT face=Arial 
color=#0000ff size=2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=ltr align=left><SPAN class=566402114-11062007><FONT face=Arial 
color=#0000ff size=2>So back to the complexity.&nbsp; The idea behind measuring 
the capabilities of different analysis techniques is to assure that the false 
negative rate for all the vulnerability classes you care about is low enough for 
the assurance level the application requires.&nbsp;&nbsp;So for example lets 
take the OWASP top ten as the vulnerability classes we care about for a certain 
application.&nbsp; If the application is high assurance such as an online 
banking application we have to make sure the false negative rate for all these 
vulnerability classes is close to zero.&nbsp; A fully manual effort is not the 
most cost effective since manual testing is the most expensive.&nbsp; If we 
combine automated static and automated dynamic and then add manual testing for 
the classes that the first 2 techniques can't detect or have unacceptable false 
negative rates then we can get to an acceptable FN rate for the complete OWASP 
top ten.&nbsp;</FONT></SPAN></DIV>
<DIV><SPAN class=566402114-11062007><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=566402114-11062007><FONT face=Arial color=#0000ff size=2>There 
are certainly things that automated static analysis can find better than manual 
pen testing.&nbsp; Integer overflows in C/C++ application is a good 
example.&nbsp;So the choice of testing technique does depend on the 
vulnerability class you are looking for.&nbsp; It&nbsp;seems to me that manual 
pen testing is the best for many of the OWASP top ten but automated dynamic and 
even automated static do have a place in driving down costs for high assurance 
applications.&nbsp; The automated techniques may also be good enough for medium 
assurance applications such as back office application that don't deal with high 
value information.</FONT></SPAN></DIV>
<DIV><SPAN class=566402114-11062007><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=566402114-11062007><FONT face=Arial color=#0000ff 
size=2>-Chris</FONT></SPAN></DIV>
<DIV dir=ltr align=left><BR></DIV>
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> owasp-webcert-bounces@lists.owasp.org 
[mailto:owasp-webcert-bounces@lists.owasp.org] <B>On Behalf Of </B>Mark 
Curphey<BR><B>Sent:</B> Monday, June 11, 2007 4:27 AM<BR><B>To:</B> 
owasp-webcert@lists.owasp.org<BR><B>Subject:</B> [Owasp-webcert] Assurance 
Levels<BR></FONT><BR></DIV>
<DIV></DIV>
<DIV><FONT face=Arial color=#000000 size=2>
<P>I propose to make assurance levels an integral part of the OWASP Web 
Certification Criteria and want your feedback on the concept.</P>
<P>In many ways it's one of those things that's so damn obvious when you see it 
described with clarity. Enlightenment came for me when&nbsp;<A 
href="http://www.veracode.com/management-team.php#Wysopal"><FONT 
color=#cc6600>Chris Wysopal</FONT></A> sent me&nbsp;the fantastic graphic 
atttached describing&nbsp;<A href="http://www.veracode.com/"><FONT 
color=#666666>Veracodes</FONT></A> view of assurance levels.&nbsp; Of course it 
is nothing new, the basic concept of assurance (confidence)&nbsp;is as 
follows;</P>
<BLOCKQUOTE>
  <P>Different&nbsp;testing techniques provide different levels of 
  assurance&nbsp;(confidence) on&nbsp;claims&nbsp;about the security of a web 
  site. </P></BLOCKQUOTE>
<P>An automated static analysis tool will provide&nbsp;a lower level 
of&nbsp;assurance than an automated dynamic analysis tool which will in-turn 
provide&nbsp;a lower level of&nbsp;assurance than a comprehensive manual code 
review.&nbsp; It also follows that an automated web application penetration test 
will provide a lower level of assurance than a manual penetration test. Both 
types of penetration testing will&nbsp;provide lower levels of assurance than 
code reviews. It also makes sense that if a company has&nbsp;demonstrated that 
security is an integral part of the security DNA of their SDLC (define, design, 
develop, deploy and maintain) then there is a higher level of assurance that any 
test results will be consistent in the future. </P>
<P>So why wouldn't everyone just go for the&nbsp;approach&nbsp;that 
provides&nbsp;the highest level of assurance? It's very simple, cost. The 
appropriate level of assurance should be based on risk. </P>
<P>Of course all of this things have a butterfly effect, no two tools are the 
same and no two testers are the same.&nbsp;Imagine a control panel with multiple 
dials but where people want a single&nbsp;output display (not necessarily a 
single reading).&nbsp; I expect lots of people arguing that a specific tool or 
firm is as good as the next level up on the assurance level but well deal with 
that as well.</P>
<P>This also enables us to define what a web app firewall is good for, what it 
isn't and place it into an assurance level bucket. More on that in a 
while.&nbsp;</P>
<P>By incorporating assurance levels into the criteria, industry sectors, 
business partners or regulators can require a level of security with an 
assurance level based on risk. This would be a significant step forward from 
where we are today with <A 
href="http://securitybuddha.com/2007/03/23/the-problems-with-the-pci-data-security-standard-part-1/"><FONT 
color=#666666>broken schemes like PCI DSS</FONT></A>.</P>
<P>So what do y'all think?</P></FONT></DIV></BODY></HTML>