The Management of Online Credit Card Data using the Payment Card Industry Data Security Standard
Clive Blackwell Information Security Group Royal Holloway, University of London. Egham, Surrey. TW20 0EX. C.Blackwell@rhul.ac.uk Abstract
Credit card fraud on the Internet is a serious and growing issue. Many criminals have hacked into merchant databases to obtain cardholder details enabling them to conduct fake transactions or to sell the details in the digital underground economy. The card brands have set up a standard called PCI DSS to secure credit card details when they are stored online. We investigate the standard and find significant flaws especially in its requirements on small businesses. Finally, we propose some general rules for the secure management of online data. The initial version 1 of PCI DSS was set up in 2004 and updated to the current 1.1 standard [2] in 2006 by the main card brands in order to protect sensitive cardholder data stored online by merchants and other card processors. It followed on from the informal program started in 1999 by Visa and formalised in 2000 into the Cardholder Information Security Program [3]. It is designed to meet the problems of storing large amounts of credit card data stored online that may be compromised. The largest number of cards compromised so far is the TK Maxx case, where over 46 million cardholder details were stolen over a number of years [4]. The hackers used the common method of breaching insecure wireless networks from car parks outside the shops and installing malware to steal the card details. Many of the PCI DSS controls would have avoided or mitigated this attack. For example, networks must be protected from external intruders by adequate firewalls, and wireless networks must use a recent standard for protecting data such as WPA. Organisations are advised not to store card details for longer than necessary, and it is a violation of PCI DSS to store sensitive card details such as the 3-digit CVV or the complete magnetic stripe at all. Any organisation that transmits, stores or processes credit card data must be compliant with PCI DSS. This applies to organisations of any size and non-compliance can lead to loss of the ability to take credit cards, fines and liability for any losses from fraud. Organisational compliance must be proved with an annual assessment, whose completeness and rigour depends on the number and value of the transactions. It poses a special risk for small merchants who do not have specialist knowledge and rely on their providers. Many small businesses are not even aware of the PCI DSS standard and its mandatory requirements.

1

Introduction

There is a pressing need for better security of credit card transactions on the Internet as more and more people make purchases online, and we move to more secure payment mechanisms such as Chip and PIN in face-to-face transactions. In particular, the sensitive credit card details must be stored and processed securely by merchants. In general, people need to have faith that their personal information that was difficult to compromise when it was stored on paper will still be adequately protected when it is stored online. There are numerous issues for online storage because the large amounts of data are an inviting target for criminals and there are multiple ways of compromising it externally over a network or internally by insiders breaching the physical and procedural controls. We investigate the Payment Card Industry Data Security Standard [1] (hereafter abbreviated as PCI DSS) created by the credit card industry to protect sensitive credit card information when it is stored and processed online. This standard may suggest a way forward in the protection of other sensitive data held online such as medical records. However, it is arguable if PCI DSS deals with the right problems in the right way and some issues of secure online storage are inherently difficult.

2

The PCI DSS Requirements

The PCI DSS standard has 12 requirements within 6 groups [2]. It applies to any organisation such as merchants where credit card numbers are stored, processed or transmitted. The requirements apply

978-1-4244-2917-2/08/$25.00 ©2008 IEEE

838

to any system or component with access to the cardholder data including secondary systems and applications connected over a network as well as the primary storage and processing computers. The PCI DSS is not comprehensive and is supported by other standards to deal with card readers and payment software applications. We first give a high-level overview of the standard before appraising each requirement in turn. There is no clear overview of PCI DSS stating its objectives precisely. Without a proper set of goals and a threat model for adversaries that can impede the requirements, the resulting controls are likely to be incomplete and inadequate. It is a document to be read, understood and acted upon by business people, but it clearly fails to meet this crucial requirement. The main goal is to protect the sensitive cardholder data and all other requirements are subordinate and support this primary goal. The best method to achieve this goal is not to store the cardholder data persistently after the end of the transaction, but it may not be possible. We assume that there is some valid business requirement for storing the cardholder data in the rest of the paper. The numerous controls proposed by the standard may interfere with efficient management of the organisation. By focussing on the primary goal of protective sensitive cardholder data, we may discover that simpler and more trustworthy procedures can achieve the goal with less disruption to the business. We shall see that there is an inordinate focus in the standard on technical controls, whereas procedural and physical controls may be simpler and give higher assurance. There are some requirements covered by existing regulations such as EMV [5]. Merchants are allowed to store the cardholder’s name, PAN and expiry date. They are not allowed to store the complete data on the magnetic stripe still used in many face-to-face transactions at point-of-sale (POS) terminals, or the 3-4 digit card validation code (CVC) or value (CVV) used in card-notpresent (CNP) transactions on the Internet. These are used for authentication and if compromised can result in unauthorised credit card transactions.

