SOAR is Boring
I have a confession to make. I spent a lot of time and effort trying to convince people that SOAR (security orchestration, automation, and response) is a cool, fancy technology. I said buzzwords like “automation” and “single pane of glass” to get important people to nod their heads and gain traction for my work. If I could convince people SOAR was some kind of futuristic, life-changing tool like a quantum computer or homomorphic encryption, then they would buy into it. Or so I thought.
The truth is, SOAR is extremely boring. SOAR is basically just a web application. The automation that you can do is just basic computer coding. The integrations with other tools just leverage their existing APIs. In fact, beyond a front-end web-app, SOAR provides you almost nothing on its own. It relies entirely on other tools to receive incidents, enrich them, and provide incident response.
Now that I have come clean. You can go unplug your SOAR tool. Just leverage your world-class software developers and fantastic DevSecOps program to build your own security operations interface. Have them document it and provide training documentation and support to the analysts. Add all of this custom code to your code base for continuous updates and maintenance. Oh, you have a full time business goal other than SOAR? That should not be a problem, just hire more developers, tech writers, and architects. Oh wait, now your custom code costs more than the SOAR license cost. Hmmm, maybe you can hold off on unplugging the SOAR tool.
Much like how Anton Chuvakin told us that custom security data lake projects will fail, I am here to tell you that your custom SOAR project will also fail. The value of SOAR is not in novelty of the technology. No SOAR tool that I have seen has any magic behind it. The tools implement standard software development and computer architecture practices. A reasonably sized software team could definitely build their own SOAR tool without access to some fancy proprietary information.
So what is the value of SOAR? Counterintuitively, the value is in its commonality. As the number of Security Operations Centers continues to grow, the customer base for SOAR tools also grows. Most if not all of these security operations teams want similar things. They want to automate mundane tasks, collect incident information into reportable cases, collaborate with other members of their team, and work with their choice of different security tools on the network. They prefer to do this from a single application. What else do they want to do? Oh, they want to focus on things like threat detection, hunting, and incident response.
So can your security operations team go become its own SOAR vendor and build a tool that meets all of those requirements? Absolutely. There is no magic to it. Just learn software development, scalability, user experience, DevSecOps, and APIs of hundreds of tools, then start building away! Make yourself a large codebase which you have to maintain for yourself as the sole customer. Make sure to constantly check for new vulnerabilities (and patch them quickly) and grow features as the market changes.
I truly believe this is a terrible idea. I have said many times that buying (or at least leveraging open source) common use software is like crowd-sourcing. If you crowd source your mom’s birthday gift, then you can get her something nicer than if you buy it yourself. You are not limited by your own budget to contribute to that gift, the gift’s cost is limited by the collective budget of all of the contributors. That means you can spend less and the gift can be nicer. So go get yourself something nice, and pay less for it — even if it is boring.
