Critique: PCI DSS v1.2

So, I posted this to my corporate blog as well, but wanted to save myself a copy in case it isn't received very well over there. Enjoy.

PCI DSS version 1.2 will be available for general use tomorrow, October 1. The SSC has standardized on a 24-month cycle for revisions and new versions, so other than the potential for additional supplements or clarifying documents, this is it for the next couple of years. The summary of changes document is here, and the FAQ for the summary of changes is here. Obviously you can read the actual document yourselves, so I’m not going to reproduce it here verbatim. However, I will happily critique the changes.

As usual, I’ll be candid with you: I’m very disappointed in the SSC for what amounts to trivial changes that fall far short of improving the standard in a meaningful way. Let’s have a look at the finished product.

Requirement 1 – A much needed change related to the review of firewall rules. After heavy lobbying from participating organizations, the required review frequency has been reduced to every six months, down from once per quarter.

Requirement 2 – meh. Ok, they removed references to WEP, but seriously, if any merchant is still using WEP after the TJ Max debacle, you deserve to get owned.
Requirement 3 – meh.

Requirement 4 – SAY WHAT?! Quote, “No new WEP implementations allowed after March 31, 2009” and “current implementations must be discontinued by June 30, 2010.” Sadly, those are NOT typos. Merchants, note my comment regarding Requirement 2, regardless of what the SSC is saying.

Requirement 5 – What exactly does “AV must address all known types of malicious software” mean?  Do these guys even use anti-virus software?! Apparently not, else they would know the major players often need a miracle just to detect the most prevalent malware out there right now, much less address it (XP Antivirus 2008 anyone?).

Requirement 6 – whoop-dee-do. Web Application Security deserved the most attention out of this revision, hands down. Epic fail for the SSC. Edit: Removed the bashing of the SSC for not changing the compliance requirement to the latest OWASP Top 10 version. As someone pointed out in the comments of my corporate blog, the new assessment procedures list "the latest OWASP Top 10" as the guideline for compliance, and specifically list the 2007 categories. That said, they still fail in the area of more meaningful requirements in arguably the least secure area of enterprises.

Requirement 7 – meh.

Requirement 8 – meh.

Requirement 9 – meh.

Requirement 10 – duh.

Requirement 11 – Ok, we got some decent clarification here. Believe it or not, there were some organizations out there that thought they could get away with “some cheap, young hackers” doing their quarterly assessments. Names withheld to protect the guilty and clueless. The SSC also clarified that internal, as well as external penetration tests are required, and that any qualified consultant or firm can perform the tests – they do not have to be a QSA or ASV. This is great news for my Indy brothas and sistas out there (sup Fish!). Note, HP is an ASV, so this hasn’t ever been an issue for us.

Requirement 12 – meh overall, but I realize this was needed to combat the “check in the box” mentality of a lot of companies out there. Now, other than the specific examples cited with each requirement, there is something the next version of the DSS sorely needed – laboratory and/or hands-on verification of requirement compliance, a la what they started with the PA-DSS. All QSAs and designated SAQ persons are not created equal, and they need some help. There are a lot of shenanigans going on out there that could be eliminated with a detailed checklist of what to look for when validating the compliance of technical solutions – e.g. Web Application Firewalls. I wanted to see specific items validated such as a policy review, logs (look for proof of inspection and blocks), and configuration (is it in monitor, learn, or block mode?).

Finally, I’d like to see a technical QSA designation – someone that has a system integrator’s knowledge of networks, systems, and the policy and processes necessary to truly comply with the spirit of the DSS and secure our Enterprises. In conclusion, I hope the authors of version 1.2 weren’t getting paid, but if they were, the SSC needs to get their money back.

PCI Knowledgebase: Learning from Web Application Security Mistakes

On August 13th, I produced a webinar with the PCI Knowledgebase's founder, David Taylor. We talked about the web application security-specific requirements of the PCI DSS, common misconceptions with these requirements, practical advice on how to comply with them, lower your overall risk, and how to improve application security in your organization to the point that you won't fear any regulation, standard, or law.

After registering (free) on the site, you can download Learning from Web Application Security Mistakes here.

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