Archive for the 'service provider' Category

28
Apr
17

The Five Stages Of PCI

Had a meeting with a prospect recently that is bound and determined to avoid PCI compliance yet still will accept payment cards.

My response?  Good luck with that!

You would think after 15 years of PCI (and actually even longer) that people would understand that PCI compliance is a fact of life.  But I continue to find that PCI is no different than the five stages of grief.

Denial

This is where that prospect is now.  They cannot believe that there is no way to avoid PCI compliance.

For once and for all, if your organization accepts payment cards, you MUST comply with the PCI DSS.  Do not like that answer?  There is nothing as a QSA I can do to effect that fact.

However, for merchants there is a way out.  Do not accept payment cards for payment.  It is that simple.

That answer though immediately leads to the next stage.

Anger

I once had a prospect tell me very emphatically that PCI was unenforceable.  I asked them if they had read their Merchant Agreement with the bank that allowed them to accept payment cards for payments.  To my astonishment they said, “What the [expletive] does that have to do with anything?”

You can be angry all you want but PCI compliance is a legal, contractual requirement documented in the Merchant Agreement, Card Operating Rules and other documentation referenced in those documents.  Someone in your organization signed that Merchant Agreement – most likely your Chief Financial Officer (CFO), Controller, Treasurer or heaven forbid – the person that is blowing their cork.  That is the person you should share your anger with, not me.  As a QSA, I am just the messenger.

Anger is even worse with service providers.  Particularly those that provide services tangential to card processing such as those that provide network, firewall or server management services.  They had no idea that their customer(s) needed them to be PCI compliant because they never realized that their service(s) could affect the security of payments.  These folks get totally blindsided by PCI compliance and hence their anger.

I have found that anger over PCI can last a long, long time with some organizations and people.  I still have clients that are angry about it.  It may be less aggressively displayed, but you can tell that they are still angry.

Bargaining

A lot of organizations get stuck in this stage.  They are bound and determined to find that “silver bullet” that somehow magically gets them to PCI compliance with the minimum amount of effort (i.e., none).  They know it is out there and all they need to do is find it.

Because of this stage and the fact that organizations get stuck in it, there are any number of “snake oil” PCI compliance solutions that prey on those in the ‘Bargaining’ stage.  All of them have “The Solution” that will solve your organization’s PCI compliance problem.  They have a pitch for every day of the week and for every situation.  Just ask them.  But at the end of the day, all of these solutions just address one or two PCI compliance issues and do not result in that magical “silver bullet” that those in this stage continue to seek.

Another indicator of organizations stuck in this stage are that they go through compliance and IT leaders like a teenage girl goes through boyfriends.  You immediately know an organization is in the ‘Bargaining’ stage as a QSA because you are always dealing with someone new every year.

Another telltale of a ‘Bargaining’ stage organization is that they are constantly arguing with their QSA over what PCI DSS requirements they need to comply.  PCI is not anything at all like “Let’s Make A Deal”.  It gets even worse when they argue the PCI DSS like it is a legal document and you get discussions over the meaning of the word ‘is’.  At the end of the day, your QSA or acquiring bank cannot cut you a deal on what PCI DSS requirements your organization can ignore.

The bottom line is that the absolute least level of PCI compliance any organization can have are the requirements documented in SAQ A.  Period.  There is nothing less than those requirements.  And SAQ A requires that an organization totally outsource to a third party everything related to card processing.  And I do mean everything.  Nine times out of ten, complete outsourcing is unacceptable to organizations who demand control over their business processes and the “look and feel” of their operations.

Depression

Once an organization realizes that there are no “silver bullets”, depression quickly sets in.  With some clients you can see depression get deeper with every data breach announcement that hits the media.  All they can imagine is that their organization is next.

Then there is the fact that PCI compliance is going to cause changes and cost people, time and money to address compliance gaps.  This is where a good QSA can be of great help.  A good QSA can give you options to minimize those resources.  Good QSAs understand that most merchants do not exist on huge margins and that investments with an ROI of more than three years are very painful and difficult to justify.

Unfortunately, in a lot of cases, there are not a lot of options available and even good QSAs are not miracle workers.  This is particularly true when the organization has not invested in infrastructure and application software in a long time.  Worse is when they have invested (usually heavily) in one or more of those “silver bullets” from the ‘Bargaining’ stage and they assist in their compliance efforts only minimally.

Acceptance

I would like to tell you that I have a lot of clients in this stage, but I do not.  Although the number is growing slowly but surely.

But the good news is that if you can get your organization to this stage, there are benefits.

