Weaknesses in payment card data security practices present one of the top reasons why enterprises fail Payment Card Industry Data Security Standard (PCI DSS) assessments. Often prohibited data, such as CVV2 account security codes or personal identification numbers (PINs), is retained (which is strictly forbidden by PCI DSS) or primary account numbers (PANs) are stored without adequate safeguards. Compared to simpler -- which is not to say simple -- network security practices, PCI DSS standards for secure data storage present a challenging problem for many merchants.
It is a common misconception that PCI DSS is about payment data security; in reality, it is about reducing the risk of payment card transactions.
People not familiar with payment security often spout generalities -- like "use encryption" -- without thinking about the extreme complexity of a globally distributed payment environment. At the same time, QSAs report stories of discovering huge data dumps of unencrypted cardholder data stored right on a merchant's Web server, visible to the whole world.
In this tip, we share some tactical advice to help organizations simplify the assessment process by streamlining their data storage practices and reducing PCI DSS assessment scope.
First, it is a common misconception that PCI DSS is about payment data security; in reality, it is about reducing the risk of payment card transactions. The subtle difference here is that you actually can reduce the risk of transactions without implementing a complex data security lifecycle or purchasing expensive tools that come with extensive management overheads.
Thus the answer is often not to encrypt the data, but to delete the data. Visa recommends this very approach in its famous ongoing campaign: Drop the Data. In our book, The PCI DSS Compliance Book, Branden Williams and myself start the chapter on data security with: "Before we even start our discussion of data protection methods, we need to remind the reader that 'the only good data is dead data.' Humor aside, dropping, deleting, not storing and otherwise not touching the data is the best single trick to make your PCI DSS compliance easier, as well as to make the transaction less risky, reduce your liability, chance of fines and breach notification losses."
The logic behind data destruction is simple: Today's security technology is complex and often requires maintenance (such as daily log review or security monitoring), as well as use of inherently unreliable technologies (signature-based antivirus, which only catches a modest percentage of attacks). As a result, expending efforts to protect the data -- and still failing -- is an inferior strategy compared to making sure data does not enter the environment. Clearly, this does not work with company intellectual property (IP) and other secrets, but can be aimed for with payment data. After all, we all accept that banks are better equipped for storing large amounts of data and we don't store millions in our place of business. Similarly, not having the card data should become as obvious in the future.
But deleting data is only the beginning. Another key strategy to make your PCI DSS assessment go more smoothly is to reduce scope. Given that complexity of PCI assessments is directly proportionate to the scope -- the PCI term for the size of cardholder data environment and in turn the number of systems that must be included in an assessment -- reducing that scope has an immediate impact on the assessment process. Why? Having a QSA look at 10,000 systems in a cardholder environment, which can happen if an enterprise network is flat and cardholder data is not segmented from the rest of the network, vs. only 10 systems, makes a huge difference in the likelihood of success during an assessment.
So before the assessment -- be it via QSA on-site assessment or SAQ self-assessment -- I highly recommend the following approach:
- Estimate the scope of your PCI assessment by counting all systems that transmit, store or process cardholder data. As a reminder, even network devices that pass unencrypted card traffic are in scope; not just transaction servers and gateways.
- Try to predict where the unauthorized storage of cardholder data may take place in your organization. Common data storage locations that are often forgotten are developer environments or servers belonging to other business units, like the marketing department. Scope creep is indeed dangerous if every developer workstation becomes "in scope" due to using real card data for system testing (by the way, this practice is explicitly forbidden in PCI DSS).
- Next, with your scope and hand, rank the systems by the amount of sensitive data.
- Go down the list and try to understand how your business processes can be changed to avoid storing the data – or at least how to run a business by storing less of it. This is the most critical step; any data that can be deleted (or never stored in the first place) will serve to reduce scope and, in turn, make the assessment process easier.
- Then, look at the data that can't be deleted and check if you can store it for a shorter period. This reduces the risk of compromise against historical data.
- Consider using modern approaches to data protection, such as tokenization, which can help avoid storing the data in favor of a harmless token instead.
- Finally, examine the step-by-step payment process to determine whether any part of it can be outsourced to a secure payment provider; such a relationship can help reduce risk as well as PCI assessment scope. The reality is that information security will never be a core competency for most merchants. Thus, structuring a relationship with a service provider is simpler than analyzing applications for cross-site scripting or writing correlation rules for a security information and event management (SIEM) product.
Only after going through the above steps should you think about using various additional technical safeguards, such as strong access controls, encryption, etc., to protect the remaining data. It is likely that your environment will use a combination of strong access controls and data encryption. The encryption choices are: disk encryption, file encryption (for flat-file data storage) and database encryption (for databases of cardholder data). The latter can be further divided into multiple approaches to encrypt the records in a database.
A common maxim in information technology states, "encryption is easy, key management is hard." That is why the PCI DSS document dedicates so much space to key management. Specifically, Requirement 3.5 ("Protect cryptographic keys used for encryption of cardholder data against both disclosure and misuse") and 3.6 ("Fully document and implement all key-management processes and procedures for cryptographic keys used for encryption of cardholder data") focus primarily on this area. Both of these requirements have multiple sub requirements, such as 3.5.2 ("Store cryptographic keys securely in the fewest possible locations and forms") and 3.6.6 ("Split knowledge and establishment of dual control of cryptographic keys").
Be sure to also avoid common encryption mistakes, such as those mentioned in my related technical paper, "Five Mistakes of Encryption", such as storing encryption keys in the same database as the encrypted data, or using hard-coded fixed passwords embedded in program code.
While thinking of simplifying PCI assessment scope and reducing the risk to payment card transactions, focus first on eliminating the data and thus reducing the scope; safeguards and protections should come later.
Specifically, leave more complex security safeguards such as data encryption until the very latest time. While some people are concerned with outsourcing, for many merchants outsourcing to a secure payment provider gives assurance to the merchant and their customers that the data will be better protected from attackers. At the very least, investigate recent approaches for "killing the data" such as tokenization.
About the author:
Dr. Anton Chuvakin is a recognized security expert in the field of log management and PCI DSS compliance. He is an author of Security Warriorand PCI Compliance and a contributor to Know Your Enemy II, Information Security Management Handbook and others. In addition, Anton teaches classes and presents at many security conferences across the world; he recently addressed audiences in the United States, U.K., Singapore, Spain, Russia and other countries. He works on emerging security standards and serves on the advisory boards of several security start-ups.
This was first published in August 2010