Channel Checklist: Top five PCI compliance mistakes and how to avoid them

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 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 and not allowing the customer to fall into a "compliance checkbox" mentality.

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

To read more you must become a member of SearchSecurityChannel.com

As an existing member of the TechTarget network please activate your SearchSecurityChannel.com account 

By joining SearchSecurityChannel.com you agree to receive email updates from the TechTarget network of sites, including updates on new content, magazine or event notifications, new site launches and market research surveys. Please verify all information and selections above. You may unsubscribe at any time from one or more of the services you have selected by editing your profile or unsubscribing via email.

TechTarget cares about your privacy. Read our Privacy Policy

Digg This!     StumbleUpon     Del.icio.us

RELATED CONTENT Regulatory Compliance Red Flags Rules compliance: Are your customers informed? PCI compliance guide: A resource for solution providers PCI DSS pre-assessment services: Prelude to a QSA The impact of PCI compliance on the channel Compliance drives opportunities for security integrators How to turn the HIPAA compliance changes into opportunities Data protection services offer revenue for security solution providers Agiliance and McAfee partner for better governance, risk and compliance services SonicWall announces partnership with Western NRG Building a framework-based compliance program PCI DSS compliance Web application security best practices: Tips on implementation Application security expertise a plus when offering WAF services PCI wireless guidelines translate to dollars for VARs PCI compliance guide: A resource for solution providers PCI DSS pre-assessment services: Prelude to a QSA The impact of PCI compliance on the channel The importance of PCI compliance PCI compliance services FAQ PCI compliance: Web application firewall vs. code review How will the planned changes in PCI-DSS affect the channel?

RELATED RESOURCES 2020software.com, trial software downloads for accounting software, ERP software, CRM software and business software systems Search Bitpipe.com for the latest white papers and business webcasts Whatis.com, the online computer dictionary

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