Identification of use cases – an analyst or cyber security information office will help an organisation to determine the location of its pain points. This is particularly true for SOC analysts who can recognise what systems are tedious and repetitive, and therefore which are the steps that can easily be automated. It’s all about the timing, using automation to speed up repetitive or dull tasks that haven’t previously been automated.
Preparing the workplace – most SOC teams will already have documented incident response procedures tailored to any specific threats, such as ‘how to handle a phishing incident’ or ‘what to do if an employee’s credentials have been stolen’. There could be a number of tried and tested steps involving both manual and automated tasks across various tools, people and processes, and the business’ workforce knows that addressing the incident is a simple case of working through the relevant steps.
Technologies and integrations – with the use cases and workflows in place, the next stage is to consider the integration with various third-party tools that will contribute towards the success of the automation itself. This means integration with threat intel, vulnerability management, active directory and email etc, in order for the automated incident response processes to work as seamlessly as required.
Start with the small stuff – focusing on the smaller, more manageable and easily automated problems first is better than trying to automate important and critical systems straightaway. Once the smaller automated process has been configured, it can be tested, retested and implemented. Then it’s possible to move on to more complex automation processes. Integration requires further testing in the SOC platform, so that it fires playbooks when specific conditions occur.
Measure – once testing and implementation are complete it’s important to measure improvement in mean time to resolution or MTTR. This is done by assessing similar events and reviewing the time taken from identification to resolution of the problem. Then a comparison is made between this and the MTTR under automated incident response. If everything is working correctly there should be a significant improvement compared to traditional manual processes.
Use cases for automated incident response
There are several use cases for automated incident response, but the most common is phishing emails – if applied correctly automated incident response would aggregate the suspected phishing email and automatically trigger a process to inform the affected users, before extracting the compromised indicators. The automated incident response platform will look at the headers, contents, subject, email address and any attachments, and from this determine a priority or incident severity and check reputation or red flags by cross-referencing data against external threat intelligence databases.
Taking that information from the artefacts, automated incident response will determine if there are any malicious indicators suggesting that the particular email is bad. While it is informing users, it will also scan the environment, email accounts and endpoints to identify any other instances of the malicious email and automatically delete them from the user’s mailbox.
It will then update the security technologies with which it’s integrated to make sure that this email is never seen again and the sender is blocked. It will also detect for any particular after effects, in that if a user has replied to or forwarded an email, or opened the link, that it then takes the next step to move into incident response containment. Completing this stage, the malicious compromised indicators will be added to any blacklists that are tracked by security tools.
In cases where malicious indicators aren’t detected (a false positive), the platform will check for any attachments in the suspect email and detonate them in a sandbox. This is to determine what it would do if it was in a production environment, monitoring it for indicators of compromise. Does it go back to particular, known bad websites? Does it do things that a normal file or a normal attachment would do? If that analysis doesn’t set off any alarms, then automated incident response would forward the incident to the IT security team for them to do a double check to ensure that it’s right to release. If the team is satisfied that it isn’t malicious, they’ll send an email back to the user, letting them know that it was a false alarm and there’s nothing more to do.