Firewall Change Management: Changes That Require No Change

Creative Commons firewall image courtesy ecastro.

Firewall administrators are frequently asked to update rules for systems that don't work. Upon further research, the problem is frequently not with the firewall ruleset, but with the system itself. In fact, many problems magically solve themselves when they are looked at in the light of day - or at least, a tcpdump and a few minutes of actual review of the traffic between the host and its destination.

Thus today's security analyst quote: "The changes we do that require no change are always done without error".

A corollary is, "Those changes that require no change often require just as much time as those that do". This is because the research to find out why a request isn't necessary often involves just as much log review and traffic analysis as a properly specified request would, particularly if the firewall system does not allow arbitrary queries for existing rules.

There are a number of methods that you can use to help reduce the number of requests that turn out to be already allowed, or that are poorly specified. I'm going to take a moment today to outline a few of the most common reasons that I encounter poorly specified rules in change requests.

These poorly specified rules are often due to one of a small handful of issues:

1. Poorly understood architecture - the client/server relationships are unclear, either because the software is outside the norm - some software initiates connections on both sides, on the same port, and sometimes at very odd times, or because the architecture isn't understood and thus the requests don't account for the logical locations of the systems affected.
2. Lack of vendor documentation or poor vendor documentation - many vendors provide poor or little documentation for their applications. Some are particularly unclear, and simply specify a port, or a wide range of ports. Others don't document whether they mean TCP, UDP, or both. Yet another set don't document which system initiates the connection, and where it goes, or how long it stays open without keepalives. All of these can create a great deal of work for the firewall administrator if they aren't documented or if the request is poorly drafted.
3. Untested software or services -if documentation doesn't exist, administrators must test their systems to determine what they actually do. This can help determine actual ports and protocols, and can find those undocumented calls that can wreak havoc if missing from the ruleset.
   
4. Lack of communications and planning, or a total lack of a real design - when projects are conducted without review, designs can be created that don't fit the capabilities of the firewall, or which can put undue stress on it. Sometimes this results in data center wide system backups occurring through an already stressed firewall, or a reliance on broadcast UDP traffic between hosts that just won't work through a stateful firewall.

How does your organization handle rule requests? Perhaps more importantly, how do you handle the workload required to document the changes and to track them?

I'll talk about a few methods to help shape requests into a useful form in a post in the near future.