By Ofer Elzam, VP and GM, FireMon Cloud & Automation Solutions

Security automation projects are making headlines, with everyone looking to automate at least some portion of the policy management process. Usually, the goal is to save time and money by automating firewall administration and policy management.

However, these two categories have grown exponentially in scope and complexity in recent years, so automation projects often become much larger and time-consuming than originally intended and produce varied results.  In some less-than-stellar cases, they even collapse all together, and people revert to the original manual processes they were seeking to automate.

How can this situation be avoided? There are four steps security organizations can take to dramatically increase the likelihood of success in security automation projects, we’ll cover the first two now:

1. Have a clear goal. Almost everyone automates to save money and improve efficiency.  But you must define more functional requirements than that – after all, there are many approaches for saving money. Focusing on a clearly defined operational goal is the key to determining the right approach, which, in turn, defines how much and where you will realize cost savings and efficiency gains. 
   
   What if you defined your goal to achieve a standard security process to meet a service level agreement (SLA) of 24 hours instead of the week or so it takes now? You could do this by analyzing the existing process and mitigating inefficiencies through the surgical application of automation, or even simply improving on existing manual processes.  
   
   Other projects like micro-segmentation, Zero Trust implementations, on-prem-to-cloud migrations, will necessitate their own functional requirements and SLAs. It is important to set goals for these projects that are realistic, while also delivering substantial cost and efficiency improvements. 
   
2. Don’t try to automate everything.  Automation projects succeed when there is a clear set of success criteria and a clearly defined and achievable scope. They often fail when trying to implement a process that will work in every scenario. A good example of this is in the change-request workflow. There are two places where time and resources can be saved in a change-request workflow: better requirements (less refinement of inputs) and reducing the wait time between individuals. Better requirements are generally achieved by focused training and more intuitive system design for a select group of users. 
   
   User and requirement creep tends to happen when relatively infrequent processes are folded into the project. This puts security organizations in a position where they spend significant time, effort and budget on automating processes that may only be encountered once or twice a month. This can delay the overall automation project and reduce ROI once it is complete, since significant resources will be invested for only marginal gains.
   
   Consuming project time to customize the workflow or software for a task that takes 10 minutes twice a month not only delays the overall project, but also causes stakeholders to question the overall value of the project. 

Let’s be honest: You’re almost certainly exploring automation to save money and time. Follow our next blog, for the last two steps to build your security policy automation roadmap.