<div>It looks like we are getting a good number of subscribers to this list, and more importantly some great comments and feedback.&nbsp; I'd like to thank everyone for their contributions and involvement, and hope that this project continues in this way.
</div>
<div>&nbsp;</div>
<div>Looking at some of the posting thus far, I think I'd like to step in with a new post and clarify some of the constraints and goals of this project.&nbsp; I've mentioned them a bit in some replies to other posts, but having a fresh post for new subscribers to see, and to give a place for existing subscribers to comment on the entire project as a whole.
</div>
<div>&nbsp;</div>
<div>First off, although I've mentioned PCI in the project title and description, the goal is for OWASP to recommend what we arrive at at the end of this project to PCI as a replacement for the &quot;OWASP Top Ten&quot; currently in place in the existing requirements.&nbsp; However, my intention is to try and develop this standard to be as stand-alone as possible so many other people can benefit from it, not just those that transmit credit card data (many many other web apps transmit &quot;sensitive&quot; data, and these should be able to benefit from it as well).&nbsp; The only reason that I've mentioned PCI to start with is that they already have a very good set&nbsp;of requirements (but network, not web-app focused), in a nice structured format, and are closely matched with the other goal of this project - why go re-inventing the wheel if there already is a public document that fits may of the intentions of the project :)
</div>
<div>&nbsp;</div>
<div>Which brings us on to the other goal.&nbsp; The aim of this project is to generate a list of *testable* requirements that a *minimally* secure web application should pass.&nbsp; I'm explicitly calling out &quot;minimal&quot; as there's certainly some best-practices and technologies that go to improve the security of an application, but we shouldn't try to prescribe any of them.&nbsp; We are aiming at a baseline that hopefully will change over the years.&nbsp;&nbsp; Also, this project is focused at the *testing* side of SDLC - although there's been some great comments about architecture and defence-in-depth, these things are very difficult to test for, especially in a black-box methodology (which most testing/audits are carried in).&nbsp; So I'd like to try and stay focused on that.
</div>
<div>&nbsp;</div>
<div>Finally, bear in mind that if we are successful here, a lot of interested parties may want to utilize such a requirements checklist.&nbsp; This is a double-edged sword.&nbsp; On the one hand we have the goal of security - ensuring that the standard is meaningful and does actually protect web applications.&nbsp; In contrast, if the requirements are wholesale adopted, they have to be appropriate for *existing* applications - we should call-out the impact companies and vendors may have in complying, especially with legacy applications.&nbsp; So, this isn't a blue-sky project, and any potential problems should be discussed here as well (for example, one of my colleagues pointed out the number of banks that still use 4-digit PIN's for passwords - this could be a major hurdle and we should at least talk about other such issues).
</div>
<div>&nbsp;</div>
<div>Although we are initially discussing the requirements, and what they consist of, any post on how we should test for them or any other off-topic (but related) posts are very welcome.</div>
<div>&nbsp;</div>
<div>Well, once again, thanks for all that have taken a look, or contributed in some way.&nbsp; I look forward to seeing more subscribers, and lively discussion :)</div>
<div>&nbsp;</div>
<div>Cheers,</div>
<div>Mike</div>