Security Orchestration & Automation: Parsing the Options

Security orchestration is a buzz topic surrounded by a lot of confusion around how to orchestrate, especially when it comes to the role of automation — two terms thrown around interchangeably.

Why is orchestration such a big deal? There are several reasons: The security industry has moved beyond a pure preventative approach. The attack surface is too large, and the threat landscape is evolving too rapidly and growing in complexity and sophistication. Add to that the human element — 43% of data breaches utilize phishing according to Verizon's Data Breach Report 2017 — and it becomes clear that trying to prevent every attack is like playing whack-a-mole.

The new paradigm is detect and respond, which means you must assume that you are already breached. This does not mean that prevention is dead. Rather, combining prevention, detection, and response reduces the time from breach discovery to containment. Prevent what you can; detect and respond to what remains.

Using orchestration, organizations can control and optimize the processes involved in detection and response. For example:

Triage: Orchestration can help evaluate and qualify an incident. Detection technologies are noisy and produce large volumes of alerts and false positives that result in "alert fatigue." You cannot maintain a continuous state of alertness when everything around you is persistently crying wolf.

Correlation & Context: Even if you can identify the alerts that constitute a real threat, you need orchestration to correlate the context from operations. Is the affected asset mission critical, does it store critical data, and does it provide critical access that can be used by an attacker to gain a firmer foothold in your environment?

Process: Incident response is not a one-way event that stops after containment; it is a continuous process that must be orchestrated until the last foothold of the attacker is removed. Even then, the next wave of attack may still come.

Containment: Speed is critical. Ransomware, for instance, does not allow a large window of opportunity, and once that data is encrypted, you will be doing disaster recovery, not incident response. Likewise, if data exfiltration is detected, you need to act now. Any delay means that the threat actor already has taken your intellectual property or customer data. Without orchestration, incident response turns into crisis management.

Next Step: Automation?
Once you head down the path of orchestration, you will then need to decide how much automation you are ready for. While automation is frequently touted as a silver bullet, to successfully orchestrate security operations for detection and incident response, automation introduces a whole new set of organizational challenges. These three security operational phases can help you identify where you are on the orchestration process maturity curve, and guide you to knowing when and how to incorporate automation:

Phase 1: The Playbook. Playbooks outline the steps to successfully respond to an incident, including incident qualification, triage, investigation, containment, notification, and post-hoc analysis. This process is often manual, and maintained via spreadsheets or Microsoft Word documents. If you experience a few incidents a month this will be sufficient. However, if there is a sudden change in circumstances that increases the occurrence of attacks and incidents, a traditional playbook is not scalable for automation.

Phase 2: Tools and Architecture. If your organization has a higher volume of incidents or is maturing its capabilities, a viable option for assessing orchestration capabilities can be found in existing security information and event management tools. SIEMs offer lightweight workflow and automation orchestration capabilities, but they do not necessarily provide the capability to create and maintain flexible and granular playbooks. They do offer a basic workflow to respond to a low volume of incidents. If this is all that you can afford, it is a better option than a completely manual process.

Phase 3: Automation. At the high end of the maturity curve, orchestration can be combined with automation. Automation is a challenging topic because it helps the security team to assess the impact of a threat, but not the impact on the production environment. In addition, automation must be conducted selectively. Tasks such as notifying stakeholders, assigning incidents and enriching data with context can be automated safely and act as a force multiplier and speed up response. But the actual containment of a data breach will frequently require a human in the loop. Bottom line: you can automate the action, but not the decision.

Gartner predicts that by 2019, 30% of large and medium enterprises will be deploying some form of security automation and orchestration capabilities. The question for security teams today is: Where is my organization in the orchestration/automation maturity curve now, and what capabilities will I need in the near future?

Related Content:

Join Dark Reading LIVE for two days of practical cyber defense discussions. Learn from the industry’s most knowledgeable IT security experts. Check out the INsecurity agenda here.