The day of reckoning is upon us. The Payment Card Industry's Data Security Standard (PCI DSS) deadline for Tier 1 companies -- those that process more than 6 million transactions per year -- was September 30. Tier 2 retailers -- between one million and 6 million transactions per year -- need to be compliant by December 31.
The deadlines should come as no surprise; they've been looming for a long time. The first set of audits and examinations has already happened. I'd be more than a bit surprised if Tier 1 or Tier 2 merchants are just starting to think about PCI now. But stranger things have happened and I know better than to assume that organizations are doing the right thing. With ramifications for noncompliance ranging from fines to losing the ability to accept credit card payments, however, no merchant can afford to ignore PCI.
So let's consider a security manager new to the job with PCI looming. Perhaps the company is a Tier 3 merchant, so the deadline is still out there and it hasn't made enough progress. What should a security professional do? Panic? Pray? Plead for mercy when the examiner shows up? Blame the predecessor? All of the above may help, but what's most critical is making progress on parts of the DSS that can be implemented quickly.
First, pick off the low-hanging fruit such as Requirement 1, which is to have a firewall to protect cardholder data, and Requirement 5, which mandates the use and updating of antivirus software. Organizations should already have firewalls and antivirus, so it's just a matter of documenting them.
What other requirements are fairly easy? Requirement 2, which is to change default passwords and other security parameters. It may be time consuming (especially if there are a lot of devices to manage), but there is nothing novel or difficult about logging into a device and changing the password. Also take a look at Requirement 4, which requires encryption to protect cardholder data that is sent over open networ
To continue reading for free, register below or login
To read more you must become a member of SearchSecurity.com
ks. Simply using SSL allows an organization to check the box on that requirement.
After picking off the simplest stuff, address the requirements that can be difficult or nebulous, like Requirement 3 to protect stored cardholder data, or Requirement 6 to develop and maintain secure systems and applications. The reality is that these tricky requirements can't be done overnight, so each enterprise needs to at least have a plan for how it will address them.
In this plan, lay out a phased approach that shows an understanding of what needs to be done. Maybe protecting cardholder data involves implementing a database-monitoring gateway or activating outbound filtering on an email security gateway. It doesn't matter what the plan is, as long as there is a plan.
With some of the more nebulous PCI requirements (like protecting cardholder data), there are lots of ways to address them. The challenge is to find the best method for your specific organization. Present the plan similar to any funding request directed at senior management. Cover what problem is being solved, how is it going to be solved, and when it will it be done. There are lots of ways to make this hard, especially by going through many levels of design and architecture. Candidly, it's overkill. The auditors want to know the requirement is understood and there is a plan to address it.
When the examiner shows up, it pays to be honest. There are a lot of new PCI assessors in the field, but if the examiner is experienced, it won't be possible to fool him or her. If an organization has a lot of work to do toward reaching compliance, it should be upfront about that. Request that the auditor be specific about what controls he or she suggests be implemented in order to achieve compliance. Also ask for some ideas on what to prioritize.
Examiners don't expect complete compliance, even if the deadline has passed. A security manager can get one "mulligan," or do over, but only one. The next time the auditor shows up, be ready. That's why it's critical to get as much detail as possible about what the auditor thinks needs to be done, take that to the boardroom and get the money needed to do the job. Or start looking for another one.
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. Rothman is also SearchSecurity.com's expert-in-residence on information security management. 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.
