Firewall Administration For Sysadmins Part 3: Application Planning

Modern enterprise applications tend to be multi-tiered, complicated beasts. Components and functions are often spread over multiple hosts, a task made almost trivial with the ubiquity of server virtualization. Often, there's an Internet-facing component involving a DMZ that allows users to access the system without a VPN client. There might be data replication schemes between network segments separated by a firewall.

When planning an application like this, security architects should be involved from the beginning. In this post, the third in a four-part series on firewall administration for system administrators, I will explain why this is critical.

I my experience, security architects are rarely brought into application planning. Instead, sysadmins and application architects spend a great deal of time with the vendor, working on a design, sorting through licensing, sizing compute requirements, creating a parts list, scheduling deliverables, planning high availability and forming a migration plan to move off of the existing platform. The infrastructure security planning is reduced to a firewall icon (usually a flaming brick wall) on an architecture map.

During application implementation, the security team is called on to open firewall ports. The presumption is that this is a simple task. As I hope I’ve established in this series, opening ports might or might not be so simple. Asking the firewall administrator to “open these ports” is akin to a network administrator asking a sysadmin to “spin up a VM” to support a newly acquired network appliance.

The sysadmin is rightly going to push back on such an ambiguous and uncoordinated request. Spin up a VM? For what? Is this temporary or permanent? What level of compute resources should be dedicated to the VM? Is a specific hypervisor required? Is it a self-contained image, or is an OS required? If an OS is required, which one? And do we have the licensing required for it? In other words, there’s a design aspect to implementing a new virtual machine.

A security team goes through similar mental gymnastics when asked to modify a firewall security policy. What is this host? Is it part of a larger application? What does the architecture look like? What’s the nature of the data handled by this application? Do compliance regulations bear on this data? Does the Internet-facing server host live data or an offline copy? Or is it merely a proxy? What are the known and potential security vulnerabilities of this application and underlying OS? Will network address translation be required? Assuming NAT, do the underlying network protocols used by the application work properly in a NAT environment? I think the challenge is clear.

If the firewall administrators are involved in the application architecture discussions from the beginning, all of these questions get answered along the way. The architecture can change as needed to accommodate the network security topology.

Alternatively, the network could be updated to meet the requirements of the application, the cost borne as an integrated part of the larger project. Even relatively simple application deployment projects involving a firewall should involve the proper staff right from the beginning to avoid unexpected difficulties during implementation.

[Read how virtualization, cloud computing and SDN defy organizational divisions and may usher in a new generation of IT generalists in "The Return Of The IT Generalist."]

One of the most profitable recent projects I was involved with was a significant Microsoft Exchange deployment that involved a number of firewalls, DMZ networks and proxy servers. I spent many hours working with the project leader, understanding the overall design, reviewing the architecture, making recommendations, implementing security policy changes, and testing the early deployment.

The experience was beneficial for all parties involved. Not only did I end up with a solid understanding of the complex Exchange architecture that was critical to the business, I also was able to share the security perspective with the other team members. In the end, everyone ended up more knowledgeable about the end-to-end traffic flow and application behaviors. When troubleshooting was required, all IT team members involved had a unified view of the application, as well as mutual trust in each other, leading to faster resolutions.

If the security folks are despised as “those annoying people in the corner,” it will be harder for them to do their jobs. Set expectations early and often. Consider the security component to any application as critical, and not a nuisance.

Can security folks be overbearing, reactionary, superior and unrealistic at times? Certainly that stereotype exists for a reason. But I also know that when security staffers are an integral part of an application deployment, they want to see the project succeed as much as anyone else. When security folks are treated as a part of a solution and not an impediment to progress, more solutions will come than objections.

In my final post in this series, I will offer tips for sysadmins to better communicate their requirements to the security team.