What If?

Here is a thought provoking question that was posed to me recently by a former accomplice in the PCI world.

What if PCI DSS assessments were only required until a merchant proved they were PCI compliant or if a merchant had been breached?

The premise behind this idea is simple.  There are going to be merchants that get information security and there are those merchants that are never going to get information security no matter the carrots or sticks employed.  Not that merchants that get information security cannot be breached, but the likelihood is significantly lower than merchants that do not get information security.

Merchants would go through the PCI DSS assessment process, clean up their act and ensure they are compliant and then they would only have to go back through the process if they were breached.  As a best practice, merchants could chose to periodically assess themselves after significant changes to their cardholder data environments to make sure no new security issues had been created or at annual intervals of say three to five years.

In the event that a merchant were breached, the PCI assessment process would be required annually for the next three years or until all of the card brands involved agreed to drop the reporting requirement, whichever comes first.  For Level 1 merchants, they would go through the Report On Compliance (ROC) process performed by a QSA or an ISA.  For all other merchant levels, they could use the appropriate self-assessment questionnaire (SAQ) but that SAQ would have to be reviewed and signed off by a QSA.

For high risk organizations that process, store or transmit large volumes of cardholder data such as processors or service providers that do transaction reporting, statement rendering or other similar services, they would still have to go through the ROC or SAQ D as they do today based on the levels defined by the card brands.

For service providers such as managed security service providers (MSSP) or cloud service providers (CSP), they would be required to go through an annual SAQ D, at a minimum, or a ROC, if they desired, for all services that are required to be PCI compliant.  The ROC would have to be prepared by a QSA or ISA and the SAQ D would have to be reviewed and signed off by a QSA.

As with merchants, if a service provider suffers a breach, all bets are off and they must do a ROC by a QSA or ISA for the next three years or until the card brands tell you to stop.

Visa and MasterCard currently maintain lists of PCI compliant service providers.  Service providers pay to be listed on those lists and the qualifications to get on those lists would also not change.

Regardless of whether an organization is a merchant or service provider, the quarterly external and internal vulnerability scanning and annual external and internal penetration testing requirements would remain the same.  Merchants would be required to file their results with the merchants’ acquiring bank or processor(s).  For service providers, their scanning and penetration testing results would be filed with the relevant card brands.  The scanning and penetration testing just help to keep everyone honest in their efforts to maintain their security.

I have to say, it sounds like a rational process to me if you accept the original premise that organizations will either do what it takes to be secure or will not.  Thoughts?

How The PCI Standards Will Really Die

Welcome to the new year.  I hope the holidays have been treating you well and the coming year is good as well.

There have been a number of articles written about why and how the PCI compliance process will die.  It is not that I look forward to the PCI standards dying as they have brought a needed visibility to information security and privacy as well as the fact that PCI keeps me gainfully employed.  However if things stay on their current trajectory, the PCI standards will eventually die, but not for the reasons being quoted in today’s articles.  The real killers of the PCI compliance process will be the card brands and the PCI Security Standards Council.  Yes, the very folks that brought us the PCI standards will bring the ultimate demise of their precious set of standards.

The first death knell I see is that it is very easy to issue edicts from on high when you do not have to implement them.  Over the years, clarifications have been issued, quality assurance reviews performed, forensic examinations conducted and a host of other activities have resulted in “enhancements” to how the PCI standards are assessed and enforced.  Do not get me wrong, a lot of what has been done was needed and appreciated.

However, by the same token, some of what has come down has been a nightmare to implement.  Any QSAC not using some sort of automated system to conduct their PCI assessments will find it impossible to meet the current and any future documentation and tracking standards now required by the PCI SSC’s QA process.  Under the current standards, QSACs need to document who they interviewed and what the persons were interviewed about as well as tying documentation and observations to the tests performed.  Without some sort of automated process, these requirements are just too intensive to perform manually.

Documentation received and reviewed needs to have its file name, date of issue and a description of its purpose in the PCI assessment process documented.  The basic PCI DSS has a minimum of around 200 discrete documents that are required for the PCI assessment process.  The average we see for most of our engagements is over 600 documents which also include not only policies, standards and procedures, but configuration files, interview notes and observations such as screen shots, log files and file dumps.  You really have to question any QSAC that tells you they manually manage the process.  They either have an amazing and magically efficient project management process, they have very, very inexpensive staff (i.e., overseas labor) or they are short cutting the processes and producing a work product that does not comply with the PCI SSC QA program and have yet to be assessed by the PCI SSC (the most likely scenario).

Even using simple SharePoint or Lotus Notes solutions are not cheap when you consider the cost of the server(s) and the storage of all of documentation collected, which can be around 5 to 10GB per project, as well as all of the requisite system maintenance.  Servers and storage may be cheap, but it all adds up, the more clients you assess.  And speaking of the storage of documentation, the PCI SSC requires that documentation related to PCI assessments be stored for at least three years.  For those of us with electronic work paper management systems, this is not a problem.  However, given the amount of paper generated by these projects, those QSACs using the traditional paper filing methods will find a lot of shelf space taken up by their PCI engagements if they are truly following the procedures required by the PCI SSC.

All of this drives up the cost of a proper PCI assessment, more than I think the card brands and the PCI SSC are willing to admit.  It is not that I think the card brands and PCI SSC do not care about this situation, but more related to they do not have an understanding of the operational ramifications of their edicts.  The card brands and PCI SSC tread a very fine line here and to this point they have been heavy handed in the issuing of their edicts.  Going forward, the PCI SSC needs to ask the QSACs, Participating Organizations and ASVs to assess the cost and time impacts of these edicts so that they can be weighed against their benefits versus what is done now which is more of a procedural and proofing review.  If this is not done, there will soon come a point where merchants and service providers will push back hard and refuse to go through the process due to the cost and the amount of time involved to be assessed.

