Mark Pimperton describes the technical and policy changes made by one UK SMB to comply with the credit card security standard.
In September 2009 my FD forwarded me an email from SecurityMetrics, Inc., an approved security scanning vendor (ASV) appointed by our payment processor (Barclaycard). The email told me we were now obliged to comply with PCI DSS and gave us a deadline about a month hence to sort it out.
"We have to what...?! But we only process a few card payments a year! Surely that security standard stuff is for the big players?"
Apparently not. And as this article shows, criminals are aware that smaller organizations may not be as careful with card data as they ought to be.
Once we started to investigate the implications, we seriously considered whether it was worth the trouble of taking card payments. On balance, though, we decided that although only a few customers pay us this way we should press ahead and see if we could achieve the standard. Merchants of our size aren't subject to on-site assessments, so for us there were two elements to compliance:
- External vulnerability scans
- Self-assessment questionnaire
External vulnerability scans
The standard requires that the network where your payment system lives is externally probed for known security vulnerabilities once a quarter. In our case we process payments via a web site from a standard workstation on our LAN. That means that any external IP address which could theoretically gain access to that workstation has to be scanned. We pay Security Metrics a small annual fee per IP address for these scans, adding up to less than $250 per annum. (The fee also includes the questionnaire, and letting your payment processor know of your compliance (or otherwise!).)
When the first scans ran on our two main public IP addresses they came back with what seemed like a daunting collection of failures. Over the next few weeks we had to take steps such as:
- Disabling SSL v.2 on an Outlook Web Access server
- Installing an SSL certificate and changing port forwarding rules on a second public-facing server
- Adding custom error pages in IIS
- Installing a more secure FTP server
These gradually nailed the failures.
(One oddity you may encounter if you have multiple IP addresses pointing to the same systems is that the scans will produce different results. For example, for our initial scans:
- IP address #1 - Five failures, scores from 5 to 8 (4 or above is a fail)
- IP address #2 - Six failures, scores from 6 to 10
Having taken those steps, we realized we needed to add a third IP address used for a remote access system. The scan for that produced some of the same failures we'd seen for our mail server, but this time the fix wasn't as simple as making registry changes since it involved an SSL VPN appliance. We had to convince the manufacturer to update the firmware to enable the relevant configuration changes.
Voila! Three scans passing and all's well every quarter...until you change something. Recently we added a route in to another IIS server and the next scan promptly failed. More registry changes needed; they're on the list for the next server maintenance.
The Security Metrics web site leads you through the Self Assessment Questionnaire (SAQ), having automatically presented you with the appropriate version based on your initial account setup. (Yes, there are different flavours of the questionnaire.) The first page is about your organization and payment setup, and asks you to confirm eligibility for that version of the questionnaire. You then have to complete 11 sections covering many aspects of your systems and policies. These include:
- Firewall & anti-virus
- How and where you store & transmit cardholder data
- Physical access to data
- Your policies on user education and incident response
- Internal vulnerability scans
The "pass mark" is 100%. If you answer No to any of the questions, you don't comply. You then have to decide what action to take, if any. You might decide, on further consideration, that actually your system or policy does meet the requirement, or that you have plans in place to address weaknesses in the near future and can therefore claim compliance with integrity.
With your external scans passing and your questionnaire completed, you're compliant. If you remain non-compliant for more than a few days, the Security Metrics system starts emailing you automatic reminders until you pass. If your non-compliance continued your payment processor would probably contact you, although I can't tell you when that would happen.
Having jumped through these hoops and breathed a sigh of relief, be prepared to do it all again every year. Our 2010 certification just missed a change in the PCI DSS standard (to version 2.0) so this year's questionnaire was different. A combination of those changes and taking more time over the questionnaire highlighted that we needed to beef up our incident response information for staff. It also reminded me that we never really got to grips with internal vulnerability scanning. (If you read the standard, vulnerability scans mean more than just having anti-virus on your PCs and installing Windows updates. I'm evaluating tools like GFI LanGuard to address this requirement.)
Anyone processing credit card payments must comply with PCI DSS. For merchants of our size, compliance requires some technical measures and a self-assessment questionnaire. The process has forced us to review and improve our system security configuration and policies, making changes which we might never have otherwise made.