How Card Payments work and PCI DSS

In support of some blog posts I'm planning regarding the Payment Card Industry Data Security Standard (PCI DSS), I thought it would be useful to set out some basic information about how card payments actually work and what the PCI DSS is. This is very high level and is meant as a primer for those who are not familiar with the underlying processes and terminology. This may be particularly useful for small businesses who are just starting out with card payments and the PCI DSS.

How do card payments actually work?

At the very top we have a collection of organisations known as the card schemes. VISA and MasterCard are examples of card schemes but there are plenty of others. Essentially they each operate a network over which card payment transactions can occur and they make money from their members through connection fees and something called interchange. Interchange is a complex set of commission fees paid by members on each card transaction.

Card scheme members go through a certification process to prove that their IT and business systems are able to correctly communicate with the scheme's network and, once approved, they are issued with a range of Bank Identification Numbers (BIN, more on that later), and are permitted to connect and send transaction messages to other members on the network.

The majority of members are also 'issuers'. Issuers are the people who actually produce and issue cards, be they credit, debit, prepaid or other. For the purposes of illustration, I will use HSBC and debit cards as an example. An individual has a personal bank account with HSBC. HSBC will issue that individual with a debit card that they can use with that bank account. The debit card itself has an account number, something called the Primary Account Number or PAN. You and I know this as the card number, typically 16 digits and printed across the middle of the card.

