Archive for the 'AOC' Category

15
Dec
16

The Council Speaks On A Number Of Topics

The Council had a Webinar session for QSAs and ISAs on Thursday, December 15. It was a great session, but at only an hour, there were a lot of questions that went unanswered.  The following were the more notable discussion topics.

Not Tested

The Council got the message and they are working on new wording for the AOCs as well as some guidance for “Not Tested” and how it can be used and not impact PCI compliance.  They expect to have something issued in the first quarter of 2017.

Network Segmentation and Scoping

This was a very hot topic and drew a lot of questions and some useful answers as well as generating a slew of new questions.

We got a definition of “purpose-built controls”.  There really is not any change here in what the Council has told QSAs and ISAs in the past regarding segmentation.  The bottom line is that “purpose-built controls” are those controls that segment one network from another network.  That can be firewall rules, access control lists (ACL) or any other controls that control or limit the communications from one network to another network.  I posed a question regarding encryption such as TLS and IPSec as still being a valid segmentation control, but it did not get answered.  I am assuming that it still is a valid control given the Council’s statement that nothing has changed, but until we have explicit confirmation, that still is an assumption, not a fact.

The Council answered a number of questions regarding whether or not in-scope devices can be on the same network segment as out of scope devices can co-exist.  As usual, we go the “it depends” discussion.  The bottom line is that it depends on the threat presented by the out of scope devices to those in-scope.  If an organization has lax security controls over all of their networks and devices, then I would be hesitant to allow out of scope devices to be on the same network segment as in-scope devices.

One of the most amazing discussions on this topic was an answer given regarding whether or not a device that has only an outbound connection from the cardholder data environment (CDE) can be considered out of scope.  Under the Open PCI Scoping Toolkit, this would be categorized as a 2C system.  The Council started out with their stock answer of “it depends” and then clarified that answer.  The answer given was that while the system would be in scope because it is connected to the CDE, what requirements it would need to comply with would depend on the risk presented by the system to the CDE.  This seemed to give organizations an opportunity to argue a minimization of requirements.  I am sure this will result in a lot of arguments between QSAs, ISAs and their assessees in the future.

As a funny aside, the Council mentioned the “three hop rule” and then feigned ignorance as to where it came from.  As I pointed out in my post, it was from the 2014 Community Meeting in Orlando.

Not-Listed Encryption Solutions

This guidance is a train wreck and just seems to keep getting worse.  The Council gave a lot of answers to questions, but it just seemed like they were digging an ever deeper hole, not filling it in.

The biggest news is that the Non-Listed Encrypted Solution Assessment (NESA) document should be available for review in the first quarter of 2017.

The next biggest news was the Council reconfirming that this is only guidance/recommendations and not some new process that is mandatory.  They even made sure to tell everyone attending that QSAs are NOT to hold up an organization’s ROC/SAQ over not having a NESA for their E2EE solution.  So if an E2EE solution does not have a NESA, then the fallback based on a lack of guidance from the Council is to preform whatever procedures that the merchant’s acquiring bank recommends.

The purpose of this Information Supplement the Council stated was to provide QSAs, merchants, service providers and banks with the Council’s acceptable way to deal with assessing E2EE solutions.  While on its face this statement and rationale makes sense, it does not make sense from the standpoint that the organizations driving the E2EE solutions are the banks and processors that have partnered with the E2EE solution providers.  Given that the banks and processors are the same organizations driving PCI compliance of the merchants that consume those E2EE solutions it seems rather odd that they would be questioning what is acceptable for PCI compliance of their approved E2EE solutions.

At the end of the day, it just seems that this NESA process is a solution looking for a problem and that the only problem the process really solves is getting more E2EE solutions to just finish the NESA and validate as a P2PE solution.

Until the banks and processors get behind the NESA process, I see this effort as dead on arrival.

So it sounds like it will be a busy first quarter for the Council.

The Council stated that the slide deck for this session will be posted to the Portal sometime after the first of the year.