The biggest benefit in my view is that organizations in Acceptance “get” security and why it is a necessary “evil” in today’s ever more connected world.  Never mind the PCI component.

Those at this stage are great to deal with because they have taken steps to minimize their PCI scope and simplify their card processing as much as possible.  They have standardized processes.  They understand that PCI compliance improves their organization’s security.  And not just for the security of cardholder data but for the security of all sensitive information and the whole organization.  Their investments in PCI compliance have paid off (sometime in spades) as they simplified their operations and got rid of sensitive information that they have no longer deemed necessary to retain.

A lot of organizations in this stage have integrated some or all of the PCI DSS requirements into their everyday operations.  As a result, PCI compliance is a daily affair, not the once a year fire drill that it is for most organizations.

These organizations are not perfect by any sense of the word.  But they are a level or more above other organizations and that is all it takes.  Because information security is no different than those movies that show a herd of animals being chased by a lion or tiger.  To survive, you just have to make sure that you are not one of the weakest animals in the pack.  Or as a friend of mine has said for years, “My security program does not have to be the best, just better than yours.”

24
Mar
17

Service Provider AOCs and Section 2g

It is becoming obvious that there are a lot of QSAs out there did not get the message when v3 of the PCI DSS came out and the new AOC for service providers was introduced.  This has been a big topic at the last few community meetings as well and recently became a big topic with a number of my clients as I continue to see service provider AOCs that are not correct.  I have even mentioned this problem already in a post about service providers, but the problem continues.

As a result, I have decided this is a great time to discuss the problem and get everyone to ensure it is fixed so that we stop the arguments over something that is clearly documented in the service provider AOC form and needs to be done correctly.  Because there is no excuse for messing this up.

Section 2a

Before we get to the actual problem, we need to talk about section 2a in the service provider AOC as it drives the problem.

PCI AOC SP Section 2a

In section 2a of the service provider AOC, a QSA is call out in the ‘Name of service(s) assessed’ and to check every box in the ‘Type of Service(s) assessed’ for every service named as part of the service provider’s PCI assessment.

QSAs seem to be doing very well in checking the appropriate boxes for ‘Type of Service(s) assessed’ on the AOCs that I encounter.  However for the ‘Name of service(s) not assessed’, QSAs seem to not necessarily doing quite as well.  The reason will become obvious when I discuss section 2g.

One important note though.  When checking the ‘Others’ box (or any of the ‘Other’ boxes), please make sure to list ALL the other services that were assessed and NEVER, EVER use “etc” in that explanation.  All the services in the ‘Others’ category MUST BE listed individually and specifically.  Again, this will become obvious as to why when we get to section 2g.

And before we move on, I get questions about cloud services, i.e., SaaS, PaaS and IaaS.  Those are services and should be listed as such in the ‘Name of service(s) assessed’.

Section 2g

PCI AOC SP Section 2g

Notice that shaded ‘Note’ that is in bold and italics that states:

“One table to be completed for each service covered by this AOC. Additional copies of this section are available on the PCI SSC website.”

What this note means is you need to have the same number of section 2g’s as you have named services in section 2a.  And this is where a lot of QSAs and their QA reviewers are going wrong with their service provider AOCs

For example, if you have named five services in 2a, there had better be five pages of 2g filled out.  One for each of those five named services.  By the same token, if you are relying on check boxes under the ‘Type of Service(s) assessed’ section to define the services covered, then you should call those out separately in 2g.

The bottom line though is that, however a QSA breaks things out, there must be multiple 2g sections for each individual service provided.

In some very rare instances there can be some services that might have the same coverages/responsibilities for the requirements in the matrix and those may be combined into one table.  The Council has even said as much in clarifying this form.  However the Council has also been very clear that when combining those services into one 2g section, those services MUST have EXACTLY the same responsibilities and that is where a lot of QSAs get into trouble.  So the recommendation I would make is just do one 2g for every service and stop trying to combine things.

Now the QSAs that I have had discussions (arguments) with over their flawed service provider AOCs always bring up the fact that the AOC Word document is locked and they cannot make changes.  I always point them back to that ‘Note’ in 2g which states:

“Additional copies of this section are available on the PCI SSC website.”

According to the guidance provided by the Council at the Community Meetings, QSAs are to append those additional 2g sections to the end of the AOC.

That said, some of us in the QSA community have unlocked the Word document (NOT approved by the Council) and just copy section 2g and insert it inline in the AOC for the number of services we need sections for and fill them out.

