Security Policies

As mentioned previously, firewalls are nothing more than access control policy enforcement points. Consequently, a firewall is only as effective as the firewall security policy (as opposed to the enterprise security policy) that dictates how the firewall will be used. Firewall security policies are discussed in great detail in Chapter 10, "Firewall Security Policies," but we can look at the fundamentals of what kinds of firewall security policies exist and how to build an effective security policy now.

The first step to a good security policy is to perform a risk analysis to determine what the threats to the protected system are. After doing this, you can develop a strategy and policy for protecting the system from those threats with your firewalls. A key thing to understand when you develop this strategy is that you may not be able to protect against or prevent everything. The reasons for this range from technological limitations (technically the recommendation cannot be done) to practical limitations (it would not be practical to undertake the recommendation) to financial limitations (you do not have the money in the budget to undertake the recommendation). As a result, you need to approach the subject from the perspective of seeking to minimize the risk associated with the threat. In some cases, that means you can reduce the risk to zero (for example, if you use a firewall to prevent all access to a system). In other cases, you can only reduce the risk to a level that is acceptable by management. For example, management may not decide that they can afford to spend the money required to implement the security solution recommended. In this instance, it is absolutely critical to convey in an honest and accurate manner what the level of risk will be. The reason for this is that after an incident occurs, it becomes real convenient for people to suddenly "forget" that they agreed to that level of risk in the first place. This is the time that it comes in handy to be able to produce a signed document that proves everyone agreed that the level of risk that was settled on was appropriate.

Examples of Security Policies

You have two primary security policies to use as a baseline in designing your security policy. The first is the closed security policy, also known as the minimalist security policy. The other is an open security policy, also known as generally a bad idea.

The closed security policy is based on the premise that by default all access is denied, and only access that is explicitly required will be permitted. The benefit of this approach is that the security policy will be designed only to allow access that has been explicitly granted. This security policy is frequently implemented when dealing with granting access from an untrusted source to a protected system (sometimes referred to as ingress filtering). The drawback of this system is the same as its strength, however. Because the default action is to deny traffic, it can be a time-consuming process to identify, configure, and maintain the list of exceptions that must be permitted.

At the other end of the spectrum is the open security policy. It takes the exact opposite approach, by default granting all access and denying only the traffic that is explicitly configured to be denied. This type of security policy is frequently implemented for granting access from a trusted network to external systems (sometimes referred to as egress filtering). The benefit of this system is that it generally takes little to no configuration to allow systems to traverse the firewall and access resources. As a result, many firewalls by default apply this methodology to traffic that is sourced from the internal network to external networks such as the Internet. Although convenient, it is incredibly insecure because the firewall will allow legitimate and malicious traffic out with equal ease. Consequently, it is not recommended that you implement a firewall that is configured in this manner. Although more convenient, the risk is simply too great for most environments.

Firewalls and Trust

After the decision has been made to allow some traffic through the firewall, the administrator has effectively made the decision (intentional or not) to trust the traffic that will be permitted. This decision is part of defining an acceptable level of risk. A firewall typically does not exist to stop all traffic. If it did, you would be better served just to disconnect the system from the network entirely. Instead, the firewall exists to allow some traffic while stopping other traffic.

In these situations, you have to realize and accept that by permitting certain traffic, you are trusting that the traffic is safe and acceptable. However, this does not mean that by deciding to permit traffic you are effectively removing any security a firewall can provide. Simply put, just because you trust certain types of traffic does not mean you have to trust the traffic in its entirety and in every way.

In the continued pursuit of mitigating and minimizing risk, you can configure the firewall to authenticate connections that will access the trusted resource, adding an additional level of security and risk management to the access that is being granted. Doing so ensures that before access to the protected resource will be granted, the requesting system must be authenticated as a legitimate user of the resource.

Another option is to use the firewall as an application proxy, serving as an intermediary for providing access to the protected resource. As discussed previously in this chapter, this can help mitigate and minimize risk by ensuring that all access to the protected resource must go through the proxy, allowing the proxy to ensure that the data being transmitted is not malicious or harmful.

The biggest thing to remember about firewalls and trust is that no matter how much you trust the access being granted, it has to go through the firewall before gaining access to the protected resource as opposed to just bypassing or not using a firewall at all.