The next death knell is the inane process that is called the PCI Report On Compliance (ROC).  When the PCI SSC did not have access to the QSACs’ work papers, the current ROC writing process made some sense as there was no other way for the PCI SSC or the processors and acquiring banks to know if the QSACs had really done the work they were saying they had done.  However, all of that changed a number of years ago when the PCI SSC required QSACs to add a disclaimer to their contracts stating that the PCI SSC had the right to review all work products.  Yet even with this change, we continue to have to write an insanely detailed ROC, typically numbering in a minimum of 300+ pages for even the most basic of ROCs.

Unfortunately, there are QSACs out there that apparently have not been through the PCI SSC QA process and that dreaded of all states – Remediation.  As a result, they have much lower costs because they are not documenting their assessment work as completely as they need to and are not sampling, observing or interviewing like QSACs that have been through the QA process.  In addition, based on some work products we have seen, they also do not care about the quality of the resulting ROC as it looks entirely like a ‘find and replace’ of a template and makes no sense when you read it.  In talking to other large QSACs that have been through the QA process multiple times, the PCI SSC has indicated that they are monitoring the large QSACs more than the little QSACs because there is more risk with the large QSACs.  While true to an extent, we have encountered a number of smaller QSACs that perform assessments for large clients due to their much lower cost structure and their willingness to ‘overlook’ compliance issues.  If the PCI SSC does not go after these QSACs soon, there will likely be a number of breaches that occur due to the QSACs’ lack of diligence in performing their assessments.

I know of a number of QSACs that would like to see Bob Russo and the representatives of the various card brands to actually work as staff on a few PCI assessment engagements so that they can better appreciate the inordinate amount of work involved in generating a ROC.  I think they would be shocked at the amount of work effort they have driven into a process that is already too complicated and prone for error.

As it stands today, the ROC writing, review and proofing process is probably 50% to 60% of a good QSAC’s project costs.  To address this, the PCI SSC QA group tells QSACs to develop one or more templates for writing the ROC which, from what we have seen from some other QSACs, means a lot of mass ‘find and replace’ to speed the ROC writing process.  For the last few years, a number of QSACs have brought the ROC writing process up at the Community Meetings.  However the card brands continue to shoot down any sort of changes to the process.  As a result, the cost of producing a ROC is driven by the size and complexity of the merchants’ or service providers’ cardholder data environment (CDE).  These costs will only continue to rise as long as the PCI SSC does not allow QSACs to mark items as ‘In Place’ with only a check box and rely on the QSAC’s work papers versus the verbosity required now.  If this sort of process can work for financial auditors, it can work here as well.

A third death knell is the PCI SSC and card brands continuing to quote that the majority of breaches are the result of organizations not complying with the PCI DSS.  In discussions with a number of the PCI forensic examination companies, I am hearing that the card brands cannot believe the fact that more and more organizations were PCI compliant at the time of their breach.  The PCI SSC and card brands have apparently convinced themselves that the PCI standards are “perfect” and they cannot imagine that an organization could be breached unless that organization was not complying with the PCI standards.  There is no security standard that I am aware that totally prevent breaches.  So while the PCI standards are good baseline security standards, the card brands and PCI SSC seem to have forgotten that security is not perfect and that any security standard only minimizes the damage done when a breach occurs if the standard is truly followed.

And as organizations have gotten the PCI “religion,” the effort required to compromise them from the outside via traditional attacks has increased significantly.  As a result, successful attackers have changed strategy and work on social engineering their way past the bulk of an organization’s security measures.  The PCI DSS only has a little bit on social engineering in requirement 12.6 regarding security awareness training.  And even those organizations with the most robust of security awareness programs will tell you that, even after extensive security awareness training, human beings are still fallible and that some people still do very questionable things that continue to put organizations at risk, sometimes significant risk.  Even when you have the most diligent of employees, they still make mistakes in judgment from time to time.

Until the human element can be totally removed, there will always be a certain amount of risk that will never go away.  Again, the PCI SSC and card brands seem to not want to acknowledge the failings of the human element and appear to believe that technology is the savior based on the focus of the PCI standards.  However time and again, every security professional has seen very sophisticated security technologies circumvented by human error or just plain apathy towards security (i.e., “it always happens to someone else, not my organization” or “we’re too small to be a target”).

Until the PCI SSC and the card brands drop the “holier than thou” attitude toward the PCI standards and stop the public pillory of organizations that have been breached, there will continue to be editorial commentary regarding the pointlessness of the standards and ever more serious push back to complying with the standards.

These are the reasons why the PCI SSC and the card brands will be the ones that will kill the PCI standards.  At the moment, they are so far removed from the process; they do not understand how complicated and expensive the process has become which is why merchants and service providers are complaining about the ever increasing costs and effort related to the PCI assessment process.

The PCI SSC and card brands also seem to have forgotten that QSACs have to make money doing these assessments and, when you pile on clarifications and edicts that do nothing to streamline and simplify the process; you are only driving the costs of the process higher.  And higher costs only make merchants and service providers, who are on thin margins to being with, even more incentivized to use the much lower cost QSACs, driving the diligent QSACs out of the market, thus increasing the likelihood of breaches.

Again, it is not that I want the PCI standards to go away as I think they have brought a real benefit.  However, if these issues are not addressed, the PCI standards will end up going away.  I fear that, with them gone, there will be no carrot to ensure the security of cardholder information and we will end up back where we were before the PCI standards existed.

Another Year, Another QSA Re-Certification

It is that time of the year when I have to go through the PCI SSC’s Qualified Security Assessor (QSA) re-certification process.

