In our previous Security Automation series post, we identified areas that should be reviewed to allow for the most success with automation. Those areas included identifying the problems, dealing with the environment, and looking for frameworks that can apply a solid foundation for the security program and its automation success. In this post, we will look at how to apply those ideas to start building a security program that is designed for automation to have a key role in the program’s success.

Identifying and Determining Risk

After reviewing the problems your organization is facing, and observing those problems in your environment, the next step is to identify areas of risk and quantifying those areas, to determine the risk level for each set of problems. How do you quantify these risk levels?

  • Data gathered from monitoring tools
  • Data gathered from business owners
  • Internal or external scans

Data gathered from monitoring tools

Using monitoring tools such as SIEMS or log-aggregators allow for a centralized location for events happening in your environment. These tools provide vital information about the systems in your environment, and serves as the launch point for many processes and tasks, and with the vast amount of information in a centralized place, allows automation to have information readily available and accessible. Simple items, such as hostnames, users/groups, IP addresses, and application names are items that security analysts spend a lot of time gathering for each incident, and are required to get the same information for every event. Having the right monitoring tools along with automation can serve that information up to the analysts automatically for every new event.

Data gathered from business owners

Getting information from business owners, managers, or individual teams about how much risk is associated with each product, application, or service is crucial to the overall security picture for your organization. This information is often not represented well, due to teams not communicating with each, not getting the information on a scheduled basis, or not having a central place to store or visualize the information. This is where frameworks and services such as Kudelski Security’s Secure Blueprint really assist organizations determine the risk for each business owner, and rolling those risks up with the security posture of the organization.

Internal or external scans

Running continuous or scheduled scans of your environment for vulnerabilities, new or removed systems, and network changes allow you to get an understanding of what needs attention. These scans and tools give a technical picture of the potential holes in your environment, and allow both the business owner and your security team to determine the risk associated with each system, and which process to apply to remediate these systems. Automation can play a large role with these scans, from running the scans on a scheduled basis, to moving high risk systems to a quarantined zone, or to remediating the systems based on overall risk score automatically.

Identifying Common Business Issues

As areas of risk come into focus, taking a look at those areas to determine any commonality, identifying common challenges and platforms, even if it spans multiple teams. In large organizations, one of the largest challenges with both security and automation, is that each team will not communicate with each other well, often using similar platforms and duplicating the work. What common issues are occurring in each risk area?

  • Fatigue from overall volume, leading to high mean time to response (MTTR)
  • Lack of relevant information, leading to multiple teams responding to same issue
  • Lack of documented processes

Fatigue from overall volume, leading to high mean time to response (MTTR)

Large majorities of security and IT teams across all verticals deal with alert fatigue, either from not having enough personnel to deal with the events, not properly configuring their security tools, or from not have a well-defined process for handling the events. These reasons lead to the teams not responding quickly enough, or in some cases not responding at all, with big events getting lost in the noise. It is important to recognize when these teams are having difficulty responding to events in a timely manner, especially when there are multiple teams that collaborate with each other.

Lack of relevant information, leading to multiple teams responding to same issue

Many security teams spend a large bulk of their time searching for relevant information to appropriately respond to an incident. Many times, multiple teams receive the same event, and work on the event in parallel with other teams, not knowing what the other team is doing. Building a security environment that has centralized reporting and monitoring, centralized case management, and a mandate from the executive level to communicate with other teams really allow the security team to thrive. Adding automated processes to those teams just puts more time back into the analysts workflow, augmenting their skills to respond to the event in a more efficient manner.

Lack of documented processes

All companies have a process for handling events, whether that is just having an analysts “fix” it, or a detailed workflow diagram that is followed religiously. Reliability is the biggest key for security processes, can they be completed over and over, the same way every time. When security teams do not have a reliable, documented process, it leads to having gaps in your ability to handle the events. If analysts handle events on their own, it is often found that those analysts spend more time for each event, leading to other events potentially falling through the cracks, or the same event not being handled the same way the next time. Another key for processes is they must be just flexible to change, but those changes need to be documented or version controlled as the business needs change.

Designing Processes for Automation

With a solid understanding of the risks, the common issues, and the frameworks that help build the case for automating a task to help better align with a business objective, the foundation is set to allow automation to thrive. Beginning an automation process without these key areas is automating for the wrong reasons, and generally leads to homegrown scripts and applications that require more maintenance than benefit. When starting to design an automated process, some key areas to have mapped out:

  • What system(s) is the process targeting?
  • What level of human interaction is wanted?
  • Reporting success/failures of the process

What system(s) is the process targeting?

Knowing what system(s) to target with a process is vital to designing the process for automation. This allows for boundaries to be set for the automation to work within, keeping it from moving beyond its intended need. Knowing what system(s) also provides a better understanding of what information you will need to gather to interact with those system(s).

What level of human interaction is wanted?

Automation is not designed to replace your security team, only to augment them. Identifying key areas within the process for a human interaction to either approve the workflow to the next step, requiring someone to input a particular device target, or having someone audit the workflow once it has finished before pushing back into production.

Reporting success/failures of the process

After building simple or elaborate processes that automation can implement and really assist your security team, there has to be a way to measure the outcomes to map back into the overall security posture of the organization. By taking the automation journey this far, adding those measures back into the overall risk score for the organization allow for continuity in your security program and its risk posture.

With these areas mapped out, a documented workflow can be automated just by filling in the holes in the workflow with system info and/or adding an analyst approval step. These documented workflows that are being automated allow your team to spend less time getting information and more time responding to the incidents at hand. Don’t have a documented workflow? At Kudelski Security, we have built numerous custom workflows for customers after answering the above questions. Our team thrives on building effective processes for challenging but repetitive tasks, allowing your security team to focus on protecting your business.

Up Next

In the last part of this series, we look at taking security automation to the next level, improving playbooks, and bringing multiple assets into one workflow to improve overall security efficiency.

Blake Dobbs