sense of security and possibly interfere with other business activities. Arguably, there should be no network access to stored cardholder data from other computers within the organisation as any logical protection such as provided by firewalls may be defeated. The most secure architecture isolates machines handling the sensitive data on their own secure wired network housed in secure physical areas, which only perform tasks related to managing cardholder data. For a small business, a single isolated computer may suffice for managing the cardholder data. This renders moot the compromise of the rest of the organisational network that is difficult to secure because it would be running multiple applications with many bugs and insecure features. The sensitive machines should not have a wireless adaptor, as insiders may be able to access it surreptitiously over a wireless link. Do not use vendor-supplied defaults. The second requirement is not to use vendor-supplied defaults for system passwords and other security parameters. They also suggest using checklists such as from NIST [6] to remove unnecessary functionality. The suggestion is valid for the systems holding cardholder data, but would be time-consuming and expensive for all the computers in the organisation. It is often unrealistic to disable every apparently unused service or protocol, as it may in fact be used in support of an important service, and make the system unusable, unstable and difficult to fix.

2.2

Protect Cardholder Data

2.1

Build and Maintain a Secure Network

Install and maintain a firewall. The first requirement is to install and maintain a firewall configuration to protect cardholder data. It suggests network controls such as perimeter and personal firewalls to protect the other computers in the organisation, as they form indirect paths of attack on the systems that hold the cardholder data. PCI DSS proposes detailed sets of controls for other organisational networks connected to the sensitive machines that are liable to give a false

Protect stored cardholder data. The third requirement is to protect stored cardholder data. It suggests a large number of controls on the use of the cryptographic keys that encrypt sensitive cardholder data that cannot plausibly be carried out by small businesses. More attention should be given to storing the data on physically secured machines backed up by simple cryptographic protection of the cardholder data and considering not storing it at all unless essential. Some old systems automatically store the entire card details in breach of the regulations. Some small businesses such as Lodi Beer have been fined [7], even though the systems were provided by third parties that are in a better position to ensure their own systems meet the PCI DSS regulations. Encrypt transmission of cardholder data over networks. The fourth requirement is to encrypt transmission of cardholder data across open, public networks. Wired networks such as Ethernet should be used, as wireless is too risky given the possibility of access from outside the secure physical area.

839

2.3

Maintain a Vulnerability Management Program

Use and regularly update anti-virus software. The fifth requirement is to use and regularly update anti-virus software. It fails to mention the need to detect and remove other types of malware such as spyware, which needs its own special anti-spyware tool, which can also detect software keyloggers among other things. Develop and maintain secure systems and applications. The sixth requirement is to develop and maintain secure systems and applications. Most merchants rely on third parties for their systems so the requirement is not applicable. Trust must instead be placed in reputable suppliers, but this is problematic as merchants may be held accountable for the insecurity of their suppliers’ systems as shown in the Lodi Beer case above [7]. This section also claims that all patches should be checked before use, but this is unrealistic for many merchants. Most companies get their updates automatically using Microsoft Update [8] and other similar services, as a manual process is intractable when handling numerous machines and many organisation cannot afford separate test machines. The few machines handling the sensitive data can be treated differently with patches checked before deployment, as it is crucial they remain secure.

2.4

Implement Strong Access Control Measures

