Managing PCI DSS Compliance

This might seem like a pretty dry subject, but if your company processes card payments, then it needs to comply with the Payment Card Industry Data Security Standard, or PCI DSS. Here's what it's all about and how I go about managing ongoing compliance.

What is the PCI DSS

OK, so it's a standard. But then so is ISO27001, but as I mention in my last post concerning GDPR, ISO27001 is a standard you can choose to comply with. You might choose to comply with it if say, you wanted a badge demonstrating that you take information security really seriously and wanted to use that badge to appear more attractive to other organisations, ones that you might want to spend money with you.

In any event, I cover that in my other post.

With the PCI DSS, If you process card payments, you really can't afford to not be compliant. There are penalties for failure, they've been here for a while and they give the potential fines from GDPR breaches a run for their money.

Here's a brief outline of what it's all about.

Online fraud sits up there with the many scourges of the internet. Crooks are constantly trying to steal payment card data either directly from individuals or from firms, in order to make fraudulent transactions for goods and services, or indeed to sell on that data in bulk to more organised crime operations wanting to do the same thing. Either way, if your card data falls into the wrong hands, you're at risk of some pretty dire consequences.

Payment card fraud runs at hundreds of millions of pounds in the UK alone per year, but runs at tens of billions globally. It's massive. It costs a fortune and it wrecks people's lives.

So, the PCI DSS is aimed at guiding commercial organisations into a safe place, where they are processing payment card data responsibly and it literally hammers them if they are found to not be. Seems fair to me.

The PCI DSS Security Council website provides all the deep and meaningful information you'll ever need, but for summary, read on.

The mechanics of the PCI DSS

What type of merchant organisation you are determines what level of compliance you need to demonstrate. In our case we take payments online and over the phone, so it's pretty much the highest there is.

The applications we use online or in our offices are all in scope, if they are used to capture card payments. We force customers to post their card data to our card payment service provider directly, but as we embed their 'payment gateways' into our own systems, our own systems are in scope.

If your organisation processes card payments using your own systems, before passing the data onto a payment service provider, then everything that cardholder data touches is in scope; the websites used to capture payments, the PCs used to capture payments over the phone, the databases if you store cardholder data, the networks the data traverses, absolutely everything. Including the people involved!

This is known as compliance scope or similar. Systems, processes and people. And so on. Compliance is measured by the adequacy of the controls in place to prevent any of those factors failing and leading to a breach, or loss of card holder data.

The current version of the PCI DSS is 3.2 and there are 12 high level requirements, spread across six themes:

Pretty straightforward eh? Well, no. It's a real challenge!

For each of the themes, there are a bunch of sub-requirements. Each different, each reaching into different business areas. So, for example:

That's just an example.

In a smaller organisation, that might be a handful of people, or maybe even just one person, or even no one at all(!). In a mid-sized firm, it's a significant number of both people and teams, all doing things other than worrying about PCI DSS compliance, day in, day out. In a large operation, it's literally hundreds, if not thousands of people, all spending their days doing something other than PCI DSS. Then of course you factor in the outside companies doing some of these things (managing your network, IT, payment processing and so on).

You start to get a feel of the scale of players in the game of compliance. And the size of the headache.

For each of these business areas, you're required to demonstrate compliance, if cardholder data touches any of them, or if people in them come into contact with cardholder data.

Where do you start?

With this basic diagram:

It's not brilliant (and I'm no artist), but it describes people sending cash, via the internet, to a system. Think about the technical implications of that. The security of:

• The web application; a safe place for someone to enter their payment card data
• Transport of that data, from the user to the payment destination
• Processing of that data, in flight
• Storage of that data (if you store it), when it's at rest

So, you start with understanding the journey that cardholder data takes, from the fingertips or voice of the customer, through to the bank accepting the payment. And you simplify the hell out of it, where you can. This is known as reducing your PCI DSS scope. Minimise or eliminate the number of systems that process the data, by using verified third parties to actually capture the data meaning you never handle it.

It begins with audits and therefore meetings. It always does.

You look at processes to begin with and then the supporting systems. Then you examine the ways that relevant data flows to and fro. What networks are traversed, what firewall configurations and proxy setups are in place. You do all that. Then you look at the people individually responsible for processing those card payments and whether their daily activities are susceptible to phishing / other social engineering, cross site scripting or other well known web application attacks. Your mind boggles and you start to wonder how you do it all yourself.

You don't.

You know you have six main themes and that they cover 12 broad requirements and that's your plan. Because you know who has responsibility for the various aspects of compliance, you involve them from the start.

