The PCI DSS Is Not The Only Relevant Payment Security Standard

One of the more lively discussions at our past PCI Dream Team session involved a discussion of requirement 12.8 and third party management (i.e., service providers).  What got the discussion started was when Art (Coop) Cooper made the comment that only SAQ A states that all third parties must be PCI compliant.  All of the other SAQs and even the ROC does not state that third parties need to be PCI compliant.

All of this is very true and has been this way since the beginning of the PCI DSS.

But …  That is not the whole story.

In this instance, the PCI DSS is not the only game in town.

People forget that Visa, Mastercard, Discover, American Express and JCB (aka “The Brands”) still have their own security programs and requirements in addition to the PCI DSS.  Some of these requirements are in their Operating Rules or similar documents.  In this case, Visa, Mastercard and Discover all require that service providers be PCI compliant as defined on their respective Web sites.  In the case of Visa and Mastercard, they maintain lists of PCI compliant service providers.  That said, those lists are marketing ploys that generate revenue for Visa and Mastercard as those service providers listed pay them to be on those lists. 

While Coop’s statement is accurate that the PCI DSS does not require service providers to be PCI compliant, it is shortsighted.  The Brands do require service providers to be PCI compliant and will enforce it through the merchant agreement/contract all organizations sign in order to accept those cards for payment.

The bottom line is that, if any service provider can provide you a current PCI Service Provider Attestation Of Compliance (AOC), you can use their services and comply with the Visa, Mastercard and Discover contracts.

Coop also stated that he has never seen the Brands enforce the contractual obligation when reviewing organizations’ ROCs and SAQs.  That is also a true statement but again not the complete story.  Based on what I have been told by lawyers that have been involved in breach litigation, it is the merchant agreement/contract that is used to hold breached merchants legally responsible and enforce fines, not PCI compliance or what is in any PCI document.  The PCI documents are used to influence fines and penalties, but the actual enforcement is through the contracts with the Brands.  If it is found that an organization was using non-PCI compliant service providers that just adds fuel to the fire.

As famous radio personality Paul Harvey used to say, “And that, is the rest of the story.”

Advertisement

Surprise! PCI Largely Ignores Disaster Recovery

As a lot of people are finding out when they rolled out work from home (WFH) for COVID-19, it turned out that compliance with the PCI DSS was not in place and in some cases, not even possible.  If the PCI Dream Team session last week is any example, I think a lot of QSAs got calls and emails from their clients asking what the Hell had happened?

What we are all experiencing is a shortcoming of the PCI DSS and a point that has been discussed off and on since it came into existence.  The problem is that the PCI DSS does not worry about business continuity (BCP) or disaster recovery (DR) unless there is cardholder data (CHD) or sensitive authentication data (SAD) involved which typically only occurs when that data exists at hot/warm recovery sites.  If the CHD/SAD is only there when recovery is occurring, then those locations are out of scope.

Unfortunately, the COVID-19 event is not your normal “disaster”.  With the invocation of WFH, production data centers and offices were still fully operational which is typically the concern of BCP/DR.  What changed was that the government enacted stay at home or shelter in place orders and the recovery site became an employee’s home, not your expected recovery location.  Worse, since WFH would not involve CHD/SAD until it was invoked, QSAs had no reason to assess any plans for such recovery because they were not in-scope until activated.

That said, a lot of QSAs (myself included) usually did have a discussion with clients that, while their BCP/DR plans were not in-scope, clients should occasionally assess those plans to make sure that, when invoked, the plan maintained PCI compliance.  Because when the BCP/DR was invoked, whatever was done had to be PCI compliant the moment it was used.

And there is the rub in all of this.  There is no grace period with PCI compliance because of the invocation of BCP/DR.  You are expected to be 100% PCI compliant regardless.

There are a number of lessons learned due to the COVID-19 disaster.

