You Take Card Payments? Read On
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 PCIDSS. Here's what it's all about and how I go about managing ongoing compliance.
What is the PCIDSS
OK, so it's a standard. But then so is ISO27001, but that one 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.
With the PCIDSS, 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 billions of dollars per year, it's massive. It costs a firms a fortune and it wrecks people's lives.
So, the PCIDSS 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 PCIDSS Security Council website provides all the deep and meaningful information you'll ever need, but for summary, read on.
The mechanics of the PCIDSS
What type of merchant organisation you are determines what level of compliance you need to demonstrate. In many cases you take payments online, at a terminal and over the phone, so it's pretty much the highest there is.
The applications or point of sale (POS) devices you use online or in your offices are all in scope, if they are used to capture card payments. You perhaps guide customers to post their card data to your card payment service provider directly, but if you embed their 'payment gateways' into your own systems, those systems are then 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.
Pretty straightforward eh? Well, no. It's a real challenge!
For each of the themes covered by the standard, there are a bunch of sub-requirements. Each different, each reaching into different business areas.
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 PCIDSS 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 PCIDSS. 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?
Think about the technical implications of that. The security of:
The web application or POS terminal; 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, contactless tap, 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 PCIDSS 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 use help! You won't necessarily know you have six main themes and that they cover 12 broad requirements and that's all in your plan. Because you may not know who has responsibility for the various aspects of compliance. Here are a few examples:
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 or Point of Sale Staff
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 PCIDSS 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 you would run vulnerability scans against your public facing payment systems (and in fact all systems). You could do that for yourselves, or outsource the work to a recognised scanning provider. 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. Since June 2018, if systems in your PCIDSS scope still support TLS1.0 or 1.1, you'll automatically be non-compliant. This is the secure transport protocol version for sending card payment (and other) data across the internet.
OK, so this isn't just you marking your 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. There are many out there. You get a monthly report, detailing its findings.
Every quarter, your 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 you literally forward on the output report. This is required to maintain ongoing compliance.
Annually, you are required to renew your Attestation of Compliance or AOC. There is spadework to get you to this point and it can be pretty full on.
As you begin, there's a busy period of looking at any new requirements from the previous year and mapping those into your existing controls, ensuring that your 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.
When all this is done (and it’s important to point out that the smaller your operation and technology footprint is, the less complex things are), you’re 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. You can read up on that in more detail elsewhere.
You would typically use your ASV to also complete your SAQ and subsequent AOC. The SAQ is a really meaty online process that requires focus and time. The great news is that if you have the input already prepared in the abovementioned spreadsheets, then you can confidently answer the questions reasonably quickly and easily.
Once done, the questionnaire is ready to submit to the ASV for processing. You’ll want to leave a couple of weeks ahead of submission for initial reviews, tweaks and then a final review. And then post the damn thing.
Once processed by the ASV (assuming you did it right!), you get an acknowledgement and a couple of artefacts:
A compliance certificate
A completed compliance report
A fresh ASV scan report
When you receive them, you are then required to submit them (again unmodified) to your payment collector. They then 'file' that information and you 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 PCIDSS, 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.
Octopi can take the hassle out of all of this for you, so for more information hit us up using our contact form below!