eIQviews

As we continue through our series on Log Management, let’s evaluate the kinds of information that are available from the typical log records we see and what we can learn from them.

First, keep in mind that pretty much everything can generate a log file for just about anything that it does. So one of the first places we’ll look is the firewall. Why? Simply put, the firewall is the first line of defense. So what kind of stuff are we looking for in the firewall logs? Here a little list:

• Traffic for unused ports – This is a pretty simple one because it’s usually indicative of some attack. After all, why would legitimate traffic be sent using ports you don’t have on. Right, it wouldn’t. So this is typically reconnaissance traffic trying to figure out what holes the attackers can start to exploit.
• Failed logons – This is self-evident as well, given that one sure-fire way to compromise a firewall is to log into it. So brute force attacks are definitely something you’ll see. This is another reason changing the default password and not using a predictable user ID (like “admin”) is critical.

Outbound connections – Given the prevalent attack vector of compromising a server and then transferring that data outside of the organization, it makes sense to scrutinize strange outbound connections. Of course there are a bunch of other things to look for as well. And a log management system that is configured to watch for strange results in these logs can save your bacon.
Similarly, you can look for information in your intrusion detection/prevention (IPS) device as well. Things to look for here include:

• Attack signatures – since the IPS is firing, we know some kind of rule was violated. The attack type is helpful to understand what you are up against.
• IP addresses – You can learn a lot from the IP addresses of attack packets. Are they spoofed packets with an internal IP address? Do they originate from a web server in your DMZ? These are all clues to some type of successful attack.

There are similar nuggets of information in database logs (like connection type, application ID, transaction type, etc.), server and application logs as well. So there is no lack of log data to collect and analyze.

Not even Einstein could make heads or tails of all this log data that is gathered on an ongoing basis, especially given that the typical large enterprise has hundreds of network devices, tons of databases, and thousands of servers. Wading through Gigabytes of log data every day isn’t really practical (though it would make for an interesting Dilbert series).

Thus you need to automate the analysis and correlation of these logs. In future posts, I’ll discuss how this needs to work, and why merely correlating log files is inherently limiting. The key takeaway here is that there is a lot of great data in the logs; you just need to know how to leverage it.

The next topic in our Log Management series will discuss the intersection of log data and identity. Stay tuned for more information on log management.