We Can Automate the Action, Without Automating the Decision…
Over the past years I have been heavily involved in research on the topic of security automation. One of the consistent feedback points has been that automation is highly desirable, at least by security teams. But this desire has been inhibited by doubt and fear. Doubt about the accuracy of the detection of threats, and fear of the consequences of automating the containment or mitigation responses and the prospect of detrimental impact and damage resulting from doing this wrong.
For those of us who have been active in cybersecurity for a long time, this is not a new phenomenon. We remember the promise of Antispam and Intrusion Prevention Systems, and the chaos these caused based on too much confidence in their ability to reliably identify anomalies and attacks.
Many organizations own an IPS, but run it in non-blocking mode, demoting them to Intrusion Detection Systems. This trend has not abated, with organizations that have automation capabilities built into existing technologies such as Security Information and Event Management, Endpoint Detection & Response and Security Automation & Orchestration solutions not trusting these to automate much beyond basic tasks such as sending out notifications or running a threat intelligence query.
This despite detection capabilities having dramatically improved, especially using behavioural modelling and machine-learning driven approaches. This really comes back to the adage that you should never try and solve a social problem through technology. Because the problem is not based on technology – it is based on trust, or rather the lack of it. The three basic principles involved in this are:
The SecOps team can assess the impact of the risk, but NOT the impact on production.
Let’s visit the first of these principles. The SecOps team sitting in its ivory tower, focused purely on the risk and impact of the threat, will struggle to build up and maintain an awareness of what is going on in production. Is the affected system mission critical, is the system unstable, or is it a legacy system? Is the system currently being used to process the annual financial reports, or is a paying customer using it?
Disabling a seemingly innocuous user account may seem simple – but that user account may be used to run critical processes. Dependencies, complexities and unknowns are the bane of automation. These are all data points that most security operations team either lack, or may be stale – but can have an impact on how the incident response or remediation process must be conducted. It’s not that anyone is advocating that the incident or vulnerability do not have to be addressed at all – but this may require additional time or a specific way of doing it.
You can automate the actions, but not the decision
Of course, the actual containment or remediation response is not the only thing that can be automated. We can automate a wide variety of tasks, including prioritizing an incident, fetching additionally required information and context or notifying stakeholders. In addition, we can automate the action itself if it has been vetted. In the simplest scenario, this means sending out a notification to the IT Operations team that outlines the issue – what is the problem, what is the potential impact and what action is required to resolve it – and asking them to either confirm that this can be executed or to reject the automated action to do it manually. We can automate the action, without automating the decision.
You can expand automation as trust and confidence increases
The downside to this is that IT operations are frequently overloaded, so that a handoff occurs from SecOps to IT Ops with a long delay in response. In the case of incidents such as ransomware, this delay can mean the difference between containment and disaster recovery, between an incident and a full-blown breach. It seems counterintuitive that a group of people that is overloaded with work would avoid a means to make their life easier, but human nature is what it is. But even there, we can help to alleviate the doubts and concerns and build trust and confidence.
This can be achieved by keeping track of what actions are done manually – how many times the same action was done by a human instead of a machine – and working out the difference in time and effort between the two. The idea is that if someone receives the same notification for similar incidents requiring the same manual actions a multitude of times, we can demonstrate to them that this could have been safely automated. After all, we have the audit trail to prove it and the data to build a business case. More importantly, we will also garner data on what and where we can’t safely automate.
An automation may be safe in one business unit, but not acceptable in another. This process must support granularity, whether when gathering metrics or configuring the automations. Ideally, whatever automation technology you use must support this approach and provide the metrics that this requires. Technology can help to build trust, but when all is said and done, it’s going to require that it is experienced by the people you expect to trust you.
