Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


08:39 PM
Adrian Lane
Adrian Lane

PCI Database Security Primer

I have written a lot about compliance in that past three months, but most of the guidance has been generic. Now I want to talk about database security specifically in relation to the Payment Card Industry (PCI) Data Security Standard, and consider compliance more from an architectural standpoint as opposed to a tools- or policy-based perspective.

I have written a lot about compliance in that past three months, but most of the guidance has been generic. Now I want to talk about database security specifically in relation to the Payment Card Industry (PCI) Data Security Standard, and consider compliance more from an architectural standpoint as opposed to a tools- or policy-based perspective.PCI is, at this time, the biggest motivator to fund data security projects. And to be totally up front, no sizable merchant or payment processor is going to store credit card and primary account number (PAN) data outside of a database. Database security to meet PCI may not be a primary discussion point in the standard, but it is a focal point of the security around the credit card data use and storage.

As a merchant trying to figure out how to comply with PCI for the first time, the learning curve always consists of four phases: trying to understand how the PCI-DSS standard applies to you, engaging security vendors to acquire missing security technologies, your first QSA engagement or audit, and then the realization you would have done things differently knowing what you know now.

Security product vendors know this, so each and every one of them provides a checklist showing how his firewall, assessment, encryption, or [fill in the blank] product covers the 12 PCI-DSS sections, with corresponding assurances of how easy it will be to get compliant with his predefined reports and policies.

Unfortunately it's never that easy, and this is the wrong approach to take. Understanding how to synchronize security tools and practices is one part of the learning curve, as is knowing how a PCI audit will be conducted and how your auditor interprets the standard. But this tactical formula to meeting the standard -- cobbling together technologies to meet each line item in PCI-DSS -- does not account for the strategic business processing model. The result is re-engineering the entire effort down the road to fix early mistakes.

I want to avoid too specific a focus on tools or even the individual DSS requirements, but instead consider two different architectural approaches to setting up a database for credit card data based on the data-processing requirements of the business. Solving PCI in a more top-down manner, you need to ask yourself the critical question, "Do I absolutely, positively need to stored credit card numbers to support my business?" The answer shapes your technology choices.

If you want to keep credit card numbers to use purely as a reference for transaction dispute resolution, data analysis, and customer identification and tracking, then you probably don't need the original credit card numbers at all. In this case I recommend tokenization of the credit card data through an outsourced service, typically provided by your payment processor. In this model you will receive a token in lieu of the credit card, which looks and acts like a real credit card number, but cannot be used fraudulently in any financial transaction.

If you need to keep credit card numbers as part of your internal business model -- for example, if your credit card processor requires you to do so to manage monthly payments -- then you will want to minimize the internal number of servers, applications, and users down to the minimum possible subset and use obfuscated data for every other purposed. Tokenization of credit card data through an external service will remove much of the associated risk of fraud and theft. By using a random token that looks like a credit card number to your database, changes to implement are minimal. You will need to make alterations to some applications to use the tokens, as well as alter some of the payment and dispute resolution processes. And you cannot totally get away from database security because you will still need to assess and audit the platform. Further, existing credit card numbers will need to be transitioned out of your systems through a data obsolescence plan. Regardless, moving forward you need to greatly reduce the scope of a PCI audit, complexity of security systems, and the associated costs of both.

In the next post I will examine the cases where credit card numbers cannot be completely replaced by tokens, and discuss a couple of different security strategies to reduce exposure of credit card numbers in order to comply with PCI-DSS.

Adrian Lane is an analyst/CTO with Securosis LLC, an independent security consulting practice. Special to Dark Reading. Adrian Lane is a Security Strategist and brings over 25 years of industry experience to the Securosis team, much of it at the executive level. Adrian specializes in database security, data security, and secure software development. With experience at Ingres, Oracle, and ... View Full Bio


Recommended Reading:

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
COVID-19: Latest Security News & Commentary
Dark Reading Staff 8/3/2020
Pen Testers Who Got Arrested Doing Their Jobs Tell All
Kelly Jackson Higgins, Executive Editor at Dark Reading,  8/5/2020
New 'Nanodegree' Program Provides Hands-On Cybersecurity Training
Nicole Ferraro, Contributing Writer,  8/3/2020
Register for Dark Reading Newsletters
White Papers
Cartoon Contest
Current Issue
Special Report: Computing's New Normal, a Dark Reading Perspective
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
The Changing Face of Threat Intelligence
The Changing Face of Threat Intelligence
This special report takes a look at how enterprises are using threat intelligence, as well as emerging best practices for integrating threat intel into security operations and incident response. Download it today!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2020-08-08
In JetBrains YouTrack before 2020.2.6881, the markdown parser could disclose hidden file existence.
PUBLISHED: 2020-08-08
In JetBrains YouTrack before 2020.2.6881, a user without permission is able to create an article draft.
PUBLISHED: 2020-08-08
JetBrains YouTrack before 2020.2.8873 is vulnerable to SSRF in the Workflow component.
PUBLISHED: 2020-08-08
In JetBrains Kotlin before 1.4.0, there is a script-cache privilege escalation vulnerability due to kotlin-main-kts cached scripts in the system temp directory, which is shared by all users by default.
PUBLISHED: 2020-08-08
In JetBrains TeamCity before 2020.1, users with the Modify Group permission can elevate other users' privileges.