LogAdvisor

The foundation of the Log Management Hierarchy of Needs is for the applications and devices to produce quality log data.

That sounds simple enough, but it is by far the most overlooked step I’ve come across when organizations are designing their log management strategy.  There have been many times when customers have needed to look at log data and find that it is not available.  Deciding what level of logging to turn on is important when creating a strategy for log management.

Logging everything is not the answer, but it’s much better than logging nothing.  Right-Logging is not easy to do; it takes time and focus.   Trade offs need to be made concerning system performance, message volume, bandwidth, and storage requirements of the log data.  Those decisions need to be made on an individual basis and regularly evaluated as the cost of bandwidth, cpu, and disk will continue to decrease.  When deciding what to log on any device or application it is important to take into account what might be needed for security, operations, and compliance.

There are many other examples of organizations that have failed to log the critical data needed for security, operations, and compliance purposes.  Quality log data might mean having an application log every successful and failed login attempt or it might mean logging both denied and successful access through a firewall.  Problems start to arise when system administrators decide to do too little.  Wired Magazine’s inside story of Walmart’s hacker attack shows why an organization needs to focus on producing quality log data,

“The company’s server logs recorded only unsuccessful log-in attempts, not successful ones, frustrating a detailed analysis.” (Wired)

Rules when deciding what to log:

1. Identify critical and high risk systems for high level logging
2. Log all successful and failed logins (typically audit logs)
3. Log security devices’ (Firewalls, VPN, Proxy servers, and Access points) denied and approved messages
4. Increase logging in the core, reduce at the edge

Do your homework on vendor recommendations

Systems can often give hints on the value of log events.  For example, even though Windows logging can be frustrating, it does by default separate security events into a specific event log called ‘Security event log’.  This is a good place to start collecting logs on Windows, because it will give you all the successful and failed logins, plus the questionable activity that would cause a security alert on the system.  There are several events that Windows will give for failed logins; make sure you have a reference.

On some systems the hints might not be as easy to follow.  For example Cisco Firewalls will only log success messages at their “informational” logging level.  Cisco documentation does not recommend logging informational messages, even though that is the only level at which the user will know what traffic is getting approved through the firewall rules.  Wouldn’t you rather know what traffic was approved through your firewall rather than what was denied by it?  When trying to correlate log messages from internal systems or intrusion detection devices with a firewall, it is necessary to have the approved messages from the firewalls.