• BCP/DR will need to be updated for pandemic incidents including WFH capabilities. According to the World Health Organization (WHO) and the Centers for Disease Control (CDC), pandemics are not going to go away, so the ability to continue operations remotely is going to have to be part of an organization’s recovery options.
• WFH capabilities will have to be incorporated into normal production capabilities. This effort will need to address PCI compliance as well as HIPAA, CCPA, GDPR and any other relevant security and privacy programs your organization may have to comply with.  I have had a number of organizations enact such capabilities, policies and procedures for various parts of their operations over the years due to changing work requirements of their personnel as WFH offers a number of flexible advantages for retaining employees.
• Implement virtual desktop infrastructure (VDI) to provide office as well as remote working capabilities. This can also potentially allow WFH to use an employee’s BYOD as long as they are not required to be PCI compliant.  Use of VDI allows the use of thin clients and Chromebooks to be used as workstations making security of those workstations a bit easier as well as reducing the cost.
• Implement P2PE or end-to-end encryption (E2EE) solutions for the entry of CHD/SAD into applications. There are a number of USB and Bluetooth options available from the various point of interaction (POI) vendors such as Verifone and Ingenico as well as other third-party application vendors.
• Softphones create a larger scope by bringing the workstation they connect to into full scope for PCI compliance. The number of requirements that need to be assessed can be reduced by using VDI and connecting the softphone to the VDI through the workstation.  Making such a connection though is not “plug and play”, so be prepared to have to work a lot with the VDI vendor to make that connection work.  But do not be surprised if it does not provide a reliable and/or clear connection, so make sure you are prepared to have to place the full workstation into scope to have an acceptable working solution.
• If you are expecting to use The Cloud for your VDI or application, make sure that you conduct appropriate capacity planning so that you are not caught without the ability to expand that solution due to WFH. A lot of organizations have found with the COVID-19 event that their Cloud implementation did not scale as they thought it would.  It turned out that Cloud providers have capacity limitations just like in-house data centers.  While you are not using that capacity all of the time, you need to reserve it for those instances when you need it.  While not free, that excess capacity can be reserved for such events as COVID-19 so that when you need it, it is available.

Requirement 12.9

I discussed requirement 12.8.2 in a prior post which applies to all organizations being PCI assessed.  Let us now turn our attention to requirement 12.9 which only applies to organizations that are service providers.  If you are unsure if you are a service provider, see this post and this post.

As a refresher, requirement 12.9 states:

“Service providers acknowledge in writing to customers that they are responsible for the security of cardholder data the service provider possesses or otherwise stores, processes, or transmits on behalf of the customer, or to the extent that they could impact the security of the customer’s cardholder data environment.

Note: The exact wording of an acknowledgement will depend on the agreement between the two parties, the details of the service being provided, and the responsibilities assigned to each party. The acknowledgement does not have to include the exact wording provided in this requirement.”

The Guidance for 12.9 states:

“In conjunction with Requirement 12.8.2, this requirement is intended to promote a consistent level of understanding between service providers and their customers about their applicable PCI DSS responsibilities. The acknowledgement of the service providers evidences their commitment to maintaining proper security of cardholder data that it obtains from its clients.

The service provider’s internal policies and procedures related to their customer engagement process and any templates used for written agreements should include provision of an applicable PCI DSS acknowledgement to their customers. The method by which the service provider provides written acknowledgment should be agreed between the provider and their customers.”

As with 12.8.2, we are told in the requirement’s Note that “exact wording” is not required.  So those of you looking for “exact wording” need to move beyond that fact.

The key though to 12.9 is that the service provider’s contract, master service agreement or whatever other legal documents used need to ensure that they acknowledge their requirements to protect the payment card data they process, store, transmit or could affect the security of the payment card data.

It is that last statement that catches a lot of service providers.  Like it or not, even if a service provider does not directly come into contact with sensitive authentication data (SAD) or cardholder data (CHD), if they can affect the security of that data, they need to be PCI compliant.  This usually catches managed service providers (MSP) such as those that manage/monitor firewalls, network devices, servers and security incident and event management (SIEM) solutions and they will argue incessantly that they do not need to be PCI compliant.  Unfortunately for them, the Council, the card brands and QSAs will tell them otherwise.

In the end requirement 12.9 is all about service providers providing the necessary information and documentation such that the organizations they provide those services can comply with requirement 12.8.2.  To that end, there are two tests for 12.9 in the ROC Reporting Template and those tests state:

“Identify the service provider’s policies and procedures reviewed to verify that the service provider acknowledges in writing to customers that the service provider will maintain all applicable PCI DSS requirements to the extent the service provider possesses or otherwise stores, processes, or transmits cardholder data on behalf of the customer, or to the extent that they could impact the security of the customer’s cardholder data environment.” and

“Describe how the templates used for written agreement verified that the service provider acknowledges in writing to customers that the service provider will maintain all applicable PCI DSS requirements to the extent the service provider possesses or otherwise stores, processes, or transmits cardholder data on behalf of the customer, or to the extent that they could impact the security of the customer’s cardholder data environment.”

The first test is all about having some sort of legal agreement in place that the service provider acknowledges that they need to comply with all relevant PCI standards.  Where this test broke new ground is the addition of the statement:

“… or to the extent that they could impact the security of the customer’s cardholder data environment.”

This statement came in as part of v3.2 of the PCI DSS.  It was added to the test to clarify to QSAs/ISAs that service providers are also those that can influence the security of payment information (e.g., managed service providers with access to PCI in scope devices).

