Wednesday, July 31, 2013

We still fail at log analysis

Recently I've been working a couple of data analysis projects, and writing  
some software in support of that. Much of it has direct application to 
automated log analysis, alerting, and decision-support. While I am still tweaking, 
I have been pleased with those results.

Which is a Good Thing, because we need to be lot better at it than the data 
suggests we currently are. Good data are scarce, but the Verizon Data Breach 
Reports do provide some. Exactly what is reported each year, and the format 
in which it is reported changes each year. To some extent it has to; the 
landscape changes rapidly.

Back in 2010

  • 86% of victims had evidence of the breach in their log files
  • 3% of breaches were discovered by log analysis or review
  • 4% were detected by the combination of event monitoring and log analysis (This is a drop from the 6% of 2009)
  • 30% were in compliance with PCI Requirement 10: "Track and monitor all access to network resources and cardholder data." A better number than the abysmal 5% in 2009

Fast forward to the report for 2012 (published in 2013), where the data 
are again presented in a slightly different way. Overall, detection via logs was 
1%, broken into undefined Small (nothing reported), Large (4%), and Overall (1%).

There was no figure for how many victims had evidence of the breach in their logs, 
but there is no reason to believe it is substantially different than the 86% 
reported in 2010. So it would appear that there is significant room for 
improvement in log analysis.

I think we can all agree that the worst-case scenario is to not only suffer a 
breach, but to have it discovered by an external party. Anyone doing incident 
response is (or should be) aware that the clock is ticking. If it's public, 
there could be a lot of people watching it tick.

Perhaps it's time to look at your log analysis systems again, including a check 
to ensure that the system is inclusive enough. It's common for organizations to 
not even know where all the logs are. The problems can be as varied as that 
they're being written by unfamiliar or misconfigured software, or systems 
being installed incorrectly or surreptitiously. 

If any of that is found, the problems are obviously more extensive than just logs.

No comments:

Post a Comment

Thanks for your comment; communities are not built without you.

But note than comments on older posts usually go into a modertion queue. It keeps out a lot of blog spam. Weird links to Web sites hosting malware, marketing nonsense, etc.

I really want to be quick about approving comments in the moderation queue. When I think I won't manage that, I will turn moderation off, and sweep up the mess as soon as possible.

If you find comments that look like blog spam, they likely are. As always, be careful of what you click on. I may have had moderation off, and not yet swept up the mess.