The PCI-DSS Framework: Protecting Stored Cardholder Data

Wednesday, November 25th 2009

Contents
The PCI-DSS Framework: Protecting Stored Cardholder Data 3 Introduction 3 PCI-DSS Compliance 4 Solutions for Encrypting Data at Rest 4 Data Classification, an Alternative to Encryption 8 Building Policies and Procedures 12 Conclusion 12
References 14

The PCI-DSS Framework: Protecting Stored Cardholder Data

Introduction

Payment cards, whether they are debit or credit cards are an essential component of modern commerce. EMV-based cards have already helped improve the security of millions of bank cards throughout the world, giving even more people the confidence to make payments. But there are other security concerns associated with bank cards. (Card Technology Today, 2009)

Globally, debit and credit cards are used for a wide variety of payments with Internet card payments increasingly significantly in recent years. However, with this growth in Internet-based transactions has come an increase in stories related to Card Not Present (CNP) fraud via Internet channels. (Laredo, 2008)

The proliferation of fraud and identity theft cases has put the Payment Card Industry (PCI) on the offensive frontlines. (Morse and Raval, 2008)

American Express, Discover, JCB, MasterCard, and Visa have joined forces and formed the PCI Security Standards Council, an independent organizational entity, in order to take back control of this widespread epidemic of identity thefts and fraudulent activities (PCI Security Standards Council, 2006). The PCI Security Standards Council has formulated a detailed set of 12 security requirements called PCI Data Security Standard (DSS) for merchants to follow.

While many people feel that PCI in itself may be ineffective, most agree that some standard must be in place to protect sensitive cardholder data. (Siegler, 2009)

The scope of this paper focuses on requirement 3 of the PCI-DSS, which is the protection of stored cardholder data. This is an important requirement since data at rest is more vulnerable than data in transit, and most of the time criminals and hackers target stored data as indicated by the countless news headlines of lost and stolen data tapes, laptops and servers.

This paper also discusses recent security breaches and various regulatory laws currently in place. Furthermore, this paper proposes additional solutions to protecting stored cardholder data, including software and hardware technologies, procedures and policies.

In short, we will conclude that financial organizations should take full advantage of the practices outlined by PCI-DSS to ensure the security of stored cardholder data.

PCI-DSS Compliance

PCI-DSS requirement 3 requires merchants to protect stored cardholder data (PCI Security Standards Council, 2006). How can merchants go about protecting such valuable information? Are merchants allowed to store cardholder data, and if so, what type of information is allowed to be stored? These are some of the questions that arise when merchants are confused as to what needs to be done in order to fulfill requirement 3 of the PCI-DSS. Merchants are also worried about non-compliance, which means they might suffer hefty fines imposed by the PCI due to data breaches. The most logical way of fulfilling requirement 3 is to go over each of the subsets of the requirement and compare them to the existing infrastructure.

Subsets of requirement 3 include the following: Minimizing the storage of cardholder data, refraining from storing certain credit card information such as the card-validation code, and masking the primary account number (PCI Security Standards Council, 2006). There is yet another subset which is not truly a required step to be in compliance and that is the use of encryption. Encryption is being listed as one of the so called requirements but not all merchants will be able to comply with it because of various factors, mainly the cost of implementing and integrating encryption systems and the time and energy in managing the encryption keys (Castagna, 2007).

However, despite the challenges, encryption can help organizations reach PCI DSS standards. (Moulds, 2008)

Solutions for Encrypting Data at Rest

According to PCI-DSS it is better to not store any cardholder information. But in the event that storing information is essential to conducting business, merchants need to be in compliance with PCI-DSS.

One of the reasons to not store cardholder data is because sensitive information can be lost due to some unforeseen event.

2007 was an unprecedented year for data security breaches when the subject made the headlines regularly throughout the year. A succession of high profile corporate data losses emerged; numerous victims of identity theft were made public and even government departments admitted to having become the targets of data security breaches.

Retail giant TJ Maxx is just one example from 2007, when the company announced that hackers had accessed internal systems used to process and store customer transaction data, including credit card, debit card, check and return transactions.

The incident cost TJ Maxx US$256 million and the retailer has since offered to pay Visa card issuers a further US$40.9 million to compensate for costs connected to data breach. Data and information security has been catapulted into the public’s conscience and once more reminded the public and company CEOs of the threats and dangers that come with communicating and holding cardholder data. (Meadowcroft, 2008)