02
Dec
16

Not Tested Clarification

In the November 2016 Assessor Newsletter from the PCI SSC, there is a clarification on what ‘Not Tested’ actually means and implies.  I am sure this will really get some service providers whipped up as it will create some issues with work they perform on behalf of their customers.

The following is taken directly from that newsletter.

“Recently, AQM has received some questions about the impact of using “Not Tested” as a response within a completed ROC. This article is intended to address a few points briefly, with published documentation to follow.

  1. Due to an oversight, the option for “Not Tested” was not included in the summary findings table within the summary overview when that table was introduced with the ROC Reporting Template for use with PCI DSS v3.2. We will publish an errata for the ROC Reporting Template shortly.
  2. Some have asked whether one can have a compliant AOC in instances where “Not Tested” was used. While PCI SSC is not able to comment on matters of compliance, we would direct you to read the verbiage at Part 3 PCI DSS Validation of the Attestation of Compliance below:aoc-part-3

How to achieve “all questions answered affirmatively” is the question. PCI SSC does not consider “Not Tested” to be an affirmative statement. The difference between “Not Tested” and “Not Applicable” is that no testing at all is performed for “Not Tested” whereas for “Not Applicable” some testing is performed to confirm a given control is truly not applicable. As such, between “Not Tested” and “Not Applicable,” only “Not Applicable” can be considered an affirmative response.

The intent in introducing “Not Tested” was to achieve a better level of transparency as to the level of compliance and this clarification supports that intent. If you have questions or suggestions, please reach out to the QSA Program Manager.”

It is that second to the last paragraph that will likely send most people off of the deep end.  Their comment that the “PCI SSC does not consider “Not Tested” to be an affirmative statement” really got me going.  What exactly then was the point of using ‘Not Tested’ if you did not consider it an affirmative statement?  Which by the way, when using affirmative as an adjective, means “asserting the truth, validity, or fact of something.”  Last I checked, ‘Not Tested’ would be considered a truth or fact.

There are a number of options for the Council to take here.

  1. Change the wording in the ‘Compliant’ box in Part 3 to reflect that an entity is compliant with all of the requirements tested.
  2. Give us a box in Part 3 that says ‘Compliant with Exceptions’ or something of that ilk which would allow those entities not testing certain requirements to still be judged compliant with what was tested.
  3. Tell QSAs that an AOC cannot be filled out for assessments that mark any requirements as ‘Not Tested’ because an AOC is not relevant.

I remember at a number of past Community Meetings various Council representatives repeatedly and emphatically told those of us from the Accounting community that PCI assessments were not SAS 70 (now SSAE 16) engagements when we would invoke SAS 70 like rules for sampling, testing and the like.  Well, I hate to say it, but the Council is sure turning them into one with all of these pronouncements.

UPDATE: On the Council’s Webinar on Thursday, December 15, it was announced that the Council will be making changes to the AOC and will issue new guidance on this topic sometime in the first Quarter of 2017.  So stay tuned for an update.

18
Jul
16

Third Party Service Provider PCI Compliance

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

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

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

What Organizations Are Service Providers?

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

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

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

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

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

Service Provider Levels Explained

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

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

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

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

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

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

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

The Global Registries

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

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

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

Service Provider AOC Issues

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

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

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

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

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

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

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

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

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

Non-PCI Compliant Service Providers

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

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

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

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

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

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

09
Apr
16

Living In PCI Denial

This was one of those weeks where you see something and all you can do is shake your head and wonder what some organizations think when it comes to PCI.  What added insult to injury in this case was that the organization arguing over PCI compliance is the manufacturer of card terminals, also known as point of interaction (POI).  It shocked me that such an organization was so clueless about PCI as a whole when you would think it is their business to know. But to add insult to injury, my client’s transaction processor and acquiring bank are also apparently clueless.

As background, I am working on a client’s Report On Compliance (ROC).  This client has almost completed with their roll out of an end-to-end encryption (E2EE) solution at all of their 4,000+ retail locations.  This E2EE solution will take all but the POI at those retail locations out of scope for PCI compliance.  That is the good news.

