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_at_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_at_gmail.com]
> Sent: Monday, January 14, 2008 6:07 AM
> To: Ryan Barnett
> Cc: Andre Gironda; B Snake; websecurity_at_webappsec.org;
> webappsec_at_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_at_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
-------------------------------------------------------------------------
Received on Jan 14 2008
Intro
