Down with SIEM, long live SOAR!

SIEM (Security Information and Event Management) tools have been the bedrock of Security Operation Centers, or SOCs, for much of the history of modern security. That does not mean that they are loved: most SIEM tools are overwrought, complex, and hard to manage. Despite the shortcomings of SIEM platforms, most blue teams felt that they had no choice but to invest in one in order to get needed visibility into their environment and to handle all the alerts generated by the myriad of security tools most teams have.

In the past few years, however, a new category of tool has come on the market: SOAR, or Security Orchestration, Automation, and Response. While many teams that invest in SOAR platforms are first leveraging them for automation, I believe that SOAR tools are also poised to finally displace SIEM at the top of the blue team tool pyramid, and rightly so. The benefits of SOAR definitely outweigh the benefits of SIEM, and although both can be complex tools to implement and manage, SOAR offers much more utility to security teams than traditional SIEM tools.

The selling point (and most complex piece) of SIEM platforms in the past has been its correlation engine: the ability to define alerts based on a number of events happening in a certain pattern within a certain timeframe. The canonical example is a successful brute-force attack against a privileged account such as Domain Admin: several failed logins for an account followed by a successful login in a relatively short period of time. By building different correlation rules, blue teams attempt to define and alert on what they believe malicious behavior will look like in their environment. The goal is to winnow down the large number of lower-value events, such as standalone login failure events, and transform them into a smaller set of high-value, high-fidelity correlated alerts.

I’ve never been a fan of this approach for several reasons. The first is that this approach by necessity is always backward-looking. Typically, after a malicious event occurs in an environment, one of the after-action tasks is to create a correlation rule in the SIEM tool that will alert if those series of events happen again. However, this requires the attacker to follow the exact same pattern in a future attack; any deviation and the alert will not fire. SIEM tools are also notorious for lacking version control and documentation capabilities, so after a while the typical SIEM tool has a large number of complex correlation rules of forgotten purpose and provenance. This leads to a pattern of fighting the last battle versus being proactive in defining malicious activity.

Second, and more importantly, I strongly believe that there are some events that should merit attention of the security team no matter how that event came to be. Going back to the canonical SIEM example, only alerting on a Domain Admin account having a successful login after several failed logins seems short-sighted. Instead, security teams should strive to alert on and investigate every Domain Admin login to determine if it is legitimate. This eliminates the chance that some suspicious event will fall through the cracks because it doesn’t match a correlation rule exactly. These kinds of alerts also don’t require a sophisticated correlation engine, and most log search/aggregation tools can handle these kinds of alerts easily.

“Hold on,” you may be saying about now, “if I alert on every single Domain Admin login, I will be swamped with alerts!” That is a valid concern, but this is where a SOAR tool comes into play to help handle the activity. Instead of focusing on identifying patterns of suspicious activity before the event, SOAR tools are very good at automating decision-making after the event occurs by allowing blue teams to convert their investigation steps and decision-making logic to automation playbooks. For example, a certain Domain Admin account may be used only from one IP for scripting purposes, so the playbook that handles these alerts can auto-close logins for that account from that specific IP as expected behavior. As time goes on and the playbook evolves, more and more of the alerts can be handled automatically, leaving fewer alerts that require manual investigation.

With this approach, although it may be noisier to begin with, it removes one of the major pitfalls of the SIEM approach: the fact that new activity patterns won’t trigger SIEM alerts if a rule hasn’t been set up for it ahead of time. With the SOAR-based approach, new patterns will typically be sent to analysts for review, since most playbooks will have a fallback “I haven’t seen this pattern before and I don’t know what to do with it” path that brings the event to the attention of a person. This approach also tends to have a side benefit of reducing the biggest source of noise for security analysts, which is bad IT practices. Having a large number of Domain Admin alerts to handle is great incentive to work with Active Directory owners to identify over-permissioned accounts, which cuts down on noise and improves security posture.

When threats were static, assets were easy to contain and manage, and perimeters were well-defined, SIEM may have been a good choice for security visibility. However, now that the threat landscape has changed, businesses are focusing more on a collaboration culture than creating walled gardens for employees to work in, and analyst time is scarce, SOAR is a much better poised benefit to blue teams.