<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns="http://www.w3.org/TR/REC-html40" xmlns:v = 
"urn:schemas-microsoft-com:vml" xmlns:o = 
"urn:schemas-microsoft-com:office:office" xmlns:w = 
"urn:schemas-microsoft-com:office:word"><HEAD>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.6000.16414" name=GENERATOR><!--[if !mso]>
<STYLE>v\:* {
        BEHAVIOR: url(#default#VML)
}
o\:* {
        BEHAVIOR: url(#default#VML)
}
w\:* {
        BEHAVIOR: url(#default#VML)
}
.shape {
        BEHAVIOR: url(#default#VML)
}
</STYLE>
<![endif]-->
<STYLE>@font-face {
        font-family: Tahoma;
}
@page Section1 {size: 8.5in 11.0in; margin: 1.0in 1.25in 1.0in 1.25in; }
P.MsoNormal {
        FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
LI.MsoNormal {
        FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
DIV.MsoNormal {
        FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
A:link {
        COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlink {
        COLOR: blue; TEXT-DECORATION: underline
}
A:visited {
        COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlinkFollowed {
        COLOR: blue; TEXT-DECORATION: underline
}
P {
        FONT-SIZE: 12pt; MARGIN-LEFT: 0in; MARGIN-RIGHT: 0in; FONT-FAMILY: "Times New Roman"; mso-margin-top-alt: auto; mso-margin-bottom-alt: auto
}
SPAN.EmailStyle18 {
        COLOR: navy; FONT-FAMILY: Arial; mso-style-type: personal-reply
}
DIV.Section1 {
        page: Section1
}
</STYLE>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext="edit">
  <o:idmap v:ext="edit" data="1" />
 </o:shapelayout></xml><![endif]--></HEAD>
<BODY lang=EN-US vLink=blue link=blue>
<DIV dir=ltr align=left><SPAN class=314243213-13062007><FONT face=Arial 
color=#0000ff size=2>Ed,</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=314243213-13062007><FONT face=Arial 
color=#0000ff size=2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=ltr align=left><SPAN class=314243213-13062007><FONT face=Arial 
color=#0000ff size=2>I do have a first cut at which techniques are better for 
which vulnerability classes.&nbsp; I will forward to the list later today as I 
am now travelling.&nbsp; In general if there is a design vulnerability it needs 
manual testing/review.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=314243213-13062007></SPAN>&nbsp;</DIV>
<DIV dir=ltr align=left><SPAN class=314243213-13062007><FONT face=Arial 
color=#0000ff size=2>-Chris</FONT>&nbsp;</SPAN></DIV><BR>
<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>Bellis, 
Ed<BR><B>Sent:</B> Tuesday, June 12, 2007 9:44 AM<BR><B>To:</B> Chris Wysopal; 
Mark Curphey; owasp-webcert@lists.owasp.org<BR><B>Subject:</B> Re: 
[Owasp-webcert] Assurance Levels<BR></FONT><BR></DIV>
<DIV></DIV>
<DIV class=Section1>
<P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN 
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN 
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">I think this makes a 
lot of sense and should likely be the way we look at incorporating assurance 
levels into the webcert standard. As discussed previously, this addresses the 
&#8220;bubble&#8221; thinking of the current PCI standard. By taking into account the 
vulnerability class and the threat that is being mitigated, you&#8217;ll be able to 
pick the &#8220;right control for the job&#8221; to achieve the assurance level required for 
the application and the organization.<o:p></o:p></SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN 
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN 
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">This is great work, and 
of course, the devil will always be in the details. Is there an existing matrix 
that maps vulnerability classes to analysis techniques (OWASP top 10 at a 
minimum)? I presume this would be something this group will need to come up 
with. Chris, do you have a head start in this area?<o:p></o:p></SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN 
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN 
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">-Ed<o:p></o:p></SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN 
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN 
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<DIV>
<DIV class=MsoNormal style="TEXT-ALIGN: center" align=center><FONT 
face="Times New Roman" size=3><SPAN style="FONT-SIZE: 12pt">
<HR tabIndex=-1 align=center width="100%" SIZE=2>
</SPAN></FONT></DIV>
<P class=MsoNormal><B><FONT face=Tahoma size=2><SPAN 
style="FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: Tahoma">From:</SPAN></FONT></B><FONT 
face=Tahoma size=2><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Tahoma"> 
owasp-webcert-bounces@lists.owasp.org 
[mailto:owasp-webcert-bounces@lists.owasp.org] <B><SPAN 
style="FONT-WEIGHT: bold">On Behalf Of </SPAN></B>Chris Wysopal<BR><B><SPAN 
style="FONT-WEIGHT: bold">Sent:</SPAN></B> Monday, June 11, 2007 9:55 
AM<BR><B><SPAN style="FONT-WEIGHT: bold">To:</SPAN></B> Mark Curphey; 
owasp-webcert@lists.owasp.org<BR><B><SPAN 
style="FONT-WEIGHT: bold">Subject:</SPAN></B> Re: [Owasp-webcert] Assurance 
Levels</SPAN></FONT><o:p></o:p></P></DIV>
<P class=MsoNormal><FONT face="Times New Roman" size=3><SPAN 
style="FONT-SIZE: 12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P class=MsoNormal><FONT face="Times New Roman" size=3><SPAN 
style="FONT-SIZE: 12pt">&nbsp;<o:p></o:p></SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial color=blue size=2><SPAN 
style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">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; 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;</SPAN></FONT><o:p></o:p></P>
<P class=MsoNormal><FONT face="Times New Roman" size=3><SPAN 
style="FONT-SIZE: 12pt">&nbsp;<o:p></o:p></SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial color=blue size=2><SPAN 
style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">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;</SPAN></FONT><o:p></o:p></P>
<DIV>
<P class=MsoNormal><FONT face="Times New Roman" size=3><SPAN 
style="FONT-SIZE: 12pt">&nbsp;<o:p></o:p></SPAN></FONT></P></DIV>
<DIV>
<P class=MsoNormal><FONT face=Arial color=blue size=2><SPAN 
style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">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.</SPAN></FONT><o:p></o:p></P></DIV>
<DIV>
<P class=MsoNormal><FONT face="Times New Roman" size=3><SPAN 
style="FONT-SIZE: 12pt">&nbsp;<o:p></o:p></SPAN></FONT></P></DIV>
<DIV>
<P class=MsoNormal><FONT face=Arial color=blue size=2><SPAN 
style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">-Chris</SPAN></FONT><o:p></o:p></P></DIV>
<P class=MsoNormal><FONT face="Times New Roman" size=3><SPAN 
style="FONT-SIZE: 12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<DIV class=MsoNormal style="TEXT-ALIGN: center" align=center><FONT 
face="Times New Roman" size=3><SPAN style="FONT-SIZE: 12pt">
<HR tabIndex=-1 align=center width="100%" SIZE=2>
</SPAN></FONT></DIV>
<P class=MsoNormal style="MARGIN-BOTTOM: 12pt"><B><FONT face=Tahoma size=2><SPAN 
style="FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: Tahoma">From:</SPAN></FONT></B><FONT 
face=Tahoma size=2><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Tahoma"> 
owasp-webcert-bounces@lists.owasp.org 
[mailto:owasp-webcert-bounces@lists.owasp.org] <B><SPAN 
style="FONT-WEIGHT: bold">On Behalf Of </SPAN></B>Mark Curphey<BR><B><SPAN 
style="FONT-WEIGHT: bold">Sent:</SPAN></B> Monday, June 11, 2007 4:27 
AM<BR><B><SPAN style="FONT-WEIGHT: bold">To:</SPAN></B> 
owasp-webcert@lists.owasp.org<BR><B><SPAN 
style="FONT-WEIGHT: bold">Subject:</SPAN></B> [Owasp-webcert] Assurance 
Levels</SPAN></FONT><o:p></o:p></P>
<DIV>
<P><FONT face=Arial color=black size=2><SPAN 
style="FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: Arial">I propose to make 
assurance levels an integral part of the OWASP Web Certification Criteria and 
want your feedback on the concept.<o:p></o:p></SPAN></FONT></P>
<P><FONT face=Arial color=black size=2><SPAN 
style="FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: Arial">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><SPAN style="COLOR: #cc6600">Chris Wysopal</SPAN></FONT></A> sent 
me&nbsp;the fantastic graphic atttached describing&nbsp;<A 
href="http://www.veracode.com/"><FONT color=#666666><SPAN 
style="COLOR: #666666">Veracodes</SPAN></FONT></A> view of assurance 
levels.&nbsp; Of course it is nothing new, the basic concept of assurance 
(confidence)&nbsp;is as follows;<o:p></o:p></SPAN></FONT></P>
<BLOCKQUOTE style="MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt">
  <P><FONT face=Arial color=black size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: Arial">Different&nbsp;testing 
  techniques provide different levels of assurance&nbsp;(confidence) 
  on&nbsp;claims&nbsp;about the security of a web site. 
  <o:p></o:p></SPAN></FONT></P></BLOCKQUOTE>
<P><FONT face=Arial color=black size=2><SPAN 
style="FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: Arial">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. <o:p></o:p></SPAN></FONT></P>
<P><FONT face=Arial color=black size=2><SPAN 
style="FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: Arial">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. <o:p></o:p></SPAN></FONT></P>
<P><FONT face=Arial color=black size=2><SPAN 
style="FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: Arial">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.<o:p></o:p></SPAN></FONT></P>
<P><FONT face=Arial color=black size=2><SPAN 
style="FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: Arial">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;<o:p></o:p></SPAN></FONT></P>
<P><FONT face=Arial color=black size=2><SPAN 
style="FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: Arial">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><SPAN style="COLOR: #666666">broken schemes like PCI 
DSS</SPAN></FONT></A>.<o:p></o:p></SPAN></FONT></P>
<P><FONT face=Arial color=black size=2><SPAN 
style="FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: Arial">So what do y'all 
think?<o:p></o:p></SPAN></FONT></P></DIV></DIV></BODY></HTML>