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.

Advertisement

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

PCI SSC Releases Virtualization Guidelines

On Tuesday, June 14, 2011, the PCI SSC released an Information Supplement regarding Virtualization Guidelines.  Not only does this Information Supplement cover virtualization from a VMware and Hyper-V perspective, but also goes into cloud computing.

The supplement is broken into six sections:

• Introduction
• Virtualization Overview
• Risks for Virtualized Environments
• Recommendations
• Conclusion
• Virtualization Considerations for PCI DSS

The Introduction and Overview sections are good foundations.  But if you have a good knowledge of the concepts of virtualization, I would not waste time reading these sections.  The Risks section is a very good discussion of the risks presented by virtualization.  However a lot of readers of this supplement are likely going to be disappointed as there is little new material covered in this section that has not been discussed before in other information sources or even my blog entries.  In my opinion, the Recommendations section presents what would be expected.

The real gem in this supplement is the Appendix that provides the Virtualization Considerations for PCI DSS.  This supplement takes the relevant PCI DSS requirements and provides a lot of guidance regarding what QSAs should consider when assessing virtual environments.  In a number of these, there are also some additional best practices and recommendations made by the writers of the supplement.  In reading these best practices and recommendations, one would think these would be common sense, but I guess you just cannot assume that any more.

Page 23 has the other great gem in a diagram that graphically represents the responsibilities of cloud customers and cloud providers regarding who is responsible for data, software, user applications, operating systems, databases, virtual infrastructure, physical infrastructure and the data center where everything resides across the three types of cloud services; IaaS, PaaS and SaaS.  If you are explaining cloud computing to non-technical people, this is probably one of the best diagrams I have seen to explain responsibilities.

If I had to take the PCI SSC to task on anything, I would argue that cloud computing does not necessarily have anything to do with virtualization.  Yes, a lot of cloud computing solution providers are using virtualized systems to provide their services, but not every cloud provider uses virtualization.  And even if the cloud provider does use virtualization, why is that the customer’s concern?  In my opinion, cloud computing should be an entirely separate document.

I have included below links to all of my prior posts on virtualization for reference.

• PCI and Virtualization
• Server Virtualization and PCI
• Cloud Computing and PCI Compliance
• More on “The Cloud” and PCI Compliance

My Opinion On SAQs

DISCLAIMER: The following is my opinion on the self-assessment questionnaire (SAQ) process and cannot be relied upon.  Only your acquiring bank can definitively tell any merchant which SAQ they should provide to their acquiring bank.

Based on the comments I got back on the first SAQ post, I thought I ought to gather that information together into one location and share my thoughts on what the PCI SSC is thinking.  The problem that small and midsized businesses (SMB) are running into is that no one SAQ meets their needs because they have multiple methods of conducting credit card transactions, from face-to-face to telephone to eCommerce.  And that is the problem.  Since there are multiple ways to conduct a transaction, no single SAQ will cover all of these transaction methods.  And since an organization is only supposed to fill out and submit one SAQ to their acquiring bank, the question becomes, which SAQ should the organization use?

Let us face it; SAQ D is just not the SAQ any organization wants to fill out.  Organizations are trying to avoid SAQ D like the plague because it is “ROC-lite.”  But unfortunately, if your business model does not fit within the strict criteria set forth with any of the other SAQs; your only option is to fill out SAQ D.  And that, my friends, is the rub.

But that does not mean that everything in SAQ D applies to your organization.  However, before everyone starts marking the majority of requirements in SAQ D “Not Applicable,” let me point out that the requirements in 9 and 12 will always apply to any organization filling out SAQ D regardless of how many ways organizations conduct their credit card transactions.

So how does an organization keep their sanity and fill out SAQ D?  In my very humble opinion, you use the other SAQs that apply to your individual transaction types to guide you in filling out SAQ D.  For example, your organization has an entirely outsourced eCommerce site (SAQ A), but you also have data entry of phone and mail orders over a PC using the eCommerce site (SAQ C-VT) and you have a portable card terminal that you conduct transactions at seminars (SAQ B).  Use the three SAQs (A, B and C-VT) as templates for filling out SAQ D.  That does not mean that there will be some other requirements in SAQ D that an organization might need to address.  However, the majority of SAQ D will be filled out and then an organization can review their SAQ D to ensure that everything that is relevant is covered.

My work with SMBs has given me an appreciation for why organizations want to avoid SAQ D.  SAQ D is not a simple task and takes a lot of time and effort to prepare, both of which SMBs do not necessarily have in abundance.  However, if your organization intends to accept credit cards for payment for goods or services, then through your Merchant Agreement with your acquiring bank, you are contractually bound to abide by all relevant PCI standards.  So, either you stop accepting credit cards for payment, or you own up to the fact that the PCI standards are just another requirement of doing business in our electronic age.

