Log Analysis and Log Correlation Basics

Log data can provide benefits beyond the obvious notification of system events and security happenings.  Aggregated logs from a system or from multiple systems can provide a more complete picture of problems when those logs are correlated together.  To any experienced administrator, this is obvious.  Consider the following environment:

In this scenario, the administrator is primarily concerned with the health and well being of the web and database servers.  Both systems generate logs at the operating system and application levels.  We can use these logs to watch for evidence of system compromise, detect hardware failures and so on.  If the web server is compromised, the administrator may be able to piece together the source and method of the attack, but depending on the type of compromise, logs may be lost.  To protect logs from tampering and to consolidate the logs into one place, the administrator implements a centralized log server to collect logs from the various systems in this sample network.

Now, the administrator has the logs from these devices securely in one location.  Going back to the situation where the web server is compromised, the administrator is able to manually correlate events from the firewall, switch, IPS and web server to determine source and method of the attack.  This capability is very useful when responding to a security incident.

The next level of maturity is using these logs to proactively look for evidence of attacks that are under way.  The major challenge is labor.  Even a skilled security administrator can only process several hundred to a few thousand events per day.  But, the average organization will see tens of thousands, to hundreds of thousands of events per day.  It is not economical to pay people to perform such a task, particularly when computers can do such a job far more efficiently.  This is where log analysis and correlation engines come in.

There are many robust analysis and correlation engines on the market.  Most are commercial software, though there are a few open source applications.  Generally, these applications either replace the centralized log server, or sit next to the log server, either interfacing with the existing log server’s data store, or requiring a separate log feed.

Support for different types of log sources and the capabilities of the correlation engines vary greatly from application to application.  Organizations looking to acquire such an application will want to ensure that the types of systems used are supported, and that the system is capable of producing the desired results – such as reporting, proactive actions (ie firewall blocking), etc.

Correlation engines can provide proactive and reactive insight into attacks; even subtle attacks that are “low and slow”.  For example, an attacker who attempts a brute force login attack may only send a login attempt every few minutes to few hours – far enough apart to not create an alert by someone looking at a single event.  The correlation engine will see the pattern and might recommend that the attacker be firewalled off as a mitigation to the attack.  In another example, events from an IPS engine could be correlated with firewall logs to determine that a focused attack is underway, potentially providing administrators the with ability to react before the system is compromised.

Log analysis and correlation engines are not intended to be stand-alone security implements.  They should be viewed as an added layer of defense to existing sound controls.  Trying to implement such a system into an environment that is not in good control will likely result in a failed project, because:

  1. There is too much “noise” for any sort of effective analysis of events.
  2. The frequency of events & false alarms will lead to frustration & abandonment.
  3. The environment does not enable administrators to take effective action (either manually or automatically) based on the output of the engine.