When planning how you are going to move your security operations from manual to automated workflows, you must first understand the mission your organization is setting for your security team, and how it supports business needs.

The relationship among regulatory requirements, market forces and information technologies realities that organizations must contend with all play a role when planning.

A key part of successfully automating a SOC is first having a clear understanding of how the assets being protected fit into achieving this overall mission, and developing metrics around these goals that will measure success along the way.

The first lesson I learned when creating automation use cases was that it required me to work with levels of abstraction other than detection engineering. Typically a detection is designed to target a specific technique, but this can be inefficient when planning automation use cases.

Chronicle SOAR uses triggers that activate a playbook when an alert is ingested. Most playbooks can be designed to handle several different types of alerts per use case. For this reason I prefer to organize my use cases around the specific data source being referenced, or in some cases the tactic. For example I might use EDR telemetry that can be primarily handled through one main playbook considering that many of the enrichment steps and investigation escalation will be the same.

MITRE ATT&CK Data Sources provide an excellent breakdown of what alert types can be grouped together. For example you would have different playbooks to deal with Active Directory alerts versus possible C2 traffic with a malicious domain.

The convenience here is that the data sources have also been mapped with components that correspond to specific sub-techniques. Using this mapping you can even view the alert types that you expect the playbook to deal with.

Google Cloud customers can even utilize the cloud security control mappings that provide a direct link between the key controls needed for a secure environment and the ATT&CK techniques that are likely to be used by adversaries.

These higher levels of abstraction allow you to make generic playbooks that cover multiple alerts but also provide the ability to quickly isolate the attacks to which the playbook is expected to react.

Organize mission-critical procedures

Remember that the importance of a SOC is only going to become a verifiable metric if its core mission is clearly defined. The next step that every team should follow is identify what threats are most likely to affect your most valued assets and business workflows. Many times these will be well-known use cases, such as phishing attempts, anomalous logins, malware detections and other common techniques used by adversaries.

Remember that specific industry threat intel is often worth taking a close look at as well. These key techniques should all have well-defined procedures for triage and investigation, and this is before automation is put in place.

Even if each step is manual, your team will find huge value in perhaps using chart drawing tools to create workflows. Use case architects can then use these same charts to create the playbooks your team needs.

During my time building automation playbooks, I have seen that by having manual processes outlined ahead of attempting automation it accelerates the design process, makes it easier to identify problem areas, and allows the engineering team to improve the workflow to an even greater extent since they have a starting point.

Turn common manual tasks into blocks

The best strategy when building playbooks for Chronicle SOAR is identify workflows that are going to be used across multiple playbooks and put them in blocks. These blocks can be thought of as contained functions that can be reused across multiple use cases. Some of the most common blocks I have designed are related to threat intel enrichment, communication such as email or chat, and ticketing systems that might be involved.

For instance, I can build blocks that contain my VirusTotal and other file analysis integrations and reuse that block across my entire collection of playbooks. Blocks also have a place for inputs, which makes it easy to customize what data will be used inside the block.

I often use these inputs when I am using templates. such as for emails or ticketing systems. For example, a ServiceNow ticket has certain fields that I will set as block inputs. This way I can reuse that same SNOW block and just change the content of the input for that specific ticket.

Consider these final reminders

Remember that the core mission of your SOC will guide what procedures need to be prioritized when automating manual procedures.

The best way to start is to identify these manual procedures by making flow charts, and giving them tags from ATT&CK that correspond to a tactic, technique, or data source. This tagging will make it much easier to keep things organized, and will provide a key metric on how much of your environment has automation involved in its protection.

The use of blocks will make the design process go faster as you move along, but don’t be afraid to move slowly at first. Sometimes, it is better to automate one manual task at a time, even in a SOAR playbook.

Every action that you use has the option to be used manually or automatically, and setting them to manual at the start of your journey will give you control over the final steps to be automated—and provide useful testing.

The next steps of your journey will be to review these playbooks often. Ask yourself questions about bottlenecks in the flow that might be costing your analysts quite a bit of time. Are their ways to further automate common tasks, such as investigation queries that are reused? These next steps in the maturing of your SOAR playbooks are essential as you seek to reach an even higher level of security.