[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [WEB SECURITY] Deploying WAFs In Listening-Only Mode - Waste of Money?
- From: Trey Ford <ford.trey@xxxxxxxxx>
- Subject: Re: [WEB SECURITY] Deploying WAFs In Listening-Only Mode - Waste of Money?
- Date: Sun, 13 Jan 2008 20:07:29 -0800
--Apple-Mail-2-785633653
Content-Type: text/plain;
charset=US-ASCII;
format=flowed;
delsp=yes
Content-Transfer-Encoding: 7bit
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
--Apple-Mail-2-785633653
Content-Type: text/html;
charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
<html><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; "><div>Ryan,</div><div><br =
class=3D"webkit-block-placeholder"></div><div>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.</div><div>-----------------</div><div>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:</div><div><br =
class=3D"webkit-block-placeholder"></div><div>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'. </div><div><span class=3D"Apple-tab-span" =
style=3D"white-space:pre"> </span>+Note, this is not a network =
vulnerability scan, but something like a run-time / black box =
application assessment or a code review.</div><div><br =
class=3D"webkit-block-placeholder"></div><div>2) Vulnerabilities =
identified in the assessment are corrected. Vulnerabilities may be =
managed by correcting code, tuning an application firewall, =
etc.</div><div><br class=3D"webkit-block-placeholder"></div><div>3) =
Weaknesses corrected in step 2 are not manifested in a reassessment of =
that code (runtime / static)</div><div><br =
class=3D"webkit-block-placeholder"></div><div>4) This cycle is repeated =
regularly *and* after new changes are made to an application *and* new =
attack research is released.</div><div>-----------------</div><div>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.</div><div><br =
class=3D"webkit-block-placeholder"></div><div>--</div><div>Trey =
Ford</div><div><br class=3D"webkit-block-placeholder"></div><div><div>On =
Jan 13, 2008, at 1:40 PM, Ryan Barnett wrote:</div><br =
class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div>On =
Jan 12, 2008 5:32 PM, Andre Gironda <<a =
href=3D"mailto:andreg@gmail.com";>andreg@gmail.com</a>> =
wrote:<br></div> <div class=3D"gmail_quote"> <blockquote =
class=3D"gmail_quote" style=3D"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> </div> <div>Since you mentioned =
PCI... I did a recent Blog post on section 6.6 (<a =
href=3D"http://www.modsecurity.org/blog/archives/2007/12/pci_requirement.h=
tml">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 "prevent" web-based =
attacks. If you look at the audit procedure document (<a =
href=3D"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. 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).</div> <div> </div> <div>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...</div> <div> </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 =
</blockquote></div><br></body></html>=
--Apple-Mail-2-785633653--
Brought to you by http://www.webappsec.org
Search this site
|