Have You Noticed?

I was on a call with our person who coordinates and does most of our quality assurance (QA) reviews for the firm. They were asked if they had any updates to provide the team regarding PCI. They took over the meeting and had us go to Part 2g of the Service Provider Attestation Of Compliance (AOC). The topic of the discussion was that we needed to make sure that we followed the Note in that section that states:

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

They said that in conversations with other QA people in the PCI arena, this had come up in the discussions as to how he was dealing with the requirement. They said that, until it had been pointed out, they really had not thought about it until just recently when one of our Service Provider clients needed their AOC created and their multiple services necessitated multiple 2g tables.

But that brought up the concern as to how many QSAs and their QA people have noticed this requirement, let alone are doing it correctly? Likely only a few.

However, it is important that the Service Provider AOC gets properly filled out as the service providers’ customers are relying on the AOC to fill out their own matrices based on the service provided by the service provider.

As a result, for every check box checked below in Part 2a, there needs to be a corresponding table filled out in Part 2g.

If you are doing service provider assessments and are not following that process expect a big black checkmark in your next PCI SSC AQM review. The question is, will it cause any QSACs to go into remediation?

Happy holidays.

Advertisement

A Better Mouse Trap?

I had the pleasure of recently talking to David Marsyla, CEO of PocketKey (http://www.pocketkey.com) about their new solution to secure card transactions. PocketKey is an independent attempt to address security issues with card transactions, particularly card-not-present (CNP) transactions such as those related to eCommerce. If any security solution was needed, it is in the CNP space.

While PocketKey seems to provide a very secure method of conducting transactions, during our conversation, I expressed my concerns about their business model.

• We have seen this before. Back around the turn of the century, Visa, MasterCard and American Express all flirted with similar schemes that required their EMV cards to be inserted into a serial device connected to a PC to be used online. Unfortunately, very few Web sites ever supported their application programming interfaces (API) so these solutions disappeared as quickly as they had been rolled out.
• It is not as portable as I would have hoped. PocketKey needs to be plugged into your PC, smartphone or other device that can provide Internet access. If an application on your device supports the PocketKey API, then the application can store the encrypted CHD information from the PocketKey for use in future transactions.
• It requires application changes. In order for PocketKey to work, applications must be modified to handle the PocketKey API to get the full potential out of the solution. This means that PocketKey needs to get application providers on board for their solution to be implemented. In my very humble opinion, the best solution is one that does not require any application changes at the merchant end.
• It requires the cooperation of transaction gateways, processors or banks. Not only do applications need to be addressed, but then card transaction gateways, processors or banks need to support PocketKey to work because the encrypted data generated by PocketKey needs to be converted at some point to actual cardholder data (CHD) for approval.
• EMV provides similar capabilities. EMV cards have the ability to secure transactions through the use of dynamic primary account numbers (PAN), dynamic card verification values (CVV) and other security features. However these capabilities also require changes with applications as well as with transaction gateways, processors or acquiring banks in order to work. Do not be surprised if once the US EMV roll out is completed that, wonder of wonders, Visa and MasterCard then tout these “new” security features and push for their implementation by merchants, gateways, processors and banks.

It is not that these limitations cannot be surmounted so much as they require cooperation within the application and transaction processing communities to make it work. It is nice to see that someone is trying do something to address fraud problems. Card present fraud is almost a thing of the past and will be once magnetic stripes are completely gone (still a long time before this happens). However CNP fraud continues to grow as attackers find it the only way to quickly monetize their illegally obtained CHD.

I wish PocketKey all the best and hope they attract the necessary partnerships to make their business model work.

Merchant, Service Provider Or Both?

Apparently there are a lot of newcomers to the PCI compliance business and are asking bizarre questions regarding PCI.  One of the most common is if their organization is a merchant or a service provider or both?

Merchant

According to the PCI DSS v3 Glossary, a merchant is defined as:

“For the purposes of the PCI DSS, a merchant is defined as any entity that accepts payment cards bearing the logos of any of the five members of PCI SSC (American Express, Discover, JCB, MasterCard or Visa) as payment for goods and/or services. Note that a merchant that accepts payment cards as payment for goods and/or services can also be a service provider, if the services sold result in storing, processing, or transmitting cardholder data on behalf of other merchants or service providers. For example, an ISP is a merchant that accepts payment cards for monthly billing, but also is a service provider if it hosts merchants as customers.”

One of the points that create some of the most confusion is the point made at the end of the merchant definition that it is possible for a merchant to also be a service provider.  A lot of people think that this is a black or white, either or type of situation which it is not.

The key thing to determining if your organization is a merchant is if your organization signed a merchant agreement with a bank and has a merchant account with that bank.  If your organization did, then you are definitely a merchant.

Service Provider

Now let us talk about service providers.  In the same document, a service provider is defined 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).”

