SIEM vs. SOAR: The Right Security Tool

Security information and event management (SIEM) and security orchestration, automation, and response (SOAR) are complementary solutions. 

For robust security, you need to have both functions, working in conjunction with one another. Your SIEM should collect data and reduce noise to a manageable number of potential threats, which are triaged and investigated, and then fed into the SOAR for actions as needed.

While a few vendors muddy the waters with yet another category, extended detection and response (XDR), I’m not a fan. Having suffered through early tools that blocked everything on a blacklist (much the way XDR does) as well as the pain of self-inflicted denial-of-service (DoS) events, I find the concept of XDR to be a worrisome combination of bad SIEM and bad SOAR. Maybe it can work well, I just haven’t seen it.

For some time, SIEM has had a bad reputation for being complex and difficult. SOAR, the newer kid, is often tasked with compensating for poor SIEM implementations.

The real SIEM vs. SOAR debate is about two things:

1. Who owns the single pane of glass to monitor everything?
2. Where does triage get done?

Workflow: Which security tool is responsible for which tasks?

There’s a large workflow overlap between SIEM and SOAR. For example, where do you create and track tickets? How do you triage? Often, a third ticketing tool, like ServiceNow, JIRA, or Remedy, comes into play. Whatever the case, you have to be able to do the following somewhere:

1. Track that you’ve detected the threat for auditors.
2. Track that you’ve taken action on it.
3. Document the time spent on tasks to justify paychecks.

In 2019, Gartner, Inc. set the criteria that for a SIEM to have a complete vision and make the top right quadrant, it needed to do all of the above. By contrast, SOAR and information technology service management (ITSM) systems haven’t been required to do what a SIEM does.

I find that in most “next-generation SIEMs” (a term I hate), you get workflow, ticketing, and minimal SOAR with links to use external SOARs and ITSMs. Therefore, because I’d rather be good at one tool than a jack of all trades in many, I build workflow in SIEM when I can and, as required, implement external SOAR for complex playbooks.

The table below gives you a quick checklist of the key capabilities of SIEM, SOAR, UEBA, and ITSM so you can see the overlaps.

Playbooks: Establishing standard procedures

A SIEM spits out potential threats and often executes what I consider the first playbook: Identify friend or foe (IFF). I prefer a SIEM to do IFF (e.g., Is this a known friendly or on an evil-doer list? Is it internal or external?). This way, the analyst can easily see in the SIEM user interface (UI) why actions were taken.

*BONUS* - Pivot into threat hunting by asking who else has this same symptom?

However, the rubber truly meets the road with SOAR playbooks. A minimal set of SOAR playbooks to block threats, remediate malware, remove malicious email, and disable accounts then completes these standard requirements:

• Block – IP or URL if confirmed evil from IFF.
• Remove – Remove the malicious file or email, block the sender or the file on an internal blacklist.
• Scan and update – Scan the host for any malware and remove it. Update the host operating system, antivirus software, and any installed applications from known-safe sources.
• Disable account – Disable the compromised user account before more damage can be done.

*BONUS* - For every playbook, also add that host or user to a watchlist, it’s more likely to get reinfected and, sometimes the removal or update fails. Some hosts are more interesting targets, and some users are frequent offenders.

SOAR customization is about linking the key playbooks to authenticate and send actions to your tools. Generally speaking, these will be a firewall, an EDR tool, a vulnerability scanner, patch management software, and Active Directory or your IAM.

Of course, there’s always more you can do.  

You may want to configure advanced workflows with escalations when service level agreements (SLAs) go unmet. Or you may have more complex actions for things like remote desktop protocol (RDP) and virtual private networks (VPNs), where the logs don’t have the necessary raw data, or the device is shared across many people.  

Certain IOT devices — for example, lasers in use during an eye surgery — aren’t something you want to automate any actions on without checking with the doctor and patient first.

The Process: Crawl, walk, run, SOAR

There is a process worth following, with milestones along the way.

1. Crawl. Collect the logs. You can’t analyze what you don’t have, and it’s a compliance mandate for most of us. Ensure data is parsing, normalized, and enriched.
2. Walk. Create top 10 dashboards. Do some basic volume and variety analysis. Run the events through the funnel of your SIEM’s correlation engine to reduce noise.
3. Run. Tune your content, add anomaly detection, configure workflow, validate findings.
4. SOAR. Automate blocking actions on low false-positive threat detections.
5. Lather, Rinse, Repeat.

Resolution Intelligence Cloud's role in the SIEM/SOAR debate

Resolution Intelligence Cloud builds on the Google Chronicle SIEM, adding capabilities and integrating ITSM and SOAR. Its open architecture facilitates interoperability and increases efficiency while also easily handling data at speed and scale to further reduce alert noise.

Stay tuned for more on the onboarding process in a future post.