To add to the re-certification process this year, I have been sick for the last two months with a cold that turned into a nasty case of bronchitis along with laryngitis that then caused a severe case of sinusitis.  I just could not catch a break this Spring.  The good news is that I am finally on the mend and should be back to normal in another couple of weeks.

However, even illness does not get you out of the QSA re-certification process.  So, I put it off as long as I could and took the examination this morning.

As I expected, there was not a lot of new material in this year’s QSA update.  The biggest focus of this year’s training seemed to be:

• The interrelationship of the various PCI standards;
• Roles and responsibilities of QSAs, ASVs, merchants, service providers, acquirers, PCI SSC and the card brands;
• Scoping of the cardholder data environment and cardholder data discovery; and
• The integration of the PA-DSS with the PCI DSS.

Other than that, it was for the most part a reinforcement of the changes in the PCI DSS v2.0 to make sure that QSAs really understand the standard.

There is an interesting section on what not to write in the In Place column.  The unfortunate aspect about this section of the training was that the examples that were presented were straight out of ROCs that the PCI SSC QA program had reviewed.  Some of those responses were very difficult to read they were so bad.

There is also a discussion on network segmentation.  Unfortunately, the examples were very simple.  I wish our clients had such simplified networks.  However, because this discussion is in this year’s presentation materials indicates there are apparently still a lot of QSAs that do not understand the concept of network segmentation and what constitutes good segmentation from poor segmentation.

As I am finishing this post, I have been told I passed the QSA re-certification examination.  So I am a QSA for another year.

PCI DSS Compliance Certificates

In this month’s PCI SSC QSA Newsletter, the FAQ of the Month is about so called ‘PCI DSS Compliance Certificates’.  I started to hear about these a couple of years ago, but it got really big last year when I started running into processors and acquiring banks demanding them.  I had a particularly troubling conversation with a processor who demanded that we produce one for one of our clients.  When offered the PCI DSS Attestation Of Compliance (AOC), this processor acted as though we were trying to put something over on them.  When I asked him where I was supposed to get such a certificate when it does not exist on the PCI SSC Web site, he accused me of not being a QSA because all QSAs know what the certificate looks like and where to get it.

As a result, a lot of QSAs must have submitted a question regarding these certificates like I did.  Here is the PCI SSC’s response.

“In addition to the official PCI SSC reporting forms and templates, some QSA or ASV companies provide certificates, letters or other documentation as confirmation that an organization is PCI DSS compliant. The PCI SSC does not prevent QSAs or ASVs from producing this type of documentation, as it is considered an additional service which the assessor company may elect to provide and is therefore outside of the purview of the Council.  However, in accordance with the ethical requirements for QSA and ASV companies, any such certificates, letters and other documentation must be accurate and not be in any way misleading.  Additionally, these certificates, letters and other documentation should be clearly identified as supplemental materials provided by the QSA or ASV; they should not be presented as documents endorsed by the PCI SSC, nor should they be considered replacements for the official PCI SSC templates and forms which have been approved by the payment brands.

The PCI SSC website contains reporting templates and forms which have been approved by all payment brands, including ROC templates, Attestations of Compliance, Self-Assessment Questionnaires, and Attestations of Scan Compliance for ASV scans. Compliance validation and reporting requirements are determined by the individual payment card brands and, irrespective of whether an organization is performing a self-assessment or has an onsite review completed by a QSA company, acceptance of a validation method outside of those listed on the Council website is ultimately up to the entity accepting the validation (that is, the acquiring bank or payment card brand). In many cases, certificates, letters or other documentation issued by QSA or ASV companies outside of the official PCI SSC templates may not be accepted by acquiring banks or payment card brands. ASVs and QSAs should encourage their clients to check with their acquirer or the payment brands directly to determine their compliance reporting requirements, including whether the submission of such certificates is acceptable.”

So all of you processors and acquiring banks that seem to think the only acceptable proof of PCI compliance is some mystical PCI DSS Compliance Certificate, stop demanding them.  They do not exist and never have existed.  The document you need for proof of PCI compliance is the Attestation Of Compliance (AOC), period.  All self-assessment questionnaires (SAQ) contain the AOC and there is a separate AOC form for those submitting a Report On Compliance (ROC).

And all of you QSAs and ASVs out there differentiating yourselves because you produce these nice, but essentially worthless, certificates, stop misinforming merchants, processors and acquiring banks by implying that QSAs and ASVs not producing such a certificate are somehow doing something wrong or worse, dishonest.

Now that the PCI SSC has clarified this situation, hopefully, this marketing ploy will stop.

Are You A Level 2 Merchant?

It is that time of the year again.  I have had calls from a number of Level 2 merchants in a panic about the upcoming MasterCard deadline.  I also have a number of perspective clients that are saying, “Deadline?  What deadline?”

To refresh everyone’s memory, three and a half years ago, MasterCard issued a directive that by June 30, 2010, all Level 2 merchants needed to either: (1) have a PCI SSC certified Internal Security Assessor (ISA) prepare their Self-Assessment Questionnaire (SAQ) or, (2) have a PCI SSC certified Qualified Security Assessor (QSA) conduct a PCI assessment and issue a Report On Compliance (ROC).

Because of the uproar this directive caused with their Level 2 merchants, MasterCard backed off on the 2010 date but set forth a new date of June 30, 2012.  Now jump to the present, it is January 2012 and the calls from Level 2 merchants are starting to ramp up.  These merchants are now in a panic because, guess what?  Level 2 merchants put the ISA/ROC issue on the back burner and forgot about it until just now and they cannot afford to meet this requirement.  Oops!

