SOAR-native SOC, Can This Work?

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