With the development of new digital technologies and digital transformation the number of new policies be requested on firewalls has increased a lot. When there are high number of requests to be handled, this task becomes an operational activity. It makes sense to automate any operational activity like firewall policy changes and there is a tendency of making this activity an automation activity nowadays. Apart from that, although there are lots of projects going on the success rate of these policy automation projects is not so high. In this post we will be trying to focus on what may be the reasons of that.
Why Do You Need Policy Automation
People opt for firewall policy automation primarily to enhance cybersecurity efficiency and effectiveness. Automating firewall policies simplifies rule management, reduces human errors, and ensures consistent policy enforcement across complex networks. It also enables rapid responses to emerging threats, minimizing potential damage. Furthermore, automation allows security teams to allocate their time and expertise to more strategic tasks, like threat analysis and risk mitigation, rather than mundane administrative work. Ultimately, firewall policy automation is driven by the need to strengthen network security, streamline operations, and keep pace with the evolving threat landscape, enabling organizations to better protect their digital assets.
There are several reasons that may cause these automation projects to be failed. One of the main reasons is the complexity of the customer environment. The other reason is lack of knowledge on the people running these projects. And finally the last reason is customer prioritites or lack of confidence to the vendor coupled with.
To begin with in a traditional network there are L2 and L3 devices like routers, switches and firewalls responsible from routing. In a small-sized network creating a topology map and so finding any path to any destination may be easy. However, in corporate environments the situation is somehow different. There are private and public cloud infrastructures nearly in all the enterprises; Vmware NSX, Cisco ACI, Amazon, Azure infrastructures are so widespread and just collecting routing data from L3 devices is not enough anymore. Apart from that, there may exist L2 firewalls in the network and the solution must understand and discover these L2 firewall devices to create policies on them. Policy-based routing and static routes applied on the servers are also nightmare for the consultants of such projects since the path analysis requires source IP address information also. Since there are lots of non-standard configurations or applications on today’s network topologies the complexity is high and this is one of the reasons why many firewall automation projects fail.
As to knowledge on the people running project. Automation projects may necessiate customer technical people involvement since the complexity of the topologies is high. However, most of the time senior people may not attend these sessions and there may be no written materials to follow to discover the network topology. Since there are lots of vendors for firewalls and other L3 devices this lack of knowledge indeed is inevitable. The consultant may know Fortinet, Palo Alto firewalls and Cisco switches well and the customer may have Checkpoint firewalls and HP switches in place and in that case the consultant will need to find information on the internet or from the people inside. This lack of necessary knowledge causes the projects to last long time and some may fail also.
Finally, customer priorities, lack of confidence to the vendor coupled with are also the reasons. Customers may prioritize the analyzer part of the solution and start using it for general analysis of the firewalls. Getting the topology drawn by the system or getting unused rules data to investigate it further. Apart from that there may be lots of projects going on in parallel and the implementation of the automation part of the system may fall behind. The lack of confidence to the vendor relates to making the solution responsible for production activity and probability of downtime due to the solution. However, that’s why automation comes to play and reducing downtime due to human error. A dilemma case. In some cases resistance to make things to automate and to keep what they are doing as it is may also be a reason, but this situation be changed surely.
Making policy changes to be done automatically is a need in today’s complex network topologies. There are several policy automation projects going on and as it it is mentioned in this post there may be several reasons behind that. Making policy change automation starts with choosing a solution that is robust, stable and scalable and easy to integrate in all kind of environments.