While security information and event management (SIEM) is rightly considered an indispensable tool for detecting and managing threats, it can only do so much good since we only detect threats to respond to them. Of course, successful threat management demands rapid incident response, and security operations teams tend to overemphasize detection as a result.

How can organizations both empower their responders to remediate threats quickly and strengthen their security posture to prevent data breaches in the first place? The answer is security orchestration, automation and response (SOAR).

SOAR Solutions Add Context to SIEM Data

SIEM solutions are now deployed in virtually every large enterprise, and for very good reason. In the U.K., in fact, the RM3808 regulation precludes any organization from bidding for public sector network services work unless it has a SIEM solution in place. This makes sense: Companies should be monitoring their events and data flows if they expect to detect threats to their information or that of their customers.

SOAR tooling enables security operations teams to automate the tedious and repetitive elements of their workflow that don’t require human oversight and instead focus on more mentally challenging tasks that call for discernment and judgment. The best SOAR solutions enrich and contextualize threats to help analysts quickly triage cases according to the severity of the risk, sensitivity and/or criticality of the business functions under threat.

Many of the remedial tasks that fall under the analyst’s supervision, such as isolating endpoints, can be orchestrated with a SOAR platform via application programming interfaces (APIs). Faster remediation leads to earlier resolution of incidents in the attack chain, which greatly reduces the risk of a data breach.

A Force Multiplier for Understaffed Security Operations Teams

Even if you had an unlimited security budget at your disposal, you would still struggle to hire the caliber and quantity of talent you need to stay on top of the constant barrage of threats to your organization. According to Cybersecurity Ventures, the cyber skills shortfall is expected to hit 3.5 million unfilled positions by 2021. This is one of the reasons why white hats are lagging behind the increasingly sophisticated threat landscape in the cyber arms race.

SOAR solutions can help organizations address the talent gap by lightening analysts’ manual workload and sharpening their ability to prioritize the most pressing threats and remediate them quickly.

Enrichment and Contextualization: Where SIEM Ends and SOAR Begins

There is a degree of overlap in how vendors describe the enrichment and contextualization functionalities of their SIEM and SOAR solutions. It’s common for both products to claim that they enrich, contextualize and help triage threats. But where does SIEM end and SOAR begin?

SIEM is all about detection. The amount of automation and orchestration required for swift incident response cannot be carried out at the detection layer. If a SIEM tool processes between 10,000 and 500,000 events per second — as it does in most cases — the computing resources required are simply not available to enrich this volume of data. So why can’t the enrichment take place once the SIEM tool has generated an offense or incident?

For the average enterprise, only about 80 percent or less of incidents originate from SIEM. It’s important to channel incidents generated by data loss prevention (DLP) tools, managed service alerts, phishing and investigations into one place so your security operations center (SOC) analysts or computer security incident response team (CSIRT) can contextualize and act upon them. SIEM tools are not optimized to support this alongside the mammoth task of analyzing enormous reams of events and data flows according to predefined correlations and indicators of compromise (IoCs). Endpoint detection and response (EDR) and threat intelligence platforms are not integrated, thus the SIEM only assists with part of the investigation process.

Lastly, case management is arguably the most crucial feature set within incident response. Cybersecurity playbooks have become enormously complex, and the level of effort and cost needed to build them into the detection layer is often prohibitive.

Why Detection Alone Is Not Enough

It goes without saying that well-calibrated detection tools give the incident response function the data it needs to remediate threats. But having well-defined incident response plans can also help sharpen and refine the rules and use cases you use to calibrate your SIEM solution. The benefits are bidirectional: What correlations and indicators are you looking for? Why are you looking for them? Once you find them, what is the incident response plan?

One of our clients recently enacted a protocol whereby detection use cases are only written if they have an associated incident response plan. If you want to write SIEM rules for the sole purpose of visibility and metrics, that’s all well and good. However, being deliberate and honest about this will keep your operations more streamlined.

If your function is willing to spend thousands or even millions on SIEM solutions but not prepared to deal efficiently with the alerts being outputted, what is the value of that investment? Why wait until your SIEM tool is churning out alerts before realizing that your team is overwhelmed?

Clients of ours that have run parallel SIEM/SOAR proofs of concept (POCs) have saved significant amounts of time and effort compared to those that have undergone an arduous SIEM POC only to have to follow up with another SOAR POC. In one case, a client even decided to switch off its SIEM solution until it had implemented a SOAR tool to help it deal with the torrent of alerts. Given that SIEM and SOAR are two sides of the coin that comprises security operations, why serve these POCs consecutively when they can be executed concurrently?

More from Incident Response

When the Absence of Noise Becomes Signal: Defensive Considerations for Lazarus FudModule

In February 2023, X-Force posted a blog entitled “Direct Kernel Object Manipulation (DKOM) Attacks on ETW Providers” that details the capabilities of a sample attributed to the Lazarus group leveraged to impair visibility of the malware’s operations. This blog will not rehash analysis of the Lazarus malware sample or Event Tracing for Windows (ETW) as that has been previously covered in the X-Force blog post. This blog will focus on highlighting the opportunities for detection of the FudModule within the…

Breaking Down a Cyberattack, One Kill Chain Step at a Time

In today’s wildly unpredictable threat landscape, the modern enterprise should be familiar with the cyber kill chain concept. A cyber kill chain describes the various stages of a cyberattack pertaining to network security. Lockheed Martin developed the cyber kill chain framework to help organizations identify and prevent cyber intrusions. The steps in a kill chain trace the typical stages of an attack from early reconnaissance to completion. Analysts use the framework to detect and prevent advanced persistent threats (APT). Organizations…

Defining the Cobalt Strike Reflective Loader

The Challenge with Using Cobalt Strike for Advanced Red Team Exercises While next-generation AI and machine-learning components of security solutions continue to enhance behavioral-based detection capabilities, at their core many still rely on signature-based detections. Cobalt Strike being a popular red team Command and Control (C2) framework used by both threat actors and red teams since its debut, continues to be heavily signatured by security solutions. To continue Cobalt Strikes operational usage in the past, we on the IBM X-Force…

What is a Red Teamer? All You Need to Know

A red teamer is a cybersecurity professional that works to help companies improve IT security frameworks by attacking and undermining those same frameworks, often without notice. The term “red teaming” is often used interchangeably with penetration testing. While the terms are similar, however, there are key distinctions. First and foremost is the lack of notice from red teams. Pen testing may be scheduled in advance to assess the ability of specific security measures to handle a simulated attack; red team…