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.

Pre-Authorization Data – The Card Brands Weigh In

I just wanted to pass along what I have heard thus far on this topic from the various card brands.  I’ll keep updating this post as I get more responses.

American Express (aka Trustwave) came back with the following.

“Per your inquiry regarding the storage of pre-authorized data, from what I can tell the American Express DSOP program currently does not address this topic. However, both the PCI SSC and the card brands (including American Express) have made it abundantly clear that pre-authorization data is to be protected with the same zeal as post-authorization data. That means encrypting it and restricting access to it. The reason the PCI SSC has not issued any directives regarding pre-authorization data yet is that it is a complicated environment and cannot be dealt with in a simple manner with the same approach working for all occurrences.

So, while pre-authorization data seemingly is not covered by the PCI DSS/DSOP programs at this time, you must do everything you can to protect it.

I hope this somewhat answers your question. I plan on doing more research to find any official documentation regarding the subject.”

MasterCard International followed up with their response.

“Merchants should talk with their acquirers to determine the pre-authorization rules particular to their vertical market and region.”

Visa quoted their Visa International Operating Regulations manual; section Account and Transaction Information Security Requirements VIOR 2.1.E (Updated):

“Ensure that all agents and Merchants do not store any of the following, subsequent to Authorization:
–    Full contents of any data taken from the Magnetic Stripe (on a Card, in a Chip, or elsewhere)
–    Card Verification Value 2 used to verify Card-Absent Transactions
–    PIN or the encrypted PIN block”

Discover has come back with the following.

“Currently the following restrictions apply:

(a) Sensitive Authentication Data obtained in connection with a Card Transaction must not be retained after receipt of an Authorization Response.
(b) Sensitive Authentication Data must not be recorded on Transaction Documentation or any other records or evidence of Card Transaction.
(c) Any processing, transmission, or storage of Cardholder Data must be conducted in accordance with PCI DSS requirements.”

JCB is still to be heard from.

I was deeply disappointed with MasterCard’s response.  Acquiring banks, for the most part, cannot answer basic questions about the PCI DSS, so we are supposed to believe that they are experts on retention of pre-authorization data based on a company’s vertical market and region?  Talk about passing the buck.

I am also surprised that I have yet to see any of the supposedly “very specific rules that prohibit any storage of sensitive authentication data (SAD) and do not make any exceptions.”  Not that I was expecting any as the Council has a tendency of making a mountain out of a molehill at times.

Based on the responses, I would highly recommend that merchants take American Express’ advice and protect pre-authorization data with the same voracity as they do with post-authorization data.

The Barnes & Noble Breach Take Aways

On October 24, 2012 it was announced that Barnes & Noble had a credit card breach that was the result of tampered credit card terminals.  As a result of the breach, Barnes & Noble pulled all of the credit card terminals out of their stores so that they can be examined.  The story published in the New York Times has some points that should be interesting to other large merchants.

“We have acted at the direction of the U.S. government and they have specifically told us not to disclose it, and there we have complied.”

This is probably the most important take away you should have because a lot of incident response plans miss this point.  While the credit card companies want to the notified immediately of a breach, law enforcement should be the first outside entity notified and then the card companies, if approved by law enforcement.  The reason is that law enforcement may want the breach to continue in an effort to more easily identify and apprehend the perpetrators and that may include allowing the perpetrators to use the stolen cards for purchases.

But the next question that typically comes up is who in law enforcement should be notified?  If you are not a large or regional entity, then you should notify your local police department or county sheriff.  If you are a regional or large sized merchant in the United States, you should contact the United States Secret Service and/or the Federal Bureau of Investigation.  In either case, whatever law enforcement entity you contact should be consulted with before notifying anyone else outside the organization and that includes notifying the card brands.

“The company determined that only one keypad in each of the 63 stores had been hacked.  Nevertheless, the company has not reinstalled the devices.”

The 63 stores involved were all across the country from San Diego, Miami, Chicago, New York and other locations in between.  This implies either a very organized criminal group that operates in a lot of locations or to a localized group that was able to infiltrate the operation that configures and ships out the terminals for Barnes & Noble.  Based on investigations similar to this, it is most likely that a criminal operation infiltrated a centralized location that is responsible for the configuration, repair and replacement of credit card terminals for Barnes & Noble.

So what can a merchant do to minimize this sort of attack?  Here are some actions to consider.