One final note about section 2g.  Please follow the instructions to the letter when filling out the table/matrix for the service.  I cannot tell you the number of those that I encounter where ‘Partial’ or ‘None’ are checked and then there is nothing documented in the ‘Justification’ column.  The instructions are very clear in how you are supposed to fill the ‘Justification’ column out so there is no excuse for leaving it blank.

And for the merchants that have to deal with these service provider AOCs.  It is up to you to police these documents.  If you receive an AOC and it is not properly filled out, it is up to you to point out your concerns to the service provider.  If the service provider does not address your concerns, you have a couple of options at your disposal.

  • Contact the PCI SSC with your concerns at qsa@pcisecuritystandards.org. Document your concern(s) in your email as well as including the AOC in question.
  • If the service provider is listed on either the Visa or MasterCard service provider lists on their respective Web site, you should notify them as well. This is because both of those card brands should have caught this error before listing the service provider on their Web site.  For Visa, go to http://www.visa.com/splisting/learnmore.html and use the appropriate email address for your region under the PCI DSS Validated Service Providers row.  For MasterCard, use the pcireports@mastercard.com email address and as with the Council document your concern(s) in an email as well as including the AOC in question.

By contacting the Council, you will provide the Council feedback that a QSAC is not conducting their assessments for service providers appropriately and that the Council may need to conduct an assessor quality management (AQM) process for that QSAC.

Notifying the card brands will do two things.  It will point out a potential flaw in their service provider listing process that needs to be addressed.  But it could also potentially put the service provider in a different status on the card brands’ lists.

21
Mar
17

Stripe Questions Come Back

I have had a couple of readers ask this question, so I thought it was time to go back and take a look at it again.  It has been since 2013 that I first brought up Stripe as a potential compliance scoping issue.

The question being posed is:

“How can Stripe claim on its Web site that its JavaScript checkout solution allows for a merchant to use SAQ A?”

The first thing to notice is the sidebar regarding the various Stripe solutions.  There are three distinct solutions offered by Stripe:

  • Checkout
  • Elements
  • Stripe.js (the original solution)

In the PCI DSS Guidelines section is the following:

“Elements and Checkout host all form inputs containing card data within an IFRAME served from Stripe’s domain.

As long as you serve your payment pages over TLS, and use either Checkout or Elements as the only way of handling card information, Stripe automatically creates a combined SAQ A and Attestation of Compliance (AOC) for you.”

The first important point is that, if a merchant is using the Stripe.js solution, it does NOT qualify for the SAQ A.  This is the original solution that I wrote about back in 2013.  But the fact that Stripe.js is not SAQ A eligible is an important point for all developers to note as it could easily be missed.

What has changed is Stripe has created two new methods for processing payments: Checkout and Elements.  Those methods create an iFrame that, in theory, would comply with scope minimization and allowing SAQ A to be used by the merchant.

But, this statement “As long as you serve your payment pages over TLS, and use either Checkout or Elements as the only way of handling card information …” is all in the execution by the merchant’s Web site as not all iFrames are created equal.  What a merchant and their developer must do is ensure that the iFrame is created ONLY on the customer’s PC and NOT on the merchant’s Web server.  If done that way, then the statement regarding SAQ A is accurate.

The reason I bring this fact up is that I have encountered solutions using an iFrame but where the iFrame is built on the merchant’s server and not in the customer’s browser.  The merchant points to the fact that the solution is an iFrame and therefore their Web server out of scope.  However, since the iFrame is constructed on the merchant’s Web server and then sent to the customer, it is no longer eligible for SAQ A and the merchant must follow SAQ A-EP.

As a result, it is important that a QSA look very closely at how a merchant’s Web site executes to ensure that the iFrame is never created on the merchant’s Web server.

Based on the examples of what I saw regarding the Checkout and Element solutions, as long as the code samples for Checkout or Element only execute in the customer’s browser, SAQ A would be a valid assessment option.

15
Mar
17

Why We Should Be Concerned About The Verifone Breach

On March 7 Brian Krebs broke the news that Verifone, one of the largest card terminal manufacturers, has suffered a breach. The next day Verifone told the world that the breach was no big deal. No big deal right? Probably not and here is my rationale.

For those of you unfamiliar with Verifone, Verifone is not only a manufacturer of points of interaction (POI, aka card/transaction terminals), it also provides transaction processing services to merchants. As a result, any breach of such an organization puts a lot of the security of the card processing ecosystem at tremendous risk.

Extent Of The Breach

Here is what Verifone has told us about the extent of the breach.

