By Mike Rothman, Contributor
Solution provider takeaway: Solution providers will learn how to help customers avoid the top five PCI compliance mistakes.
Everyone wants to talk about regulatory compliance. If your customers have any kind of regulatory oversight, they want to make the auditor go away as quickly as possible with minimal pain. Over the past two years, the Payment Card Industry Data Security Standard (PCI-DSS) has emerged as the most tangible of the regulations by specifying tactics and technologies to protect credit card data. Thus, many customers focus on PCI first because it's less nebulous relative to other regulations.
But if you look hard enough, you'll find folks making pretty sophomoric PCI compliance mistakes -- and you don't really have to look too hard to find PCI compliance errors. The good news is you (as the solution provider) can help them avoid these PCI compliance issues by paying attention using this PCI compliance checklist.
-Mistake #1: Not picking the low hanging fruit
There are a number of PCI aspects that are really Security 101. Yet amazingly enough, many customers don't have even the simplest of defenses in place. Your first job in preparing a customer for a PCI audit is to make sure these simple controls are in place.
- Requirement 1 on the PCI compliance checklist is about having a properly configured firewall. You could get fancy and use a policy reporting tool or run an automated pen testing tool to make sure the right attacks are blocked. But ultimately, just make sure the customer has simple perimeter defenses in place and working.
- As of PCI 1.2, which goes live in October, antivirus (Requirement 5) is now beyond Windows devices. You need to help customers think about how they are going to "prove" viruses are blocked on Linux, Unix and Mac OS X. It's not clear whether customers will be expected to load Symantec on their mainframes, but ultimately, this is a pretty easy box to check.
- Change the default passwords (Requirement 2) on devices like firewalls and servers. Yes, if you use the default password in a wireless access point or any other device, you'll be owned. This isn't hard, but most folks don't think about it.
-Mistake #2: Not scanning applications
A majority of attacks now directly target Web applications, so PCI pays a lot of attention to securing Web applications in Requirement 6. Though customers need to walk before they run, some customers focus on just installing a Web application firewall and figure their work is done. Not so much. The reality is that Web application firewalls and code reviews (the key aspects of Requirement 6.6) are important, but most customers don't know what they don't know. So run a Web application scanner on the Internet-accessible applications and find out how porous those apps are. Then you can figure out how to fix the issues.
-Mistake #3: Not looking from the inside out (data-centric view)
Requirement 3 of PCI-DSS is all about protecting credit card data where it lives -- the database. Many organizations focus on strengthening the perimeter of the network, which I term an "outside-in" perspective. That's great and important, but not sufficient. You also need to work with your customers on looking from the inside out. This means finding all the credit card data and figuring out what systems and/or resources have access to the data. Ensure those attack vectors are protected. It also makes sense to think about database monitoring and vulnerability assessments to keep perspectives on the data, not just the systems.
-Mistake #4: Not capturing enough log data
Logging event and other key data is the focus of Requirement 10. While it's easy to meet this requirement, it's hard to do it right. To meet the spirit of PCI-DSS you just need to gather some event data and keep it for a while. But that won't necessarily help your customers when they have to respond to an incident. I advise customers to log as much as they can, from networks, systems, databases, applications, physical security systems and so on. The more log data, the better.
Make sure the customer is protecting the log data -- this includes storing off- device and cryptographically signing and sequencing -- to make sure it can be used as evidence in a prosecution. The customer can always throw log data out if they don't need it -- hopefully, they won't!
-Mistake #5: Thinking it's done when the auditor leaves
I've saved the worst mistake for last. I see a lot of customers that are just looking to check the box that says "compliance," as opposed to focusing on protecting the credit card data. PCI compliance is not a thing you finish, so when I talk to folks I always caution them against taking an "audit-centric" view of compliance. Many security gurus say security is a process, not a product or an audit, and they are right. The best way you can help your clients and ensure they don't have silly compliance errors is to help them understand the lifecycle of information protection. For better or worse, security people are never finished, and this philosophical adjustment is the best gift you can give to any client.
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. Get more information about the Pragmatic CSO at http://www.pragmaticcso.com, read his blog at http://blog.securityincite.com, or reach him via e-mail at mike.rothman (at) securityincite (dot) com.