Another SIEM blog series? Really? Why are we still talking about SIEM? Isn’t that old technology? Hasn’t it been subsumed by new and shiny security analytics products and services? Be honest – those thoughts crossed your mind, especially because we have published a lot of SIEM related research over the past few years. We previously worked through the basics of the technology and how to choose the right SIEM for your needs. A bit over a year ago we looked into how to monitor hybrid cloud environments.

The fact is SIEM has become somewhat of a dirty word, but that’s ridiculous. Security monitoring needs to be a core, fundamental, aspect of every security program. SIEM – in various flavors, using different technologies and deployment architectures – is how you do security monitoring. So it’s not about getting rid of the technology – it’s more about how to get the most out of your existing investment, and ensuring you can handle the advanced threats facing organizations today.

But we understand how SIEM got its bad name. Early versions of the technology were hard to use, and required significant integration just to get up and running. You needed to know what attacks you were looking for, and unfortunately most adversaries don’t send attack playbooks ahead of time. Operating an early SIEM required a ninja DBA, and even then queries could take hours (or days for full reports) to complete. Adding a new use case with additional searches and correlations required an act of Congress and a truckload of consultants. It’s not surprising organizations lost their patience with SIEM. So the technology was relegated to generating compliance reports and some very simple alerts, while other tools were used to do ‘real’ security monitoring.

But as with most other areas of security technology, SIEM has evolved. Security monitoring platforms now support a bunch of additional data types, including network packets. The architectures have evolved to scale more efficiently and have integrated fancy new ‘Big Data’ analytics engines to improve detection accuracy, even for attacks you haven’t seen before. Threat intelligence is integrated into the SIEM directly, so you can look for attacks on other organizations before they are launched at you.

So our new SIEM Kung Fu series will streamline our research to focus on what you need to know to get the most out of your SIEM, and solve the problems you face today by increasing your capabilities (the promised Kung Fu). But first let’s revisit the key use

cases for SIEM and what is typically available out of the box with SIEM tools.

Alerting

The original use case for SIEM was security alert reduction. IDS and firewall devices were pumping out too many alerts, and you needed a way to figure out which of them required attention. That worked for a little while, but then adversaries got a lot better and learned to evade many of the simple correlations available with first-generation SIEM. Getting actionable alerts from your SIEM is the most important use case for the technology.

Many different techniques are used to detect these attacks. You can hunt for anomalies that kinda-sorta look like they could be an attack or you can do very sophisticated analytics on a wide variety of data sources to detect known attack patterns. What you cannot do any more is depend on simple file-based detection, because modern attacks are far more complicated. You need to analyze inbound network traffic (to find reconnaissance), device activity (for signs of compromise), and outbound network traffic (for command and control / botnet communications) as well. And that’s a simplified view of how a multi-faceted attack works. Sophisticated attacks require sophisticated analysis to detect and verify.

Out of the box a SIEM offer a number of different patterns to detect attacks. These run the gamut from simple privilege escalation to more sophisticated botnet activity and lateral movement. Of course these built-in detections are generic and need to be tuned to your specific environment, but they can give you a head start for finding malicious activity in your environment. This provides the quick win which has historically eluding many SIEM projects, and builds momentum for continued investment in SIEM technology.

SIEM technology has advanced to the point where it can find many attacks without a lot of integration and customization. But to detect advanced and targeted attacks by sophisticated adversaries, a tool can only get you so far. You need to evolve how you use security monitoring tools. You cannot just put a shiny new tool in place and expect advanced adversaries to go away. That will be our area of focus for the later posts in this series.

Forensics

Once you have determined an attack is under way – or more accurately, once you have detected one of the many attacks happening in your environment – you need to investigate the attack and figure out the extent of the damage. We have documented the incident response process, especially within the context of integrating threat intelligence, and SIEM is a critical tool to aggregate data and provide a platform for search and investigation.

Out of the box a SIEM will enable responders to search through aggregated security data. Some tools offer visualizations to help users see anomalous activity, and figure out where certain events happened in the timeline. But you will still need a talented responder to really dig into an attack and figure out what’s happening. No tool can take an incident response from cradle to grave. So the SIEM is not going to be the only tool your incident responders use. But in terms of efficiently figuring out what’s been compromised, the extent of the damage, and an initial damage assessment, the SIEM should be a keystone of your process. Especially given the ability of a SIEM to capture and analyze network packets, providing more granularity and the ability to build a timeline of what really happened during the attack.

Compliance

Finally, the SIEM remains instrumental for generating compliance reports, which are still a necessary evil to substantiate the controls you have in place. This distinctly unsexy requirement seems old hat, but you don’t want to go back to the days of preparing for your assessments by wading through reams of log printouts and assembling data in Excel, do you? So SIEM tools ship with dozens of reports to show the controls in place and map them to compliance requirements, so you don’t need to do this manually.

Another reason the compliance use case is still important is the skills gap every security team struggles with. If you have valuable and scarce security talent generating reports to make an auditor go away, they aren’t verifying and triaging alerts, tuning detections to find new attacks, or investigating incidents. So automating as much of the compliance process as possible remains an important SIEM use case.

As we have mentioned in earlier SIEM research, a lot of these basic use cases can (and should) be implemented during a PoC process. That way you can have the vendor’s sales engineers help kickstart your efforts and get you up and running with the out-of-box capabilities. But a sophisticated attacker targeting your organization will not be detected by basic SIEM correlation. Through the rest of this series we will dig into more complicated use cases, including advanced threat detection and user behavior analysis, which require pushing the boundaries of what SIEM does and how you use it.