Firewall Administration For Sysadmins Part 4: Communication Tips

In my previous post, I explained why sysadmins need to have an ongoing dialog with the security team on projects and how this leads to better project results. In the final post of this series, I will offer guidance on how sysadmins can better communicate their requirements to the network security folks.

First, sysadmins who understand the network behavior of their applications will be better able to communicate their needs. Network and security folks have general working knowledge of protocols, but don't know intimate application details. What I mean is that a firewall administrator might understand that an HTTP conversation typically happens across TCP port 80 between two IP hosts, and probably even knows a bit about the HTTP protocol itself. But what the firewall administrator won’t know is what happens when, let’s say, an end user presses a specific button on a Web form.

This is where the sysadmin can be helpful by articulating details when working through problems. Finding out that pressing the button results in a form submission that kicks off a SQL query can lead the firewall administrator to investigate whether SQL traffic is allowed by the security policy and where the database resides. Admittedly, not every sysadmin will know applications to that level of detail, but engaging a vendor or developer who does know will help move problem resolution along. At the very least, the sysadmin should be able to communicate what hosts will need to talk to what other hosts using what protocols and in what directions.

[Read why network and security engineers need to understand where network virtualization is going and why they need to go with it "Don't Leave Network Virtualization To Server Admins."]

Second, a sysadmin should anticipate what a firewall administrator will need to know to fulfill a request. Details are absolutely necessary. When asking for a firewall security policy change, a sysadmin should include at least the following information:

•Hostnames and IP addresses of impacted hosts. In the sysadmin world, hostnames are important. In the firewall administrator world, IP addresses are more critical. Hostnames change and internal DNS servers might or might not be able to resolve a given hostname. Therefore, a sysadmin should include both pieces of data when submitting a request.

•Communications ports, ranges and purposes. Most vendors supply a list like this for their applications, especially when the application is complex. The purpose of this list is to ensure not only that firewall access lists are built appropriately, but also to make sure that proper high-level inspections are being performed against non-standard ports.

For example, Web servers frequently are assigned to TCP ports other than 80 or 443--for instance, 8080 and 8443--at the whim of a vendor. The firewall administrator might need to instruct the firewall to treat traffic on 8080 and 8443 as HTTP traffic and inspect it accordingly.

•Directionality. The key element in directionality is articulating from which host communications will be initiated. As explained in part 2 of this series, which host is starting a conversation on a particular port bears greatly on the security policy.

•Contextual justification. A firewall administrator who fulfills requests blindly is not doing his or her job properly. There should be a valid reason for a security policy to be changed; convenience is usually not a valid reason. “Because my manager said so” is not a valid reason in most cases, either, although politics might dictate otherwise. Valid reasons are given in the context of business drivers: The change will enable a business function that could not otherwise be performed. For most businesses, this means that a firewall policy change is part of a larger overall IT project.

IT organizations function best when working together. That's because applications span silos, whether the people in those silos do or not. The highest functioning IT teams I’ve been a part of are ones that keep communications open between silos.

The gap between systems administration and security administration need not be a large one. Building systems and security functions jointly results in a better overall product for an organization. And after all, that’s what IT exists to enable: the businesses and organizations they support.