I get a lot of inquiries asking about these sorts of situations and thought I should clear this up before too many organizations get hurt. The scenario goes something like this.
“I outsource my eCommerce site to a third party. The third party’s Web site does a redirect to [pick your processor]. I asked the third party for their Attestation Of Compliance (AOC) and they are telling me they do not need to be PCI compliant because they are out of scope. This is because their servers do not process, store or transmit cardholder data (CHD).”
From the PCI DSS Glossary v3.1, the PCI SSC defines a ‘Service Provider’ 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).”
So here we go again – organizations splitting legal hairs, this time on the meaning of “directly involved.” The discussion from the service providers seems to revolve around the fact that issuing a redirect to the actual payment processor puts them out of scope because they are not “directly involved.”
I hate to rain on your parade, but it is my job.
First, as an outsourcer, you are a service provider to your customers. You can split legal hairs all you want on the first part of the definition, but your organization definitely meets the second part of the definition that this “also includes companies that provide services that control or could impact the security of cardholder data.”
Oh, that is right, you do not believe that your service could “control or impact the security of cardholder data.” Really? Your Web site that issues the redirect does not “control” the security of cardholder data or your site that issues the redirect could not impact the security of cardholder data if that redirect is changed. Who is liable for those problems? Your merchant customers? Think again and think about how that will play out in the media.
Second. To add insult to injury, a lot of you service providers point to SAQ A to support your argument. Seriously? SAQ A at least requires your organization to comply with certain requirements in sections 9 and 12 which means your organization is in scope for PCI compliance. Talk about twisted logic. But you are a service provider, so you cannot use SAQ A because only SAQ D or a Report On Compliance (ROC) can be used by service providers.
But if the first two points do not convince you, let us talk about how the card brands and payment processors dole out responsibility and liability if a problem occurs. Do you really believe that you have no skin in this game? As the outsourcer, you have all the skin in the game. If any redirect is tampered with, it’s not your merchant customers that will be on the hook. Yes, they will likely be the first one’s taken to the woodshed, but when the truth comes out that it was all your organization’s fault, your customers and their processors will come after your organization. It was not the merchants that created the problem, it was your organization. Your organization will be the one held liable for the problem, not your merchant customers.
The bottom line here is that you are a service provider and you are in-scope for PCI compliance. Get over it. You go right ahead and try to get around PCI compliance with your warped logic. When it hits the fan, it will be your organization that will be held liable, not your customers.
For all you merchants that are using these sorts of service providers, you need to either: [1] badger them to give you an AOC, [2] assess them as part of your own PCI assessment, or [3] find a new service provider that can provide an AOC. The choice is yours.
PCI Guru 
I’ve been asking a potential service provider for an AoC, they keep sending me a certificate. I’ve repeated the question and I understand that compliance certificates are worthless. You would think it was top of their list to provide an AoC when asked given that we will be new business for them.
So, I’ve got a certificate and am waiting on the AoC. The difficulty is that the certificate says that the service provider has “self validated their compliance”, albeit to v 3.1.
Surely a self validated AoC is worthless? Additionally they are refusing to add any inclusions to contract wording to accept their responsibility in any of their data handling and keep pushing me the PSP certificate as the default, even though the way they are working with the PSP is via an API.
Where does that leave me and what should I do to address it?
Level 2 service providers can self assess and fill out a service provider self-assessment questionnaire (SAQ) D. According to the PCI SCC, an Attestation Of Compliance (AOC) for a self-assessment can still be relied upon for PCI compliance by a service provider. The AOC is after all signed off by an officer of the organization. Unless you have evidence that the service provider is not PCI compliant, you accept their AOC and move on.
In regards to contract language, that is a different story. The PCI DSS is very clear as to the language required in third party contracts. If this service provider is not willing to include the required language, then you need to find another service provider.
Thank you for your advice, I find it very helpful. Alas we are still in a situation where we have a service provider for whom we have no valid AOC but which is still providing our service. What does this mean for our own SAQD sign off in terms of the requirements? For example, 1.1.2 If we can state Yes to that requirement for our internal systems, can we still say Yes even though we have no idea for the third party provision? Or is it just that we can state Yes to that and other requirements but when I get to 12.8.2 that is where I have to put No, thus throwing the whole of my compliance out.
You have two choices: (1) assess the service provider as part of your SAQ, or (2) create one or more compensating controls and have your bank approve them.
OK, lets try this. I have two slightly different use cases to describe. We’ll start out with your opening scenario:
“I outsource my eCommerce site to a third party. The third party’s Web site does a redirect to [pick your processor]. I asked the third party for their Attestation Of Compliance (AOC) and they are telling me they do not need to be PCI compliant because they are out of scope. This is because their servers do not process, store or transmit cardholder data (CHD).”
That being so, let’s say the third party does the re-direct to whatever processor, and the processor payment page is configured to process transactions using my merchant ID (MID) from my acquirer. In this case I would say the third party is a service provider. No question.
But, what if the third party was using their own MID that they obtained from their acquirer, and that the the third party uses that MID for only my transactions. Their business model is based on their revenue coming in on a per transaction basis. After they take their skim from the gross they send me a check for the net. This third party could argue that they a) are using a re-direct, and b) are processing transactions using their own MID. Thus, they qualify to operate as a merchant and they validate their compliance using SAQ A. I’m not sure I agree with that, as the only processing done via that MID is for transactions coming in from my customers.
This is a common situation that I encounter in my sector (higher education.) The third party offers some compelling Software as a Service that people in my organization cannot live without. My job is to make sure my customers always interact with PCI compliant organizations when e-commerce is involved. The third party makes some stupid argument that they never touch cardholder data so PCI doesn’t apply, or that if it does apply then they are a merchant needing nothing more than SAQ A. From my point of view, the third party is operating as a service provider, processing payments on my behalf, minus a small fee.
So, PCI Guru, what do you think about this? Is the third party a service provider? Does it all come down to one simple question: “Who signed the merchant agreement and requested the MID?” Or are there some other subtler considerations.
I would love to hear your take on this.
From a pure and simple perspective, the PCI DSS very clearly states that any entity that processes, stores or transmits sensitive authentication data (SAD) is in scope. The Council has further clarified through statements and certain FAQs that third parties that control the payment process, such as that describe in your examples, are also in scope. I know it’s a slippery slope, but I also think asking for a service provider to provide an AOC from the Service Provider SAQ D that covers the controls in SAQ A is little to ask.
Since I’m working for a Service Provider, I might be biased but as PCI Guru indicated, it is a requirement for any entity hiring a SP to make sure that they 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 (Ref. PCI DSS 12.8.2). So the problem we have is that many assessed entities complain to their SP that the SP should comply with requirement X and Y when there’s no contractual provisions to cover those requirements.
So at the end of the day, any assessed entity should have formal agreements with their SP as to which controls are the SP’s responsibility. So if they fail to comply 12.8.2 and 12.8.5, they’re simply not PCI DSS compliant.
The v3 Attestation Of Compliance (AOC) in the ROC and SAQ D require that the service provider identify those 12 sections that were assessed by service. This table requires the service provider to identify by section whether it was ‘Fully’ assessed, ‘Partially’ assessed or was not assessed (‘None’). If the section was either Partially assessed or not assessed (‘None’) then an explanation is required identifying what was and was not assessed or why the section was excluded from assessment.
Correct and this explanation should be supported by the formal agreements (ref. 12.8.2, 12.9 and 12.8.5).
Knowing Braintree and working with them currently, I think we would find that the SAQ-A claim is valid if you are a merchant which is a valid assumption about their target market. So, perhaps it just needs some clarification becasue it is also possible that Service Providers will use it as I do, but I wouldn’t say its constructively misleading. If you approached them I’m sure they would attend to it. I recently approached them over their apparent lack of a Safe Harbor renewal – a link on their website lead to the registration database showing it to be out of date. This was a simple case of the site not being updated to reflect the new status – they are under PayPal’s umbrella.
But on the point of being a Service Supplier using such a service as we do our SAQ-D has many elements that are answered not applicable to such an extent that we end up with what amounts to a SAQ-A-EP. So, I don’t really think there is much to grumble about.
This comment isn’t relevant to this post beyond perhaps the “splitting hairs” aspect.
Braintree (a PayPal subsidiary) recently released a feature called “Hosted Fields” which they claim to be SAQ A compliant since card data is entered in iframes. However due to the nature of their API and the multiple integrations they offer it’s possible for an attacker to switch the checkout on a merchant’s site from “Hosted Fields” to Braintree’s other “Custom” integration. This would allow an attacker to intercept cards without interrupting payments.
I have argued with Braintree that this should disqualify Hosted Fields for SAQ A but their defence amounts to taking quotes from the council about iframes out of context. I think it’s pretty clear that when the council mentions “iframes” they mean the types of iframes that if redirected elsewhere would interrupt payments and thus would be noticed before significant card data is stolen.
I have received a copy of a letter from Security Metrics certifying that Hosted Fields are SAQ A but it looks like Braintree only demoed a narrow integration in order to qualify. I believe that since all three of Braintree’s integrations use the same credentials and can be swapped around via client side javascript then all of them should be assessed together as one.
Additionally, even while refusing to admit that Hosted Fields are SAQ A-EP, Braintree has admitted that they are working on “anti-tampering” measures that in my view might qualify Hosted Fields as SAQ A. Why work on such a feature unless someone at Braintree knows the truth?
What should I do about this? I have repeatedly asked Braintree to tell me what exactly makes Hosted Fields more secure so I can make an informed decision but they have offered no answers. It’s possible that there is something I’ve missed but they won’t tell me if I have.
Are Braintree breaking the rules and false advertising a product? What is the point of SAQ A-EP if the mere mention of an iframe can qualify you for SAQ A?
Here’s John Downey who according to LinkedIn is “Lead Security at Braintree” admitting that Hosted Fields don’t currently prevent iframe manipulation: https://news.ycombinator.com/item?id=9510613
Yet here’s Braintree currently advertising Hosted Fields as SAQ A: https://www.braintreepayments.com/features/hosted-fields
Did Braintree purposefully trick Security Metrics? Are Security Metrics incompetent?
Nope, no trickery. It’s the Council and the card brands that allow SAQ A to be used with iFrames and redirects. See my original post on how they figured that out. For more on SAQ A-EP, see this post.
The Council and the card brands believe that there is very low risk with iFrame and redirect solutions. However there is a risk that the iFrame or redirect invocation get changed and send customers to some bad payment looking process. If that happened and the organization that invokes the iFrame or redirect did not alert on that change, then it would be the invoking organization that would have the liability, not the transaction processor. Therefore, I am of the opinion that you need to at a minimum monitor the invocation point for changes and halt your site if that code/executable/etc. changes and you were not expecting a change.
In your original post there is a link to “Visa Europe’s Processing eCommerce Payments guide”. Under Visa’s definitions Braintree’s Hosted Fields would best match a “Javascript created form” which depending on the settings chosen could operate either by direct post or iframes.
A compromised implementation of Hosted Fields would have the same “hows”. “whats”, and risks that VISA use in their table for direct post.
I’m pretty sure Visa would consider Hosted Fields to be SAQ A-EP but Braintree only showed Security Metrics one mode and got themselves validated as SAQ A.
You could very well be right and it would not be the first time a vendor only certified one method of capture.
Until someone complains, the Council issues a clarification or the card brands say something, we are stuck with it as is.
I contacted Security Metrics and they said that they were not made aware of the behaviour of Braintree’s API keys and that they will “look into it”. So I take that as an admission that Braintree tricked them but it remains to be seen if they will take any real action or risk upsetting a big client like PayPal.
Is there anywhere worth reporting this to to ensure that Security Metrics and Braintree are forced to act as soon as possible?
You could report it to your acquiring bank, but I’m not sure what they would do unless you were actually using it and raising it as an issue.
I’m betting Braintree didn’t “trick” Security Metrics so much as they just limited the scope of Security Metrics’ assessment to the one method. The other thing that might be going on is that Braintree wanted an opinion on whether or not that particular method met SAQ A. Regardless, as background, there should have been some sort of writeup in any report stating that other processing methods exist and those were not assessed and the reason why they were not assessed.
I phoned Allied-Irish Bank per your advice and they can’t take security complaints on weekends.
Jesus Christ…
So as a conclusion to this…
We all agree that the council allows for man-in-the-middle attacks in their risk assessment of iframes (equivalent to a real world shimming attack).
What we disagree on is whether or not skimming style of attacks are included in the same assessment.
Braintree’s line: “the council uses a vague definition of MITM so we believe it includes skimming attacks even though nobody is actually in the middle.” (see below for exact quote)
My line: “I think it’s bad wording and it’s clear that when the council says MITM they mean only MITM. Why would they use a definition that’s different from the rest of the industry?”
Security Metrics is still looking into it but I imagine that since every processor seems to share Braintree’s interpretation nothing will happen.
The core idea of Braintree’s defence seems to be that the rules are made to encourage safe implementation of payments, e.g. copy and pasting an iframe is a lot harder to fuck up than direct API access.
But I always believed that the rules were made to encourage security from beginning to end.
It’s one for the council to fix I think.
For reference, here’s the exact quote from Braintree in regards to MITM:
“When you read these documents they aren’t really using MITM in the traditional way (literally the attacker intercepts and modifies your traffic). You can read their definition as anything that modifies the page to attack the cardholder data.”
It’s the Council and the card brands that set the rules and allows the SAQ A to be used. That does not mean that you have to blindly follow their advice and the SAQs alone and do the bare minimum. Do what you need to do to ensure your security and the PCI compliance will 99.9999% of the time follow.
Just going through PCI compliance in my company. In the PCI council guide, my understanding is that “redirect’ and “iframe” are offered as examples. The key criteria is that “all elements of the payment page are outsourced to a PCI DSS compliant provider”. For example, I came across Beanstream allows merchants to embed external javascript and css in their hosted pages through redirect. However, as soon as you use the feature, I would think this gets you to the javascript category (SAQ A-EP).
Really enjoyed this article. We have a 3rd party who argued exactly the same thing.
A redirect is a redirect regardless of how it gets implemented. After all, HTML is essentially code as well. As long as no cardholder data ever comes into contact with the redirect/iFrame invoking server, it is out of scope.
This is where things can get complicated as you need to fully understand that the code involved is a true redirect and does not gather data as with a repost. Too many times the code actually ends up being a repost of fields back to the processor.
The redirect invoking server is not out of scope – but the scope can be limited to the few lines of code doing the invoke. All the SAQ-A-EP requirements still apply to the location of that invoke code.
Your answer is the “security” answer not the “PCI” answer.
If the code you discussed is purely a redirect, then under the PCI definition all you have to do is meet certain requirements in 9 and 12 (see SAQ A for the complete list). So yes, you are correct that it is not entirely out of scope, but you do not have to do vulnerability scanning, penetration testing, etc. See my post on SAQ A versus SAQ A-EP for a longer discussion.
I am not saying I disagree but what are your thoughts about the VISA statement that they will not fine merchants that qualify for SAQ A?
It is funny that you can hire a professional to program your site and have more liability than if you developed your own WordPress, Joomla, or Drupal site. From what I have seen these sites break when not managed correctly.
That’s the rub though. Everything breaks if it’s not managed and taken care of.
I’m not saying I totally agree with the Council and Visa’s stance on redirects and iFrames being completely out of scope since there still is risk present for invocation of those methods being tampered with. But the rules are the rules and there are those organizations that will only do the bare minimum of the rules and call it a day.
**PCIGuru drops mic, walks confidently into the distance**
applause! so many service providers think they’re out of scope when they aren’t.
“The bottom line here is that you are a service provider and you are in-scope for PCI compliance.”
If the outsourcer does not have a contract that binds them to adhere to PCI standards, tough noogies. PCI isn’t a law except in Nevada and a few other states that enacted excerpts of it.And that outsourcer almost undoubtedly has written T&C’s that cause their customer to retain all liability for the security of their data and even indemnifies the outsourcer..
The PCI Council can write all of the verbiage they want about who is in scope and who isn’t and it doesn’t mean squat without a signed contract or a law to enforce it. Without a signed contract or a law, it’s just a fiction story.
It’s all on the merchant and they had better open Door #3:
“[3] find a new service provider that can provide an AOC.”
But they won’t because it will cost them more money. And the outsourcer won’t care if they do because there is always another company just waiting to take their place as a customer.
The PCI DSS does put the onus on the merchant in 12.8 to manage their vendors and business partners and make sure there is language in the contracts. So if that did not happen, then the merchant is on the hook regardless.
All I was trying to do with this post was to educate both the merchants and service providers out there that are attempting to get around the requirements under some false sense of logic.
Understood. The title might have been a bit clearer if it read “Get Over It, They ARE A Service Provider” because then the article is directed at the merchant. Without a contract, the service provider does not have to worry about any fancy legal footwork. It’s all on the merchant.
Contract or not, the processors, card brands and maligned merchants will legally come after any service provider that screws up.
Hello, we’re looking to partner with a new company, and asked them for proof of PCI compliance as our customers handle CHD. What we got in return was an AOC for their cloud solution- is that enough, or should we be pressing for the company’s AOC?
That AOC should be sufficient as long as the organization’s Cloud solution is what you are using for your services.
Make sure to check section 2g of the AOC or a controls matrix provided by the organization to make sure that your control environment meshes with your service provider’s control environment so that there are no control gaps.
I have been dealing with PCI standards since before the PCI SSC existed. One of my recurring comments to the organization is to state what you mean in the requirement. Words having meaning. This is a good example, if the word “directly” is not significant to the requirement then don’t use it.
Sure, anybody can sue anyone for anything. But the entity needed to have a duty to act in order to be found guilty. Without a duty to act there is no failure and there was no screw up. There are a few state laws dealing with this but those laws only apply to their residents, which severely limits the cost.
If you haven’t read Home Depot’s request for a summary judgement to dismiss that class action, that is the position they are taking. They also point out that the banks acted on their own to replace cards before there was any loss so that cost should be borne by the banks. In addition they point out that the banks need to replace cards periodically, so this was not an additional cost. At worst it was performing an action they would have had to perform anyway, just sooner than they had planned. And since the banks decided on their own to do it, Home Depot believes they have no liability to those individual banks (and because they did not have contracts with those banks.)
That will be one interesting decision to read.
No doubt about it that lawyers can create interesting and twisted ways of justifying the actions of their clients. Unfortunately, the courts are being swayed more and more by public opinion. It’s getting harder and harder for business to justify their mistakes and missteps in an effort to keep prices low for their customers.