Re: [WEB SECURITY] Deploying WAFs In Listening-Only Mode - Waste of Money?

["Ryan Barnett" <rcbarnett@xxxxxxxxx>]

------=_Part_7026_2828989.1200260406269
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

------=_Part_7026_2828989.1200260406269
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

<div>On Jan 12, 2008 5:32 PM, Andre Gironda &lt;<a href="mailto:andreg@gmail.com";>andreg@gmail.com</a>&gt; wrote:<br></div>
<div class="gmail_quote">
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Deploying WAFs at all - Waste of Money?<br><br>Answer: Not if you just made a check-mark on a PCI-DSS audit
</blockquote>
<div>&nbsp;</div>
<div>Since you mentioned PCI...&nbsp; I did a recent Blog post on section 6.6 (<a href="http://www.modsecurity.org/blog/archives/2007/12/pci_requirement.html";>http://www.modsecurity.org/blog/archives/2007/12/pci_requirement.html
</a>) and it appears to me that the spirit of this section is to implement some form of remediation to help &quot;prevent&quot; web-based attacks.&nbsp; If you look at the audit procedure document (<a href="https://www.pcisecuritystandards.org/pdfs/pci_audit_procedures_v1-1.pdf";>
https://www.pcisecuritystandards.org/pdfs/pci_audit_procedures_v1-1.pdf</a>) it essentially states that either option you chose for 6.6 has to result in prevention of attacks.&nbsp; If you choose the code review route, then you also must have actually fixed the code as well.&nbsp; Just showing a PCI auditor a list of vulns identified by a code review, code scanner or web app scanner will not suffice.&nbsp; The auditor is suppose to obtain proof the the code has also been fixed.&nbsp; If not, then I don&#39;t see how you could get a &quot;check mark&quot; here and pass 
6.6.&nbsp; On the flip side, if you chose the WAF route, it also states that it needs to be &quot;preventing&quot; attacks which seems to me to mean that it has to be be doing some form of blocking.&nbsp; 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).</div>
<div>&nbsp;</div>
<div>I guess that this topic is slightly ahead of the curve since 6.6 is considered &quot;Best Practice&quot; right now, however this will be changing in abount 5 months...</div>
<div>&nbsp;</div>
<div>Are there any PCI auditors on this list that care to comment on this issue?</div></div><br>-- <br>Ryan C. Barnett<br>ModSecurity Community Manager<br>Breach Security: Director of Application Security Training<br>Web Application Security Consortium (WASC) Member
<br>CIS Apache Benchmark Project Lead<br>SANS Instructor, GCIA, GCFA, GCIH, GSNA, GCUX, GSEC<br>Author: Preventing Web Attacks with Apache 

------=_Part_7026_2828989.1200260406269--