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_at_e-stalkers.net]
> Sent: Friday, May 25, 2007 2:17 AM
> To: Bubba Gump
> Cc: webappsec @OWASP; WASC Forum; webappsec_at_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_at_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]
>
>
-------------------------------------------------------------------------
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
--------------------------------------------------------------------------
Received on May 25 2007
Intro
