Tag: Vendor Due Diligence

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

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?

[Apologies for the blank post yesterday, here is the real one]

The timing for this part of the Going Beyond the Standard series is almost perfect given the SSC’s release of their ‘Information Supplement: Third-Party Security Assurance‘. Which, despite it’s gratuitous use of the word ‘may’, and the ongoing generic-ness of the SSC supplements, is actually pretty good.

It has always irritated me that the phrase ‘third parties’ is now the established norm in these scenarios, when it’s actually SECOND parties that create the most challenges;

third party
[noun]
1. a person or group besides the two primarily involved in a situation

So third parties are the service providers that YOUR service provider hires to do [part of] the work for which you (the first party) hired the original provider. Third parties are fairly common, but not as common as second parties, and while third parties ARE an issue, they should be addressed in the same way as any other outsourced service; with proper due diligence.

Unfortunately, this due diligence is almost universally performed badly, or there would be no need for the SSC to issue an information supplement in the first place. Or course, if the requirements in the PCI DSS were written better perhaps there would be less confusion, but it’s too late now.

Because the supplement is quite good, I’ll not go into the nitty gritty of vendor management, but it is important to realise that the choice of an outsourced service does not start with vendor due diligence, it starts with a business need that has been PROPERLY analysed, and a risk assessment performed.

PCI itself has driven an enormous growth in outsourcing, and not because there was suddenly a need for more services, but because so many organisation wanted PCI to just go away. The thought was if you outsourced, you could just point at them and shirk all further responsibility.

In reality, you can outsource almost every function relevant to PCI, but you can NEVER outsource the responsibility for the protection of the cardholder data. Yes, you can throw financial liabilities into the contract, you can buy cyber-insurance, you can even drag your service provider down with you if things go horribly wrong, but it’s going to be YOUR name in the papers.

The other big mistake organisations make at the beginning phases of outsourcing is, as always, asking the wrong questions. While a service provider does not have to BE PCI compliant for the service they are providing, their services have to SUPPORT yours. Not only that, if they do not have a Report on Compliance backing up their services, they will have to be fully assessed and validated against yours.

I’ve had small clients whose PCI assessment costs and effort increased FIVE fold because they had not performed the correct due diligence.

Even if I assumed you are outsourcing for the right reasons, CHOOSING vendors is next step where things go wrong. DSS v3.0 has built in the requirement for  ‘third parties’ to qualify their services with detailed analysis of EXACTLY what is being provided against the requirements themselves. This was always a requirement in my mind, but rarely followed, and has led to significant gaps based on assumptions.

However, if if your chosen service provider is PCI compliant for the services, there is surprisingly little they can do in terms of reducing your effort;

1. DSS Requirement 1.x – You can outsource management, but you will always own the policies, the final configuration standard(s), and of course, the ruleset(s). About the only things that can be 100% outsourced is stageful packet inspection.

2. DSS Requirement 2.x – Again, you can have a service provider put together configuration standards for you, but you will always own them, the business justifications for every available service and listening port is yours to document, and insecure protocols are yours to fix or compensate for.

3. DSS Requirement 6.x – Outsourced development is great, but unless their SDLC supports your compliance, YOU won’t be.

4. DSS Requirement 10.x – The most egregiously overstated service provider coverage of them all. The issue is rarely in the collection of the events, it’s what events should be logged in the first place and how. And how ANY service provider dares to say they can cover a daily review without establishing a baseling is beyond me.

5. …and so on.

I’m already ay 700 words and I’ve barely starched the surface, but that should be an indication of just how messy this topic can be. It deserves a white paper, but that will have to wait.

Bottom line; If you don’t have a program for vendor selection and vendor management, get one, and make it retroactive. Get help if you need it, but in the end, if your service providers fail, YOU fail, and deservedly so.

Read the SSC supplement, implement what it says, they have not missed much.