“According to third-party forensic teams, this cyber attempt was limited to approximately two dozen U.S. gas station convenience stores and occurred over a short time period. No other merchants were targeted and the integrity of our payment networks and Verifone’s payment terminals remained secure and fully operational.

Verifone’s information security team identified evidence of this very limited cyber intrusion into our corporate network in January 2017, and we proactively notified Visa, MasterCard and other card schemes.

In concert with our partners, Verifone immediately implemented additional security controls across its corporate networks and began work to determine the type of information that may have been targeted.

It is also worth noting that there have been no adverse events or misuse of any data resulting from this incident. Verifone, partner agencies, and law enforcement remain vigilant and will continue to monitor for this.

We believe that our immediate response and coordination with partners and agencies has made the potential for misuse of information extremely limited.”

The first thing that any forensic examiner will tell you is that determining the extent of a breach is not a trivial process. It takes time. Most times, a lot of time. The reason is that attackers can be very stealthy in how they cover their tracks by wiping logs, leave behind malware/backdoors, and other techniques to obscure what they did and how they did it.  Even though Verifone took almost two months to acknowledge the breach and tell everyone that things are fine, all may not necessarily be well within Verifone.  But only time will tell if that is true.

The troubling thing about Verifone’s statement and likely demanded by their lawyers is the wording at the very end of their statement as they start their last sentence – “We believe”. Legalese that will give them an out should their forensic teams find more issues or issues turn up later.

“Asked about the breach reports, a Verifone spokesman said the company saw evidence in January 2017 of an intrusion in a “limited portion” of its internal network, but that the breach never impacted its payment services network.”

This was followed up by an update by Mr. Krebs after his original post. Verifone stated:

“According to the forensic information to-date, the cyber attempt was limited to controllers at approximately two dozen gas stations, and occurred over a short time frame. We believe that no other merchants were targeted and the integrity of our networks and merchants’ payment terminals remain secure and fully operational.”

Hold on a moment.  What is a “short time frame”?  Oh, and by the way, the attackers had access to controllers and around two dozen gas stations?  And then there is that “According to the forensic information to-date” comment.  That statement would seem to imply that Verifone is not necessary complete with their forensic examination.

So did Verifone or someone else find this breach?

“But a source with knowledge of the matter told KrebsOnSecurity.com that the employee alert Verifone sent out on Jan, 23, 2017 was in response to a notification that Verifone received from the credit card companies Visa and Mastercard just days earlier in January.”

So like most organizations, they were notified by a third party that they likely had been breached.  In this case, two card brands recognized fraudulent transactions that came from merchants serviced by Verifone.

But follow that statement with this one regarding what happened once they were notified.

 “Verifone’s information security team identified evidence of this very limited cyber intrusion into our corporate network in January 2017 …”

My concern with this and the prior statement is that it takes a while for the card brands to recognize fraud.  I have seen it take brands as little as a month to as much as two years for the brands to notify a merchant or service provider that they think there has been a breach.  The reason is that it depends on the extent of the breach (i.e., small versus large merchants, small versus large service provider(s), number of transactions/cards involved), how quickly the cards are used for committing fraud, how quickly those fraudulent transactions are reported back to banks by their customers, how quickly the brands determine a pattern and then that pattern traces back to a likely source or sources.  As a result, I am very suspect as to how long the intruders were in their network and the likelihood that the intrusion was truly as “limited” as Verifone is leading us to believe.

The bottom line in all of this, in my very humble opinion, is that this could just be the tip of the iceberg and this breach could be more extensive than Verifone knows and could have larger ramifications.

Why You Should Care

Given that I suspect that the attackers were in Verifone’s network for a while, I would assume that not just Verifone’s service provider operation was targeted and compromised.

The first clue to this suspicion is that Visa and MasterCard were the ones that notified Verifone that something was going on.  As I stated earlier, the brands take a while to determine a breach which likely means that the attackers were inside Verifone for more than just a short period of time.  In addition, it is rare that PANs collected in a breach are used immediately after they are obtained.  The reason is that there are bigger rewards if they are not used immediately.

The next piece clue in our puzzle is this statement from the Krebs post.

“The source said his employer shared with the card brands evidence that a Russian hacking group known for targeting payment providers and hospitality firms had compromised at least a portion of Verifone’s internal network.”

If this is accurate then it is highly likely that not just card information was gathered.  What also was likely gathered was source code to things like card terminal firmware and software such as Verishield, Verifone’s end-to-end encryption (E2EE) solution.  Any attackers that are focused on targeting payment providers would know that if they were inside of an organization that provides such solutions as Verifone that they should get their software as well as cardholder data (CHD).  If you have the ability to exfiltrate CHD, why not exfiltrate other useful information such as source code, certificates, encryption keys and other sensitive information.

