I saw a blog post yesterday that reminded me of complexity and confusion surrounding the relationship between PCI DSS compliance and fraud prevention. The details of the story are less important than the central idea that the author was communicating – the notion that merchants should rely on PCI DSS compliance for the prevention of fraud. The idea behind PCI DSS is of course to reduce the amount of fraud by helping to protect payment data from unauthorized disclosure and use, but it should be noted that the standard is not a fraud prevention program. It is a data security compliance program. Understanding the difference between fraud prevention and data security will help to clarify the relationship between the PCI DSS and fraud.
Fraud is the intentional deception for personal gain. This is a broad definition that includes social engineering as well as the misuse of financial data. Fraud prevention, then, must be a very broad set of practices and procedures that are put in place to prohibit people from being able to misuse (in this case) payment card data. All of the major card brands have suggestions and best practices for preventing fraud at the merchant level. MasterCard Worldwide provides a quick reference guide to help merchants educate their staff on fraud prevention techniques. Among the suggestions is the notion that staff should be familiar with what a card is supposed to look like. Valid cards have a number of fraud prevention mechanisms, including embossed numbers and holograms. (Each of the card brands can also provide a sort of “anatomy of a card” that will keep merchants and their employees current with new card designs and security mechanisms.
Data security is a subset of fraud prevention tools. Ensuring that the data is adequately protected from unauthorized disclosure (data compromise) helps mitigate the risk of fraudulent transactions. All of the major card brands require compliance with the PCI DSS with any entity that stores, processes, or transmits cardholder data. This helps to prevent data thieves from perpetrating fraudulent transactions on a large scale. Merchants should not rely on the PCI DSS to protect them from fraud schemes. PCI DSS is designed to help companies protect payment data from thieves, not to protect merchants from fraud schemes.
ProPay is excited to announce that we received news today that our Zumogo mobile solution was selected as the winner of the 2011 ETA Techology Showcase. This is a very proud day for ProPay. As the first Social M-Payment solution in the market, Zumogo is an exciting opportunity for companies to not only accept payments from mobile phones but to directly market to potential customers. For a video of Zumogo at the 2011 Sundance Film Festival see below!
Heather Mark and Travis Allen are attending the Visa Global Security Summit this week while our EVP of Risk, Lance Rich is at the MasterCard Risk Symposium. Based on initial feedback both events are outstanding and packed with valuable information. ProPay applauds the card brands for hosting such valuable events. Below is a picture of the ProPay booth at Visa’ summit.
Recently I found myself in a discussion with a person about a particular feature of payment cards. When I started discussing the concept of authentication the look on the other persons face told me that I was discussing a completely foreign subject. While this is not a dissertation on security authentication is a vital component of information security and fraud prevention within the payment card industry. For this reason, it is important to have an understanding of the concept and how it applies to our daily lives.
Authentication is described on wikipedia as: “…the act of establishing or confirming something (or someone) as authentic, that is, that claims made by or about the subject are true”.
There are three generally accepted factors of authentication. 1) something you know (like a password), 2) something you are (biometrics like fingerprints or iris scans), and 3) something you have (like a token). Each of these factors alone have some value and may be sufficient to demonstrate with an appropriate degree of confidence that you are the person who is authorized to access the resource.
Access control is a combination of authorization and authentication. Authorization is simply the approval to access a particular resource. Consider a work environment where you are required to use a badge reader to enter the building. As an employee you are authorized to enter the building. To ensure that it is truly you (the authorized party) entering the building you need to provide some evidence that you are who you say you are. In many cases, the authentication mechanism is a proximity card that is waved and the door opens. The proximity card is a token and would be considerd as a single factor of “something you have.”.
When you get to your desk you need to access your work computer. As an employee, you are authorized to access your email, and certain applications. To log into the system you enter a user name (the system knows the person who owns this username is authorized to access certain resources) and then you enter your password. This password (something you know) is a single factor of authentication that tells the system with some degree of confidence that you are the person that matches the username.
In both of these examples the astute reader has likely identified the vulnerability of single factor authentication. In the first example a thief may have stolen the badge and may be masquarading as the legitimate user. In the second example a person may have shared their password with another of the password may have been stolen in which case an ‘unauthorized’ person could also masquarade as a legitimate, authorized user. When it is necessary to have an increased level of assurance that the authorized person is indeed the one accessing the resource, two factors of authentication can be used. For the solution to truly be considered two–factor authentication it requires two of the three types of factors to be used simultaneously. In high security areas it is common to see two factor authentication used.
Consider an example where you bank online. Due to the sensitive nature of your account (and FFIEC regulations) the bank wants to have assurance that only the authorized account holder is accessing the account. Since the bank website is accessed over the internet the bank is limited in their ability to confirm the identity of the user. A password alone is not sufficient as a password can be stolen or shared. In this scenario a bank would use a second factor of authentication. While it does not guarantee that the person using the authentication mechanism is the authorized user it provide a much greater level of assurance than a password alone.
Payment cards possess a number of authentication mechanisms. The objective is to authenticate the transaction or user and reduce the incidence of fraud. In card not present transactions such as ecommerce purchases the CVV2 number is often used to authenticate the card. Since the number is only printed on the card and it is against card brand rules (PCI DSS) to store the CVV2, the assumption is that if someone can input the CVV2 they are in possession of a valid card. Unfortunately, it is this fact that makes CVV2 such a valuable target for data thieves. More robust authentication mechanisms include 3DSecure (Verified by Visa, MasterCard Secure Code), EMV (Europay, MasterCard, Visa) and the PIN used in debit transactions. While each of these technologies increase the level of assurnace that the authorized user is making a legitimate transaction it does not guarantee such.
Authorization is a critical component to any information security or fraud prevention system. Understanding the basics fo authentication can help users better manage the security of their payment cards.
Yesterday I was on a call with a service provider attempting to explain the PCI DSS requirements and card brand mandates when it became apparant that the person on the other end of the phone did not understand their company’s PCI DSS responsibilities and had an very limited understanding of security in general. As frustrating as it was for me personally, I was more concerned about the merchants using this particular company’s services as the merchants are likely unaware of the risk to which they are exposed. If you are a merchant using a third party or a third party with questions, hopefully this post will help shed some light on the responsibilities.
In an attempt to provide some clarification on the PCI requirements for service providers, I will use excerpts from the card brand websites. (also to assuage any fears that I may be misrepresenting or misinterpreting the rules in my post
“PCI DSS compliance is required of all entities that store, process, or transmit Visa cardholder data, including financial institutions, merchants and service providers. The PCI DSS applies to all payment channels, including retail (brick-and-mortar), mail/telephone order, and e-commerce. Visa Inc.’s compliance programs manage compliance with the PCI DSS with the required program validation.”
Quite simply, if you store, transmit, or process cardholder data then you must comply. Even if your company does not store data you may be processing or transmitting which means the PCI DSS requirements apply to your organization. Hosting companies, gateways, processors, back end service providers, CRM, etc.etc. There ar literally hundreds of companies that fall into the “service provider” category and they must all comply if they store, transmit, or process cardholder data.
At this point some are likely asking “who says I have to comply?”…as stated on Visa website:
“Members (Visa member banks) must comply with the PCI DSS and are responsible for ensuring the compliance of their merchants, service providers, and their merchants’ service providers. Acquirers must include a PCI DSS compliance provision in all contracts with merchants and agents. Specific compliance requirements and validation criteria are provided at this website.“
In short, acquirers’ are responsible for their merchant’ compliance and this includes ensuring that their merchant’s use compliant service providers. Specifically requirement 12.8 of the PCI DSS mandates that companies use service providers that are compliant with the PCI DSS. The acquirer has liability for the merchant which includes liaibility should the merchant use a ‘non compliant’ 3rd party.
As stated on Visa’ website:
“If a member, merchant or service provider does not comply with the security requirements or fails to rectify a security issue, Visa may fine the responsible member.”
“Both issuers and acquirers must use, and are responsible for ensuring that their merchants use, service providers that are compliant with the PCI Data Security Standard (DSS). Although there may not be a direct contractual relationship between merchant service providers and acquirers, Visa issuers and acquirers are responsible for any liability that may occur as a result of non-compliance.”
So what is a Service provider? In the Visa world there are two basic types of service providers. VisaNet Processors (VNP) and Third Party Agents (TPA). At last count there were only about 90 VNPs. The vast majority of Service Providers will fall into the TPA category. As stated in the Visa TPA FAQ document.
“A TPA is an entity, not connected to VisaNet, that provides payment-related services, directly indirectly, to a Visa client and / or stores, processes or transmits Visa account numbers. TPA perform multiple functions on the issuing and acquiring side of a Visa client’s business.”
In the MasterCard world, service providers are either Third Party Processors (TPP) or Data Storage Entities (DSE). As stated on the MasterCard website:
“In the SDP Program, Service Providers is a collective term for Third Party Processors (TPPs) and Data Storage Entities (DSEs). Web merchants contract with Service Providers to facilitate many business functions, including, but not limited to, offering and selling their content online, payment services, hosting applications and processing.”
By this point in the post it should be clear that if a company stores, transmits, or processes cardholder data then they are required to comply with the card brand rules including those mandating compliance with the PCI DSS. All service providers are required to validate compliance with the PCI DSs through either (depending upon their classification) completion of a Self Assessment Questionnaire and network scan OR completion of an onsite assessment by a Qualified Security Assessor and completion of a network scan. These are the only two options to validate compliance with the PCI DSS for Visa and MasterCard and all service providers are required to validate. This can be confirmed by reading the MasterCard and Visa websites.
In addition to complying with the PCI DSS, service providers are also required to register with Visa and MasterCard. Visa’ registration information can be found at this link.
In summary, if you are a company that stores, transmits or processes (even if you don’t store) cardholder data then you must comply with the PCI DSS. If you store, transmit, or process cardholder data for merchants then you are a service provider and must comply and validate compliance and register with the card brands. Requirement 12.8 of the PCI DSS standard requires that only compliant service providers are used to store, transmit, or process cardholder data. In addition, the card brands mandate that service providers comply, validate and register and the card brands hold the merchant’s acuirers liable for any service provider that is not in compliance with the rules.
To gain more insight into the rules you can read some previous posts on this blog or visit the card brand websites.