RE: PCI 6.6 Questions

Hi,

Take a look at this list:
https://www.pcisecuritystandards.org/pdfs/asv_report.ht
ml , which
contains ASVs.

Thanks,
-Ory

 

> -----Original Message-----
> From: Raymond Forbes [mailto:rforbese-stalkers.net] 
> Sent: Friday, May 25, 2007 2:17 AM
> To: Bubba Gump
> Cc: webappsec OWASP; WASC Forum; webappsecsecurityfocus.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
> > Webappseclists.owasp.org
> > ht
tps://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://ww
w.webappsec.org/lists/websecurity/
> 
> Subscribe via RSS: 
> http://w
ww.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/whi
tepapers.aspx?id=701500000008rSe
------------------------------------------------------------
--------------

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 <osegalwatchfire.com> wrote:
> Hi,
>
> Take a look at this list:
> https://www.pcisecuritystandards.org/pdfs/asv_report.ht
ml , which
> contains ASVs.
>
> Thanks,
> -Ory
>
>
>
> > -----Original Message-----
> > From: Raymond Forbes [mailto:rforbese-stalkers.net]
> > Sent: Friday, May 25, 2007 2:17 AM
> > To: Bubba Gump
> > Cc: webappsec OWASP; WASC Forum;
webappsecsecurityfocus.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
> > > Webappseclists.owasp.org
> > > ht
tps://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://ww
w.webappsec.org/lists/websecurity/
> >
> > Subscribe via RSS:
> > http://w
ww.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://ww
w.webappsec.org/lists/websecurity/
>
> Subscribe via RSS:
> http://w
ww.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/whi
tepapers.aspx?id=701500000008rSe
------------------------------------------------------------
--------------

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 <davefddavewking.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 <osegalwatchfire.com> wrote:
> >> Hi,
> >>
> >> Take a look at this list:
> >> https://www.pcisecuritystandards.org/pdfs/asv_report.ht
ml , which
> >> contains ASVs.
> >>
> >> Thanks,
> >> -Ory
> >>
> >>
> >>
> >> > -----Original Message-----
> >> > From: Raymond Forbes [mailto:rforbese-stalkers.net]
> >> > Sent: Friday, May 25, 2007 2:17 AM
> >> > To: Bubba Gump
> >> > Cc: webappsec OWASP; WASC Forum;
webappsecsecurityfocus.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
> >> > > Webappseclists.owasp.org
> >> > > ht
tps://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://ww
w.webappsec.org/lists/websecurity/
> >> >
> >> > Subscribe via RSS:
> >> > http://w
ww.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://ww
w.webappsec.org/lists/websecurity/
> >>
> >> Subscribe via RSS:
> >> http://w
ww.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://ww
w.webappsec.org/lists/websecurity/
> >
> > Subscribe via RSS: http://w
ww.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/whi
tepapers.aspx?id=701500000008rSe
------------------------------------------------------------
--------------