A Reason Why The PCI Standards Get No Respect

Call it the “Rodney Dangerfield Effect.”  Conflicts of interest seem to pervade the PCI compliance process and it is something the PCI SSC and the card brands need to clear up before their precious standards get even more bloodied in the media.

I have run across another processor that dictates the use of a particular QSAC.  Now do not get me wrong, I am a capitalist and interested in making money just like the other guy.  But I have to say that I am not a shark like some of my competitors.  I know this post will sound like someone bemoaning sour grapes but, in my opinion, this situation just makes the whole PCI compliance process look like a worthless sham.

What prompts this post is a call with one of our clients that we have performed PCI assessments for years, even before the PCI SSC existed.  They are implementing a new point of sale (POS) terminal that requires them to use a different credit card transaction processor because their existing processor is not yet certified to process transactions from this new terminal.  Fair enough.

The new terminal is a test installation to see if the service should be expanded to all of our client’s locations.  Since the terminal will only generate a couple of thousand transactions in the coming year, the new processor has identified our client as a Level 4 merchant and is treating them accordingly.  In reviewing the processor’s contract, our client found that the contract dictates that they use a specific QSAC to “assist” them in filling out their PCI Self-Assessment Questionnaire (SAQ) A.  Knowing the SAQ A, our client cannot figure out what a QSAC would do to assist, but it is in the processor’s contract.

Our client’s first question was, “Since when does a processor have the right to force us to use a particular QSA?”  We explained that we have been told that while the PCI SSC and the card brands allow processors to have rules that go above and beyond the PCI SSC’s and card brand’s requirements.  While I understand that the processor is likely trying to ensure that their Level 4 merchants are not just checking the ‘Yes’ box on their SAQs, forcing the use of a particular QSAC seems a bit questionable.  Particularly when we have been told that some QSACs are giving processors payments for all of the customers they refer.

I have written about this issue before with processors charging fees to merchants for the filing of their SAQs.  There is also the scam of forcing merchants to use a specific PCI Approved Scanning Vendor (ASV) to scan the merchant’s networks even when the merchant does not have an ecommerce presence or outsources their ecommerce to a third party that already provides their ecommerce customers ASV reports.  This is just one more questionable requirement that processors demand that makes merchants and the media think PCI is a scam.

Their next question was, “Since you already do our ROC, can’t we just submit that to our new processor?”  You can do that, but you need the new processor’s approval as they do not have to accept our work.  What is the likelihood that the new processor will accept our client’s ROC?  No idea and I am anxious to hear what our client tells us in that regard.

The problem here is that the processor in question and the QSAC have numerous connections that give a distinct impression of conflicts of interest.  First, the QSAC in question runs the processor’s Level 4 merchant compliance program.  That program dictates that the QSAC perform some sort of assessment process in order for any of the processor’s Level 4 merchants to create and submit their SAQ.

The justification the processor gave our client was that the PCI SSC requires this action.  Last I checked, the PCI SSC and the card brands did not require a QSA to fill out an SAQ.  MasterCard has a deadline of June 30, 2012 for Level 2 merchants to have either an ISA fill out their SAQ or have a QSA conduct a PCI ROC.  Visa in Canada also requires that a QSA sign off on all SAQs.  But those are the only SAQ rules involving QSAs that I am aware.

Next, the QSAC and the processor have swapped various personnel over the years.  As a result, there is an appearance that the two are essentially one in the same given that the QSAC runs the processor’s compliance program and the processor dictates that their merchants use the QSAC for PCI assessments.  I know that people move between organizations in the same industry all the time, but the number of people that have gone between these two would seem to be higher than expected.

I guess since I am an employee of a public accounting firm in the United States, I have greater sensitivity to conflicts of interest than most.  The American Institute of Certified Public Accountants (AICPA) has very specific rules in regards to conflicts of interest.  We have an entire department dedicated to ensuring that we avoid conflicts of interest.  As a result, we regularly look at the services provided to our clients and ensure that we are not in conflict or even give an appearance of a conflict of interest.