Systems Development

They build the software systems that take card payments. What are they doing to ensure that those systems are processing payments securely? Find out. If they're not doing the right things, work with them to ensure they are. For example, we're talking about encryption of data, in transit and at rest, using strong methods.

Networks

These teams ensure that there should be no worrying ingress / egress points and that firewalling and routing best practice is being followed. You get the idea.

Infrastructure

The platforms that the software systems operate on need to be secure. They need to be configured to observe best practice, when it comes to such things as transport security, server hardening and the like.

Operations

These guys are dealing with the card holder data, so need to be aware that the processes by which they manage card holder data don't require that they actually ever see it. And by now means should they ever request this data to be provided via unsecure means, for example email.

They also need to be aware of unsolicited emails that may be carrying malware, that might drop a payload onto local machines, the wider network and so on, potentially causing havoc.

HR / Learning and Development

The people responsible for raising wider awareness or delivering training of things in general, but also there to ensure that policies are being adhered to and that relevant training is kept up to date. They're especially helpful if you need to get key messages across to a wide audience.

Compliance

You need oversight and auditability of everything above, so the compliance function is essential in providing that. Whether that be through regular auditing, or spot checking of processes being followed, through to providing support in achieving compliance itself, these people are at the heart of the matter.

Third Parties

With third party organisations, you effectively have to trust that they are maintaining their own side of the PCI DSS compliance bargain. You can build clauses into contracts to enshrine that legally and conduct myriad assessments of your own, but at the end of the day, you have to trust that they're doing the right things.

The Process of Compliance

I'm coming towards the end of this post, so in this section I'll describe how the assessment and declaration of compliance is managed.

Every month we run vulnerability scans against our public facing payment systems (and in fact all systems). We do that for ourselves, using tooling provided by Netsparker. Anything discovered that merits attention gets exactly that, with anything requiring a fix subsequently addressed.

So, we're talking here about things like web application vulnerabilities, firewall holes and transport layer security issues.

N.B. Come June 2018, if systems in your PCI DSS scope still support TLS1.0, you'll automatically be non-compliant, but I'm sure you know that already. :)

OK, so this isn't just us marking our own homework, because every month an independent scan is also run against those systems, provided by what is referred to as an approved scanning vendor or ASV. In our case, it's Trustwave. We get a monthly report, detailing its findings. Because we run our own scans, we're more often than not a step ahead of the ASV, but we need that external validation for what I'm about to describe.

Every quarter, our payment collector, or clearer expects a copy of the ASV report, so this needs to be sent, unmodified to them. The ASV runs the scan and we literally forward on the output report. This is required to maintain ongoing compliance.

In September each year, we are required to renew our Attestation of Compliance or AOC. I do the spadework to get us to this point and it's pretty full on.

From early August, there's a busy period of looking at any new requirements from the previous year and mapping those into our existing arrangements, ensuring that our posture hasn't changed for the worse, recording where it's changed for the better and so on. Meetings, spreadsheets, workshops, systems changes where necessary and stuff like that.

By the end of August, I'm ready to tackle the Self Assessment Questionnaire or SAQ. There are a few flavours of SAQ, which are determined by the type of organisation you are. Ours is SAQ-D. You can read up on that in more detail elsewhere.

As we use Trustwave to do our independent scanning, we also use them to complete our SAQ and subsequent AOC. The SAQ is a really meaty online process that requires focus and time. The great news for me is that I have the input already prepared in the abovementioned spreadsheets. This means I can confidently answer the questions reasonably quickly and easily.

Once done, the questionnaire is ready to submit to Trustwave for processing. We usually use the couple of weeks ahead of submission for initial reviews, tweaks and then a final review. And then we post the damn thing.

Once processed by Trustwave (assuming we did it right!), we get an acknowledgement and a couple of artefacts:

• A compliance certificate
• A completed compliance report
• A fresh ASV scan report

When we receive them, we are then required to submit them (again unmodified) to our payment collector. They then 'file' that information and we are compliant for another 12 months.

And the process reboots.

Conclusion

It's a lot of work to manage compliance, but for me the point isn't about the compliance itself. You can get your PCI DSS, or ISO, or GDPR, or whatever. It's what motivates you to do it that's important. Practising good data security is where the impetus or drive should always be.

Don't do it to tick boxes or earn badges. Do it because you take privacy and the protection of data seriously.

It's known as a security based approach to compliance.

Do the right things and compliance should be a doddle.

Thanks for reading.