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.

UPDATE: July 25, 2012 – In the July issue of Transaction Trends, page 6, there is an announcement from Square that they are offering a new loyalty program for merchants using Square Register and Pay. Let us hope it is securely implemented as I am sure Square is using a customer’s PAN for tracking based on how they describe the program.

UPDATE: August 30, 2012 – The Square Web site is now implying that the transmission of card data is secured through “industry-standard encryption,” whatever that means.  There have been rumors that Square has implemented point-to-point encryption (P2PE) in their card readers but was not advertising that fact.  That is why I went to this page to see what, if anything, had changed.  However, based on the statements on this page, it appears that P2PE has not been implemented as you would think they would be touting that fact.

UPDATE: October 15, 2012 – A good friend of mine just started working at Square, so hopefully we can get to the bottom of how Square works and what risk there is to merchants using their solution.  Stay tuned.

End-To-End Encryption – The Rest Of The Story

Step right up folks.  I have something that will cure all of your problems with credit card processing.  It is called end-to-end encryption.  Yes, folks, it is the be all, to end all in security.  It will cure all that ails you, particularly those nasty data breaches.  Don’t be shy, just step right up and get your own version while supplies last.

Gee, when end-to-end encryption (E2EE) is put that way, it sounds great, almost too good to be true.  And you would be right; it is too good to be true.  But if you listen to the statements of the proponents of E2EE, they make it sound like once E2EE is in place, it is like the Ronco Showtime Oven, “Just set it and forget it.”

Now, do not get me wrong.  E2EE is not a bad thing, but it does have its own set of risks.  And it is those risks that do not get discussed that concern me.  The reason for my concern is that if you discuss E2EE with any merchant, most see it as this panacea, something that will get them out of the PCI compliance game altogether.  However, nothing could be further from the truth.  If anything, E2EE may make PCI compliance even more daunting than it is today.

The first thing everyone seems to forget is that E2EE only removes those systems and networks that are between the endpoints.  That is because the data stream between the endpoints is encrypted and, therefore, out of scope for PCI compliance.  However, for a merchant, that means that the device that accepts the credit card is still in-scope for PCI compliance.  Bring this fact up to most merchants and they start complaining like no tomorrow.

That device might be as “simple” as a credit card terminal or as complex as an integrated point-of-sale (POS) workstation on a network.  However, since this device is an endpoint, the merchant or the merchant’s QSA needs to ensure that the endpoint is properly secured and cannot end up being a breach point.  Depending on the complexity of that device, that assessment might be very straight forward or very time consuming.  The reason the endpoint needs to be assessed is that security is only as good as its weakest link.  In the case of E2EE, the weakest links are the endpoints at which the data is encrypted and decrypted.

The next thing that seems to slip people’s mind is that fact that since the merchant has an endpoint, that endpoint is still a target.  Worse yet, because it is an endpoint, the level of sophistication likely required to compromise that endpoint goes up exponentially, meaning that any successful attack will likely be beyond the average merchant’s capability to readily detect.  The PCI DSS addresses this threat fairly well by requiring network monitoring, daily log reviews, anti-virus, anti-malware, firewalls and the like.  However, I can tell you from personal experience that your average merchant is not going to be equipped to deal with this new threat.

And what is the new threat?  The new threat is tampered with hardware and software.  If you think this is farfetched, think again.  It has already happened on a limited scale.  The doctoring of hardware is fairly straight forward to both accomplish and to detect.  Detection only takes looking inside the device and noticing something that does not belong.  However, doctored software is another story.  The concept of doctored software has been a concern in the health care industry since the start of using computerization for heart pacemakers.  While the health care industry has developed rigorous testing and certification procedures, the rest of the software industry has said there is no need.  That is, until now.  As the world further automates, the need for reliable, safe and secure software only increases because of the reliance people and organizations apply to that software.

So what can an organization do to stem this new threat after implementing E2EE?  Here are some thoughts.

• Purchase your credit card processing equipment only from your acquiring bank or reputable vendor.  This is not a perfect solution to the problem, but doing this should be better than buying a used unit off of eBay or from Joe’s Guaranteed Card Equipment.  Yes, you may save a few bucks, but is that worth having every one of your customers that uses a credit card being compromised?  Probably not.

• Ask your supplier of terminals or POS workstations about what they do to test these systems to ensure that they operate as expected and are not routing cardholder data to Timbuktu as well as your bank.  Ask them to provide those procedures in writing and review them to ensure they appear adequate.
• Use serialized tamperproof tape on the seams and doors of your terminals and POS workstations.  Require that at every Manager shift change the new manager on duty is required to log their review of the devices, inventory the devices and notate if any have been tampered with.  If a device does appear to have been tampered with, it should be taken out of service until a new, secure device can replace it.
• If using self-checkout systems, make sure to have those systems under both video and employee monitoring.
• Upgrade your card processing devices to the latest devices.  Over the last few years, some of these devices have seen significant changes in their design that improves their tamper resistance.  This is particularly true of fuel pumps and certain types of terminals.
• Review video monitoring if any manager notates that a device may have been tampered with to determine if you can identify possible suspects that may have tampered with the device.
• Patch your devices as soon as possible to minimize their susceptibility to attack or compromise.
• If the vendor of the equipment will perform updates, make sure that you or someone in your organization schedules the updates.  If anyone shows up at a location to “update” your equipment and it was not scheduled by your organization, contact law enforcement.
• If updates will be done by the vendor remotely, make sure that someone from your organization initiates the remote access and they observe the remote update process.  At the end of the update process, the person should terminate the remote session of the vendor.

Even implementing these processes will not remove all of the risk.  Particularly the risk of having modified software introduced into your environment.  However, these processes will show a court that you attempted to conduct due diligence and tried to keep your equipment secure.

