The leading reason why companies fail their Payment Card Industry Data Security Standard (PCI DSS) assessment is that they fail to protect cardholder data.1 This comes as little surprise; the charge to protect such sensitive data is quite a broad challenge that can increase exponentially. Not only is cardholder data used to authenticate a transaction, they are also used for settlements, reconciliation and chargebacks, and in other business processes such as loyalty rewards programs, marketing, sales auditing and loss prevention.
Any business that accepts credit or debit payments is likely required to comply with PCI DSS—measures created in 2006 to establish minimum data security measures for organizations around the world that hold, process or exchange cardholder information from any of the major card brands. These security conditions are now revised on a rotating, three-year schedule, along with related Payment Application Data Security Standard (PA-DSS) requirements, to be sure that they remain adequate in protecting sensitive data. The PCI Security Standards Council (PCI SCC) released new 2.0 versions of the PCI DSS and PADSS standards on 28 October 2010. The updated versions, which took effect on 1 January 2011, did not introduce any new major requirements and were intended to “provide greater clarity and flexibility to facilitate improved understanding of the requirements and eased implementation.”2 While the new standards have taken effect and should be adopted by organizations as soon as possible, validation against the previous version of the standard (1.2.1) will be allowed until 31 December 2011.
Until PCI DSS forced their hand, many businesses did not regularly analyze cardholder data security. However, in recent years they have faced the daunting task of, among other things, segmenting networks, upgrading point-of-sale (POS) hardware and software, and implementing fraud detection techniques in their online checkout procedures. Businesses have to verify, through costly audits and attestations, that they have installed sufficient controls to meet the requirements of PCI DSS.
Members of the National Retail Federation have collectively spent more than US $1 billion so far on PCI DSS compliance as part of their security programs, and they sometimes question the value of this investment.3 Businesses can be PCI-compliant and still not have fully secure cardholder data environments. Some of the more noteworthy data breaches have happened to companies that had passed their PCI DSS audits.
PCI DSS is not the only pressure point for businesses. Many states have enacted legislation that requires consumer notification of personal data breaches. The costs of notifications, remediation, consumer credit monitoring, legal defense and other aspects of a breach continue to rise. The Ponemon Institute assessed the cost of a data breach at US $204 per compromised customer record in 2009, up from US $202 in 2008.4 Even a small breach involving only a few hundred records can be costly, especially for small businesses. However, these cost commitments are minor when compared to the potentially devastating economic and reputational risks of a data breach or other major violations, including industry fines, reputation damage and uncertainty of business survival.
More of the liability of a data breach is shifting to consumers and businesses. For example, there is an effort by the card brands to bring new technology to the US within the next five years. The Europay MasterCard Visa (EMV) specification, already in operation and actively increasing in Europe and other global regions beyond the US, provides technology that helps detect the fraudulent use of electronic payment cards when they are physically presented for use. If an EMV-enabled card is used in a fraudulent transaction, the onus of proof is on the consumer to show that it was not he/she who used the card. This could make consumers, rather than banks and card companies, liable for fraudulent purchases that they did not make.
Businesses, too, could assume more financial responsibility for losses stemming from card fraud. This amount is on top of the cost to implement new POS hardware to support EMV, which can cost up to US $500 for each new POS terminal.
It is clear that today’s cybercriminals are more sophisticated than ever in their operations and attacks. They are always on the lookout for new ways to exploit vulnerabilities in the global payments system. According to Verizon, 285 million consumer records were compromised in 2008—more than the previous four years combined. Data breach statistics from 2010 are expected to be even grimmer due to the growth of increasingly sophisticated attack methods such as malware infections, which grew tenfold in 2009.5
With attacks coming in many different forms and from many different channels, consumers, businesses and financial institutions must gain a better understanding of how criminals operate, especially in newer channels such as social networks. They then have a better chance of mitigating the risks and recognizing attacks before they do serious damage. Understanding the nature of data theft and the conversion of stolen data into cash can help organizations of all types better anticipate in what way criminals may exploit the system, so that organizations can put appropriate preventive measures in place.
Examples of such criminal activity include masquerading as a trustworthy entity such as a bank or credit card company. These “phishers” send e-mails and instant messages that prompt users to reply with sensitive information such as usernames, passwords and credit card details, or to enter the information at a rogue web site. Other similar techniques include using text messaging (SMSishing or smishing) or voice mail (vishing) to lure victims into submitting sensitive information. Whaling is phishing targeted at high-worth accounts or individuals, often identified through social networking sites such as LinkedIn or Facebook.
While it is impossible to anticipate or prevent every attack, one way to stay a step ahead of these criminals is to have a thorough understanding of how criminals operate their enterprises.6
Every computer system and filing cabinet, along with every application that uses or stores sensitive card data, is part of the overall cardholder data environment (CDE) and in scope for PCI DSS compliance. Even if sensitive data are encrypted within the CDE, they are still within scope of PCI DSS requirements for protecting stored cardholder data. As cardholder data are used beyond the POS and for more purposes beyond transaction authentication, the CDE grows and, likewise, PCI DSS compliance and validation grow more complex and costly.
The extent of the CDE is frequently underestimated when businesses conduct their initial appraisal of the resources needed to achieve PCI DSS compliance. In many cases, it is not known that actual cardholder data are used in various business applications until the first thorough PCI DSS assessment is conducted. According to Verizon Business RISK Team research, in 2009 two-thirds of data breach cases involved data that the organization did not know were on the compromised system.7 When the data are discovered, the scope of the CDE grows to incorporate the data’s host systems and applications, as do the requirements and costs to meet PCI DSS.
For example, data encryption may need to be employed on a tape storage system utilized by the marketing department, which uses cardholder data to evaluate marketing campaigns. Even though the tape storage system is not connected in any way to the POS system, it still holds data that are required to be protected under PCI DSS.
Every business accepting payment cards has a CDE under the PCI DSS purview. However, businesses can limit—and even shrink—the scope of the CDE to reduce or minimize their PCI DSS compliance and validation burden.
For example, businesses can restrict the use of cardholder data to only those applications directly pertaining to payments: transaction authentication, daily settlements, chargebacks, add-ons for items such as gratuities, or recurring payments. Such restrictions can help limit the environment of the data to the POS system, related applications and a storage system. PCI DSS specifications provide guidelines on how to secure this, rather than limit the CDE.
Each business application that uses cardholder data pushes the boundary of the CDE outward. That is, these applications and their related storage and data flows are now in scope for all PCI DSS assessments. But, what if these applications could function exactly as they need to without the use of actual cardholder data? What if some representation of the card data would act as a suitable stand-in?
In the process of tokenization, a credit card is used in a transaction and, once authorized, the cardholder data are sent to a centralized and highly secure server, called a “vault.” Immediately after, a random unique number is generated and returned to the business’s systems for use wherever the cardholder data would be used. Essentially, the credit card data have been removed from various business applications and replaced with a token. The token can be used by an authorized application to retrieve the stored cardholder data, if necessary; otherwise, the business application simply uses the token instead of the cardholder data.
This approach has two significant advantages. First, the token has no meaning to a hacker who might siphon it from a server or an application, thus dramatically reducing the impact of a potential data breach. Second, the business application using the token data is not included in the CDE since there is no cardholder data present. Businesses that replace cardholder data with tokens in all their enterprise applications can significantly reduce the scope of the CDE and, subsequently, reduce the scope and cost of PCI DSS compliance and annual assessment/quarterly scan.
Further benefit is achieved if the business outsources the data vault to a third party. Removing the data vault from the CDE—and handing the responsibility (and liability) for it over to the third-party service provider—shrinks even further the environment that is subject to PCI compliance. However, a company’s business process owners should remain engaged with the third party to ensure that the organization maintains PCI compliance and that regular updates are provided regarding any critical process issues, such as how data are securely stored and backed up.
Many industry experts believe that tokenization and other up-and-coming techniques and technologies offer the promise to reduce the scope of the CDE in far more extensive ways than current solutions, allowing potentially significant savings to businesses striving to meet PCI DSS requirements. Additional benefits of tokenization and other enhanced security initiatives include improved business agility by focusing internal resources on core operational processes and priority objectives. Businesses should bolster PCI DSS compliance knowledge and develop a proactive, layered strategy of actions to reduce and protect cardholder data—or the ramifications of a breach could become a reality.
From a PCI DSS compliance perspective, tokenization has powerful implications for businesses, banks and service providers. One of the biggest challenges organizations face is reducing the size of their CDE and isolating it from the larger corporate network. Effectively doing so significantly streamlines the annual assessment process. By ensuring that the business applications, systems and infrastructure are processing randomly generated numbers instead of regulated cardholder information, organizations can drastically reduce the controls, processes and procedures needed to comply with the PCI DSS. This is particularly true if tokenization is provided to businesses as a service from a third party that maintains ownership of the secure cross-reference table.
For example, consider PCI DSS compliance as a spectrum. On one end, there are more than 200 detailed requirements with which merchants, for example, must comply. On the other end, there are far fewer requirements, mostly because the specifications for the PCI DSS requirement to protect stored data have been removed. The number of PCI DSS requirements that businesses must contend with is predicated on whether and how each business processes, transmits and stores cardholder data. By using tokenization to replace sensitive stored data, businesses move toward the “fewer requirements” end of the PCI DSS spectrum. Businesses eliminate a large technology and administrative burden, saving money in the long run.
In shifting the data breach risk from businesses to a third-party token provider, businesses do not need to spend unnecessary time and money building extra security into their transaction systems. Some security measures will still be needed, of course, such as in the POS device and application. However, enterprises can focus on growing the business instead of worrying about stored cardholder data because there are none on the enterprises’ systems.
Meanwhile, the token provider is now the keeper of the cardholder data for many businesses. Some critics of tokenization say the token provider represents a single point of failure. That is, if this company is breached, the cardholder data from hundreds or thousands of businesses can be compromised. True, but a trusted and reputable token provider should have sufficient resources and expertise to build and maintain strong security in its systems—just as major payment processors do today. Also, if the token service provider is breached, this company generally assumes liability for the problem.
One more business benefit is protection of the business brand in the market. If internal risk of data exposure is significantly reduced and most of the liability for safeguarding cardholder data has shifted to a third party, the organization has taken great strides to protect its brand. It is less likely to become the next company in the headlines accused of carelessly handling its customers’ sensitive data.
There are some drawbacks to tokenization. For instance, it is a relatively new application of technology. While there are successes in the marketplace, there are no long-term implementations that provide a sufficient history of how well the technique performs. Furthermore, there is a lack of trust in the various small, independent vendors that have brought tokenization solutions to market. It is not that their solutions are not good; it is simply that they are unproven over time. Many organizations feel that the stakes are too high to trust their most sensitive data to a newcomer in the data security or payment processing market.
Some larger businesses resist outsourcing data security to a third party. They believe there is an increased business risk in giving access to the organization’s most sensitive data to an outside company.
A company can either forgo tokenization altogether or implement it completely in-house with an insourced solution. In this case, the company assumes all responsibility (and liability) for data security. Or, the organization can outsource the measure to a third-party provider, thus trusting the outsourcer with the sensitive data while also lessening the liability burden. The company must decide for itself which risk is more acceptable.
The most critical aspect to ensuring outsourcing success in a PCI compliance program is choosing the right partner. Choosing an expert who specializes in secure data storage and has all of the proper controls in place will make any project manager’s life easier and allow him/her to focus on other areas of business importance. It us the project manager’s responsibility to find the vendor that meets the organization’s specific needs, with every aspect of the relationship clearly communicated, agreed upon and anticipated ahead of time. For example, all issues related to legal liability in the event of a data breach must be fully understood by both sides, with a disaster scenario action plan in place for immediate response to all affected parties if an unfortunate event becomes a reality.
Many businesses have already made significant investments in data encryption for their cardholder data. This begs the question, “If we encrypt our data, why would we also need to tokenize it?” The primary answer here is to reduce the scope of the PCI DSS requirements that the organization must satisfy.
While encrypting data is a valid security measure, it does not significantly reduce the requirements the company must meet because the cardholder data are still present— albeit encrypted. By complementing data encryption with tokenization, businesses remove sensitive card data from their applications and storage systems. This effectively reduces the CDE and subsequently reduces the cost and extent of the quarterly scans and the annual PCI DSS assessments.
Large organizations may use cardholder information in business applications such as management information system (MIS) reporting, marketing, return processing, sales auditing, loss prevention and loyalty programs. They may be concerned about replacing the actual card data with a representative token for these applications. As long as the token is format preserving—in other words, it uses the same number and format of characters as the original cardholder data—the token can be safely used by any application throughout the organization without extensive modification to those applications. Any further concerns can be overcome by how tokenization is implemented. There are two different models of tokenization: dynamic and static. The dynamic model creates a new token for a card transaction every time the card is used to make a purchase. The static model reuses an existing token that has been assigned to the card. If the static model is implemented, the merchant can maintain the functions supported by storing cardholder data. The static model represents a one-to-one relationship for life between the token and the public area network. Both models achieve the goal of reducing the burden placed on the merchant through the PCI DSS requirement to “protect stored data.”
PCI DSS compliance is growing more burdensome every year. As new threats to data security emerge, businesses are forced to apply more security techniques to attempt to stay a step ahead of cybercriminals and to account for newly identified vulnerabilities. The cost to attain, maintain and verify PCI DSS compliance is skyrocketing. Thus, all businesses in the card payment ecosystem have a vested interest in implementing long-term enhancements to data security and reducing the scope of the CDE.
Data encryption and data tokenization are two emerging technologies that show great promise in the race to secure transaction processing systems and applications. Many larger businesses are already enjoying the benefits of encrypting their cardholder data, and a few businesses have initiated data tokenization projects. Used as a one-two punch, complementary to each other, these two technologies can be especially effective at lowering the cost of PCI DSS compliance and validation by reducing the scope of the CDE.
Businesses are not expected to do this alone. The end-to-end card payment process includes many players—acquirers, independent sales organizations (ISOs), payment processors, card networks, etc. Businesses can look to these players to assist with cardholder data security and, in the process, help reduce the burden of PCI compliance.
1 VeriSign Global Security Consulting Services, Lessons Learned: Top Reasons for PCI Audit Failure and How to Avoid Them, 20072 PCI Security Standards Council, PCI Security Council Releases Version 2.0 of the PCI Data Security Standard and Payment Application Data Security Standard, 20103 National Retail Federation, et al., Letter to Bob Russo of the PCI Security Standards Council, 9 June 20094 The Ponemon Institute, Cost of a Data Breach, January 20095 Verizon Business RISK Team, 2009 Data Breach Investigations Report, Verizon, March 20096 First Data, Fraud Trends 2010: Top Threats from a Growing Underground Economy, March 20107 Op cit, Verizon Business RISK Team
Tim Hortonis vice president of merchant product management and oversees First Data’s TransArmor secure payment processing offering and other security-related products. Horton joined First Data in 1995 and has since held a variety of leadership roles of increasing responsibility. Prior to his current position, he was in corporate strategy, working on large company initiatives and working with third parties on potential partnerships. He served as vice president of product and business development for the DDA Payment Services Organization, now known as CONNECTPAY, an innovative ACH payment card solution. In this position, Horton was responsible for development of the product and go-to-market strategy. Before that, he was director of strategy and market development and helped create a new retail market organization.
Enjoying this article? To read the most current ISACA® Journal articles, become a member or subscribe to the Journal.
The ISACA Journal is published by ISACA. Membership in the association, a voluntary organization serving IT governance professionals, entitles one to receive an annual subscription to the ISACA Journal.
Opinions expressed in the ISACA Journal represent the views of the authors and advertisers. They may differ from policies and official statements of ISACA and/or the IT Governance Institute® and their committees, and from opinions endorsed by authors’ employers, or the editors of this Journal. ISACA Journal does not attest to the originality of authors’ content.
© 2011 ISACA. All rights reserved.
Instructors are permitted to photocopy isolated articles for noncommercial classroom use without fee. For other copying, reprint or republication, permission must be obtained in writing from the association. Where necessary, permission is granted by the copyright owners for those registered with the Copyright Clearance Center (CCC), 27 Congress St., Salem, MA 01970, to photocopy articles owned by ISACA, for a flat fee of US $2.50 per article plus 25¢ per page. Send payment to the CCC stating the ISSN (1526-7407), date, volume, and first and last page number of each article. Copying for other than personal use or internal reference, or of articles or columns not owned by the association without express permission of the association or the copyright owner is expressly prohibited.