Now I am not suggesting that the PCI SSC and card brands go to the levels that the AICPA requires.  But let us face it, it is the Wild West out there and some of the QSACs do not care what conflicts they may have and how it might hurt the PCI compliance processes.  The PCI SSC only requires its assessors document the services they provide to the organizations they assess in their assessment reports.  While that offers a certain amount of transparency, when you read some of these ROCs, it becomes painfully obvious that some QSACs are assessing their own security services.  In some cases, the organization being assessed has outsourced almost everything related to their PCI compliance to the QSAC doing their assessment.  What do you think the likelihood is that those services will be assessed as not compliant if there are compliance issues?  One would assume it will be very unlikely.

But it can get even worse.  A certain QSAC operates one of the card brand’s merchant PCI compliance program.  Merchants submit their Attestations of Compliance (AOC) and Reports On Compliance (ROC) to this card brand through the QSAC which manages the process.  Does this QSAC inform their clients that accept this card brand’s cards of this fact?  Not that I have ever been told by any prospects.  Does the QSAC list the management of the card brand’s merchant program on their ROCs?  Not that I have seen and I have seen a number of their ROCs for merchants that accept the card brand’s cards and I have never seen the program listed.  Does the QSAC submit their ROCs to the program that they manage?  They must as the ROCs I have seen are from merchants that accept the card brand’s cards.  Is this a conflict of interest?  One would think, but this is how things operate today.

The bottom line is that in this age of openness and transparency, it is these sorts of relationships and actions that give a very bad impression to the outside world.  The PCI SSC and the card brands need to enhance their rules for QSACs that define conflicts of interest.  Until this is done, the PCI standards will continue to be ridiculed and viewed as pointless.

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.

The Global Payments Breach

We are very early on in this breach from a publicity sense as this is breaking news.  A big thank you to Brian Krebs for bringing this breach out into the sunlight.  However, there are a couple of things that are known that are troubling.

The first troubling statement is Visa and MasterCard stating that,

“the breached credit card processor was compromised between Jan. 21, 2012 and Feb. 25, 2012.”

There are two ways you can interpret this statement; (1) they do not know when the breach actually occurred other than this data range, or (2) for 36 days the attackers were in Global Payments and Global Payments had no idea they had been breached.

Regardless of interpretation, the bottom line is that no one really knows the timeframe of the breach.  That implies that Global Payments’ logging, monitoring and review processes were not performing to PCI DSS requirements.  Had they been working per PCI DSS requirements, I could understand a couple of days of not being able to know if you were breached as Global Payments would have been researching the information.

However, if it is option (2), it really is sad when statistics get confirmed.  This means that for 36 days, Global Payments was unaware that it had been breached.  If you look at my post regarding the latest Verizon Data Breach Report, Verizon states that most breaches are not detected quickly, if at all.

My favorite quote thus far though is from Visa.

“Visa also supports advanced security layers such as encryption, tokenization and dynamic authentication through EMV chip technology to further protect sensitive account information and minimize the impact of data compromises.”

Hello!  This was a processor that was breached Visa.  All of that security mumbo-jumbo you just pushed out there is meaningless once a transaction is at a processor.  The processor has to be able to read the information otherwise they would not be a processor.  This quote is nothing but a whole lot of spin.  It would have been better to have shut up than tried to put spin on this incident.

But the bigger issue that I think the card brands are just figuring out is that when you start shrinking the scope of where cardholder data (CHD) is stored in the systems, you just make those entities that do store CHD a bigger target.  I wrote about this phenomenon twice when I discussed point-to-point encryption (P2PE) and what would happen once merchants stopped storing CHD.  Where we are ultimately headed is with large merchants, service providers, processors, issuers, financial institutions and the card brands left with CHD.  The bottom line is that these organizations that are left storing CHD will have to be on their security “A Game” 24/7/365 in order to avoid being breached.  In addition, the PCI DSS will not be enough; they will have to be practicing security well above what the PCI DSS requires.

And finally, one piece of speculation.  Avivah Litan of Gartner is reporting:

“One interesting twist again sheds light on the fact that knowledge based authentication should not be relied upon.  I heard (and this may not be factual) that the crime was perpetrated by a Central American gang that broke into the company’s system by answering the application’s knowledge based authentication questions correctly.  Looks like the hackers took over an administrative account that was not protected sufficiently.”

I would love to meet the security “rocket scientist” that thought knowledge-based authentication (KVA) was a good idea, particularly for people with the keys to the kingdom.  Want to bet they are a former employee of a KVA solution provider?

All of the recent high profile hacks of public figure email accounts and smartphones were done through KVA using information from LinkedIn, Facebook and the like and you thought it was robust enough for your administrator accounts?  If this proves to be true, I guess we know the answer to that question and we will likely know one update to the PCI DSS.

It will be interesting to see how this breach unfolds in the coming weeks.

UPDATE: Monday, April 2, 2012

News outlets are reporting the fact that Visa has removed Global Payments from Visa’s Global Registry of Service Providers.  This is standard operating procedure for Visa, however, some of the news outlets are writing their stories to appear that Visa has severed their relationship with Global Payments and nothing could be further from the truth.  Unless the forensic examination points to some glaring error such as what was found at Heartland years ago, Visa will only remove Global Payments from the registry.

Now that Global Payments is removed from the registry, they will have to go through the PCI DSS assessment process and re-file their compliance with Visa to be added back to the registry.  It is likely that this will take a bit of time as it is my understanding that the forensic examination is not yet complete.  Until that examination is complete, it will be difficult for Global Payments to address any shortcomings in their operations that they need to correct to be PCI compliant.

The forensic examination could come back with findings that Global Payments was PCI compliant at the time of the breach.  I know a lot of you are questioning how that could be.  Remember, the PCI DSS is only a baseline for security practices, not a “be all to end all” list of security practices.  As a result, Global Payments could have been PCI compliant only to find that certain security measures needed to be at a level higher than what the PCI DSS requires.  This is how changes to the PCI DSS occur.  Attackers up their game and the PCI SSC institutes changes to the PCI DSS to address those changes of the attackers.

UPDATE: Friday, May 4, 2012

News outlets this week are reporting that the Global Payments breach may have started as early as June 2011.  Originally the breach was reported to only be 30 days in duration.  Since the breach was announced, the date the breach began has been slipping further and further back from January 2012, to December 2011 and now to June 2011.  Given the history of this breach, it is likely to slip again.  The only consistent news in all of this is that the number of breached accounts continues to be reported at under 1.5 million.  However, I am concerned that if the date of the initial breach slips again, we may find that the number of accounts may also start to rise.

The other troubling thing, as the date of the breach continues to slide backwards, is the fact that this starts to imply that Global Payments was not as diligent in their monitoring as we thought.  When the breach was initially announced, I took some flack over my implying that fact as there was only a 30 day window of breached data.  However, now that we are hearing that the breach could have been going on for more than six months, I think it is safe to say that monitoring was likely not as good as it should have been.  This would also seem to imply that they likelihood that Global Systems was PCI compliant is probably low.

UPDATE: Friday, May 18, 2012

Talk about a train wreck.  Krebs On Security is reporting that the Global Payments breach started back in January 2011.  Yes, you read that right, 2011, a full year earlier than thought.  It gets better.  Brian Krebs is stating that he has spoken to one of the persons involved in the breach and has some very interesting information about the breach posted as well.  The tally now is around 7M cards have been compromised.  I have been at a client all week and they have a minimum of 100 pre-paid cards that have been affected and they suspect there will be more.

When Will The PCI SSC And Card Brands Stop The Mobile Payment Insanity?

This week PayPal introduced Here, their mobile payment processing application for Apple iOS and Android devices.  The good news is that PayPal Here at least appears to encrypt cardholder data, but that appears to be the extent of the good news.

If you pay attention to the latest Suzie’s Lemonade Verizon Wireless advertisement, you will see Intuit’s GoPayment solution on a tablet computer processing a payment.  In another bit of good news, the Intuit GoPayment solution is also encrypted.

