28 Oct Gartner Market Guide for SOAR – Key Points by Phase, Part Two of Four: Triage
In the Gartner Market Guide for Security Orchestration, Automation & Response (SOAR), published June 27, 2019, (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 second 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 second phase in this series, the “Triage” 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: Risk is Not Static.
Whether the use case is an event-triggered Alert (e.g. potential endpoint malware infection) or proactive Threat Hunting (e.g., mapping and finding every instance of a new IOC throughout the environment and the backlog of existing Alerts/Incidents, logs, etc.), the risk associated with these use cases isn’t static. It changes as new information is gathered, either through machine or human enrichment. Many SOAR solutions ingest correlated risk signals and assign (or simply inherit) a risk rating from the originating source. However, these ratings often don’t automatically change as new context is generated and captured. To be effective reducing cyber risk with SOAR, risk-scoring must be adaptive, particularly with the limited human cycles available to every SOC or CFC.
For example, imagine an Alert comprised of analysis from several failed database server login attempts from locations that are not a user’s typical work locations. The incoming Alert has a risk score assigned to this type of event, and it’s slated int a queue for automated enrichment and, if necessary, human review prior to escalation. Automated enrichments are run that determine that:
- The source IPs of the failed login attempts are associated with a known nation-state threat actor,
- The user associated with these failed logins, has privileges to significant sensitive data, and
- There have been network DLP policy violation events generated during the corresponding timeframe of these failed logins.
Obviously, the risk associated with this Alert if significantly higher after these enrichments have been executed. As a result, the priority for addressing this risk with human decision-making and intervention must be higher as well. Using a static risk score, this might linger before being addressed, and that increased risk exposure window might be the difference between a minor set of automated containment actions or major breach event. The ability to dynamically adapt risk-scoring, and the associated priority for applying the human intervention the Gartner Market Guide highlights as necessary, is critical to best leveraging the limited cycles available.
Key Point 2: Use Human-Machine Teaming to Validate Alerts as Incidents:
Many of the risk signals ingested by a SOAR platform cannot be assigned a disposition, despite having run automated enrichments, and/or statistical and machine learning-based analyses. The process of coming to a conclusion and the decision to convict by declaring an Incident from one or more correlated Alerts, involves a human investigating and validating the level of risk, then deciding if the thresholds and criteria for taking action has been met. Once that decision is taken, this triggers the containment and remediation workflows, again, which will likely require human intervention, at a minimum in the form of approvals for production system changes.
This “Investigation” capability as Gartner refers to it, is a distinct and separate process, that requires different application features, than the automated enrichments and triage. A useful analogy is police work. If all the cops had to do was plug in some data to a workflow, and out popped the perpetrator, there’d be no need for detectives. Similarly, in Cyber Security, the truly “low and slow”, most nefarious and insidious infiltrations require the ability to find clues, pivot to investigate, find more clues, etc. All of this may result in declaring an Incident. But it might also lead to a decision, which must be documented and justified, that the risk wasn’t valid (a false positive) or didn’t meet the criteria for escalation. Mature SOCs/CFCs segregate this Triage, Investigation and Response work logically, and sometimes physically by having separate tams managing them, and the recognize the need to logically working these investigations without necessarily declaring an Incident. That’s important because often times declaring an Incident adds many additional compliance and regulatory steps to the process, which may not be needed.
See, “Figure 2. Mature SecOps Process Model,” which highlights the typical SOC/CFC validation and escalation procedure.
Figure 2. Mature SecOps Process Model
Key Point 3: Sharing is Caring:
Whether the source is organically generated intelligence from the on-going Triage, Investigation and Response processes described above, or if it’s the result of threat hunting based on indicators of compromise sourced from a third party (e.g., ISAC) or a Threat Intelligence feed or platform, the resulting indicators and their meta-data (e.g., where seen, associated Alerts/Incidents, etc.) must not only be captured and tagged, they must be rated according to various methods (e.g., Traffic Light Protocol or TLP) and available for sharing via automation. The key to this sharing beyond adopting standard languages and transport such as STIX and TAXII, is the adoption of a standard data model. The Open Source Security Events Metadata (OSSEM) is a community-led project that focuses primarily on the documentation and standardization of security event logs from diverse data sources and operating systems. Adopting a SOAR platform adhering to this model is essential to the sharing needed to ensure better collective cyber defense across industry sectors, geographies, and nations.
Syncurity believes more effective Triage is the key to unlicking the most value in SOAR. The faster and more effective this process is executed, the smaller the risk exposure windows across an enterprise or a Service Provider’s client base. However, the Triage process must dynamically assesses risk, facilitate human-led investigations, and be built on an industry-standard data model in order to provide the maximum risk reduction and cost savings.
Syncurity also believes these key points are supported by the Gartner SOAR research and Market Guide. For Enterprises and Security Services Providers looking to evaluate SOAR platforms, the “keys” to success in the Triage phase are:
- Dynamically Re-assess Risk
- Use Human-Machine Teaming to Validate Alerts as Incidents
- Data Model Matters
In the next blog, we’ll examine keys to success in the “Respond” SOAR phase.
What do you think? Let us know at https://www.syncurity.net
Gartner, Market Guide for Security Orchestration, Automation and Response Solutions, Claudio Neiva, Craig Lawson, Toby Bussa, Gorka Sadowski, 27 June 2019. Gartner does not endorse any vendor, product or service depicted in its research publications, and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner research publications consist of the opinions of Gartner’s research organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this research, including any warranties of merchantability or fitness for a particular purpose.