Implementation of security automation can be overwhelming, and has remained a barrier to adoption
Previously, I wrote about balancing security automation and the human element to accelerate security automation initiatives. Equally important to address are the implementation aspects of security automation, which are holding many organizations back. In fact, a recent survey (PDF) found that while trust in security automation is rising, technology is the top barrier to adoption. And in Twitter poll, Allie Mellen, Senior Analyst at Forrester, asked teams that use security orchestration, automation and response (SOAR) how many playbooks they use regularly and two-thirds of respondents said 5-10 or less. In a related blog, Allie ties these results to the limitations of manual process automation.
SOAR playbooks focus on automating entire processes. So, to implement them you need to define and document complex decision trees for each playbook and bring in SOC analysts with coding skills to customize and standardize implementation. Also, process-driven playbooks must be updated manually to adapt to changes in the threat landscape and the environment. As the number of playbooks grows, complexity mounts and manual updates simply aren’t sustainable. Security teams limit their use to a few basic playbooks and, therefore, aren’t really leveraging the full value of the tools.
Implementation of security automation can be overwhelming, which is why I believe the secret is to use a data-driven, not process-driven, approach and break automation down into smaller chunks. It’s akin to what it takes to form a great snowball (and a timely reminder with winter approaching). Start with a solid core and then pack onto it little by little to make it bigger. If you try to do too much all at once, it will fall apart. Similarly, with security automation implementation, if we begin with the right core architecture and are thoughtful in scope—starting small and then building over time—we can reap more value.
Here are three recommendations to help:
1. Prioritize interoperability. Standardize on cybersecurity automation platforms with open versus closed architectures to ensure interoperability across the widest range of security tools and extensibility. When disparate systems and sources that talk in different languages and use different formats can communicate, you can gain a comprehensive understanding of the threats you are facing and know what you must defend. With the right architecture, you can automatically aggregate the right data from the right tools into a central repository and move towards a data-driven approach to drive automation of discrete tasks. This will also ensure you have the right foundation in place for working with emerging approaches such as extended detection and response (XDR).
2. Remember context is king. Now you can start to apply automation to a basic use case, such as contextualization of data which in and of itself provides significant value. You can automatically augment and enrich internal data with threat data from the multiple sources you subscribe to – commercial, open source, government, industry, existing security vendors – as well as frameworks like MITRE ATT&CK. Combining and correlating internal and external data gives you context to understand what is relevant for your organization. For example, say an executive has received a possible spear phishing email. You can automatically correlate the source IP with external threat intelligence to start to connect the dots and more quickly determine if further analysis and action is warranted.
3. Choose the right use cases. You can build on that contextualized data to expand your implementation of security automation, adding discrete tasks based on triggers and thresholds you set and defined by the use cases you select. Continuing with the spear phishing example above and moving into the territory of XDR, the next step could be to apply an automated scoring framework. If the email has indicators that have a high threat score, you can take immediate action like sending these indicators to your endpoint detection and response (EDR) solution for blocking. Or you can look-up the indicators in your SIEM to see if there are other events around it. Each atomic-level action is self-contained and, therefore, simple and quick to define, execute and maintain.
Spear phishing analysis is just one possible use case. Other popular use cases proven to show value from security automation by saving time and improving the effectiveness of security procedures include threat intelligence management, incident response, alert triage, vulnerability management, and threat hunting, amongst others.
Implementation has remained a barrier to security automation adoption. However, organizations can change that by starting with an open architecture, focusing on getting the right data for analytics and applying automation methodically in smaller chunks. As we put these steps together to address key use cases, we end up with straightforward playbooks that are data-driven to ensure the actions remain relevant and the confidence to broaden our use of automation and deliver more value to the organization over time. Instead of mounting complexity, it’s a “snowball effect” we can all get behind.