Despite organization-wide interest in implementing security automation, security leaders often struggle with identifying common security automation scenarios and implementing custom automations.

These security leaders often run into common barriers that include automating the wrong things, incorrect prioritization of use cases, misunderstanding what should be automated or misunderstanding where to automate.

In order to establish a framework to identify security automation use cases, security leaders should implement a four-phase approach that allows them to identify high-priority areas of interest for automation and gather requirements for technical professionals to build and deploy automation strategies.

Phase 1: Prework

In this phase, security leaders must first gather automation requirements — without good requirements, security leaders could end up automating simply for the sake of automating.

It might be a “fun” engineering challenge to see what is possible to automate, but often the results will not justify the expense and effort of automation.

This phase can be kicked off by conducting a needs assessment in operations to identify the best candidates for automation and the amount of work that automating those candidates would require. The data gathered in this prework phase will guide later choices for identifying uses cases, development and implementation.

While selecting use cases, security leaders will analyze possible gains, identify success metrics and rank candidates based on a scoring methodology.

A goal during use-case selection is to identify those security automations that can help save time, provide better predictability with respect to response, speed time to response/containment and act as a force multiplier for the staff that is already in place.

Ultimately, this will hopefully lead to longer-term outcomes for the security operations center and the organization. Think of these as strategic outcomes, while automation goals are more about tactical outcomes.

Phase 2: Use case selection

With a list of automation use case candidates outlined from the prework phase, security leaders can then move on to selecting use cases.

Security leaders will need to keep in mind that they might not automate all of the candidates they identify in the prework phase — this is okay. The goal with gains analysis is to identify the heavy-hitter tasks that will help them reach their automation goals. 

First, security leaders can perform a gains analysis for their use cases. One of the most effective ways to communicate potential gains from automation is improvement over a baseline. The first step should be performing a gains analysis for only your top automation candidate, as the analysis can be time-consuming to perform. 

One way to determine a top automation candidate would be to order the list by total time taken. Secondarily, security leaders can look at frequency. For example, are there tasks that happen many times a day rather than just several times a week?

There are six gain analysis steps security leaders can take:

1. Start with the automation candidates identified in the prework phase. If there are a large number of candidates, it might not be feasible to evaluate all of them with this gain analysis. The top 5-10 candidates may need to be identified that will provide the best outcomes. These will likely be activities that are done daily and often. Don’t focus on activities that are less frequent as these might not provide the best gains. 
2. Record the actual work to be done on each tool at the lowest level, and estimate the average time that might be required to perform each task. 
3. Take the identified candidates and derive the time savings (or other gains) per instance. The way to derive the time savings is varied but generally breaks down into two options: Estimated time savings and actual time savings.
4. Calculate the total time savings for all tasks, and create a prioritized list of the activities for which automation delivers the greatest benefit. Note that this is about identifying the time savings per task.
5. Estimate total gains per month based on how frequently these tasks are performed, or the known time spent to perform them manually. There might be a task that can be automated down from an hour of manual work to just five minutes with automation. But if it is only executed once a month, then are there really going to be benefits from automating this task?
6. Produce a gains analysis report where all captured data is combined so that decisions can be made about which automations to implement, which to put on hold, and which should not be touched.

Phase 3: Automation/playbook development

Exploring the possibility of what can be automated and how to go about it is a fun engineering challenge. However, it’s strongly recommended that the development requirements for automation be determined through a gains analysis, as discussed above.

The output of the gains analysis should give security leaders a good idea of the processes and tasks needed to drive playbook development.

The gains analysis should also yield the success metrics, which can be used to validate the effort required to develop the automation. Can the deployed playbook and implementation strategy yield the type of gains expected? Some of this work may have already been completed as part of the scoring methodology.

One advantage of breaking up objectives into processes and tasks is that, although an objective might be unique to an organization, the activities required to reach the objective are common. Common activities are likely to already be developed by a group of domain experts, which can save time when automating objectives.

As with any development effort, testing and validation are important steps to ensure design requirements are met.

During testing, ensure that the task functions are working as expected. Are the APIs responsive? Are there delays in delivery? Do delivery errors occur? These are all important tactical testing steps to ensure the playbooks work as designed.

Phase 4: Implementation

At this point, the playbook should be working as designed against requirements and validated to work in operations as planned. During this phase, it’s time to put the playbooks into production operations so gains can be realized.

Operational processes must be updated to reflect playbook usage. Since playbooks can vary in size and type, document how and when to use which one. Playbook usage be documented at the objective-level in process documents. This level of documentation will help not only to instruct on usage guidelines, but also to track process-level dependencies and break points.

Security leaders must also communicate metrics for reporting, which should be revamped on a regular basis to include actual gains realized through automation. Some automation providers include playbook-level usage tracking in their tools, which can help with reporting.

If no such capability exists, it’s best to incorporate a way to track playbook usage and record the gains of each instance for regular reporting. 

The type of activities any one operator performs shouldn’t change much, but that individual’s involvement in the activities and tasks will change. The type of decision assigned to each role should be consistent — such as routing, classification and actions — and the operator should be trained on how to make such decisions.

As with any code, playbooks will have a shelf life. They will require maintenance and will eventually need to be retired. For each playbook, determine whose responsibility it is to keep the playbook fresh. 

The upkeep of custom playbooks is an in-house responsibility. During the development process, document any dependencies in the playbooks (such as third-party APIs, log formatting, OS or application version). 

If security leaders follow these phases, they should be well on their way to achieving an enterprise-wide goal of maintaining the latest security trends to stay one step ahead of any attacks.