Actually, I did state the following which was meant to point that out:
"I guess that this topic is slightly ahead of the curve since 6.6 is
considered "Best Practice" right now, however this will be changing in
abount 5 months..."
-Ryan
On Jan 14, 2008 12:46 AM, Boaz Shunami <BoazS@comsecglobal.com> wrote:
Ryan,
One thing you haven't noted, regarding 6.6 is that until June 30 this year,
this requirement is considered best practice: "Note: This method is
considered a best practice until June 30, 2008, after which it becomes a
requirement."
Best Regards,
Boaz Shunami
QSA, Comsec Consulting
________________________________
From: Trey Ford [mailto:ford.trey@gmail.com]
Sent: Monday, January 14, 2008 6:07 AM
To: Ryan Barnett
Cc: Andre Gironda; B Snake; websecurity@webappsec.org;
webappsec@securityfocus.com
Subject: Re: [WEB SECURITY] Deploying WAFs In Listening-Only Mode - Waste of
Money?
Subject: Re: [WEB SECURITY] Deploying WAFs In Listening-Only Mode - Waste of
Money?
Ryan,
I am no longer with a QSAC, but I held the QSA desgnation. I believe the
best way to discuss a PCI requirement may be in light of what a QSA
(Qualified Security Assessor) will need to evidence an 'in place' finding.
-----------------
Stated as simply as possible, Requirement 6.6 states that "web facing
applications are secured from known attacks". We can help the QSA collect
evidence showing that:
1) An organization has demonstrated due care, by supplying evidence that
they have an organization that 'specializes in application security' test
their web facing applications to identify 'known attacks' or 'common
vulnerabilities'.
+Note, this is not a network vulnerability scan, but something
like a run-time / black box application assessment or a code review.
2) Vulnerabilities identified in the assessment are corrected.
Vulnerabilities may be managed by correcting code, tuning an application
firewall, etc.
3) Weaknesses corrected in step 2 are not manifested in a reassessment of
that code (runtime / static)
4) This cycle is repeated regularly *and* after new changes are made to an
application *and* new attack research is released.
-----------------
Your statement was spot on, "either option you chose for 6.6 has to result
in prevention of attacks." I see the two options listed in 6.6 as
suggestions on how to remediate application layer vulnerabilities- if you
control your code, fix and evidence that; if you do not control your code,
close vulnerabilities with a WAF.
--
Trey Ford
On Jan 13, 2008, at 1:40 PM, Ryan Barnett wrote:
On Jan 12, 2008 5:32 PM, Andre Gironda <andreg@gmail.com> wrote:
Deploying WAFs at all - Waste of Money?
Answer: Not if you just made a check-mark on a PCI-DSS audit
Since you mentioned PCI... I did a recent Blog post on section 6.6
(http://www.modsecurity.org/blog/archives/2007/12/pci_requirement.html ) and
it appears to me that the spirit of this section is to implement some form
of remediation to help "prevent" web-based attacks. If you look at the
audit procedure document (
https://www.pcisecuritystandards.org/pdfs/pci_audit_procedures_v1-1.pdf) it
essentially states that either option you chose for 6.6 has to result in
prevention of attacks. If you choose the code review route, then you also
must have actually fixed the code as well. Just showing a PCI auditor a
list of vulns identified by a code review, code scanner or web app scanner
will not suffice. The auditor is suppose to obtain proof the the code has
also been fixed. If not, then I don't see how you could get a "check mark"
here and pass 6.6. On the flip side, if you chose the WAF route, it also
states that it needs to be "preventing" attacks which seems to me to mean
that it has to be be doing some form of blocking. The details of exactly
what must be blocked is a bit hazy (although I would assume that you must be
blocking both SQL Injection and XSS vulns/attacks as those two categories
are the only 2 high vulns that would result if a failure of other sections
of PCI such as 6.5).
I guess that this topic is slightly ahead of the curve since 6.6 is
considered "Best Practice" right now, however this will be changing in
abount 5 months...
Are there any PCI auditors on this list that care to comment on this issue?
--
Ryan C. Barnett
ModSecurity Community Manager
Breach Security: Director of Application Security Training
Web Application Security Consortium (WASC) Member
CIS Apache Benchmark Project Lead
SANS Instructor, GCIA, GCFA, GCIH, GSNA, GCUX, GSEC
Author: Preventing Web Attacks with Apache
________________________________
IMPORTANT: The contents of this email and any attachments are confidential.
They are intended for the named recipient(s) only.
If you have received this email in error, please notify the system manager
or the sender immediately and do not disclose the contents to anyone or make
copies thereof.
*** eSafe scanned this email for viruses, vandals, and malicious content.
*** ________________________________
--
Ryan C. Barnett
ModSecurity Community Manager
Breach Security: Director of Application Security Training
Web Application Security Consortium (WASC) Member
CIS Apache Benchmark Project Lead
SANS Instructor, GCIA, GCFA, GCIH, GSNA, GCUX, GSEC
Author: Preventing Web Attacks with Apache
-------------------------------------------------------------------------
Sponsored by: Watchfire
Methodologies & Tools for Web Application Security Assessment
With the rapid rise in the number and types of security threats, web
application security assessments should be considered a crucial phase in the
development of any web application. What methodology should be followed? What
tools can accelerate the assessment process? Download this Whitepaper today!
https://www.watchfire.com/securearea/whitepapers.aspx?id=70170000000940F
-------------------------------------------------------------------------
