A good log management tool can be very effective in managing and ensuring security in an enterprise. However, the right tool can quickly become the wrong tool unless the organisation puts in the time and effort required to make the tool effective.
Here are a few best practices to ensure a successful implementation of a log management tool:
A fool with a tool is still a fool – Don’t spend a fortune on a log management system if you’re not prepared to invest the time in installing and managing it properly. Log management systems must be configured to parse events and data that matter to the organization so that reports have business and technical value. Another commonly committed mistake is failure to look at and review the alert console, thereby missing critical security events. Investing in a good log management tool is only the first step and needs to be followed up with a process whereby the team commits the time necessary to use the log management tool well.
Make sure you have the information you need – To be able to write effective correlation rules, the log management system must have enough contextual data to analyze. For example, where specifically did the traffic or activity come from? This requires knowledge of the source IP address, which means the log management systems must be logging that information in order for the engine to be able to parse it. What happened on the target device or application? If an organization wants to write log analysis rules and alerts for activity, the log data must record that activity.
Think beyond static reporting – The last thing most organizations need is another list or spreadsheet filled with rows and rows of data that has no overarching analysis model to help make sense of it all. Alerting should be done not just on “the characteristics of individual rows but also on sets” and baselines of expected or acceptable activity. Consider logins to a critical database. The normal baseline may be two failed logins, but if the password requirements for that system are changed from a simple dictionary word to an 8+ character non-dictionary string, login failures may be expected to increase while users get accustomed to the new rules. Intelligently aware log management systems could be tuned to monitor trends and provide feedback to the administrators who may decide to use the trending information to temporarily alter the alerting threshold.
Use log data to figure out what is happening or what just happened – “Logs are wonderful for outages,” because, very often, all of the information necessary to determine what is causing (or caused) the outage can be found in the log files themselves. During a crisis, staff often goes into reactive mode, sometimes relying on intuition, speculation, and atomic unrelated pieces of information to piece together what is going on or what happened. But logs are a record of what actually happened. Systems that allow staff to write and run reports in real-time based on outage information deliver the facts that response teams need to understand what’s happening on the network.
Think outside the security box – Log management systems are excellent for aggregating and analyzing information from security devices for security awareness, but the information being gathered can be used for other purposes as well. For example, an organization “can analyze the customer experience for their top ten business relationships.” Many trending and click track type Web application-reporting systems don’t provide a granular view of the actual customer experience. “Well-designed application logging would take the customer experience into account,” and expands the utility of the log management well outside of the security box.
Some of the open source log management tools are:
OSSEC (ossec.net) an open source tool for analysis of real-time log data from Unix systems, Windows servers and network devices. It includes a set of useful default alerting rules as well as a web-based graphical user interface.
Snare agent (intersectalliance.com/projects/index.html) and ProjectLasso remote collector (sourceforge.net/projects/lassolog) are used to convert Windows Event Logs into syslog, a key component of any log management infrastructure today.
syslog-ng (balabit.com/network-security/syslog-ng/) is a replacement and improvement of classic syslog service – it also has a Windows version that can be used the same way as Snare.
Some other tools that can be used to summarize logs into readable reports are Logwatch (logwatch.org), Lire (logreport.org) and LogSurfer (crypt.gen.nz/logsurfer).
LogHound (ristov.users.sourceforge.net/loghound) and slct (ristov.users.sourceforge.net/slct) are more “research-grade” tools, that are still very useful for going thru a large pool of barely-structured log data.
Log2timeline (log2timeline.net/) is a useful tool for investigative review of logs; it can create a timeline view out of raw log data.
LogZilla (aka php-syslog-ng) (code.google.com/p/php-syslog-ng) is a simple PHP-based visual front-end for a syslog server to do searches, reports, etc
Comments are closed.