I have sent a message to MasterCard to confirm that the June 30, 2012 date is still valid.  Until I have confirmation, if you look at MasterCard’s Web site, the June 30, 2012 date is still posted as the date you will need to meet the aforementioned requirements.

For all of you Level 2 merchants that accept MasterCard, I would highly recommend that you contact your acquiring bank and confirm the SAQ and ROC reporting requirements.

UPDATE: MasterCard confirmed on Thursday, January 26, 2012, that the June 30, 2012 date is going to be enforced.

When A Breach Is Not A Breach

An interesting but troubling article appeared this past week.  A merchant is suing their processor and acquiring bank over a fine they were assessed for an alleged credit card breach.  What makes this situation troubling is that the merchant had a forensic examination of their systems conducted and the results of that investigation were that there was no breach.  Yet Visa and MasterCard said the merchant was the source of the breach because their analyses of transactions lead them to the merchant and that was enough to invoke fines and penalties.

What should rile merchants is a quote that comes from David Navetta, founding partner of the Information Law Group, who states,

“Most QIRAs (qualified incident response assessors) do not necessarily do a deep-dive forensic assessment.  Rather, they do something more tailored to the task of confirming PCI compliance and validating the existence of a card breach.  Unfortunately for merchants, we have found that some of the assumptions made by QIRAs in this context are often not favorable to the merchant.”

To be fair, there are two issues here.  One is a breach of data and the other is compliance with the PCI standards.  In regards to compliance with the PCI standards, if you were breached, what is the likelihood you were PCI compliant at the time of the breach?  It does not take a rocket scientist to figure that out, let alone some QSA or PFI (PCI Forensic Investigator) coming in after the fact.  In fact, even without any analysis, I would say that your compliance with all of the relevant PCI standards at the time of the breach was probably somewhere between slim and none.

However, this lawsuit points out an even more disconcerting issue with a cardholder data breach.  What Mr. Navetta is pointing out is that any incident investigation initiated by the card brands under the PCI standards is going to focus on PCI compliance and not on whether or not the breach actually occurred.  What a piece of comforting news that should be to merchants.  The card brands know that you were not in compliance with the PCI standards, yet they go through the motions of an “investigation” just for appearances.

But the most troubling thing of all, and the point that should scare all merchants, is the indication that Visa and MasterCard did not even conduct an investigation into the breach and how it occurred.  The article implies that Visa and MasterCard implicated the merchant based on an analysis of the fraudulent transactions.  That transactional analysis led the card brands back to a common point, the merchant that filed suit.  And as the following examples show, the card brands’ all knowing analyses are not always the entire story.

I can tell you from experience with some of our clients that this happens all of the time.  A number of our clients have been involved in these card brand driven “witch hunts.”  The card brands point the finger at a number of merchants because of the fact that the merchants all came into contact with the cards involved.  Unless you have the wherewithal to prove you are not the reason for the fraud, you are the reason the breach occurred.

As an example, back in the ancient times when the Visa CISP ruled the land, we were involved in the forensic examination of a client that is a franchisee of a restaurant chain.  Visa informed them that one of their restaurants was the source of a cardholder data breach.  Their “evidence” was a report that showed their restaurant had come into contact with the cards involved in fraud.  Their attorney asked Visa to explain how this analysis was proof that no other merchant could have been the cause of the breach?  The attorney also asked if any other merchants had also come into contact with the cards in question.  Visa told their attorney that it was proprietary information and that they could not share that information.

Since our client was getting nowhere with Visa, they asked us to conduct a forensic examination of the computers involved to see if a breach had occurred.  While we found a number of improvements in security that should be made, we were not able to find any evidence of the card numbers in question on any of his systems that could have come into contact with the cardholder data.  When presented with this information, Visa replied to our client and their legal counsel that it did not matter as their restaurant was the source of the breach.  In the end, our client paid Visa the equivalent of a third of a year’s profit as their fine to resolve the situation.

As Paul Harvey liked to say, “And now, the rest of the story.”  It turned out our client actually was involved in the data breach, albeit indirectly.  Skip ahead a half a year at the same restaurant.  One day the police walk in and arrest an employee for skimming credit cards.  As the police continued investigating, it turned out there were two more employees that were also skimming cards.  Did Visa apologize or return the “fine” they collected.  Heavens no, our client was still guilty as far as Visa was concerned.

In another case only a couple of years ago, the same situation occurred.  This time our client was a very large Midwestern retailer with a store in the same town where the fraud was occurring.  When approached with the fraud analysis report, the retailer’s legal team ambushed Visa’s representatives and got them to admit that there were four other potential outlets that could also be the source of the breach.  However, in retaliation, Visa implicated our client in the breach through various local media outlets.  The retailer involved us in some due diligence regarding their PCI compliance and other potential issues surrounding the possibility they were the source of the breach.  In the end it turned out that a convenience store in town was the actual source of the breach.  The overnight convenience store clerk had allowed a friend to doctor the ATM in the store to skim cards.  While Visa dropped their “investigation” with our client, they never once apologized for accusing our client of being the source of the breach or the inconvenience they caused with their “investigation.”

The lesson to be learned here is that the card brands are very heavy handed when dealing with a breach.  While I understand their motives for this approach, I also feel it is also very one sided in the favor of the card brands.  I know they are trying to protect their brand names.  But in the end, such heavy handedness will only alienate merchants and, in the end, customers who use their cards to pay for goods and services.

It will be interesting to see how this lawsuit plays out.

UPDATE: Since posting this entry, I have had an opportunity to talk to a number of PFIs about this topic.  While they would not comment on specific investigations, they have all stated that how investigations are conducted has changed significantly.  While the card brands may still only be interested in PCI compliance, the investigations now typically cover everything regarding the breach: how it occurred, who was behind the breach and other relevant investigative topics.  They also told me that they are finding themselves more and more in an adversarial position with the card brands over breaches that were not the fault of the merchant or the result of a merchant’s PCI non-compliance.

