Deploying a SOAR and building an automation roadmap

Security Orchestration, Automation and Response (SOAR) is becoming an increasingly common technology in the arsenals of SOCs and Blue Teams. Like most Cyber technology it isn’t simply a matter of plugging it in, turning it on and receiving boundless value back from the tool.

So how should you go about implementing a SOAR and what should your strategy be? I’ll impart some of my experience and thoughts over the next few paragraphs.

Measure Your Success

Technology shouldn’t be implemented without a clear goal in mind; this usually follows a business case process so by the time you own a license key you have an idea of why you are implementing a SOAR.

Some example/common goals could include:

• “I want to increase my SOCs capacity by X%”
• “I want to reduce my cost of sale for the services I offer by Y%”
• “I want to reduce my time to detect/respond to an incident to Z minutes”

There are many goals out there and you may already have a few of them in mind but make sure you include definitive success criteria so that your efforts can be quantified. The important thing when you come to implement the tooling is that you know how to measure your goals. The clarity early on in the process provides you the following benefits:

• You can demonstrate clear return on investment.
• It helps you define your automation roadmap more clearly.
• Gives you a way of ensuring the scope of the tool is not hijacked — often this comes in the guise of putting a fix for a situation into a SOAR playbook which should actually be resolved elsewhere. A SOAR playbook is not a replacement for a process that is not fit for purpose.

Measure your goals often, I’d recommend at least monthly to avoid any surprises and allow you to correct the roadmap if necessary. Make sure you set some measurements that help you accurately quantify the success of your goals; bare in mind if you use things like “time saved” you are at the mercy of how much work there is that period to do I.e. less SOC alerts one month can show a downward trend in time saved during the period, which does not paint an entirely accurate picture.

Your Roadmap

Having an automation roadmap is key to enabling continued value from your efforts & technology choices. You should make sure someone is on the hook for delivering on your roadmap, it’s really quite a challenge to balance adding automations and a regular day job.

Consider how you are going to build your roadmap, how are you to know what to automate next? Everyone will always have great ideas on cool automations you could make but in my experience I found that starting small and Keeping It Simple Stupid (K.I.S.S) will yield the best results.

If I can offer another piece of advice here it would be “evidence your roadmap”. Using your goal(s) and measurement, you can start to create a roadmap as you can target the items that deliver on your measurement.

Here’s an example; let’s take the first goal I wrote which was to “increase capacity of the team by X%”. First let us assume that X is 20% and that the team is 5 strong, and that they work 40 hours a week. That means you want to target saving 40 hours a week; so everything on your roadmap should have an “estimated time saved” assigned. This will not only help you prioritise the roadmap but give you a way of seeking out opportunities that you, and others, can be assured will deliver on your goals.

The Three Pillars of SOAR Playbooks

Finally, I wanted to touch on my three pillars of SOAR playbooks. I differentiate SOAR Playbooks into three groups, this helps me determine which initiatives would be the most effective in helping to achieve the targets of each objective. Here’s the three pillars and some examples of questions I use to find those opportunities:

Detect Faster

• How can I enable the analyst to identify bad actors quicker?
• How can I lower my “Mean Time To Detection”?
• What does the analyst need to know to triage this correctly?
• What sources of information are humans going to look at to qualify alerts?

Respond Quicker

• What response is my organisation carrying out most often?
• What steps of our incident response playbooks do humans not need to be involved in?
• How to I enable to humans to make decisions on actions and not spend their time enacting the actions themselves
• Who needs to be kept in the loop on decisions/actions and how often?

Remove the Mundane

• What processes are the SOC doing that don’t require human input?
• How do I shift people from performing actions to performing approvals/decision making? Allowing the product to enact the appropriate action.
• How can I enable people to be more proactive and less reactive?

If you’ve been looking at acquiring a SOAR tool or you’ve already got one, these techniques and approach should help you get the most out of it.