The second test is to ensure that service providers that rely on boilerplate agreements ensure that those boilerplates contain the necessary language that requires the service provider to maintain their PCI compliance.  The idea being that if it is in the boilerplate, it is less likely to be removed.

I am sure a lot of you are questioning who ensures that the boilerplate language does not get removed or modified?  That is one of the purposes of 12.8.2 on the customer’s side of the equation.  This is why the testing meshes with each other.  The service provider’s QSA/ISA makes sure that the language is in the standard agreements.  The customers’ QSA/ISA makes sure that the language still remains in the agreements.  Each are a check on the other.

I cannot stress enough the importance of QSAs/ISAs filling out the service provider’s AOC correctly let alone using the correct form and instructing their service provider clients to give the AOC to any customer that requests the AOC.  There is nothing more frustrating than service providers who refuse to provide their service provider AOC.  It is not a secret as many apparently believe.  And please, do not refer your customers to either the Visa or MasterCard service provider lists.  That is also not what your customer or their QSA/ISA needs for their assessment.  Yes, it does confirm that your organization is PCI compliant, but tells the customer nothing about their PCI compliance responsibilities when using your services.  That is the whole point of why customers need your AOC.  Get over it and put your service provider AOC in your customer portal like you do your SOC1 and SOC2 reports.

There you have it about requirements 12.8.2 and 12.9.

Requirement 12.8.2

I got a comment a while back about contracts and PCI compliance.  The two requirements that are relevant in this discuss are 12.8.2 and 12.9.  Requirement 12.8.2 is for all organizations (merchants and service providers) that are being assessed under the PCI DSS.  Requirement 12.9 is only for service providers.

As usual, the clarifications surrounding these requirements were all provided verbally over the years at various PCI Community Meeting presentations and Q&A sessions.  But the overall gist of these requirements can be readily determined.  It just takes a little bit of effort and looking at more than just the PCI DSS.

Requirement 12.8.2 states:

“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.

Note: The exact wording of an acknowledgement will depend on the agreement between the two parties, the details of the service being provided, and the responsibilities assigned to each party. The acknowledgement does not have to include the exact wording provided in this requirement.”

The Guidance provided for 12.8.2 states:

“The acknowledgement of the service providers evidences their commitment to maintaining proper security of cardholder data that it obtains from its clients. The extent to which the service provider is responsible for the security of cardholder data will depend on the particular service and the agreement between the provider and assessed entity.

In conjunction with Requirement 12.9, this requirement is intended to promote a consistent level of understanding between parties about their applicable PCI DSS responsibilities. For example, the agreement may include the applicable PCI DSS requirements to be maintained as part of the provided service.”

If things are still not clear enough, it helps to look at the ROC Reporting Template to get clarification.  The tests being conducted for a given requirement usually clear up any confusion regarding what is being expected.  There is only one test for 12.8.2 and it states:

“Describe how written agreements for each service provider were observed to include an acknowledgement by service providers that they will maintain all applicable PCI DSS requirements to the extent the service provider handles, has access to, or otherwise stores, processes, or transmits the customer’s cardholder data or sensitive authentication data, or manages the customer’s cardholder data environment on behalf of a customer.”

The first thing to notice in all of these discussions is that nothing in the PCI DSS states that any organization is required to work with a PCI compliant third party.  None of the requirements in 12.8 specify that an Attestation Of Compliance (AOC) be provided.  A lot of QSAs will argue that requirement 12.8.4 requires it, but if you read the test:

“Describe how it was observed that the entity maintains a program to monitor its service providers’ PCI DSS compliance status at least annually.”

There is nothing in that test that explicitly mandates that an AOC is required to monitor third parties.  Granted an AOC is the easiest way to monitor service provider compliance, but there is nothing explicitly calling it out in this test.

So where does this “requirement” originate?  It comes from the merchant agreements with the card brands, specifically Visa and MasterCard.  They require that their merchants only work with third parties that are PCI compliant and can prove that compliance with a Service Provider AOC.  This is why it is important to read and understand the brands’ merchant agreements and their own security programs.  There are a number of key “requirements” that come from those documents that are just as important as what is in the PCI DSS.  So, read them as well as all of the PCI documents.

Getting back to the PCI DSS, what the Council wants QSAs and ISAs to look for in contracts, master service agreements, addendums and any other legal documents that describe the parties’ legal relationship is some sort of acknowledgement between all parties that they will abide by the PCI DSS and ensure that sensitive authentication data (SAD) and cardholder data (CHD) is kept secure.

Where a lot of QSAs/ISAs go wrong is demanding that the words “PCI DSS”, “PCI standards” or other explicit acknowledgement of “PCI” something to appear somewhere in those documents.  The Council has stated a number of times that explicitly using “PCI DSS”, “PCI standards” or “PCI” anything is not required.  It would be great if such documents did, but a lot of legal documents do not because they either predate the PCI DSS or lawyers argue it is not necessary.  That is what led to the Note in both requirements.  The key is the last sentence which explicitly states:

“The acknowledgement does not have to include the exact wording provided in this requirement.”

It is this sentence that the Council always points to and states that this is why explicit statements of PCI or any other direct reference to PCI is not necessary nor required.  My advice is, when in doubt, ask your client’s legal counsel for their legal interpretation of the legal agreements and whether they fell it covers the PCI responsibilities of the parties involved.

That will lead you to the fact that a lot of legal agreements reference the PCI DSS and PCI standards indirectly through language that obligates the parties to follow and comply with “regulatory or other legal requirements”.  The reason this language works is because “other legal requirements” will drag in the card brand legal agreements for taking and processing card payments.  Every card brand has legal agreements for merchants and service providers that explicitly call out that the customer of the brand will maintain PCI compliance for all relevant PCI standards.

Where this discussion becomes problematic is with service providers that do not directly process, store or transmit SAD/CHD such as managed service providers and the like that can affect the security of payments.  That is because they are not directly under the card brands’ legal agreements, so their contracts while using the same “regulatory or other legal requirements” will not necessarily be referencing PCI compliance because they are indirectly involved.  It is in these cases that I rely on getting a PCI AOC from the service provider which then provides the additional assurance that the service provider understands that they need to be PCI compliant.

It is when I cannot obtain an AOC from a service provider that I then explain to my client that this service provider’s environment needs to be assessed as part of their assessment.  Either that or my client needs to find a new PCI compliant service provider.

What a QSA/ISA needs to be looking for in a service provider’s AOC is a couple of things (actually, there are a lot of things, but these are the most important).

First, you need to ensure that the services provided to your client have all been covered by the service provider’s assessment.  Section 2a of the AOC documents the services covered and not covered.  The most common problem found with section 2a is that one or more services used by an organization were not assessed.  If services were not assessed, then you need to notify the service provider and develop a plan of how to handle this situation.

The next thing to review is the locations that were part of the assessment.  It still amazes me the number of AOCs I review where a client’s data center or processing center was not part of the assessment.  It gets worse when you bring this to the attention of the service provider and they get put out or worse, they argue with you over the fact that they must review every facility where a service is conducted.  I am sorry, the PCI SCC and the card brands are the ones that make the rules, I am just the poor assessor that must enforce and live by them.

Finally, you need to review section 2g for all of the services assessed (if they were assessed from section 2a).  Section 2g are a matrix of the 12 PCI DSS sections that explains who is responsible for the various PCI DSS requirements.  From this matrix an organization is to construct their PCI program to fit the controls that they need to implement to be PCI compliant for this service.

There should be a section 2g for every individual service assessed, but in instances where PCI coverage is the same for different services (e.g., SaaS application hosting), you can combine services in section 2g.  However, this is where problems usually are found.  My favorite example of such a problem is the day I found data center co-location and call center services listed in the same matrix.  I am sorry, but those services have very little similarity particularly in PCI controls.  When you encounter this situation, it is usually indicative of a QSAC that does not understand how to deal with service providers and is cutting corners to get the ROC and AOC out the door.  In addition, it also likely indicates a service provider that is just “checking a box” for PCI compliance to placate customers.  But worse is when that service provider is listed on the Visa or MasterCard service provider lists (it is rare, but I have seen it) which then indicates that the brands are also not doing their due diligence in their review of the AOC.

Hopefully, you now better understand requirement 12.8.2.  In a future post I will discuss requirement 12.9.

Can I Use SSAE 18 SOC 2 Reports? Part 1

This is a common question that QSAs encounter from clients.  The client has an SSAE 18 Controls at a Service Organization (SOC) report from one of their service providers and they want to know if they can use it to satisfy any or all of the requirements in 12.8, 12.9 and 12.11 related to vendor management?

The biggest caveat in this discussion is that the PCI SSC does not sanction the use of any report other than a PCI Attestation Of Compliance (AOC) and/or a PCI Report On Compliance (ROC) in addition to any other PCI reports.  The Council has repeatedly stated that if a QSA chooses to rely on an SSAE 18 SOC 2 report (or any other compliance report for that matter), the QSAC and their client accepts the risk if the SSAE 18 SOC 2 does not cover what the QSA claims it covers and therefore relies upon it for fulfilling PCI ROC requirements.  As a result, most QSAs will not accept an SSAE 18 SOC 2 report (or any other non-PCI compliance reports) for any reason.

For those of us “recovering” certified public accountant (CPA) types that have conducted SSAE18 audits, we know how to read and interpret these reports.  As a result, when we are asked about SSAE 18 SOC 2 reports being relevant, our answer is that, “It depends on what the SOC 2 covers and how it was tested.”