The (EMV/Contactless) World According To Visa

Based on discussions this week with a variety of large merchants at the PCI Community Meeting in Phoenix, there is a lot of confusion as to what Visa is trying to accomplish with their new Technology Innovation Program (TIP) to promote adoption of EMV and contactless cards.  I wrote about this program earlier and after the Community Meeting, it seems that my opinion of this program is shared by most merchants and QSAs.

The big clarification from discussions with Visa was related to the first criteria which is:

“At least 75% of the merchant’s transactions must originate from dual interface EMV chip-enabled terminals“

The big question merchants had was if it was strictly just terminals, or did it also require EMV or contactless cards?  Visa clarified this on Thursday morning stating that it was just to install and use EMV or contactless terminals.  However, in clarifying these criteria, they created a new question.  Visa claims that they will know through analysis of transactions if a merchant truly meets the 75% rule.  While Visa could now what types of cards are used and how they are used through transaction logs, we were all stumped as to how Visa would know the type of terminal used to conduct the transaction since EMV cards are not yet available in the United States and contactless cards do not always appear as contactless if they are swiped.

The next big clarification came from the PCI SSC regarding the implication of this program and PCI compliance.  The PCI SSC stated that while Visa is not requiring merchants to file a ROC or AOC, the merchant still has to ensure that it is PCI DSS compliant.  This means that the merchant still must go through the PCI compliance assessment process of a ROC or respective SAQ to ensure that their controls are functioning properly.

Visa representatives were pushing this aspect of the program very heavily at the Community Meeting and their wording regarding this aspect of the program was very carefully crafted.  On first blush, what they seemed to say was that a merchant meeting the program criteria did not have to meet the requirements of the PCI DSS.  However, when you went back and reviewed their statements and comments, Visa really was not contradicting the PCI SSC’s comment.  My concern is that some merchants will not do that re-review and will think that they are off the hook for complying with the PCI DSS.

In talking to the other card brands at the meeting, they are not buying this aspect of the program.  Since around 99% of merchants that accept Visa also accept MasterCard, going through an assessment and filing an AOC is still going to be required by them.  So, unless Visa can get the other card brands on board, this benefit will not create an advantage for any large merchants.

It is not that the other card brands do not want EMV.  It is that they are not agreeing with how Visa is trying to approach the problem of getting EMV adoption started in the United States.  The fear expressed by one of the other card brand representatives was that such a program opened the door to going back to pre-ROC times and not knowing if merchants really were securing cardholder data or not.  All of the other card brands stated that they were assessing the Visa initiative, but for the time being, were sticking with their existing compliance requirements.  I have to admit, after having the interaction with Visa on Thursday morning, I too am concerned that this is what Visa is inadvertently promoting by their new TIP program.

The point that really got the table roaring was when one of the merchants used the term “Chip and PIN” when the Visa representative used the term EMV.

In response to the use of “Chip and PIN,” the Visa person said very loudly and matter of fact, “There is no PIN involved, only the chip.”

At which point, one of the QSAs at the table said to the Visa representative, “So, what’s the point of having EMV without the PIN?”

There was no Visa response which drew laughter all around the table.

And that is the point.  There is no driver for any large merchant to adopt new terminals just because Visa will allow them to not have to file an AOC and ROC.  And the way the Visa announcement was worded gave most merchants the impression that the program would get merchants out of the PCI compliance process, which was patently not true.  And when the PCI SSC made that clear, most merchants I spoke with did not understand the point of Visa’s program.

One of the processors I ran into at the Community Meeting brought up a very interesting perspective on this whole topic.

He stated, “With eWallets just around the corner, what is the point of trying to drive EMV?”

He went on to explain, that with eWallets, bar codes can be generated that can be scanned thus avoiding the need for new terminals.  As a result, he said a lot of merchants are just biding their time, waiting until the whole mobile payment, eWallet technology is fleshed out.

The bottom line is Visa is attempting to use its 800 pound gorilla status to drive EMV and contactless into the United States.  The problem is that large merchants are not buying it and that appears to be frustrating to Visa since they have a vested interest in EMV and contactless technologies.

As I stated in my earlier post, if Visa were to work with a consortium of e-Commerce merchants, payment processors and other relevant entities to produce a common API for using EMV and contactless cards with PIN online, that would likely drive the adoption of more secure cards in the United States because there would be a business reason for adoption.  Without such a driver, EMV and contactless are still a solution looking for a problem.

It Is Time To Address PCI Compliance Reporting

It is QSA quality assurance assessment season at work.  I found out through our QSAC key contact person that we are being assessed again by the PCI SSC to see if our Reports On Compliance (ROCs) are written correctly.  This is a rather timely topic given the recent news that the PCI SSC revoked the QSAC and PA-QSAC status of an organization.

If the PCI compliance program has a flaw, this is the spot.  In the immortal words of Billy Crystal from his Saturday Night Live skit ‘Fernando’s Hide Away’, “It is better to look good, than to feel good.”  And that is exactly what the Scorecard, now known as the Reporting Instructions basically promote.  I have written about this topic before, but it is time to remind people of how ridiculous this process is to PCI compliance.

To any QSAs that have been through the QA process, it all comes down to having used the correct language in responding to the requirements of the ROC, rather than whether or not you actually assessed the right things.  And to add insult to injury, the PCI SSC advises QSACs to develop a template for the ROC with all the correct language written and proofed to ensure that ROCs are written to the standard the PCI SSC requires.  Technically, this allows a QSA to just fill in the blanks so that the ROC can be correctly filled out.

