WebApp Sec mailing list archives

Previous By Date Next
Previous By Thread Next

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

From: "James Landis" <jcl24 () cornell edu>
Date: Fri, 1 Jun 2007 12:17:53 -0400
Dave,
I wish I had official information to point you to, but I don't have
much to go on at this point other than best guesses and industry
rumblings. I suppose I should have been clearer about that in my
original post. It certainly seems natural for us to assume that just
because a company can get on the ASV list for 1.0 (e.g. they can type
some IPs into Qualys) that doesn't mean they're automatically
qualified to review source code or even perform a competent
application run-time assessment per 1.1. However, given the vague
definitions of the standards at this point, I suppose that might not
actually be a fair conclusion.

Given that 1.1 isn't locked in yet, really anything we hear or read
about it should still be treated as speculation.

Again, sorry for the confusion.
-j

On 6/1/07, Dave King <davefd () davewking com> wrote:

James, you say that there is a separate process to make the list for
source review, but I can't find anything about this.  I used to work for
a ASV and I know code review may not be in the scope of their test, but
looking at the requirement as it stands it looks like there is no list
for source review or any process in place to certify companies to be on
a list.  The requirement says:
"Having all custom application code reviewed for common vulnerabilities
by an organization that specializes in application security"

Do you have other information on this?

Thanks,
Dave

James Landis wrote:
> 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]
>>
>>
>
> ----------------------------------------------------------------------------
>
> 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
--------------------------------------------------------------------------
Previous By Date Next
Previous By Thread Next

Current thread: