Mobile Payment Application PA-DSS Certification Clarification Announcement

On Friday, June 24, 2011, the PCI SSC issued a press release and a number of supporting documents regarding PA-DSS certification.

In my opinion, the most important part of this announcement is in the FAQ and is the classification of mobile payment applications.  According to the PCI SSC, they have identified the following three categories of mobile payment applications.

• Category 1 – any mobile payment application that operates on only a PCI PTS certified device.
• Category 2 – any mobile payment application that meets all of the following criteria: the application that is “bundled” with a specific mobile device; the mobile device is purpose built and performs only the payment function; and when installed on the device per the vendor’s PA-DSS implementation guide, allows the merchant to meet and maintain PCI DSS compliance.
• Category 3 – any mobile payment application that runs on a consumer electronic device such as a smartphone, tablet or PDA that is not dedicated to payment processing.

What the PCI SSC has stated in this latest clarification announcement is that Category 1 and 2 applications and devices can continue through the certification process.  For the first time, these mobile applications have been explicitly called out even though these sorts of applications have been part of the certification process in the past.

What is interesting is the definition for Category 3.  What the PCI SSC appears to be saying is that applications such as Google Wallet and the like may have to go through PA-DSS certification.  While this makes sense from a payment security perspective, it takes the PCI DSS into the realm of pre-authorization data.  While the PCI SSC will not officially certify mobile payment applications in Category 3 at this time, they are highly recommending that mobile payment applications in this category use the PA-DSS as a guide to ensure their security.  The PCI SSC also commits to releasing guidance on what PCI DSS requirements are relevant to Category 3 mobile payment applications while it continues to research how it should handle these mobile payment applications.

However this is not the first time the PCI SSC has delved into recommendations regarding securing pre-authorization data.  At the first PCI Community Meeting in September 2007, there was an infamous breakout session on the security of pre-authorization data.  And sometime later this year, the PCI SSC has said it will issue an informational supplement on securing pre-authorization data.

The other important piece of news from this announcement is that, in the interim, the PCI SSC is asking merchants to conduct their own risk assessment of Category 1 and 2 mobile payment applications to determine how well they comply with relevant PCI DSS requirements. These risk assessments should include consultation with an organization’s QSA as well as acquiring banks.

PCI SSC Nixes PA-DSS Certification For Mobile Payments Applications – For A While

In a not so widely disseminated and tough to find statement, the PCI SSC has basically put the kibosh on the PA-DSS certification of any mobile payment applications for the time being.  The second paragraph of the statement says it all.

“Until such time that it has completed a comprehensive examination of the mobile communications device and mobile payment application landscape, the Council will not approve or list mobile payment applications used by merchants to accept and process payment for goods and services as validated PA-DSS applications unless all requirements can be satisfied as stated.”

The statement indicated that the Council will be taking up the topic of how to certify these applications and addressing any changes to the PA-DSS program that may be required.  However, there was no idea as to when this topic would be addressed until recently when the PCI SSC further clarified their position on this matter through a statement made to Evan Schuman’s StorefrontBacktalk stating that any decision on mobile payment applications will not be issued before April 2012.

The threat from mobile payments made through a Web site modified for mobile devices is no worse than the threat presented by a customer’s home PC.  However, applications developed for the Apple or Android marketplaces are a problem.  They are totally new applications and these platforms have keyboard loggers embedded in them, so they make PA-DSS compliance difficult, if not impossible.  And then there is the question of who is responsible for ensuring they are PA-DSS compliant?  The developer?  The marketplace?  Apple?  Google?  Then there is the whole issue of ensuring that the application is installed to ensure compliance with the PA-DSS.  These are just some of the issues that the PCI SSC and their mobile payments working group have to address.

As I stated in a previous post, mobile payment processing, no matter how you define it, is not the easiest environment to secure.  I am glad to see that the Council has seen the light and is approaching their analysis in a careful and considered manner.  However, until there are guidelines issued, it is the “Wild, Wild, West” as vendors from the card brands to Google to open source deliver mobile payment solutions.  All of which have their issues when it comes to security and PCI compliance.

Google recently introduced their “Wallet” application that runs on a smartphone and uses near field communications (NFC) technology to conduct payments similar to contactless credit cards.  For those of you not up to speed on NFC, a bit of background.  NFC is a wireless technology that operates in the 13.56 MHz band and can transmit data at 106kbps to 848 kbps at a distance of 1.5” (4cm) to almost 8” (20cm).  NFC works similar to proximity cards used with access control systems and, as such, an NFC reader can provide power to the device so that it can be used.  In the case of Google Wallet, since the platform is an Android smartphone and can provide power, I would assume that for Google Wallet the phone powers an NFC transmitter.  The big difference with NFC from proximity cards is that NFC devices can be rewritten, although for contactless credit cards, they are read-only.  NFC also shares some communication characteristics with Bluetooth, but NFC has less range.

The biggest problem with the NFC standards is that they do not specify security protocols, so out of the box, NFC is not secure.  That means that security must be added by the developers and that is where we tend to get into trouble.  When security is not part of a standard, I get the opinion that a lot of developers look at security as a kludge and therefore do not provide it until an incident happens.  The other problem we can encounter is the developer that creates a proprietary security solution.  I remember a number of years ago talking to a group of developers about potential security issues their application could encounter and one of them spoke up and said, “Why would anyone want to hack our application?”  Indeed, why would anyone?  But a number of hackers point to mountain climbers and use their quote, “Because it is there.”

The next largest problem is developing the application to comply with the PA-DSS.  Based on how the Google Wallet announcement was written, since there was no reference to the PA-DSS in that announcement, I seriously doubt Google Wallet was developed to be PA-DSS compliant.  Since there was no reference to the PA-DSS, I have serious concerns about Google Wallet security.  And my concerns get further heightened when I consider Google’s business model of selling information to the highest bidder.  No, Google will not be selling credit card numbers, but do you think the PA-DSS stops them from selling your spending habits?  If you do, think again.

And finally, being a wireless technology, the obvious threat for NFC is eavesdropping and man-in-the-middle attacks.  NFC vendors made the eavesdropping threat all the more easier by offering “developers” free developer toolkits.  Up until last year, if you registered at most vendors’ Web sites as a “developer,” the vendor would send you a free developer toolkit that was comprised of software, drivers, samples of cards and the all important reader.  It turned out that some enterprising individuals were using these developer toolkits to electronically skim cards.  The process was simple enough.  Load up a notebook with the necessary drivers and applications, attach the antenna, put that in a backpack and walk the streets.  Some were hiring teenagers that worked at convenience stores and the backpack was placed directly under the real reader.

That is not to say that there are no PA-DSS certified mobile payment solutions available.  There are some certified solutions from Verifone and other vendors that basically bypass the iPhone, iPod Touch, Android software and use it strictly as a display with no input capability.  However, in order to make these solutions work, you or your processor has to support the method of end-to-end encryption that these mobile payment solutions use to secure their transactions.

Hopefully what we get from the PCI SSC regarding mobile payments will be worth the almost year long wait.

UPDATE: This post by Evan Schuman indicates that the PCI SSC may have something of a standard for certain mobile platforms in August or September of this year.

The PCI SSC has released a press release and some articles on this topic.

• 
  https://www.pcisecuritystandards.org/pdfs/pci_pr_110624.pdf
  
• 
  http://www.digitaltransactions.net/news/story/3101
  
• 
  http://risnews.edgl.com/retail-news/PCI-Council–Validation-of-Some-Mobile-Payment-Acceptance-Apps-Now-Possible73855
  

Doctored Credit Card Terminals

It was announced this week that the Michaels retail stores breach was much larger than originally thought.  However, to those of us in the PCI business, this breach should not have been a surprise.  This sort of breach has been going on for quite a while.

Now before everyone goes out and pillories Michaels for their bad luck, I would like all of you to consider how you would have detected such a situation?  The bottom line is that for most of you, you would have been just as clueless until the FBI and Secret Service turned up at your doors.  So be careful about getting too sanctimonious.  More on how to detect these attacks later.

Regardless of what the PCI SSC has said in the past, credit card terminals are not the “dumb” devices as portrayed by the PCI SSC.  With the introduction of the PA-DSS v2.0, there was an indication that the PCI SSC had finally come to their senses and recognized this fact by having the software that is used in credit card terminals finally certified under the PA-DSS standard.  Let us face it, certain credit card terminals are just as sophisticated as netbooks, use a Linux or Windows Embedded OS as a base and have their own software development kits (SDK).  Not exactly the specification for a “dumb” device.