Ironically, on August 3, 2011, this may be exactly what happened to Chief Security Officers (CSO) and why they were stripped of their QSAC and PA-QSAC statuses.  CSO may have had the greatest templates for Reports On Compliance (ROC) and Reports On Validation (ROV), but without the supporting documentation, they could have been just filling in the blanks with the right type of information without actually ensuring that the information supported the conclusions of the report.  While the FAQ issued by the PCI SSC does not explicitly state the reason for CSO’s QSAC and PA-QSAC status revocation, it does imply that this was likely the case when it says, “CSO’s status as a QSA and PA-QSA was revoked only after careful review of reports and evidence submitted as part of the quality assurance program …”

It is not like the PCI SSC cannot determine this fact; it is just that they likely do not have the resources to go through a proper assessment of a QSAC or PA-QSAC.  We have been repeatedly told over the years that the whole reason that all of that verbiage is required in the ROCs and ROVs was that the PCI SSC and the acquiring banks only had that language to give them an idea of what was performed, how it was performed and what the results were.  However, the PCI SSC has had the right to review work papers as well as the ROCs and ROVs for over two years now.  And what, exactly, the acquiring banks gleaned from the verbiage in the ROCs are debatable as I rarely ever hear back from any institutions regarding questions.  As a result, in my humble opinion, there is no good reason for all of the verbiage in the ROCs/ROVs.  As long as the PCI SSC has access to any project’s work papers as evidence, there is no reason to document all of the fieldwork in the ROC or ROV.  And to take things to their logical conclusion, unless there are compliance issues for a particular requirement, is there really a need for acquiring banks to get anything more than the AOC?

In the past when I have brought this up, it has been rebuffed by the PCI SSC, card brands and processors because they point out that the ROC and ROV are the only pieces of documentation that proves the QSA or PA-QSA did their job.  Really?  Telling your assessors to have a template and fill in the blanks is better?  Seriously?  This all comes down to an ability to trust the assessors are doing their job.  And if you cannot trust your assessors, then what is the point?  Coupling the QA program with an independent assessment of a QSAC’s/PA-QSAC’s work papers should be more than adequate to determine if the evidence exists and the appropriate work is being performed.

Reviewing work papers is a tough process.  In the public accounting world, we have internal and external reviews of our work.  Internal reviews are typically referred to as inter-office inspections as senior personnel from one office examine another office’s work papers for a sample of engagements to confirm that the work papers support our conclusions and opinions.  External reviews are conducted in a similar fashion, but by another accounting firm.  Inter-office reviews can occur as often as necessary.  External reviews typically occur every three to five years.  While all of this can appear a bit self serving, I can tell you from going through numerous inter-office and external inspections that they are anything but easy and typically bring out a number of areas that require improvement or changes in procedures.  I would highly recommend to the PCI SSC that they consider the self assessment and independent assessment approach for QSACs and PA-QSACs to supplement the existing PCI SSC QA process.

There would be all sorts of winners if we brought sanity to the ROC and ROV.  The first would be the organizations being assessed as they would likely see lower costs for their assessments.  I believe this because in my limited analysis of engagement costs, 30% to 50% of the cost of an assessment seems to be attributable to writing the report to meet the requirements documented in the Reporting Instructions.  QSAs would be able to create ROCs and ROVs much faster as the only times that would require detailed documentation would be any items that are Not In Place.  QSAs would win because they would not have to put forth an inordinate amount of effort generating 200+ page tomes.  Acquiring banks and processors would win because they would not have to read through those 200+ pages to figure out if there are issues and where they exist.

I intend to bring this topic up again at the PCI Community Meeting in September.  Hopefully we can fix this problem and bring some rationality to the PCI compliance reporting process.

Kicked Out Of “The Club”

It has finally happened.  A Qualified Security Assessor Company (QSAC) has finally had their status revoked by the PCI SSC.  In a little noticed release dated August 4, 2011, the PCI SSC announced through an FAQ that as of August 3, 2011, Chief Security Officers (CSO) of Scottsdale, Arizona is no longer a QSAC.  To add insult to injury, CSO was also a Payment Application Qualified Security Assessor Company (PA-QSAC) as well and that status has also been revoked.  In reviewing CSO’s Web site, all references to merchant and application assessments have been removed which was likely required by the PCI SSC with the revocations.  These revocations are pending any appeal by CSO and only they know if an appeal will be mounted.

The PCI SSC did not explicitly share the reasons why CSO’s statuses were revoked.  But based on what little information is in the FAQ, it seems to imply that CSO was not able to provide documentation that supported their conclusions regarding the assessment opinions in their Reports On Compliance (ROC) and Reports On Validation (ROV) they had issued.  While there is no public way to determine the number of ROCs that CSO has issued, in reviewing the PA-DSS certified applications list from the PCI SSC Web site, CSO had issued around 56 ROVs for payment applications.

What is interesting about this whole situation is that the PCI SSC issued the announcement as an FAQ versus the usual press release.  From the FAQ, we now know something about the revocation process.

• First and foremost, it seems that the PCI SSC is finally showing its teeth regarding their quality assurance assessment process.  The FAQ states, “CSO’s status as a QSA and PA-QSA was revoked only after careful review of reports and evidence submitted as part of the quality assurance program …”.  The implication here is that CSO was unable to provide sufficient evidence that supported the conclusions of their assessments.  The reason this is important is it seems to indicate that the PCI SSC is now including a review of work papers to determine if QSACs are collecting evidence that supports their conclusions in the Report On Compliance (ROC).

