Hello Readers!! Today, let’s talk about SOAR – Security Orchestration, Automation, and Response. SOAR attempts to address the cross-platform automation and response problem in enterprise security. The technology has been around for 5+ years now and is gaining adoption after its turbulent initial years.
In Q4 2022, Query conducted a series of discovery interviews with mid to senior level security professionals working in organizations with a SOC. Below, we have extracted the learnings, successes, and challenges of SOAR implementations in the industry based on their responses. For more details on how we conducted these discovery interviews, please refer to my previous blog, Top Three MDR Investigation Challenges.
Now let’s go through what we heard…
Success: SOAR is getting real with a budget and a niche.
Creating and running a SOAR project is becoming a key CISO and SOC goal, and organizations have allocated a budget for SOAR. While SIEM and EDR have bigger budgets, SOAR is gaining the opportunity to exist and complement them with its Playbooks. The objectives are to have Playbooks process and evaluate security events, bring contextual data, and run an automated response loop. Our interviewees said they are planning or already have SOAR projects at various stages of implementation. This is a big win and validation of SOAR as a product category.
Learning: The first iteration failed. This is the second iteration.
For several organizations, we found this is not their first attempt at SOAR. It was typical to hear that a prior project – one or more years back – had failed. The new project is being targeted either with their primary security vendor’s acquired SOAR or with a “nextgen” niche SOAR vendor.
The prior failure did leave a bad taste, and we often heard the pun “SOAR makes me sore!” This time around, organizations have more realistic expectations.
The fact that those sore organizations are attempting a new project again proves the problems SOAR is promising to solve are real. Problems like high alert volume, too many analyst priorities, lack of consistent processes, and the like are being faced in most mid and large environments.
Challenge: SOAR is a long and complex project that requires engineering resources, both upfront and ongoing.
It used to be a given that you needed python developers to implement SOAR. Then came the ‘nextgen’ flock of ‘low-code’ and ‘no-code’ SOAR vendors with claims that their deployments don’t need python developers. But, even in the best case, we heard that automating analysts’ investigation processes is a complex, time-consuming task that requires specialized engineering resources to plan, program, and test Playbooks. These resources are needed not just for initial deployment, but on an ongoing basis. This hugely impacts the costs and practicalities of the SOAR project. Typically these are devsecops and platform engineering resources that require additional headcount and are not the organization’s SOC analysts.
Challenge: Need to invest in training.
The above identified resources still need to be trained on the vendor’s platform to be able to capture the investigation processes and author Playbooks. Funding the specialized resource, training, and on-going engagement really limits SOAR projects to be feasible only for large organizations and some mid-organizations in specialized sectors like finance, technology, etc.
Learning: SOAR first requires mature “as-is” processes to be successful.
Before implementing Playbooks, organizations should invest in having well-defined and developed security processes. Automating a broken/immature workflow is just automating a problem and will lead to GIGO (garbage-in, garbage-out).
Challenge: Data mapping, quality and consistency is a big problem.
To be effective, SOAR platforms rely on accurate, consistent, and complete data. We heard this is a big challenge in dynamic environments with disparate data sources. Lack of a common data model across vendors is not a SOAR-specific problem but a general cybersecurity industry problem. However, it impacts SOAR most as it is in the middle of connecting and automating the idiosyncrasies of data from disparate vendors across their different product versions and upgrade cycles.
Some nextgen SOAR vendors have implemented their own proprietary common data model to deal with this problem. Recently there is hope with OCSF, a community-driven cybersecurity data schema over which I’ve written a previous blog “Need to model Cybersecurity Data? Let’s walk through OCSF!”. We have seen vendors jump at OCSF but have not heard of any SOAR that has already made a release available with OCSF adopted.
Challenge: Limited opportunities for application of SOAR.
Specific use cases are great candidates for SOAR, such as classic phishing Playbooks, but teams struggle to broaden good coverage of the SecOps practices. Even within a particular use-case like phishing, there are too many decision branches and only a few get implemented. These implemented branches are the typical high volume, repetitive, well-scoped ones, so they are extremely valuable. However, the more complex branches leave more investigation work back for the analysts where they need to manually investigate their phishing workflow.
Overall, what we understood from the partially automatable phishing decision tree is that it validates the basic need for SOAR to handle some of the simpler high volume security events, and validates the need for analysts to do manual investigation of non-trivial scenarios.
Learning: The bots are not going to replace the security humans.
As discussed in the above phishing use-case, it’s rare that a process can be completely or even mostly automated. The heuristics we heard were around 1-3 Playbooks that got implemented. Organizations should not consider SOAR as an analyst replacement but as a value-add tool that assists them with specific repetitive tasks such as enrichment with threat intelligence.
Learning: SOAR is being used for Alert Triaging and Case Management.
As we saw above, the security process automation is limited. A more grounded purpose of the Playbooks can then be to just update tickets, route alerts, and enrich with threat-intelligence for further analysis. This does not require deeper use-case driven automation and, if implemented correctly, can help the analyst more efficiently triage alerts.
Case management, or security investigation ticketing, has turned out to be a common use-case for SOAR. Interestingly, many of the SOAR products are not designed for this kind of security alert triage, prioritization, and collaboration workflow. But since SOARs do promise access to cross-platform contextual data, they are being shoehorned into this.
Challenge: SIEM, XDR, and MDR are nibbling to make SOAR their feature.
SOAR has overlap with SIEM, XDR, and MDR, and they are all trying to make it a feature of their platform. New SIEMs and XDR are having built-in “SOAR-lite” capabilities; or their vendors have acquired and integrated “SOAR+” that has greater integration with their own stack. Beware that this is at the cost of genuine vendor neutrality which was the original promise of SOAR!
MDRs are attempting home-grown SOAR “service” by augmenting automation with humans sitting behind the scenes with the service provider. Refer to my recent blog for related MDR Investigation Challenges.
Summary and Recommendations
Through our discovery interviews of security professionals employed in SOCs, we learned that SOAR shows promise, but is not a silver bullet for the security team’s efficiency and productivity problems. It requires significant upfront engineering and config effort, and ongoing resourcing. We heard from multiple organizations that they needed to add one or more dedicated security engineers to care and feed their SOAR platform. It was unclear to them whether they were getting ROI as a result…their sense was it was breakeven at best.
Are there approaches to complement SOAR and improve analyst efficiency?
Evaluate adding a “Federated Search” solution next to your SOAR. Federated search can give analysts direct access to parallel-query data from multiple platforms and get a collective answer from your combined tools stack. The free-flow querying and ad-hoc pivoting can often give analysts what they need, helping them investigate scenarios where you don’t have/need a Playbook.
I would love to get your take on our learnings above. Does your organization have an active SOAR project? Have you considered Federated Search for analyst efficiency? Please reach out to me or contact Query (contact@query.ai) to share your experiences and thoughts.
