17 Oct Gartner Market Guide for SOAR – Key Points by Phase, Part One of Four: Detect
In the Gartner Market Guide for Security Orchestration, Automation & Response (SOAR), published June 27, 2019, (ID: G00389446, by Analyst(s): Claudio Neiva, Craig Lawson, Toby Bussa, Gorka Sadowski) Gartner recommends Security & Risk leaders should evaluate SOAR platforms:
“SOAR solutions are gaining visibility and real-world use driven by early adoption to improve security operations centers. Security and risk management leaders should start to evaluate how these solutions can support and optimize their broader security operations capabilities.”
As part of their Market Guide for SOAR, Gartner provides an overview reference model for, that breaks the solution scope into four phases – Detect, Triage, Respond and Prioritize. This is the first of a four-part blog series dedicated to highlighting key points about each phase prospective buyers should consider when evaluating and selecting a SOAR platform. See, “Figure 1. SOAR Overview,” below to see this overview reference model.
Figure 1. SOAR Overview
To fully appreciate the key points in each phase, especially the first phase in this series, “Detect” phase, it’s important to understand the context of where the SOAR platform typically sits in the overall enterprise information flow within a SOC. For the purposes of this blog series, we will focus on the Enterprise SOAR use case. While the processes are similar for Security Services Providers (MSPs, MSSPs, and MDRs), they differ due to the multi-tenancy, tool variability, and process variations (e.g., how much automation is the Service Provider entitled, authorized to execute).
Key Point 1: SOAR ≠ SIEM
From the Enterprise perspective, it’s important to clarify that SOAR platforms are not SIEMs. They do not ingest high volumes of raw log data for storage, processing, normalization, de-duplication, and correlation. SOAR platforms typically ingest a curated output from a SIEM or Log Analysis platform of meaningful Alerts or Events generated through analysis and correlation that cross a risk threshold that requires further validation, disposition, and if needed, containment and remediation actions.
Key Point 2: SIEMs/Log Analysis Tools aren’t the only source of “Alerts”
SIEMs/Log Analysis platforms aren’t the only source of Alerts for a typical SOC. Most SOCs, or Cyber Fusion Centers (CFCs), as some are choosing to call them, are actually ingesting multiple streams of unnormalized Alerts from several sources.
See, “Figure 2. Typical SecOps Data Flow,” which highlights the typical data flow in a SOC/CFC pre-SOAR deployment.
Figure 2. Typical SecOps Data Flow
Let’s walk through the typical risk sources many enterprises SOCs/CFCs must address:
- MSSP Alerts: Many Enterprises augment their monitoring with an external third party, typically established as a need to achieve compliance
- Curated SIEM Alerts: As mentioned above, SIEMs or Splunk native, Splunk ES, and custom-build ELK stacks are used to ingest, normalize, de-duplicate, analyze, and correlate logs in to a subset of meaningful event
- User-submitted Phishing: Most enterprises have trained their users to be suspicious of email, and empowered them with “right-click to report” or a shared inbox to forward suspicious emails, which creates a challenge, particularly if a campaign targets thousands of employees in short time period
- Threat Intel Notifications: While many very large enterprises have adopted Threat Intelligence Platforms (TIPs), many enterprises receive notifications from ISACs or other threat-sharing forums via email. These pose yet another stream of operational risk
- Phone Calls/IT Tickets: SOCs/CFCs must also deal with the inevitable phone call, “hey the CFO’s laptop is hit with Ransomware, we need help,” as well as simple Help Desk calls that are escalated from the ITSM platform once initial investigation leads Tier 1 Help Desk Analyst to believe it’s a Security issue
- Confidential Investigations: Many SOCs/CFCs leverage their expertise and forensic skills to internal investigations, such as an HR investigation of misconduct, or an eDiscovery request for employees related to pending litigation
Key Point 3: Apply Pre-Triage Normalization & Rationalization:
The third key to managing the “Detect” phase in the Gartner model is to normalize the disparate Alert sources listed above into a common information model, such as Open Source Security Events Metadata (OSSEM), and apply an initial normalized risk-score. The next step is to rationalize these Alerts first by deduplicating them (e.g., 5,000 employees all forward the same suspicious email as Phishing), and second, setting thresholds for initial normalized risk-score, or other criteria, which limit the SOC/CFC workload to only those Alerts that qualify for additional treatment.
Gartner has established an industry standard for defining the tools applied to improving Security Operations effectiveness and efficiency with their SOAR research. The most recent Gartner Market Guide for SOAR re-iterates a helpful baseline model for understanding the SOAR domain and its continuous lifecycle by identifying four distinct phases – Detect, Triage, Respond, Prioritize. For Enterprises and Security Services Providers looking to evaluate SOAR platforms, there are several “keys” to success in each phase. In this blog, we’ve examined the three keys to the first phase, “Detect,” which were:
- SOAR ≠ SIEM
- SIEM’s aren’t the only source of Alerts
- Ensure to apply pre-Triage Alert normalization & rationalization
In the next blog, we’ll examine keys to success in the “Triage” SOAR phase. What do you think? Contact us to let us know.