Another point that should not have been a shock is the fact that the terminal was used as the attack vector.  Those people advocating end-to-end encryption fail to remind people that wherever the endpoints are will become the new attack points.  As a result, the Michaels attacks will become a very popular attack vector once end-to-end is implemented.

Wait a minute, the terminal will become more popular for attacks?  After all of last year’s belly who about end-to-end encryption, I can tell you that merchants are under the impression that end-to-end encryption gets them out of being breached.  It is people like Bob Carr, CEO of Heartland Payment Systems, that are the biggest neglectors of explaining the whole story behind end-to-end encryption.  End-to-end encryption just moves the attack points, in this case out to the terminal at the merchant’s location.  Worse yet, it also makes security of the merchant’s endpoint even more difficult than it already is because the techniques used in doctoring terminals can easily go unnoticed.

Early attacks on terminals were crude and, for the most part, remain this way.  Typically, USB thumb drives are soldered into the terminals.  This attack approach requires the criminals to swap out the doctored devices periodically to obtain their contraband.  Fortunately the “electricians” used to doctor these terminals are usually not good at their tasks.  As a result, only a few of the doctored terminals actually work and collect usable track data.  To get their doctored terminals into retail locations, the criminals hire on as night custodians or other overnight stock help and swap the devices during that time.

But times change.  The criminal element gets smarter and begins doctoring terminals using software, not hardware.  After all, these devices are just small computers.  So now the device is programmed to collect the data and then transmit it during the overnight to a server on the Internet or, worse yet, a server that has been compromised on your own network.

So what can a merchant do to counteract such attacks?  Actually, quite a bit.

• Put serialized security tape on all of the seam openings on your card terminals and check it at least daily to ensure that it is still in place and that the serial numbers match.  When the tape becomes worn, replace it and record the new serial numbers.  If you ever notice the tape missing or the serial numbers do not match, take that terminal out of service.  Contact your acquiring bank or processor and obtain a terminal directly from them to replace the potentially tampered with unit.
• Use only reliable card terminal vendors.  I know that merchants are under tremendous cost pressures, but are these savings really in your best interest when you are leaking cardholder data on every transaction?  Probably not, particularly when customers start complaining and your legal costs start ramping up.  However, even trusted vendors can become a bad source of equipment, so keep this in mind.
• Do not trust anyone that just shows up to replace your card terminals.  If you did not ask for service, no acquiring bank or processor is going to be proactive replace terminals unless they notified you.  Be very skeptical of any service person that appears out of nowhere to “fix” your terminals.
• If your terminals are on your network, monitor your terminals for when they are disconnected.  In most organizations, terminals are rarely disconnected, so any such alert would be an indication that something abnormal has occurred and should be investigated.
• Monitor your external network connections and connections from the terminals to devices that should not be in your cardholder data environment (CDE).  Any traffic from the terminals outside your network or to devices not in your CDE is probably someone leaking cardholder data from your terminals for their criminal use.  If you see such activity, notify your local FBI office immediately and ask them if you should stop the traffic.  At this point, you should also probably get a computer forensic analyst involved to begin gathering documentation on the attack.

These are just some ideas on how to address this situation.  You may have additional options available to you because of the way your organization is configured.  However, you need to begin considering this new attack vector as one that will only get worse.

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.

If Not The PCI Standards, Then What?

I have just read a couple of articles as well as attended a couple of meetings where the topic du jour was the PCI standards.  They were a bash fest of the highest order.  Frustrated, I asked the participants at my last meeting, “If not the PCI standards, then what standard do you want to follow to ensure the security of cardholder data?”  Roaring silence.

This is the frustration that I and others have with people who complain about the PCI standards or any standards.  People complain and complain, yet they offer no solutions to address their complaints.  One thing I have always stressed with and required of people who work with me, if you are going to complain about something, you better have an idea for a solution.  Constructive criticism is fine, but if you do not have any ideas on how to make things better, then all you are doing is whining.  Children whine, adults have solutions.

But then you have the complainers who do offer a solution but that solution is to allow the marketplace to address the problem.  Hello!  How long was it going to take before merchants and service providers got a clue about securing cardholder data?  If it was such a priority, why did it take the card brands to come out with the standards?  For merchants and service providers, cardholder data security was not a priority, it was some other merchants’ or service providers’ problem.

The other problem with the marketplace approach is that each organization learns from its own incidents and possibly from incidents suffered by their business partners, not from the incidents experienced by all.  Under the marketplace approach, security protection only improves as each individual institution suffers a particular incident.  As a result, organizations reinvent the wheel with the majority of incidents.