But what is most disconcerting is that this is just another in a string of mobile payment processing solutions to be introduced with no way of knowing whether or not the security claims are accurate or can even be trusted.  This is because the PCI Security Standards Council halted last year the certification of any of these mobile payment processing solutions through the PIN Transaction Security (PTS) and Payment Application Data Security Standard (PA-DSS).  Do not get me wrong, the Council was in a tough spot and did not have a plan as to how to deal with these solutions, so the called a halt while they went back and reassessed things.

However the marketplace is not waiting.  So while the marketplace continues to deliver solutions, the merchant is left to their own devices to know whether any of these mobile payment processing solutions can be trusted.  And what I am fearful of is that small merchants, who are the marketing target of these solutions, will be put out of business should the device somehow be compromised or they lose a device.

So what are the questions surrounding the PayPal Here?

First, what is the encryption algorithm that is used?  I am guessing that they are using DUKPT, as that is common with these sorts of devices, but it is something that should be explicitly identified in their FAQ.  What PayPal currently says is, “… the PayPal Here card reader is encrypted and is backed by over a dozen years of experience of providing buyers and sellers the highest levels of security.”  If they are using DUKPT, can the key be changed?  Most of the mobile solutions I have seen do not allow for the key change under DUKPT which could be a problem.

Then there is the fact that you can manually enter a cardholder’s information through the iOS/Android application.  Given the fact that these systems are notorious for having keyboard loggers of industrial strength that means that any manual input will be recorded in the device.  I am guessing that would include cardholder name, PAN and expiration date.  However, if PayPal Here collects the CVV/CVC/CID value in manual entry that would be an extremely bad thing as the device will retain that until it overwrites it months later.  Again, there is no documentation to determine what is allowed to be manually entered, so we cannot assess how much risk this might introduce.

But the scariest feature of the PayPal Here is unrelated to credit cards; it is the remote capture of checks.  PayPal Here allows the merchant to scan a check and then submit it to their financial institution.  Again, given the data retention of these devices, I can only guess that the check images processed through the PayPal Here application will remain on the device until the space is needed which could be months.  The problem with all of this is that if people think credit card security was questionable, check processing security is nonexistent.  As a result, anyone with a modicum of knowledge could use the check information on one of these devices to drain every bank account stored.

Let us hope that the PCI Security Standards Council and the card brands quickly get back to certifying these applications so that merchants are not using insecure payment solutions.

Financial Institutions – Your Time Is Coming

I have been getting a lot of inquiries lately about whether or not financial institutions are required to comply with the PCI standards.  It fascinates me how certain groups seem to think that the rules apply to everyone else but their own.  Page five of the PCI DSS states:

“PCI DSS applies to all entities involved in payment card processing – including merchants, processors, acquirers, issuers, and service providers, as well as all other entities that store, process or transmit cardholder data.”

I do not see any exclusion for financial institutions in that definition and the use of the term ‘all’ seems pretty inclusive to me.

A few years back we started to get panicked phone calls from financial institutions that were being pressured by the various ATM networks to prove that the financial institution’s ATM network was PCI compliant.  While most financial institutions in the United States outsource the management and networking for their ATMs to a third party, a small number of financial institutions still switch their own ATM networks.  And it was those financial institutions that switched their own ATMs that were the target of the PCI compliance initiatives of the ATM networks.  Some of those financial institutions did PCI Report On Compliance (ROC) for their ATM networks.  Some financial institutions outsourced their ATM networks.

Most financial institutions in the United States and Europe outsource their credit card processing and issuance to third parties or wholly owned subsidiaries.  As a result, the financial institution itself is typically not involved in the PCI compliance regarding the credit cards issued under their name.

Unfortunately, the same cannot be said about debit cards.  While the issuance of debit cards is typically done by a third party, in order for the debit card to work, the financial institution must store the debit card primary account number (PAN) in their banking system so that the debit card can be linked to the customer’s account.  As a result, the financial institution is storing cardholder data in their computer system(s) which means they must be PCI compliant.  And that cardholder data must securely traverse the financial institution’s network.

