By Craig Tieken, firstname.lastname@example.org
According to VeriSign Global Security Consulting Services, the leading reason why companies fail their PCI assessment is the failure to protect cardholder data. 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, but it is also used for settlements, reconciliation and chargebacks, as well as in other business processes such as loyalty rewards programs, marketing, sales auditing and loss prevention.
Understanding cardholder data vulnerabilities
Merchant-based vulnerabilities may appear almost anywhere in the card-processing ecosystem. This includes point-of-sale (POS) devices, PCs or servers, wireless hot spots, Web-based shopping applications, paper-based storage systems and the transmission of cardholder data to service providers. Vulnerabilities can extend to outside systems operated by service providers and often lead to the exposure or theft of sensitive cardholder data, especially at the merchant level.
Merchants need to understand that sensitive data is vulnerable in the following three states:
The PCI Data Security Standard (DSS) provides guidelines to help merchants understand how to protect or limit the exposure of the data.
Defining the cardholder data environment
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 is encrypted within the CDE, it is still within scope of PCI DSS requirement No. 3: Protect stored cardholder data. As cardholder data is 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.
Impact on PCI DSS compliance
The extent of CDE is frequently underestimated when merchants conduct their initial appraisal on the resources needed to achieve PCI DSS compliance. In many cases it’s not known that actual cardholder data is used in various business applications until the first thorough PCI DSS assessment is conducted. According to Verizon Business Risk Team research, two-thirds of data breach cases involved data that the organization didn’t know was on the compromised system. When the data is discovered, the scope of the CDE grows to incorporate the data’s host systems and applications, and the requirements and costs to meet PCI DSS grow as well.
For example, data encryption may need to be employed on a tape storage system used 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 is required to be protected under PCI DSS.
Limiting -- even shrinking -- the CDE
Every merchant accepting payments cards has a CDE under PCI DSS purview. However, merchants can limit -- and even shrink -- the scope of the CDE in order to reduce or minimize the merchant’s PCI DSS compliance and validation burden.
For example, merchants 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, and so on. Such restrictions can help limit the environment of the data to the POS system, related applications and a storage system. The specifications of PCI DSS 1.2 provide guidelines on how to secure this rather than limited CDE.
Each business application that uses the 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 cardholder data would act as a suitable stand-in? This is the principle behind tokenization technology.
“Token” solution advantages
In the process of tokenization, a credit card is used in a transaction and, once authorized, the cardholder data is sent to a centralized and highly secure server called a “vault.” Immediately after, a random unique number is generated and returned to the merchant’s systems for use wherever the cardholder data would be used. Essentially, credit-card data has 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.
There are two significant advantages of this approach. First, the token has no meaning whatsoever to a hacker who might siphon it from a server or application, thus dramatically reducing the impact of a data breach. Second, the business application using the token data is not included in the CDE, since there is no cardholder data present. Merchants that replace cardholder data with tokens in all their business 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 merchant 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 -- even further shrinks the environment that is subject to PCI compliance.
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 merchants striving to meet PCI DSS requirements. I encourage all merchants to learn more about PCI DSS compliance, and to develop and implement a strategy to reduce and protect the cardholder data environment -- or the ramifications of a breach could become a reality.
Craig Tieken is VP merchant product management, First Data. He can be reached at email@example.com.