Network Security Platform Options

There are three main platforms for deploying security technology. The first and most common is general-purpose security devices. The second is an "appliance" form factor of some kind. Integrating the security technology into the network fabric is the third option. In most good network designs, you use some combination of all three platforms, but certain platforms are better suited to certain roles.

General-Purpose Operating System Security Devices

Every security technology discussed in Chapter 4, "Network Security Technologies," is available on general-purpose operating systems (OSs). In this platform, the security administrator starts by building a general-purpose PC and then installs the security technology on top. The PC runs some form of generally available OS (most commonly a UNIX variant or Microsoft Windows). This section first discusses the general pros and cons, and then, at the risk of my own peril, it details two variants of this platform: commercial versus open source software.

Pros

The biggest benefit for using a basic PC platform can be summarized in one word: flexibility. A wide range of security software is available; something is more than likely available that already meets your needs. If, down the road, you decide to change software, you need only update the system and are not tied to any one vendor.

In using the basic PC platform, hardware costs are often low, and in some designs more than one security technology can be run on a single piece of hardware.

Cons

The aforementioned flexibility benefit comes with a price. From a management standpoint, you are responsible for managing two systems: the security software and the OS and hardware that it runs on. This has implications not just in the initial staging of the system but also in its ongoing management. Someone managing a firewall running on a Windows system must manage the OS (patches, logs, and so forth) in addition to performing the same tasks for the firewall software. This increases the skill set and management time required by a firewall administrator.

Another downside of the basic PC platform is performance. Because the security software sits on top of a general-purpose OS and general-purpose hardware, the system isn't tuned to run only the function you are asking it to perform. You can tune components to a certain extent, but this will only take you so far. The general-purpose OS your firewall runs on is designed to run the latest game just as well as it runs the firewall code. This can be mitigated somewhat by the availability of high-performance hardware. Often the latest CPUs can be purchased for basic PCs long before they are seen inside an appliance or network device.

The final downside is support. If you are running your security software on a PC platform, any problem you encounter could require contacting one of the following:

• OS vendor
• Security software vendor
• PC manufacturer
• Network interface card (NIC) manufacturer

There are others as well, but the preceding four are the major players. Any one of these vendors might claim the problem is with one of the others. This starts the ping-pong support process, which can be all too common in today's complex networks.

Software Options

You might be wondering if this book will get into the religious debate between open and closed source software. Not a chance! People make decisions in this area for reasons far removed from the technology. It is worthwhile, however, to highlight some differences between the two options. Instead of discussing open versus closed source, I've instead divided the technology into commercial (supported) software and open source unsupported software. Commercial software can be based on, or consist entirely of, open source software, which is fine. I also realize that just because something is open source, it doesn't mean you can't get support for it. It does generally mean that there isn't a toll-free number you can call to scream at someone when your security melts down. If you have such a number, it is probably a commercial version of open source code.

Commercial OSs and Security Software

People select commercial software for a few main reasons:

• Support Commercial software (open or closed source) almost always comes with support. When you hit a wall in your troubleshooting, it is nice to know a phone number exists that you can use to get help. Open source can offer support by e-mail, but if your firewall is down at 2:00 a.m., you aren't going to have a lot of luck getting an immediate response.
• Comfort Commercial products often have a level of polish to them. Their management interfaces are generally crisper, installation is often fairly easy, and getting a basic configuration up and running doesn't require a lot of manual reading.
• Organizational mandate For any number of reasons, an organization might have no other choice than to deploy commercial products. Many organizations that had such a mandate 2 years ago no longer do today, especially because major PC manufacturers started shipping open source OSs on their platforms.
• Long-term viability Some feel that, over the long term, commercial offerings will remain, while individual open source projects might no longer receive active development. Note that this argument could easily go the other way.
• Certification Oftentimes, when deploying security technology, organizations look for products certified by some outside organization. Since these certifications often cost large sums of money for the product developers, it is more common to find them associated with commercial rather than open source software.

These are all reasonable reasons, but many are increasingly becoming reasons to deploy open source as well. Downsides for commercial software include cost and security when closed source code is in use.

Open Source OSs and Security Software

Open source software is often selected for these reasons:

• Cost Free is a great price to pay for anything. Open source dramatically reduces the upfront capital costs, but it can increase the ongoing maintenance costs.
• Comfort System administrators (sysadmins) with an open source background feel more comfortable with open source software. Because they are able to look at the code, they can determine how a particular function operates. For this reason, open source advocates often cite that they can trust open source code more.
• Customization In the hands of a skilled developer, open source code can be tuned to a particular environment. This allows an organization to extend the functionality of software without waiting for the software vendor to put the organization's feature request on the road map for the next release.
• Security Security is often cited as a reason to deploy open source, be it commercial or free. This can be true, but only if competent security analysts review the code. Just because millions of people have used Linux doesn't mean that millions of eyes have examined the code. The new Advanced Encryption Standard (AES) is not presumed secure just because the code is available, but rather because competent cryptanalysts have reviewed the cipher in detail.

