Here are ten critical facets to consider in your security log monitoring process. You can argue that other things should be on this list, but in my experience, these are the ten that really deserve a higher level of thought and attention. You’ll most likely also have company-specific rules or constraints that impact your log analysis program.
Define Compliance Drivers
Are you required to follow specific government or industry mandated rules regarding information security? In the financial industry, mandates such as Sarbanes-Oxley must be understood to avoid possible financial or legal penalties. Any company associated with the health care industry is required to follow HIPAA regulations. Your requirements for logging and compliance may have already been defined for you.
How many security logs do you have? Probably many more than you think. A full security log audit includes logs related to devices/activities from across your operations. This includes firewalls, VPN systems, authentication servers, mail and database servers, and any other application servers.
Rank your Logs
Although you might have more logs than you think, not all systems, data, and their associated logs are of equal value. You need to allocate your time and energy to the most mission-critical logs first and work out towards less important fringe logs as time permits. You never want to have an unmonitored log, but not every log deserves the same amount of time and attention in this process.
Once you have identified and ranked your logs, establish formal teams to divvy up the workload. Use your resources to the fullest. For database log analysis, get the database analysts (DBAs) and database developers in the loop. Many of these individuals may not actually ever capture or view a log file, but their expertise is critical in understanding data and crafting responses.
It makes little sense to establish a great system for capturing and analyzing security log data without having clear cut procedures to respond appropriately to what’s discovered. This is where analysis morphs into response. The appropriate response may be to simply do nothing, but unless this has been thought through thoroughly, documented, and communicated to your team, the analysis serves little purpose. You can’t create a procedure for every possible scenario, but you can easily identify the most common type of scenarios that logs can generate.
Make Training a Priority
You must depend on the knowledge of experts from several roles and functions to define procedures. The SQL Server DBA will play a critical role in defining database security responses. It doesn’t take a rocket scientist to realize that your analysis and responses will be flawed if your experts don’t have the most up-to-date training on how their systems function. Training dollars, if spent wisely, are one of the most cost effective, proactive responses to solid security. Half the value in process training is the feedback from your team members on the processes themselves. Defining a process on paper is often quite different from getting feedback from those who implement the process themselves.
Protect the Data
Security logs contain sensitive data. There’s no way to sugar coat this one, but you can have the best experts and the best procedures and still get into big time trouble if your logs are compromised. Although you may use teams to monitor, analyze, and respond to log events, keep access to your logs on a need to know basis and make sure that you minimize the number of individuals who have direct access to log files. Kick things up a notch by making sure that the core log file access team also understands how serious this log file protection really is. If you can, put some teeth behind it and designate abuse of log security as a serious offense.
Use Software and Hardware Tools
Security logs are often stored in their original location on systems distributed throughout your organization. Anything you can do to centralize and consolidate log file data will free up more time for analysis and response planning. Luckily, there are now a plethora of log consolidation and analysis tools available for nearly any system that will allow you to dramatically streamline your processes.
Automate as Much as Possible
Your end goal for log analysis is an ongoing process that keeps your resources safe. Once you know what your final objective is, you can then work on streamlining and automating your capture, analysis, and response procedures. Software tools along with a simple flowchart analysis can help you minimize the time and effort required to achieve the vigilance you seek. One critical factor when assessing any software driven tools is how much automation you can achieve and how costly the process is to get there.
Use Redundant Analysts
Although you want to automate and streamline as many components within your log analysis system, you must always be vigilant for missed data. Most log consolidation and analysis tools give you the capability to target specific log events and set response actions. However, remember that the most powerful computers you have available are the human experts still running the show. A basic tenet for any log file analysis system should contain procedures to have multiple eyes review the same data. Do not leave your organization open to log events that slipped through the cracks because only a single human analyzed the data. Having multiple team members review and report on the same data is a valuable use of human talent.
Ultimately, with less effort than you might expect, you can build a consistent, high-quality data capture and analysis system. Your organization will be able to move forward knowing that your people and systems are vigilantly checking for security weaknesses and mitigating risks. And you, as an IT security professional, can sleep just a little more soundly.
Excerpted and available for download from Global Knowledge White Paper: Security Log Analysis: Saving the World, One Company at a Time