[WEB SECURITY] PCI standards regarding appsec to change again?

Ryan Barnett rcbarnett at gmail.com
Tue Jun 27 09:35:35 EDT 2006


Here is another similar story from a few days ago -
http://www.digitaltransactions.net/newsstory.cfm?newsid=620

While changing standards are always hard to follow, this type of amendment
is sorely needed to more accurately cover webapp vulnerabilities.  Arian is
100% correct in that the current requirements for scanning do not even come
close to adequately addressing these web app problems.  Basically, you could
adhere to the PCI standard for the scanning requirement by just running
Nikto againt a site on a quarterly basis.  That is a fine starting point,
but does not address even half of the problems.

There are a few OWASP docs that I have seen that attempt to outline some
recommended improvements to the PCI standard -

http://old.owasp.org/docroot/owasp/misc/PCI-WASS_Strawman_Draft.doc
http://old.owasp.org/docroot/owasp/misc/Security_of_Payment_cards.doc

Also, Jeremiah Grossman pointed me to a very good set of webappsec testing
criteria put forth by Plynt -
http://www.plynt.com/criteria/

Hopefully, these types of criteria will find their way into the new PCI
standard.

While the current PCI standard is winning some praise for its
straight-forward approach, it still lacks teeth because it is not legally
enforceable.  The only leverage here is customer trust, which may not be
enough by itself.  When you look at the news article that Arian referenced,
you will notice that the writer uses passive terms of enforcement.  Look at
this passage -


*Credit card companies Visa and MasterCard will push large merchants to
verify that they do not store magnetic-strip, or "track", data, and will
encourage ISVs to fix payment applications that do store the data, said
Martin Elliott, director of corporate risk and compliance at Visa. *

Wow, they will push and encourage, huh?  The visual image I have is of
someone trying to pull a stubborn donkey by the reins.  There needs to be
consequences if a retailer does not comply.  The problem is that the only
thing that would get the retailers attention would be if Visa/Mastercard
would pull their account and not let the retailer use their cards.  If
CompanyX could only accept Diner's Club cards because they weren't PCI
compliant, that would get their attention.  The Catch-22 here is that
Visa/Mastercard will most likely not take this stance because it would
effect their bottom line.

Oh the Almight Dollar wins again...

-- 
Ryan C. Barnett
Web Application Security Consortium (WASC) Member
CIS Apache Benchmark Project Lead
SANS Instructor, GCIA, GCFA, GCIH, GSNA, GCUX, GSEC
Author: Preventing Web Attacks with Apache


On 6/26/06, Evans, Arian <Arian.Evans at fishnetsecurity.com> wrote:
>
> Another drop in the PCI bit bucket:
>
>
> http://www.infoworld.com/article/06/06/26/79520_26NNpcideadline_1.html?source=NLC-SEC2006-06-26
>
> "The PCI standard will also change to reinforce application security. A
> section on vulnerability
> management will be amended to require merchants to protect against
> application-level attacks such as
> SQL injection and cross-site scripting attacks using application-firewalls
> and, possibly, application
> code scans."
>
> The way I read the current docs, there's no real difference
> between running a network-based vuln scanner that cannot
> even perform form-based auth (and hence having a chance in
> heck of finding post-auth issues), versus doing deep manual
> pen testing or code review.
>
> Perhaps these changes will require app specific controls, or
> lay out what should [must] be "scanned" more clearly.
>
> Arian J. Evans
> FishNet Security
> 913.710.7085 [mobile]
> 816.701.2045 [office]
>
>
>
>
>
>
>
> ----------------------------------------------------------------------------
> The Web Security Mailing List:
> http://www.webappsec.org/lists/websecurity/
>
> The Web Security Mailing List Archives:
> http://www.webappsec.org/lists/websecurity/archive/
> http://www.webappsec.org/rss/websecurity.rss [RSS Feed]
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/attachments/20060627/ed76009f/attachment.html>


More information about the websecurity mailing list