But if there is good news, you know there must be bad news.  In reviewing their documentation of this E2EE solution, I discovered that the POI vendor is providing management and updates to the POI through a terminal management system (TMS).  Since this TMS solution/service connects directly to my client’s cardholder data environment (CDE), I naturally asked the client for a copy of the vendor’s Attestation Of Compliance (AOC) for the TMS solution/service.

I thought those worthless PCI Certificates of Compliance took the cake.  Then, BAM!  I got the following message forwarded to me by my client from the POI vendor.  I have redacted all of the potential information that could identify the relevant parties and the TMS solution/service.

“Please see the follow up note below that you can send to your QSA for review and feedback:

  1. TMS systems in our industry do not require any type of PCI certification since PCI is concerned about card holder information that would be at risk. Since [vendor solution] does not have any card holder data at all, it falls outside of PCI requirements.  [Vendor solution] is merchant configuration and estate management tool only and as such, no payment card information passes through it, or directed to it.  In addition, no secure keys are stored on [vendor solution] so transaction data cannot be decrypted with anything on [vendor solution] or POS.
  2. [Vendor] Hardware and [vendor solution] Software are all PCI PTS compliant and certified and listed on the PCI website. Transactions are encrypted in hardware using the [encryption solution] keys which again [vendor solution] has no knowledge.  Transaction information can only be decrypted by [processor] the processor.  [Vendor solution] has no knowledge of this encrypted information being sent directly from the [vendor] to the processor.
  3. The beauty and simplicity of [vendor solution] semi-integrated terminal application is that is has all transaction data go directly to the Processor ([processor]) and no customer data is directed to the POS or [vendor solution] which makes the POS out of PCI Scope by the very nature of no card holder data in their environment.
  4. [Client] has a merchant certification with [processor] for the [encryption solution] with our [vendor solution] terminal application. Any questions regarding the certification should be directed to [acquiring bank] or a [processor] representative.

Let us know if your QSA has any further questions and we can also schedule a concall with all parties to address any concerns on [vendor solution] TMS and PCI.”

The first thing that wound me up is that this vendor is a business partner of my client’s transaction processor.  The processor is also a business partner of my client’s acquiring bank.  Those two organizations put forth this vendor to my client as being able to provide POI compatible to the processor’s E2EE and tokenization solution.  Obviously from this vendor’s response, these two well-known institutions did nothing in the way of due diligence to ensure that this vendor and its services were PCI compliant.

The second thing that totally irritated me is that there is no excuse for this vendor’s uneducated response.  Granted, this vendor is new to the US market, but they have been supplying POI to other merchants all over other parts of the world.  Which then starts to make you wonder just how lame are the banks, processors, card brands and other QSAs that they have not been called on the carpet about this before.  But that is a topic for another post and a good reason why the FTC is investigating the PCI compliance industry.

So let me take apart this vendor’s response.

“TMS systems in our industry do not require any type of PCI certification since PCI is concerned about card holder information that would be at risk.”

Wrong!  On page 10 of the PCI DSS the first paragraph under ‘Scope of PCI DSS Requirements’ clearly defines what is in scope for PCI compliance.

“The PCI DSS security requirements apply to all system components included in or connected to the cardholder data environment. The cardholder data environment (CDE) is comprised of people, processes and technologies that store, process, or transmit cardholder data or sensitive authentication data. “System components” include network devices, servers, computing devices, and applications.”

The operative phrase the TMS solution/service falls under is “connected to”.  The TMS solution/service directly connects to my client’s CDE.  That solution/service may not process, store or transmit cardholder data (CHD) or sensitive authentication data (SAD), but it is directly connected to my client’s CDE.  As a result, according to the above definition, the TMS solution/service is definitely in scope for PCI compliance.

“[Vendor] Hardware and [vendor solution] Software are all PCI PTS compliant and certified and listed on the PCI website.”

