Blog: Errors of Ommission
Blog: Errors of Ommission
Submitted by Ted Ritter on Tue, 2008-07-08 11:17.Last month I listened to a briefing from Verizon Business (NYSE:VZ) where Dr. Peter Tippett and A. Bryan Sartin talked about their recent report on data breach analysis. Verizon analyzed over 500 forensic analyses of breaches from the past four years. We all know that 10’s of millions of records containing personally identifiable information (PII) have been breached in the past four years. In fact, the number is probably higher since a) these are only the ones that are reported and b) the ones that are never discovered are never counted.
What’s interesting about Verizon’s report is that the forensics - of the forensics -provides great insight into the breach process. In 82% of the cases Verizon found evidence of the breach in an IT log file. That’s great news! The bad news is that only 4% of the breaches were discovered based on a log file. So what does this mean? I can think of three things:
1)IT is not implementing tools to manage their logs so the breach artifact is being missed due to being a needle in a logstack.
2)IT is implementing log management tools and the tools are missing the relevant events.
3)IT is implementing tools that are catching the events but the operators are either not programming the tools correctly or the breach alerts are being drowned out by other alerts.
We know from our own research that 64% of participants in Nemertes’ Security and Information Protection benchmark are collecting logs, yet only one-quarter are implementing a security information and event management (SIEM) tool for sophisticated log analysis. We also know that SIEM tools are notoriously difficult to manage and tune. I asked Verizon for some clarification and they consider this log management dynamic to be an “act of omission:” the policies are in-place to manage logs, the tools may also be in-place but for whatever reason the process is broken or not being followed.
The bottom-line is that the smoking gun is clearly in the log files. What’s required is either a tool that is intelligent enough to interpret and detect a breach – and sound the alarm – and/or a tool that is intuitive enough for an operator to filter and search through the mountains of logs to pull out a possible breach artifact.


Post new comment