The only good news in this regard is that while a lot of transaction gateways and processors use Verishield, they all have their own certificates and encryption keys.  So the attackers would have only gotten certificates and keys for the merchants processing through Verifone.  Since Verifone is an encryption endpoint, it is possible that the attackers did not get the certificates or encryption keys because they would not necessarily need them to get at the clear text CHD.  However one should ever assume that is the case.

Now What?

The net of all of this is that if you have Verifone terminals and/or Verishield or other Verifone applications, you should probably be doing a lot more monitoring of that hardware and software since there is no reason to believe that it has not been compromised.

It will be interesting as time goes on to see if this is the end of the discussion or if more will come out on the Verifone breach.

07
Mar
17

Verifone Investigating Breach

Just a quick note to everyone since this could affect a lot of merchants and service providers.  Brian Krebs is reporting that Verifone is investigating a possible breach of their systems.  More on it here.

11
Feb
17

The Council Gets A Clue

Late this week the PCI Security Standards Council issued a new information supplement titled ‘Multi-Factor Authentication’ after the brew-ha-ha that occurred last fall at the Community Meeting in Las Vegas.  For once, the Council has issued an excellent reference regarding the issues of multi-factor authentication (MFA).  Although I still have a couple of minor bones to pick about this document, but more on that later.

If you understand the concepts of MFA, you can skip through the document to the end where the Council presents four scenarios on good and bad MFA.  These are well documented and explain the thought process behind why the scenario works or does not work for MFA.  The key takeaway of all of this is the independence of the MFA solution from the logon process.  The Council is getting in front of the curve here and stopping people from creating insecure situations where they believe they are using MFA that minimizes or stops breaches through administrators or users with access to bulk card data.

Now for a few things that I do not necessarily agree with in this document.

The first involves the Council’s continued belief that hardware security modules (HSM) are actually only hardware.  On page four, the following statement is made.

“Hardware cryptographic modules are preferred over software due to their immutability, smaller attack surfaces, and more reliable behavior; as such, they can provide a higher degree of assurance that they can be relied upon to perform their trusted function or functions.”

The Council has made similar statements over the years in the mistaken assumption that HSMs are only hardware.  HSMs are hardware that use software to manage keys.  There are standards that are followed (e.g., FIPS 140) to ensure that the HSM remains secure, but these devices are predominately software driven.  That is not to say that just any device can serve as an HSM, but a lot of us in the security community are concerned that the Council continues to perpetuate a myth that HSMs are only hardware which is patently false.

My other issue comes on page six as part of the discussion regarding the use of SMS for MFA.

“PCI DSS relies on industry standards—such as NIST, ISO, and ANSI—that cover all industries, not just the payments industry. While NIST currently permits the use of SMS, they have advised that out-of-band authentication using SMS or voice has been deprecated and may be removed from future releases of their publication.”

While everything in this statement is accurate, it gives the uninitiated the impression that SMS or voice is no longer a valid MFA solution.  I know this to be true because I have fielded some questions from clients and prospects on this subject, particularly about SMS.  The key is that this is not SSL and early TLS where NIST called them out as insecure and to no longer be used.  This is a “heads up” from NIST to everyone that there is an issue that makes SMS and voice not secure enough for MFA.

But while there is a risk, a lot of us in the security community question the viability of that risk when matched against merchant risk versus a bank or a government agency.  While I would not want any bank or government agency to use SMS or voice for MFA, a small business may not have a choice given their solution.  The reason is that the risk of an attack on SMS or voice is such that only a high-value target such as a bank or government agency would be worth such an effort.  In my very humble opinion, while a total ban is the easy solution, this is an instance where the Council should take a more nuanced approach toward the use of SMS and voice for MFA.  The bottom line to me is that small merchants using any MFA solution, even if flawed, is better than using no MFA solution.

I would recommend the following approach to manage this risk.

  • Level 4 merchants can be allowed to use SMS or voice for MFA.
  • Level 1, 2 and 3 merchants would be allowed to transition away from SMS and voice to a more secure MFA solution within one year of NIST stating that they are no longer acceptable.
  • All service providers would not be allowed to use SMS or voice for MFA once NIST states that both are no longer acceptable. This means service providers should start transitioning now if they use either.

Those are my thoughts on the subject.  I look forward to the comments I am sure to receive.

18
Jul
16

Third Party Service Provider PCI Compliance