PTS certification is a card brand requirement, not a PCI DSS requirement.  Nowhere in the PCI DSS does it require that a PTS certified POI be used so I really do not care about this statement as it has nothing to do with my PCI DSS assessment activities.  If PTS were a PCI DSS requirement, then all of those people using Square and the like would be non-compliant.

“In addition, no secure keys are stored on [vendor solution] so transaction data cannot be decrypted with anything on [vendor solution] or POS.”

“Transaction information can only be decrypted by [processor] the processor.”

True, your TMS solution/service does not have the encryption keys.  But the firmware delivered by the TMS solution/service does have access.  (Unless you are the first POI vendor I have ever encountered that spent the huge amount of money required to truly create a hardware-only encryption solution.)  Given the low retail price and discounting of your POI you gave my client, I very seriously doubt that is the case.  So the firmware that your TMS solution/service delivers is what is doing the encryption and therefore has access to the encryption keys.  So while the TMS solution/service does not have the keys, it could be used to deliver rogue firmware that could obtain them.

Then there is the firmware delivery itself by your TMS solution.  If someone hacks your TMS environment, how easy would it be for them to have it deliver a rogue version of your firmware?  Since my client has no AOC, I have no idea if your security measures surrounding your TMS solution are adequate to prevent such an attack.

“[Client] has a merchant certification with [processor] for the [encryption solution] with our [vendor solution] terminal application.”

Such a statement ranks up there with those previously mentioned worthless PCI Certificates of Compliance.  Any QSA is required to obtain an AOC for the TMS solution/service to ensure that it is PCI compliant or the solution/service must be assessed as part of the merchant’s PCI assessment.

PCI DSS requirements under 12.8 are very clear as to everything a merchant needs to be able to provide to their QSA regarding third party PCI compliance.  Primarily of which is that AOC for your TMS solution/service among other items of evidence.

So I have a conference call with my client’s bank to discuss this situation.  I pushed back very hard when they told me that my client needs to do a compensating control for their business partner’s incompetence.  I even got an “atta boy” from the bank for identifying to them that they have a PCI compliance and potential security issue.  But I could not make the bank budge on the compensating control so I am off to get that written.

The lesson to be learned from this post is that nothing can be taken for granted when doing a PCI assessment even when you transaction processor and bank are involved.  A lot of people and QSAs would assume that a POI vendor would know better and that their bank and transaction processor had vetted the POI vendor.  Therefore, why do I have to worry about this vendor?  However as I have pointed out, you can never take anything for granted even when it involves organizations that you would think would know better.

This is just one way of many that could result in an organization being breached.  The TMS solution/service is a gateway directly to the merchant’s CDE.  Yet there has been no PCI assessment of that solution/service to ensure that it is PCI compliant and the risk it could be subverted has been minimized.

Thank goodness it is the weekend.  Oh, wait.  This weekend’s project is my income taxes.  Looks like I will be cranky all weekend as well.

09
Mar
16

The FTC Enters The Fray

On Monday, March 7, the United States Federal Trade Commission (FTC) issued a news release that I am sure got a lot of notice by practice leaders of the PCI qualified security assessor companies (QSAC). On Friday, March 4, the FTC commissioners decided in a 4-0 vote to compel the following QSACs to respond to a 6(b) Special Report order.

  • Foresite MSP, LLC;
  • Freed Maxick CPAs, P.C.;
  • GuidePoint Security, LLC;
  • Mandiant;
  • NDB LLP;
  • PricewaterhouseCoopers LLP;
  • SecurityMetrics;
  • Sword and Shield Enterprise Security, Inc.; and
  • Verizon Enterprise Solutions (also known as CyberTrust)

The first thing that is notable in my mind is that some of the big players in the PCI assessment business are absent from this QSAC list. I am not sure how the FTC arrived at this QSAC list, but it would be interesting to know their methodology.

