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.

Merchant Beware – New Mobile Payment Solution Out In The Wild

Merchants need to be aware of a new mobile payment solution – Square from Square Inc.  A colleague pointed me to the Square site with the question, “Is this PCI compliant?”

Square appears to be a hardware/software solution for iPhones, iPads and Android devices.  It has a cute, square magnetic stripe reader for swiping cards, but also appears to provide the capability to manually enter cardholder data through these devices’ virtual keyboards.  This all appears to be similar to the iPhone that used to appear in the first Apple iPhone commercials that, for reasons that will become obvious, magically disappeared from their commercials very quickly and quietly.  It is also why Apple no longer uses iPhones or iPod Touches in their stores to process payments.

In referencing the PCI SSC’s PTS certification database, I could not find Square’s certification for the PTS standard.  Although, given the pictures on Square’s Web site, I really did not expect to find it certified to the PTS standard as there is no way it could meet the PTS standard.  Has Square submitted their solution for PTS certification?  It may have, but since the PCI SSC PTS certification database only lists those devices that have completed the certification process, there is no way for anyone to know if it has submitted Square until it is certified.  However, since the use of PTS certified devices is a requirement of all of the card brands, until Square is PTS certified, use of a Square device for processing of credit cards violates a merchant’s merchant agreement.  Game over.

While not complying with the PTS standard is a deal breaker in my opinion that is not the only PCI compliance issue.  In referencing the PCI SSC’s PA-DSS certification database, I could also not find the Square software application listed.  That situation was also not unexpected as the PCI SSC announced in a press release on June 24, 2011 that it was suspending the PA-DSS certification review of all mobile payment applications indefinitely.  As a result, there is no way Square’s software will be PA-DSS certified for the foreseeable future whether they submitted it for PA-DSS certification or not.  Not that the PA-DSS certification is a deal breaker for merchants to use the Square software, but it means that merchants using the Square software to process payments will have to have the Square software assessed to ensure it meets all of the PCI DSS requirements regarding payment applications.

And knowing what I know about all of these devices, I can guarantee that the Square software will not be PCI DSS compliant because all of these devices will store the cardholder data unencrypted for an untold amount of time until it is written over.  Even if Square’s software encrypts the data, the underlying OS will also collect the data in cleartext.  Forensic examinations of these devices have shown time and again that regardless of what the software vendor did, the data still existed in memory unencrypted.  And that unencrypted data in memory can exist in these devices for days, weeks to even months depending on transaction volume and other applications loaded on the device.  It is this surreptitious OS data collection activity, the security issues with other applications as well as other security concerns that caused the PCI SSC to suspend their PA-DSS certification activities of these applications.

There is only one solution that uses an iPhone or iPod Touch that is PTS and PA-DSS certified at this time and it is from Verifone.  The reason that Verifone’s PAYware solution is certified is that: (1) Verifone submitted it for the PCI certifications prior to the June 24 suspension and, the bigger reason in my book; (2) it relies on a digital back separate from the iPhone/iPod that performs the card swipe and all of the card data processing/transmission in a secure manner.  The iPhone or iPod Touch are used only as a display and cellular/Wi-Fi conduit for network connectivity.

The only other mobile payment solutions I am aware that are PTS compliant are purpose built credit card terminal using Wi-Fi or cellular communications.  These are considered terminals by the PCI SSC, so their underlying software is not required to be PA-DSS certified at this time, but they are required to be PTS certified.  In addition, these terminals have been in use in Europe for quite some time, so they are a proven secure solution.

The bottom line is that it is the merchant’s responsibility to ask vendors the right questions and weed out non-PCI compliant solutions.  The card brands and the PCI SSC are not in the business of regulating vendors, they leave that to the marketplace.

If you are looking for a PCI compliant mobile payment solution, talk to Verifone, Equinox, Ingenico or other recognized card terminal manufacturers as those are going to be your only PCI certified mobile payment processing options at this time.

UPDATE: I have had a number of people contact me about the certification status of the Square solution based on the fact that Square Inc. is listed on Visa USA’s Web site as a PCI DSS compliant service provider.  Remember, this listing only means that the card processing services provided by Square Inc. to their customers (i.e., all of the back office processing they do to process card transactions) are PCI DSS compliant, not that the devices that actually conduct the card swipe are certified PCI compliant.  A certified card terminal would be PCI PTS certified and the software running on the terminal would be PA-DSS certified.  The Square Inc. device that connects to iPhones and Android devices does not have that PCI PTS or PA-DSS certifications, therefore it should not be used for conducting credit card transactions.

UPDATE: Here is another solution that avoids the iPad altogether, Hubworks Interactive.  I spoke with them and their QSA and this product avoids the iPad by conducting the transaction in the digital framework surrounding the iPad.  The iPad is strictly used as a display and a Wi-Fi conduit.  The digital framework encrypts the cardholder data before it is ever seen by the iPad just as Mark Bower suggested would work.

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.