Standards allow organizations to learn from the collective experience of all organizations, not just their own organization.  For example, if your organization does not have wireless networking but decides to implement wireless, a standard provides a guideline as to how to implement wireless securely.  Without a standard, you are on your own to do the best you can.  On your own you will likely get some things right, but you will also get some things wrong.  It is those mistakes due to lack of experience that come back to bite organizations.  With a standard to follow, the chance of getting bitten after the fact is often greatly minimized.

However, standards are not a guarantee.  Going back to wireless, just look at how things went wrong with WEP.  WEP is a standard and was well documented on how to implement it; supposedly securely.  WEP was also known to have the potential for security problems, but those problems were not widely publicized until organization began to have security incidents.  So a stop gap standard was provided called WPA which turned out to have its own security issues.  Ultimately, WPA was replaced by WPA2 which is the secure, permanent solution.

This is why early adopters of technology can end up getting burned.  When an organization decides to hop onboard the latest and greatest technology, there is a high risk that the security learning curve is not very far advanced.  As a result, the organization will be at a higher risk of suffering a security incident than an organization using a more tried and true approach.  As a new technology matures, typically its security posture matures and with a more mature security posture, the lower the likelihood that a security incident will occur.  However, the time it takes for that security maturity to occur can take quite a while and it is where things take quite a while where organizations are at the highest risk.

Unfortunately, in some instances, a new technology gets quickly usurped by an even newer technology and the original new technology never matures.  The bad news is that the early adopters get stuck with a solution that will never have its security shortcomings addressed, leaving the early adopters to either convert to the newer technology or find another alternative.  Many a career has been ended over such technology leap frogging events.

The PCI standards were not developed in a vacuum.  They are a consolidation of a lot of other security standards and guidance gained through root cause analysis of security incidents gathered over the years with the express purpose of protecting cardholder data.  If you follow another security standard such as ISO 27K or FISMA, a lot of what is in those standards is also in the PCI standards.  But there are also a lot of requirements in the PCI standards that are not in other standards as well.

The bottom line is if you do not like the PCI standards, then get involved in the process to make things better and stop whining.

If They Want You, They Will Get You

Over the last few years, card brand executives have implied that the PCI standards are the ‘Holy Grail’ and that only by following these standards can cardholder data be protected.  To add insult to injury, the House of Representatives’ Subcommittee on Emerging Threats, Cybersecurity, and Science and Technology held hearings on the PCI DSS and its ineffectiveness in stopping terrorism funding.  In the end, all of this bluster just added fuel to the fire around security and in particular cardholder data security.

What all of these people have missed is that regardless of whatever security standard you follow, sensitive data, cardholder or otherwise, is always at risk.  There will always be a market for private information and there will always be someone willing to take the risk to obtain that information, regardless of the barriers put in their way.  If they want you, they will get you.

Do not believe this to be true?  Over a week ago, it was announced that HBGary Federal, an obscure subsidiary of Internet security firm HBGary, was attacked by “Anonymous” and their internal emails and other documents were posted on the Internet.  To add insult to injury, Twitter and LinkedIn accounts were also compromised and postings were made under those compromised accounts.  But the most embarrassing thing about this was that the documents posted showed that HBGary Federal is in the business of corporate espionage and discrediting corporate rivals.

What the HBGary incident highlights is how different a dedicated attacker is from your everyday, annoying attacker.  Dedicated attackers are hunters.  They research their prey conducting detail reconnaissance of their target.  They know about the defenses of their target and they develop plans to defeat those defenses or at least keep them at bay.  These are people skilled in their craft.  These are people that take a job as part of the night cleaning staff at the building where their prey is located.  They use this as an opportunity to scope out their quarry and determine where the weaknesses are located.  If they need other expertise, they will go and acquire that expertise either through training or by teaming with someone that has that expertise.  In the end, if they want you, they will get you.

And that is where the ‘Holy Grail’ status falls apart.  Security relies on human beings either to configure, manage or monitor the process.  Unfortunately, humans make mistakes either deliberately or accidentally.  It is those mistakes that more times than not create the problems the result in breaches.  Decisions are made to short cut a process to save time.  Alerts or warning messages are ignored because they always are generated.  Commands are mis-keyed resulting in an unforeseen configuration change that opens a hole.  Whatever it is, mistakes occur and sometimes organizations pay the price.

