May
IT Consultancy, Bedfordshire
Are you compliant with the PCI standards?
In September 2006, the Payment Card Industry (PCI) Security Standards Council released version 1.1 of a document entitled ‘PCI Data Security Standards’, generally referred to as the ‘PCI DSS’. The PCI Security Standards Council was formed by the leading payment brands, including Visa and Mastercard, specifically to develop the Data Security Standards. This was in response to rising fraud within the industry, and the standards were designed to ensure organisations adopt consistent security measures to proactively protect customer account data. The standards will be updated in response to new payment security risks, as they are identified.
Adherence to these standards became a mandated requirement in July 2007 for all organisations handling credit and debit card transactions, or providing systems or services that do. However, many companies are still not compliant and nonconformity could result in hefty fines and possible withdrawal of payment services. The largest merchants, those handling over 6 million transactions a year, are expected to be compliant first, with the smaller merchants following along later, working towards a deadline of December 2008. Companies offering systems or services that handle credit and debit card data will also need to comply or face going out of business.
The PCI requirements, like many standards, are just a framework and so by their nature are quite generic. This can make it difficult to pin down exactly how they should apply to your business, your systems and your processes. Anyone who has implemented an ISO standard, such as ISO 9001, will be all too familiar with this problem.
The good news, of course, about a framework such as this is that it’s prescriptive about what needs to be done but not always about how it should be done, so allows you some leeway to implement the approach in a manner that suits your business and the way you like to operate.
So what are these standards really about?
The key information that the standards are interested in is known as ‘cardholder data’. The PCI define cardholder data as the ‘full magnetic stripe or the PAN (card number) plus any of the following: cardholder name, expiration date and service code (often referred to as the security code on the magnetic strip)’. In fact, however, many of the requirements deal with general industry best practice in connection with system and data security and have nothing directly to do with card data at all. For example, ensuring that each user of your system has a unique user id and password, and that their password is not one that can be easily guessed. If your system security policy is already top-notch, then you’ll be a long way there already. If not, you may have a lot of work to do.
Let’s have a look into the essence of what these standards are really getting at. There are 12 main requirements which are grouped under 6 main headings. Here are the headings with my simple explanation of the requirements underneath each:
1. “Build and Maintain a Secure Network”
Ensure you have a secure network, including firewall protection and the need for passwords to gain access.
2. “Protect Cardholder Data”
Protect cardholder data wherever it is stored, and even when being transmitted outside your secure network.
3. “Maintain a Vulnerability Management Programme”
Ensure your systems are protected against unauthorised access, including using up-to-date anti-virus software.
4. “Implement Strong Access Control Measures”
Install and maintain strict controls around system access, even access to the physical bits of hardware, ensuring only those people who actually need to see cardholder data have access to it.
5. “Regularly Monitor and Test Networks”
Monitor and track access to systems and, more specifically, cardholder data within systems. Also, regularly test the security systems that have been put in place.
6. “Maintain an Information Security Policy”
Implement and maintain a policy for the security of information in your business
A common misconception about the standards is that they only apply to credit or debit card numbers. In fact, whilst only the card numbers themselves need to be protected using encryption (meaning converted into something incomprehensible using a ‘key’, so that only a holder of the matching key can convert it back to its original form), information such as expiry dates, issue numbers, customer names, addresses, etc., all need to be carefully protected according to these standards.
The 12 requirements under these headings are then further broken down into a total of 64 smaller requirements. I don’t propose to list them all out here - suffice to say that the PCI council have been very thorough in covering a lot of areas that could result in a security breach, leading to card fraud. Interestingly, as you can see from these 6 headings, only number 2 is actually concerned directly with what state cardholder information is in inside your business. The others are all to do with stopping any unauthorised or unscrupulous activity that might compromise that information.
Is everyone affected in the same way?
The PCI have categorised merchants into 4 levels, each with their own set of compliance criteria, based on the annual number of credit/debit card transactions that your business handles, as follows:
Level 1 - over 6m transactions, or anyone whose data has previously been compromised. An annual onsite security audit and a quarterly network security scan are necessary.
Level 2 - between 1m and 6m transactions. An annual self-assessment questionnaire and a quarterly network scan are necessary.
Level 3 - 20k to 1m transactions. An annual self-assessment questionnaire and a quarterly network scan are necessary.
Level 4 - everyone else. An annual self-assessment questionnaire and an annual network scan are necessary (although this is under some debate and may be lessened in the future).
What will happen if I don’t comply?
In theory, each payment brand will take the action that it feels is appropriate (and achievable) to enforce these standards. At the moment, there isn’t a set fine, and the PCI council doesn’t appear to have any plans to create one. It’s likely that each brand will want different evidence to show you are compliant and they may opt to withdraw your payment services, in extreme cases.
All the original deadlines that were set for compliance have now all passed, so they’ll probably be looking to set a date based on factors such as your level and the importance of your business. Your acquiring bank should be the best place to start to find out what date you need to work to and what penalties you can expect to pay if you’re not compliant on time.
How do I go about implementing these standards into my business?
So, what do you need to do to implement these standards into your business? And how can you ensure that you are compliant with a standard, if it’s so generic?
Firstly, it’s important to review each of the standards carefully and assess how it applies to you and to your business. You may already have some of these things covered, so it’s a good idea to find those straight away and tick them off the to-do list. This should leave you feeling slightly happier and with a more focussed list of work to be done.
A number of the requirements are things which are going to need a business process change rather than a system change. For example, users of a system being forced to regularly change their passwords. You’ll be able to confirm whether your systems are capable of this, or change them to make it so, but it’s not quite so simple to establish whether your people are actually using the facility. So, identify the standards that cover a business process in this way and think about how you’ll implement them, and how you’ll confirm that they are being adhered to.
You’ll also need to think carefully about where your credit and debit card data is being captured, stored and sent. Ideally, it should remain either hidden or encrypted at all times, but of course this just isn’t practical. In order to actually use the information, it will need to be decrypted and visible. However, it will need to be re-encrypted again once it’s been used in order for it to remain safe, so you’ll have to find these scenarios as soon as possible and work out what you are going to do.
It’s important to remember that any form of recording or transmission is covered by these standards, so emails, forms, and letters are just as much of a security risk as computer systems. Make sure you know about the use of these other methods in your business and are doing something to control and audit their use.
The standards call for you to protect cardholder data from prying eyes and not to expose it to the risk of being stolen, even by your support staff. This is harder than it sounds! Usually, there are backdoors that allow support staff to view and even amend data. This won’t be allowed in the future, in all but the most extreme cases and, even then, use of this facility has to be carefully controlled and audited.
Think carefully about your support processes because these changes could have an impact on your people’s ability to handle certain transactions in your business successfully. For example, are there any regular processes in your business that involve someone either looking at or manipulating card data? If so, you’ll need to find these and start working out an alternative approach to handling them.
What about processes that rely on the use of people’s card details? For example, do you process credit card chargebacks? These often start with the need to search a system using the customer’s credit card number. This might not work once card numbers have all been encrypted on your system! Check these situations out carefully.
OK, I’ve started work on this but what will all this change mean?
Let’s have a look at the type of testing need all this will create. At the end of last year we completed a testing project for one of our customers to help them ensure that their system met the requirements for the PCI DSS.
We undertook the work in 4 streams:
1. We needed to prove that the changes to their system achieved what they were supposed to have done. In essence, were they doing what it said on the tin?
2. Then we had to confirm that the changes had led to the requirements under the PCI DSS being either met or exceeded.
3. Also, it was important for us to confirm that everything else still worked correctly on their system, i.e. that the changes hadn’t broken any of the important processes they already used.
4. Lastly, we had to check that other changes they had had to accept as part of the upgrade were also working correctly. Their system is essentially a package, so some dependant updates were also provided by the software provider to make the PCI changes work. This issue may or may not affect you.
After we had completed our testing successfully, we handed everything back to our customer so they could start their own testing, to make sure everything was fit for purpose for their business and their business processes.
I can’t stress strongly enough that all the changes you are going to need to make, whether they are to your business processes or your systems, are going to need to be tested thoroughly. Don’t just implement them and expect them to work.
Hopefully, that gives you something of a flavour as to how complex testing something like this can be, and what all this change is going to mean to you. The bigger companies are spending millions of pounds getting this right.
So what do I do next?
The best place to start is to download the standards themselves and the Self-Assessment Questionnaire from the PCI website at www.pcisecuritystandards.org. You also might also want to contact a PCI Approved Scanning Vendor (ASV) and get them to come in and assess how much work you’ve got to do.
Also, if you haven’t already done so, I’d talk to your acquiring bank as soon as possible and confirm with them what level merchant you are. Oh, and don’t forget to ask them that all important question about when you need to be compliant by, and how much it will cost you if you’re not ready by then!
Ultimately, this could be a complicated and costly process. But, it’s worth remembering that it’s an important investment in risk reduction. And, according to statistics from Visa Europe released in January this year, 84% of customers want to shop with merchants who are security market leaders and 75% say they would not shop at a store that had suffered a security breach.
Derrick Cameron is Managing Director of Eximium Ltd, who specialise in helping businesses use their IT to solve their business headaches. For further information or advice on the use of IT in your business, please see www.eximium.net or call 01582 635 078.
This entry was posted on Wednesday, May 28th, 2008 at 11:24 am and is filed under Articles, Business Advice, Data Security, IT Advice, IT Consultancy . You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.
June 15th, 2008 at 3:59 am
Hey, I was looking around for a while searching for information on security standards and I happened upon this site and your post regarding PCI Standards, I will definitely add this to my information security standard bookmarks!
June 16th, 2008 at 11:11 am
I’m very pleased that you found the article informative and that you plan to visit us again.