Firewall automation projects are seemingly all the rage these days, with everyone looking to automate at least some portion of the 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? By taking a systematic and achievable approach to firewall automation. Here are four steps security organizations can take to dramatically increase the likelihood of success in firewall automation projects:
- 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.
For instance, enabling security for a DevOps team so their applications can get to market 30 percent faster will absolutely save money (in eliminating lost opportunity cost, employee efficiency gains, etc.). But to do that, you’d likely need a process that consistently delivers security implementations in less than two hours. The organizational change and implementation process to achieve this goal is likely a radical evolution from how normal security operations happen now, which will introduce significant costs and company disruption. In the end, the means for achieving the goal may exact too high a price to be practical.
Instead, what if you defined your goal to be achieving 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. Setting this achievable goal will deliver significant benefits to the organization (24 hours instead of one week), but at a very different cost and likelihood of success than the original “stretch” goal of responding in two hours.
Other projects like micro-segmentation, Zero Trust implementations, on-prem to cloud migrations, and the like 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. For example, projects that templatize common access (VPN connectivity, third-party access, new server setup, etc.) are likely to succeed, while projects that include special handling for one-off and infrequent processes are often subject to extensive delays.
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. Broad user sets tend to not have the same level of competence and, as a result, will impair the overall return on investment (ROI) on the project. Likewise, the broader the types of project requirements, the more complex (and less intuitive) the system design may have to be.
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. It is an excellent place to enforce the 80/20 rule – focus on the 80 percent who will benefit from a readily achievable project, rather than expending inordinate resources on including the other 20 percent (or your 80 percent beneficiaries may become disillusioned). In the words of one customer – “I don’t have time to help with the implementation of this project, because I’m too busy with the repetitive tasks that this project is trying to remove.”
3. Take a fresh look at how things are done. Some organizations fall into the “this is the way we’ve always done it” trap. Most firewall automation processes have two distinct elements: engineering and automation. Automating the engineering process of determining if a change is necessary, what to change, and should (from a risk perspective) the change be made, is where the majority of time can be saved. Making the change operationally, once it is understood, is a quick exercise regardless of whether or not it is automated.
Many organizations fall into the trap of focusing and measuring the operational part of this equation, rather than placing the emphasis on the far-more-impactful engineering part. This is a situation where taking a fresh look at the entire process continuum, rather than just “doing things the way we’ve always done them,” can reveal significant opportunities for automation and improvement.
4. And, take a fresh look at technical standards. In any automation project, you are likely going to sacrifice some fidelity on the change for the return in efficiency. If you are looking to make changes faster, sacrificing the exact construction of a firewall rule for a more consistent approach is important. The design must still be technically accurate – it must protect the endpoints and block inappropriate traffic – but you will likely lose some control of the design (rule order selection, for example) in favor of speed of implementation. Existing technical standards may be putting you in a situation where the perfect becomes the enemy of the good – it is entirely possible to reap dramatic efficiency gains through automation with little practical impact on overall control, if you revisit your technical standards through the lens of your automation goals.
Let’s be honest: You’re almost certainly exploring automation to save money and time. This is a practical and honorable goal – and you will achieve it if, in the immortal words of the current Philadelphia 76ers, you “trust the process” and follow the four steps to firewall automation success. Now start stepping – it’s doable!
The opinions expressed in this post belong to the individual contributors and do not necessarily reflect the views of Information Security Buzz.