This has recently become a very hot topic as more and more businesses get serious about controlling their supply chains not only for PCI but for information security in general.  It has only taken three years after the Target breach for organizations to really understand that their computer systems and networks are all part of a larger technology ecosystem and that their security depends on the security of everyone else they are connected.  This post provides guidance for service providers and merchants alike.

The first question that can come up is what is the difference between a third party and a service provider?  Technically there is no difference.  “Third party” is a term that comes from the financial audit industry which is where I first encountered it a long time ago.  Third parties are those outside organizations that provide services under contract to another organization.  Examples can include services such as office cleaning, facility management, mailroom management, lock box services, secure document destruction, human resources and a whole host of other business services.

In today’s complex corporate structures, functions such as information technology or human resources as well as whole business units can be separate legal entities and provide business services to other parts of the corporation.  While not truly outside organizations, for regulatory assessments they may also be treated as third party organizations.  I have a number of large clients that take this approach because it simplifies their audit/assessment and compliance reporting processes.  However if a merchant or service provider is going to take such an approach, it should be discussed with their acquiring bank and/or the card brands to obtain their formal approval before assessing and reporting under that approach.

What Organizations Are Service Providers?

The next question that comes up is what organizations qualify as a third party service provider under PCI?  The PCI SSC defines a service provider in the PCI DSS Glossary as:

“Business entity that is not a payment brand, directly involved in the processing, storage, or transmission of cardholder data on behalf of another entity. This also includes companies that provide services that control or could impact the security of cardholder data. Examples include managed service providers that provide managed firewalls, IDS and other services as well as hosting providers and other entities. If an entity provides a service that involves only the provision of public network access—such as a telecommunications company providing just the communication link—the entity would not be considered a service provider for that service (although they may be considered a service provider for other services).”

Under that definition any third party organization that directly processes, stores or transmits sensitive authentication data (SAD) or cardholder data (CHD) are service providers.  Examples of these organizations are transaction gateways, transaction processors and some loyalty program providers.  One notable exception is acquiring banks.  Acquiring banks are only third parties if they provide services in addition to being an acquiring bank such as card terminal management and transaction processing.

Where things get messy is third party service providers that do not directly come into contact with SAD or CHD but could come into contact with it.  While I have written two posts on this topic, there still seem to be a lot of managed service providers in denial over whether they need to be PCI compliant.  The bottom line is that if you are a service provider and you could impact the security of SAD/CHD, you must comply with the PCI standard (see PCI SSC FAQ 1092).

But that is where complaints and arguments from such peripheral service providers focus.  Most have no idea if their customers need PCI compliance unless they ask or get asked by a customer.  As a result, they tend to argue that because they do not know they do not need to comply.  Unfortunately, ignorance and/or lack of knowledge are not a valid reason to not be PCI compliant.  That is why it is incumbent for all service providers to ask every customer and prospective customer if they require PCI, HIPAA, GLBA or any other regulatory compliance so that the service provider can ensure that they can properly comply with those requirements.

Service Provider Levels Explained

Service providers, like merchants, are categorized into levels by the card brands.  The most commonly referenced service provider levels are those defined by Visa, MasterCard and Discover.

  • Level 1 service providers conduct 300,000+ transactions annually on behalf of their customers, and
  • Level 2 service providers conduct less than 300,000 transactions annually for their customers.

JCB and American Express have their own service provider level definitions, but there are very, very few service providers that only process exclusively for those brands.  If you are one of those rare service providers, I would tell you to visit the appropriate brand’s Web site and review their service provider level definitions.

Level 1 service providers must conduct a PCI assessment that results in a service provider Report On Compliance (ROC) and related Attestation Of Compliance (AOC).  That assessment can be conducted by a QSA or an ISA just as with merchant PCI ROCs.  Level 2 service providers can use either the service provider SAQ D or create a service provider ROC.

These levels also add confusion to those service providers that do not process or transmit any transactions.  As they rightfully point out, their transaction volume is zero.  I then point out to them that zero is less than 300,000, so they are considered a Level 2 service provider.  Problem and confusion solved.

The most important thing to understand about service provider levels are that if your organization is a service provider level 1 for any card brand, your organization is a level 1 for all card brands.

The next important thing to note about these assessment processes is that they must use the service provider specific SAQ D, ROC and AOC forms.  I cannot tell you the number of times I have gotten a service provider’s AOC and/or SAQ/ROC and it is not the service provider specific version.  More on this topic later.

The Global Registries

