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

 

Recommended Reading:

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
COVID-19: Latest Security News & Commentary
Dark Reading Staff 6/1/2020
Stay-at-Home Orders Coincide With Massive DNS Surge
Robert Lemos, Contributing Writer,  5/27/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: It's the latest version of antivirus.
Current Issue
How Cybersecurity Incident Response Programs Work (and Why Some Don't)
This Tech Digest takes a look at the vital role cybersecurity incident response (IR) plays in managing cyber-risk within organizations. Download the Tech Digest today to find out how well-planned IR programs can detect intrusions, contain breaches, and help an organization restore normal operations.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-13759
PUBLISHED: 2020-06-02
rust-vmm vm-memory before 0.1.1 and 0.2.x before 0.2.1 allows attackers to cause a denial of service (loss of IP networking) because read_obj and write_obj do not properly access memory. This affects aarch64 (with musl or glibc) and x86_64 (with musl).
CVE-2020-7662
PUBLISHED: 2020-06-02
websocket-extensions npm module prior to 1.0.4 allows Denial of Service (DoS) via Regex Backtracking. The extension parser may take quadratic time when parsing a header containing an unclosed string parameter value whose content is a repeating two-byte sequence of a backslash and some other characte...
CVE-2020-7663
PUBLISHED: 2020-06-02
websocket-extensions ruby module prior to 0.1.5 allows Denial of Service (DoS) via Regex Backtracking. The extension parser may take quadratic time when parsing a header containing an unclosed string parameter value whose content is a repeating two-byte sequence of a backslash and some other charact...
CVE-2020-12017
PUBLISHED: 2020-06-02
GE Grid Solutions Reason RT Clocks, RT430, RT431, and RT434, all firmware versions prior to 08A05. The device’s vulnerability in the web application could allow multiple unauthenticated attacks that could cause serious impact. The vulnerability may allow an unauthenticated attacke...
CVE-2018-18623
PUBLISHED: 2020-06-02
Grafana 5.3.1 has XSS via the "Dashboard > Text Panel" screen. NOTE: this issue exists because of an incomplete fix for CVE-2018-12099.