Before we get too deep into this discussion though, we need to define the terminology surrounding this topic.  The first thing is that SSAE 18 replaced SSAE 16 as of 2017 even though nothing else appears to have changed.  The next key thing anyone needs to know about SSAE 18 is that there are three reports that can come from this reporting series: SOC 1, SOC 2 and SOC 3.

The first, SOC 1, is for financial auditors only.  It used to be called a SAS 70 years ago.  It is a report focused on financial controls that an external auditor needs to ensure that the financial numbers coming from the third party can be relied upon in their annual audit of their client.  Yes, these SOC 1 reports can cover security controls, but that is only in regard to financial systems, not necessarily the third party’s entire environment.  In addition, the control coverage is typically not as deep as required for PCI compliance.  The bottom line is that any reliance on a SOC 1 report outside of financial systems should never be assumed.

I am going to cover the SOC 3 report next because it covers all of the security domains.  The SOC 3 report (also sometimes referred to as the ‘SysTrust’ report) covers the following domains:

• Organization and Management – The criteria relevant to how the organization is structured and the processes the organization has implemented to manage and support people within its operating units.
• Communications – The criteria relevant to how the organization communicates its policies, processes, procedures, commitments, and requirements to authorized users and other parties of the system and the obligations of those parties and users to the effective operation of the system.
• Risk Management and Design and Implementation of Controls – The criteria relevant to how the entity (i) identifies potential risks that would affect the entity’s ability to achieve its objectives, (ii) analyzes those risks, (iii) develops responses to those risks including the design and implementation of controls and other risk mitigating actions, and (iv) conducts ongoing monitoring of risks and the risk management process.
• Monitoring of Controls – The criteria relevant to how the entity monitors the system, including the suitability, and design and operating effectiveness of the controls, and takes action to address deficiencies identified.
• Logical and Physical Access Controls – The criteria relevant to how the organization restricts logical and physical access to the system, provides and removes that access, and prevents unauthorized access to meet the criteria for the principle(s) addressed in the engagement.
• System Operations – The criteria relevant to how the organization manages the execution of system procedures and detects and mitigates processing deviations, including logical and physical security deviations, to meet the objective(s) of the principle(s) addressed in the engagement.
• Change Management – The criteria relevant to how the organization identifies the need for changes to the system, makes the changes following a controlled change management process, and prevents unauthorized changes from being made to meet the criteria for the principle(s) addressed in the engagement.

There are also some additional considerations that are related to Confidentiality specified in the Trust Services Principals and Criteria (TSP), but those are not required to be covered in the SOC 3 report.

Finally, there is the SOC 2 report.  The SOC 2 report uses the same TSP as the SOC 3 but with a twist.  The third party can select any or all of the seven domains to be assessed.  Think of it as a “cafeteria style” assessment.  With the SOC 2, the AICPA does not require that all domains be covered (as with the SOC 3), the assessed entity can select only those domains they wish audited.  As a result, a third party could select only the ‘Organization and Management’ domain to be assessed and nothing else in their SOC 2 report.  Therefore, just because you have a SOC 2 does not mean it covers the domains necessary for your PCI assessment.  Like the SOC 3, in addition to the seven domains, the SOC 2 can also cover none, any or all of the additional considerations documented in the TSP.

Within each of these SOC reports there is a Type I and a Type II report.  A Type I report is basically worthless from a reliance perspective because no testing of the controls is ever performed.  With a Type I report, the auditor is signing off on the fact that the third party has controls defined and formally documented.  But without testing, there really is no point to this report.  Yet every now and then, I encounter a Type I report that an organization has relied upon for years.

The only report worth anything is a Type II report which tests the control environment to ensure that the controls are functioning as designed.  So, when you get that SOC 2 report, you need to make sure you have a Type II report where testing has been performed by the auditor.  Even then though, the report might not be as useful as you might think.

I Have A SOC 2 Type II Report From A Service Provider

While you want to read the whole report in detail, when I am pressed for time and cannot read it in its entirety, here is where I focus so that I can get a quick view of what I have.  Some CPA firms provide a one-page Executive Summary that gives the reader a quick overview of the report, provides the timeframe the report covers, opinion, exceptions and other useful information.  But that is not required by the AICPA so you cannot always rely on such an overview being in every report you receive.  When they are available, they can help you focus your quick review efforts even better.

The first thing to do is to read the auditor’s opinion which should be the first section of the report.  It is in the form of a letter on the auditor’s letterhead and signed by the auditing firm.  The opinion the auditor provides will be either:

