Category: PCI

There seems to be quite a bit of confusion about the ‘new’ requirements for service provider contracts. I say ‘new’ sarcastically because this should have been part of your vendor due diligence processes from the beginning.

From a merchant’s perspective, unless they have hired a QSA (or other PCI expert) to help define the service requirements and contractual obligation, it’s very difficult for them to ask the right questions. From a  service providers perspective, I’ve seen the gamut from complete ignorance of their obligations, to out-and-out lies in terms of what they are and are not providing.

The DSS v3.0 requirements of 12.8.X go a long way to resolve this, but not far enough in my opinion. The bottom line is that someone has to be responsible for each requirement, and there are only the following choices;

  1. SP agrees to be fully responsible for the requirement;
  2. SP agrees to be partially responsible, and;
  3. SP pushes the entire requirement back on you.

That’s it.

The above list is fairly obvious, but for the service provider’s clients the challenges are now twofold:

  1. If the service provider accepts full responsibility, are they PCI compliant for the service(s)?
  2. If they are only partially responsible, EXACTLY what part of the requirement is left?

Does the service provider need to be fully PCI compliant for you to achieve compliance? The answer is no, but if they are not, you have just doubled your assessment scope. Again, someone has to answer the questions, so if your service provider has not validated compliance for the services they are offering, you need to add them to your validation efforts.

As for the partial responsibility, that’s easy, get your service provider to tell you what they’re doing. For example;

DSS Req. #

Description

 Service Provider Responsibility Client Responsibility
1.1.3

Examine data-flow diagram and interview personnel to verify the diagram:

*  Shows all cardholder data flows across systems and networks.

*  Is kept current and updated as needed upon changes to the environment.

SP will provide initial diagrams in Visio format for the pre-production environment but will not own, manage, or keep up-to-date the data-flow diagrams post-production.

 This requirement is not part of SP PCI Report on Compliance dated [Mmm dd, yyyy]

Client must own, manage, and keep up-to-date all data-flow diagrams for inclusion into their own PCI compliance efforts once services have reached a production state.

You must repeat the above for EVERY requirement in the PCI DSS v3.0, then add this as an addendum or annex to your signed service contract. This applies not only for the services they are providing DIRECTLY, but the SP has a responsibility for any SUB-contractor they may bring in, and so on down the line.

Again, SOMEONE has to answer the questions!

However, let’s back up a bit and handle each DSS Requirement in turn:

12.8.1 Maintain a list of service providers

Easy, just maintain a list of Service Providers, with – at a minimum – the following detail;

  • Company Name
  • Service Description
  • Is [CONFIDENTIAL] Data Shared?
  • Regulatory Compliance Date
  • Status Verified By

12.8.2 Maintain a written agreement that includes an acknowledgement that the service providers are responsible for the security of cardholder data the service providers possess or otherwise store, process or transmit on behalf of the customer, or to the extent that they could impact the security of the customer’s cardholder data environment.

Even easier, they wrote it down for you!! Include – again, at a minimum – the language in red in your contracts. You will likely want significantly more than this as there is no declaration of LIABILITY, or even SLAs.

12.8.3 Ensure there is an established process for engaging service providers including proper due diligence prior to engagement.

If you don’t have robust vendor due diligence and vendor on-boarding/off-boarding processes you are really asking for trouble. For PCI services, if you have not ensured they are PCI compliant for the services they are providing AND you have the full details written into contact, then you have created a world of pain for yourself.

12.8.4 Maintain a program to monitor service providers’ PCI DSS compliance status at least annually.

Does this say anything about the service providers actually working towards PCI compliance? No, it doesn’t, so the status could be; “They will never achieve PCI compliance.” and this is good enough for PCI. This should NEVER be good enough for you.

12.8.5 Maintain information about which PCI DSS requirements are managed by each service provider, and which are managed by the entity.

This we’ve already covered, all you need is a table, like the above, of every PCI requirement handled by each of your service providers and their sub-contractors. Your QSA can then tell you precisely what is left for you to cover for full compliance.