Once we get these third parties to admit they are in scope for PCI compliance, the next issue that typically comes up is in regards to the card brand global registries for service providers.  Both Visa and MasterCard have public registries of service providers on their respective Web sites.  These are strictly marketing schemes run by the respective brands and it is not mandatory that service providers be listed on either of these lists.  Since they are marketing schemes, they have no real meaning regarding any merchant organization’s PCI compliance and are not a substitute for getting an AOC from a service provider.  What they do provide is a quick way for merchants to find PCI compliant service providers providing services they wish to outsource.  As a result, a lot of service providers like to be listed on these Web sites just so that merchants will consider them.

To be listed on either of these Web sites, the service provider must have a PCI QSA (an ISA cannot be used) conduct an assessment and then the QSA must file the resulting compliant ROC and AOC with the appropriate card brand.  In the case of service providers that process or transmit SAD/CHD, they will have a relationship with a bank that must sponsor the service provider with the brands to get listed on the Web site.  For service providers that do not have a relationship with a bank because they do not process or transmit SAD/CHD, those service providers must contact the appropriate card brand who will then sponsor them.  Once approved by the brand, the service provider then pays a fee to be listed.  To stay listed on the brands Web site, the service provider must annually revalidate their compliance using a QSA, have the QSA file their compliant ROC/AOC with the brand and pay a renewal fee.

To add confusion for service providers, Visa also maintains a separate, private inventory of service providers.  This list is for Visa and their acquiring banks to reference and is not available to the public.  Visa is trying to ensure that all service providers are tracked for their annual PCI compliance even if they do not register for their public Global Registry.  So if you are a service provider and are filing a service provider SAQ D/ROC or you do not register for the public Global Registry, you will be asked to fill out information for this private Visa service provider inventory.

Service Provider AOC Issues

The most common AOC problem we encounter with service providers is that they only assess some of their services provided, not all of their services.  For third party run data centers the most common requirements assessed are requirements 9 (physical security) and 12 (policies) but no other requirements are assessed even if that same firm provides managed services such as network security, network monitoring, virtualization, server management and network management.  I will address this situation later on in the post when discussing service providers that do not have a PCI assessment.

The next most common problem is that the AOC provided to the merchant is not a service provider AOC.  The biggest problem this mistake creates is that there is no way to know what services provided to the merchant were assessed for PCI compliance.  Then you have a very embarrassing conversation for all involved as you inform the service provider that their PCI compliance is reported on the wrong form(s).  Worse is the fact that most times this results in a whole new assessment being conducted because service provider requirements were not assessed and too much time (i.e., more than 90 days) has passed since the assessment was completed.

With the introduction of v3 of the PCI DSS, the service provider AOC has had a number of changes to facilitate merchants’ evaluation of the service provider’s PCI compliance.  The first change was to list not only what services were assessed in section 2a, but what services were not assessed.  Then for each service that was assessed, the QSA/ISA is required to individually document in separate sections of 2g of the AOC which of the 12 requirements were tested for each service.

Which brings us to the third most common problem.  The AOC does not document each service individually in section 2g.  As I stated earlier, this was a change with v3, but many QSAs/ISAs did follow the instructions in the section.  In addition, the Council has not helped this situation as the AOC document is locked so adding additional sections for 2g are not possible using the Council’s form.  The Council’s advice is to copy that section and then paste additional sections as necessary to the end of the AOC.

Another situation that we occasionally run into is service providers that have gone through the PCI assessment process but refuse to provide their customers with a copy of their AOC.  Reasons for not providing the AOC vary (from the stupid to the absolutely idiotic), but it happens more often than I would like to admit.  The PCI SSC has repeatedly reinforced at their Community Meetings and in FAQs that if a service provider has been independently assessed, they must provide their service provider AOC to their customers.  If you encounter such a situation, I would recommend contacting the appropriate card brands and complaining to them about the service provider particularly if that service provider is listed on the card brands’ public Global Registry.  In most cases, such complaints will result in the brand suspending the service provider’s listing until they comply.

The last problem we encounter with AOCs is their timing and availability.  In a perfect world, every service provider would have an AOC less than a year old available for every customer.  But in the real world, a merchant conducting their assessment encounters service providers that either: (a) are also in the process of conducting their assessment, (b) had their assessment delayed and will not be able to provide an AOC by the time the merchant’s assessment is completed, or (c) does not have an AOC.