• Unqualified – no material control weaknesses or failures were identified.
• Qualified – some material control weaknesses or failures were identified.
• Adverse – significant control weaknesses or failures were identified.

An unqualified opinion is what all organizations desire and what most reports document.  But do not be fooled by an unqualified opinion.  There still could have been control weaknesses or failures identified but they did not rise to the level of being considered “material”.  I have seen some unqualified reports with control weaknesses that I would have considered material as their auditor, so you might still want to contact the organization to get clarification on any weaknesses identified.

A report with a qualified opinion is not the end of the world, but that will all depend upon what control weaknesses or failures created the qualification.  Someone misusing their access can be minor compared to not performing backups of servers for months.  As a result, you need to read each control weakness to determine the criticality of the control failure as well as review management’s responses to how they addressed or will address the failure.  Again, you may find yourself contacting the organization to clarify weaknesses documented.

In my experience, reports with an adverse opinion never get issued to the public.  Management sees all of the control failures and weaknesses and then embarks on the long arduous task of cleaning up their control environment.

The next section to look at is the one labeled ‘Information Provided by Independent Service Auditor’ or similar.  This is the section that will contain the testing results and will define which of the domains were covered as well as the timeframe the report covers.  Most organizations issue SOC reports annually, so you always want to make sure that you have the most current report.  If the coverage end date is getting within three months of a year old or more, you should contact the third party and ask them when the next report will be issued.  They should inform you that the new report is in progress and give you an estimated date the report will be issued.  If they do not give you a succinct answer, I would be concerned.

You need to go through this section looking at a couple of things.  The first is to determine which of the domains were covered.  While documenting those domains, you also need to review the testing that was performed and at what level of detail those tests were conducted.  For example, it is not unusual to see tests for change control cover five random changes but not test those changes for having appropriate documentation, backout instructions and testing, only that the changes were approved.  At some point you will need to read this section carefully to determine what, if anything, will cover the testing required by the PCI DSS.  But a quick perusal will usually give you an idea of what you are likely going to get out of the SOC 2 for PCI compliance, if you are going to get anything at all.

This leads to the next section of the report you should read.  The last section of all SOC reports is usually titled ‘Supplemental Information Provided By [Organization Name]’.  This section contains information that was provided by the entity being audited but is not covered by the auditor’s opinion.  There can be all sorts of information presented here but the important point to remember is that the auditor did not test or assess the accuracy of that information.  So, you need to take any information provided in this section with a bit of skepticism.

It is in the Supplemental Information section that you want to look for a sub-section titled ‘Management’s Response to Control Exceptions’ or similar.  Even when an organization has an unqualified opinion, there can still be items listed in this section.  If there are items listed, you want to carefully read what those items were and how management addressed or corrected the condition.  If you find any control issues and responses that concern you, you should contact the entity and get those discussed so that you are comfortable with the situation.  If you cannot get comfortable with the situation, then you may want to consider additional controls at your end to compensate for the control weakness with the third party.

In the next postpost I will take you through a more thorough review of the SOC report.

Business Continuity And PCI

This topic came up this past week in a conversation.  I had to go to the PCI DSS v3.2 and check to make sure what was being discussed was accurate.  The discussion was around requirement 12.10.1 which says:

“Create the incident response plan to be implemented in the event of system breach. Ensure the plan addresses the following, at a minimum:

• Roles, responsibilities, and communication and contact strategies in the event of a compromise including notification of the payment brands, at a minimum

• Specific incident response procedures

• Business recovery and continuity procedures

• Data backup processes

• Analysis of legal requirements for reporting compromises

• Coverage and responses of all critical system components

• Reference or inclusion of incident response procedures from the payment brands.”

The points of the discussion focused on the third and fourth bullets.  Yes, that is right, they are calling out business recovery and continuity procedures and data backup processes.  This caught me a bit flat footed at first.

For those of you that have been involved in or around PCI for a while are probably scratching your heads because the PCI DSS has never truly cared about business continuity unless it was a hot failover solution.  The Council has even said so much at various Community Meetings over the years when business continuity and disaster recovery have come up as question topics.

So, what is the deal?

Well, the guidance provided for 12.10.1 sure does not give you a clue as it only says:

“The incident response plan should be thorough and contain all the key elements to allow your company to respond effectively in the event of a breach that could impact cardholder data.”

And the Report On Compliance (ROC) is still only asking for the name of the QSA that will attest to the incident response plan including these items.

Is the PCI DSS now interested in business continuity?

As I said earlier, the PCI DSS was to a degree interested in business continuity if it was always active as with a hot failover scenario and they have always been concerned about data backup processes as witnessed by requirements 9.5, 9.6, 9.7 and 9.8.  The more we discussed these topics the more we believe that the PCI DSS is looking for organizations to ensure continuity of their PCI compliance when they invoke their business continuity plan.