Whether you’re assessing for the first time, or re-assessing under v3.0, you need to start these conversation with your service providers NOW, as while this may be simple, it is not easy.

Advice for Merchants:

  • Only choose PCI compliant service providers (start here; Visa Europe Merchant Agent List)
  • Only choose service providers who have already addressed 12.8.2 and 12.8.5 up-front. You should not have to ask for this from SP worth their salt
  • If you have existing SPs and don’t know where to start, hire a decent consultant who is familiar with the PCI DSS to help

Advice for Service Providers:

  • Get your responsibility mappings and your contract language sorted out now, BEFORE you are asked
  • If you need help, ask for it, ignorance is not an excuse your clients can accept, nor can the card schemes

Easy huh?

Once again I have chosen a dramatic title to sucker you in. But seeing as it’s PCI related it’s never going to be even remotely exciting.

First; per the title, I’m not actually a QSA any more, but I have been in the trenches of PCI since before there were QSAs. Anyone remember QDSPs? I am therefore reasonably well qualified to write about it.

Second; by “PCI From the Other Side”, I mean that I found myself in a scenario where I was the one being assessed. The remainder of this blog is about that experience. It was truly eye-opening, and I hereby apologise to every client I’VE assessed over the last decade. I only now feel your pain.

But it’s not until you find yourself on the other side of the assessment fence that you can truly appreciate the challenges. I am both a PCI and cybersecurity expert, and even I had a hell of a time putting my organisation through the process. And I designed the infrastructure with compliance in mind!

My first challenge was finding a PCI compliant service provider (SP) who covered the vast majority of the infrastructure related processes. From configuration standards, to AV, to logging and monitoring I didn’t want to do anything in-house. I spoke to several service providers, and found myself guiding THEM in the design of their PCI services! Regardless, they were universally unhelpful, and if I had this much difficulty, what chance does anyone else have?

Even Amazon Web Services does a better job than every SP to whom I spoke. While AWS basically devolve almost every aspect of compliance back on the client, they at least break down the EXACT responsibilities for all parties. Yes, PCI DSS v3.X does a better job of making this a requirement, but it can still be very difficult to get the right information based on a vendor documentation. If you don’t ask the right questions, no SP seems anxious to provide them for you.

The second major challenge was the sheer volume of ‘paperwork’. Policies, Procedures and Standards make up roughly 35% of the PCI DSS requirements, and at least 47% of validation against all requirements involves review of some form of documentation. Even if it’s just a screenshot.

As an assessor, I would give my clients a spreadsheet that tells them what kind of document I need against any given requirement. They would then complete this with the document THEY believe meets the intent of the Testing Procedure. For my QSA I went one stage further and mapped my policies and procedures (including Section numbers!) against the Report on Compliance v3.X template itself.

Now these are Policies that I have mapped against the PCI DSS / ISO2700X/ CoBIT etc. I have even sold them to several clients to help with their compliance efforts, yet it took me several weeks get them where they needed to be. As for the Procedures and Standards, I had to create 24 separate documents to cover everything from Change Control to Vulnerability Management. This was NOT fun, or easy!

Like finding a Service Provider, I had a huge advantage over most people in charge of putting together their organisation’s documentation. If this was the pain I went through, I do not want to begin to imagine the pain for anyone not an expert. [Note: The ‘paperwork’ is critical not just to PCI, but to security in general, and should NEVER be done with just compliance in mind!]

I have written too many blogs about the problems with the PCI DSS to harp on about them here, and there were far more issues I faced than you want to hear about. Needless to say, if the SSC really want to train new QSAs, they should throw out their entire curriculum and put them in the client’s shoes for a day.

95% of them would fail.

Who am I kidding, 95% of CURRENT QSAs would fail, I almost did!

[If you liked this article, please share! Want more like it, subscribe!]