HSBC will issue the card under one of the card schemes (this is a business decision based on the rates offered to them by the scheme, acceptance rates and other factors). For this illustration I have been issued with a VISA card. The PAN assigned to my card is not a random string, it has meaning. The first part of the PAN is allocated from the issuer's BIN range. The BIN range is a range of numbers, typically six digits in length which denote who issued the card and what it's for. The BIN for HSBC VISA debit cards is 465942 (see http://en.wikipedia.org/wiki/List_of_Bank_Identification_Numbers). The rest of the number is arbitrary and up to the issuer but in order to be considered valid it must pass something called the LUHN check which is a simple checksum algorithm. This algorithm is not designed to offer any kind of security, merely to prevent accidental errors with the PAN.

So, this is all great but what does that machine do when I go in a shop and put my card in it (or near it), or that website when I put my details into the form? Enter 'Merchants' and 'Acquirers'. A Merchant is the shop, website or other organisation with which you interact when you make a card payment. They are the ones you are paying money to for the goods or services you are purchasing. How they get the money is down to something called a Merchant Account which is a credit account with an Acquirer. The Acquirer supplies the Merchant with a Merchant Account and a means to take card payments, be this over the Internet in the case of e-commerce or physical terminal equipment in the case of real life. They also take care of communications with card issuers via the card scheme networks. The Acquirer makes money by charging a regular fee for the account as well as commission fees on each transaction.

In the case of many large financial institutions, such as HSBC, they are both an issuer and an acquirer. This has obvious benefits in terms of an overall proposition to customers and in reducing costs.

So, I've just walked into my local shoe shop and picked up a new pair of Converse All Stars and I pull out my HSBC debit card. What actually happens? I insert my card into the slot, enter my PIN and the card machine makes a telephone call, yes, literally a telephone call, to the acquiring bank. To make things interesting let's say that my local shoe shop is "acquired" by Barclays, not HSBC. The Point-of-Sale (POS) terminal dials up Barclaycard Merchant Services (BMS) phone number, makes a network connection with its authorisation systems and begins transmitting authorisation messages.

BMS' systems will derive the BIN from the incoming PAN, work out which issuer and scheme this relates to and send an authorisation over the relevant scheme network to the issuer. In this example therefore, BMS will send an authorisation request over VISA's VISANet to HSBC. HSBC's systems will check the bank account associated with my debit card and decide whether or not to allow payment. In my case I'm in luck, the boss has decided to pay me this month so I can have those Converse. HSBC respond with a success and include something called an Authorisation Code.

BMS tell the terminal that the payment was successful, I breath a sigh of relief, remove my card from the machine, collect my little slip of paper (which has the authorisation code on it along with information about the POS terminal id and amount debited) and head out of the shop.

All done right? Nope. The authorisation is only part of the process. No funds have actually been debited at this point. At the end of the day, the merchant will cash up. Through interaction with the POS terminal they perform an upload of the transactions to the acquirer, via the same phone call mechanism. The acquirer receives the transaction list and proceeds to upload settlement batch files to each of the card schemes requesting payment. The card scheme ensures the delivery of this information to the correct issuer who is then responsible for remitting the funds to the card scheme. The card scheme deducts its interchange and sends the remaining funds to the acquirer. The acquirer deducts their fees and the merchant is then paid the remainder. This generally happens over night.

The overall process is the same for an Internet merchant except that the payment service provider takes care of all the interaction with the acquirer (and in many cases actually is the acquirer), including the transaction upload at the end of the day. Many Internet payment service providers maintain what is called a Master Merchant Agreement with an acquirer which allows them to use their merchant account in order to process transactions on other sub-merchants behalf.

A brief history of crime

As with just about any process, criminals look to find a way to abuse it. Right from the start fraudsters realised that copying cards or acquiring card details provided them with a rich revenue stream. The boom in Internet e-commerce in the early 2000's provided criminals with two significant new attack vectors, end user PCs through malware or viruses and web site databases. It's fair to say that few e-commerce companies were developing secure sites in those early years, both in terms of code or storage, and it was common for websites taking payments to have databases full of unencrypted card payment details. Criminals quickly worked out ways to infiltrate these databases and walk away with thousands, or even millions of card numbers.

Due to chargeback rules, if a cardholder detects misuse of their account they can contact their card issuer, declare transactions as fraud and the issuer will return the funds or reinstate the credit. The card issuer is then left with the problem of tracking down the fraudster to try and recover the monies. Not an easy task. The card schemes needed to find an approach to deal with this.

The PCI DSS is born

Five of the card schemes, VISA, MasterCard, American Express, JCB and Discover, combined their independent card security programmes in 2004 to create the PCI DSS. Its aim is to provide a baseline level of security for card payment processing. The PCI DSS is a set of six "control objectives" made up of twelve high-level requirements. These high-level requirements are then broken down into nearly three hundered individual low-level requirements.

The control objectives are as follows:

Build and Maintain a Secure Network
Protect Cardholder Data
Maintain a Vulnerability Management Program
Implement Strong Access Control Measures
Regularly Monitor and Test Networks
Maintain an Information Security Policy

You get a feel for the sort of things they are looking for here. I won't take up any more space on this blog post regurgitating the long list of requirements, they can be found at the PCI DSS website http://www.pcisecuritystandards.org.

The PCI DSS is overseen by the PCI Security Standards Council (PCI SSC), comprised of representatives of each of those card schemes. Other businesses can join the SSC as a Participating Organisation (for a fee of course) and review proposed changes to the DSS.

The PCI DSS applies to all merchants that store, process or transmit cardholder data. The SSC breaks merchants down into levels based on transaction volume with the validation requirements for each level varying as appropriate for their size. The standard itself doesn't change however, just the process of validation.

Level	Criteria	Validation Requirements
1	Processing over 6 million transactions per year, or has previously suffered breach	Annual Onsite Security Assessment carried out by Qualified Security Assessor (QSA) and quarterly network scan by an Approved Scanning Vendor (ASV)
2	Processing between 1 and 6 million transactions per year	Annual Self Assessment Questionnaire and quarterly network scan by an ASV
3	Processing between 20,000 and 1 million transactions per year	Annual Self Assessment Questionnaire and quarterly network scan by an ASV
4	Processing less than 20,000 transactions per year	Annual Self Assessment Questionnaire and, depending on acquirer, quarterly network scan by an ASV

Merchants who comply with the PCI DSS are given "safe harbour" from fines and penalties associated with any card data theft which occurs from them, if they are proven to be PCI DSS compliant at the time of the breach. The scope of an assessment can be one of the hardest parts to nail down, before you even start to think about whether you comply or not. If you took the scoping statement literally you could argue that any device with an Internet connection is in scope and herein lies one of the core problems that we shall discuss in a further post, there is an awful lot of interpretation to be done with the PCI DSS and so much of a successful compliance assessment is in correctly understanding the standard and applying it appropriately.

In upcoming posts I will get in to some of the positives of the PCI DSS, how you can use it to make a genuine difference to your organisation's security, not just card data security and ways to invest time and money smartly. I will also examine some of the reasons I feel the PCI DSS is deeply flawed and is doing a disservice to information security professionals everywhere by distracting businesses to solve someone else's problem for them. You have to consider who is the real beneficiary in all of this, it's not the merchants, that is for sure.

Why I love the PCI DSS

I've been involved with PCI DSS since virtually the beginning, through work with a number of large Internet Payment Service Providers I was responsible for designing and implementing solutions which would accomodate some of its more specific requirements.

It's fair to say I have a love/hate relationship with PCI DSS and in this, the first of two posts, I'm going to explore my love of it. I think you can probably guess what the other post is going to be about. I'm not going to put forward any of the counter-arguments in this post so you'll need to read both to get the balanced view.

If you're unsure what PCI DSS is or how it may apply to you, we have published a high level overview of card payments and the PCI DSS here.


Raising Awareness

So what's to love about PCI DSS? Well, as with any compliance requirement it's going to get the attention of a company's board. "Attention" being that thing that we security professionals are trying hard to achieve all the time. So raising awareness of security issues; PCI DSS does that. Executives realise that they are going to have to evaluate their security practice and even spend some money to make improvements in a lot of cases. With PCI DSS as a compliance requirement, organisations which may have struggled to secure funding and focus are suddenly able to make a host of overall security and operational updates. This has led to improvements in policies, processes, infrastructure, physical controls and overall awareness of card data security. It all sounds great right? We'll come back to that in a later blog post.

Something is better than nothing

Well, in information security terms this is probably true in many cases. PCI DSS is a very prescriptive standard in a lot of respects, forcing even small merchants to consider security techniques that otherwise they may not. As independent consultants we work with many businesses who just aren't sure where to start. Many produce in-house web applications but their developers have never heard of Cross-Site Scripting, Injection flaws or any of the other common security risks on the OWASP Top Ten, let alone OWASP itself.

PCI DSS explicitly requires that companies develop in-house applications in accordance with widely available secure coding practice and cites OWASP and SANS specifically. So PCI DSS, if you do it right, gives you the opportunity and buy-in to create a secure development training programme, school your developers in doing things the "right" way and introduce them to the consequences insecure code brings.

It's certainly possible to write insecure code and still be PCI DSS compliant but isn't it surely better to have a development team who are aware of the core principles of secure development? Realising that you can't trust any input to your application is really the first step on a long journey, but it's an important one.

Ooh, shiny

Like most information security professionals who have to deal with compliance, I'm dismayed at the number of "compliance-in-a-box" products being churned out. Hey, I understand basic economics, there's no supply without demand, but seriously, there's no box for this. If you can see past all this nonsense and look at the standard for what it is you've actually got a huge number of process and documentation requirements and very few actual software/hardware ones.


This is good. What is going to save your company's data? That shiny IPS box with flashing blue lights or your staff following good security processes, reviewing logs and making educated decisions based on solid incident response procedures? That's just one example and PCI DSS requires you to have these types of procedures in place. It's surely difficult to argue with that isn't it? It has to make a positive difference.

Real world examples

Let's take a theoretical situation, ignore PCI DSS for a second and consider the following requirement from a security architecture perspective. Your IT Manager comes to you and says he needs to allow his Unix guys remote access to one of their Unix servers. The server is hosted in some remote datacentre.

After you've ascertained what's on the server and are comfortable that it can be Internet facing, what's on your checklist for allowing this access securely?

* Unique usernames for each engineer?
* Encrypted protocols only, probably SSH or SSH over a VPN?
* If it's SSH you'll want to use Public Key authentication only - so, Two-factor authentication ensuring engineers have passphrases on their keys?
* No direct root logins?
* Firewall off any other services not required?
* Remove any software you don't need?
* Make sure it's patched
* Make sure this host is in the DMZ, not the internal network?
* Ship logs to a central syslog server and monitor logins?
* Perform a remote scan to ensure you've left nothing silly available?


I could go on further but you get the idea. These are the sorts of things most security guys are going to say and they make sense. You'd be in pretty reasonable shape if you did all those things.

Well, PCI DSS is going to make you do all of those things. It's hard to criticise that.

What about designing a network to host a web application with a baackend database? How would you lay it out?

* Put the webservers in a DMZ?
* Place the database server on an internal network behind a further firewall?
* Only allow connections to the database server from the DMZ?
* Not permit direct Internet connections from the database network to the Internet, only the DMZ?

Again, these are just basics but they're likely on most security architects layered defence checklist. I probably don't need to say it but, PCI DSS will make you do this stuff.

Summing up

So, I've touched on a few of the positives of PCI DSS so far. It gives companies the impetus to implement a good security approach where perhaps they otherwise wouldn't. It opens the door for the information security team to get some valuable improvement done but it still takes a lot of work to implement solutions which actually improve security. For this reason I love it. I wish it wasn't the case but I'm a realist. If this is what it takes for companies to think about security then so be it.

PCI DSS is criticised for providing only a minimum baseline but, in its defence, that's exactly its purpose, the minimum. PCI DSS is guilty of far worse failings than that and in my next blog post I will explore my views on some of these.


On that note, the point I want to leave you with is this:

For all the apparent positives of the above, what is it focused on? Protecting card data. Is protecting card data the only data that needs protecting above all else? For almost all businesses the answer is no.

So is any of this actually improving your overall security? Well, maybe but maybe not. It's up to you to take the things which PCI DSS is asking you to do and squeeze every last drop of security value out of it while the budget and business focus is there.

Implement policies and procedures which cover PCI DSS but also cover the things that matter to your business. Design a network architecture that supports PCI DSS but which can also host the servers and data which really matter to your business.

Check out my next blog post as I dive deeper into the murky waters of PCI DSS compliance and expose it for what it really is.