• The FAQ states, “It accompanies CSO’s inability to demonstrate sufficient improvement through a prior remediation process.”  CSO had already been through the QA process once and had to go through remediation as a result of the prior QA review.  CSO must have gone through the remediation process within the last two years as it was two years ago when the QA process started.  Even after going through remediation, CSO was apparently not able to get through the QA assessment without being placed in remediation again.  What is unclear is whether a QSAC is not allowed to go through remediation twice in a row or if the CSO situation was the outgrowth of larger QA issues that could not be corrected.
• The FAQ states that ROCs and ROVs issued by CSO and accepted by the card brands and the PCI SSC are still valid, but that any work in process will need to be conducted by a different QSAC or PA-QSAC.  What I find interesting here is that while the PCI SSC QA process found that CSO was not doing their job as a QSAC or PA-QSAC, merchants and others are to accept their previously issued work and results.  That seems a bit too flexible in my opinion.  If CSO’s status as a QSAC and PA-QSAC has been revoked, particularly for being unable to support their conclusions, then why should any organization accept their conclusions on any previous assessments?  I am particularly concerned about any payment applications certified as PA-DSS compliant.
• One thing implied by the FAQ but not explicitly stated is that all of CSO’s employees that had a QSA designation are no longer QSAs.  As a result, based on my understanding of the QSA rules, they cannot go to another QSAC to retain their QSA status.
• Finally, CSO has an opportunity to appeal the PCI SSC’s revocation of the QSAC and PA-QSAC status.  However, as of this writing, I have not seen anything in the press that would indicate that an appeal has been requested.

It will be interesting to see if CSO appeals this decision or just accepts the Council’s ruling.

Merchant Levels

I get requests all of the time regarding how to determine an organization’s merchant level.  Even though the card brand Web sites have this information posted, the questions still persist.  But even with those tables and references such as this post, it is very important for all merchants to remember that the only entities that can definitively set a merchant’s level are the merchant’s processor(s), acquiring bank(s) or the card brands.

So, while what I am going to discuss in this post should provide the information necessary for most merchants to determine their merchant level, you cannot use this post as the definitive answer on this subject.  This is only my opinion.  Again, if you want a definitive answer, you need to get that from your processor(s), acquiring bank(s) or card brand(s).  Also, before I forget, I have not included a discussion regarding vulnerability scanning, penetration testing and other requirements, so you will need to reference the card brand tables for those other requirements.

One would think that this issue is simple to resolve.  After all, the card brands have this information posted on their Web sites.  So, you just go to their Web sites and figure it out.  Oh, if it were only that simple.

Card Brand Merchant Level Tables

The first problem most merchants run into is that Visa, MasterCard, Discover, American Express and JCB all have tables for merchant levels.  Which leads to the first question merchants typically have; “Whose table should I use?”

The answer is you use the tables for only those card brands for which you have a merchant agreement.  This sounds easy enough, but as we will see later on, might not be as simple as you might think.

Things can get even easier for some merchants.  While Visa, MasterCard and Discover have their own table of merchant levels, if you compare them, you will note that Visa, MasterCard and Discover have gotten together and decided to use the same criteria for determining merchant levels.  So, if the only credit cards you accept as a merchant are Visa, MasterCard and/or Discover, you only need to reference the Visa tables as their merchant level criteria are all the same.  But for those merchants that accept American Express and/or JCB in addition to the other card brands, do not fret.  The card brands have made things easy for you as well.  If you are a given merchant level for any other card brand, you are that merchant level for every card brand.  However, as we discuss the merchant level criteria, for merchants accepting American Express or JCB credit cards, smaller processing volumes of those cards can easily make you a Level 1 or 2 merchant.

With the exception of Merchant Level 3, transaction volumes are the total number of credit card transactions processed, regardless of whether those transactions are card present, card not present, e-Commerce, whatever.  Level 3 merchants introduces the concept of e-commerce only transactions, but we will discuss this a bit later.

The Big, Bad, Ugly Level 1 Merchant

Level 1 merchants are the easiest to define and the ones that must go through the full Security Assessment Procedures and produce a Report On Compliance (ROC).  If you are a merchant that meets any of the following annual transaction processing volumes, you are a Level 1 merchant to all of the card brands:

• Over six million Visa, MasterCard or Discover transactions
• Two and a half million or more American Express transactions
• Over one million JCB transactions

The first thing merchants that have big transaction volumes with American Express or JCB is that they can easily end up a Level 1 merchant with very few Visa, MasterCard or Discover transactions.

I Am A Level 2 Merchant, I Can Do A Self-Assessment Questionnaire

On the face of things, Level 2 merchants are also easy to define.  If your organization meets any of the following annual transaction processing volumes, you are a Level 2 merchant to all of the card brands.

• One to six million Visa, MasterCard or Discover transactions
• 50,000 to two and a half million American Express transactions
• Less than one million JCB transactions

Where things get complicated for merchants is in regards to the credit cards they have agreed to accept, particularly JCB cards.  It turns out that if you have agreed to accept Discover or Diners Club cards, you may also have inadvertently agreed to accept JCB cards.  In the United States and some of Europe, Discover processes Diners Club and JCB transactions and your merchant agreement with Discover may have included JCB.  Overseas, JCB processes for Discover and Diners Club in some countries.  As a result, you will need to review your merchant agreement with your processor to make sure that JCB cards are not included in your agreement.  If your merchant agreement does cover JCB cards, even if you have never processed a JCB transaction (mathematically zero is less than one million), technically you could be classified as a Level 2 merchant by your processor or acquiring bank.

For merchants that accept MasterCard, and that would be most merchants, things get further complicated regarding what you need to do for reporting.  A few years ago, MasterCard tried to get Level 2 merchants to do a ROC for compliance instead of an SAQ.  Thankfully after a lot of complaints, that requirement died a quick death.  However, as of June 30, 2012, MasterCard is requiring their Level 2 merchants to:

