I mentioned that I spent last Friday morning with card fraud and security experts. The conversation began with a wide view of what’s happening, and a focus upon PCI DSS Standard 2.0, which is yet to be published.
The Payment Card Industry (PCI) Securities Standards Council (SSC) have developed new versions of the PCI Data Security Standard (PCI DSS) and Payment Application-Data Security Standard (PA-DSS) for release at the end of October, which will then last three years in implementation.
After that period, there will be a one-year sunset before the next generation of PCI standards take over.
This is based upon the new agreement in the cards markets which means that every three years a new standard is released to keep up with market and technology change, with a year to implement the new standards and phase out the old one.
Source: PCI Lifecycle Factsheet
The fact that the new standard appears to be an evolution of the old standard, with no changes to merchant technology, is a good thing some say, as it means no major budget changes to card machines.However, it’s not a good thing as it ignores many key areas of technological development within the card community, such as server and desktop virtualization, tokenization of regulated data, end-to-end encryption (E2EE) of card holder information and the use of cloud-based applications.
This is interesting as card processors, such as Visa, are offering guidelines in these areas, such as Visa’s best practices for tokenization.
Tokenization is a relatively recent practice whereby credit card data is changed to ensure data thieves cannot steal it, for example by only communicating the last four digits of the credit card. The view being that if the data’s not there, it cannot be stolen.Their report makes an interesting read:
“In October 2009, Visa published the Visa Best Practices for Data Field Encryption to promote the proper encryption of sensitive card data that is transmitted, processed or stored by stakeholders throughout the payment system. As part of these best practices, Visa recommended that entities use tokens (such as a transaction ID or a surrogate value) to replace the Primary Account Number (PAN) for use in payment-related and ancillary business functions.
“Tokenization can be implemented in isolation or in concert with data field encryption to help merchants eliminate the need to store sensitive cardholder data after authorization. Entities that properly implement and execute a tokenization process to support their payment functions may be able to reduce the scope, risks and costs associated with ongoing compliance with the Payment Card Industry Data Security Standards (PCI DSS).
“How Tokenization Works
“Tokenization defines a process through which PAN data is replaced with a surrogate value known as a ‘token’. The security of an individual token relies on properties of uniqueness and the infeasibility to determine the original PAN knowing only the surrogate value. As a reference or surrogate value for the original PAN, a token can be used freely by systems and applications within a merchant environment.
“Where properly implemented, tokenization allows merchants to limit the storage of cardholder data to within the tokenization system, potentially simplifying an entity’s assessment against the PCI DSS. As a reference or surrogate value for the original PAN, a token can be used by systems and applications within a merchant environment without having to consider the security implications associated with the use of cardholder data.
“The security and robustness of a tokenization system is dependent upon the secure implementation of four critical components, and the overall management of the system and any historical data:
- Token Generation: Defines the process through which a token is generated.
- Token Mapping: Defines the process for associating a token to its original PAN value.
- Card Data Vault: Defines the central repository of cardholder data used by the token mapping process.
- Cryptographic Key Management: Defines the process through which cryptographic keys are managed and how they are used to protect cardholder and account data.”
“The Merchant Risk Council (MRC) is a merchant-led trade association focused on electronic commerce risk and payments globally. The MRC was formed when two entities decided to join forces: the Merchant Fraud Squad and the Internet Fraud Round Table.
“The Merchant Fraud Squad was founded in September of 2000 by American Express, ClearCommerce and Expedia. The membership quickly grew and, by the end of 2002, the primary focus was to educate online merchants on how to prevent fraud.
“In 2001, HP and ClearCommerce founded the Internet Fraud Round Table, a grassroots group of large retail merchants, to share best practices through twice a year face-to-face meetings and monthly conference calls. By the end of 2002, the Internet Fraud Round Table had grown to over 60 marquee e-Commerce retailers.
“At the end of 2002, the two groups teamed up to form the Merchant Risk Council.”
If you like the Finanser, check out the books of the blog: the new Complete Banker Series