The first thing to remember about service providers is that you can be tagged as a service provider and not be directly processing, storing or transmitting cardholder data (CHD) or sensitive authentication data (SAD).  We see this most often with organizations that provide managed security services (MSS).  In most cases, these organizations manage/monitor the devices that provide and/or secure the communications links.  As a result, these MSS providers can have access to unencrypted CHD/SAD whether they realize that or not.  If the MSS could be in contact with unencrypted CHD/SAD via the devices they manage, then they are in-scope for PCI compliance.

I can tell you from personal experience that service providers that are not directly processing, storing or transmitting CHD/SAD will push back and fight very hard to be ruled out of scope for PCI compliance.  It has gotten to the point that I have seen and heard of service providers taking customers to court for misrepresenting their business and to force their customer out of their service contract.  In the majority of the cases I am aware; it was shown that it was the service providers’ negligence from not explicitly asking whether or not PCI compliance was required by the customer.  So if you need to be PCI compliant, it is very important to make that clear to any service provider you are looking at just in case one or more of their services could come into contact with CHD/SAD.

Another way an organization can become a service provider is when they conduct card transactions on behalf of a third party.  The best example of this situation is with outsourced call centers.  While the call center might be conducting the card transactions on your systems, they are a third party that is processing and transmitting CHD/SAD through their workstations for your organization.  As a result, the call center is a service provider and is in-scope for PCI compliance.

Another way an organization can become a third party is if they are conducting transactions through their systems using a merchant account of a third party.  I have encountered this with call centers where the call center is using their own applications, but the merchant account used to process payments through is not the call center’s merchant account, it is the merchant account of the call center’s customer.

Both?

Finally, there is the example from the Merchant definition where the organization is both a merchant and a service provider.  As pointed out in the definition, this most commonly occurs with Internet service providers (ISP) and shared hosting providers that provide not only services for hosting a customer’s IT environment, but then accepts cards for payment for those hosting services.  From the hosting perspective, these organizations are a service provider and must comply with the PCI DSS for those services provided to their customers.  However, these organizations are also merchants because their customers can pay using a credit/debit card.

Some Closing Comments

Before I finish this post, I also want to add some comments regarding compliance reporting for service providers.

The first comment I would like to make is regarding reporting and compliance testing.  If you are a service provider, you only have the choice of a Self-Assessment Questionnaire (SAQ) D or a Report On Compliance (ROC).  If your organization processes, stores or transmits less than 300,000 card transactions, then you can use either the SAQ D or perform a ROC.  If your organization processes, stores or transmits 300,000 or more card transactions, then you are required to do a ROC.

If you are an ISP, MSS or similar service provider that does not process, store or transmit CHD/SAD, then you will not have a transaction count and therefore will fall on the under 300,000 transaction count rule.

Why would an organization that can do an SAQ D do a ROC?  If an organization desires to be listed on the Visa Global Registry of Service Providers or the MasterCard PCI Compliant Service Provider lists, then the service provider must do a ROC.  There are rules and fees for being included on these lists that each card brand Web site documents.  A knowledgeable QSA can help facilitate your listing on these sites as well as conducting the requisite ROC assessment.

A quick side note regarding Visa and service providers.  Visa is conducting a separate service provider inventory program that is outside of their Global Registry program.  This new inventory process has confused a lot of service providers and QSAs alike including yours truly.  For about the last year or so, Visa has been “registering” all service providers in an attempt to create a complete inventory of service providers.  This service provider inventory program has nothing to do with the Visa Global Registry and does not put any organization that is processed through it on the Visa Global Registry.

