Database Security 3.0

PCI 2.0: Secure Cardholder *Data*

As we brace ourselves for the release of PCI 1.2 (see a TechTarget story here and a Rothman blog entry here) it is as good a time as any to think about how PCI could be improved. 

I bet a lot of you have mixed feelings about PCI just like I do. Don't get me wrong -- there is a lot to like about PCI.  The standard is desperately needed, its motives are noble, and it is one of the most prescriptive security standards out there (even accounting for the compensating controls black hole). In contrast to other security standards, most of PCI’s dirty dozen requirements make it pretty clear what you need to do. But looking back it is clear that in an attempt to be holisitic - offering a fairly complete set of security best practices - PCI started out bloated and has gone downhill from there. Over time, new requirements have been tacked on to address emerging security threats, like wireless and Web applications.  If that weren't bad enough, legacy requirements have gotten more complicated to address new permutations.  

 

PCI has lost its way. The combination of bloat with ample room for interpretation by assessors has weakened the standard’s effectiveness and frustrated the merchants and financial institutions that are critical to its success. A continuation of these trends – further expanded scope and continued room for interpretation – is not likely to yield rapid improvement in cardholder data security. 

 

To solve this problem as we look toward PCI 2.0, I propose we get back to our roots and focus on what the standard is all about. After all, unlike broad standards such as COBIT 27001, PCI is relatively bounded. It’s all about card holder data. It’s not about rock-solid wireless security or next-generation host security. It’s not about vulnerability-free application development or holistic security management. As an industry we have run ourselves ragged trying to secure all the conduits to the data: PCs, wired networks, wireless networks, web applications, etc. And from a cardholder data security perspective, let’s face it – it hasn’t worked. More of the same, can’t be the answer. 

 

So, for PCI 2.0 I propose that rather than adding a 13^th requirement we bring it down to one (maybe with a few subheads ;-). Secure cardholder data where it lives: in the database. The solution is certainly broader than database security. And since I work at a database security vendor, I’m certainly biased as could be. But bear with me... 

 

Let’s say Retailer X has done a solid job securing the databases that house cardholder data. They regularly scan for databases with credit card numbers in them and test those databases for misconfigurations and known security vulnerabilities. While it’s impossible to keep them all up to current patch levels, they generally stick to their policy of within a few patch levels of current. As a result, the attack surface is well managed, bad guys don’t have a lot to hold on to.  Better still, the regular scan reports document their hard work and compliance with the standard while also allowing them to demonstrate continuous improvement to management and auditors.  Next, they monitor the activity on these databases. Not only does this help them flag insider misuse and abuse (ex. the admin trying to run off with all the credit card numbers), but tied to their scanning process it allows them to intelligently monitor those databases they haven’t yet been able to patch. And finally, they are encrypting credit card data in those databases to the greatest degree possible. 

In short, thanks to vulnerability assessment they’ve locked down those databases pretty tight to manage the risk of a breach and document that their stated controls are in place (here are your reports Mr. PCI auditor :-).  Thanks to monitoring, in the event of an attempted breach they are likely to know prior to major data loss during early reconnaisance (ex. an attempted exploit by an outsider or an insider grabbing a couple numbers to test if they're valid). Though not full-proof, encryption provides a great fail safe: if all else fails the data is unusuable. 

 

In this scenario, and relative to protecting cardholder data, why do they need a firewall? Anti-virus? Web application firewalls? Wireless security? They don’t. With a solid data security strategy rooted in database security best practices, all of those other security measures could be compromised and the data would still likely be safe.

Database Security Hits Home – I’m a Statistic, Pt. 1

View this photo

Posted by Ted Julian

Given what I do all day, thisis pretty ironic.  Today I got a letter in the mail that said, “your account number may have been illegally obtained as a result of a merchant database compromise and could be at risk for unauthorized use...” 

I’ll post more on this later.  But for now, a note to merchants, banks, processors, etc. – please secure your databases!

PCI - Let's Put the Data Back In the Data Security Standard

Submitted by Ted Julian

I have a feeling a lot of you have mixed feelings about PCI just like I do.  On the one hand, the standard’s motives are noble and it’s one of the most prescriptive security standards out there.  With most of PCI’s dirty dozen requirements, it’s pretty clear what you need to do.  But on the other hand, PCI has gotten both broader and deeper over time as it has added new requirements around things like wireless and Web applications, while adding additional detail to legacy requirements.  Meanwhile compensating controls remain ill-defined and largely up to the whim of assessors.

I believe that PCI has lost its way.  The combination of bloat with ample room for interpretation by assessors has weakened the standard’s effectiveness and frustrated the merchants and financial institutions that are critical to its success.  A continuation of these trends – further expanded scope and continued room for interpretation – is not likely to yield rapid improvement in cardholder data security.

 

It doesn’t need to be this way.  As we look toward PCI 2.0, I propose we get back to our roots and focus on what the standard is all about.  After all, unlike broad standards such as COBIT 27001, PCI is relatively bounded.  It’s all about card holder data.  It’s not about rock-solid wireless security or next-generation host security.  It’s not about vulnerability-free application development or holistic security management.  As an industry we have run ourselves ragged trying to secure all the conduits to the data: PCs, wired networks, wireless networks, web applications, etc.  And from a cardholder data security perspective, let’s face it – it hasn’t worked.  More of the same, can’t be the answer.

 

So, for PCI 2.0 I propose that rather than adding a 13 th requirement we bring it down to one (maybe with a few subheads).   Secure cardholder data where it lives. The solution is certainly broader than database security.  And since I work at a database security vendor, I’m certainly biased as could be.  But bear with me – using it as an example helps illustrate an important point.

 

Let’s say Retailer X has done a solid job securing the databases that house cardholder data.  They regularly scan for databases with credit card numbers in them and test those databases for misconfigurations and known security vulnerabilities.  While it’s impossible to keep them all up to current patch levels, they generally stick to their policy of within two patch levels of current.  As a result, the attack surface is well managed, bad guys don’t have a lot to hold on to, and better still, the regular scan reports document their hard work and allow them to demonstrate continuous improvement.  Second, they monitor the activity on these databases.  Not only does this help them flag insider misuse and abuse (ex. the admin trying to run off with all the credit card numbers), but tied to their scanning process it allows them to intelligently monitor those databases they haven’t yet been able to patch.  And finally, they are encrypting the credit card column in those databases to the degree possible.  In short, they’ve locked down those databases pretty tight and in the event of a breach they are likely to know immediately and the bad guys won’t likely get the goods – the data’s encrypted.

In this scenario, and relative to protecting cardholder data, why do they need a firewall?  Anti-virus?  Web application firewalls?  Wireless security?  They don’t.  With a solid data security strategy rooted in database security best practices, all of those other security measures could be compromised (or not even exist) and the data would still likely be safe.