As a recent question pointed out to me, while service providers now seem to understand they need to be PCI compliant, they do not seem to understand the process under which they assess their PCI compliance. As a result, I thought I would use this space to clarify this process.
When Do I Have To Be PCI Compliant?
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. 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. Entities such as telecommunications companies that only provide communication links without access to the application layer of the communication link are excluded.”
On the straight forward side of this definition, if your organization processes, stores or transmits cardholder data on behalf of one or more other organizations, your organization is considered a service provider and needs to be PCI compliant. That point seems to be clear and most organizations that are processing cardholder data for others understand this fact.
It is organization that do not directly process, store or transmit cardholder data but could impact the security of cardholder data that get tripped up. The bottom line is, any third party that has access to an organization’s cardholder data environment (CDE) needs to be PCI compliant for those services offered that come into contact with the CDE.
Based on this definition, the following are examples of services would need to be PCI compliant. This is not a complete list but something to assist you in understanding why your organization might need to be PCI compliant.
- Management of firewalls that are considered part of an organization’s CDE.
- Management of networks that carry cardholder data that is not encrypted.
- Management of encrypted networks that carry cardholder data and the MSP manages the encryption keys for encrypting the network.
- Management of servers that process, store or transmit cardholder data.
- Management of PCs that have access to cardholder data.
- Management of applications that process, store or transmit cardholder data.
The first question service providers typically ask is, “How am I supposed to know if my customer needs our services to be PCI compliant?” My rather indignant response is, “What, you cannot ask them?”
If you are a service provider and you are providing any value added services, you need to be asking every customer about their regulatory or legal requirements when going through the sales and contract processes. It is not just PCI these days, but in the US there is HIPAA, GLBA, SOX and there all sorts of similar requirements in various parts of the world that you should be finding out whether your prospects need to comply. If you are not, then you are sitting on a potential legal time bomb should something happen and your value add services are deemed the culprit.
SAQ D or ROC?
Service providers are broken into two levels, Level 1 service providers and Level 2 service providers. Level 1 service providers are those that process more than 300,000 Visa, MasterCard or Discover transactions annually and are required to perform a full PCI assessment using a qualified security assessor (QSA) that results in a Report On Compliance (ROC). Level 2 service providers are those that process 300,000 annual transactions or less and they can conduct their own assessment using the SAQ D. SAQ D is the only SAQ that service providers are allowed to use.
The first issue most MSPs face is determining what parts of the ROC or SAQ are relevant. There are no easy answers in this area as it all comes down to those value added services you are providing and how you provide those services. However, before you can determine what parts of the ROC or SAQ are relevant, you need to determine the services that are to be assessed.
Where MSPs can miss the boat is taking the lowest common denominator approach and only assessing those value added services that all customers need to be PCI compliant. Typically this results in an AOC that discusses physical security (requirement 9) and security policies (requirement 12). If you take the lowest common denominator approach, then do not complain when each of your customers’ QSA have to traipse through your facilities and disrupt operations over the value added services you did not cover in your AOC.
The best approach is to assess all value added services you provide so that you do not have to worry about whether or not a given service is PCI compliant. The reason this is important is that customers are required to make sure that all service providers that need to be PCI compliant are PCI compliant. It is not that customers cannot work with non-PCI compliant service providers; it is just a lot easier to work with PCI compliant service providers. The reason is that non-PCI compliant service providers have to be annually assessed as part of the customer’s PCI assessment as well as the customer is supposed to be monitoring the service provider’s PCI compliant efforts. As a result, you will have an easier time and be easier to deal with if all of your value added services are PCI compliant.
Now back to what parts of the PCI DSS are relevant. There are too many permutations of services and PCI requirements to go into this for every possible situation, so I am just going to provide some examples.
If you are providing firewall management services, then you are going to have to comply with requirements 1, 2, 4 (if your organization is managing any transport encryption), 5 (the PCs/servers used to manage the firewalls), 6 (change control for the PCs, servers and firewalls), 7, 8, 9, 10 (log management and analysis for the PCs, servers and firewalls), 11 (PCs, servers and firewalls) and 12. Some tests in these sections may be Not Applicable for your organization, but you will need to go through all of the tests in the sections.
If you are managing applications such as in a software as a service (SaaS) environment, you are going to have to comply with requirements 1 (if you manage any firewalls or routers that could be in-scope), 2 (servers, firewalls, routers, switches), 3 (if your application encrypts the cardholder data), 4 (if your network encrypts cardholder data), 5 (servers running the application as well as any support PCs and servers), 6 (change management as well as any software development), 7, 8, 9, 10, 11 and 12. Some tests in these sections may be Not Applicable for your organization, but you will need to go through all of the tests in the sections.
As you can see, even a “minor” service such as managing firewalls can require a significant amount of effort to be PCI compliant.
Do I Need A QSA?
A Qualified Security Assessor (QSA) is only required if: (1) your organization is considered a Level 1 service provider, or (2) you wish to have your organization listed on Visa’s Global Registry of Service Providers or with the MasterCard Registration Program (MRP). In both of these cases, you will need to hire a QSA and produce a Report On Compliance (ROC) and Attestation Of Compliance (AOC). If you can answer ‘No’ to both of these, then you can do your own assessment using the SAQ D.
Scope Of Assessment
At the 2012 PCI Community Meetings, the PCI SSC clarified scoping for PCI assessments. The PCI SSC stated that:
“To be considered entirely out of scope, a network or system must be isolated from, with no connectivity into, the CDE (such that even if the system is “owned”, it cannot impact the security of the CDE).
If connections are limited to specific ports or services, those systems are included in PCI DSS scope to verify applicable controls are in place.
Applicable PCI DSS controls may vary for in-scope systems depending on the function of the system and presence of other controls.”
As a result, any of your systems that have access into a customer’s CDE are in-scope for compliance as they could be used to access the CDE. This does not mean that these systems need to meet all of the requirements of the PCI DSS. But it does mean that they need to be evaluated to determine those portions of the PCI DSS that do apply. All of this is dependent on the potential to access cardholder data inside the CDE.
To minimize the impact of this clarification, we are seeing a lot of MSPs using “jump boxes,” PCs that do nothing but provide access into the systems to be monitored or managed. This provides an air gap between the MSPs internal systems and the customer’s environment, including the CDE. As a result, the jump boxes need to be PCI compliant and the internal systems at the MSP just need to have current anti-virus and anti-malware and be properly authenticated.
Hopefully this post helps all of you managed service providers that are facing PCI compliance.
This post was revised after a review by Walt Conway at 403Labs pointed out some inaccuracies. A big thank you to Walt for his diligent eye.
Service providers represent!
One comment about the service provider levels: it’s my understanding that American Express and Discover have only one level of service provider which requires a RoC, so if you (or your MSP clients?) processing Amex or Discover then you’re looking at a RoC regardless of volume.
(I’m at a service provider handling card data, though, not an MSP, so I’m not sure how the Amex/Discover numbers affect MSPs.)
One other thing I’ve found difficult in managing our relationships with *our* service providers is that their AoC isn’t sufficient to satisfy our QSAs — we also need to have the division of responsibility clearly documented in our agreements with them, and stock agreements with large service providers don’t often make it completely clear where the line is drawn.
That’s a great concise summary of scoping, too, thanks. It sounds like that makes it clearer that a jump box is an acceptable way to limit scope.
American Express and Discover are new to the service provider space. I am not sure if either even have any service providers yet although Discover was being rather aggressive in their search for service providers so they may have signed some on by this point. There are a lot of service providers that pass through American Express and Discover accounts, but that is not consider being an actual service provider for American Express and Discover.
American Express does not list any service provider levels, but Discover chose to use the same levels and definitions as Visa and MasterCard. I would assume that American Express would accept the definition of service provider levels of the other three if you pressed them. See http://www.discovernetwork.com/merchants/data-security/service-provider.html for Discover’s levels.
The primary problem with service providers’ AOCs that we encounter is that a lot of QSAs and service providers neglect to list the services that were assessed. As a result, when we start asking the service provider for information, they refer us to the AOC which we then point out does not address the services. This of course winds up the service provider and, I am sure, gets the service provider calling their QSA to complain that they screwed up the AOC or improperly scoped the PCI assessment. Either way, I am sure it ends up pretty ugly.
How could you say “I’m not sure if either even have any service providers yet”? Are you saying that Amex doesn’t use any hosting, or managed service providers for their networks? What if a company is hired by Amex or Discover to do analysis on accounts or transactions after they are processed, crunching the data for reporting? Wouldn’t they be a service provider, even though they are not involved in processing cards?
Can you clarify what you mean by “there are a lot of service providers that pass through…accounts” without being considered service providers. I’m not sure what that means.
What I meant by the “pass through” comment is that some processors such as First Data and Chase Paymentech are interconnected with the Discover and American Express networks and can take in a Discover or American Express transaction and pass it to the respective card brand for authorization.
American Express and Discover (maybe) do not have independent processors such as First Data that operate on their behalf authorizing transactions. The reason for the maybe after Discover is that they have been actively trying to sign up service providers to authorize transactions, but I am not aware of any that have signed on board with Discover. First Data, Elavon, Chase Paymentech and the like can authorize Visa and MasterCard transactions on behalf of the banks they process. American Express and Discover have no such relationships at the moment but are supposedly looking to establish such relationships.
Companies that do transaction analysis for any of the card brands are service providers, but are dealing with post authorization data, not the authorization process.