Another area that catches financial institutions is statement preparation.  While a lot of financial institutions outsource this as well, some have purchased software that accomplishes the combining of statement information from a variety of sources.  Unfortunately, the firms that process their credit and debit card transactions put the full PAN on their statements.  As a result, the statement prep software creates PDFs and other documents with the full PAN without the financial institution necessarily being aware of that fact.

What adds insult to injury to this situation is that most financial institutions purchase their software applications from third party development firms.  As a result, the financial institutions are at the mercy of these third parties to ensure that cardholder data is processed, stored and transmitted per the PCI standards.  To make matters even worse, with all of the regulatory changes going on in the financial institution industry over the past five years, these software firms have been focused on those regulatory changes and not PCI compliance.

The only piece of good news in all of this for financial institutions is that the card brands have not been pushing the issue of PCI compliance.  The unofficial reason that financial institutions have not been pushed on PCI compliance to this point is that, in the scheme of things, they have not been where the breaches have occurred.

With merchants and service providers finally getting their acts together on PCI compliance, the focus is going to shift to the other entities named in that earlier definition.  How soon financial institutions will start to be asked to document their PCI compliance is anyone’s guess.  But I have to bet it will start occurring over the next two to three years.  We are already hearing rumblings from some fairly large financial institutions that want to get PCI gap analyses done so that they can get started on remediation and stay ahead of the curve.

So, if you are one of those financial institutions with their head in the sand, you have been warned.  It is not a question of ‘IF’ you will need to be PCI compliant; it is a question of ‘WHEN’.  And knowing how quickly some of you move, it might behoove you to get started on your PCI compliance efforts now.

Why The Push For EMV Adoption In The United States?

Have you noticed all of the press lately regarding the Europay, MasterCard and Visa (EMV) card coming out of Visa?  It has been very hard to miss.  As a result, I started wondering about the purpose of this full court press for EMV.

Before getting into my post, I need to be clear that EMV only refers to the chip in the EMV card.  In the past I have gotten a lot of feedback from Visa when I referred to EMV as “chip and PIN” even though the world almost universally refers to EMV as “chip and PIN.”

With that disclaimer, since last August, Visa USA has been making a concerted effort to get merchants to adopt EMV.  Just a week or so ago, there was another push by Visa USA to entice merchants to support EMV.  So what is the driver behind this push?  That is the $64,000 question and the more you talk to processors and merchants, the more confusing it gets.

Merchants are just as puzzled as I am regarding Visa USA’s EMV push.  In the case of a number of large merchants I have spoken with, they do not get it as they refreshed their card terminals and POS equipment over the last three years and there is no way they are going to swap all of that new gear for EMV-capable equipment.  These merchants are not even looking at contactless terminals.  Such an equipment swap this soon would not be cost effective.

But merchants question what EMV would do for them.  EMV was developed in response to the fall of the Iron Curtain when fraud ran rampant in Europe.  Credit cards were being cloned at an obscene rate and card present fraud was huge.  When EMV was fully implemented, card present fraud in Europe went to levels close to or a little lower than in the United States and EMV card present fraud has remained around those rates since.  Given where card present fraud rates are currently in the United States, introducing EMV would have a limited effect on card present fraud and that would not be enough to offset the costs of implementing EMV or contactless terminals.

So if it is not card present fraud, it must be card not present fraud that Visa USA wants to address right?  Card not present fraud, particularly on eCommerce Web sites is running almost out of control.  I would like to say that this increasing fraud rate that is the reason for Visa USA’s push.  However, EMV does nothing to address the rapidly rising rates of card not present fraud.  The reason is that in order for EMV to address card not present fraud, there would have to be some sort of interface written that would produce codes, single use transaction numbers or similar that could be used by the consumer online.  But no such solution exists, so card not present fraud cannot be the driver either.

