Avoiding TJX-Sized Breach Takes More than Compliance

Lora Bentley

We'd imagine the recent data breach at TJX, which jeopardized the personal data of thousands of credit card holders, caused many companies to double or at least refocus their compliance efforts with regard to regulations like Sarbanes-Oxley, the Health Insurance Portability and Accountability Act and -- more specifically -- the PCI Data Security Standard.


However, as this Dark Reading piece points out, compliance with the PCI DSS won't be enough to protect many businesses from disasters like the TJX debacle. PCI compliance, after all, doesn't ensure that data breaches will be detected in a timely manner. So even though PCI and Sarbox compliance are good places to start, that's all they are when it comes to data breaches.


To avoid being "the next TJX on the block," the writer recommends taking such steps as keeping sensitive data in one place with virtualization, going the proverbial "second mile" with PCI compliance requirements, archiving your audit data for five years, and clearing endpoints of sensitive data after each SSL session.

Add Comment      Leave a comment on this blog post
Apr 10, 2007 2:08 AM datasecurity datasecurity  says:
We have posted a reply to the Dark Reading post:http://pcianswers.com/2007/04/09/pci-wont-save-you/ Reply
Apr 20, 2007 1:36 AM sanjeev mathur sanjeev mathur  says:
Entreprise DRM is the right solution for these incidents. It calls for persistent protection of data. Perimetric security helps in certain areas of data flow, EDRM is a mechanism which protects data in repositort / transition and even when stored some one else PC. Reply
Apr 20, 2007 4:30 AM Tim Holman Tim Holman  says:
I strongly disagree. If TJX were PCI Compliant when the compromise was attempted, then it would not have been successful.Word on the street is that several controls were not in place at the time of compromise.It's completely misleading to say that PCI Compliance isn't enough to protect businesses from compromise, but in reality, it DOES. Take for example a well known case where a root kit was installed on a server, and used to regularly harvest credit card data. If the credit card data was encrypted (control 3.4) and subject to secure key management (3.5,3.6), then all the hacker would have retrieved would have been garbage. Take also controls surrounding central event management/reporting and system integrity (section 10). It's hard (although not impossible) to defeat these and install a rootkit in the first place.Then take section 11.4 - which involves IDS/IPS. If an IDS/IPS was in place, there's a good chance rootkit behaviour can be identifide.Last but not least, if proper network segmentation was in place and firewalls / processes configured to report and detect suspicious behaviour (for example repeated access from the outside, or reverse access from the inside), then this would have been quickly identified and stamped out. Reply

Post a comment





(Maximum characters: 1200). You have 1200 characters left.




Subscribe to our Newsletters

Sign up now and get the best business technology insights direct to your inbox.