[blank] as a Service. There are so many XaaS services available now that we are running out of letters:

  • AaaS – Authentication as a Service
  • BaaS – Back-End as a Service
  • CaaS – Communication as a Service`
  • DaaS – Desktop or Data as a Service
  • EaaS – Encryption as a Service
  • FaaS – Failure as a Service [I know, couldn’t believe this one myself]
  • …and so on.

As much as I have an issue with buzz-words and inventing acronyms, I cannot deny the trend that; Unless it’s a core function, don’t do it yourself.

Retailers should outsource payment acceptance, insurance companies should outsource cyber due diligence, and every business should outsource some of its security risk management.

Sure you can change the oil in your own car, you may even be able to perform some basic plumbing, but why would you? There’s an excellent chance that a professional can do it better, and in the long-run cheaper, than you. What’s more important; saving money, or saving your time? I guess the answer is different for everyone, but a business does not have the luxury of experimentation to the degree we do. False economy, while relatively trivial for us, can be make or break to a business.

I see a time where the economies of scale, combined with the abundance of competition will enable service providers to give far better service at a much lower price-tag that you could possibly hope to achieve in-house. Doing one thing and doing it well should automatically provide the necessary scalability of service, appropriate innovation and business transformation capability necessary to run a competitive venture in the 2010s and beyond.

Even in the cybersecurity industry, there is significant confusion on how to choose the right vendor or technology, and this will only increase exponentially in the era of The Outsourcing of Everything. Inevitably there will come along a new type of service provider; the Service Provider Integrator. In the same way you cannot manage your security if you have 15 different management stations, you cannot run your business if your service providers are not performing seamlessly, and in full support of your business goals.

In the Information Age, where entire businesses can be run in the virtual world, a competitive edge lasts weeks, not years, and only the organisations who can effective balance risk and innovation, and then transform their business processes in support of that innovation, will succeed. And with everything outsourced, only the companies who are best able to chose, then integrate the most effective and flexible services, can hope to compete. The best Service Provider Integrators will be able to create entire white-labeled businesses from any concept.

In one of my earlier blogs; How Information Security Enables Transformational Change, I made the statement; “Information in context is knowledge, success however is in the correct application of that knowledge.”. The drive towards specialisation will accelerate in every service to be provided. It will be the organisations that are best able to correlate both the management information gathered over years of providing a specific services to multiple organisations, along with the ability to apply those skills to prospective clients, who will run away with the business. This will eventually create new Googles and Amazons, but they are where they are for a reason;

Good service.

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

========================

Update 22-Oct-13 09:23: Don’t normally add bad language to my posts, but this is too funny not to; www.foaas.com. My thanks to Steve R!

Remember when CheckPoint were just firewalls, Symantec were just AV, and security companies could just provide consultancy?

Neither do I, it’s been too long.

Security has now become too complex, and too important to play the mix-and-match game with individual vendors, it’s only integrated, multi-function, solutions that will now make the cut.  But there are so few of them out there.  Well, so few that actualy do what they say they do anyway.

As security became a multi-billion £/$/€ a year industry, hundreds of companies started up to bring us the silver bullet appliances that will end our problems forever.  Not only do silver bullets not exist in security – and you should be shot for using the phrase in any way that’s non-derogatory – but where are those companies now?

They either failed, or have been bought up by larger companies who have tried to duct-tape the disparate products into silver-bullet SOLUTIONS.

Which have also failed.

It’s not that the products don’t work, some of them actually do, it’s that;

  1. Businesses threw technology at problems without knowing WHY they were doing it
  2. The big companies that collected the smaller ones tried to integrate the individual products together under one GUI, instead of unifying the functionality under a single code base
  3. There has never been, and there never will be, a one-size-fits-all solution to security

But the market is still ripe for innovation, and there will continue to be companies starting up with the goal of bringing a single product to market that will catch the latest security hype/wave/buzz and make them their fortunes (MDM for example).  They may even succeed, but only if they make their impact in the first year or two, otherwise the market will have moved on.

If they’re VERY lucky, the larger companies that collect little ones will be naive / ignorant enough to buy them and save them the trouble.

I am not against combining single products into a larger solutions, in fact it’s the only way to go, but only if it’s done correctly.  Single product companies have 100% focus, which gives them drive, goals, and a dedication to making their one product the best. The second you absorb that company, every one of those attributed that put them on (or near) the top, is lost in the larger mix.  The functionality is diluted, innovation ceases, and the the whole thing quickly becomes obsolete.

True integration of functionality can only be accomplished with a single code base, and a single platform, which means that any organisation that absorbed the smaller companies better have a plan in mind to migrate not only the applications over to their growing solution, but they will need to consider all of the clients who bought the product prior to the M&A.  These guys often suffer from a total lack of customer service and support, and there’s no way they’ll buy into the larger programme.

From what I have heard, the due diligence necessary to combine product companies is not overly abundant, and until it is, we should all be VERY careful when we look to resolve our security issues with multi-function solutions.

That’s why I call these ‘collage companies’, as the picture might be pretty, but it’s in no way whole.

Here are a few questions you might want to ask your potential providers;

  1. Can your solution replace some / most of my current functionality?
  2. Do you provide a consultancy ‘wrapper’ around these solutions to help us manage them against our business goals?
  3. Will the output from your solution feed into my current collection mechanism, or can my current output feed into yours?
  4. Are the various aspects / functions of your solution ‘home grown’, or obtained through acquisition?  If acquisition, how have you unified the back end code and platforms?
  5. How do you ensure that the different functions of the solution receive a similar attention to what the single product vendors provide?
  6. Do you have a single customer support process to handle all functionality questions?

Regardless of the shenanigans going on in the security product market, your choice of vendor should only be driven by what your risk assessment and gap analysis said you need, and your due diligence should cover any requirements you may have regarding integration and ongoing maintenance.

If is doesn’t, don’t expect the collage companies to help, they have enough problems keeping their own houses in order.

Choose wisely.