Another such event occurred in February 2005, where Bank of America disclosed that it had lost backup tapes containing 1.2 million federally issued credit cards (Mogull, 2005). This debacle could have been mitigated had Bank of America used tape encryption.

In order to encrypt backup tapes there needs to be an infrastructure available to support it. There are several vendors that provide encryption appliances for encrypting backup tapes and data storage. One of these solution providers for securing data at rest is Decru.

Decru stands out from all the other solutions because their appliances are actually formally tested and verified. Additionally, Decru is one of the best vendors for providing a robust solution for encryption key management. The encryption appliances are used by the military and they are certified by the National Institute for Standards and Technology (NIST) (Decru, 2007).

So how does the Decru Tape Encryption appliance work? A very high level explanation is that the Decru appliance sits in between a backup server and a tape storage device. As illustrated in Figure 1, data backups flow through the backup server in unencrypted format, then from the backup server, data flows through the Decru device; as the data flows through the Decru device it gets encrypted and written to the tape media and an encryption key associated with the tape media is created and saved onto the Decru appliance (Decru, 2007).

[pic]

Figure 1. Decru Encrypting Backup Tapes (Used with permission, Decru, 2007)

As mentioned earlier not all merchants need nor can afford data at rest encryption. The Decru appliance costs approximately $75,000 (Decru, 2007). This makes the Decru device a very costly propostion and small businesses cannot afford to spend that kind of money on encryption. However, in Bank of America’s case, the cost of $75,000 is small compared to the costs and consequences of lost tapes.

Is it possible to calculate an approximate amount for Bank of America’s lost tapes? Bank of America might have been able to come up with some numbers, but the intangible costs are much higher. Costs such as loss of reputation, customer mistrust and brand image hurt more. In addition to these losses Bank of America suffered other consequences due to federal regulations.

Banks have to abide by mandatory federal laws, such as the Gramm-Leach-Bliley Act (GLBA). Under the GLBA there are also protection mandates for financial privacy, safeguards and pretexting (Federal Trade Commission, 1999). Essentially, Bank of America has to deal with numerous regulations such as GLBA which overrule standards such as PCI-DSS.

A data loss such as the ones at Bank of America or TJ Maxx were highly visible and well publicized. But there are other data breaches that did not make national news. One such recent event occurred at Montana State University (MSU).

It was discovered that on September 28th, 2007 an unknown person or machine remotely accessed a web server that housed student information including credit card and social security numbers (Montana State University, 2007). According to the university, the files housed on the web server were stored in encrypted fashion. But just to be cautious they have notified 1,400 people that might have been affected. This was done in good faith by MSU. If the files are encrypted, then by law MSU doesn’t have to notify or report the incident. But this incident brings up a good point; does encryption give an entity immunity from reporting the incident to the people involved? According to the law it does. But encryption does not guarantee that the files might not be accessible.

With encryption there should be verification tests performed on the data for encryption validation. Due diligence is an absolute must when dealing with private customer information and encryption. Vendors such as Decru certify their appliances. In other words, they guarantee that their product works as intended. This type of formal testing and verification is dependent on the provider. In order for Decru to gain such high certifications, they took it upon themselves to seek the necessary certifications and backing from the military (Decru, 2007). But even though the appliance is certified, there is still that weakness of not installing the device properly, in turn bypassing all security measures. In other words, humans are still the weakest link when it comes to implementing security solutions.

Decru is a good solution for encrypting data at rest within an enterprise data center environment, but what about users who travel and carry laptops from location to location?

There are certainly many incidents pertaining to laptop thefts and losses. Many of these laptops contained very private customer information, including credit card information. As mentioned earlier, according to the PCI-DSS, encryption is not a mandatory requirement, but when users are carrying sensitive information on their laptops it becomes a necessity.

On October 12th, 2007 the Transportation Security Administration reported that 2 laptops were missing and were considered stolen; in addition, the information contained in the laptops pertained to commercial drivers that transport hazardous material (Sullivan, 2007). This information is alarming since the theft of these laptops relate to the Patriot Act and National Security. The information contained on these laptops allow commercial drivers with security clearance to drive trucks that carry hazardous material. It was discovered that the laptops were not encrypted.

