In the age of electronic payments, chances are you have received a letter like this:
OPEN LETTER TO OUR CUSTOMERS
June 1, 2009
Dear valued customer:
Our company values your business and respects the privacy of your information, which is why we wish to inform you that between November 2008 and May 2009, the computer systems of our business in the U.S. and Canada were accessed without authorization. This unauthorized access was in violation of both civil and criminal laws. Our company has been coordinating with federal law enforcement to assist in the investigation of this incident. While the number of potentially affected outlets involved in this incident is limited, the data accessed may have included personal information such as the name printed on a customer’s credit card or debit card, a credit or debit card number, and/or a card expiration date.
We recommend that you review your account statements and credit reports closely. To the extent that there is any suspected unauthorized card activity, it should be reported to the bank that issued your credit card, as well as to proper law enforcement authorities, your state attorney general’s office, or the Federal Trade Commission. Please also visit our website at www.company.com for instructions on how to receive free credit monitoring for one year.
Our company values customer privacy and deeply regrets that this incident occurred. Working with law enforcement and forensic investigators, Company is conducting a thorough review of the potentially affected computer systems and has implemented additional security measures designed to prevent a recurrence of such an attack and to protect the privacy of Company’s valued customers. The company also is working closely with major credit card suppliers and law enforcement to ensure that the incident is properly addressed.
For further assistance regarding this incident, please visit Company at www.company.com or call (800) 555-8001 between 7 a.m. and 11 p.m. CST daily. Company is focused on delivering customer satisfaction and value for our customers and is committed to doing everything we can to resolve this issue expediently and thoroughly to reinforce your confidence.
Sincerely,
Jane Doe
Executive Vice President & Chief Operating Officer
Company
After reading this letter, you might feel a wave of panic, wonder whether you check online for suspicious transactions or have your card reissued, wonder whether you should trust the company, or ask why your credit card data is so easily accessible.
These are all logical questions, and even with strict security standards in place, consumers are still often left with less than assuring answers. It’s time to address the problem.
There’s a new (well, not really new) sheriff in town
The Payment Card Industry Security Standards Council (PCI SSC) was formed by Visa, MasterCard, AmEx, Discover and JCB. These companies aligned their individual policies and released the Payment Card Industry Data Security Standard (PCI DSS) in December 2004. Although many companies view the PCI SSC as a heavy-handed bureaucracy and a means for the card associations to boost profits with fines and penalties, the result has been that companies have made information security a strategic part of their business.
One thing is clear about PCI DSS: There will never be a final version of the standard. The need will always exist to adapt to evolving technology; payment channels; and the primary reason PCI exists in the first place, criminals.
At its core, the PCI DSS deals with data security and encryption. The requirement specifically written for stored cardholder information is Requirement 3.4, which states that businesses shall render primary account number (PAN) unreadable anywhere it is stored using any of several approaches, including one-way hashes based on strong cryptography, truncation, index tokens and securely stored pads, and strong cryptography with associated key-management processes and procedures.
When the initial PCI DSS requirements were published, they primarily provided a framework, and most applications were unable to implement data-at-rest encryption technology without major design and development efforts. Not only was there limited availability of commercial off-the-shelf software, but the only available technology was expensive to implement. Most businesses addressed the problem of data at rest with compensating controls. According to the PCI Council, “Compensating controls may be considered for most PCI DSS requirements when an entity cannot meet a requirement explicitly as stated, due to legitimate technical or documented business constraints, but has sufficiently mitigated the risk associated with the requirement through implementation of other, or compensating, controls.” For Requirement 3.4, compensating controls are focused on limiting access to the data. This could be in the form of strong access controls, network-layer separations and application-level security, to name a few. However, the design and verification process for these controls can prove to be extremely costly and certainly are not without their challenges.
Moreover, are compensating controls sufficient?
Fear and loathing
Although many publicized intrusions and thefts have occurred in the past few years, they are by no means a new phenomenon in the payments marketplace. One well-publicized debit card theft occurred long before PCI DSS existed, in 1989 (http://massis.lcs.mit.edu/archives/security-fraud/atm-bank.fraud). A well-respected payments application provider placed a consultant onsite at a large financial institution for a long-term contract. While onsite, the consultant obtained the security credentials needed to copy all of the PIN verification information, as well as the card database. The consultant also obtained a card-encoding machine, which he used to create ATM cards.
The plan was for the consultant to create counterfeit debit cards and, along with a few accomplices, make cash withdrawals at various ATMs around the southwestern United States. The plan was thwarted when one of the accomplices tried to recruit a friend to join the group, and that friend notified authorities, who estimated that the theft could have resulted in up to $14 million of losses. That would have been quite a few $20 bills to haul and launder!
This particular crime was considered high tech for the time and illustrated that internal attacks are equally as threatening as external attacks. It also demonstrated that these crimes typically involve highly educated and clever individuals.
Just consider some of the recent highly publicized incidents (company names have been removed):
“A data breach at a payments processing firm has potentially compromised credit and debit card information from all of the major card brands,” CNNMoney, April 2, 2012
“Experts say Company either failed to encrypt or truncate credit card numbers or did not secure encryption keys,” Network World, March 29, 2007
“Hackers breach Payment Credit Card System,” USA Today, January 23, 2009
You get the picture, and it isn’t pretty. The fallout from these events can cause businesses to suffer by way of damage to brand and/or reputation; costs associated with investigation, remediation and victim notification; financial loss; fines and fees (noncompliance, reissuance, fraud loss); chargebacks for fraudulent transactions; disruption in operations; sensitive information disclosure; potential closure of the business; and potential legal liabilities beyond the association rules.
As consumers, we consider our credit/debit cards very personal items (or at least we should), and we expect our personal, card and account information to be protected from attacks.
What the Pundits Are Saying
“The overall cost of targeted attacks to organizations worldwide is $1.29 billion annually.” — Cisco, “2011 Global Threat Report”
“The costs associated with being PCI compliant are estimated at $1.7 million annually.” — Gartner, “Retail Security & Compliance Survey 2011”
What to do, what to do?
With all of the information available about information security and PCI DSS, one would think that every business that processes cardholder data is either planning to implement or already has implemented encryption strategies that protect PAN data not only to reduce the possibility of this data falling into the hands of the bad guys but also to reduce the scope and effort of the PCI compliance audit.
Many organizations now consider PCI DSS requirements a long-term business strategy rather than an annual checklist exercise. By analyzing, architecting and implementing new business processes, organizations can adapt quickly to changes to PCI requirements, as well as design new applications and platforms that conform to the policies that have been put in place. This allows even the largest organizations to roll out new products and services knowing that their storage of cardholder information complies with internal and external data security policies.
By analyzing the complete life cycle of a cardholder transaction, payment processors can pinpoint the applications that use PAN data and decide whether the processing requires clear data or can use an encrypted form. From this analysis, plans can be made to phase in protection across all the platforms that store PAN information. Some of the typical applications and platforms that store PAN data include transaction processing systems; settlement, chargeback and clearing systems; business intelligence systems; data warehouses or marts; call centers, card issuing systems; and archives.
Tokenization, Encryption or a little of both
Advances in computing processing power and encryption technology have given payments processors options on how to tackle the conundrum of protecting the PAN. The two most popular are tokenization and encryption.
Both technologies are accepted methods of protection by PCI SSC and the Qualified Security Assessors (QSAs) that administer the compliance of businesses processing payments.
Tokenization
Tokenization essentially replaces PAN data with nonsensitive data that can be used as a reference to the PAN. Tokens are designed to maintain the same format of the original data and may be used by some applications and viewed by users. The original PAN is typically required for transaction processing, particularly by the issuing bank, to authorize the transaction (PIN verification, dispute processing, call centers, etc.).
Implementing tokenization typically requires a dedicated token server (or vault) that maps the original PAN data to its associated token. (The original PAN data in the vault must also be encrypted.) This server must be designed to be highly available, as every application that participates in the token implementation may need to access the server. Some critics point to this single point of failure as one of the disadvantages of tokenization, whether the failure is in the hardware or software, or through a security breach where credentials are stolen and criminals could access the entire vault database.
Encryption
Encryption is becoming a popular choice for protecting PAN data. New encryption technologies allow the format of the data to remain while offering the ability to offset into the PAN to encrypt a certain number of digits versus encrypting the entire PAN. This type of encryption is referred to as Format Preserving Encryption (FPE), and, along with stateless key management, it eliminates the requirement for a database of encrypted PANs or data vault.
Whether tokenization or encryption is deployed, a solution that has the ability to function cross-platform and across the enterprise will make the solution easier to design, implement and manage, particularly as encryption requirements expand. Deploying these technologies may require changes to the application to integrate encryption functionality into the core business processes. There are solutions by XYPRO and other ISVs that integrate with applications using NonStop SQL and Enscribe databases, in some cases without modifying the source code. If modifying the source code is not acceptable, then intercept libraries are available from XYPRO and other ISVs to assist in protecting application data for companies using applications such as BASE24.
One approach that I have not mentioned here is volume-level encryption. Some would argue that this is the easiest method to address protecting the data, but many claim that applying strong encryption to binaries and nonsensitive data isn’t worth the added overhead and management. Moreover, VLE generally protects only the theft of a disk as all applications and utilities will have access to the unencrypted data as the encrypt/decrypt processes are automatic as the volume level.
Res Ipsa Loquitor (the thing speaks for itself)
The Latin term “res ipsa loquitor” is typically used in legal speak (readers of Hunter S. Thompson certainly recognize it) and refers to a doctrine of law “that one is presumed to be negligent if he/she/it had exclusive control of whatever caused the injury even though there is no specific evidence of an act of negligence, and without negligence the accident would not have happened” (www.law.com). (Don’t you just love legal speak!) If any executive were accused of negligence in a major breach of cardholder data, he/she would have sworn that PCI standards were being followed and everything was protected.
I believe that in the near future compensating controls for protecting personal information will no longer be an accepted practice by the PCI SSC. Either driven by the card associations, consumer groups, banks or by the federal government (please not the Feds), I think we’ll soon see litigation that will require personal information to be secured via cryptography.
Although security and intrusion detection technology continue to evolve and improve, there are many highly skilled, tech-savvy people worldwide who have at their fingertips the hardware and software resources to keep in pace with or one step ahead of commercially available security products.
Enterprise-wide encryption of cardholder information should no longer be an option but a mandate of every electronic payments business. The technology is available, and reputable partners are prepared to help businesses design and deploy enterprise data protection solutions.
Through the work of the PCI SSC, the guidelines and recommendations have been made clear and, for the most part, complied with. The fact that cardholder data at rest is still stored in the clear on many systems remains a gaping hole, but it can be addressed with commercial products available on the market. Whether it is tokenization or encryption or a combination of both, the time has come to embrace the technology. As consumers, we should demand it; as an IT person, it’s a challenging project; as a business, what are you compensating for?
James Knudsen
XYPRO Technology Corporation
www.xypro.com
Posts
