The 2010 Data Breach Investigations Report published by the Verizon Business RISK Team has a shocking statistic about the effectiveness of log analysis in helping organizations discover that they've been a victim of a security breach. According to Verizon, logs are available in nearly 90% of the breaches they've investigated, but effective in discovering the breach less than 5% of the time. This article outlines some best practices for deploying a security information event management (SIEM) solution to put those logs to better use.
The 2010 Data Breach Investigations Report published by the Verizon Business RISK Team is out, and it's a gold mine of information. This year's report includes investigations conducted by the U.S. Secret Service, dramatically increasing the scope of the breaches that have been analyzed for root cause. The reason this report is so valuable is that it gives us an opportunity to see where other organizations have failed to protect their data and systems, so that we can learn from others' misfortune.
There are always some surprising statistics and details in the report. For example, the 2010 report states, "We consistently find that nearly 90% of the time logs are available but [breach] discovery via log analysis remains under 5%."
Does this mean that collecting log data isn't worth the effort? No, not at all. But the report suggests that maybe a change in strategy is needed; instead of looking for a needle in a haystack, perhaps it's time to look for haystacks. The report says there are three major tip-offs (i.e., haystacks) that could be signs of a breach:
* Abnormal increase in log data
* Abnormal length of lines within logs
* Absence of (or abnormal decrease in) log data
The investigators write, "We've seen log entries increase by 500% following a breach. We've seen them completely disappear for months after the attacker turned off logging. We've noticed SQL injection and other attacks leave much longer lines within logs than standard activity. Those are more like haystacks than needles." Furthermore, "just finding the haystacks would be a very real improvement."
Tools like security information event management (SIEM) systems can help you find the needles as well as the haystacks so that you increase your chances of not only detecting but perhaps even mitigating a breach or other violation of policy. Bill Roth, executive vice president of global marketing at LogLogic offers his suggestions for best practices for SIEM deployments:
Understand your data and what you want it to do for you.
You have to understand the size, frequency and behavior of your log data before you deploy. This means knowing where your data comes from (e.g., systems, routers, switches) and how it's delivered. You also want to identify your goals for implementing a SIEM system. Is your SIEM project primarily to support day-to-day operations? Is it for security and keeping logs as an audit trail? Or is it for meeting a specific compliance mandate? Understanding what you want the SIEM system to do for your organization will help you define the policies and procedures you'll need to adhere to, as well how long to retain your log data.
Identify the scope of devices you want to log (e.g., syslog, systems, routers, firewalls). Depending on the above mentioned use cases, you may have a specific set of devices in mind. Keep in mind that you can log things beyond just network equipment. For example, you can also collect from physical logins like security access into a building. Also, on the compliance side, PCI-DSS requires you to log all devices that are involved in payment card transactions. Often, enterprises will segregate that network, and keep a year audit trail on just those devices. To play it safe, log everything to ensure you are covered across your entire network and enterprise.
To correlate or not?
Defining the log management layers will help identify what use cases are needed for correlation. Often, enterprises use correlation with security specific devices such as IDS/IPS devices, firewalls and domain controllers at the minimum to take a proactive approach to security. However, some businesses use correlation for operational purposes, such as identifying an OS error message with a specific database error message, and tying that together with a software error message across multiple platforms. Both are excellent use cases.
Don't "set it and forget it."
If you set the SIEM deployment and don't come back to it, you might as well not deploy it at all. You've got to set up your roles and policies across both the log management and correlation layers. You also will have to tune them over time so that they work well together to reduce false positives. Be sure to assign responsibility to those who should review reports that your SIEM solution creates, and put a policy in place to make sure that new devices are added to the system as they come online.
Reporting is key.
Instead of pulling a ton of reports at once, start with specific reports tailored to your needs. By collecting a specific set of data, you can tweak it and optimize. In other words, start with the end in mind. Be able to answer questions like "What do I really need to know?" and build your final reports with that end in mind. Make sure you consider your stakeholders (like your boss) when designing your reports. Keep in mind that you should look for haystacks as well as needles.
Having a solid plan in place for deploying your SIEM solution should help your organization achieve compliance and maintain a strong security posture within your IT operations.