The late David Taylor at PCI Knowledge Base was quoted as saying, “It’s easy to find somebody to be in noncompliance if that is the primary goal.”  What Mr. Taylor is pointing out is that ‘witch-hunts’ are always successful given enough resources.  No matter how well you think your organization is run, there are always enough ‘rocks’ that can be turned over to reveal a less compliant side of the organization.  Forensic examinations are looking at the underside of all of those ‘rocks’ to determine which ones resulted in the breach.

Unfortunately, for most organizations, the forensic process becomes a witch-hunt because the media and public demand it.  Why?  Because thanks to the card brands and the PCI SSC holding out the PCI DSS as the ‘Holy Grail’, the public’s expectation is that a breach should never happened.  That is not the message that should be being delivered.

What the card brands need to do is explain to the public the actual realities of the PCI standards.  Particularly the fact that even if the PCI standards are followed, breaches are still going to occur.  Now those breaches that occur should be much smaller and less costly, but they are still going to occur.  That is the stark reality of security because, as I know some of you are tired of hearing, security is not perfect.

UPDATE: After the comments I have received, I want to clarify this point.  I am not suggesting that security is a worthless endeavor because it is not and cannot be made perfect.  Security is a necessary activity that all organizations need to participate in at some level.  What people need to realize is that security is not perfect, it will stop the great majority of incidents if properly implemented and managed, but it will not stop everything.  The problem is that there are sales and marketing types, as well as security “experts” that imply that their solutions or ideas will result in a “perfect” solution.  It is these things that concern me because the unknowing believe that they are absolutely protected and then are dumbfounded when an incident occurs and then blame the security industry for misleading them.

More On Mobile Payments

As I have found out, the definition of “mobile payment” is defined by to whom you are talking.  For consumers, mobile payment means using their smartphone to pay for goods and services.  For merchants it includes the consumer definition as well as using smartphones or similar mobile devices to process payments.

Last year I wrote a post regarding mobile payments and the use of smartphones, primarily the iPhone, for use as credit card terminals.  When I wrote that first post, Apple was running an advertisement for the iPhone that showed it being used to process a credit card payment with the ubiquitous tag line, “There’s an app for that.”  Shortly after that post, the advertisement dropped the iPhone as a credit card terminal.  I am not aware that the PCI SSC or any of the card brands complained about that advertisement, but I found it interesting that those images of it processing a credit card were removed particularly given that a number of security and privacy issues that were and still are being discussed regarding the iPhone.

That is not to say that iPhone credit card adapters have not continued to be developed.  It is just that they are nothing like the one shown in that original Apple advertisement.  The first one that I came into contact with was Verifone’s PAYware Mobile solution and the fact that it is PA-DSS certified.  Whoa!  In my previous post I talked about all of the issues with the iPhone that make it almost impossible to be PCI certified.  How did Verifone create a PA-DSS certified application on the iPhone?  What Verifone did was to create a digital back to the iPhone.  All of the operations that need to comply with the various PCI standards are done through the digital back, not the iPhone.  The iPhone is just used as a display.  In the event that a credit card will not swipe through the digital back, the customer must go to a standard register.  I have also been privy to a number of similar iPhone applications.  All of them avoid the iOS interfaces as iOS is the problem in achieving PCI compliance.

While iPhone is the “Big Kahuna” of smartphones, it does not mean that Android and Windows Phone devices are not also used for credit card payments.  Unfortunately like the iPhone, Android and Windows Phone devices have similar issues that make them difficult, if not impossible; to have PA-DSS certified applications.  So from a merchant perspective, iPhone, Android and Windows Phone all have to be treated very carefully when they are used to process credit card payments.

But security concerns have not stopped merchants from rolling out mobile payments.  Starbucks recently introduced an iPhone and Android application that allows the customer to put their Starbucks cash card on their phone.  The application creates a 2D bar code with the cash card’s number.  The Starbucks POS system reads the bar code and automatically deducts the purchase from the account’s balance.  Within a week of releasing the application, it was determined that if you take a picture of the screen containing the bar code, anyone with the bar code can use the account until it cannot pay for a purchase.  So much for secure mobile payments.

