/*

With our final part in the Security Automation series, Kudelski Security will take a look at what our clients are doing to take their manual playbooks to the next level, using automation. Before we take a look at playbooks, a quick review of the key factors from our previous articles to ensure automation success.

Keys to Successful Automation

  • Understanding your organization’s problem that you are trying to solve
  • Understanding your organization’s environment as it exists currently
  • Understanding the maturity of your program and mapping it to a cybersecurity framework
  • Identifying the business risk areas that automation can solve
  • Identifying the common business issues across teams in the organization
  • Designing and documenting manual processes to allow for future automation

With a firm grasp on these automation keys, let’s take a look at a common use case for most environments that are ripe for automation: Firewall Requests.

Firewall Requests

With most organizations protecting their network perimeter with a firewall (or ten), a question we get asked often is how to make that process more efficient, even if without automation, but preferably with automation. Let’s take a look at a fairly common workflow for generating firewall changes.

One of the first things we review is how the teams interact with one another for any workflow. In this example, each team is shown in a different color because they interface with each other using a different mechanism, whether that be by email, chat, or by separate IT Service Management (ITSM) tools (e.g. ServiceNow). While everyone in the technology world has been looking for the holy grail of a single pane of glass for all tools, for processes like these and most other IT operations processes, it is fairly routine to have all parties involved using the same means for communicating and documenting the tasks in a workflow. Using the same tool or mechanism for communication allows you to then create a separate channel or project for each workflow, and each channel or project includes only the team members needed for that workflow. For example, most network operation teams use an ITSM and have their own project for handling day to day activities, and the same for the firewall team, application team, etc. By leveraging that same ITSM and creating a new project that includes all teams that are required for that workflow, there is a central location for all communication and interaction, for both a manual and automated process.

Once a centralized location or mechanism for handling these requests has been agreed upon, it really facilitates open discussions and interactions on what the actual process should look like, where changes can be made, and where parts of the process are being duplicated. We have seen the most success when the teams get together, in the same room (crazy right?), and iron out the process to where all parties are satisfied and unified. From a manual process, it becomes a much cleaner simpler process that looks like the figure below.

From this cleaner process, we can apply automation to handle the interactions between the central location or mechanism for communication (i.e. ITSM, email) and the relevant technology to handle the firewall changes via automation platforms or custom API gateways. The final playbook comes out like the figure below.

From this playbook, we can see how everything comes together. The interactions between the ITSM and Firewall Management System are handled via web-hooks or API calls either after the push of a button from the ITSM workflow or via the custom-built automated workflow in the Firewall Management System (e.g. FireMon). This allows for maintaining a human interaction in the loop but drastically reduces the required work for that individual. That individual or team is also only using one system for this interaction, with all data flowing through the ITSM for process handling, thus reducing the number of systems required for access, and creating a much easier audit trail for long-term auditability and accountability.

Reviewing Keys to Automation Success

Let’s take a look at a few of the key areas for successful automation:

  • Understanding your organization’s problem that you are trying to solve
    • In our example, the organization’s problem was a decentralized firewall request process that led to many interactions with multiple systems to accomplish the same task.
  • Understanding your organization’s environment as it exists currently
    • In our example, the organization’s environment was a typical enterprise environment, with teams existing in different segments. These teams are required to interact with one another to accomplish certain tasks but do not see the inefficiencies in the overall process. Once able to understand each team’s process and responsibilities, the realization became clear that there were many areas they were able to consolidate.
  • Identifying the common business issues across teams in the organization
    • In our example, the common business issue was each team had their own process for handling the same task, albeit a smaller portion. With each team having to create and manage their own ITSM workflow and incidents and not able to interact with other teams, there were lots of tasks being repeated, and no centralized location for communication or data retention.
  • Designing and documenting manual processes to allow for future automation
    • In our example, the creation of the visual workflow for the legacy process was a key driver to have each team get together and spend quality time redesigning the process. The process was disjointed and repetitive for no real reason and a simpler, more consolidated, process was quickly realized and developed. By consolidating the process and having each team be a key stakeholder in the process, the benefits of automation could be realized by augmenting what the teams already handle on a daily basis.

Final Thoughts and Questions

Many companies are beginning to understand that automation will not soon replace human interaction in IT, but there are many processes that can be improved by it. Automation should not be used to fix a broken process, but to give information to those who can fix the problem in a faster, repetitive, and less expensive fashion. This will allow your superstar employees to continue to be superstars, freeing them from remedial tasks, and allow for less experienced employees to get all the information they need without having to needlessly search for the correct resource to engage for assistance. From a CISO’s perspective, it comes down to what problems am I having, and is there a sliver of a chance that automation can be leveraged to maximize the return on investment. At Kudelski Security, we are happy to assist with understanding what issues exist and where there are potentials for automation or just assistance helping to make processes more efficient, just let us know how we can help.

 

Blake Dobbs

Blake Dobbs

Cybersecurity Solutions Architect at Kudelski Security
Blake Dobbs is currently a Cybersecurity Solutions Architect at Kudelski Security. Blake's primary focus is automation integration within enterprise environments. Blake spent the last six years working and leading a solutions team for a cybersecurity research laboratory at the Georgia Tech Research Institute. While at Georgia Tech, Blake worked on and led multiple projects designed to bring automation to the forefront of the laboratory's long term strategy. Blake currently holds a Security+ certification, and is on track for his CISSP.
Blake Dobbs