The Transportation Security Administration has recently taken the necessary steps to start encrypting their laptops (Sullivan, 2007). In addition, they have put controls in place for verifying and identifying all employees that have access to the ports, since these employees pick up and deliver hazardous materials to and from various sensitive areas within the United States (Sullivan, 2007).

The Transportation Security Administration could have mitigated these risks by proactively managing the contractor and making sure that the contractor had the necessary security measures in place. It is unclear if the Transportation Security Administration had any policies regarding laptop encryption for themselves as well as for their contractors.

A viable solution for encrypting laptops is PointSec by CheckPoint Software Technologies. Figure 2 depicts how the PointSec solution works for encrypting data residing on laptops (CheckPoint, 2007).

[pic]

Figure 2. PointSec Encrypting Laptops (Used with permission, CheckPoint, 2007)

Had the Transportation Security Administration implemented PointSec on their laptops, they could have first identified the laptops as lost or stolen, then a systems engineer would have been able to remotely wipe-out all data residing on the laptops. The event suffered by the Transportation Security Administration could have been easily avoided and was due to organizational incompetence and a lax approach to security.

Data Classification, an Alternative to Encryption

In lieu of encrypting data at rest what other options do merchants have in order to protect stored cardholder data? Figure 3 depicts the PCI-DSS compensating controls in the absence of data encryption (PCI Security Standards Council, 2006).

[pic]

Figure 3. Compensating Controls (Used with permission, PCI Security Standards Council, 2006)

These alternatives to encryption listed by the PCI-DSS are all good recommendations and they are likey have been put in place by many of the merchants prior to any PCI-DSS requirements. But if these compensating controls are not in place, they can easily be implemented by the merchants.

Access restrictions to cardholder data based on IP addresses, user accounts, application, and data types indicated by the PCI-DSS are not sufficient for preventing data thefts and fraudulent activities. The PCI-DSS fails to list an important and worthwhile solution to protecting cardholder data, and that is data classification.

Data classification requires less of a technology solution and more of a procedural approach. The PCI Security Standards Council should revise the PCI-DSS and add the use of data classification to the compensating controls as a possible alternative solution to encryption.

What is Data Classification? According to (Woodbury, 2007) “Data classification entails analyzing the data your organization retains, determining its importance and value, and then assigning it to a category.” The military follows a model where data is identified based on Bell-LaPadula’s mandatory access controls (Schneier, 2004). The Bell-LaPadula Model classifies data as: Top Secret, Secret, Confidential and Unclassified (Bishop, 2003). The Bell-LaPadula model seems to work well for the military but it is too stringent for the commercial sector (Schneier, 2004).

What type of classifications should the commercial industry have? In the case of protecting cardholder data storage, the categories should be classified accordingly. Once data is analyzed, it is then identified. Once the data is identified it is then designated to categories. The categories are then protected by discretionary access controls, where certain users are allowed or denied access to stored data.

Data classifications are subjective in the commercial industry, unlike the military (Bishop, 2003). Categories such as confidential/private, official use only and public, work well in the commercial sector. In order to comply with the PCI-DSS, merchants need to go through their stored data, find any documents pertaining to credit cards, social security numbers, and anything that is deemed private, classify it, then secure it (Norris, 2007).

Figure 4 was created in order to visually illustrate discretionary access controls, data and categories. As an example of how the hierarchy works, figure 4 depicts that only the CEO, Legal and HR have access to confidential and private information.

[pic]

Figure 4. Information Classification Hierarchy

There are technological solutions for data classification. But, they require time in order to gauge the organization’s environment.

One of these solutions is provided by a company called Reconnex. The idea behind their product is to have the product deployed within an organization’s infrastructure. Once the product is deployed it begins to learn the environment (Reconnex, 2007). The product also contains pre-packaged policies that can be deployed accordingly. GLBA policies for financial institutions, Health Insurance Portability and Accountability Act (HIPAA) policies for privacy of health data, PCI-DSS and so on. The problem with such a solution is that it still requires a subjective overview of what data is being classified or blocked. The product has to be fine-tuned for each environment.

Figure 5 shows how the Reconnex product works (Reconnex, 2007).

[pic]

