[Owasp-standards] PCI-WASS constraints and goals

owasp-standards-admin at lists.sourceforge.net owasp-standards-admin at lists.sourceforge.net
Wed Dec 21 07:24:51 EST 2005

It looks like we are getting a good number of subscribers to this list, and
more importantly some great comments and feedback.  I'd like to thank
everyone for their contributions and involvement, and hope that this project
continues in this way.

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

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 "OWASP Top Ten" currently in place
in the existing requirements.  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 "sensitive" data, and these should be able to
benefit from it as well).  The only reason that I've mentioned PCI to start
with is that they already have a very good set 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

Which brings us on to the other goal.  The aim of this project is to
generate a list of *testable* requirements that a *minimally* secure web
application should pass.  I'm explicitly calling out "minimal" 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.
We are aiming at a baseline that hopefully will change over the years.
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).  So I'd like to try
and stay focused on that.

Finally, bear in mind that if we are successful here, a lot of interested
parties may want to utilize such a requirements checklist.  This is a
double-edged sword.  On the one hand we have the goal of security - ensuring
that the standard is meaningful and does actually protect web applications.
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.  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

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.

Well, once again, thanks for all that have taken a look, or contributed in
some way.  I look forward to seeing more subscribers, and lively discussion

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.owasp.org/pipermail/owasp-standards/attachments/20051221/6d5927eb/attachment.html 

More information about the Owasp-standards mailing list