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

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
COVID-19: Latest Security News & Commentary
Dark Reading Staff 11/19/2020
New Proposed DNS Security Features Released
Kelly Jackson Higgins, Executive Editor at Dark Reading,  11/19/2020
How to Identify Cobalt Strike on Your Network
Zohar Buber, Security Analyst,  11/18/2020
Register for Dark Reading Newsletters
White Papers
Cartoon Contest
Write a Caption, Win an Amazon Gift Card! Click Here
Latest Comment: This comment is waiting for review by our moderators.
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2020-11-24
499ES EtherNet/IP (ENIP) Adaptor Source Code is vulnerable to a stack-based buffer overflow, which may allow an attacker to send a specially crafted packet that may result in a denial-of-service condition or code execution.
PUBLISHED: 2020-11-24
An ACL bypass flaw was found in pacemaker before 1.1.24-rc1 and 2.0.5-rc2. An attacker having a local account on the cluster and in the haclient group could use IPC communication with various daemons directly to perform certain tasks that they would be prevented by ACLs from doing if they went throu...
PUBLISHED: 2020-11-24
Barco wePresent WiPG-1600W firmware includes a hardcoded API account and password that is discoverable by inspecting the firmware image. A malicious actor could use this password to access authenticated, administrative functions in the API. Affected Version(s):,,,
PUBLISHED: 2020-11-24
HRSALE 2.0.0 allows XSS via the admin/project/projects_calendar set_date parameter.
PUBLISHED: 2020-11-24
A flaw was discovered in WildFly before 21.0.0.Final where, Resource adapter logs plain text JMS password at warning level on connection error, inserting sensitive information in the log file.