How far can you take SOC automation?
by Abdullah Bin Zubair
Background
For a few years now, Security Orchestration, Automation and Response (SOAR) has offered the promise of greater automation in Security Operations Centres (SOCs). Tools like Splunk’s Phantom, Exabeam’s Incident Responder, and Palo Alto’s Cortex XSOAR are becoming more popular.
From the very first SOC onwards, the challenge of how to handle the huge volume of data that needs to be analysed has always been present.
As SOCs have grown in scope and complexity, they have driven a requirement for an increased number of skilled staff. Those skills have generally been in short supply. All of which adds up to increasing the cost of SOC operations.
Benefits of SOC Automation
SOC Automation offers a number of benefits –
- Reduced demand for costly human skills to work on repetitive tasks.
- Increased accuracy and consistency as natural variability of human response is automated.
- Increased speed of response as systems drive responses and automate previously time consuming tasks.
- Improved SOC morale as mundane and repetitive tasks are delivered by systems rather than by people.
The question that this leaves us with is how far can that automation go? How much can we trust the machines? And where do we need a human in the loop instead?
With many SOC teams already following prescriptive playbooks for many activities, turning those ‘human instructions’ into ‘machine instructions’ seems a logical step, but one many organisations seem hesitant to take. Why?
Risks
With a little thought, it’s easy to come up with a few risks that might deter you from making widespread use of automation.
Unintended consequences. Automation is often based on the idea that taking a particular action in a particular scenario is always the right response. But what if it’s not?
Runaway automation. Once automated defences start interacting with automated attacks, things could get out of hand pretty quickly.
Bad outcomes due to a changing environment. What happens as things evolves? We all know that both the security threat and our own environments are in state of constant evolution. What if something changes and it results in the automation taking an action that isn’t appropriate in that changed environment?
Is the technology ready? All technology goes on a maturity journey, investing in the technology that has just reached the right level of maturity for your situation is the key to any successful technology strategy. Is this the right moment to innovate around SOC automation?
How confident can I be that what I build doesn’t have to change so regularly that it isn’t worth the effort? Automation is ultimately designed to save time, but if the build effort is significant when the rate of change is the environment is high, it could cost you time, not save it.
Approaches
Given the potential benefits of automation, and the risks of being left behind as innovators blaze a trail, there are a number of ways organisations can de-risk security automation –
Semi-automation as a bridge to full automation. The ‘safe’ starting point for automation is to build all of the automation, but still have a human in the loop making the decision to run the automation. The price is speed of response, but the reward is a circuit-breaker in the automation just in case.
Data driven decisions. By carefully analysing the volume and cycle time of individual scenarios, it’s possible to identify which automations will be most impactful, and by reviewing playbook update frequency, you can identify the more stable scenarios for automation.
Taking a step by step approach. In all changes, evolution can be less impactful than revolution. Working through phases of automation, increasing the scope of automation in steps and measuring the benefits as the program matures.
It’s a journey, not a destination. Seeing SOC automation as a programme of work that is going to be ‘complete’ one day in the future is ultimately going to create something that degrades over time, so building an effective maintenance and improvement program is a must.
SOC Automation Journey
RiverSafe has adopted a 6 step approach to SOC automation, increasing the value and impact of automation at each step.
| 1 | Automating data transfer to helpdesk tools (replacing manual data recording tasks) |
| 2 | Automating reconnaissance (automating the process of collecting data to support the analysis process) |
| 3 | Streamlining analysis and testing (e.g. automated sandbox detonation) |
| 4 | Automated defensive measures against identified external threat sources (inhibitive blocking or limiting or specific IP, net blocks, or external user entities). |
| 5 | Automated defensive measures against identified internal threat sources (locking down suspicious accounts or systems) |
| 6 | Automated protective measures for internal systems (e.g. disabling or protecting at risk services) |
For many SOC teams, the journey to step 3, where automation focusses solely on non-invasive measures is easier to contemplate, and has already been fully or partially achieved in some organisations.
Going beyond step 3 is where many SOC teams have drawn a line, wondering if they might be about to grab the third rail going any further. But, to paraphrase a line from The West Wing, the third rail is where all the power is.
