This post is part of our current SOC research, but it also touches on our past SOAR research.
Here is the thing: when we looked at SOAR technology, we mostly saw more mature SOCs adopting the tech. This is primarily based on the fact that they “tried the SOC thing” already and know what their operational problems are. Hence, they can deploy a SOAR to solve those problems. In other words, they are ready to “force-multiply” with SOAR since they tried applying the force they had, and they know it needs some multiplication :–)
However, we did say mostly, didn’t we? We also saw a small number of organizations adopting SOAR at the time of their initial SOC build-out. Essentially, they start a SOC right with SOAR deployed on day one, a SOAR-native SOC.
Now, can this go well? Or will it explode just like IT GRC did when adopted with no risk management program or knowledge? Kaboom!
Let’s analyze it! First, imagine you have deployed some detection tech (like NIDS or NTA, EDR, and/or SIEM or at least CLM – sorry for the acronym soup) and some ad hoc processes (such as for alert triage), and, naturally, some people (like, you who is reading this), but no have formal standing SOC, to be sure.
Now you need to forge all the above “raw materials” into a fighting unit – your SOC. I think that starting with SOAR may work well. Here is why:
- Good SOAR tools come with playbooks that (lacking other choice!) you can use to start your own IR and alert triage processes
- Some SOAR tools can be used to support your ad hoc process, and then slowly evolve it to real playbooks
- A SOAR vendor or a consultant can come and build the process for you inside the tool; then you will have something that runs and not merely something you can read on paper (now, if it breaks…)
- You start documenting processes from the start (use SOAR as a system of record!), so you don’t hit that point where you stop and think “oh, now we need to stop and write everything we are already doing in an informal manner”
- You have performance and effectiveness metrics from the start, easier to track evolution and focus improvements where they are actually necessary (this one is big!) – it also makes this easy to maintain you “living business case” for SOC, a critical component of its success
- Easier to grow your SOC as new analysts will have the processes they need to learn already in place, as they do the job.
[Thanks to Augusto for his wise comments and additions!]
In this way, you can mature tools and processes in parallel, and hopefully not kill yourself in the process… All in all, is this a bad idea? No, it is not a bad idea. Is this a great idea? Perhaps not [philosophically speaking, it is better to grow your SOC organically and then automate, but it takes time]. But it is an idea that has worked well for some organizations and it may work for you too.
Posts related to our SOC research:
- Next Research: SOC, SIEM, and Again Overall Detection and Response
- Hybrid SOC Scenarios
- Can You Do a SIEM-less SOC?
- Is Your SOC your CSIRT? (by Augusto)
- Can You Do a SIEM-less SOC?
- SIEM Alternatives? What Are They? Do They Exist?
- SOC Webinar Questions Answered
- Our “How to Plan, Design, Operate and Evolve a SOC” Paper Is Published (from 2016 – now the update is under development)
- Our Security Orchestration and Automation (SOAR) Paper Publishes
The Gartner Blog Network provides an opportunity for Gartner analysts to test ideas and move research forward. Because the content posted by Gartner analysts on this site does not undergo our standard editorial review, all comments or opinions expressed hereunder are those of the individual contributors and do not represent the views of Gartner, Inc. or its management.
Comments are closed
Anton, good write up and I completely agree. I was reading enjoyably though, till suddenly towards the end this sentence hit me “Philosophically speaking, it is better to grow your SOC organically and then automate” — specifically “and then automate”. Your post does well to explain that SOAR is doing more than automation, so forgive me for nitpicking but I think its important to hammer that message, because while automation is an important element of it, a SOAR platform offers much more than that (SOC process mgmt, case mgmt, triage, collaboration, investigation, process documentation (even when manual), KPI measurements, etc). So I think rather than referring to it as an automation tool, a good way to describe SOAR is as a security operations management system, with the ability to apply automation to processes where applicable.
Well, you got me 🙂 This point was the weakest logically of the entire post.
I think my position “grow organically and then automate” needs to be evaluated more. Perhaps I was scarred for life when people without any risk / sec programs bought IT GRC tools and then expected to be secure and compliant “because GRC.”
So, OK, MAYBE it is not philosophically better but it saves you from excessive reliance on tools as a crutch for lacking process…
Good stuff. I don’t think the concern is about lack of process for new entrants deploying SOAR. Quite the contrary. An organization deciding to put together an incident handling and hunting solution today from scratch is not encumbered by past processes, so it can start right off the bat with the best available solution, without worrying about past processes. It is all about people, after all.adoption will be easier and faster that way.
Thanks for the comment. Indeed, “lack of process” may mean “no stale process to adopt” and no old guard [who sticks to it] to fight.
Thanks for bringing some light to this topic, Anton. We tend to see both, but I’m curious whether you anticipate certain types of organizations (size? industry? security maturity?) as being more likely to build a SOAR-native SOC than others? I’m curious as to what defining qualities you think might make an organization more likely to be successful.
These are exactly the questions we have 🙂