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.

Perimeter

4/6/2010
08:39 PM
Adrian Lane
Adrian Lane
Commentary
50%
50%

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
Comments
Newest First  |  Oldest First  |  Threaded View
Data Leak Week: Billions of Sensitive Files Exposed Online
Kelly Jackson Higgins, Executive Editor at Dark Reading,  12/10/2019
Intel Issues Fix for 'Plundervolt' SGX Flaw
Kelly Jackson Higgins, Executive Editor at Dark Reading,  12/11/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
The Year in Security: 2019
This Tech Digest provides a wrap up and overview of the year's top cybersecurity news stories. It was a year of new twists on old threats, with fears of another WannaCry-type worm and of a possible botnet army of Wi-Fi routers. But 2019 also underscored the risk of firmware and trusted security tools harboring dangerous holes that cybercriminals and nation-state hackers could readily abuse. Read more.
Flash Poll
Rethinking Enterprise Data Defense
Rethinking Enterprise Data Defense
Frustrated with recurring intrusions and breaches, cybersecurity professionals are questioning some of the industrys conventional wisdom. Heres a look at what theyre thinking about.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-5252
PUBLISHED: 2019-12-14
There is an improper authentication vulnerability in Huawei smartphones (Y9, Honor 8X, Honor 9 Lite, Honor 9i, Y6 Pro). The applock does not perform a sufficient authentication in a rare condition. Successful exploit could allow the attacker to use the application locked by applock in an instant.
CVE-2019-5235
PUBLISHED: 2019-12-14
Some Huawei smart phones have a null pointer dereference vulnerability. An attacker crafts specific packets and sends to the affected product to exploit this vulnerability. Successful exploitation may cause the affected phone to be abnormal.
CVE-2019-5264
PUBLISHED: 2019-12-13
There is an information disclosure vulnerability in certain Huawei smartphones (Mate 10;Mate 10 Pro;Honor V10;Changxiang 7S;P-smart;Changxiang 8 Plus;Y9 2018;Honor 9 Lite;Honor 9i;Mate 9). The software does not properly handle certain information of applications locked by applock in a rare condition...
CVE-2019-5277
PUBLISHED: 2019-12-13
Huawei CloudUSM-EUA V600R006C10;V600R019C00 have an information leak vulnerability. Due to improper configuration, the attacker may cause information leak by successful exploitation.
CVE-2019-5254
PUBLISHED: 2019-12-13
Certain Huawei products (AP2000;IPS Module;NGFW Module;NIP6300;NIP6600;NIP6800;S5700;SVN5600;SVN5800;SVN5800-C;SeMG9811;Secospace AntiDDoS8000;Secospace USG6300;Secospace USG6500;Secospace USG6600;USG6000V;eSpace U1981) have an out-of-bounds read vulnerability. An attacker who logs in to the board m...