‘PCI Compliant’ Service Providers, You Are Warned!

Readers of my blog know I am opinionated, which I why I have so many non-readers I suspect. I find myself now with something of a mission, and that is to either train providers of PCI-related services to perform 12.9 correctly, or I will make available a responsibility mapping matrix of their Attestation of Compliance (AoC)-defined services. Merchants need to perform appropriate due diligence, without full disclosure and guidance from Service Providers (SPs), this is all but impossible for the majority of non-PCI experts.

I  am not saying the SPs are doing anything nefarious,[mostly] they are not, it’s just clear that neither they, nor it would appear their QSAs, have taken the time to produce a responsibility mapping that makes sense.

I will not be posting names, but if you contact me on david@coreconceptsecurity.com and ask about a specific provider, I will tell you whether I have the mapping or not (just started this, so it’s unlikely, but stay tuned…). I am also happy to accept AoCs for your provider if you want a mapping done. Finally, I am also happy to help SPs directly if they would like to get ahead of this.

For Merchants: Regardless of the SAQ you complete, you are responsible for EVERY requirement in the PCI DSS, so any mapping and contract you have in place must be at that requirements level, not that of the SAQ, so if all you get is an AoC, there’s a very good chance your residual responsibility is significantly higher that you would like, and perhaps been led to believe.

At a minimum, your mapping will have 3 columns:

  1. AoC Mapping – This is the only ‘official’ recognition of the requirement numbers included that you have to go by, anything else the SP may say is irrelevant. If it’s not on the AoC, you cannot point your RoC/SAQ to it, and the requirements must still be assessed on your behalf. Note: Be VERY careful re: sub-requirements, if they are not SPECIFICALLY addressed, they are not included (Listing Req. 1.1.5 on the AoC does not necessarily mean Reqs. 1.1.5.a AND 1.1.5.b for example).
    o
  2. Services YOU Require – This is where you specify EVERY requirement you’re looking to outsource, but you need to be reasonable. There are surprisingly few requirements you can fully outsource (depending on the service), and you must detail what partial responsibility must remain with you. For example; you can outsource the changes to your rule-set, but you will usually retain ownership of it (which is the majority of Reqs. 1.X).
    o
  3. Residual Responsibility – This is what’s left for you to cover, and will represent an agreement between you, your service provider, and your QSA (if applicable). Anything NOT handled by your SP, is yours.

The above is not to say that an SP cannot provide significant support outside of their officially assessed services, but whatever they are doing needs to be noted, and included in your report.

For example; regardless of the services provided, EVERY policy requirement is owned by you, and followed by your SP. They may have their own policies, and even have them listed on their AoC, but those policies do not cover you as a merchant from a RoC/SAQ perspective.

Once complete and agreed by both sides, this mapping should form the basis of your contract. It does not matter if it’s an annex, addendum or in the main contract body, but the actual PCI DSS v3.0 requirement numbers must be part of any binding agreement. Whether or not you put SLAs around the services, or require full compliance on an ongoing basis, is a business decision, tying your SP to the DSS requirements they cover on your behalf is a PCI obligation.

I have uploaded an example of a Service Provider Responsibility Mapping that I recently provided to a client – help yourself. Hopefully it makes sense, but you are free to contact me if you would like more guidance.

This is actually a very simple process, as is everything else in security, it’s only not knowing yourself what to do that makes it difficult. So ask for help.

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

PCI DSS v3.0: Service Provider Agreements (Req. 12.8.X)

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?

PCI From the Other Side: An Ex-QSA’s Worst Nightmare

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!]

Continuous Compliance Validation: Why The PCI DSS Will Always Fall Short

Just about everyone who writes on information security has had ample blodder from the Target / Neiman Marcus et al breaches, myself included. Some blame the PCI standards or the card brands themselves, some blame the retailers for not doing enough, and those that are a little more charitable, just blame the thieves.

