Ten Security Orchestration Myths and Clarifications

Since security orchestration is still an evolving space with competing definitions and maturing feature sets, there are some misconceptions that exist about its scope of use, consequences, and effort required in deployment.

Here are some myths about security orchestration that we’ve tried to clarify. These myths don’t quite reach the heroic scales of Hercules and the Nemean Lion, but are interesting and insightful nonetheless!

Security Orchestration Will Replace Your Security Teams

“Automation” always has a negative connotation with respect to job replacement and a removal of the human element. But in security orchestration’s case, nothing could be further from the truth. Security orchestration aims to achieve a balance between machine-powered automation and human-powered decision-making to improve security operations.

In an ideal security orchestration process, only the tasks that are repetitive, time-consuming, and not intellectually stimulating will be automated. Any action that requires further human investigation or approval – whether through email response, task approval, or collaboration – will be open for security teams to weigh in.

Security Orchestration is a Fancy Term for SIEMs

Almost every organization that’s serious about security has a Security Information and Event Management (SIEM) tool deployed in their environment. SIEM tools and security orchestration tools have some feature similarities on the surface such as automation of actions, product integrations, and correlation of data. However, it’s incorrect to assume that either tool could do the job of the other.

There are two schools of thought to contend with here:

• Security orchestration tools are the same as SIEM tools: While SIEMs deal with collection of machine data, correlation, and aggregation, current SIEM tools do not have the capabilities to coordinate further enrichment of alerts and response to alerts. Likewise, security orchestration tools can coordinate and automate cross-product response to alerts, but they cannot (currently) detect these alerts to begin with. In this scenario, SIEM collects disparate pieces of data and aggregates them into alerts, and security orchestration tools take alerts and drive them to response.
• SIEMs will eventually include all the features of security orchestration tools: In the future, if SIEMs incorporate cross-product playbooks and response automations, they will still not be equivalent to security orchestration tools because of SIEMs’ relatively narrow focus of detection. Security orchestration tools are poised to be general-purpose process and response solutions for security and IT teams that will ingest alerts (maybe from SIEMs), vulnerabilities, emails, cloud data, and correlate all these disparate data-sets before driving automated resolution.

Any Technology with Playbooks is Security Orchestration

As with any new industry term that gains adoption and market buzz, security orchestration’s rise has led to a cavalcade of vendors attaching the ‘security orchestration’ name to their products, whether genuine or not.

Here are some tips on separating true security orchestration from the rest of the bandwagon:

• Scope of use: If a security orchestration tool is narrow in its scope of focus (for example, just dealing with phishing response), then it’s not a true security orchestration tool. Security orchestration is defined by its general-purpose nature and execution across a wide range of use cases.
• Extensible integrations: A security orchestration tool is only as strong as its partner integration network. If a vendor builds a security orchestration product-line extension just to strengthen its initial products and limiting other integrations, such a product doesn’t align with security orchestration’s true tenets.
• Flexibility: Out-of-the-box, vendor-provided content such as playbooks, automation tasks, and product integrations should just be the foundation instead of the whole building. Users should be free to build their own combination of automated and manual tasks, custom playbooks, in-house integrations, and more.

Security Orchestration and Security Automation are the Same Thing

While educating users on new technologies, people in the industry sometimes enthusiastically – and incorrectly – interchange the terms “security orchestration” and “security automation”.

Security automation is making machines do task-oriented ‘human work’. Security orchestration is executing the interconnectivity of different products (both security and non-security) and automating tasks across products through workflows, while also allowing for end user oversight and interaction.

Security automation is a subset of security orchestration. Security orchestration involves the combination of people, processes, and technology to improve an organization’s security posture. Security automation is more focused on the ‘technology’ aspect of the aforementioned trio.

Security Orchestration Playbooks are “One Size Fits All”

Unfortunately, no security orchestration playbook is a one-shot panacea for an organization’s process woes. Vendor-provided playbooks are meant to be both teaching material and guidelines for users to follow and build their own (undoubtedly better) playbooks.

Out-of-the-box playbooks can be useful because they combine best practices across customer deployments that a vendor has been privy to. Ultimately though, security is a very organization-based practice. A company’s security processes are perfectly tailored to its industry, hierarchies, and level of agility – its playbooks should reflect the same degree of personalization. A good security orchestration tool will provide users with this flexibility.

Security Orchestration is Only Meant for Large Enterprises

Since security orchestration involves the coordination of actions across multiple security products, there’s usually a presupposition that only large enterprises with well-defined SOCs and a wide range of products will extract value out of security orchestration. But with a 2018 Verizon report claiming that 58% of data breach victims are small businesses, the need for repeatable and automated incident response is apparent irrespective of company size.

Even SOCs with 3-5 security analysts and a handful of tools can benefit from security orchestration through well-defined processes, increased team productivity, and setting the SOC up for eventual scale. Smaller firms can also avail Managed Security Service Providers (MSSPs) to oversee their security posture, where security orchestration tools can provide a valuable console for collaboration and data centralization.

Every Security Process can (and should) be Automated

“Automate or Die” is a pithy, marketing-friendly way to convey the urgency and need for automation, but it incorrectly paints the situation in black and white. Not every security process and action can (or even should) be automated.

Some tasks will continue to be too sensitive for unsupervised automation and will have manual approval processes baked in. Some tasks will continue to be too sophisticated and nuanced for machine execution and will be performed by security teams. For those high-quantity, repeatable tasks however…bring on that automation!

Creating Playbooks Will Require Coding Expertise

Although coding expertise is never a bad thing to have, security orchestration tools are meant to provide layers of abstraction to help level the playing field and increase the productivity of employees who are experienced in security practices but may be out-of-touch with coding.

Security orchestration tools should ideally provide features such as:

• Visual task-based flowchart views for playbook creation and editing
• Drag and drop menus for choosing security automations and product integrations
• Classification wizards for mapping data values between various products and standardizing data collection formats within the security orchestration tool

While knowledge of Python, JSON file handling, and JavaScript will always help, security orchestration tools should aim towards the ideal of “codeless automation” and keep on refining feature sets till they get there.

Just Deploying a Security Orchestration Tool Will Solve My Security Problems

Security orchestration is not an end-state but a journey of constant flux and churn. After the initial deployment of security orchestration tools, organizations need to iterate and keep tweaking elements of their security outlook such as:

• Verifying the effectiveness of playbooks and making them more concise or descriptive according to requirements
• Adding new security tools to and removing existing security tools from the product stack
• Conducting regular process audits and search for currently manual processes that can be automated with time
• Creating and reviewing dashboards for specific security analysts, alert types, and product integrations to measure what’s good and what can be made better

Security Orchestration is Only for Response Processes

Since security orchestration is usually touted as a solution to deal with rising alert volumes, it’s easy to perceive orchestration’s value being limited to response processes. But some benefits of security orchestration also transfer over to proactive and scheduled processes that security teams otherwise don’t have the time to perform.

Security orchestration playbooks can usually be scheduled to run at pre-determined time intervals and, for example, conduct health checks on organizational endpoints or verify the presence of systemic vulnerabilities. Playbooks can also be run in real-time to, for instance, execute threat hunting operations across user environments after some malicious indicators were detected in a separate alert.

The bottom line is: security orchestration’s value is contingent on organizational need and the process itself more than the method of deployment.

If you're looking for more information about security orchestration, its drivers, use cases, and avenues for future growth, you can read 'Security Orchestration for Dummies'.

SIGN UP FOR FREE COMMUNITY EDITION