Re: [WEB SECURITY] Re: [Webappsec] PCI 6.6 Questions

["James Landis" <jcl24 () cornell edu>]

The qualified ASV list below is not valid for the new PCI reqs; there
is a separate certification process to make the list for source
review.

There has already been a ton of great discussion on WAF vs. source
assessment, but there are a few pieces missing I'd like to throw on
the fire:

1) Expect the PCI reqs to say AND instead of OR at some point down the
road; an investment in either category is not likely to be wasted
unless of course it is spent with a vendor/consultant that is not
giving you what you paid for.

2) WAFs can do a lot of good things at runtime that even perfectly
secure static code can't; I've been harping on the "Web Application
IPS" angle for a while now, especially with behavior-based signatures.
No one is seriously playing in this space, but it's the natural
progression, just as things evolved from FW to IDS to IPS on the
network side. IPS at the app layer has a number of other advantages
compared to NIPS and significant security improvement can be gained
very quickly with a minimal set of rules. $billions to the first
player to own this market - I'd recommend you to every one of my
customers.

-j

On 5/25/07, Ory Segal <osegal () watchfire com> wrote:
> Hi,
>
> Take a look at this list:
> https://www.pcisecuritystandards.org/pdfs/asv_report.html , which
> contains ASVs.
>
> Thanks,
> -Ory
>
>
>
> > -----Original Message-----
> > From: Raymond Forbes [mailto:rforbes () e-stalkers net]
> > Sent: Friday, May 25, 2007 2:17 AM
> > To: Bubba Gump
> > Cc: webappsec @OWASP; WASC Forum; webappsec () securityfocus com
> > Subject: [WEB SECURITY] Re: [Webappsec] PCI 6.6 Questions
> >
> > There are some interesting questions in there....
> >
> > 1) that really depends on the org and the size of your
> > infrastructure.
> > Web App Firewalls seem ok if you aren't pushing too much
> > traffic and are willing to do spend the time maintaining it.
> > Most of them seem to have some level of heuristics but I
> > can't imagine there is no administration necessary.  On the
> > other side, however, having a 3rd party audit your code can
> > be really expensive, not even counting the time it takes to
> > remediate all the problems found.
> >
> > 2)That is still a controversial question.  One of the SPI
> > guys exchange mailed with the PCI committee who agreed the
> > SPI pen test tool was sufficient.  I have talked to a couple
> > of auditors who do not agree.
> >  From what I understand this is still being hashed out and we
> > should know better by the end of the summer.
> >
> > 3) Personally, I am looking at that as "in scope" code.
> > Which means, only apps that deal with credit card data.
> >
> > 4) That hasn't really been defined.  I am guessing we will
> > get further clarification by the end of the summer or when
> > the new standard is released.  It is always possible that it
> > will be at the auditors discretion.
> >
> > -Raymond
> >
> >
> > Bubba Gump wrote:
> > > I have a couple of questions about PCI section 6.6.  It states that
> > > companies will need to do one of the following two things:
> > >
> > > Having all custom application code reviewed for common
> > vulnerabilities
> > > by an organization that specializes in application security
> > >
> > > or
> > >
> > > Installing an application layer firewall in front of web-facing
> > > applications.
> > >
> > > I have the following questions about this requirement:
> > >
> > > 1.  Assuming a company only has enough resources to do one or the
> > > other, which would you recommend, and why?  Which option is the
> > > easier/cheaper route to compliance?  Which is likely to lead to the
> > > most real improvement in security?
> > >
> > > 2.  Would hiring a company to do black-box scanning and
> > testing of our
> > > websites satisfy the first option?  Or would we actually
> > need to have
> > > the company go through our code line by line and review it for
> > > security defects?
> > >
> > > 3.  Does "all custom application code" mean all of our credit card
> > > processing code, or every line of code behind every one of our
> > > Internet-facing websites?
> > >
> > > 4.  If we go with the code review option and the company
> > that we hire
> > > finds a bunch of issues with our code, are we required by
> > PCI to fix
> > > all of the issues, just certain types of issues, or none of
> > the issues?
> > >
> > > Thanks,
> > > Bubba
> > >
> > ----------------------------------------------------------------------
> > > --
> > >
> > > _______________________________________________
> > > Webappsec mailing list
> > > Webappsec () lists owasp org
> > > https://lists.owasp.org/mailman/listinfo/webappsec
> > >
> >
> >
> > --------------------------------------------------------------
> > --------------
> > Join us on IRC: irc.freenode.net #webappsec
> >
> > Have a question? Search The Web Security Mailing List Archives:
> > http://www.webappsec.org/lists/websecurity/
> >
> > Subscribe via RSS:
> > http://www.webappsec.org/rss/websecurity.rss [RSS Feed]
> >
> >
>
> ----------------------------------------------------------------------------
> Join us on IRC: irc.freenode.net #webappsec
>
> Have a question? Search The Web Security Mailing List Archives:
> http://www.webappsec.org/lists/websecurity/
>
> Subscribe via RSS:
> http://www.webappsec.org/rss/websecurity.rss [RSS Feed]

-------------------------------------------------------------------------
Sponsored by: Watchfire

The Twelve Most Common Application-level Hack Attacks
Hackers continue to add billions to the cost of doing business online 
despite security executives' efforts to prevent malicious attacks. This 
whitepaper identifies the most common methods of attacks that we have seen, 
and outlines a guideline for developing secure web applications. 
Download today!

https://www.watchfire.com/securearea/whitepapers.aspx?id=701500000008rSe
--------------------------------------------------------------------------