Re: [WEB SECURITY] PCI 6.6 Questions

["Ryan Barnett" <rcbarnett () gmail com>]

Disclaimer: I work for a WAF vendor.  Although I still believe my
remarks are unbiased.  I have just recently been participating on PCI
panel discussions at the SecureWorld conferences and all of your
questions were brought up by the audience.  Comments inline below.

--
Ryan C. Barnett
ModSecurity Community Manager
Breach Security: Director of Application Security Training
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 5/24/07, Bubba Gump <bubbagump123 () gmail com> 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?

I would go with the WAF.  I know, I know, so much for my disclaimer
right?  Here is why - first of all, a big gripe that I have with the
PCI language is that they are not focusing on actual mitigation with
some of these requirements.  A source code review and a vulnerability
scan do not do anything to actually mitigate the vulnerabilities.
They only identify them.  Whereas a WAF actually provides immediate,
persistent protection.  Unfortunately, some organizations only do code
reviews once a year to pass the PCI audit and not because it is part
of their normal SDLC.  This means that as soon as the PCI audit is
over, and new code and functionality is added to the webapp, it may
not go through the same rigorous code review.  With a WAF, you just
deploy it once and then it will keep protecting.  If you have a WAF
with learning capabilities, it can also identify when your webapp has
changed and then it can feed back into your change control processes.
>   Which option is the easier/cheaper route to compliance?

Two things to consider here:

1) If you are just looking at requirement 6.6, then putting up a WAF
is easier, quicker and cheaper to do.
2) Also consider that there are two earlier sections (Requirements
6.3.7 and 6.5) that already state that you should be doing code
reviews and fixing identified vulns.  So, the only real difference for
6.6 is that you are having a 3rd party do another code review.
> Which is likely to lead to the most real improvement in security?

Now this is the question that has caused all the controversy with 6.6
- Compliance vs. Security.  A code review and a WAF are not
alternatives, they are complimentary.  Depending on your viewpiont,
you could argue either way as to which one provides a real security
benefit.  A code review is the best way to actually fix the identified
vulnerabilities, period.  The problem is that there a so many
different scenarios where organizations either can't, or for business
reasons, won't update the code.  This is what has lead to more and
more people getting onboard with the WAF Virtual Patching concept.
Now, taking a step back a bit and re-analyzing your question, if you
are interested in a real improvement in overall security for your web
applications there are many features that WAFs have most normal web
app don't such as:

1) Full audit logging.  If you have ever tried to conduct incident
response for a web compromise and all you had were standard common log
format logs, you know what the pain that I am talking about.  WAF are
able to log full request and response data including headers and body
payloads.

2) Identifying, blocking non-input validation attacks.  Most web apps
do a poor job of identifying brute force attacks and attacks aimed at
session management.

3) Information Leakage issues.  WAFs do a great job of protecting
sensitive data from leaving your network.

These are just 3 examples of where a WAF helps your overall security posture.
> 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?

The answer is - maybe...  Check out this Blog post by Jeremiah
Grossman on this topic -
http://jeremiahgrossman.blogspot.com/2007/03/pciv11-sec-66-clarification-leads-to.html
.  You might be able to even have internal staff run the tools,
however the question then becomes what sort of webappsec training have
these people had to know how to use, tune and interpret the results.

> 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?

What is considered in-scope would be any system that the CC data
passed through - so essentially you are talking about all web tiers
(presentation, app and persistent).
> 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?

Well, with regards to fixing vulns identified by vulnerabilty
scanning, organizations must fix all vulns labeled as Critical, Urgent
and HIGH severity.  So, I would guess that the same would go for vulns
identified by a code review.

-------------------------------------------------------------------------
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
--------------------------------------------------------------------------