The PCI DSS has only included business continuity (aka disaster recovery) in scope if cardholder data (CHD) is actively involved.  This happens when organizations have hot recovery capabilities in their disaster recovery data center or are replicating data (that includes CHD) in real time to a disaster recovery site.  Otherwise, the disaster recovery site is not in scope for the PCI assessment.  As a result, most organizations push back on including their disaster recovery sites in their PCI assessments if they are cold or warm sites with no CHD involved.

However, here is the rub with that approach.  Under the PCI DSS and the card brand agreements, the moment that any disaster recovery site becomes active because of a disaster, it is required to be PCI compliant.  There is no grace period.  None.

So, if a disaster recovery site has never been assessed for PCI compliance, how does an organization know it will be compliant?  They do not.  There could be significant PCI compliance issues not just with the site, but with the emergency business processes as well.  That is why smart organizations periodically assess their disaster recovery sites and processes for PCI compliance so that there are few, if any, PCI compliance surprises when they activate them.

While the PCI DSS is not asking for an assessment of business continuity and data backup processes, the PCI DSS is providing a friendly reminder to organizations that business continuity can become a compliance problem and should be looked at before it creates an issue.

The Great Multi-Factor Authentication Debate

The Council brings back the Assessor Session to this year’s Community Meeting and it takes only one question to get passions flowing.  The question was to get a clarification of a comment made by Ralph Poore, Director, Emerging Standards at the Council, about multi-factor authentication (MFA).

First a little background to get everyone up to speed remembering that the US National Institute of Standards and Technology (NIST) SP800-63B standard in question is still a draft and has not been finalized.  However, everyone expects this standard to be adopted largely unchanged and with only minor wording revisions that would not affect the overall recommendations in the standard.

What NIST stated about SMS was in section 5.1.3.2. Out-of-Band Verifiers of SP800-63B which states:

“Due to the risk that SMS messages or voice calls may be intercepted or redirected, implementers of new systems SHOULD carefully consider alternative authenticators. If the out-of-band verification is to be made using the public switched telephone network (PSTN), the verifier SHALL verify that the pre-registered telephone number being used is not associated with a VoIP (or other software-based) service. It then sends the SMS or voice message to the pre-registered telephone number. Changing the pre-registered telephone number SHALL NOT be possible without two-factor authentication at the time of the change. OOB using the PSTN (SMS or voice) is deprecated, and may no longer be allowed in future releases of this guidance.”

NIST is only calling out that new implementations of SMS or voice MFA should consider the security implications of using SMS or voice for MFA.  But NIST has not totally invalidated any existing SMS and voice MFA solutions.  They just do not want any new implementations unless there is no choice because the process is already underway.  So while SMS or voice MFA can still be used in existing implementations, NIST is saying that future implementation of SMS and voice MFA are out of the question, have basically killed those solutions.

With that as our background, in a Community Meeting session, Ralph Poore stated that MFA to devices such as smartphones or back to the same device or browser (i.e., “soft” solutions) were not considered secure because of statements in the NIST Draft of SP800-63B.  I was attending a different session when Ralph made his statements, but I can tell you that my cell phone started buzzing with text messages from various people asking if we had all heard what we had heard.  But since there was no Q&A at that session, there was no way to clarify Ralph’s statements.

As a result, this issue was brought up in the Assessor Session to clarify those MFA comments.  Ralph stood and reiterated his remarks and that sent the room into an absolute tizzy.  It was pointed out that NIST had only invalidated SMS and voice for future two-factor authentication, not all soft token solutions such as RSA’s or Symantec’s application solutions.  However, Ralph continued to repeat his remarks saying that they had invalidated all soft solutions.  That brought the house down and people were loudly explaining that his comments were invalidating decades of recommendations for OOB MFA solutions.  Eventually the room calmed down and the Council agreed to review their position on such “soft” MFA solutions.

So that is where we are with this subject.  Time will tell if the Council revises its statements on MFA and comes into line with what NIST is saying on the subject.

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.

Heads Up – Changes To SAQ A

I had a question this week regarding v3.2 of SAQ A that pointed out there have been some changes to that SAQ that people may have not noticed given the larger issues with the changes to the PCI DSS.  As a reminder, SAQ A is the least amount of PCI requirements any in-scope organization can comply.

Those added requirements to SAQ A are:

• 2.1(a) – Are vendor-supplied defaults always changed before installing a system on the network?
• 2.1(b) – Are unnecessary default accounts removed or disabled before installing a system on the network?
• 8.1.1 – Are all users assigned a unique ID before allowing them to access system components or cardholder data?
• 8.1.3 – Is access for any terminated users immediately deactivated or removed?
• 8.2 – In addition to assigning a unique ID, is one or more of the following methods employed to authenticate all users?
• 8.2.3(a) – Are user password parameters configured to require passwords/passphrases meet the following?
• 8.5 – Are group, shared, or generic accounts, passwords, or other authentication methods prohibited
• 12.10.1(a) – Has an incident response plan been created to be implemented in the event of system breach?

Even when a merchant outsources all of their card processing, these are controls that can still apply because in a lot of cases, a merchant is responsible for setup, management and maintenance of their outsourced payment processes and applications.

In addition, merchant employees will also interact with an outsourced payment system to handle chargebacks and disputes.  Those user accounts used by the outsourced environment will normally be managed by someone at the merchant, not necessarily the service provider.

In regards to incident response, the merchant will be involved with incident response even when they have totally outsourced their payment environment.  The merchant will work with their outsourcer to work through an incident and those responsibilities of the merchant need to be documented.

As a result, the addition of these controls should not be a surprise to anyone.

PCI DSS v3.2 Draft Released

On Friday, April 15, 2016 while a lot of you were probably getting your US income taxes done, the PCI SSC decided to release the draft of v3.2 of the PCI DSS.  I know the announcement message to me from the Council ended up in my company’s spam filter, so you may want to check there if you did not receive a message.  I was lucky enough for a colleague to forward his copy along to me.  However to get the draft, you need access to the PCI Portal to obtain the draft PCI DSS v3.2 and the requisite change log.

These are some of the more notable changes in the new PCI DSS version.

• The draft provides an official sunset date for v3.1 of the PCI DSS. Regardless of the date in April that v3.2 is released, v3.1 will be withdrawn on October 31, 2016.  So any assessments done after that date will need to comply with and use v3.2.
• Two new sections to Appendix A have been added. In addition to the Appendix for shared hosting providers (now marked A.1), we get Appendices A.2 and A.3.  2 covers SSL and early TLS for those of you that will miss the June 30, 2016 date.  For those of you that thought 2018 was the deadline and missed discussions on the Webinar about the SSL/early TLS deadline, while the deadline was extended to June 30, 2018, any organizations missing the June 30, 2016 date must fill out Appendix A.2.  A.3 is where the Council added the designated entities supplemental validation (DESV) requirements.
• There are a number of new requirements for service providers that are best practices until February 1, 2018. Those new requirements include: (1) maintain a documented description of the cryptographic architecture, (2) detect and report on failures of critical security control systems, (3) perform penetration testing on segmentation controls at least every six months, (4) executive management to establish responsibilities for the protection of cardholder data and a PCI DSS compliance program, and (5) perform reviews at least quarterly, to confirm personnel are following security policies and operational procedures.  I would bet that numbers three and five will likely create a lot of contention with service providers.  But you have until February 1, 2018 to get those in place.  However, if experience teaches us anything, service providers had better start now getting these new requirements in place and operating.
• All organizations picked up the following new requirements that are best practices until February 1, 2018: (1) change control processes to include verification of PCI DSS requirements impacted by a change, and (2) multi-factor authentication for all personnel with non-console administrative access to the CDE. As with the aforementioned new requirements for service providers, these will also require a lot of organizations to get started now to ensure these new requirements are in place and operating.
• The Council clarified requirement 8.1.5 to show that it is intended for all third parties with remote access, rather than only vendors. While most organizations understood the intent of this requirement, there were a few that played “legal eagle” and refused to require compliance for non-vendors.
• Requirement 6.5 has been clarified that developers must go through secure coding training at least annually. This change will likely create some consternation for some organizations that are developing their own software that is in-scope for PCI compliance.
• Clarified 11.5.a by removing “within the cardholder data environment” from the testing procedure for consistency with requirement, as the requirement may apply to critical systems located outside the designated CDE. This will likely expand the number of systems that require critical file monitoring.
• Clarified 12.8 1 by saying that the list of service providers now must include a description of the service(s) provided.
• Clarified 12.8.2 by adding guidance that service provider responsibility will depend on the particular service(s) being provided and the agreement between the two parties.
• One of my pet peeves has finally been addressed. I have always had an issue with requirement 1.1.6 and the use of the terminology “insecure protocols”.  The reason is that in one way or another, all protocols have their insecurities whether they are known or not.  In v3.2, the Council has finally removed the “insecure” designation as, in their words, “these may change in accordance with industry standards.”  It is those small battles at times that make your day.

There are other clarifications and edits that have been made to the new version.

For all of us QSAs, we await the Reporting Template which will detail out the actual testing to be performed which will allow us to assess the real impact to the effort required to conduct an assessment.  As a result, there could still be some surprises with this new version of the PCI DSS.  So stay tuned.