Back in August Visa USA announced that merchants using EMV or contactless could avoid filing a PCI Report On Compliance (ROC) with Visa USA, so that must be the reason for the push.  At this year’s PCI Community Meeting in Phoenix, Arizona, PCI SSC General Manager Bob Russo made it very clear that regardless of what Visa USA was saying about filing a ROC; all merchants were still required to prove that they are in compliance with the PCI DSS.  Other card brands also reinforced this statement by reaffirming that they still required the merchant’s ROC and/or AOC as proof of compliance.  As a result, merchants save themselves very little by not having to file a ROC/AOC with only Visa USA.

What about EMV being more secure?  While that is typically true for small and mid-sized merchants, large merchants that switch their own credit card transactions would still likely have card data in their switch systems if not elsewhere in their computer systems.  So claims by some, including at times Visa USA, that PCI compliance is easier with EMV are not totally true.  Large merchants in Europe will back this up.

So after 15 years of EMV, what is Visa USA trying to prove with this push of EMV?  Apparently only Visa USA can tell us because, for the rest of us, there are no business cases we can construct to justify the switch to EMV.  Obviously, Visa USA knows something that the rest of us do not.  Or do they?  I have consistently said that without any card not present fraud solution; EMV is just a solution looking for a problem.

But wait, maybe there is something here that we have been missing.  Is it possible that Google Wallet and similar current and future applications make Visa USA feel threatened?  There may be some factual basis in that statement.

At the PCI Community Meeting last fall, I spoke with a number of processors that seemed to have an idea of why Visa USA was finally pushing EMV.  These processors indicated that the EMV push was being driven by Visa USA to get EMV into the United States market before Google Wallet and similar applications could take the advantages of EMV away.  After all, the United States is the largest credit card transaction market in the world and if EMV was not in the United States, there is no driver to get worldwide adoption pushed.

When I quizzed these processors about the supposed “advantages” of EMV, they said that was the real problem.  With the advent of smartphones and applications such as Google Wallet, EMV has no advantages.  As a result, merchants and banks have no incentive to implement EMV with these new technologies just on the horizon.

When I went back and talked to a couple of key merchants, they all said that they are waiting out the technology race to see what wins from a smartphone perspective.  If Google Wallet and the contactless approach win, then that is where they will head.  However, a lot of merchants are betting on one-time use transaction codes displayed as bar codes to win out as they do not typically require any technology changes at their POS.  American Express went down the one-time use transaction code (15 digit number that appears like a credit card number) around five years ago, but only had limited success with it for online transactions.  However, maybe the time has come for another try.

In the end, it is the consensus of merchants and processors that Visa USA has missed the window for EMV in the United States.  Most organizations believe that if Visa USA wanted EMV in the United States, they should have pushed it long ago.

UPDATE:  American Banker and PaymentsSource are holding a Webinar entitled “The End Of The MagStripe?” on Tuesday, March 6, 2012, at 3PM EST.  Unfortunately, it is not free, it costs $99.  This Webinar purports to answer some of the questions I have posed here as well as some other interesting insights into Visa and MasterCard’s thoughts on EMV.

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.

Google Wallet

Good news for anyone considering using Google Wallet.  Google Wallet encrypts the PAN and only stores the last four digits of the PAN in clear-text according to a forensic assessment conducted by ViaForensics.  The other piece of good news from ViaForensic’s examination was that drive by attacks against Wi-Fi or near field communications (NFC) to intercept Google Wallet communications appear to fail.

Based on ViaForensic’s analysis, it appears that Google Wallet would likely comply with the PA-DSS.  The full PAN is encrypted and communication of the PAN via Wi-Fi or NFC is secured.  Granted there are a lot of other PA-DSS requirements that we do not have a window into that may or may not be PA-DSS compliant.  But on the whole, I would have to believe that Google Wallet would be PA-DSS certified.  So, why is Google Wallet not PA-DSS certified?

First and foremost, in the eyes of the PCI SCC and the card brands, Google Wallet and similar applications are storing pre-authorization data and are just an electronic representation of someone’s traditional wallet.  The PCI SSC does not certify traditional wallets, so why would they certify electronic wallets?  As a result, the PA-DSS does not apply.  Should Google and other vendors of electronic wallets ensure the security of cardholder data?  No doubt about it.

