Photo: Prat Moghe

Prat Moghe is the General Manager of the Data Compliance division of Netezza (NYSE: NZ). Previously, Prat was the Founder & CEO of Tizor, a data auditing company acquired by Netezza. 

Read More »

Subscribe By Email

Your email:

Keepers

Data Auditing Blog

Current Articles | RSS Feed RSS Feed

Top 4 PCI Data Issues & Lessons

 | Submit to Digg digg it | Submit to Reddit reddit | Add to delicious delicious | Submit to StumbleUpon StumbleUpon | Share on Facebook Facebook | Share on Twitter Twitter | Share on LinkedIn LinkedIn 
I’d like to take up another timely topic based on my enterprise visits and my work with the PCI SVA. Enterprises are starting or have initiated PCI projects around credit card security. There is a marked difference in these projects from a year ago – back then they were all focused on network-level vulnerability scanning, they are now beginning to focus on credit card data. I hear four common problems from the field around credit card data. Here they are, along with my summary recommendations.

  1. Where is the credit card data?: Can we discover data in my databases and fileservers? Early experience with crawlers seems disappointing with scalability and manageability problems.
  • Recommendation: Lightweight discovery is better than none. Make progress in steps – active discovery combined with selective deep crawling will give you the momentum to solve the messy data problem in stages.
  1. Audit logging of credit card data access: PCI 10 requires audit logging of access to credit card data – in addition to logging other system and network access. Do we need to do data-level auditing or is it sufficient to just network/system-level security logging?  If we log at the data-level, what should be the approach? Do we need to turn logging on within our databases and fileservers and re-direct these logs to our SIM? What should we be doing here?
  • Recommendation: Data-level logging is a must and may feel like a big overhead, but new technologies like data auditing or database auditing are here to make this task much easier and cost-effective.
  1. Database-level encryption: PCI 3 requires encryption at the database-level. Encrypting the database is not easy – particularly across different versions of the databases & platforms. We have heard about a compensating control for encryption. What is it? Does it help us get away from encryption?
  • Recommendation: Database-level encryption does indeed have data auditing as a substitute lightweight compensating control. This can ease your life if used correctly and in the right spirit. “Correctly” & “right spirit” are key words. Longer-term data auditing is a good complementary addition to encryption.
  1. Data Breach protection: If TJX was indeed PCI compliant how did the breach happen? Does PCI compliance protect us against a breach? If it does not, what should we be doing?
  • Recommendation: PCI compliance will help you protect against data breaches, but only if you seriously invest in PCI 10 analysis & alerting requirements around data access. Over 60% of data breach losses happen from core servers that keep critical data, but aren’t being monitored. So that’s a good place to monitor, analyze and alert.
In my next four posts, I will take up these problems one at a time and describe experiences and my recommendations in more detail. If you have a PCI problem around credit card data or have experiences to share, please email me or send me comments.

 
Tags: 

Comments

Currently, there are no comments. Be the first to post one!
Post Comment
Name
 *
Email
 *
Website (optional)
Comment
 *

Allowed tags: <a> link, <b> bold, <i> italics

Receive email when someone replies.