In the end, it’s not about blame, it’s about learning the lesson, making the necessary adjustments, and moving on responsibly. Unfortunately, this will NOT include being able to move on from credit cards or from the PCI DSS v3.0 any time soon, so organisations wanting to avoid becoming the next Target (excuse the pun), had better pay more attention to their enterprise-wide security program, not just their annual compliance ‘projects’.

Just as importantly, they need to pay VERY close attention to innovation in the payment / authentication space, and advances in more real-time security measures / technologies.

Nothing in the PCI DSS is anything other than a bare minimum, and represents enough security for the card brands to say they are doing what they can. But any organisation who thinks this is enough will eventually lose data, and I for one have no sympathy.

You can look at every single requirement and come up with two choices: 1) Good enough for PCI, and 2) Appropriate for the business. 9 times out of 10, the second option is more difficult to implement, but in almost every instance, it is both easier to maintain, and more secure.

For example;

PCI DSS Requirements 1.X are all about networking, firewalls, segmentation and the like, and while it does stress that every service/protocol/port must have a business justification, it does not state specifically that every individual in-scope device must have least-privilege inbound and outbound rules applied.

  1. 1.1.6.a – Verify that firewall and router configuration standards include a documented list of all services, protocols and ports, including business justification for each
  2. 1.2.1.a – Examine firewall and router configuration standards to verify that they identify inbound and outbound traffic necessary for the cardholder data environment.
  3. 1.2.1.b – Examine firewall and router configurations to verify that inbound and outbound traffic is limited to that which is necessary for the cardholder data environment.

Yes, we can imply it means each device (especially 1.2.1.b), and yes, it’s the right thing to do, but no QSA can enforce anything that is not specifically written within the standard. If they had just replaced “the cardholder data environment” with “each in-scope system” DSS Section 1 would be VERY different, and instil a significantly better security posture.

However, if they DID change it to least privilege for every device, is it actually possible to implement and maintain it? Same goes for more robust configuration standards (DSS Section 2), or real-time logging (DSS Section 10), what should be done is very different from what the DSS requires.

In answer to the question, yes, it is possible, and it all boils down to one thing; baselines

Security is not about crunching big data to determine patterns, that’s only truly relevant in forensics when it’s already too late. Real security is knowing exactly what something SHOULD look like performing normally, and reporting everything outside of that. Keep it simple, or it cannot be monitored, maintained, or measured, but the PCI DSS can never go this far.

Hypothetical: If you knew every running service, listening port, and permitted connections each in-scope device should maintain to perform its function, then anything NOT those things should be investigated. That’s a baseline. Security would dictate that you have alerts based on these anomalies for all systems, not a sample of them and certainly not once a year (point-in-time).

How difficult would it be to automate this process so that EVERY system (not just PCI ones) reports back on a daily/weekly/monthly – or ANY period of time less tun a year! – basis to a centralised management console to perform the baseline comparisons? Then what’s to stop you comparing the device’s listening ports to firewall rule sets to make sure they are properly defined? Or comparing them against enterprise policies and standards, or known business data flows?

Not one organisation or security vendor is doing this properly, at least not that I have seen, or not yet. Some vendors do bits of this, but the last thing you want to do is patch together a bunch of separate, non-integrated systems, as the effort to do so will usually outweigh the risk mitigation, or the cost-to-benefit ratio.

However, none of this can happen until you have centralised and accurate asset management, and seeing as the PCI DSS just added that as a requirement in v3.0, most organisations have a long way to go before they can ever achieve this ultimate in security; continuous compliance validation.

PCI DSS v3.0 – Do NOT Pay More For Your QSA Services!

Last week I had the pleasure of conducting a 1 day Advanced PCI course that included details of the changes between v2.0 and v3.0. It was clear that there is not only continued confusion regarding the ‘new’ content, but that the less scrupulous vendors of QSA and penetration testing services are using this confusion to charge more for the same service.

I have warned of this previously, but let’s be very clear. If you are being asked for more money based on the v3.0 changes, your service provider is:

  1. Confused about what the changes mean themselves;
    o
  2. Covering up for not performing their work properly in previous years;
    o
  3. Lying to you.

