<HTML>
<HEAD>
<TITLE>Re: [Owasp-webcert] OWASP Evaluation and Certification Criteria</TITLE>
</HEAD>
<BODY>
<FONT FACE="Verdana, Helvetica, Arial"><SPAN STYLE='font-size:12.0px'>Hi Mark,<BR>
I like the direction you&#8217;re headed, and I hope to make use of the final result. &nbsp;At the same time, I&#8217;m not sure I completely understand all of what you&#8217;re driving at, so perhaps some of the following criticism stems from my lack of understanding. &nbsp;If that&#8217;s the case, then maybe I&#8217;m just pointing out places where the document is open to misinterpretation.<BR>
<BR>
Here goes:<BR>
<BR>
- Would E-bay be adequately secure if it complied with the extended criteria? &nbsp;Since the criteria don&#8217;t say anything about what&#8217;s required to run a fair and legal auction, I have to think E-Bay needs to do more than you specify. &nbsp;For that reason, it seems like you&#8217;re defining a <I>minimum</I> set of requirements. &nbsp;Auditors and security-conscious organizations might like to extend that set with their own more specific requirements, in which case there will be a lot of value in the format you define in addition to the security requirements you establish.<BR>
<BR>
- At the same time, it is feasible that an application need not meet all of the specified criteria in order to be adequately secure. &nbsp;(Do I need SSL if the application can only be accessed through a VPN?) &nbsp;For this reason, I can imagine that people would want to say &#8220;I&#8217;m compliant with the OWASP basic requirements minus the following set (x, y, z).&#8221; &nbsp;This is where specs like PCI get kind of fuzzy, but without some way to specify a set of security requirements, people are likely to throw up their hands and say &#8220;that OWASP thing just doesn&#8217;t apply to me.&#8221; &nbsp;&nbsp;I could imagine defining something along the lines of a CC protection profile and then trying to popularize a small number of profiles. &nbsp;Essentially you&#8217;ve already started to do that by defining &#8220;basic&#8221; and &#8220;extended&#8221;.<BR>
<BR>
- From the sound of it, OWASP is going to be a certifying body for auditors. &nbsp;It will also manage the exception process and process applications for Gold Certificate status. &nbsp;That sounds like a lot of work and a lot of coordination. &nbsp;I think OWASP has done some great stuff, but it hasn&#8217;t done anything even close to this before. &nbsp;Further, these kinds of activities are typically not the kinds of things that loosely coupled volunteer-driven organizations excel at.<BR>
&nbsp;<BR>
- I think I&#8217;d benefit a lot from more examples in the document. &nbsp;I can see that it&#8217;s part of your plan to add some, so I suppose I&#8217;m just voting for doing those sooner rather than later.<BR>
<BR>
Looking over my notes, my over-all suggestion is that you reduce the scope of this initial effort. &nbsp;Establishing the long term vision is important, but revealing the path that will get us started is perhaps equally important. <BR>
<BR>
Regards,<BR>
Brian<BR>
<HR ALIGN=CENTER SIZE="3" WIDTH="95%"><B>From: </B>Mark Curphey &lt;mark@curphey.com&gt;<BR>
<B>Reply-To: </B>&lt;owasp-webcert@lists.owasp.org&gt;<BR>
<B>Date: </B>Sun, 5 Aug 2007 09:11:25 -0700<BR>
<B>To: </B>&lt;owasp-webcert@lists.owasp.org&gt;<BR>
<B>Conversation: </B>[Owasp-webcert] OWASP Evaluation and Certification Criteria<BR>
<B>Subject: </B>[Owasp-webcert] OWASP Evaluation and Certification Criteria<BR>
<BR>
For those that want to see some progress attached is the latest draft.<BR>
<BR>
1. Remember the idea is to build a template from which we can derive<BR>
individual Evaluation and Certification Criteria or indeed a complete<BR>
scheme. What you see is the template from which we will &quot;configure&quot; a<BR>
reference implementation. This approach is scalable and I have heard from a<BR>
few of you off-line that you really like this and a few banks plan to adopt<BR>
it which is great news! This will allow Big Co X or Big Co Y to choose their<BR>
password quality or link to their own secure code standards without being<BR>
constrained by a generic lowest common denominator approach but agreeing on<BR>
the big ticket items. The idea is not to cover every possible thing.<BR>
<BR>
2. Authorization - I need some help with this. What do we need to define<BR>
here?<BR>
<BR>
I plan to complete the Process and People parts tomorrow and then configure<BR>
the reference implementation. This will be the one with tangible values and<BR>
not the cut and paste &lt;insert here&gt;.<BR>
<BR>
Please don't waste time on detailed feedback (especially for grammar) BUT I<BR>
would like commentary and feedback on the topics included in Technology and<BR>
Process. Are there any missing?<BR>
<BR>
Note: This has highlighted that there is a need for a great deal of<BR>
supporting material such as secure coding standards and detailed How To Test<BR>
for specific issues. This is both an issue and an opportunity for OWASP to<BR>
pull together various projects in a cohesive way.<BR>
<BR>
</SPAN></FONT>
</BODY>
</HTML>