Figure 5. Reconnex iGuard (Used with permission, Reconnex, 2007)

Although data classification seems like a good solution, it has weaknesses, and these weaknesses stem from state and federal regulations. There are legal requirements to maintaining information. These requirements pertain to data retention requirements regulated by laws such as GLBA. This information might or might not contain cardholder data. If data is purposely deleted and/or corrupted because of malicious activities then the data is not in stable and original status. And if there are certain laws that have been broken, then the data needs to be preserved in case of forensic investigations. This in a way works against the PCI-DSS requirements. What if the retention period proposed by PCI-DSS is insufficient? If there is an ongoing court case, then the information housed in the systems that are necessary for litigation supersede security standards like PCI-DSS and retention policies (Jackson, 2007). Banks, according to the GLBA, need to retain information for a minimum of 6 years (Federal Trade Commission, 1999). PCI-DSS seems to favor data destruction. So, there are some conflicting aspects. There has to be a balance between the PCI-DSS, the GLBA, and any litigations. This is definitely a difficult situation to be in, and it is understandable how merchants and organizations alike, feel powerless no matter what steps are taken. The old saying damned if you do, and damned if you don’t holds true.

Building Policies and Procedures

Having an encryption solution such as Decru for the data center, and PointSec for laptops and personal computers adds to the defense-in-depth model of information security.

In addition to encrypting data at rest in order to comply with the PCI-DSS, there are other procedural solutions such as data classification. Data classification is an involved process but it might be more cost-effective and beneficial than purchasing encryption technologies. Even though data classification is more of a manual process, it is better to know what information actually resides on merchants’ servers. This way merchants can be involved from the beginning to the end of the process in revealing sensitive data.

In order to have good security there needs to be a good structure and framework in the design and deployment of these security solutions. A way of creating frameworks for security policies is building threat matrices (Platt, 2002). The threat matrices lists all risks and their associated likelihood of occurrence. Once the threat matrices are formulated and in place, it is much easier for organizations to implement security measures pertaining to identified threats.

Building policies and procedures requires the involvement of business owners for small merchants, and upper management for larger organizations. Policies and procedures are not developed overnight and require careful consideration and constant updates.

Conclusion

So how should merchants proceed in order to comply with requirement 3 of the PCI-DSS? It really depends on the entity seeking compliance. If for example, the organizations are banks, then it is essential to invest in a way to encrypt data at rest, and in addition classify data accordingly. Banks have to comply with laws and regulations before they comply with standards such as PCI-DSS, which is not a law.

On the other hand, if the organizations involved are small merchants, then it is more cost-effective to comply with the PCI-DSS using the suggested compensating controls . Why should small merchants spend so much money on encryption if their risks of data breaches are small?

The PCI-DSS is another way of the credit card companies passing the cost of data breaches onto consumers and small business owners. Recently, California Governor Arnold Schwarzenegger vetoed the Retail Data Security Bill (Krebs, 2007). This is a step in the right direction; why should the credit card companies get the upper-hand on small businesses? The PCI have already done so with their outrageous interest rates and late payment penalties. Small businesses do not make much profits; so why should this bill be passed as law?

Credit card companies need to implement better security for their financial instruments and not pass the problem onto the merchants. The Payment Card Industry can certainly afford it.

However, despite the political challenges, the PCI-DSS is a good model for merchants to follow and it is a step in the right direction. PCI-DSS is a framework, however, and should not be made mandatory nor into law; it should just remain as is, a helpful standard for securing and protecting the merchants’ data infrastructure. Financial organizations should take full advantage of the practices it outlines to ensure the security of stored cardholder data.

With penalties ranging from fines to the ultimate sanction of issuers removing the right to accept cards, organizations across every vertical market are now aware of the business risk linked to non-compliance with the PCI-DSS. Add in the negative publicity associated with a breach in credit card security, and failure to address PCI requirements could become a business-threatening oversight. (Kidd, 2008)

References

Bishop, M. (2003). Computer Security Art and Science. Upper Saddle River: Addison-Wesley.

Castagna, R. (2007, September). Scramble that data! Storage , p. 4.

CheckPoint. (2007). Full Disk Encryption Software for Desktop PC and Laptop Security. Retrieved October 28, 2009, from CheckPoint Software Technologies Web site: http://www.checkpoint.com/products/datasecurity/images/lgdiagramPC.gif