But a more important reason that the PCI SSC is backing away from certification is related to the other findings in ViaForensic’s report.  Their analysis also uncovered some not so good news in that Google Wallet stores a lot of personally identifiable information (PII) unencrypted.  This PII includes such information as cardholder name, expiration date, credit limit and account balance.  I think most people would now start to understand why the PCI SSC backed away from certifying such applications.

The PCI SSC does not want to be on the hook for the unsecured PII.  If the PCI SSC were to certify Google Wallet as PA-DSS compliant, I am sure their lawyers informed them that such a certification would drag them into lawsuits involving the exposure of the unsecured PII even though the PA-DSS does not cover PII outside of the PAN.  Their lawyers probably advised them that a PA-DSS certification would likely imply to users of these electronic wallet applications that their PII was included in the PA-DSS certification.  As a result, the PCI SSC and card brands would likely have to launch a massive and costly educational campaign to explain to the public that the PA-DSS certification was only related to protection of a cardholder’s PAN and nothing else.  And even with such a campaign, the PCI SSC would likely still get dragged into lawsuits over peoples’ PII being exposed.

And the likelihood of such lawsuits is very high.  Smartphones are regularly lost and the security protecting them is almost non-existent, if security is even enabled.  A hacker can easily take a lost smartphone and obtain enough information to perform identity theft.  Hackers could even decrypt the PAN given the high likelihood that the PIN to decrypt the PAN could be derived from other information on the smartphone.  The nightmare scenario would be development of malware delivered through the smartphone’s application store that harvests the PII.

At the end of the day, there is just too much risk involved in certifying such applications because there is just no way to manage the risk.  So those of you thinking the PCI SSC should certify these applications need to rethink your position.

FYI  This is my 200th post.  I never guessed that this blog would last this long and I want to take this time to thank all of you for keeping this going.

What Is “In-Scope?”

You would think this question would be an easy question to answer when talking about the PCI standards because anything that processes, stores or transmits cardholder data is in-scope for PCI compliance.  However, the nuances in the implementation of technological solutions do not always allow a black and white answer.  Here are some of the most common in-scope issues we seem to come across.

Defining The Cardholder Data Environment

The first step in any PCI assessment is determining the extent of an organization’s cardholder data environment (CDE).  However, it should come to no surprise to anyone that defining an organization’s CDE can be difficult even in the smallest of organizations.

The first question is who is responsible for defining the CDE?  Until the release of the PCI DSS v2.0, this was not clear, but had always been implicitly defined by the PCI SSC and the card brands as the responsibility of the organization, not the QSA.  The QSA’s role is to take the CDE definition provided by the organization and confirm that the CDE definition is accurate based on the QSA’s assessment work.

The next question that inevitably comes up is how does an organization prove that its CDE is its CDE?  There are a variety of things an organization can do to define their CDE.  The first thing to do is to document the cardholder data flow.  This effort should define all of the applications involved as well as which applications actually store cardholder data.  Once the data flow is defined, then an organization should develop a network diagram that documents all of the firewalls, routers, switches, access points, servers and other network devices and how they are architected.

The final step in proving the extent of the CDE is for the organization to scan their entire network to confirm that cardholder data is not stored anywhere outside of the CDE.  For organizations that have invested in data loss prevention (DLP) technology, it usually means setting their DLP solution to look at all computers on their network and determine if any unencrypted cardholder data exists anywhere outside of the proposed CDE.  However, some DLP solutions have not capability to look at data stored in databases, so just because you have a DLP solution does not mean you have searched everything.

For those organizations that do not have a DLP solution, the process is the same but possibly a bit more complicated.  For organizations that have a budget, they can license GroundLabs’ Enterprise Recon utility to scan their network and databases.  For smaller organizations, GroundLabs also has Card Recon that it licenses on a number of PCs/servers basis.  There are also free or open source utilities available such as Spider from Cornell University, SENF from the University of Texas and CCSRCH from Sourceforge.  I personally prefer Spider from Cornell as I think it finds the fewest false positives of the three free utilities.  However, none of these utilities can scan a database and find cardholder data stored in a database.  And just so we are clear, all of these utilities are no absolute guarantee that an organization has truly found all cardholder data they may have stored on systems.  But, it is better than have done nothing.

