Phase III: Secure the Enterprise

Ironically, this is usually the only phase that most organizations undertake and even then only partially. After you have completed Phases I and II, you can start to appreciate how hard it is to secure an asset without a thorough understanding of its value, purpose, and the threats arrayed against it. You wouldn't want to spend a million dollars defending something that is only worth a hundred, and vice versa.

Only when the first two phases are complete should an organization focus its energies on securing its assets. This is not to say that some emergency stop gap measures are not appropriate in the interim, but do not make the mistake some organizations have made of assuming these temporary measures are sufficient for a leisurely approach to Phases I and II. We have seen some government agencies that have given themselves years to complete Phases I and II with disastrous, highly public results.

There are three basic sub-phases to this phase:

1. Implement policies

2. Implement procedures

3. Deploy security technology and counter measures

Implement Policies

This sounds like a simple step, but it's often overlooked. Policies are created but aren't effectively enforced or implemented in a meaningful manner inside an organization. If the policies don't make sense because the users don't understand them or know they exist, they won't be followed. Or if the managing authority lacks the authority to enforce the policies, they aren't worth the paper they're written on. The implementation phase involves dealing with all of these issues in a productive manner so that your security policies are actually effective. This can be one of the more time-consuming elements of bringing a risk management program into an organization, as typically the process starts from inside the IT group in a corporation, which does not have the authority to dictate policies to the entire rest of the organization. For any set of policies to be effective, the process will require full management support and buy-in, all the way up to the highest possible authority in the company. Otherwise, you are left not with policies, but with suggestions. Suggestions will not protect you from risk.

Implement Procedures

As with policies, put the procedures into regular daily use. A good practice is to make sure it's as difficult as possible to not follow the procedures. When there is a shortcut available that bypasses your security procedures, sadly, people will take it. Policies can help here by instituting sanctions for bypassing proceduresas can technical barriers. For instance, password strength checkers are an example of automating a policy and a procedure. The user is forced to follow good security procedures for creating that strong password.

Deploy Security Technology and Counter Measures

As this book focuses on firewalls, we will concentrate on how we can deploy security technology and counter measures using a firewall; however, keep in mind that this phase is absolutely not accomplished through the use of firewalls alone. There are a number of excellent books and resources that explain how to secure all the elements of an enterprise. We must stress that this phase is not complete until all the elements, not just the firewall and the network or networks it protects, are properly secured through the use of additional security technologies and counter measures, such as IDS, patch management, AAA, and so on.

Securing the Firewall Itself

More about how to accomplish this is detailed in Chapter 3, "Local Firewall Security." The key point to remember is that the firewall, as a trusted element of the security model, needs extra attention paid to securing it. A firewall should have as few functions as possible and should never be used for anything other than a firewall. When you run any service on a firewall, you are changing its function into a server that doubles as a firewall. If you have the extra resources, do not run any services on your firewall; run them on other systems.

Isolating Assets

Isolation or compartmentalization is the cornerstone of security and what firewalls are really good at implementing. The principle is simplesecure an asset so that it cannot be used to break into another asset regardless of how compromised that asset might have become. An example of this would be two servers, one on either side of a firewall, that have no means of communicating with each other through the firewall. In that sense, those servers are isolated and compartmentalized from one another, so if one is broken into, it cannot be used to break into the other. Typically with firewalls, this is accomplished with what are called DMZs or Demilitarized Zones. Basically, a DMZ is like a no man's land for systems that might be exposed to greater threats than other systems and have a higher probability of being broken into.

Another use of compartmentalization is through the use of internal network firewalls, isolating elements of an organization's networks from one another. An example would be firewalling off the accounting department from the rest of the company to prevent unauthorized users on the company's network from accessing the accounting network. Each separate isolated network is sometimes referred to as an enclave or domain. We prefer to use the term enclave, because domain has a different context with some systems, as with Microsoft products for instance, but you might see the term used interchangeably in this book.

Figure 2.2. The wrong and right ways to forward traffic through a firewall.

For those systems that need to have presence in multiple enclaves, this is where DMZs come into effect. It's generally a bad idea to just allow traffic from a system in a less secure enclave (the Internet) to have direct access to a system on your more secure enclave (your internal networks). Moving systems into a DMZ segment that is isolated from both enclaves ensures a more secure design. A compromise on the system utilizing a DMZ will not allow an intruder to escalate access across the board on your internal network. This is known as Secondary Exploitation. Remember, the intent with compartmentalization is to isolate a system or systems so that if they are compromised, they cannot be used to break into other systems.

One bad trend we have seen recently is placing web servers on a DMZ and having them communicate to internal database servers back through the firewall. This is a recipe for disaster. A better model would be to set up a duplicate database server on the DMZ and to have the internal database server synchronize itself with the DMZ-ed copy. This way, if the DMZ database is compromised, the internal database server cannot be broken into and then used to break into other internal systems.

Figure 2.3. The wrong and right ways to connect databases to web servers on a DMZ.

Filtering

As you are no doubt already aware, this is the bread and butter of what a firewall doesit filters traffic, or at least it tries to, and we hope that it does. The golden rule with firewalls is always this: unless allowed, deny it. Never under any circumstances attempt to build a firewall that is configured the other way around: allow everything; deny something. This is an approach doomed to fail. One additional advantage of the good approach, "unless allowed, deny," is that you learn very quickly what sort of traffic is traversing your firewall. This might produce time-consuming work determining what to allow in and out of your firewall, but it's an excellent invaluable tool for determining what's going on. This approach gives you visibility into your network and users that you would otherwise never see if your firewall were built only to block certain things.

Also keep in mind that ports alone do not a good firewall policy make. Do not assume that just because you only allow port 80 traffic into a network that the traffic will only be HTTP if you are using the Linux kernels packet filtering capabilities. By default, the kernel has no way of inspecting the traffic to ensure that it is HTTP traffic. Ports are no longer enough to define what the traffic is. If you want to filter the traffic into or out of a network by protocol, then you will need to use either an application proxy that understands the protocol (squid, gatekeeper, reaim, and so on) or utilize some of the iptables modules that can perform protocol inspection, such as ipp2p. We have had the unfortunate task of cleaning up security breaches of customers that failed to understand this distinction. A port is nothing but a number to an IP stack; it has no bearing on the protocol that might run over that port. Anything could be running on that port, not just the service that normally resides there.

Ingress/Egress Filtering

Filtering what goes out of your networks is just as important as filtering what is allowed to come in. This is easily one of most overlooked elements of firewall configuration. Too many organizations set up their firewalls to, essentially, allow anything out of their networks. We always recommend that you carefully control what traffic you allow out of your networks so that you can minimize the effects of internal security breaches, such as information leakage, deliberate or inadvertent exposure of sensitive data, worms and viruses and unauthorized VPNs, and other tunnels set up by your users to bypass your security controls.