Natural Flow of Log Management

I just came back from visiting some of our customers and then did a bit of thinking of what logs people tend to deal with first (and why). It would sound obvious for some, but possibly insightful to others. While we often say that you need to look at all the logs, often real-life limitations interfere

So, even a few years ago, any firewall or network admin worth his salt would look  at least at a simple summary of connections that his baby PIX or Checkpoint is logging. Indeed, firewall log analysis represented a lot of early business for log management vendors. Many firewalls log in standard syslog format and such logs are easy to collect and review.

Reviewing network IDS logs (for those companies that chose to deploy this technology), while unduly exciting in case of an incident, is often a very frustrating task since NIDSs would sometimes, you know, "lie" to you by recording "false positives." Still, NIDS log analysis, at least the post-mortem kind, often comes second after firewalls since the value of such info for security is undeniable and logs can, in most cases, be easily centralized for analysis.

Even though system administrators always knew to look at logs in case of problems, massive server operating system (both Windows and Unix/Linux flavors) log analysis didn't materialize until more recently. Collecting logs from all critical (and many non-critical) Windows servers, for example, was hindered by the lack of agentless log collection tools, such as LASSO. On the other hand, Unix server log analysis was severely undercut by a total lack of unified format for log content in syslog records.

Web server logs were long analyzed by the marketing departments to check on their online campaign successes (and most web server admins would not ignore those logs as well). However, since web servers don't have native log forwarding capabilities (most log to files stored on the server itself) consistent centralized web log analysis for both security and other IT purposes is still ramping up. There is plenty of interesting info to dig for.

Similarly, email tracking thru email server logs languishes in a somewhat similar manner: people only turn to email logs when something goes wrong (email failures) or horribly wrong (external party subpoenas your logs). Lack of native centralization and, to some extent, complicated log formats slowed down the email log analysis initiatives.

Judging by the traffic on loganalysis mailing list, database logging wasn't on the radar of most IT folks until probably last year. It is emerging now! In fact, IT folks were perfectly happy with the fact that even though RDBMS had extensive logging and data access auditing capabilities, most of them were happily never turned on. It will be all the rage in a very near future. Oracle, MS SQL, DB2, MySQL all provide excellent logging, if you know how to enable it (and know what to do with the resulting onslaught of data)

What's next? Web applications and large enterprise application frameworks largely lived in the world of their own, but now people finally starting to realize that their log data provides unique insight into insider attacks, insider data theft and other trusted access abuse. I expect to see much more of such logs flowing into log management solutions. Additionally, desktop log analysis should not be too far behind.

In a more remote future, various esoteric log sources will be added into the mix. Custom applications, physical sensors and many other uncommon devices and software want to "be heard" as well! :-)

So, from firewall logs to NIDS to servers to databases, web servers and then applications seems very common across a large number of organizations.

Just an interesting observation!

Technorati tags: log management, logs, loglogic, chuvakin, security management