This is a guest blog post by Andrea Dainese, senior network and security architect, and author of UNetLab (now EVE-NG) and  Route Reflector Labs. These days you’ll find him busy automating Cisco ACI deployments.

Following the Ivan’s post about Firewall Ruleset Automation, I decided to take a step forward: can we always have up-to-date and clean firewall policies without stale rules?

The problem

We usually configure and manage firewalls using a process like this:

• A developer asks for a new rule;
• A security specialist evaluates the request asking questions like: is it secure? Does it comply with the internal standards? Does it comply with public standards like ISO27001, PCI/DSS…?
• If the request is accepted, a network engineer creates a rule (or updates an existent one) with a comment describing the rule itself.

What happens next?

Probably nothing and the new rule stays in the firewall configuration forever because no one can say whether an application still requires that rule years after the rule was created. Moreover, things get way worse if security engineers try to optimize rulesets by aggregating rules.

Any firewall configuration managed directly or indirectly in this way becomes at some point a very long list of rules where no one can say with any level of certainty if any single rule still matters or not. The result is predictable: stale rules remain in the ruleset, the complexity inevitably increases, and the security of the infrastructure decreases.

The solution

If we want to have an up-to-date and clean firewall policy we have to tie firewall rules to applications that need them:

• A CMDB must describe all connectivity requirements of all running applications (which host is connecting to which other hosts);
• Each firewall rule describes a relationship between two hosts. Rule aggregation (particularly across multiple applications) is forbidden;
• Each rule must be approved by security engineers (you can also try to automate this part of the process);
• The firewall ruleset is generated daily and overwrites the previous one;
• To reduce the ruleset sprawl, we should charge each application/organizational unit by the number of rules installed in the firewall or limit the number of rules per application.

The moment an application is decommissioned and deleted from the CMDB (or marked as disabled), the next automatically-generated policy will exclude all rules related to the application itself.

To use the approach I described you must use firewalls that can:

• Handle hundreds of thousands of rules without impacting forwarding latency;
• Overwrite an entire rule policy without disruption;
• Read externally-generated rule policy.

We successfully implemented this solution in multiple customer networks.

Conclusions

I’m convinced that we should automate as many tasks as possible because:

• Automated tasks saves time and thus money (competitiveness);
• They are reproducible (standardization);
• Deployment process is less prone to errors (security).

As always, you should do a thorough analysis before writing the first line of code (or even product specs) answering at least these questions:

• How are the users of our solution used to work?
• How do we expect them to work?
• How can we improve the processes?

The analysis of the ongoing expectations and processes is even more critical when you try to automate firewall configurations because almost everyone in the company gets involved in rule policies, and automating firewall policies often radically changes how people work. The whole process can be expensive, but the benefits you gain with proper implementation are indispensable.

Want to implement something similar in your environment? You'll get all the knowledge and skills you need to build your own network automation solution in our Building Network Automation Solutions online course.

To learn more about what Andrea is doing these days, and whether he might be able to help you doing something similar, contact him through LinkedIn.