If we expect to secure payments, the traditional credit card is just not going to get the job done.  EMV, aka Chip and PIN, is a short term technological fix but also a back up payment method for where I think we are really headed.  I truly believe that the future in payments is smartphones and other mobile devices with software that generate one-time transaction codes for paying for goods and services.  Whether those codes are displayed as a 15/16-digit number or bar code on a screen or transmitted via Wi-Fi, Bluetooth or RFID, a consumer will not need a traditional credit card.  A 15 or 16 digit number will be necessary to use so that POS systems do not have to be re-engineered to support the new payment method.  Scanners are already capable of reading bar codes from smartphone screens, so that much of the solution is already in place.  Wi-Fi, Bluetooth and RFID technology is coming as we speak so it is only a short matter of time before the infrastructure is in place to support such a solution.  All that is needed is the software.

Such an approach not only will secure card present transactions, but would also tackle the security issues we face with card not present transactions.  If done right, mobile payments can become the solution to our PCI compliance problem.

RTFM

Bear with me as I tell you a short story.

“A long time ago, in a galaxy far, far away,” (thank you George Lucas) I worked with a very seasoned IBM systems programmer.  He had the acronym ’R T F M’ neatly framed hanging behind his desk.  I quickly found out what it meant the first time I had a problem with the mainframe that I could not solve.  As I walked into his office carrying the huge case of paper that was my program dump, he pointed to the picture behind his desk.

“Yeah, so what?” I replied rather indignantly.

He said, “R T F M!”

“Yeah.  And what the [expletive] is R T F M?” I replied a bit confused and frustrated.

He snapped back, “Did you Read The [Expletive] Manuals?”

RTFM was one of his few pet peeves.  If you had read the manuals, he would help you as long as it took to solve your issue.  If you had not read the manuals, you were quickly guided back out of his office and not so politely told to read the [expletive] manuals.  If you then went and read the manuals and still had problems, then you could come back and ask for his help.  Heaven help you if you still did not read the manuals and came back.  I only saw it happen once and it was not pretty.

The reason I was brought back to this memory recently is because I am getting tired of people only reading the PCI DSS.  It is painfully obvious from their questions that this is all that they have read.  The PCI SSC’s Web site contains all of the documentation you need to interpret the PCI standards, yet it seems the only document that people download and read is the PCI DSS.  All the rest of the documentation just seems to get ignored.  If people were just reading the rest of the documentation that is available we would all be better off.

As a result, I thought I would take some time to walk people through the documentation that exists outside of the PCI DSS and explain why they should read it.  In my opinion, the following documents are mandatory reading for anyone involved in PCI compliance efforts.

• PCI DSS Quick Reference Guide – At 30+ pages long, it is not as “quick” as one might like, but it is probably the best Primer you can get.  If you are new to credit card processing, new to the PCI standards or an Executive just trying to figure this PCI thing out, this will get you up to speed in a hurry.  This is the piece that you put in your Executives’ and Board of Directors’ hands to get them up to speed and should be mandatory reading before discussing PCI compliance.
• Glossary – This document should have been titled, “READ ME FIRST” instead of the Glossary as it is more than just a traditional glossary of terms.  The Glossary explains key industry concepts as well as the terminology.  In some cases, the Glossary explains key security concepts that are referenced in the PCI DSS.  The bottom line is that this document should be read before reading the PCI DSS and then used as a key reference as you read the PCI DSS.  Even for those of us “veterans” of the banking and technology worlds need to read this document just as a refresher.  I would guess 45% of questions regarding the PCI DSS are answered just by the Glossary.
• Navigating the PCI DSS – This document explains the other 45% of the questions regarding the PCI DSS (I know, that only adds to 90%.  The other 10% are valid questions).  The key thing you will get out of this document is the intent of each of the requirements and some of the tests.  This document should be read in conjunction with the PCI DSS as it will answer most of those, “Why in the world would I want to do that?” and “What were they thinking?” sorts of questions.
• Information Supplements – These are white papers published by the PCI SSC that explain technologies or concepts that can enhance PCI compliance and/or improve your security.  As of January 2011 there have been seven of these published on topics such as wireless, penetration testing, code reviews and other key topics.  This is where you can get all of that detailed PCI compliance guidance that QSAs have running around in their heads.  The PCI SSC promises us even more of these in the coming years, so you need to check this section of the Documents Library regularly to make sure you have them all.

These documents are optional reading for any involved in PCI compliance efforts.  However, the Prioritized Approach is a great tool to get you quickly moving on PCI compliance.