Decru. (2007). Decru Solutions for PCI Compliance. Retrieved October 27, 2009, from Decru Web site: http://www.decru.com/solutions/pdf/pci.pdf

Federal Trade Commission. (1999). The Gramm-Leach Bliley Act. Retrieved October 28, 2009, from Federal Trade Commission Web site: http://www.ftc.gov/privacy/privacyinitiatives/glbact.html

Jackson, C. L. (2007). Plan Now for Managing Electronic Data & Avoid Tomorrow's Legal Risks. Business Guide To Compliance , 17-20.

Kidd, R. (2008). "Counting the cost of non-compliance with PCI DSS." Computer Fraud & Security 2008, no. 11: 13-14. Academic Search Complete, EBSCOhost (accessed November 25, 2009)

Krebs, B. (2007, October 26). Schwarzenegger Vetoes Retail Data Security Bill. Retrieved October 28, 2009, from Washington Post Web site: http://blog.washingtonpost.com/securityfix/2007/10/schwarzenegger_vetoes_retail_d.html

Laredo, V. (2008). "PCI DSS compliance: a matter of strategy." Card Technology Today 20, no. 4: 9. Academic Search Complete, EBSCOhost (accessed November 25, 2009).

Meadowcroft, P. (2008). "Card fraud – will PCI-DSS have the desired impact?." Card Technology Today 20, no. 3: 10-11. Academic Search Complete, EBSCOhost (accessed November 25, 2009).

Mogull, R. (2005, March 1). Missing Bank of America Tapes Underscore Encryption. Retrieved October 27, 2009, from Gartner Research Web site: http://www.gartner.com/resources/126500/126581/missing_bank_of_america_tape_126581.pdf

Montana State University. (2007, October 16). Security Alert. Retrieved October 28, 2009, from Montana State University Web site: http://eu.montana.edu/security/

Morse, E., and Vasant R. (2008). "PCI DSS: Payment card industry data security standards in context." Computer Law & Security Report 24, no. 6: 540-554. Academic Search Complete, EBSCOhost (accessed November 25, 2009).

Moulds, R. (2008). "Protecting cardholder data with encryption." Computer Fraud & Security 2008, no. 6: 14-15. Academic Search Complete, EBSCOhost (accessed November 25, 2009).

Norris, C. (2007, September 19). Strategies for success -- PCI DSS Requirement 3: Protecting stored data. Retrieved October 27, 2009, from Search Security Web site: http://searchsecurity.techtarget.com/generic/0,295582,sid14_gci1271969,00.html

"Payment Card Industry Data Security Standard" Card Technology Today 21, no. 4 (2009, April): 9. Academic Search Complete, EBSCOhost (accessed November 25, 2009).

PCI Security Standards Council. (2006). Payment Card Industry (PCI) Data Security Standard. Retrieved October 27, 2009, from PCI Security Standards Council: https://www.pcisecuritystandards.org/pdfs/pci_dss_v1-1.pdf

Platt, F. N. (2002). Physical Threats To The Information Infrastructure. In S. Bosworth, & M. Kabay, Computer Security Handbook (pp. 14.1-14.25). New York: John Wiley and Sons Incorporated.

Reconnex. (2007). Data at rest. Retrieved October 28, 2009, from Reconnex Web site: http://www.reconnex.net/images/products/diagram_dataatrest_lg.jpg

Schneier, B. (2004). Secrets and Lies. In B. Schneier, Secrets and Lies (pp. 122-127). Indianapolis: Wiley Publishing Incorporated.

Siegler, T. (2009). PCI Is Meaningless, But We Still Need It. InformationWeek, (1226), 8. Retrieved from Academic Search Complete database.

Sullivan, E. (2007, October 15). TSA Laptops With Personal Info Missing. Retrieved October 28, 2009, from The Associated Press: http://ap.google.com/article/ALeqM5jVsQSGHmxE5jv_4QU9UxSKo2ggGQD8S9SORO3

Woodbury, C. (2007). Sky View Partners Incorporated. Retrieved October 28, 2009, from The Importance of Data Classification and Ownership: http://www.skyviewpartners.com/pdf/Data_Classification_Ownership.pdf