The first two conditions are timing issues and should not be a problem unless the service provider has not been compliant in the past.  As the Council has repeatedly pointed out, no organization’s PCI compliance is affected by the PCI compliance of any other organization.  In addition, the Council has also said that the PCI assessment process are not conducted to the standard of an AICPA SSAE 16 assessment which needs reliance on third party assessments.  As a result, you need to work with your QSA/ISA, bank and service providers to agree to an approach to handling these first two conditions.  My recommendation is as long as there is close to a year between assessments (give or take 30 to 60 days), I would accept whatever current AOC is available from the service provider.  For situations where there is going to be significant differences in time, I would consult with your acquiring bank or the card brands.

It is the third condition that creates the most heartburn for a merchant and the service provider.  In this situation, a merchant has no choice but to include that service provider as part of the scope of their PCI assessment (see PCI SSC FAQs 1065 and 1290).  Most of the time, this is covered under the service provider’s contract under a section regarding regulatory and legal compliance audits and assessments.  The service provider agrees to allow the merchant’s staff or authorized representatives to conduct any audits/assessments whenever required.  In very rare situations, I have encountered older contracts that do not have such audit/assessment provisions and it becomes a painful issue to get the service provider to comply with the assessment process.

However, this third condition creates a larger scope and will result in increased costs for a merchant’s PCI assessment.  Sometimes that increase can be extremely significant if the service provider is doing a substantial amount of the work that needs to be evaluated such as hosting and managing a merchant’s IT environment.  While QSAs try to minimize the occurrence of this sort of situation when scoping engagements, they still encounter it as the merchant is confused and does not understand the implication of their decision to use a non-PCI compliant service provider and their responsibilities under the PCI DSS and their Merchant Agreement.  As a result, the QSA does not get accurate answers to their scoping questions and does not find out about the service provider’s involvement until they are performing the assessment.

Non-PCI Compliant Service Providers

Before discussing this, I first need to dispel a myth.  Nowhere does the PCI DSS require a merchant to use only PCI compliant service providers (see PCI SSC FAQ 1312).  That is a requirement specified by certain card brands in their Merchant Agreements (most notably Visa and MasterCard).  Therefore not using PCI compliant service providers does not and should not result in a PCI compliance issue provided they are assessed as part of the merchant’s assessment as stated earlier.

Getting back to the topic at hand.  As an example, you have a service provider AOC and it says that section 8 is not compliant (with the latest changes in v3.2 for service providers, this is a situation that is becoming more and more common.)  As a merchant, what do you do?

This is where requirements 12.8 and 12.9 come into play as part of an organization’s vendor management process.  As part of your organization’s vendor management process you should have the following processes, at a minimum, in place.

  • Have a complete inventory of service providers including the date of their last AOC, expected receipt date of their next AOC, and whether the current AOC was PCI compliant. If not PCI compliant, it should note for each service provider those areas of non-compliance and the dates each area will be compliant.
  • For any non-PCI compliant service providers, periodic meetings need to be held with the non-compliant service provider to obtain updates on their remediation efforts. Depending on the duration and complexity of the project(s), these meetings may be conducted quarterly, monthly or even weekly.  However notes need to be kept for all of these calls and information updated as to the project(s) status.  These updates should not be suspended until the service provider is judged PCI compliant.
  • Any adverse changes in remediation efforts status should result in a review of the service provider and possibly result in seeking a new PCI compliant service provider.
  • To be judged compliant, the service provider must have a QSA/ISA submit proof (for example, a letter outlining evaluation procedures followed with a revised AOC) that they have evaluated the remediation efforts and that those efforts are complete and the PCI requirements in question have been judged PCI compliant.

The most important take away in this whole discussion regarding non-PCI compliant service providers is that it does not affect the PCI compliance of the organization using the service provider.  That said, anyone following such procedures outlines above should be prepared to provide their acquiring bank and/or card brands with proof of all of these monitoring activities.

As with all topics related to PCI compliance, this one is no different and there will be nuances to all of these discussions.  But hopefully you now understand all of the basics regarding third party service providers.




Announcements

If you are posting a comment, be patient, as the comments will not be published until they are approved.

If your organization has a PCI opportunity, is in need of assistance with a PCI issue or if you would like the PCI Guru to speak at your meeting, you can contact the PCI Guru at pciguru AT gmail DOT com.

I do allow vendors to post potential solutions in response to issues that I bring up in posts. However, the PCI Guru does not endorse any specific products, so "Caveat Emptor" - let the buyer beware. Also, if I feel that the response is too "sales-ee", I reserve the right to edit or not even authorize the response.

Calendar

August 2017
M T W T F S S
« Jul    
 123456
78910111213
14151617181920
21222324252627
28293031  

Enter your email address to subscribe to the PCI Guru blog and receive notifications of new posts by email.

Join 1,857 other followers