• Prioritized Approach for PCI DSS v1.2 – Okay, this is out of date and I am sure a new one will be produced.  However, for those of you that want to focus on getting PCI compliant, this is for you.  It will take you through the PCI DSS is a way that hits the requirements that are most important to least important so that you focus on big ticket, big bang requirements first and then work your way through the rest of the PCI DSS.  For the most part, it still works with v2.0.
• PCI DSS Summary of Changes Version 1.2.1 to 2.0 – For those of you familiar with the PCI DSS and you want to know where the changes are between v1.2.1 and v2.0, this is the document for you.

The PCI SSC’s Web site has a wealth of information on its Documents Library page.  Not only is the PCI DSS covered, but they also have all of the Self-Assessment Questionnaires and related documents, Payment Application Data Security Standard (PA-DSS), PCI Pin Transaction Security (PTS) as well as information on Approved Scanning Vendor (ASV) standards and other resources.

In addition to the Documents Library, there is also the ‘FAQs’ system.  This is an interactive system that allows you to research questions that have been posed to the PCI SSC.  So, before you ask your QSA that question, go to the ‘FAQs’ and look for it there.  I would have posted a link, but it is a dynamic Web page and you must go to the page by clicking on the word ‘FAQs’ at the top of the Web page.

RTFM people!  And for those of you that are curious; yes, I had read all of the relevant manuals.

The Harsh Reality Of Security

Chris Skinner has a blog entry that asks the question, “Why does the card securities council not care about card security?”  What concerns me is the title of the article as it again implies that the PCI standards do nothing to secure cardholder data.  As a result, I thought I would take a shot at answering this question.

Mr. Skinner points to a number of technologies that he feels the PCI SSC is ignoring as potential solutions to securing cardholder data.  These solutions include tokenization, end-to-end encryption (E2EE) and Chip & PIN (EMV).  I recently posted a blog entry on all of these technologies, so I will not go into all of these here.  The bottom line on all of these is that, individually, they do not solve the security problems we face.  However, used in conjunction, they will create a much more formidable barrier to breaches.  I can tell you that the Council is not ignoring these technologies; they are only doing proper research to ensure that whatever guidance they issue is not flawed resulting in a recall or wholesale rewriting of a standard.  Want to lose credibility?  Issue a standard that you have to later heavily modify or replace.  Do I have to remind everyone about Wired Equivalent Privacy (WEP)?

Then we have the dynamics of the card brands.  Just because Visa writes a whitepaper on some technology does not mean that the other four card brands have bought into Visa’s analysis.  Visa may be the 800 pound gorilla of the card brands, but as anyone in business knows, the 800 pound gorilla does not always get its way regardless of how boisterous or how much chest pounding it may do.  A prime example of this was in the late 1970s when IBM (then the 800 pound technology gorilla) tried to force System Network Architecture (SNA) down the International Organization for Standardization’s throat as the Open Systems Interconnect (OSI) model.  What happened was that the rest of the technology companies in the world banded together and created the OSI seven-layer model that we have today.  While it has a lot in common with SNA, it also has numerous differences.  The bottom line is that there are certain dynamics between the card brands that will preclude the Council from always following Visa’s lead, regardless of whether Visa’s analysis is right.

How about the cost of any change?  Merchants do not live on thick margins.  Most are lucky to retain 1% to 4% of total sales as their profit margin.  If you are Wal-Mart or Target, margins can be huge numerically, but still not enough to fund the kind of wholesale changes Mr. Skinner is suggesting.  Unfortunately, most merchants are nowhere near the size of Wal-Mart, so they need to be even more judicial with their expenditures.  As a result, any change that requires a significant investment is going to be tough for any merchant to swallow and will take time to get rolled out.  After all, we are in the midst of a recession, so there is even higher sensitivity to expenditures that do not enhance the bottom line.

But for a number of merchants, the cost is not so much theirs to bear as much as it is their merchant bank’s cost.  That is because a lot of merchant banks provide the entire cardholder processing environment to their merchants.  As a result, the bank will have to absorb the cost and possibly increase fees should new terminals or software be necessary.  Banks are not necessarily doing well either, so they too are avoiding any expenditures that are not going to positively influence the bottom line.  Since security is an intangible, banks are going to be very reluctant to spend on cardholder infrastructure that does not drive up revenue.  After all, in the United States and United Kingdom, the banks were bailed out by the government and are now being watched very closely by the various regulators and the regulators are holding the purse strings.  Unless the regulators come on board, there will be no expenditure on what they will consider a frivolous expense on new terminals or software.