• Use an internal person certified as an Internal Security Assessor (ISA) by the PCI SSC to create their Self Assessment Questionnaire (SAQ); or
• Use a Qualified Security Assessor (QSA) conduct the PCI Security Assessment Procedures (SAP) and file a ROC.

So those of you Level 2 merchants that were looking forward to only doing an SAQ, you might want to clear that with your processor first.

And remember, if you are classified as a Level 2 merchant by one card brand, you are that level for all other card brands.  So, if you get caught in the JCB conundrum I described above, you will be a Level 2 merchant to MasterCard and you may have to do a ROC.

What Is A Level 3 Merchant Exactly?

At Level 3, things get a bit more complicated, mostly because at this point some of the card brands do not even have a Level 3 classification.  However, as I stated with Level 2, if you have JCB cards being processed, you will end up as a Level 2 merchant regardless,

Where Level 3 really confuses people seems to be the fact that the criteria now focuses on one particular type of sales delivery method, e-commerce.  If your organization meets any of the following criteria, you are a Level 3 merchant.

• 20,000 to one million Visa e-commerce transactions annually
• 20,000 combined MasterCard and Maestro e-commerce transactions annually but less than or equal to one million total combined MasterCard and Maestro e-commerce transactions annually
• 20,000 to one million Discover card-not-present only transactions annually
• Less than 50,000 American Express transactions

An additional trick with the Level 3 merchant classification is related to the e-commerce sales channel.  According to Visa, MasterCard and Discover, if your organization has 20,000 to one million e-commerce transactions, you can also have less than one million transactions through other sales channels such as physical stores, mail orders and telephone orders and still be a Level 3 merchant even though your total number of transactions technically exceeds one million transactions and is less than two million in total.

As with Level 2, if you are a Level 3 merchant for one card brand, you are a Level 3 merchant for all card brands.

Level 4, I Can Do Nothing

Level 4 merchants process less than 20,000 Visa e-commerce transactions annually and/or process up to 1 million transactions annually.  As with the other merchant levels, if you are classified as a Level 4 merchant, you are a level 4 merchant for all card brands.

As a Level 4 merchant, you are only recommended to attest to your organization’s PCI compliance.  This means that filing an SAQ with your processor or acquiring bank is not required by the card brands.  However, as I posted earlier, some processors are not only requiring that Level 4 merchants file an SAQ, they also require that a QSA sign off on your SAQ.  If you are a Level 4 merchant in Canada, Visa Canada is also requiring that a Level 4 merchant’s SAQ is signed off by a QSA. (As of October 2010, a QSA does not need to sign off on a Level 4 merchant’s SAQ.)

Clear as mud, right?  Well, there are some other issues that need to be considered before you can claim you are a particular merchant level.

Holding Companies And Legal Entities

What can bring the first twist into the merchant level setting process is how your organization is legally incorporated or structured.  If your organization is a holding company with multiple legal entities underneath it, then your multiple legal entities will have their own individual merchant level and require an individual PCI compliance report filing.  A good example of this is Yum! Brands and their A&W, Long John Silver’s, Pizza Hut, KFC and Taco Bell restaurants.  The restaurants are separate legal entities and therefore have their own merchant level and their own PCI ROC.

Sometimes you can negotiate with your processor or acquiring bank to get your multiple legal entities treated as a single entity and do one compliance filing, but they are not obligated to go along with this request.  The key is that you need to negotiate this change before you start your PCI compliance efforts, not after the fact.

Another fact that can complicate this holding company relationship is how the organization processes their transactions.  In some organizations, the individual entities all process their transactions separately under their own merchant numbers and even possibly with their own processor(s) and/or acquiring bank(s).  In other instances, the holding company aggregates transactions from all of the entities, but the transactions are still processed under individual merchant numbers and my be processed through different processors.  And in a third variation, the holding company aggregates the transactions and processes everything under one merchant number.  In the first two instances, typically each entity is going to be responsible for their individual PCI compliance and will report separately.  In the last instance, the holding company is usually held responsible for each entity’s PCI compliance.  However, any determination of what is correct is going to be up to the acquiring bank(s).

And one other thing that comes up regarding holding companies.  There are organizations that attempt to use their legal incorporation as a way to manipulate the level setting process.  They also have each legal entity process transactions through different processors so that their transactions volumes are not known between the processors.  While in the past this was a good strategy to keep your organization creating SAQs, processors have gotten wise to this game and are talking to one another as well as documenting the processors used in the reports.  So for those of you playing this game, it is only a matter of time before you will be found out and possibly have your merchant level changed.

Been Breached?

Take a close look at your merchant agreement regarding PCI compliance.  There should be a statement that says if you suffer a breach, your organization will automatically be classified as a Level 1 merchant for PCI compliance purposes, regardless of transaction volume.  All of the card brands added this to their merchant agreements a number of years ago.

Unless you are already a level 1 merchant, just the thought of not being able to file a SAQ should put the fear of God in you.  Conducting a full ROC, even for a small organization, will likely be extremely daunting and expensive.  So there is added incentive for you level 2 through 4 merchants to make sure that they truly are PCI compliant.

So that is merchant levels.  I hope this gives you the guidance you seek.  It definitely should give you the background you need to discuss the topic intelligently with your processors and acquiring banks.

UPDATE: I ran into a person from Yum! Brands at the 2011 PCI Community Meeting and they informed me that they file one ROC for all of their restaurant brands, however, technically they could file separately for each, but they do not.  I was only using them as an example and apologize for misrepresenting their filing status.