Vaughan Shanks, Cydarm CEO, says the resourcing challenges of security operations teams are nuanced and unlikely to be substantially solved using automation alone.
We know there’s a security skills shortage. We’re constantly reminded of it – the gap between supply and demand isn’t closing and a high number of data breaches and ransomware incidents are occurring as a result.
Automation is commonly marketed as a panacea for the skills shortage to lift the technical burden placed on cybersecurity operations analysts and free up their time to focus on higher-order tasks or remove the need for analysts altogether.
That looks immensely attractive to organizations looking for quick ways to do the proverbial ‘more with the same (or less)’.
But anyone who’s spent any time in cybersecurity knows automation is a more complex challenge than it seems and can have unintended consequences. The whole reason security operations teams exist is because the existing controls on our perimeters, endpoints and servers have been unable to block intrusions.
While automation is useful in some limited contexts, security teams cannot abrogate their risk management responsibilities by delegating decision-making to a machine. Nor can automation provide an account of what is happening to a senior decision-maker, supply chain partner or regulator.
In addition, the skills required to configure and maintain automation often requires hiring security engineers, and these are harder to come by than SOC analysts.
A capability maturity model (CMM) for security operations can assist in determining what is best handled by humans or computers.
A base level of human agency will always be required for threat identification, triage and response. But automation can be of utility where processes are well-defined and the effect of automating them is well understood. A CMM can be used to create the right mix and balance to constantly evolve and continuously improve the mix as operational requirements change.
Down the wrong path
Several risks arise when organizations use automation to try to stretch the existing resourcing of security operations. For organizations that have already started down this path, some or all of these may already be familiar.
The first tell-tale sign automation has been pursued too early is that processes are not well-defined, leading to unexpected complexity or outcomes. Automation that results in delegating decision-making around mission-critical issues to an algorithm is inadvisable and will come unstuck the minute the computer makes a ‘wrong’ decision, for example locking down an executive’s workstation at a critical time due to false detection of malicious activity. It’s not just that a human needs to remain in the loop for decision-making – it’s that people need to be making these critical calls, not algorithms.
A second sign is cost and complexity hurdles. If you want to automate anything you need to have systems that interoperate. If the systems in the security operations environment use different ontologies and data formats, that poses a huge integration challenge. Also, the setup of automation itself isn’t automated. Organizations need to find skilled people to work with internal domain experts to configure automated systems. Labour costs may rise with an automation program of work.
Thirdly, if the automation creates as many, or more, risks than it solves. Automation inevitably requires a high level of authorization so it can take administrative-level action. That action needs to be tailored; if attackers suspect predictable machine-generated responses to what they’re doing, they could find a way to exploit the automation. For example, spoofing malicious data to cause resources to be blocked or locked as a denial of service. Automated systems with high levels of authorization, enabled by stored credentials, are risks themselves. If they’re ever compromised, an attacker will use the authorization against the organization to effect lateral movement or actions on the objective.
Capability maturity, case management and collaboration
The use of a CMM can help organizations avoid premature use of automation, and can be used to underpin decision-making as to which parts of operations require a higher degree of human agency or involvement
All CMMs have five distinct levels: initial, repeatable, defined, managed and optimizing.
At the initial stage, processes may be new, undocumented and single-person dependent resulting in ad hoc execution. The immediate step is to document at least parts of the process so that they look repeatable, so they won’t be performed differently each time.
Security teams that automate prematurely often move from repeatable (level two) to optimizing (level five), skipping two important middle steps. They end up automating processes that are not yet standardized and that haven’t been proven capable from repeated use over time.
By following a CMM, teams can better define and test a process before attempting to automate it. Performing the interim steps may also lead teams in a different direction, which is likely to lead to a more judicious overall use of automation.
A collaboration and case management solution has a part to play in this, ensuring that the more people-driven aspects of security operations are well-supported and that the workflow of human-machine elements is mapped out and understood. In these solutions, teams set up repeatable workflows and playbooks for dealing with different types of alerts or incidents.
Detailed workflow mapping means everyone understands their contribution and the different skills of the team can be used effectively. The cognitive burden on senior responders is reduced by not having to remember everything, and less experienced team members can be more productive and independent. These process improvements lead to better, faster and more consistent security operations.
