When a new regulation hits the street, you can usually see the security channel circling around like a pack of hungry vultures ready to rip into some compliance budget like it's fresh road kill. Graphic analogies aside, the Payment Card Industry Data Security Standard (PCI DSS) has turned into quite a bonanza for security partners. Besides being applicable to a wider audience of customers than HIPAA and Sarbanes-Oxley, PCI is also far more specific about which controls need to be implemented and why. However, that doesn't entirely eliminate confusion related to PCI compliance.
Nothing in PCI has caused more angst among customers than requirement 6: Develop and maintain secure systems and applications. Talk about trying to boil the ocean! But if you deconstruct the requirement, it's largely about doing some secure configuration and patching on servers housing credit card data, and also using secure development processes to reduce the likelihood that data will be compromised via an application.
Finally, requirement 6.6 specifies that Web applications either need to be reviewed by an application security specialist or an application firewall needs to be implemented in front of the applications. Most customers hate either/or questions because they require them to think and make a decision. To help in this regard, the PCI Security Standards Council issued a clarification, which provided more specifics about exactly what a code review means and what functions are required in a Web application firewall.
So now we know more about what the standards entail, but that still doesn't help the customer figure out which option is best for them. That's where you (as the security channel partner) come into play. Remember customers look to you to provide the perspective and guidance that will keep them secure. So let's deconstruct the issues and think about a framework for walking customers through this decision.
Compliance is not security
First and foremost, let's get rid of specific anticompliance biases. I've long said that being secure will most likely result in customers being compliant. But the converse is absolutely not true. Just think of Hannaford Bros., which was allegedly PCI-compliant and was still compromised to the tune of millions of stolen identities. So we always need to focus on making the customer's environment more secure. The fact that we do it within the context of a compliance mandate is beside the point.
Next, we need to analyze what actually needs to be protected. That means you should work with the customer to determine exactly where their credit card data is. PCI only cares about credit card data, so don't spend a lot of time worrying about other stuff -- that's what follow-up projects are for. Once the data stores are isolated, it's a matter of understanding which applications have access to that data. This gives you the universe of applications that need to be protected.
Two divergent paths
PCI 6.6 now allows either a code review or an application firewall to be deployed. The reality is, the best choice is both, but this usually isn't practical -- especially with the specter of an audit creating urgency at all levels of the initiative.
The first path is to implement a Web application firewall (WAF). You likely have one of these on your line card already. Folks like Imperva, Breach Security and F5 (among others) offer these devices. They block common attacks like SQL injection and cross-site scripting. The WAF tends to be the path of least resistance; the client plugs in the box and they're done, where the code review requires new processes.
To be clear, a WAF is not a panacea to solve all application maladies, especially not business logic flaws or advanced attacks like cross-site request forgery -- not by a long shot. But it will prevent many of the attacks that are commonly used by unsophisticated hackers.
The second path is to do a code review, which means to use either application scanners or source code analyzers. You could do this manually, but with the millions of lines of code in a typical organization, that's not really practical. If you go with a Web scanner, then you are looking at tools from folks like IBM, HP and Cenzic. These tools identify issues but don't do anything to remediate. You'll need to work with the developers to close the holes.
Similarly, source code analyzers from companies like Fortify, Ounce Labs, Coverity and Klocwork analyze code while it's being developed. The sooner in the development process that these issues are addressed, the cheaper it is for the customer, which is why there is a lot of interest in source code analysis right now.
I recommend that most companies start with a WAF and then address the bigger issues around the development process. Yes, this is not perfect because WAFs are not perfect. No piece of equipment is. But when something needs to be deployed and most applications tend to be as secure as Swiss cheese, the WAF can buy your customers some time.
Know the deep water of PCI compliance
Before I send you on your merry way to start monetizing PCI 6.6, let me remind you that applications are different than networks. Implementing a WAF is significantly different than plugging in a firewall or an IPS. So if your specialty is network security, you can get into deep water pretty quickly when dealing with applications.
It may make sense to partner with local resellers that have specific application security expertise, while you are building your own capabilities. The opportunity is right here, right now -- and it's unlikely your customers will wait until you are ready to service them. That's not an option.
Also take a look into some training classes to start educating your technical folks about application security topics. Companies like Aspect Security and Security Innovation have well-regarded training programs and service offerings to help kick-start your efforts.
Consider it an investment, and a good one at that. With more than 75% of attacks being launched directly at the application layer, it makes sense to start thinking about how you can protect your customers more effectively.
About the author
Mike Rothman is president and principal analyst of Security Incite, an industry analyst firm in Atlanta, and the author of The Pragmatic CSO: 12 Steps to Being a Security Master. Read his blog at http://blog.securityincite.com, or reach him via email at mike.rothman (at) securityincite (dot) com.
