Let’s get one thing straight:
Security automation and orchestration are at the heart of D3’s Incident Management Platform.
Our platform’s security automation features streamline the investigation and context-gathering aspects of response, and also provide automated actions, such as blocking IPs and closing ports. The time-savings are significant; according to Vahid Foroushani, our Chief Scientist and resident IR expert, a 10-person IR team can save 20,000 analyst-hours per year through automation.
Sounds great, right? And it is, but companies still need to be cautious about the risks that come along with automation.
While automating the right processes can make your incident response more efficient, decisive, and conclusive, the possibility of automating the wrong processes, or doing it incorrectly, should be top of mind for any responsible security team.
Poorly thought out automation can leave you more vulnerable to attacks, increase dwell time, and remove valuable agility and human decision-making from the process—downsides no incident responder should take lightly.
Therefore, security teams need to balance the benefits of automation with the risks. And while every organization has different thresholds or appetites for risk, we at D3 generally believe that there are some things you should definitely automate, and others you should not.
In this post, we’ll discuss five aspects of incident response you should automate, as well as a handful you shouldn’t.
Investigation
The investigative phase of incident response offers great potential for improvements via automation. An IRP can save analysts significant time by enriching incident records with information such as:
- SIEM data and log files
- IP, URL, file and domain reputation checks
- Whitelist and blacklist lookups
- IP geolocation
- Similar events, same targets, and critical resource checks
Threat Intelligence
While gathering threat intelligence can be considered part of the investigation phase, it merits its own mention. Threat intelligence platforms aggregate data on cyber threats, and make them available to your organization. There are many useful feeds, including HPE Threat Central, FireEye iSIGHT, and IBM X-Force. Integrating with one or more of these feeds for automated enrichment is a great way to immediately put each incident into context.
Actions (With Approvals when Appropriate)
The promise of security automation is to be able to automate not just information gathering, but also entire processes. Some automation vendors present a vision of a SOC that shuts downs threats and responds to alerts, all without any human involvement. This type of automation can be useful, but should be applied carefully.
An incident response platform should be able to communicate with other security products, such as firewalls and servers, to automate some security actions, like closing a port or blocking an IP. However, there should still be analyst approval required for actions that could have a negative impact. See the section on what not to automate for more detail.
Notifications and Tasks
Automation and orchestration are two words that you will often hear together in the world of incident response. Sometimes they are used interchangeably, but they actually mean different things. At D3, we think of orchestration as the tools that coordinate, organize, and guide the incident response process. One place where automation and orchestration intersect is notifications.
Automated notifications make status updates, collaboration, reporting, and task management more streamlined and error free. This represents a great operational advantage over manual processes, which force analysts to look up contact information, prepare reports, and delegate responsibilities manually—all during the chaos of a security breach. Examples of valuable automated communications include:
- Reports—either scheduled or based on predetermined criteria (e.g. triggers)
- Assignment of tasks based on playbooks
- Notifications of activities that are relevant to a user
Prioritization
Alert fatigue is a major problem in most enterprise SOCs. Analysts are overwhelmed by thousands of alerts, and the majority are false positives. Automation offers the possibility of keeping analysts focused on the alerts that pose a real danger to the company. Using predictive criteria, a system can automatically set levels of priority within analysts’ queues, in order to keep the most likely false positives toward the bottom. This may take the form of a false positive probability percentage that the system assigns, or a more general risk scoring. When designed well, this type of incident response automation can provide an incredible boost to the productivity of your SOC.
What NOT to Automate
Incident response automation has the potential to bring substantial benefits, but when used indiscriminately, it can have a negative effect and create a litany of other problems. Here are a few things we think companies should think twice about automating.
Don’t automate major actions without requiring human approvals. If the parameters for your automated actions are even slightly off, you could cause a significant business disruption, such as blocking a partner’s IP or shutting down an e-commerce portal.
Don’t automate overly rigid or incomplete processes. It’s tempting to try and automate your entire incident response plan, but response needs to be dynamic in order to face new incident types and zero day threats. Compliance or legal requirements also change over time, meaning that they are easily missed by automated workflows.
Don’t automate processes that don’t allow for improvement over time. An automation platform that doesn’t support root cause resolution, retain comprehensive incident data, or leverage machine learning is really only treating the symptoms. Analysts learn and adapt to new threats over time, and your platform should reflect that.
Don’t automate using a system that relies on a web of expensive or redundant third-party integrations. Some automation platforms get all their functionality by tapping into external information sources—whose data often overlaps with each other, or with that of existing internal sources. Not to mention, these external data sources often require costly subscriptions, and in some cases even require you to build or maintain the integration. The cost of such an approach can scale very quickly, while leaving your incident response capability dependent on the uptime of a dozen different integrations and companies.
At D3, we’ve integrated intelligent automation into our Incident Management Platform. Our automation capabilities are growing every day, and always have the goal of supporting better, faster, and more streamlined incident response. To see first-hand how your organization can achieve incident response automation and orchestration, schedule a D3 demo today.