While on the one hand, few organisations take information security as seriously as they should, to blame merchants for not maintaining PCI compliance is akin to blaming the doctor for your illness. In non-cash payments the fault lies not with the merchant’s lack of security culture, but with the payment card ecosystem itself.

I understand the motivation behind this article; Maintaining PCI Compliance a Showstopper for Many Retailers, but it shows a spectacular lack of understanding of the real issues.

The branded-card payment technology is broken, pure and simple, and so far no-one in the card-payments arena has done much to fix it. Instead, they have all put the onus, and the cost, onto the end merchant, who then has two choices;

  1. Eat the cost
  2. Pass the cost on to their customer

Guess which happens 9 times out of 10?

But why should the merchant be wholly responsible for the protection of the cardholder data? Are credit cards core to their business? They shouldn’t, and no, are the respective answers; payment for services / goods rendered is core, the means by which they receive payment is ancillary, and in this case then, responsibility for securing the payment type should be on the payment service provider.

50 odd years ago certain card brands came up with an excellent concept; the payment card. Banks jumped all over it and started providing lines of credit through the medium of plastic and the concept exploded. Now credit cards are the de facto, and ubiquitous, form of non-cash payment accepted globally.

So ubiquitous in fact, that few people seem to question the fact that the system is inherently insecure, inefficient, inflexible and massively expensive to maintain. Not for the card brands mind you, but for everyone else. The only ones who cannot recoup their costs is the consumer.

I have no problem paying for the convenience of a non-cash payment mechanism, but as a business owner, I DO object to being the only one paying for security of cardholder data when the technology itself is broken and any innovation away from the current system is stifled until such times as the card brands can catch-up. Which they won’t at the rate they are going.

The card brands clearly want things to continue as they are, as do the issuers and acquirers for obvious reasons. Banks make money from branded cards by charging both annual fees and interest on lines of credit so they have no desire to change things. Large retail, who should have enormous power and influence over payments innovation have, for some reason, completely missed the point. So it’s left to the rest of us to make a difference.

The challenge is that ‘we’ are ignorant and are clearly quite happy to go along with whatever is given to us. If this seems harsh, just look at the above article again. Verizon SHOULD know better than to blame the merchants, but if they don’t, what chance to the rest of us have?

Until such times are the ‘merchants’ learn ask the right questions this type of nonsense will continue, and until we, the ‘consumer’, start demanding REAL alternatives, we have no-one but ourselves to blame.

[Ed: I am very pleased to present a guest blog for a good friend of mine. He and I have spent more time in the PCI trenches than we would either care to admit;]

“I read your blog somewhat religiously and I find myself thinking about my feelings towards PCI both from an assessor and client perspective and moreover as a security professional.

With breaches now on the rise, it is time to reflect a bit on how did we get here? Why are things this way? Is PCI working?

We got here because of money. The all mighty dollar (pick your currency). Greed, my friends, has fueled this issue, and for years and will continue to do so.

Greed by the card brands has pushed them to promote acceptance so wide that the only way anyone even thinks about non-ash payments is with a card. This push for acceptance came in the early 1990’s and continues today. At that time, very little was thought of PCI other than a little fine print that was quietly overlooked until breaches began to result from this push.

At that point, the card brands felt that the public – being sufficiently hooked on the drug of convenience – was finally ready for enforcement of compliance with standards. Shortly thereafter the PCI SSC was born, and the real greed and corruption was to begin.

