New PCI requires code review or WAF

I didn't see any further clarification in the document, but
I'd 
specifically like to know if the said organization has to be
external to 
the group responsible for development of the custom code. I
realize that 
would be best practice anyway (just like development and QA
groups 
should be distinct) but the realities of business may not
always 
encourage that.

On the firewall side... will there be some kind of
validation process, I 
wonder, to certify that a specific product / solution meets
the PCI 
requirements?

I suppose that's why we have until June 2008 for this to be
fleshed out 
more. Definitely a step in the right direction however.

Jeff Robertson wrote:
> Before actually reading the PDF, I immediately want to
ask:
> 1. What are the criteria for an "organization
that specializes in 
> application security"?
> 2. What is considered an application layer firewall?
> Maybe these questions are answered in the document.
>
>    
------------------------------------------------------------
------------
>     *From Jeff
Williams [mailto:jeff.williamsowasp.org]
>     *Sent Thursday,
September 07, 2006 10:22
>     *To
webappsecsecurityfocus.com; webappseclists.owasp.org;
>     websecuritywebappsec.org
>     *Subject [WEB
SECURITY] New PCI requires code review or WAF
>
>     Under the new requirements, applications processing
cardholder
>     information MUST get either a code review or a web
app firewall.
>     The language isn’t exactly clear about what happens
in 2008.
>
>     >From the document --
>
>     https://www.pcisecuritystandards.org/pdfs/pci_dss_v1-1
.pdf
>
>     6.5 Develop all web applications based on secure
coding guidelines
>     such as the Open Web Application Security Project
guidelines.
>     Review custom application code to identify coding
vulnerabilities.
>     Cover prevention of common coding vulnerabilities
in software
>     development processes, to include the following:
>
>     6.5.1 Unvalidated input
>
>     6.5.2 Broken access control (for example, malicious
use of user IDs)
>
>     6.5.3 Broken authentication and session management
(use of account
>     credentials and session cookies)
>
>     6.5.4 Cross-site scripting (XSS) attacks
>
>     6.5.5 Buffer overflows
>
>     6.5.6 Injection flaws (for example, structured
query language
>     (SQL) injection)
>
>     6.5.7 Improper error handling
>
>     6.5.8 Insecure storage
>
>     6.5.9 Denial of service
>
>     6.5.10 Insecure configuration management
>
>     6.6 Ensure that all web-facing applications are
protected against
>     known attacks by applying either of the following
methods:
>
>     . Having all custom application code reviewed for
common
>     vulnerabilities by an organization that specializes
in application
>     security . Installing an application layer firewall
in front of
>     web-facing applications.
>
>     Note: This method is considered a best practice
until June 30,
>     2008, after which it becomes a requirement.
>
>     --Jeff
>
>     Jeff Williams, Chair
>
>     The OWASP Foundation <http://www.owasp.org/>
>


------------------------------------------------------------
-------------
Sponsored by: Watchfire

As web applications become increasingly complex, tremendous
amounts of 
sensitive data - personal, medical and financial - are
exchanged, and 
stored. Consumers expect and demand security for this
information. This 
whitepaper examines a few vulnerability detection methods -
specifically 
comparing and contrasting manual penetration testing with
automated 
scanning tools. Download "Automated Scanning or Manual
Penetration 
Testing?" today!

https://www.watchfire.com/securearea/whi
tepapers.aspx?id=701500000008Vmm
------------------------------------------------------------
--------------