The biggest reason not to deploy free open source software is support issues. If you have a Linux guru on staff, he could certainly set up a Linux-based firewall/IDS component. He could also customize it to better meet your needs. Unfortunately, as a colleague of mine most eloquently says, "What happens when he is hit by a bus?" The real message out of this is documentation. Make sure any open source product you use is extensively documented within your organization. This should include the way it was configured in addition to any modifications that were made to the code. This applies to commercial software as well, but the ability to change the source code of open source software makes it a special priority.

Software Option Recommendations

You should use commercial products for any inline security functions. Inline security devices include any device that actively intercepts and forwards traffic. This includes routers, switches, firewalls, proxy servers, and so on. If an inline device fails, you need a quick avenue to get it back on track, which generally requires the ability to open a priority case with tech support.

Assuming you have the staffing and the expertise to run open source, feel free to use it for other areas. Open source is a great alternative for special-purpose code. The software arpwatch, referenced in Chapter 6, "General Design Considerations," is a great example. The functions and configuration options it provides are fairly easy to understand, lessening the benefits a commercial offering might provide.

Appliance-Based Security Devices

Appliance-based security devices were briefly discussed in Chapter 5, "Device Hardening." You might wish to refer to the "Appliance-Based Network Services" section in that chapter to reread the differences between appliance types. To keep things simple, this section divides appliances into two categories:

• General-purpose hardware/OS with appliance packaging
• Fully custom appliance

The next two subsections highlight the differences between the two options.

General-Purpose Hardware/OS with Appliance Packaging

These are by far the most common type of security appliance. Most commonly, the OS is some form of UNIX, and the security software sits on top of this. The hardware is usually a PC with limited interfaces. Often they contain a hard drive.

Pros

The pros of this kind of system are that it removes two of the cons from the basic PC platform: support and management. Because you are purchasing a total system from a single vendor, you can direct all your problems to that vendor without worrying about finger pointing. Also, to be considered an appliance, it must provide a simplified method of installation and configuration. This should mask any underlying OS functions and focus the administrator's attention on the security configuration itself.

Cons

Because this type of appliance runs on a standard PC with a standard OS, the performance issues discussed in the previous sections probably apply. The appliance vendor can certainly tune the box to better serve its purpose, but not to the extent possible with custom hardware and OSs.

A second downside is that you are locked in to the vendor for new features and fixes. In a basic PC platform, if you grow dissatisfied with your current firewall, you can replace it with one from another vendor. You also must ensure that any security issues with the underlying OS are quickly fixed by your vendor and offered in a patch to the system.

Finally, the flexibility of the PC platform is lost in exchange for greater support. Just because your firewall appliance runs on Linux, it doesn't mean you can add additional UNIX software and expect the vendor to support your product.

Fully Custom Appliances

Fully custom appliances are just what the name describes. The hardware and OS are not basic commercial offerings. The separation between the OS and the security software is almost nonexistent. These systems can either use shared memory and CPU resources or have custom hardware forwarding application-specific integrated circuits (ASICs) or network processing units (NPUs).

Pros

Fully custom appliances remove the performance con from the basic PC platform. Running custom hardware and software usually means better performance. In addition, management should be more straightforward than for any security platform discussed here. Because there is no significant underlying OS, configuration and management are limited just to the security functions. Software upgrades tend to be very simple as well. Finally, like other appliances, you only have one place to call in the event of needing support.

NOTE

Another benefit most custom appliances provide is no hard drive. This improves the mean time between failures (MTBF) of the device. A hard disk drive is often one of the most failure-prone devices in any computer, so by removing it (assuming you can get the same functionality), MTBF improves.

Cons

The first con, depending on your perspective, is that the OS is proprietary. Some list this as a pro because common vulnerabilities in commercial OSs do not render your security platform vulnerable. I put it in the con section because since the OS is not receiving a lot of attention from security researchers, it is more likely that large problems wait undiscovered (or unreported) in the product. The degree of testing the vendor puts the product through matters a lot. This "negative testing," as it is often called, doesn't make sure that the product works as advertised, but that it doesn't break as unadvertised.

The other downside is that, like all appliances, you are locked into a specific vendor. If the vendor no longer has a leading product, you must sacrifice both your hardware and software investment to go somewhere else.

Network-Integrated Security Functions

The third type of security platform takes advantage of your existing network infrastructure. Security capabilities can be embedded inside a router or a switch using either software or hardware. Each has its own pluses and minuses.

Router/Switch Software Integrated

Some networking vendors are beginning to offer security capabilities beyond basic access control lists (ACLs), which have been available for years. Some of the functions available within a router or switch today include:

• Stateful firewall
• IDS
• IPsec VPN

