Deployment Guidelines

Introduction

Before you install Cisco Security Manager, you should give thought to the topology of your network(s) before deciding what type of system to install (standalone or distributed) and where to deploy the different feature sets of the system. This appendix describes a fairly simple network topology and then discusses the different ways that a person might deploy Cisco Security Manager on that network. We hope that this scenario enables you to extrapolate concepts about deploying Cisco Security Manager and helps you discover the best way to deploy the system on your network.

We do not present this scenario as an actual network topology or even as a recommended design for your network. To show you the different ways that you can deploy Cisco Security Manager, as well as to point out the do's and do not's of deployment, we have kept the example simple. More than likely, your actual network is more complex, but the guidelines that we present still apply nonetheless.

Note Certain aspects of the scenario are purposefully unacceptable from a network administration point of view. For example, no central firewall is positioned behind the default gateway on the backbone network, but not many network administrators would recommend such a setup, because it leaves the backbone network virtually unprotected. Once again, we have intentionally designed this scenario in such a way as to point out its failings, particularly as they affect Cisco Security Manager.

Network Topology Scenario

Figure A-1 depicts a hypothetical small corporation's network topology. The registered external IP address is 172.31.7.130, while the default gateway on the internal side of the router is 192.168.1.254. All outbound traffic destined for the Internet is routed to the default gateway.

The corporation has a backbone network 192.168.1.0 with a network mask of 255.255.255.0. Two PIX Firewalls are connected to this backbone network. One PIX Firewall protects an inside network 10.1.3.0 with a network mask of 255.255.255.0. This inside network provides connectivity for one department of the corporation (for example, engineering). The other PIX Firewall protects an inside network 10.1.1.0 with a network mask of 255.255.255.0. This inside network provides connectivity for another department (for example, IS personnel). This PIX Firewall also protects a perimeter network 10.1.2.0 with a network mask of 255.255.255.0. This network provides connectivity for all other administrative and support staff.

Behind each PIX Firewall, the network administrator has dedicated one server for Cisco Security Manager. On the 10.1.3.0 network, that server is 10.1.3.10; on the 10.1.1.0 network, that server is 10.1.1.10. The first task is to deploy Cisco Security Manager in such a way as to provide policy management for both PIX Firewalls on the corporate network.

Figure A-1: Example Network Topology

Deploying a Standalone System

One option is to install a standalone system for each PIX Firewall. In this case, a standalone system on the primary server 10.1.3.10 would perform all policy distribution and management, as well as system reporting and monitoring, for the PIX Firewall protecting the 10.1.3.0 network; another standalone system on the primary server 10.1.1.10 would perform the same tasks for the PIX Firewall protecting both the 10.1.1.0 and 10.1.2.0 networks.

The limitations of this type of deployment are apparent. Central policy management of both PIX Firewalls is not possible with two standalone Cisco Security Manager systems. While a standalone system can manage multiple PIX Firewalls, the system that is distributing the device-specific command sets to the PIX Firewall must be connected either to the interface named "inside" or to an internal "DMZ-slot:#" interface of all managed firewalls. Therefore, in our scenario neither standalone system can manage both PIX Firewalls.

As you can see, the person who is managing this corporate network would have to perform twice the work to manage both PIX Firewalls, creating and applying policies for both systems. One solution, if the network administrator were so inclined, would be to position one PIX Firewall on the 192.168.1.0 network so that it protected all internal networks. The other PIX Firewall could be reserved as a backup, although currently Cisco Security Manager does not directly support failover PIX Firewalls. While all internal networks would then be exposed to one another, central policy management of the PIX Firewall by a single standalone Cisco Security Manager system would be possible.

Another way to ease legwork would be to keep the PIX Firewalls positioned as depicted and then import the database key of one standalone system (say 10.1.3.10) to the Policy Manager of the other (so that administration of both systems could occur from one server, preferably the one on the IS network). Unfortunately, the systems would still be independent from each other, so true centralized management would not be possible without disconnecting from one system and connecting to another.

These solutions are both less than optimal. A better way to solve the problem, without repositioning the PIX Firewalls, is to deploy Cisco Security Manager as one distributed system. The next section discusses this approach.

Deploying a Distributed System

When you distribute Cisco Security Manager, you are in essence installing parts of the system on different servers that, when combined, create a whole (as the standalone system does on one server). The benefits of distributing the system include increased speed and performance (because different feature sets are able to use all the resources of the server on which they are installed), more flexibility in physically positioning the different feature sets, and of course an easier mode of centralized management (as opposed to the dilemma of the standalone systems described in the previous section).

The obvious drawback is that more hardware resources are necessary to accommodate the different feature sets. If resources are not a problem (for example, the network administrator in our scenario has enough resources to accommodate distributing the system), the benefits are certainly worth it.

