Friday, May 9, 2008

PCI Compliance and Web applications: Another perspective

Ordinarily, I agree with Michael Cobb's advice and tips at searchsecurity.com. May 8, however, I read his PCI compliance and Web applications: Code review or firewalls? security tip, and disagree with him on a few different points. So much so, in fact, that I have to get it off my chest.

Let's begin with the assertion that "emerging threats" is the main reason to choose a Web Application Firewall (WAF) over some form of code review:
The main reason for an application firewall is that it will, if properly supported, actively protect against emerging threats, something a one-time code review will not.
Wrong. First, that's a BIG if. Second, everyone involved in securing, or breaking, web applications knows that virtually all emerging web application threats are simply new vectors of attack based upon the same old fundamental problems, 1) poor, or complete lack of input or boundary validation 2) poor, or complete lack of output encoding 3) application ids with too many privileges 4) terrible access control, and so on.


If you implement a secure development lifecycle, targeting the fundamentals of application security, not only do you shutdown today's threats, but emerging threats as well. Let's look at AJAX as an example. Attacks against AJAX are nothing new - they are the same, rehashed attacks we've seen for years, but appear amplified because more logic and functionality is pushed to the client. In other words, developers are making the same mistakes - the amplification comes from the fact that there's more opportunity to create those same mistakes.

A final note about the emerging threat position; WAFs are complex devices, and the organizations deploying them will do so in baby steps, and many will never implement the strictest control capabilities for fear of denying service to legitimate customers. Unfortunately, it's this complex functionality that would actually have the ability to stop a completely new attack vector. Hence, few organizations will benefit from some WAF's ability to stop true 0-day attacks.

Next, I'm curious to know where that pricing came from. If you didn't RTA, here's the relevant quote:
Pricing varies between brands but you could easily be looking at a purchase cost of around $5,000 for something that will handle around 900 MB of throughput, rising to around $8,000 for 2 gigabites per second (Gbps).
I conducted an RFP for my last employer in 2007, and have continued research on WAFs since then. The best I've been able to come up with recently are entry-level offerings from Breach, in the form of the ModSecurity appliance for $12,995, and Barracuda Networks' Web Site Firewall, which, at the low end, can handle a reported 1-5 servers, or 25mbps for $4999. Both vendors have high-end devices as well, starting around $24,995 for Breach WebDefend and $27,550 for Barracuda Networks' Web Application Controller (don't even bring up the $9,500 model - 100mbps is not high-end). Now, add in high-availability requirements, maintenance cost, and the cost to hire or train someone to manage them. Oh, and give me a break with the "let the current firewall guys do it." WAFs are not firewalls, and configuring a WAF and analyzing its output is nothing like managing a firewall.

Before moving on, I'll mention that Mr. Cobb does elude to the fact that WAFs require constant care and feeding, thank you. Imperva would have you believe otherwise, that after the initial period you can "set it and forget it" - yeah, right. Imperva's solution is really good, but nobody in their right mind is going to set and forget a device sitting in front of a web site doing millions in revenue per year.

Now, code reviews - Mr. Cobb mentions that enterprises should already be setting aside funding for reviews during the development process - something else I agree with. Especially, since security in the DLC is mandatory per PCI!!! From the PCI DSS v1.1:
Requirement 6: Develop and maintain secure systems and applications
Section 6.3 of the PCI DSS v1.1 takes it a step further:
Develop software applications based on industry best practices and incorporate information security throughout the software development life cycle.
So, what it boils down to is you must implement secure development best practices in the DLC, and in fact, a secure development lifecycle is a best practice. Furthermore, code reviews are a best practice when inserting security into the DLC. My talk at the upcoming HP Software Universe makes this point: By implementing a secure development lifecycle, thereby releasing secure web applications, you gain compliance implicitly, and in fact, operate within the true spirit of regulations and standards like the PCI DSS; that is, to create a safe and secure environment in which to conduct business.

There's been a lot of speculation, concern, and questions about how to comply with section 6.6. This might be best supported with yet another quote from Mr. Cobb's article:
Unfortunately, some earlier PCI guidelines gave the impression that internal code reviews would not be acceptable.
This is only true if that's how you interpreted it, and either didn't read or believe sources that cleared this up, such as Dennis Hurst's blog post of March 16, 2007. Of course now we have the Information Supplement: Requirement 6.6 Code Reviews and Application Firewalls Clarified document mentioned in Mr. Cobb's article that not only vets what Dennis has been saying for over a year, but explicitly clarifies the options available to meet the requirement.

In conclusion, you must thoroughly research all of your options. We're not looking at a one size fits all situation here. Discuss section 6.6 compliance with your QSA, or another expert if you're not a L1 merchant, but keep in mind, there's more to section 6 than putting a band-aid on your insecure applications, ala a WAF. A WAF might prevent some of the attacks in the OWASP Top 10 from succeeding (What about access control, priv escalation, session handling, etc.?), but what if the WAF fails open, exposing your site, and its vulnerabilities, to the masses? A WAF can't lift a finger to help you develop secure applications, and an application behind one with SQLi and XSS defects is not a secure application. A WAF simply mitigates the threat and likelihood of an attack succeeding.

The PCI SSC has stated, as I do when asked, that ideally you should do both: deploy a WAF and do code reviews, either
with web vulnerability scanners, or through source code analysis (manual or automated). In reality, however, this may not practical for small organizations, so there's going to be some risk analysis involved. Good luck! June 30 is close, and the clock is ticking...