This section highlights the pros and cons of these software additions to basic networking platforms. Although both switches and routers can have this modification, throughout the section only the term "router" is used.

Pros

There are two main benefits of integrating security functions on a router. First, you probably are already using routers. Adding security to them reduces the number of boxes you must support and maintain. This saves on rack space and often reduces capital costs. Second, because the router already takes an active role in the overall network (forwarding traffic), adding security functions can often be done without impacting the network design.

Cons

The primary con has been touched on previously. A router is designed to route, so adding security capabilities means asking a router to do something it wasn't originally designed to do. Vendors are starting to address this by improving performance and management, but many still require steps that would be less cumbersome if security were configured on dedicated devices. Some of the specific concerns include the following:

• As you learned in Chapter 5, routers default to open, meaning the hardening tasks become very important.
• The configuration of the router with security functions is often more complex than configuring both a router and a security device as separate systems. See the axiom "Strive for operational simplicity" in Chapter 1, "Network Security Axioms," for more details.
• Because routers were originally designed to check as little of the packet as possible before making a forwarding decision, adding functions such as IDS or firewalling usually has a stiff performance penalty.

Router/Switch Hardware Integrated

This is an area of active development by networking vendors. The idea is easy to grasp, but often the implementation is difficult. In this model, security functions are added to a router or switch (hereafter called "router") by adding custom hardware to the router that performs the security function. Common examples include hardware acceleration cards for virtual private networks (VPNs), firewalls, Secure Sockets Layer (SSL), or network intrusion detection systems (NIDS).

Pros

The main benefit of adding hardware security capabilities to a router is that you get all the benefits of adding software security functions without the performance penalty.

Cons

The downsides are almost the same as the software downsides (performance concerns excluded). Special emphasis is needed, however, on configuration complexity. Today, for example, you can buy a modular switch that, in addition to Layer 2 (L2) and Layer 3 (L3) routing, also includes hardware IPsec, SSL, firewall, and IDS. These additions are usually in the form of "blades" that are added to a switch.

The trouble comes in when you try to enforce a particular packet flow through the device. Say, for example, you want to first pass through the routing engine, then terminate IPsec traffic, and then have the decrypted traffic flow through the firewall, the SSL offload device, and finally the NIDS. Using dedicated hardware for each function is straightforward and looks like Figure 7-1.

Figure 7-1. Multiple Security Functions

In this kind of a topology, it is clear to the administrator what the insecure and secure interfaces on the firewall are and how they are connected. When integrated into a single switch, the topology looks like Figure 7-2.

Figure 7-2. Switch-Integrated Security

In this, each security function is a discrete blade on the switch. Interconnections between these devices are made by setting up virtual LANs (VLANs) and virtual ports between the different devices. Unless the management interface for this configuration is outstanding, the entire configuration becomes error prone. In addition, with everything in one device, compromising the switch means compromising all the security connected within the switch. The resulting topology is very attractive, though. If your organization finds the management interfaces acceptable, you can drastically reduce the number of individual devices you must support.

TIP

When you are evaluating these switch-"integrated" solutions, be sure to watch out for systems that really don't integrate at all. A security device that just draws power and interface connectivity isn't really integrated. Instead, it runs separate software and has a separate configuration interface, much like you would if it were a separate device. This does have benefits, however. If you would like the INFOSEC group within your organization to control the firewall within a switch and the NETOPS group to control the rest of the switch, this lack of integration might be desirable.

Network Security Platform Option Recommendations

Given all these options, which should you use in any given situation? A big part of your decision comes from the experience levels of your staff and the requirements of your security system as defined by your security policies. In general, however, what follows is a reasonable set of recommendations that the rest of this book develops into actual designs.

Appliance-Based Security Devices

In most networks, appliances should be the bulk of your security system. Their ease of support, configuration, and deployment outweigh the downsides of vendor lock-in. Use appliances in critical locations where uptime is critical and performance requirements are high. Examples of security technologies best implemented with appliances are VPN gateways and stateful firewalls.

General-Purpose OS Security Devices

Use the general-purpose OS security devices for two reasons. First, use them for specialized security functions that serve either a specific role or a small subset of your user community. Second, new security technologies often appear on the PC platform first, making the PC the most likely choice for bleeding-edge security features. Examples of functions potentially implemented with the PC platform include proxy servers, niche security functions, antivirus, and URL filtering.

Network-Integrated Security Functions

Use network-integrated security functions in two main locations within your organization. First, use them for remote locations where dedicated IT staff are not usually present. A classic example of this is branch office connections to a central site. A small branch office is better served by a single router/firewall/IDS/VPN combination device than by separate appliances. Integrating the functions reduces cost and eases the administration burden for the central IT staff. Second, use integrated functions in environments where the existing network must be modified as little as possible. For example, integrating hardware NIDS into a switch in your data center allows you to inspect traffic on all data center VLANs without deploying multiple IDS sensors or modifying the topology.