5 Reasons Your Firewall Team Will Love Microsegmentation

I’ll never forget an incident that happened early in our customer history. We had just completed training with a large customer’s firewall architecture and implementation teams. One of the lead firewall administrators raised his hand and said, “So if I understand this correctly, I’ll never have to write a firewall rule again.” I smiled and said, “That’s right.”

Six months later, we were standing in the elevator together, and he excitedly told me how much he loved microsegmentation. I asked why, and he replied, “You were right. I don’t write ACLs anymore and our policy is much tighter.”

That was a great moment, but the simple fact is that microsegmentation is great for firewall operations teams. Here are five top reasons why.

1. No more manual ACLs. Conceptually, writing firewall rules is “easy” – simply type the rules for what you want permitted and everything else will be denied. It’s true at a high level of abstraction, but close to the work, it is a significant oversimplification. In a traditional firewall, every policy desire must be translated from the way that app owners talk about their systems to the language of IP addresses, subnets, and zones. With microsegmentation, the enforcement point moves to the application instance itself, which means that the segmentation doesn’t rely on any network construct for enforcement. When coupled with a powerful Policy Compute Engine, the administrator can write policies in plain language, “The web server talks to the application server; which in turn talks to the database. The web servers never talk to each other or directly to the database”. A simple policy can be turned into an enforceable rule base without any human needing to know an IP address, subnet, or zone. Microsegmentation frees firewall administrators from writing ACLs.
    
2. Obtain a scalable policy model. While firewalls come out of the box with a default-deny at the bottom of the rule table, they quickly grow to have a complex mix of permit and deny statements. These mixed denylist and allowlist policies scale poorly because there is limited inheritance. As long as the rules are mixed allow and deny statements, rule ordering matters and that limits inheritance – what order should a merged policy observe? Microsegmentation works on a pure Zero Trust model. Since there are only permit statements, policy inheritance is easy – all that can happen is that something is permitted more than once. This makes it easy to specify policy at any arbitrary level of abstraction. A particular server could inherit policy from both a data center-wide policy and a policy for the production environment and databases in general. When large swaths of the policy originate from templates, the job of writing policy simplifies and scales much better.
    
3. Know that the policy is correct. Developing a firewall policy is not easy. All application traffic must be characterized down to the port and protocol. This information often lies outside the hands of the infrastructure and security teams. Worse, even the app team is often unaware as the application may have been installed by a vendor or contractor who is no longer involved. Microsegmentation provides a rich application dependency map that the whole team can understand. Since the map only displays application data and not network devices, the application and DevOps teams can easily understand the flows their application generates and what needs to be protected. Microsegmentation makes it easy to reach a consensus on protecting critical applications and delivers accurate information to the policy team.
    
4. Know that the policy is safe. How do you test a firewall rule? You don’t. Firewalls don’t work that way – we type the rules and if there’s a problem, the phone rings. In 2021, that’s no longer good enough. With a brand-new application, there is some room for back-and-forth with the app team to get it into production. But with existing applications, any mistake in the segmentation policy causes an outage. Microsegmentation offers a better way. Policies move through a lifecycle that includes discrete build, test, and enforce stages. In this way, everyone from the app owner to the security and infrastructure teams can validate that the policy is “as designed” and that the policy covers all necessary communications. The simple application dependency map makes it easy to know that the policy is safe and can be placed into enforcement.
    
5. Get help from application owners. In every organization there are far more people on the application team than the security team. And if we considered the number of applications vs. the number of segmentation policy authors, the contrast would be even larger. Given this disparity, it is always challenging to try to help each team understand what the firewall team needs and to get it in a timely fashion. Microsegmentation provides visualizations and workflow designed for application owners to be part of the process. When the app team is involved in the microsegmentation project, it is much easier for them to support the security and infrastructure teams’ goals for the app. It builds confidence and removes the blame game when everyone can see how the application works and the interaction of segmentation policy with those flows. App owners can easily validate both the flows and the application portion of the policy, speeding progress towards enforcement.

Microsegmentation is great for firewall administrators. Exchange manual firewall rules for a simple natural language policy that doesn’t require any network knowledge. Get a true Zero Trust policy model that easily scales with full inheritance. All segmentation policies need to be correct and complete. Microsegmentation makes this a simple graphical process that the application owners can be involved in. With them on your side, the segmentation project becomes faster, easier, and more enjoyable. Microsegmentation is the upgrade firewall administrators have been waiting for.