| Logs, logs, logs. Ever since I started taking my first steps in the world of security, it has been clear that “the log” plays a crucial—and sometimes undervalued— role in the security management of any IT infrastructure.This fact alone explains the plethora of tools, applications, and solutions whose only purpose is to generate, analyze, and report on logs. Entire software companies were built on nothing but a few valid ideas on how to analyze logs or how to process and aggregate information coming from different logs. I myself spent a great deal of time in this field while developing the Microsoft Log Parser tool to tackle some of these problems.
Despite the proliferation of log-generating, processing, and reporting tools, and partially because of it, however, obtaining something useful from “the log” is still a somewhat obscure, complicated, and confusing wizardry, caused by, I believe, the fact that computers are still far from being as smart as we wish they’d be.Wouldn’t it be nice if your security sensors told you immediately what’s going on as an event was happening, rather than generate a huge log of seemingly worthless data? Wouldn’t it be wonderful if you could instruct your Web servers to show you a trend related to a variable over the past 10 weeks rather than have to retrieve, correlate, and aggregate gigabytes and gigabytes of log files?
Unfortunately, that’s not the case—yet—with the current state of software engineering. Most of the time, the developer of an IDS can’t come up—rightfully so—with a list of all the possible questions you might want to ask the IDS in the future, so the solution is simple: let’s log everything, and when users come up with new questions, they can go back to the archive and ask the question directly to “the log.”This is especially true in the world of security, where in most cases a single “event” can not be deemed of security importance unless correlated with other “events” occurring at other key places in your network. |