Prat Moghe is SVP Strategy and New Markets, and General Manager for the Data Compliance division at Netezza
Matt Benati is Director of Marketing for the Data Compliance Division of Netezza.
Current Articles | RSS Feed
Certegy has just announced that its data theft by an internal DBA was much worse than they thought. Apparently 8 million records were compromised, instead of 2.2 million as believed earlier. This led me to revisit the incident and its interesting implications around forensics. There are two observations worth noting around the Certegy data theft. The first observation is well-known: traditional security tools did not detect the data theft when it happened. The second one is not as obvious: after data theft was suspected, forensics could not prove this theft. This is an important implication that all incident investigators need to understand about data breaches. As many data breaches happen at the "database-level", traditional forensics tools that focus on PC or outbound electronic channels (emails etc.) may not capture evidence of the breach.
To understand the Certegy incident, check two sources out:
Forensics did not identify or prove the root-cause of the breach. In fact, after FIS/Certegy was alerted by customers of a potential breach, they used forensics focused on firewall activity. Naturally, they didn’t detect any external breaches. This absence of firewall activity pointed to the possibility of an internal breach. However, forensics could not prove this conclusively nor identify where the breach occurred. A separate "non-electronic" investigation proved the linkage between an internal DBA and the theft. As it turns out, all of the check-paying customers were receiving communication from one company, which happened to be the company started by a Certegy employee - the malicious DBA. Were it not for this direct linkage, the root cause may have never been found.
How to bridge the "forensic gap"
If Certegy had used database auditing, they could have had access to "non-repudiable" database access logs. This could have directly identified and proved that the DBA’s hand was in the cookie jar. In fact, with the combination of auditing and analytics, such tools could proactively alert. For example, the moment the DBA accessed more than X customer names in a transaction or over time, an alarm could have been tripped. In my conversations with enterprises I have learned that the focus of data loss prevention is moving rapidly to the core databases. The forensics gap is critical and must be addressed.
Allowed tags: <a> link, <b> bold, <i> italics