This chapter covers the following topics:
- Network Security Platform Options
- Network Security Device Best Practices
But lo! men have become the tools of their tools.
Henry David Thoreau, "Economy," Walden, 1854
All of the books in the world contain no more information than is broadcast as video in a single large American city in a single year. Not all bits have equal value.
When preparing to deploy security technology, many decisions must be made. Two of the main ones are deciding which kinds of devices should be deployed and where they should be deployed. This chapter covers these two topics in detail. First you will learn the different platforms on which security technology can be deployed, and then you will learn the pros and cons of various deployment scenarios and their related best practices.
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.
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.
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:
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.
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:
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:
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:
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.
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.
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).
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.
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.
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:
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.
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.
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:
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).
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.
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.
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.
Part I. Network Security Foundations
Network Security Axioms
Security Policy and Operations Life Cycle
Secure Networking Threats
Network Security Technologies
Part II. Designing Secure Networks
General Design Considerations
Network Security Platform Options and Best Deployment Practices
Common Application Design Considerations
Identity Design Considerations
IPsec VPN Design Considerations
Supporting-Technology Design Considerations
Designing Your Security System
Part III. Secure Network Designs
Edge Security Design
Campus Security Design
Teleworker Security Design
Part IV. Network Management, Case Studies, and Conclusions
Secure Network Management and Network Security Management
Appendix A. Glossary of Terms
Appendix B. Answers to Applied Knowledge Questions
Appendix C. Sample Security Policies
INFOSEC Acceptable Use Policy
Guidelines on Antivirus Process