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!
“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.
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:
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:
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.
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.
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.
“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!
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:
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.
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:
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'.
By submitting this form, you agree to our Terms of Use and acknowledge our Privacy Statement. Please look for a confirmation email from us. If you don't receive it in the next 10 minutes, please check your spam folder.