• Contract with only a reliable terminal supplier.  In this age of lowest cost providers, there is a big temptation to use anyone as a supplier, particularly if their costs are the lowest.  However, the old adage of “you get what you pay for” is very relevant in these situations.  As part of your vendor selection process, you should be asking a supplier of terminals what they do to ensure that terminals do not get tampered with.  If you cannot get an answer or the answer you get is “trust us,” then you should probably not consider them as a vendor.  At a minimum, vendors should put their employees through periodic background checks (at least every three to five years), track which employees work on what units, do random physical internal inspections of units and random testing of units to ensure that they are not tampered with before they are sent out.  If you are doing this activity in-house, you should also be following this process.
• Lock down your terminals.  Anyone that has been into a Barnes & Noble might recall that terminals just sat on the counter.  As a result, they were easy to quickly swap out with a doctored unit.  I have been involved in a number of situations where merchants had terminals doctored because they were easy to swap out.  If terminals are locked in a cradle and only the manager on duty has the key, anyone trying to swap terminals is going to have to have a key to free the device.  This prevents swaps that occur after hours when only the cleaning people are present.  In addition, the keys to these terminal cradles needs to be different for each location so that one key does not open every cradle at every location.  The common key is a lesson the gas station industry has only recently addressed.
• Use tamper-proof serialized security tape or stickers over the seams of the terminal and check them daily.  This is a trick that has been used for quite a while with gas pumps.  The key is to at least daily (I recommend at each manager shift change); have the stickers checked to make sure that they are still in place and log that activity.  If they have been tampered with or are missing, the lane should be immediately taken out of service and your loss prevention unit contacted.
• Confirm a terminal swap.  A lot of merchants are very lax in their terminal swap procedures.  If a terminal turns up with instructions to swap it with another or a technician appears at the location with a new terminal, the store personnel do it, no questions asked.  That is wrong.  At a minimum, a good terminal swap procedure should involve the generation of a trouble ticket in a help desk system or similar and having the store manager confirm the swap with the help desk or POS support.  No ticket, no swap, no exceptions.
• Put video monitoring on all your POS locations.  This does not stop such a swap from occurring, but it does at least record such an event if it does occur.  This is particularly important in situations where the customer also acts as cashier as with any self checkout situation.
• Use MAC address filtering on your store location networks.  If a device is unplugged and a new device is plugged in with a different MAC address it will not work.  Yes, I know for some of you this creates a bad situation.  But I always ask people in response, “Why should store personnel be swapping equipment in the first place?”
• Monitor your sensitive devices.  If a credit card terminal or POS gets unplugged from your network, you should generate an alert.  That alert should then be correlated to a help desk ticket.  If there is no ticket, then someone should immediately notify loss prevention and also follow up with store management to find out why the device was unplugged.
• Monitor your network.  Terminals or POS should only be communicating with your service provider for transaction authorization and your routers(s) and/or firewall(s) should be configured accordingly.  If a terminal or POS attempts to communicate with any other external IP address, that should generate an alert to corporate IT and security that should then be investigated immediately.  This will catch those devices that are tampered with and then transfer data to a server outside of your network.  It is highly likely that the communication will be encrypted, but the traffic will be directed to an external IP address that should be blocked if your firewall(s) or router(s) are configured properly.

UPDATE – October 24, 2012: I am quoted on the Financial Times Web site regarding the B&N breach. http://www.ft.com/intl/cms/s/0/919e3292-1dd7-11e2-8e1d-00144feabdc0.html#axzz2BjZ8C9WJ

UPDATE – November 1, 2012: I got to be a guest blogger on CNBC because of this blog entry. http://www.cnbc.com/id/49624444/How_Retailers_Can_Avoid_a_Credit_Card_Breach

UPDATE – November 5, 2012: I am interviewed by a USA Today reporter. http://www.usatoday.com/story/tech/2012/11/05/debit-card-account-theft-qa/1677537/

UPDATE – November 6, 2012: I am quoted on the front page of USA Today. http://www.usatoday.com/story/tech/personal/2012/11/05/debit-card–numbers-pins-stolen-at-pos-terminals/1675795/

UPDATE – November 8, 2012: I am interviewed on WCCO 830 Radio in Minneapolis.

Pre-Authorization Data – The Definitive Answer

Hot off the press from the PCI SSC and this month’s Assessor Newsletter.

Is pre-authorization data in scope for PCI DSS?

PCI DSS applies wherever cardholder data (CHD) and/or sensitive authentication data (SAD) is stored, processed or transmitted, irrespective of whether it is pre-authorization or post-authorization. There are no specific rules in PCI DSS regarding how long CHD or SAD can be stored prior to authorization, but such data must be protected according to PCI DSS while being stored, processed or transmitted.  Use of PTS-validated payment devices and PA-DSS validated payment applications can support PCI DSS compliance for the protection of data prior to authorization.

With respect to SAD, PCI DSS Requirement 3.2 prohibits storage of SAD AFTER authorization, even if encrypted. Whether SAD is permitted to be stored prior to authorization is determined by the individual payment brands, including any related usage and protection requirements.  Any permitted storage of SAD prior to authorization would be subject to strict conditions and controls above those defined in the PCI DSS.  Additionally, several payment brands have very specific rules that prohibit any storage of SAD and do not make any exceptions. To determine payment brand requirements, please contact the individual payment brands directly.

There we have it.  Pre-authorization data is in-scope with a number of caveats as dictated by the individual card brands.

Just to be clear, I have never argued that pre-authorization data was not to be secured with the same diligence as post-authorization data.  I just could not find anything in the PCI DSS that explicitly called out the coverage of pre-authorization data.  Past training had always explicitly referenced that the PCI DSS was for data stored after authorization, i.e., post-authorization.

Now I guess I am off to bug the card brands about their pre-authorization data retention rules if they are not posted out on their merchant security Web pages.

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.  Until October 2010, Visa Canada required 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.