All of these parties are intimately involved in the PCI Security Standards Council as stakeholders.  All of the card brands and a number of larger financial institutions are on the Council’s board and various work groups.  Given the economic environment and the predisposition of these parties, is it any wonder why the Council appears to not be moving forward?

Not to mention that the changes Mr. Skinner is suggesting do not eliminate the problem of security breaches, they just shift the risks.  Granted the risks get reduced, but by how much is anyone’s guess.  But in the end, there are still going to be risks.  As I always like to remind people, security is not perfect.  Yet that seems to be what the card brands and Council seem to want people to believe.  That if everyone followed the PCI standards, breaches would not occur and that is simply not true.  Breaches would still occur, they just would not necessarily occur every week releasing thousands or millions of accounts.  It would be more like a release every month of tens or hundreds of accounts.

I too would like to live in a perfect world.  But the real world is always far from perfect.  Decisions get made only when the wheel is so squeaky that it needs to be replaced.  We can rant and rave all we want, but we will only get action when we can either show (i) a measurable business benefit, such as an increase in profit or improved efficiency, or (ii) someone else is doing it and they now have a competitive advantage.  Unfortunately, I see neither of these conditions satisfied at this time nor any time in the near future.  As long as the status quo remains, no one is going to move.

In the end, the PCI SSC does care about security.  It is the politics that slow things down and those politics are not going to go away any time soon.  That is the harsh reality of business and security.

UPDATE: Forrester Research has published a great white paper titled ‘How To Market Security To Gain Influence And Secure Budget’ that explains how to avoid the common mistakes that most security people commit and, as a result, why security professionals do not get the resources that they need to get the job done.

I Must Have Struck A Nerve

My last post on the PCI SSC backing off on certifying mobile payment applications sure got a lot of people in touch with me.  As a result, I would like to recap my discussions with them so that the rest of the readership can be up to speed on this topic.

Like the term “cloud computing,” “mobile payment” means a lot of different things to people.  For most people, a mobile payment refers to the use of a cell phone, smart phone or personal digital assistant as the credit/debit card.  However, for a number of my more progressive merchant clients, a mobile payment refers to the use of a mobile, wireless device as a cash register.  This is one of the reasons why I believe that the PCI SSC has pulled back on certifying mobile payment applications.  The definition is becoming too broad and confusing thus creating too many issues to cover in a quick time.

Then there are the methods as to how these mobile payments are conducted.  From a consumer side, mobile payments can be done through RFID just like the contactless cards currently being deployed in the United States as well as using Bluetooth or Wi-Fi.  From a merchant perspective, there are a number of large merchants that are rolling out smart phones and PDAs with software to process payments over Wi-Fi and cellular.    All of these communication methods have risks associated with them.

Then there are the devices themselves that are involved regardless of whether you have the consumer or merchant view.  When you talk of cellular devices such as cell phones and smart phones, you open a Pandora’s Box of operating environments from proprietary to Windows and a number of others in between.  PDAs offer some common operating environments with their cellular brethren, but also bring some OSes of their own to the table.  All of these operating environments have their own idiosyncrasies when it comes to security or lack thereof.

Add into the mix the variety of proprietary and open development environments for each platform.  Then there is how applications get distributed.  Apple started the application marketplace approach and all the other mobile OS vendors are following their lead.  This all causes the issue of who makes sure that payment applications are certified?  Is it the developer or the marketplace?  Does the marketplace need to make sure that payment applications have been certified before they are allowed to be pushed out?  It is issues such as these that need to be discussed and addressed before the PCI SSC can issue guidance.  And these issues surrounding distribution are not simple ones.

Ultimately we are heading towards a payment environment where there is no card in the traditional sense.  I truly believe that a software algorithm will be developed that will generate secure, single use “codes” that are used to conduct transactions between consumers and merchants.  This algorithm will be similar to the Advanced Encryption Standard (AES) and will be platform independent and therefore can be run on any “intelligent” device.

In the end, I am sure all of this led the PCI SSC to want to take a step back rather than blindly charge ahead, issue a standard and then have to repeal or greatly modify the standard because of knowledge gained later.  Such an approach, while inconvenient to the rush of technology, should create a much more thoughtful approach.  So let us all be patient and let the Council do their work and get it right rather than issue something that ultimately is severely flawed.