It is very important for service providers to know that the Attestation Of Compliance (AOC) form for the service provider is very different from the merchant version of the AOC.  The AOC for service providers provides a list of the services provided by the service provider that were assessed for the AOC.  This information is necessary for customers to know if all of their services were assessed for PCI compliance.  If a service was missed, then the merchant is responsible for assessing that service for PCI compliance.  So it is very important that you ensure that all services provided to your customers that require PCI compliance be assessed for PCI compliance.

Then there are the number of times I have received an AOC from a service provider only to find that it is a merchant AOC, not a service provider AOC.  With v3 of the PCI DSS, the Council has created separate SAQ D forms for merchants and service providers that will hopefully cure some of this issue.  It is incumbent on service providers to make sure that when they sign the AOC that it is a service provider AOC and all of the services are listed.  If not, then you need to go back to your QSA and get the right AOC form with the right information created.

And finally, my biggest pet peeve with service provider AOCs.  Some QSACs create these wonderful “Certificates Of PCI Compliance” that, while they look really nice, have no meaning to your customers and their QSAs.  No matter how many times the PCI SSC has stated that the only officially recognized document out of a PCI assessment is the AOC, I still encounter these certificates as “proof” of PCI compliance.  When asked to provide the AOC, I then get the indignant response that I should have everything I need.  In one case, I was even told I could not possibly be a QSA because I did not recognize the certificate as proof of compliance.

As I stated earlier, the service provider AOC is required to ensure that all service provided were assessed and QSAs are required to have copies of all service provider AOCs in order to show that all third parties have been officially assessed for PCI compliance.  No AOC means that the service provider is not PCI compliant and must be assessed as part of the customer’s PCI assessment.

I hope we are all now on the same page regarding the concepts of a merchant and a service provider.

Third Party Service Providers And PCI Compliance

There seems to be a lot of confusion regarding third parties that provide networking or hosting services and their obligations regarding PCI compliance.  This confusion is not uncommon as merchants and their service providers have not necessarily been provided enough guidance to understand their obligations.  I hope this post will clarify those obligations for all involved.

If you learn nothing else from this post, if a third party is providing your organization a service that has access to your cardholder data environment (CDE) or the third party could come into contact you’re your cardholder data (CHD), then that third party must ensure that the service complies with all relevant PCI requirements.  As a result, the third party needs to either allow you or your QSA to assess the services that they are providing or provide you with an Attestation Of Compliance (AOC) that documents that those services have been assessed and they are PCI compliant.

In the past, I have stated that third parties could also submit a letter signed by an officer of the third party stating that all of the services provided to their customer are PCI compliant.  Now that v2.0 of the PCI DSS has a separate AOC and the PCI SAQs have the AOC built into the SAQ, there should be no reason to need such a letter or to ask for one.  If a letter is what your third party is offering, it is better than nothing, but you should be pushing them hard for an AOC.  If they are reluctant to get you an AOC, as part of your vendor management process, you should take that into account and probably begin looking for a new vendor that will provide an AOC for their services.

The most common issue we run into with third parties is that their AOC or other representations of PCI compliance do not cover all of the services provided to the customer.  In case after case, we see the AOC covering requirements 9 and 12 and nothing else even though the services provided may require compliance with some or all of PCI requirements 1, 2, 3, 4, 5, 6, 7, 8, 10 and 11.

In a lot of cases, it is not that the third party does not want to comply with PCI; it is they are taking the lowest common denominator approach and only picked those services where all customers requiring PCI compliance are asking for an AOC.  That way they have reduced their costs of a QSA to assess their environment.  These third parties are accepting the fact that any customer that needs more services assessed will have to do it themselves.

Related to this issue is the third party that offers their SSAE 16 Service Organization Control (SOC) 1 report has proof of PCI compliance.  While a SOC 1 report can cover a few PCI requirements, people must remember that the SOC 1 report is structured specifically for financial auditors to ensure that the controls at a third party are properly constructed to support financial reporting at the customers.  As a result, a SOC 1 report is not going to be a substitute for an AOC that covers all services.  There is an alternative to this and that is to have the third party go through a SSAE SOC 2 report that focuses on the security controls of the PCI in-scope services provided.  We are hearing from third parties inquiring into the SOC 2 report, but cost and a lack of customers requesting such a report are driving why we do not see more SOC 2 reports available.

Another common issue we encounter is the refusal of the third party to cooperate in assessing the services provided to ensure they are PCI compliant.  There are still third parties that argue their services are not in-scope for PCI compliance even when it is painfully obvious that the third party’s personnel have access to their customer’s CDE and/or CHD.