Below are a few points that have been smoldering quietly in the back of my head that are now demanding to be shared.

  1. Unless it’s my core business, it will never be my core competency. You cannot make merchants into military. They won’t go, they never will, stop trying to make them. Realize this now and move on.
    o
  2. The card brands have created the problem by pushing their acceptance channels as hard as they have, and then attempted to throw security on top of the pile long after the fact. Security first, acceptance of cards later.
    o
  3. The card brands added insult to injury by creating the PCI SSC. This is a self serving group that dictates a set of documents and charging fees, then completely and utterly fails to enforce its own assessor quality assurance program.
    o
  4. The SSC has, through their actions and inaction, contributed to the creation of a scandalously corrupt cottage industry of PCI QSACs. These companies are selling assessor services for a flat fee and assigning work at a rate of 35 to 45 PCI assessments a year per QSA. This volume is horrific and does not serve the client, or the card brands. The delivery of an appropriate assessment is simply not possible. You can have two of the three, “cheep”, “fast” and “good” but only two. Cheep and fast does not make for good, yet the SSC has allowed the QSAC’s to promote and aggressively sell just that.
    o
  5. The SSC has allowed the same QSAC and QSA to assess the same environments year after year creating complacency and further corruption. If you care about compliance, rotate assessors. Assessors make bad calls, and in order to maintain the client, must live with them year after year. Fresh eyes are critical to maintaining integrity.
    o
  6. The card brands have failed to adopt more secure methods of moving funds. The clear text account number adhered to the back of a piece of plastic via technology rivals that of the 8 Track player in my mother’s 1976 Mercury Cougar. This is criminal.

I could go on and on, but the key points remains the same, the card brands are the cause of the problem, and have made it worse by setting up an unrealistic security program rather than focus on their own flawed methods.

The reality is this; PCI is a way to shift the burden of securing the otherwise insecure from the card brands to the merchants, banks and service providers. God forbid the card brands pick up the tab??

As long as I am ranting, how is it that Moore’s Law drives down the cost of all technology except when it comes to transaction processing?

Will my rant change anything? No, but I do feel a bit better sharing with you all.

Regards,

Frustrated Assessor”

…or better still, keep doing what you’ve learned, all day every day.

This is the final post in my ‘Going Beyond the Standard’ series – HURRAH!! – and hopefully despite all of the spelling mistakes, grammatical errors, left-field rants, and miscellaneous off-topic diatribes that you have derived some benefit from it.

Timing is pretty good as well, seeing as the SSC came out with their Information Supplement: Best Practices for Maintaining PCI DSS Compliance, and I will say that I have to agree with the majority of its content. However, reading a book on emergency appendectomies does not make me a doctor, so when it comes to the implementation of the ‘staying compliant’ concepts, have an expert help you.

It takes someone very skilled to make things simple, do not half-arse your security.

There is nothing in PCI that you should not already be doing around all of your sensitive data, and there are no validation requirements that should fall outside of standard practices. In fact, you should be validating EVERY day, not once a year, and the only way to do that is to baseline everything and report against exceptions.

I previously used this ridiculous analogy; If every PCI requirement was a tennis ball, you could very easily carry them all from a weight perspective, but it’s impossible to hold them all together without some kind of container (Tennis ball = DSS Requirements, Container = Security Program). In other words, the requirements themselves are basic, but completely out of context from an ongoing management, business, or even good security practice perspective.

The reason PCI becomes so difficult to maintain is because security in general is too often seen as an IT project and not what it is; a business process. The only time it gets the attention it deserves is when there’s a problem, which is already too late.

When I started my own business, and when I began this blog, it was with the following premise; “Security Is Not Easy, But It Can Be Simple.” Yet every business for whom I have ever provided guidance were basically making a pig’s ear of it, and it always revolves around a lack in at least one, but usually all of the The 4 Foundations of Security.

The way I have always phrased it is; “If my boss does not care about something, guess how much I care about it?”, which is why I have made this statement several times now;

“Let’s be very clear; The CEO sets the tone for the entire company: its vision, its values, its direction, and its priorities. If the organisation fails to achieve [enter any goal here], it’s the CEOs fault, and no-one else’s.”

So if you get nothing out of this series of 25 blogs, take that away and do what you can to help them change the culture to one of accountability and responsibility across the entire organisation. It will pay dividends.

Hope you enjoyed the series, and I would welcome any guest blogs that either expand on the concepts on the subjects on which I am weakest (encryption, coding, charm, spelling etc.) or are better than mine if it’s a subject in which you are an expert.

There is no room for ego in security, everyone has to win.