The installation of Cisco Security Manager occurs in steps, the first of which is to install the Primary Policy Database feature set on a primary server. The database key that you export during installation of the Primary Policy Database is necessary for installation of all other feature sets. For a complete discussion of the different feature sets, please refer to Chapter 1, "Planning Your Cisco Security Manager Installation," which covers planning your installation.

Note Throughout our documentation, we refer to the computer on which you have installed either a standalone system or a Primary Policy Database feature set as the primary server; all other feature sets are installed on computers that we refer to as secondary servers.

Before we discuss how our hypothetical network administrator might deploy a distributed system across the corporate network, you need to be aware of a few issues. First of all, data traversing between different parts of the Cisco Security Manager system is secure through encryption; however, data traversing between the PIX Firewall and the Cisco Security Manager system is not secure, which means that Syslog data destined for the monitoring point (either the Policy Monitor Point or the Policy Distribution / Monitor Point) should not travel across untrusted networks. Another point to make about the monitoring point is that the Syslog data that it receives travels via UDP , so the network on which you install the monitoring point potentially can be flooded with UDP packets. You should carefully consider the repercussions to all other computers on the network on which you install the monitoring point. Also, the distribution point (either the Policy Distribution Point or the Policy Distribution / Monitor Point) can distribute commands to multiple PIX Firewalls, although it must be connected to the inside or perimeter interface of all PIX Firewalls to which it distributes. Finally, you should never install any part of the Cisco Security Manager system on a network that is insecure, such as a DMZ network.

So keeping these rules in mind, our network administrator might deploy the system like this: install the Primary Policy Database on the network administrator's network, on primary server 10.1.1.10, and install a Policy Distribution / Monitor Point on secondary server 10.1.3.10, which can distribute commands to the PIX Firewall in front of it and can process its Syslog data. One more thing, though, is missing: a Policy Distribution / Monitor Point, which could be installed on another secondary server on the 10.1.1.0 network.

Of course, if our network administrator had unlimited resources, as well as a need for dedicating a server to each function (distribution and monitoring), a Policy Distribution Point and a Policy Monitoring Point could be installed both on the 10.1.3.0 network and on the 10.1.1.0 network. Either way, all feature sets would connect back to the Primary Policy Database on primary server 10.1.1.10.

One issue arises out of this scenario. If the PIX Firewall that protects the 10.1.1.0 network is performing address translation , then the distributed feature sets installed on the 10.1.3.0 network potentially cannot communicate with the Primary Policy Database on the 10.1.1.0 network. When the database key is exported, it stores the IP address of the primary server so that any secondary server can locate it. However, with the PIX Firewall performing address hiding, the 10.1.1.10 address of the primary server becomes unaddressable. Our network administrator needs to do two things to rectify the situation: create a bi-directional mapping rule for the PIX Firewall protecting the primary server, and then override the database key information during installation of any feature set on the 10.1.3.0 network.

Note Any distributed feature set such as a Policy Distribution / Monitor Point installed on the 10.1.1.0 network can use the information on the database key, because it is unaffected by the address hiding performed by the PIX Firewall.

Other Issues

The brief discussions in the preceding sections were intended to give you an idea of the different choices that you have when deploying your Cisco Security Manager system. They are not comprehensive or exhaustive, because much depends upon the way that you have constructed your network(s). The following two sections list various things that you should and should not do when deploying Cisco Security Manager, including some of the major concepts described previously.

Some Do's in Deploying Cisco Security Manager

You must deploy the distribution point on the network that is connected to the inside or perimeter interface of the PIX Firewall(s) to which it is distributing commands. This stipulation applies to any standalone system, Policy Distribution Point, or Policy Distribution / Monitor Point.
You must apply a bi-directional mapping rule to the PIX Firewall that is protecting the network on which the Primary Policy Database is installed and that is performing address hiding . Also, when installing other feature sets that must communicate with that Primary Policy Database from other networks, you must override the database key information and instead specify the IP address reserved by the mapping rule.

Some Do Not's in Deploying Cisco Security Manager

You should avoid deploying any part of Cisco Security Manager on a network that is unprotected. For instance, in the example topology, you would never want to install any part of the system on the 192.168.1.0/24 network unless a firewall were positioned between it and the default gateway.
You should avoid deploying the monitoring point (either the standalone system, the Policy Monitor Point, or the Policy Distribution / Monitor Point) on any network that cannot sustain heavy UDP traffic. The monitoring point receives Syslog data in the form of UDP packets, which can flood a network and all workstations directly connected to it. For instance, in our example topology, you would probably not want to install a monitoring point on the 10.1.2.0/24 network if that network could not sustain the increased network traffic due to Syslog data.
You should avoid separating the monitoring point from the PIX Firewall from which it receives Syslog data with untrusted or insecure networks. Syslog data is not encrypted, so a potential security breach could occur if those packets traversed an untrusted network.

Table of Contents

Deployment Guidelines