For organizations that are not using a utility that understands database scanning, there is a manual way to conduct your assessment.  Unload any credit card account number (PAN) fields as well as all comment fields into a CSV or similar file format and then use whatever utility you are using to scan those files for cardholder data.

Networks and Managed Service Providers

Networks that are used to transmit cardholder data in the clear are always in scope – no exceptions.  Where things seem to get confusing for people is when encryption is brought into the mix.  However, going back to the original definition, if cardholder data is in the clear, then that portion of the network is in-scope.  But, believe it or not, this just creates more confusion and arguments.

The bottom line is that any network encryption endpoints are also always in-scope.  That is a statement that I have almost come to blows over more than once with managed service providers (MSP) that thought their devices and network were totally out of scope because of encryption.  In a lot of these instances, the MSP is the one managing the encryption keys and since they managed those endpoints and the related encryption keys, those endpoints are in-scope for PCI compliance and so are the MSP’s policies, standards and procedures for managing those devices (Requirements 1, 2 and 4) and keys (requirements 3.5 and 3.6).

“But the cardholder data is encrypted,” is the common refrain from the MSP.  Agreed.  But a QSA still needs to gauge compliance for the endpoints, not the connectivity between the endpoints.  However, MSPs argue that the endpoints are also out of scope because of encryption.  That would be right if someone other than the MSP managed the encryption keys.

Another battle QSAs run across is about MPLS networks.  At this year’s PCI Community Meeting, the question of MPLS networks being private was brought up and discussed.  What the PCI SSC and the card brands told QSAs is that it is up to the QSAs to confirm that the networks are in fact private.  That means that QSAs are going to have to examine the configuration of the endpoint routers to ensure that the MPLS network is in fact private.  I can tell you that this will put QSAs in a battle with a number of carriers who treat their MPLS networks and their configuration as intellectual property.  I can tell you from personal experience that these battles to get carriers to reveal their configurations can become very contentious and downright ugly.

The bottom line is that a lot of MSPs do not agree with their activities being in-scope and they refuse to allow an assessment of their environment where their activities are in-scope.  In those instances, we have no choice but to mark the client as not having those requirements in place.  I have constantly asked MSPs that fight us to explain why the MSP is not responsible when the client cannot respond to the requirement because the MSP performs that function?  More often than I would like to admit, we get the “trust us” response.  In a few instances, I have been told that, “The PCI SSC and card brands never meant it to be treated that way.”  Really?  Because in QSA training the PCI SSC has been very consistent on the explanation of what is in-scope and MSPs are in-scope if they perform functions that are required to comply with the PCI standards.  While the majority of MSPs have come to this realization, there are still holdouts out there that still refuse to cooperate.

Applications

Applications that process, store or transmit cardholder data are always in-scope – period.  I think everyone understands that statement; however, it is the nuances within applications that create the problems.

In today’s integrated application environment, it is no wonder that determining what applications are in-scope is difficult, if not impossible.  Most organizations have gotten out of the complete application development game and are now in the application package integration game.  As a result, organizations are relying more and more on the application package vendors to understand data flow, particularly cardholder data flow.  While the PA-DSS process has greatly helped in getting data flow diagrams, there are still a lot of credit card processing applications where the data flow diagram is just not supplied.

Then we have “middleware” that further obscures things.  Middleware reformats information streams so that one application package can communicate with another application package.  The biggest problem with middleware comes from the fact that a lot of application integration teams are not really sure as to whether the cardholder data is in cleartext or encrypted.  The other problem we have encountered with middleware is the lack of security surrounding the administration consoles of the middleware.  Most middleware consoles are browser-based and can be accessed by anyone on the network.  Worse yet, a lot of these consoles can have serious security issues that make then susceptible to compromise.

Hopefully this explains the most common issues we see with scoping PCI assessments.  If you have any situations where you question scoping, please share them with the group and hopefully we can explain what is in-scope and what is not in-scope.