It’s not uncommon for teams first deploying a security orchestration, automation, and response (SOAR) solution to experience a long deployment timeline. This is because most teams don’t have incident response processes that map clearly to automated workflows. Coming up with these workflows for the first time is risky and understandably prolongs the deployment process. In this blog, I’ll outline three milestones you can focus on in your first SOAR implementation that will simplify your automations, bring value to your analysts quickly, and keep stakeholders up to date with your progress.

Normalizing alerts will make playbook development much simpler. For example, if you have three different alert sources, each containing a hostname variable, having a standard alert schema in your SOAR platform will enable you to store the hostname variable in the same place, regardless of the alert source. Then, your playbook will only need to point to one place instead of three. This minimizes the number of tasks, conditionals, and playbooks you need to build.

Read this deep-dive if you’re interested in learning more about normalization in SOAR.

Most teams start by trying to automate use cases from beginning to end. This is not straightforward if you haven’t deployed automated workflows before. To get the most value out of their SOAR implementation, while minimizing the risk of setbacks, it’s recommended to start by building workflows to automate artifact enrichment.

Artifact enrichment builds off of the previous step of normalization as well. By normalizing alerts and having artifacts stored in standard fields, playbook development is simplified. This enriched data can be organized and displayed to your users in a way that helps them classify alerts as false or true positives.

The third milestone for your SOAR implementation could be reporting. Or, in other words, displaying your team’s security metrics for you and other stakeholders to review.