I fully understand the pressures QSA companies are under with regard price compression, competition and so forth, but using this DSS update to raise prices is unconscionable.

Here is an example;

Requirement 1.3.3 Do not allow any direct connections inbound or outbound for traffic between the Internet and the cardholder data environment.

In v2.0 of the DSS the ‘Testing Procedures’ states; “1.3.3 Verify direct connections inbound or outbound are not allowed for traffic between the Internet and the cardholder data environment.”

In theory, the QSA could just say; “[QSA company] verified that direct connections inbound or outbound are not allowed for traffic between the Internet and the cardholder data environment.” However, in the ‘ROC Reporting Instructions for PCI DSS v2.0, September 2011‘ your QSA is responsible to do far more;

 Identify the network documents/diagrams specifying that direct connections are not allowed for traffic between the Internet and the cardholder data environment:

i. Inbound ii. Outbound

 Describe how observed firewall/router configurations prevent direct connections between the Internet and the cardholder data environment:

i. Inbound ii. Outbound

 Describe how observed traffic between the Internet and the cardholder data environment confirms that direct connections are not permitted:

i. Inbound ii. Outbound

Now look at v3.0; “1.3.3 Examine firewall and router configurations to verify direct connections inbound or outbound are not allowed for traffic between the Internet and the cardholder data environment.

Other than changing ‘verify’ to ‘examine’, the reporting instructions are STILL not fully built into the new standard, but are getting closer. So the vast majority of the DSS v3.0 is just clarification of validation requirements based on a document that is already more than 2 years old.

To put this another way; your QSA and YOU were responsible for performing 95% of what’s in the v3.0 for the last 2 years. The other 5% are things you SHOULD have been doing anyway if your QSA was doing their job, and you were doing security properly:

2.4 – Maintain an inventory of system components that are in scope for PCI DSS

Seriously? How could you have EVER achieved compliance without having an asset inventory of some sort?

6.5.6 All “high risk” vulnerabilities identified in the vulnerability identification process (as defined in PCI DSS Requirement 6.1).

Verify that coding techniques actually address the ‘high vulnerabilities’? What ELSE would it be doing?

8.5.1 Additional requirement for service providers: Service providers with remote access to customer premises (for example, for support of POS systems or servers) must use a unique authentication credential (such as a password/phrase) for each customer. 

The sad part is that they actually had to add this, as a lot of breaches were caused by NOT having this in place. Vendor due diligence is almost universally poor across PCI relevant service providers, and this is entirely the fault of each organisation, not the SSC.

9.9 Examine documented policies and procedures to verify they include:

 Maintaining a list of devices

 Periodically inspecting devices to look for tampering or substitution

 Training personnel to be aware of suspicious behavior and to report tampering or substitution of POS devices

If you weren’t doing this already you deserve what you get.

10.x [Logging Stuff]

Significant clarification of what’s expected in logging and monitoring, and will only negatively impact those organisations doing the bare minimum to get through PCI.

11.3.x [Penetration Testing Stuff]

Nothing in here is different from the intent of penetration testing all the way back to v1.0, and if your QSA says things have changed, they have been doing it wrong all along.

12.8.x [Service Provider Stuff]

The only organisations this will negatively affect are service providers who were hiding the true extent of their service coverage, and clients trying to outsource responsibility of PCI compliance to others. If your organisation’s vendor due diligence and vendor management programs don’t already cover this, it’s your fault.

If you want a more complete listing of the changes, go here; PCI DSS v3.0 – Mapping to v2.0_v07NOV13.xlsx

Every QSA company has training courses, white papers, presentations and God knows what else trying to explain the difference between v2.0 and v3.0. If you want to save your time and money, learn how to do SECURITY properly and PCI will make perfect sense.

Take the phrase ‘cardholder data’ out of the DSS and replace it with ‘personal information about your family’. Name ONE requirement you don’t want in place?