Event logs provide all the information you need to troubleshoot operational errors, and investigate potential security exposures. They are literally the bread crumbs of the IT world. But as you're likely aware, finding the insight you need inside those scattered bread crumbs, isn't all that straightforward.
Thankfully, there are some useful technologies that can assist with bringing together those scattered bread crumbs into a trail that we can follow... to improve incident response, threat management, and satisfy compliance requirements. And event log management is a key part of that. However, there are a few myths associated with log management, so we've provided a list of myth busting facts to help you better understand these technologies.
Myth #1: Log management and event correlation are the same thing.
It is true that these two capabilities are both essential for security and compliance; however, they are far from the same. When it comes to deriving insights from your event logs, you need to do two things. First, you need to securely store and retain your raw event logs for a period of time, and second, you need to analyze and correlate that raw event log data across your infrastructure. The first step is satisfied by log management, and the second step is provided through event correlation or SIEM. And even though these are distinct capabilities, it's best to look for products like AlienVault USM that can deliver both, using the same management platform and console - since they are so closely related.
Myth #2: The more log data, the better the analysis.
One of the biggest mistakes many organizations run into when they implement log management is that they try to integrate everything into their log management tool. In other words, if any IP-enabled device creates a log, let's put it in, and let's not finish integrating until there's not a single raw event log left. Instead, start with the event log data that you know will answer the questions you need to ask. Typically, this core set of raw event log data would include your key security-relevant sources: gateway firewall logs, VPN logs, domain controller logs, Anti-Virus logs, database server logs, web server logs, and IDS logs. But it could be that your organization has additional priorities, based on the type of business you're involved in, and where sensitive data resides. The bottom line is: understand what you want to know BEFORE trying to boil the ocean of logs in your environment.
Myth #3: Log management is just about storing logs, not accessing raw log data.
This myth is similar to the endless debate over system backup and restore. The critical operational question is not whether you're backing up your systems on a regular basis, but rather whether you're actually testing those backups by using them for full system recovery. The same concept applies here. Yes, you do need to securely store your raw log data for a period of time, keeping in mind that data retention policies will be dictated by key business requirements, including your compliance obligations. But you also need to access that raw log data easily, reliably, so you can quickly respond and investigate incidents as well as answer your auditor's questions. Look for easy-to-use search capabilities, including full text search, as well as flexible data retention policies.
Myth #4: When it comes to doing effective security monitoring, all you need are the logs.
Yes, event log data is necessary for security monitoring, but it's not sufficient. You'll still need additional context for the raw log data, which on its own, doesn't tell you much. Asset inventory data, vulnerability assessment results, netflow analysis, IDS alerts and more will provide the full context you'll need to know how to think about the raw event log data. Correlation of the event log data with information about your environment (devices, users, vulnerabilities, etc) provides richer context, and sets you up for effective prioritization of security incidents and issues.
Myth #5: Log analysis is only relevant within a real-time context.
In a perfect world, we'd be able to catch security incidents as they happen. But as we all know, attacks against your network are happening so frequently, and many of them are conducted "under the radar" that what we may find "now" is merely a symptom of a larger and broader exposure. Don't get me wrong, "real-time" analysis is necessary in order to spot those exceptions to normal traffic patterns. But a "real-time-only" approach is not sufficient. Chances are that when you're in the process of responding to a real-time alert, you'll discover that you need to find out when and how the attacker first entered your network, and what systems they may have exploited in the process. And that trail will likely lead you back to the historical record of raw event log data.
As you explore various options for log management, log analysis, and event correlation tools and techniques, don't forget to avoid the hype and stay focused on the essentials.
