8.10 Maintaining Firewalls

Like any network device, firewalls require regular maintenance to remain effective. A firewall that is an effective countermeasure one day could become an attack vector overnight through the discovery of vulnerabilities in the firewall software itself. Thus, it is critical that regular updates and critical updates be applied to the operating system in a regular manner.

When evaluating firewalls, it is a good idea to examine some of the security-focused mailing list archives for vulnerabilities that may exist in the firewall product. The actual existence of vulnerability is not the deciding factor. That is, you are not looking for the total number of vulnerabilities exclusively (although it should be an important factor); just as important is the attitude that the vendor takes in working with the security community and the release of operating system patches to address discovered vulnerabilities.

The relationship between those interested in security and those that sell security in their products is an interesting one. The issue of disclosure is the point of the most contention. We can illustrate this with a short example.

Assume that the fictitious firewall vendor "Strong Security" creates and markets the product "StrongWall" as a firewall product. Being a drop-in solution with support for VPNs, various authentication schemes, good logging, friendly user interface, and, best of all, a very affordable price, the StrongWall product becomes very popular. With this popularity comes the attention of the security researchers, the "white hats," and the security threats, the "black hats." The black hats, knowing that a large number of their targets may be running the StrongWall product, begin looking for weaknesses in the product themselves. This may even mean purchasing or stealing a few copies of StrongWall so that they can put it through its paces in a lab setting without attracting much attention. At the same time, the white hats are doing something very similar, but in this case the goal is to assure the world at large that the StrongWall product provides the security that it claims.

At some point, the white hats discover vulnerabilities in the StrongWall product. This is not unusual. Virtually every software product (and even hardware) will fail if subjected to enough scrutiny. While there are some mistakes that experienced, security-minded programmers should never make, it is difficult to thoroughly test every conceivable combination of events that a product will see in a production environment and still price a competitive product within a target market. So compromises are made in the development and quality assurance portion of development, simply in acquiescence to business needs.

When the vulnerability is discovered, the question then becomes what to do with the information. Should it be released to the world at large to alert them to the vulnerability? If the black hat community has already discovered the same information, then a great number of StrongWall installations could be at risk and users of the product should know that they are vulnerable. On the other hand, if knowledge of the vulnerability is not at this point widely known, alerting the security community and users of the StrongWall product would also inform the black-hat community of the same vulnerability. In the time-frame between the public release of the knowledge and Strong Security's release of the patch, attackers could easily create and distribute exploit code, leaving the users of the StrongWall product in a difficult predicament.

The better solution, and the most commonly followed one, is to privately contact the firewall vendor and work with them in examining and resolving the vulnerability. In this case, the vendor reaction to this forewarning is what to pay attention to. Many vendors will work with researchers who discover legitimate security flaws and create a patch that will be released to the public at the same time the vulnerability is revealed. This provides the researchers with some acknowledgment of their contribution to the security community, allows the vendor to market its response to security vulnerabilities, and allows users of the StrongWall product to patch their systems and immediately address the threat the vulnerability presents.

The process breaks down when the firewall vendor, in this case Strong Security, refuses to work with the security researcher. It may be that Strong Security wants to protect its public image of secure firewall products and hopes to avoid drawing attention to itself. Strong Security may even go so far as to threaten the security researcher or any institution assisting the that security researcher in disseminating information about the vulnerability with legal action. Strong Security may also simply, and legitimately, feel that what the security researcher terms a vulnerability is simply not the case. For example, if a security researcher "discovered" that someone with a boot disk could override the security settings of the firewall if they were able to manually boot the server from the boot disk itself — well, that is a vulnerability, but it is a vulnerability that every product has and is not easily solved through software in the firewall application itself. In this case, Strong Security may simply decide that the vulnerability is either outside its area of control or that the discovered vulnerability simply does not warrant an update to the software.

In either case, the security researcher may feel that either Strong Security does not take their information seriously or is moving too slow on the information. In this situation, the information may be released to the rest of the security world along with the attending consequences. Strong Security would typically respond to customer concerns by then developing and releasing some sort of patch for the vulnerability if it is possible or issue a statement describing why the discovered flaw is not really a flaw at all.

Based on this fairy tale, we see that a vendor relationship with the security community is in many ways more important than the number of vulnerabilities that have been discovered in a given product. As a consumer of the product, you want to know that patches will be released in a timely manner when vulnerabilities have been discovered. You are also hopeful that when vulnerabilities are discovered, security researchers are confident that vendors will work with them to provide the fix at the same time the vulnerability is released so as to not leave you in the lurch and your network in a risky situation.

Another important issue in maintaining firewalls is the patching procedure supplied by the vendor and patching procedures supplied by any operating system that the firewall runs on. For example, the Check Point firewall is an application that can be run on several operating systems, including Microsoft Windows and UNIX platforms. When evaluating firewall platforms, you must also ensure that the people who will be responsible for the maintenance of the firewall are comfortable working on such a platform. It will do you no good if Check Point is easy to patch yet the system administrator is unsure how to install, secure, or patch the UNIX OS hosting the software. If this is the case, you may lean toward a firewall appliance, meaning that the firewall and OS are bundled as a single drop-in product.

Finally, when considering the maintenance and care of a firewall, there is the rule set and any application layer filters that must be maintained. Application layer filters are filters that may include virus scanning. Because new viruses are released all the time, it stands to reason that these application layer filters need constant updating. Examine your proposed vendor's track record in responding to new Internet threats. When a threat is released, are their configuration servers unavailable for downloading due to the huge demand for the update?

Changes to your rule set may occur from time to time. Ideally, these should only occur when the security policy as a whole is examined or new applications are required for your business and some thought has been devoted to understanding the impact of this new application on information security. Remember that the security policy is what drives the implementation rules on the firewall; the firewall configuration does not drive the security policy. There should never be an issue of making changes to the firewall because someone comes running to the desk of the network administrator demanding, begging, or bribing the firewall administrator to open a port for whatever reason.

That said, when changes do occur, how friendly is the firewall in supporting changes? I have worked with more than one customer who has never made changes to the firewall because the person who made the rule set had left the company and nobody was really sure which rule was doing what. As part of the documentation process that occurs with the implementation of the firewall, an annotated copy of the rules should be kept as a backup. This way, someone picking up firewall administration duties can easily pick up the logic of the current rule set and make changes, confident that he or she is not affecting any other parts of the security policy.