Data Auditing Blog View Mantra V5

Photo: Prat Moghe
 

Prat Moghe was the founding CEO of Tizor and led the company from 2002 to 2006 including driving the launch of its product into the data auditing market. Prat led Tizor through two financing rounds and established its security and compliance market strategy.
Read More »

Subscribe By Email

Your email:

Keepers

Current Articles | RSS Feed RSS Feed

Top 4 PCI Data Issues & Lessons

 | Digg digg it | Reddit reddit | del.icio.us del.icio.us 
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.

 

Posted by Prat Moghe on Wed, Aug 29, 2007 @ 03:10 PM

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.