[Owasp-standards] RE: New OWASP project - PCI Web Security Standards

owasp-standards-admin at lists.sourceforge.net owasp-standards-admin at lists.sourceforge.net
Tue Dec 20 17:59:37 EST 2005

I agree with Lyal however,
I just posted to the main list for the new project.
A problem that a lot of users that I talk with have though is the PCI
security standards are not entirely application based.

So most application architects and developers don't read or have never heard
of the PCI standards, they have however heard of OWASP.

Creating an application specific standard for credit card handling based
around the PCI standards is a great idea, though I believe they should
reference each other but be independent of each other.

Just my 2c..

-----Original Message-----
From: Lyal Collins [mailto:lyal.collins at key2it.com.au] 
Sent: Wednesday, 21 December 2005 6:48 AM
To: mike.owasp at gmail.com; webappsec at securityfocus.com;
owasp-standards at lists.sourceforge.net
Subject: RE: New OWASP project - PCI Web Security Standards

I'm confused as to the intention here.
PCI, section 6.5 requires the use of secure coding guidelines e.g. owasp
PCI requires quarterly vulnerability scanning, and an annual pen-test.

Looking at the draft doc from the site, I have several comments:
There is no definition of 'cardholder data'. PCI desn't have one either, but
I believe most people take the term to mean 'at least the card account
number'. ymmv
Section 1 is already an auditable requirement under PCI.  Limiting scope to
SSL only means things like VPNs can't be used for cardholder data, nor
encrypted objects in Web Services/SOAP environments (encrypt the payload
data, and pass it via http, not necessarily https)
Section 2 is already an auditable requirement under PCI.  Further PCI
contains no specific hardening standard or requirements, other than
disabling 'those services not required for businss purposes'.  NIST, SANs
etc often aim to do different things than PCI, thus they may not be
appropriate docs for all businesses/IT environments without lots of
Section 3 is just restating whats in PCI. 
Section 4 is already an auditable requirement under PCI.
Section 5 is already an auditable requirement under PCI.  This is worded
slightly better in someways
Section 6 is already an auditable requirement under PCI.
Section 7, 8 are already an auditable requirement under PCI, as part of the
secure coding methodology requirement.
Section 9 is new (i.e. goes beyond PCI), and a good design idea.
Section 10 is a good idea, but only useful in the external software honours
'don't cache' tags.
Section 11 is already an auditable requirement under PCI.

Things like SQL-injection tests, XSS tests ( and determining false
positives), sesion management tests and app-level DOS tests etc will be more
useful, I think 

Just my 3cents

-----Original Message-----
From: mike.owasp at gmail.com [mailto:mike.owasp at gmail.com] 
Sent: Tuesday, 20 December 2005 6:45 AM
To: webappsec at securityfocus.com
Subject: New OWASP project - PCI Web Security Standards

Hello list,

I'm pleased to announce the start of a new OWASP project focused on creating
a proposed set of Web-application Security Standards for sites that process
credit card information.  

As things currently stand, the payment card industry (PCI - Visa,
Mastercard, etc) plan to specify compliance to the OWASP Top Ten as part of
successfully passing a scan/audit.  Although the Top Ten lists the common
threats to web applications, it is neither comprehensive nor testable in a
pass/fail methodology.

The OWAS PCI-WASS project aims at producing a set of *minimum* standards a
web-application should be tested against if it is to process credit card
information.  A final goal is to arrive at a set of testable criteria, much
the same as the existing PCI security standard.  

If this interests you, please visit the project home page at
http://www.owasp.org/standards/pci-wass.html.  There you will find a
strawman document (available at
http://www.owasp.org/docroot/owasp/misc/PCI-WASS_Strawman_Draft.doc) to
start discussions and set direction.  To marshal comments, ideas,
discussions, criticism, and feedback, I have set up another list at
owasp-standards at lists.sourceforge.net

I look forward to your participation.


More information about the Owasp-standards mailing list