Hi Stephen,
Yes, organizations must resolve the issues discovered by the automated tools,
at least to the extent that the tool no longer complains.
While implementing both options of requirement 6.6 is recommended, it is not
required by PCI DSS.
Instead of doing what you propose, I suspect most companies will use an
automated tool, deal with the underlying issues in their codebase, and run the
tool again; but not do that plus buy and deploy a WAF as well.
Michael Date: Tue, 1 Jul 2008 09:02:01 +0800 From: [EMAIL PROTECTED] To:
[EMAIL PROTECTED] Subject: Re: [SC-L] InternetNews Realtime IT News -
Merchants Cope With PCI Compliance CC: [EMAIL PROTECTED]; [EMAIL PROTECTED];
sc-l@securecoding.org Hi Michael, So, unfortunately for the WAF
vendors, people can just use a static source code analysis tool or a web
application vulnerability scanner instead of purchasing and deploying a
WAF. I don't know much about PCI 6.6 (yet), but don't the organizations
have to mitigate the vulnerabilities found? (fix, bear or transfer risk, use a
different security control..) Surely one just doesn't have to just run the
tool... I am guessing that WAFs can mitigate a considerable amount of these
vulnerabilities. Automated tools suck at finding business logic flaws which
just so happens to be a WAF's supposed weakness, too. So to me it seems to
be a perfect marriage: automated tools that can only find bugs and WAFs that
can only fix bugs :-) Stephen On Tue, Jul 1, 2008 at 5:40 AM, Michael
Gavin [EMAIL PROTECTED] wrote: I too was wondering how much of a boon 6.6
would be to the WAF vendors and/or the companies that do security code
reviews. That is, until 4/22, when the PCI SSC issued a press release
(https://www.pcisecuritystandards.org/pdfs/04-22-08.pdf) announcing an
information supplement clarifying requirement 6.6
(https://www.pcisecuritystandards.org/pdfs/infosupp_6_6_applicationfirewalls_codereviews.pdf).
Clearly, completing security code reviews on all of those web
applications and/or protecting them with those expensive magic pizza
boxes, which, last time that I checked (almost 2 years ago now) were
running about $35K to start, wasn't going to happen any time soon. The
good news from that information supplement is that the PCI Security
Standards Council defined what they mean by an application firewall and
specified what it is supposed to do; the less good news is that they
specified 4 alternative methods for satisfying the code review option: 1.
manual security code review, 2. automated security code review, 3. manual
web application vulnerability scan, and 4. automated web application
vulnerability scan. While I think automation of code reviews and
vulnerability scans is essential, I also believe that none of the automated
tools are yet sufficient (completeness-wise) without some additional manual
effort. So, unfortunately for the WAF vendors, people can just use a
static source code analysis tool or a web application vulnerability scanner
instead of purchasing and deploying a WAF. Michael Date: Mon,
30 Jun 2008 09:17:34 -0500 From: [EMAIL PROTECTED] To: [EMAIL
PROTECTED] CC: SC-L@securecoding.org Subject: Re: [SC-L] InternetNews
Realtime IT News - Merchants Cope With PCI Compliance for the vast
majority of the profession - slamming the magic pizza box in a rack is
more preferable than talking to developers. in many cases the biggest
barrier to getting better security in companies is the so-called
information security group. it has very little to do with technology,
its a people problem. -gp Kenneth Van Wyk wrote: Happy
PCI-DSS 6.6 day, everyone. (Wow, that's a sentence you don't hear
often.) http://www.internetnews.com/ec-news/article.php/3755916
In talking with my customers over the past several months, I always
find it interesting that the vast majority would sooner have root canal
than submit their source code to anyone for external review. I'm betting
PCI 6.6 has been a boon for the web application firewall (WAF) world.
Cheers, Ken - Kenneth R. van
Wyk SC-L Moderator KRvW Associates, LLC http://www.KRvW.com
___ Secure Coding
mailing list (SC-L) SC-L@securecoding.org List information,
subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List
charter available at - http://www.securecoding.org/list/charter.php SC-L
is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___
___ Secure Coding mailing list
(SC-L) SC-L@securecoding.org List information, subscriptions, etc -
http://krvw.com/mailman/listinfo/sc-l List charter