I wish I had a better answer, but there is not one.

VoIP And PCI Compliance

I have had some interesting conversations with people lately regarding voice over IP (VoIP).  It fascinates me as to how little people really know and understand how this technology works.  But what really scares me is how this lack of information is putting organizations at risk.

The most obvious problem with VoIP is segmenting it away from the cardholder data environment (CDE).  I am really disturbed by the number of organizations that have no security around their VoIP.  Yes a lot of organizations have segmented the VoIP from the rest of their network, but there are no controls that stop anyone from getting into that network segment.  As a result, anyone with the right set of tools can gain access to the traffic in the VoIP network segment.

The next thing that scares me is the lack of security surrounding the VoIP servers including any call recording servers.  People treat these VoIP servers just like their traditional PBX.  Unlike their PBX that likely ran a proprietary version of UNIX, VoIP servers are just Windows or Linux servers running a VoIP application.  As a result, they are susceptible to all of the viruses, malware and everything else any other server is susceptible.  However, these servers typically do not run anti-virus (performance issues) or are they hardened to any rational security standard.  When they get infected or hacked, it seems to be a shock to the system administrator.

And what about the call recording technology?  We keep hearing from vendors of call recording solutions that they use proprietary recording methods requiring special CODECs.  While in some instances the proprietary claims are true, what we are finding more and more is that vendors are just manipulating file header information such that Windows Media Player, iTunes and the like do not recognize the file as being in a valid format.  However, tools such as VLC Media Player are able to see past the header changes and recognize these files for what they are, WAV, MP3 and the like.  Thus some proprietary formatting claims are all a bunch of smoke and cannot necessarily be relied upon for security or privacy.  Another tell on the proprietary nature of call recordings is that, when you “convert” a recording, if the conversion software seems to be copying the recording more than actually converting it, it is likely that the header is being fixed to WAV, MP3, etc.  Real audio conversions typically take more time than just copying because the file has to be fully processed.

But the final insult in this whole scenario is the lack of understanding security personnel have regarding the VoIP protocols.  While VoIP call setup and teardown are usually conducted over TCP/IP (a stateful protocol), the actual call itself is conducted via streaming protocols over UDP/IP (a non-stateful protocol).  As a result, when you start talking to security people about VoIP security, their knee-jerk response is to tell you that VoIP is secured by the corporate firewall.  However, given that the VoIP protocols are stateless, even behind a firewall really does not provide any protection.

So you have a VoIP solution in place.  What should you be doing to ensure its security if it is in-scope for PCI compliance?  Here are my thoughts.

• Properly segment your VoIP from the rest of your network.  This means either physically or logically separating the VoIP from the rest of your network.  This also means implementing access control rules so that only those devices and people that need access to the VoIP network have access.  If you are also using your VoIP phones as the network jack for a PC, make sure to VLAN that jack to something other than the VoIP VLAN.
• If you can, implement the VoIP segment without DNS and DHCP and use MAC filtering to avoid the accidental or deliberate plugging in of a PC into a network jack that is VoIP only.  At a minimum, use MAC filtering to at least control what gets plugged into the LAN jack.
• Closely monitor your VoIP segment and generate alerts on any devices that are unplugged or plugged in.  Also monitor for any protocols other than the VoIP protocols that your VoIP system uses.
• Do not use the last octet or any other portion of the phone’s IP address as the extension number.  Yes, I know this is an easy way for the help desk to identify and troubleshoot phones, but it is also easy for an attacker to locate targets of interest, so keep that in mind when you are implementing your VoIP solution.
• Never, ever connect your VoIP network to another VoIP network outside of your explicit control.  Given that VoIP primarily uses UDP/IP, you cannot expect any firewall to protect your VoIP system from anything outside of your control.  Always use plain old telephone system (POTS) circuits to connect to any foreign network.  I know that is not as sexy as VoIP, but how else can you protect your VoIP system from outside influences?
• Work with your VoIP vendor to harden all servers that manage the VoIP system.  These are just Windows, Linux, etc. systems.  Obviously you will need to do some testing of this and you may not be able to use all of the hardening items in your server hardening standard, but you would be surprised at what you can do that the vendor says will not work.  Remember, they are just trying to cover their butts should a problem crop up.
• Be careful implementing VoIP on traditional PBXs.  A lot of these solutions are just PCs or servers and can be easily hacked once on your network just like their full VoIP brethren.
• Get a hold of VLC Media Player or similar tool and see if you can play a recording off of your call recording system.  We are getting about a 25% hit rate using VLC to play recordings.  A lot of the success of this approach depends on the age of the call recording system.  The newer the systems, the more likely it is that you will find that the recordings are just tweaks of existing standards.