Archive for March, 2012

17
Mar
12

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.

07
Mar
12

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 they 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.




March 2012
M T W T F S S
 1234
567891011
12131415161718
19202122232425
262728293031  

Months