Restrict physical access to cardholder data. The ninth requirement is to restrict physical access to cardholder data. It discusses access by unauthorised individuals, but fails to properly consider authorised users operating in unauthorised ways. The standard suggests using video cameras in sensitive areas, but they may not work, can be disabled by insiders, and it assumes they are carefully monitored. It treats temps and consultants as regular employees, but they may not be as loyal and trustworthy, so should have fewer rights and undergo more extensive checks. Maintenance workers such as cleaners can attach hardware keyloggers and come back next day. We are certain to see an increasing problem of organised crime placing people with false identities in organisations as the value of credit card data is so high. Many of the proposed access controls are irrelevant against attacks by organised crime, as they do not care if they are detected. Storing backups offsite in a secure facility is required by PCI DSS, but again the employees at that location can access the backup, which may include the cardholder data. This indicates the need to encrypt or sanitise cardholder data first. The standard suggests sending media containing sensitive data by secure courier, but this is hardly acceptable and additional controls such as encryption are always necessary. Destroying media such as hard disks is not realistic for small companies and should be carried out by specialist organisations, but some of their employees may not be honest.

2.5

Restrict access to cardholder data by need-toknow. The seventh requirement is to restrict access to cardholder data by business need-toknow. Restricting access is the goal and should be the title of this group of controls (2.4) rather than a subsidiary requirement. The individual requirements would then be the various methods of restricting access. Assign a unique ID to each person. The eighth requirement is to assign a unique ID to each person with computer access and use authentication such as a password, token or biometric. It does not distinguish adequately between passwords that are considered a weak method of authentication [9] and the other methods that are possibly stronger. Physical attacks are possible to circumvent these logical controls and are once again overlooked. Passwords are easily defeated by insiders using multiple methods such as discovering passwords when they are written down, observed by shoulder surfing and installing keyloggers, and they can also be eavesdropped if they are used over a network.

Regularly Monitor and Test Networks

Track and monitor access to network resources and cardholder data. The tenth requirement is to track and monitor all access to network resources and cardholder data. Auditing and logging are obviously important, but they occur after the event and the loss of cardholder data is often permanent even when detected. The checks can be avoided especially by trusted insiders such as administrators that may avoid auditing altogether or change the logs afterwards. Employees can easily acquire passwords and steal or borrow authentication tokens to pass responsibility to an innocent victim. The fraudster may not care if they are detected after they have left especially if they assumed a false identity. Many of the controls proposed are unrealistic for smaller companies, who do not have access to specialist security advice and the money and time to install all the controls suggested. Regularly test security systems and processes. The eleventh requirement is to regularly test security systems and processes using vulnerability scans, penetration testing, intrusion detection

840

systems and file monitoring tools among other things. This is a completely unrealistic requirement for many merchants such as small businesses.

2.6

Maintain an Information Security Policy

The last requirement is to maintain a policy that addresses information security. It states correctly that the policy needs to be disseminated to all employees to let them know what is expected of them. What is omitted is that many security policies are very lengthy, written in legalese and therefore never read or followed by anyone. Many policy documents also present an unrealistic idealised view of work processes. The policy needs to be stated in clear and simple terms that can be understood and is relevant for every employee. It should demonstrate a business need for each policy requirement so that the employee is less motivated to breach policy to save time. The consequences of failure for the employee should be spelt out as well as the general repercussions for the company. Some employees will only change their behaviour by effective warnings and discipline, so the policies need to be consistently enforced including on management. The standard prohibits the transfer of cardholder data onto employees’ workstations or external media, but this is unenforceable and needs to be backed up by technical controls. This can be achieved by physical isolation of the machines with the cardholder data from employees that do not need access. Use of the machines should be limited by controlling the use of USB ports and CD/DVD recorders. Stealing thousands of cardholder details would take seconds using a USB memory stick. These controls also limit phishing attacks as well if the employee cannot access the requested information. It mentions background checks before people are employed, but it does not mention subsequent checks, or monitoring for suspicious or unusual behaviour. Organisations should attempt to improve motivation and encourage loyalty by good pay and an interesting working environment, which should reduce fraud.

