Impact of Network Security on the Entire Design

As you design security controls into the different layers of your design, there are certain broad implications you should consider. Many of these have been touched on in other areas of the book, but they are summarized here again because of their importance in the overall security system.

Routing and IP Addressing

Proper consideration and accommodation of your security devices as they relate to routing and IP addressing is necessary to both enable your security system to function and to minimize its impact on the rest of the network.

Routing

Some security purists are against any form of routing protocol on a security device. If this sounds like you, you will have to pay extra attention to your security device placement because anywhere you put such a device you will interrupt the flow of routing protocols and effectively create multiple autonomous routing systems within your network. In some areas of the network, this makes sense. If you are adding a security device to a remote area of your network that contains only one or two subnets, it is fairly simple to use static routing instead of running a routing protocol. If, however, you are trying to secure a choke point between two large areas of your network, stopping all routing might make for a difficult management challenge with only minimal security gained from avoiding dynamic routing protocols.

WARNING

Keep in mind that the ability to reach certain parts of the network isn't the only thing you can affect by blocking routing protocols at a security device. Many networks implement HA through routing. Blocking dynamic routing can prevent the security device from taking advantage of alternate paths in the event of a failure.

In most situations, you are safe using routing protocols on security devices, provided you use a routing protocol with an authentication/integrity option, as discussed in Chapter 6, "General Design Considerations." Also, be sure to set up the routing on your security device not to accept any routes you wouldn't expect to receive. Distribution lists are the primary mechanism to implement such filtering. Distribution lists are like ACLs, except for routing protocols. You could use them to define the route prefixes you are willing to accept and those you are not.

There are other considerations such as the impact on asymmetric versus symmetric routing. This is discussed in Chapter 6. Additionally, be aware of the capabilities of your security devices with respect to multicast traffic. Often security devices have a more difficult time with multicast packets (if they are able to do security controls at all). Refer to the documentation for your security device for more information.

IP Addressing

The consistency of your network's IP addressing significantly impacts how easy the security system is to roll out. Although application layer security doesn't generally have much to do with IP addresses, ACLs, firewall policies, and other network security devices are very dependent on the underlying IP allocation scheme. A basic example is if you are trying to implement intersubnet filtering as discussed in Chapter 6; it is all but impossible unless each user group is allocated a specific IP subnet. Even simpler controls such as RFC 2827 filtering benefit from IP allocation best practices including summarization. As you learned in Chapter 6, RFC 2827 ingress filtering is best deployed as close to the edge as possible. In some cases, however, that might not be possible. Perhaps you are running older devices that exact a significant performance penalty for such filtering. If this is the case, you must move that filtering closer to the core of your network. If you've properly allocated your addresses, you can probably represent many different networks with a single access control entry.

Proper summarization and address allocation give you the most deployment options and ensure that those options are as easy to implement and manage as possible. I've often run across firewall administrators who boast that their firewall configuration has thousands of lines of ACLs. If you fall into this category, you might want to evaluate your underlying design to determine whether there are ways that number could be reduced. I'd hate to have to troubleshoot a firewall configuration of that size while under attack or while dealing with some other network issue.

Manageability

Focusing on manageability has been a continual theme of this book, so this section is brief. As you design your network with security controls implemented on a wide variety of devices, the consistent, secure management of these controls is critical. In large networks, these management requirements require techniques to manage devices over sometimes insecure protocols and long distances. Potential solutions include migrating to secure management protocols, cryptographically securing the management protocols you must run, and running a separate management network to provide access to the remote devices. All of these options are discussed in Chapter 16.

Scalability and Performance

In designing your security system, one of the most important decisions you must make is where your performance-impacting (or performance-limited) security technology will be deployed. Deciding on the location for a technology that is easy to manage and has no performance impact is easy. Routing protocol authentication within a small enterprise is fairly easy to set up and doesn't impact the function of the network it supports. Most security-sensitive networks, therefore, deploy it on all routers.

Unfortunately, most security technology does have performance limits. This is part of the reason security controls don't have much applicability in network cores. Thankfully, the access layer is often where most of your security controls are needed, and this is often the location that has the lowest performance requirements.

On occasion, however, you will have a choice to make. Your security policy will mandate a security control that your system can't implement without severely impacting network performance. If your policy, for example, mandated that all internal network traffic be inspected by a stateful firewall when passing from one L3 network to another, you might have a problem. Implementing the requirements of the policy will likely seriously slow down the network and create a firewall configuration that is very complex. Ideally, you would have caught this kind of mistake in the policy development process, as discussed in Chapter 2. If you are already at the design phase, you have three choices. Some choices are more likely to be made than others, depending on your ability to modify the policy and your organization's commitment to security.

Choice 1 is to implement the policy as specified, incurring a large performance and management hit to the network. If the reasons behind the policy decisions are sound and the organization is willing to live with the reduced network functionality, by all means implement the security control.

Choice 2 is to modify the security policy to better define the requirement in a way that can be supported. Perhaps the stateful firewall requirement can be reduced to only stateless ACLs augmented by NIDS.

Finally, choice 3 is to modify the policy to focus more on the security control required rather than the method of implementing that control. As discussed in Chapter 2, the policy should primarily be telling you what the security requirements are as opposed to how you implement those requirements. After tuning the policy, the security system could meet the requirements in a more network-friendly way. Perhaps you could focus on NIDS while implementing some basic ACLs and host firewalls where necessary.