But even more interesting and concerning is the information the FTC is requesting. From their request, here is a sample of some of the questions they are asking and the information they are seeking.

  • For each year of the Applicable Time Period, state the number and percentage of clients for which You completed a Compliance Assessment and for which You declined to provide: a “Compliant” designation on the Attestation of Compliance (“AOC”); or an “In place” designation on the final Report on Compliance (“ROC”).
  • For each year of the Applicable Time Period, state the number and percentage of clients for which You completed a Compliance Assessment and for which You provided: a “Non-compliant” designation on the AOC; or a “Not in place” designation on the ROC.
  • The extent to which the Company communicates with clients in determining the adequacy of any compensating control. As part of Your response, provide all documents related to a representative Compliance Assessment that considered a compensating control, including all communications between the Company and the client or any third party such as PCI SSC, a Payment Card Network, an Issuing Bank or an Acquiring Bank.
  • The policies and procedures for completing a Report on Compliance (“ROC”), including, but not limited to a discussion of whether a draft report is created, whether that draft is shared with the client or any third party such as PCI SSC, a Payment Card Network, an Issuing Bank or an Acquiring Bank, whether the Company accepts input on the draft from the client or any third party, and whether the Company ever makes changes to the draft report based upon the client or other third parties’ input. As part of Your response, provide all documents relating to a representative Compliance Assessment in which You provided a draft of the report to the client and/or any third parties, including a copy of the draft report, any communications with the client or third parties about the draft report, and the final ROC.
  • Provide: a copy of the Compliance Assessment with the completion date closest to January 31, 2015; and a copy of a Compliance Assessment completed in 2015 that is representative of the Compliance Assessment that the Company performs. For each Compliance Assessment provided in response to this specification, the Company shall also include a copy of any contract with the client for which the Compliance Assessment was performed, all notes, test results, bidding materials, communications with the client and any other third parties, such as the PCI SSC, a Payment Card Network, an Issuing Bank or an Acquiring Bank, draft reports, the final ROC, and the AOC.
  • State whether the Company ever identifies deficiencies in a client’s network during a Compliance Assessment and gives the client the opportunity to remediate the deficiency before the Company completes its final ROC. If so, provide all documents relating to a representative Assessment where the Company gave the client an opportunity to remediate before completing the ROC, including any communications between the Company and the client or any third parties such as PCI SSC, a Payment Card Network, an Issuing Bank or an Acquiring Bank, and the final ROC and AOC.
  • State whether the Company ever identifies deficiencies in a client’s network during a Compliance Assessment and issues a final ROC before the deficiencies are remedied based on assurances that the client will remedy the deficiencies in the future. As part of Your response, provide copies of all policies and procedure related to remedying deficiencies.
  • State whether the Company has any policies or procedures relating to potential conflicts of interest, including, but not limited to, any policies that prevent the Company from providing Compliance Assessments to clients to which it has also provided another type of service, or that concern the marketing or provision of other services to clients for which You have provided a Compliance Assessment. As part of Your response, provide copies of all relevant policies and procedures.
  • State the annual number of the Company’s Compliance Assessment clients that have suffered a Breach in the year following the Company’s completion of the Assessment for each year of the Applicable Time Period. For each such client, state whether it was subsequently determined not to be PCI compliant and provide the date of the initial Compliance Assessment and any communications between the Company and client or any third parties such as PCI SSC, a Payment Card Network, an Issuing Bank or an Acquiring Bank related to the Breach.

All of these questions lead one to believe that the FTC is looking to confirm that the PCI assessment process is a sham.

It will be very interesting to see how the FTC interprets the results of this effort. However, based on these questions and how I know they will end up being answered, I would venture to say that the result will be the government getting into the data security game with regulations.

11
Dec
15

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

PCI SP AOC Part 2gThey 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.

PCI SP AOC Part 2aIf 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.




Announcements

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

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

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

Calendar

February 2017
M T W T F S S
« Jan    
 12345
6789101112
13141516171819
20212223242526
2728  

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

Join 1,775 other followers