may be able to piece together enough to get the complete cardholder details. For example, by phoning the customer and demonstrating they have some of their details, they can then ask the customer to prove who they are by giving the sensitive cardholder details. The liability for fraud still lies with the merchant irrespective of any contract (although they may be able to pass on any loss or fine to the third party), and they may also suffer consequential damage such as loss of reputation. Customers will leave in droves if there are persistent data breaches [10], and they are not too concerned if the ultimate responsibility is with a third party.

3

Issues for merchants using PCI DSS

2.7

Further requirements on outsourcers

It is common to outsource administrative tasks such as answering questions and other clerical tasks such as printing bills to external organisations. They may employ numerous temps whose backgrounds are not properly checked, and compliance may be inadequate so breaches of cardholder data could be straightforward. A crooked employee may not have access to all of a customer’s details but they

We discuss the issues for merchants using PCI DSS, which is a complex and poorly understood standard. The card issuers used their economic power to design PCI DSS with a view to dump liability onto other organisations such as merchants. This is known as moral hazard [11 pp823-4], which avoids the need for the originator of a problem to take sufficient care because third parties have to deal with the consequences. An established legal principle is that problems should be handled by the subject that is best able to deal with them [12]. For example, cardholder authentication could always be carried out by the card issuer, which avoids altogether the need for the merchant to store credit card details. The costs of PCI DSS are pushed onto the merchants, which will then be passed to its customers. Merchants will continue to accept credit cards if their customers demand to use them, which seems certain unless alternative payment methods are developed. Insisting that all merchants meet challenging cardholder data protection requirements does not solve the problem, as many merchants will not be able to comply. Small merchants may have inordinate costs to comply with PCI DSS relative to the level of threat and the benefit of taking credit cards. Compliance with a standard makes people feel better, but it can become reduced to an exercise in ticking boxes without proper thought of the issues. The standard deals with some issues in the wrong way by proposing excessively complicated technical controls. In contrast, there is a lack of detail about organisational controls to deal with employees acting maliciously or inadvertently. It hardly considers that the most trusted staff such as management or security administrators that can cause the most damage may be crooked. Insiders account for most instances of fraud [13] and phishing and other social engineering attacks are on the rise. ‘Only amateur attack machines: professionals target people’ (Bruce Schneier) [14].

841

Auditing is obviously important, but it can be bypassed by anyone with physical access to the system. It does not deter organised criminals, or a dissatisfied employee with a grudge against the company. Companies must look after their staff to ensure they are highly motivated and loyal. There is always the change that criminals will find and exploit weaknesses in the system if they are highly motivated, so the risks are high because of the value of compromising large numbers of cards. Many activities may be outsourced for efficiency to third parties who may pay less attention to the protection of the sensitive data. These organisations must be efficient because they work on very small margins, which may allow breaches in their policies. Contracts with outsourcers do not avoid liability for fraud in their primary contract with the card issuer, and there are possible consequential issues such as loss of reputation. Trust is slowly gained, but easily lost.

4

Conclusions

We conclude by determining some general rules for the management of sensitive online information. We need stronger regulations backed up by enforceable laws for the protection of sensitive personal data. Regulations must deal with the problem of moral hazard, where the value of the privacy of personal data is not highly rated by the most powerful players such as governments and large organisations. The regulations may need to be backed up by strong enforceable legislation for organisations to take data breaches seriously. Some states in the US such as California [15] hold organisations accountable for breaches of personal data requiring them to write to customers explaining what happened and maybe having to offer compensation. Even so, it is doubtful if victims will be compensated fully for the loss of personal data, which may be intangible such as hurt feelings from the loss of medical records, or include other factors such as the time and inconvenience of recovering from identity fraud. We propose that the minimum amount of data should be stored to meet strictly defined business requirements. There is little incentive to reduce the amount of stored information as it does not meet a business goal and costs money. On the contrary, retaining information in case it is ever needed again can help organisations be more efficient, and information used for one purpose can be subsequently used for another. The availability and malleability of information is also its weakness allowing its use for other business purposes not envisaged or agreed by the subject, or stolen and used for criminal activities. There would be an incentive to reduce the quantity and increase the protection of personal data if there was a cost for each data breach. Revenue and Customs in the UK