The most common third party relationship we encounter is the management of routers or other layer 3 devices.  Where we encounter the most confusion in this relationship is in regards to the use of encryption to keep the network services organization out of scope for PCI compliance.  The key here is if the network services organization manages the encryption of the network, then they are in-scope for PCI compliance.  The reason is that the employees of the network services organization have access to the encryption keys and therefore could decrypt the communications and gain access to CHD transmitted over the network.  As a result, at a minimum, the network services organization is responsible for complying with some or all of requirements 1, 2, 4, 6, 7, 8, 9, 10 and 12.  If you receive such services and are not getting an AOC that covers these requirements, then you should be doing more work on your own as well as asking the third party why they are not covering more of the necessary PCI requirements.

The next most common service we encounter is the network services firm that is managing or monitoring an organization’s firewalls, remote access or intrusion detection/prevention.  Such services always put the third party in-scope for PCI compliance.  Some or all of requirements 1, 2, 6, 7, 8, 9 and 12 will need to be assessed for compliance with the PCI DSS.  The log capture and analysis requirements in requirement 10 may also be complied with if your organization is not capturing and analyzing the log data from these devices.

Another group of third parties we encounter a lot are records retention vendors.  Organizations like Iron Mountain have conducted their own PCI compliance project and readily hand out their AOC to customers.  However, where we see issues is with such vendors that provide their own tape library for their customers to use for backup.  We have encountered a number of third party’s doing the encryption at their library which puts them in-scope for PCI compliance, at a minimum, for requirements 3, 4, 6, 7, 8, 9, 10, 11 and 12.

We encounter outsourcing the data center a lot with large organizations, but small and mid-sized organizations are also hopping on the data center outsourcing bandwagon.  Where this puts the third party in-scope for PCI compliance is when the third party is responsible for maintaining the environment such as applying patches, managing servers or any other activities that would allow the third party’s personnel to potentially have access to CHD.  In such situations, at a minimum, the third party is responsible for complying with some or all of requirements 2, 5, 6, 7, 8, 9, 10 and 12.  Compliance with some or all of requirement 1 may be applicable if the third party is managing your firewalls or routers.  Compliance with some or all of requirements 3 and 4 may also be applicable if the third party is responsible for managing encryption keys for encrypting CHD or encrypting communications.

Where the most confusion regarding third party responsibilities occurs is in regards to “The Cloud.”  The most common reason for this is that every vendor seems to have a different definition for what “The Cloud” is, based on their particular services.  Using the definitions provided by the National Institute of Standards and Technology (NIST) in their publication SP800-145, ‘The NIST Definition Of Cloud Computing’, I can provide the following guidance.

If your organization is purchasing Infrastructure as a Service (IaaS), then the third party providing these services will typically be out of scope for PCI compliance except for requirements 9 and 12.  There are some instances where IaaS implementations may require compliance with the PCI DSS if the third party is managing network infrastructure that comes into contact with CHD as is usually the case with private cloud environments.

For Platform as a Service (PaaS) and Software as a Service (SaaS), the third party will have to provide PCI compliance for the services they are providing to your organization.  That is because with either of these service offerings, the third party must have access to the CDE and will have the potential of coming into contact with CHD.

The problem with the majority of PaaS and SaaS vendors is that they only deal with your organization through a Web-based interface, i.e., everything is automated – contracts, support, etc.  As a result, the contract is a “take it or leave it” situation that does not usually cover everything needed for PCI compliance, there is no way to independently verify the representations made by the third party as well as the fact that the AOC provided by the third party typically only covers only the physical security requirements in requirement 9 and possibly some of requirements 11 and 12 and nothing related to the other requirements, even though the third party may have responsibilities for PCI compliance outside of what is represented in their AOC.

If this is the case, there is little you or any QSA can do to properly assess the environment to ensure it is truly PCI compliant.  As a result, we have a lot of organizations that try to develop compensating controls for these cloud implementations.  These organizations very quickly and frustratingly find out that there are very few, if any, controls on their side of the equation that can get them to “above and beyond” the original requirement.

I know there are a lot of other examples of services being provided to merchants.  But, hopefully these examples can assist you in clarifying what you need or do not need from your third parties when it comes to PCI compliance.