PCI and SOX, HIPAA, GLBA, et.al.

Just got a call regarding PCI and Sarbanes Oxley (SOX) compliance.  Whether it is SOX, the Health Insurance Portability and Accountability Act (HIPAA), Gramm Leach Bliley Act (GLBA) or some other regulation, organizations that also have to comply with the PCI standards want to maximize the work effort to avoid redundancy.  After all, all of these assessments take a lot of effort to gather the documentation and other supporting materials as well as interviews and the like to go through the various assessments.  It is not that this cannot be done, but it can get complicated to ensure efforts are coordinated properly and assessment work done by one party is acceptable to the QSA and vice versa.  It has been my experience that properly planned, a lot of these other assessment programs can be aligned to minimize the amount of effort required to go through a PCI assessment.  However, be advised that there may still be a significant amount of effort on your QSA’s part as well as your own organization because of the testing required by the PCI DSS.

For example, since the release of SOX there have been a lot of changes, particularly for section 404 where most public companies think they will gain leverage.  What has happened is that with the changes to 404, the number of applications in-scope for SOX has been greatly reduced as has been the testing requirements.  Therefore what is in-scope for SOX is usually a very small subset of what is in-scope for PCI or may not even be relevant to an organization’s PCI compliance.  I know this will seem hard to believe, but we have publicly held clients where their point of sale (POS) is not in-scope for SOX.  As a result, any leverage between SOX and PCI efforts is not always possible.

But that is not to say there are not areas where leverage can be obtained.  One place where we typically get leverage is with the assessment of logical access controls, PCI DSS requirements 7 and 8.  Since most companies have a central directory for managing users such as Microsoft Active Directory, logical access controls get fairly well covered under SOX, HIPAA or GLBA.  As such, an organization’s internal audit function and/or external auditors have covered how users are added/changed/disabled/deleted, password aging, password strength, etc.  There may still be areas that were not covered such as password resets, but there is no reason to go back over what has already been covered if that was already assessed and the parameters of their assessment meets or exceed the PCI DSS requirements.  In most cases, we find that the assessment by the other party typically goes above and beyond what the PCI DSS requires.

Another area we find where leverage can be gained is with application development standards, PCI DSS requirement 6.3, and change control, PCI DSS requirement 6.4.  Both of these areas get quite a bit of scrutiny under SOX, HIPAA and Federal Financial Institution Examination Council (FFIEC) regulations as well as most organizations’ internal audit work programs.  Granted, these various assessment efforts will not cover every application or device in-scope for PCI.  However most organizations have common policies, standards and procedures for application develop and change control and those will have been assessed and tested under other assessments.  These assessments should be able to be leveraged and minimize a QSA’s testing to in-scope PCI items that were not tested as part of other assessment efforts.  Again, in most cases, we find that the assessments of these areas go above and beyond what the PCI DSS requires.

Caveats

Now before everyone runs joyously off to limit their QSA’s review activities, there are some caveats that need to be considered in order for this to be effective.

First and foremost of all of these caveats is that it is up to the QSA to be willing to accept the other parties’ work efforts in assessing the requirement in question.  The PCI SSC has made it clear that a QSA is under no obligation to accept any third party’s assessment efforts, even another QSA’s.  As a result, just because you have these other assessments does not mean that you will gain anything in your PCI assessment.  Which leads me to recommend that when you are assessing QSAs for your PCI compliance work, it is a good idea to ask them about whether or not they will accept other third parties’ assessment work?  You cannot leverage the results of these other assessments if the QSA will not cooperate.

Another caveat is that the assessment efforts from any third party must have occurred within the PCI assessment period.  No one should expect a QSA to rely on a work product that did not occur during the PCI assessment period.  I have run into situations where, because of timing, the assessment of logical access occurred a few months prior to the PCI assessment time period and would not be re-assessed by the organizations until a month after the PCI assessment period.  In those cases, we have had to conduct our own testing of logical access controls and could not leverage the other auditor’s work.  I also have had run into instances where the assessment of a particular control occurred right at the start of the PCI assessment period.  Because almost a year had passed, we opted to conduct some limited testing of the control to ensure that the control was still functioning as designed but did not conduct our full testing because of the results of the prior testing.

A third caveat is that the QSA needs to be careful in determining what was covered by the third party in their assessment.  Not that we have had organizations trying to put one over on us, but as a QSA you really need to read the third party’s report and, if necessary, ask questions about the scope of the assessment.  We have found in a number of instances that what was represented by our client and the work performed by the third party were not the same.  The reason this occurs is that what we (QSA) asked for; what our client contact then asked for; what the person who has the report supplied; do not always jive with what we (QSA) were expecting or requested.  As a result, it is not unusual to have to go a couple of iterations to get what we need.  And even then we may find out that what we can get will not meet our needs.

The final caveat is that the third party must be qualified to conduct the testing you are going to rely upon.  This is similar to the requirement that the PCI SSC tells QSAs about for internal vulnerability scanning and penetration testing.  Per my earlier example, if an organization’s external auditor has done testing regarding how users are established and assigned access to the network and applications, there is little to be gained from a QSA going through the same exhaustive testing.  As an employee of a public accounting firm, I can tell you that SOX testing is not a small effort in regards to logical access.  So unless the logical access testing totally missed the cardholder data environment, I would typically have no trouble relying on the external auditor’s assessment.

So there are ways to leverage other compliance efforts to reduce the impact of PCI compliance work.  In order to leverage all of these efforts, quite a bit of planning and coordination are required.  And just because you can do this, does not automatically mean that the leverage gained outweighs the effort required to make it happen.  So you need to keep in mind that such efforts may be for naught.