lost 25 million personal records when that were sent through the post on 2 CDs [16]. If they were under strict liability and had to pay £100 for every record compromised, their data controls may not have been so lax. Regulations should however be crafted to the particular need and not be excessive as they may unnecessarily increase bureaucracy and thereby reduce efficiency and profitability. For example, the passing of laws to control the activities of publicly traded companies in the US such as Sarbanes-Oxley (SOX) [11 p320-1] in the wake of the Enron and WorldCom scandals may have been excessive. It has been estimated that the cost of compliance with SOX may be as much as $1.4 trillion [17] and has led to many companies moving abroad to other financial centres such as London. Any controls will eventually be compromised if the rewards are high enough. Many regulations such as PCI DSS focus on technical controls, which may give a false sense of security, as they can always be defeated especially by insiders. We suggest using controls at many layers and locations to provide defence-in-depth. Technical controls need to be supported by procedural and physical controls. There should be protection measures to separate sensitive systems from the rest of the organisation as well as protection from external threats. For example, the physical separation of systems that store sensitive data in secure areas without network connection to the rest of the organisation would be more secure than logical partitioning mechanisms such as firewalls. Insiders pose the biggest risk to organisations, especially trusted insiders as they can evade the controls and cause the most damage. Problems are more likely to arise when staff are poorly motivated, which could be improved by good pay and work conditions. The trusted employees check and control the activities of the other employees, but trusted employees themselves need control, which unfortunately is likely to be easily breached. Employees are also a potential weakness if they are not trained properly. For example, phishing and other social engineering attacks are becoming more widespread as computer systems become more secure. There should be proper background checks for employees. For example, employees of companies working airside at airports are background checked for criminal convictions and other undesirable behaviour for obvious reasons. However, not all of these checks can be completed, because some other countries do not provide criminal records for their citizens. There was the case of the Afghan national working at Heathrow who had previously been convicted of aircraft hijacking. People should only be accepted if there is sufficient information about their good character rather than the lack of negative

842

information as the checks may be incomplete as above or abused by using a false identity.

5

References

[1] PCI Security Standards Council, “Welcome to the PCI Security Standards Council” at https://www.pcisecuritystandards.org. [2] PCI Security Standards Council, “Payment Card Industry Data Security Standard” at https://www.pcisecuritystandards.org/security_standards. [3] VISA, “Visa USA Cardholder Information Security Program (CISP) Overview”, at usa.visa.com/download/merchants/cisp_overview.pdf. [4] BBC, “Q&A: TK Maxx credit card fraud” 30 March 2007 at http://news.bbc.co.uk/1/hi/business/6509993.stm. [5] EMV, “EMV Specifications” at www.emvco.com/specifications.cfm. [6] NIST, “NIST checklist program” at http://csrc.nist.gov/pcig/cig.html. [7] Wall Street Journal, “In data leaks, culprits often are mom, pop”, 22 Sept 2007. [8] Microsoft, “Microsoft Update FAQ” at www.update.microsoft.com/microsoftupdate. [9] Alfred J Menezes, Paul C van Oorschot and Scott A Vanstone, “Handbook of applied cryptography”, CRC Press, 1996. [10] L Wood, “Security feed” in CSO, 20 April 2007 at www2.csoonline.com. [11] Ross Anderson, “Security Engineering”, Wiley, 2008. [12] RJ Mann, “Payment systems and other financial transactions (3rd ed)”, Aspen Publishers, 2006. [13] DTI, “2008 Information Security Breaches Survey”, BERR, 2008. [14] B Schneier, “Secrets and Lies”, Wiley, 2000. [15] FindLaw, “California Raises the Bar on Data Security and Privacy” at http://library.findlaw.com/2003/Sep/30/133060.html. [16] BBC, “UK's families put on fraud alert”,20 Nov 2007. [17] The Economist, “A price worth paying”, 19 May 2005.

843