Guest

Cisco Security Manager

Managing a Cluster of Cisco Security Manager 4.1 Servers

  • Viewing Options

  • PDF (1.0 MB)
  • Feedback
Managing a Cluster of Cisco Security Manager 4.1 Servers

Table Of Contents

Managing a Cluster of Cisco Security Manager 4.1 Servers

Abstract

Deciding When To Use Multiple Security Manager Servers

Factors That Affect Application Performance

Scenario Overview

Scenario Problem Resolution Overview

Before the Split: Download IPS Updates to the New Security Manager Server

Before the Split: Add New Security Manager Server to Applicable Device Policies

Policies Where You Can Refer to Both Security Manager Servers

Policies Where You Should Refer to A Single Security Manager Server

Splitting a Security Manager Server

Step 1 (Optional): Create a Device Group For Export Devices

Step 2: Submit and Deploy All Configuration Changes

Step 3: Create the Export File

Information Included when Exporting Devices with Their Policies

Tips for Exporting Devices with Their Policies

Step 4: Copy the Export File to the New Server

Step 5: Import the Device Inventory

Tips for Importing Devices with Their Policies

Step 6: Verify that You Can Configure the Imported Devices

Step 7: Update Policies to Point to the New Security Manager Server

Step 7.1: Assigning a New Shared Syslog Servers Policy

Step 7.2: Using a Device-Level Override to Specify the New Syslog Server Address

Step 7.3: Verify that Syslog Events Start Appearing

Step 8: Delete Moved Devices from the Original Security Manager Server

Synchronizing Shared Policies Among Security Manager Servers

Tips for Exporting Shared Policies

Exporting Shared Policies


Managing a Cluster of Cisco Security Manager 4.1 Servers


First Published: March 2011

Abstract

Cisco Security Manager enables enterprises to manage and scale security operations efficiently and accurately. Security Manager integrates a powerful suite of capabilities including policy and object management, event management, reporting, and troubleshooting that are essential to maintaining security posture in today's ever changing threat environment. Cisco Security Manager supports a range of security solutions, including Cisco ASA 5500 Series Adaptive Security Appliances, Cisco IPS 4200 Series Sensor Appliances, and the Cisco AnyConnect Secure Mobility Client.

A Security Manager server cluster is two or more Security Manager servers used to manage a network. Typically, you want to maintain some relationship between the servers. Although there is no systematic relationship between the servers in the cluster, Cisco Security Manager 4.1 introduces import/export features that you can use to copy shared policies, or devices plus their assigned policies, between Security Manager servers.

Unlike previous Security Manager device import/export features, the new device import/export feature includes all of the policies, policy objects, and shared policies assigned to the exported devices. Thus, when importing the devices, you are also importing all of the policies, which preserves the work you have done to create and assign local and shared policies. Device rediscovery is not needed.

The shared policy import/export feature allows you to export shared policies, whether they are assigned to a device or not, and import them into another Security Manager server. Thus, you can designate a single Security Manager server as the master policy server, configure the shared policies on that server, and export them to your other Security Manager servers. Device assignments for the shared policies are not altered by the import, so that newly imported policies are automatically applied to the devices to which they are assigned on the server.

Although there is no programmatic relationship among Security Manager servers, these features allow you to treat multiple servers as if they were a coordinated cluster managing a single network.

This paper uses a specific scenario to describe how to use Cisco Security Manager 4.1 to do the following:

Split a single Security Manager server into two servers, moving some devices plus all of their policies to the new server.

Create and manage shared policies on one of the servers and export them to the other server, ensuring consistency of security policies.

This paper is not specific to any device type. You can use these features with any device that Security Manager can manage.

This paper assumes the following:

That you have a basic familiarity with using Cisco Security Manager. This paper does not cover installation or initial configuration of Security Manager. Note that this paper assumes that you are using non-Workflow mode; if you are using Workflow mode, you must explicitly create and manage activities and deployment jobs according to your organization's policies, which adds a few steps to the procedures.

That you are actively using shared policies to ensure consistency among devices. Using shared policies is not a requirement for splitting a server (that is, moving some of the device inventory to a new server). Therefore, the information in this paper about splitting the server applies even if you do not use shared policies. However, the information in this paper about maintaining a consistent set of shared policies across servers does not apply if you are primarily using local (device-centric) policies.

That you are not using Auto Update Server (AUS) or Configuration Engine (CE) to manage configuration deployments. If you are using these applications, when splitting a server, you can either continue to use the same AUS or CE, or you can also install a new AUS or CE to use with the new Security Manager server. If you install a new AUS or CE, you will also have to update the AUS policy to point to the new AUS or CE, and ensure that the device properties for moved devices use the appropriate AUS or CE.

For more information about the products discussed in this paper, see the following:

Cisco Security Manager: http://www.cisco.com/go/csmanager.


Note Security Manager 4.1 reorganizes the user interface into three separate applications: Configuration Manager, Event Viewer, and Report Manager. Unless stated otherwise, all procedures in this paper are performed in Configuration Manager.


Deciding When To Use Multiple Security Manager Servers

You can use a single Security Manager server to manage many network devices. There is no set maximum number of devices that you can manage. Instead, you need to determine if having more than one server is right for your network. Considerations include, but are not limited to, the following:

Security Manager performance. The more devices that you manage, the larger their configurations, and whether you are using Security Manager Event Viewer to view events from the devices, can impact the application's performance potentially to a point where the performance is unacceptable to your needs. In very large networks, the configuration deployment window could exceed your maintenance window. Or, the number of devices you are monitoring, and the events per second they generate, could overwhelm the server. For more information about factors that can affect performance, see Factors That Affect Application Performance.

Geographic issues. One of the factors that can affect performance is the geographical scope of your network. Due to network latency over large distances, it simply takes more time to deploy a configuration to a device that is on the other side of the planet compared to a device that is on the same LAN in the data center. Thus, you might want to deploy Security Manager servers in geographic locations that are closer to the managed devices in network distance.

Organizational issues. The lines of command and control in your organization might define distinct domains of network device management, and you might want to segregate device management along those lines while still maintaining some policy relationship among the domains.

Technology managed. You might want to segment device management based on the technology managed. For example, you might want to use one server to manage your site-to-site VPNs, another server to manage ASA firewall and remote access VPN policies, and a third server to manage IPS.

Factors That Affect Application Performance

The following information on factors that affect application performance is quoted from the Deployment Planning Guide for Cisco Security Manager 4.0. For more information on performance and deployment planning recommendations, please review the deployment guide and also the Installation Guide for Cisco Security Manager.

There are many factors that affect application performance. These include, but are not limited to the following:

Server and client hardware (for example, processor, memory, and storage technology).

The number of managed devices, including the type of the devices and the complexity of the device and the size of configurations (such as a large number of ACLs).

Event management engine and the event volume reported by managed devices and their logging level.

The number and complexity of policy objects.

The number of simultaneous users and the specific activities the users are performing.

The frequency of configuration deployment or IPS signature updates for large numbers of devices.

The network bandwidth and latency, such as between Security Manager clients and the server and between the server and the managed devices.

The use of fertilization technology such as VMware.

The use of ACS server for AAA services.

The number of devices present in a deployment job.

Large geographic distances between a Security Manager client and server results in poor client responsiveness due to the latency introduced. For example, it is not recommended to use a client in India with a server located in California because of the large latency involved. In such cases, we recommend that you employ a remote desktop or terminal server arrangement, where the running clients are co-located in the same datacenter as the server or nearby at least.

Scenario Overview

This paper uses the following scenario to describe the import/export features:

An enterprise customer has upgraded to Cisco Security Manager 4.1 and uses it to manage 500 devices.

This paper assumes that the upgrade has already happened, so that the customer can evaluate application performance before deciding to split the server. For detailed information on upgrading to 4.1, see the Installation Guide for Cisco Security Manager.

There is no single site-to-site VPN that exists across all devices, and that at maximum, a site-to-site VPN covers 250 devices. Alternatively, that it would be possible to split a large VPN topology into two smaller ones.

Security Manager requires that you manage all devices within a single VPN topology on a single Security Manager server. Thus, your VPN topologies can limit your ability to split a server. This paper does not directly address VPN topologies, and instead assumes that site-to-site VPNs are not a limiting factor in your network.

Configuration deployments are exceeding the customer's maintenance window for the network. The customer has determined that the maintenance window cannot be changed, and no additional server hardware or tuning will resolve the issue.

The customer has determined that the 500 devices can be logically divided into two separate spheres of management. For this example, we are assuming that the customer identified a geographic separation that would likely provide adequate performance. The spheres will be called East and West for purposes of explanation.

Although the customer decided that an East/West split would allow them to effectively manage their security devices, the customer wants to maintain some level of central control over the 500 devices. Thus, the customer will designate a single Security Manager server as the policy master, and the security experts will update shared policies and policy objects on the master, and import them into the second server, to maintain policy consistency. For purposes of this example, the West server will be the policy master, because it is the currently existing server.

Scenario Problem Resolution Overview

To resolve the problem described in the scenario, the customer would follow these steps:


Step 1 Install the new Security Manager server as described in the Installation Guide for Cisco Security Manager. To use policy import/export, both servers must use the same version of Security Manager.

Ensure that the server is functioning correctly, and also ensure that you install licenses with a device count that will be sufficient for the devices you will move to the server. To install the licenses, select Tools > Security Manager Administration, then select Licensing > CSM.

Step 2 If you are moving IPS devices, download IPS updates to the new server. Security Manager 4.1 no longer includes IPS packages, and to successfully import IPS devices, the target server must have the same signature packages available as the ones assigned to the devices. For information on downloading IPS updates, see Before the Split: Download IPS Updates to the New Security Manager Server.

Step 3 Prepare for the split by ensuring that the shared policies and objects will work when using multiple Security Manager servers. You have several options that you can use, as described in Before the Split: Add New Security Manager Server to Applicable Device Policies.

Step 4 Split the existing server in two, adding half the device inventory to the new server. For an explanation of the steps involved in splitting a server, see Splitting a Security Manager Server.

Step 5 Periodically export shared policies from the master server to the second server. For an explanation of the steps involved policy export/import, see Synchronizing Shared Policies Among Security Manager Servers.

Step 6 Periodically rebalance the device inventory, moving devices from one server to another when performance or management policy indicates that a move is required.

The considerations and steps required to rebalance the device inventory are the same as those required for a server split; only the size of the export file is different. Complete all of the steps explained in Splitting a Security Manager Server.


Before the Split: Download IPS Updates to the New Security Manager Server

This step is required only if you are moving IPS devices or service modules to the new server. IPS packages are no longer installed with Security Manager. However, if you import an IPS device, the server must already have the same signature package that is currently configured for the IPS device, or the import will fail. Because import is an all-or-nothing process, a signature miss-match for a single device will prevent the import of all devices, IPS or otherwise.

You have two choices for downloading updates:

Download updates directly from Cisco.com. This is the easiest procedure. However, when you download from Cisco.com, you must download all available IPS update packages, starting with version 5.1, whether you use the package or not. An initial Cisco.com IPS package download will be very large.

Create your own update server. To do this, you must set up an HTTP server and download the IPS updates to the HTTP server. Using this procedure, you can selectively download only those IPS packages that you want to use. After manually selecting and downloading the packages from Cisco.com, you can then use Security Manager to download the updates from your HTTP server. After setting up the update server, the download process in Security Manager is the same as the one used for Cisco.com, you simply configure a different update server.

The following procedure explains how to download updates from your chosen IPS update server.


Step 1 In Configuration Manager, select Tools > Security Manager Administration, then select IPS Updates from the table of contents.

Step 2 Click Edit Settings in the Update Server group and configure the following:

Update From—Select whether you are identifying a local HTTP server or Cisco.com.

If using an HTTP server, enter the IP address or hostname, port, username and password (if you require it), and path to update files.

If using Cisco.com, enter the Cisco.com username and password to use. The user account must be eligible to download strong encryption software.

For detailed information about these settings and additional proxy settings, click the Help button.

Click OK when finished.

Step 3 Click Save at the bottom of the page to save the IPS update server settings.

Step 4 Click Download Latest Updates in the Update Status group to download the IPS update packages to the Security Manager server. Depending on the number of updates, this process can take a long time.


Before the Split: Add New Security Manager Server to Applicable Device Policies

Several of your device policies might include the Security Manager server's IP address, or at least the address of the server's subnet, to allow the server access to the device or to otherwise interact with it. Security Manager must be able to interact with the device to configure and monitor it.

When you add a new server, you must ensure that the IP address, or subnet, of the new server is also reflected in the policies of the devices that you will move to it. Otherwise, after the move, you might find that there is no connectivity between the server and the managed devices.

Broadly speaking, there are two types of policy that might refer to the Security Manager server addresses. These are addressed in the following sections:

Policies Where You Can Refer to Both Security Manager Servers

Policies Where You Should Refer to A Single Security Manager Server

Policies Where You Can Refer to Both Security Manager Servers

For some policies, you can simply update the policy to include the address of the new server without removing the address of the old server. The device would then allow the related service for both of the Security Manager servers. This might in fact be the ideal situation, allowing you to use a server to configure a device that is usually configured by the other server, if you find yourself in an emergency situation and one server is down. Following are some examples of policies where you might want to include the addresses of both Security Manager servers:

Firewall Services > Access Rules—Interface ACLs for all devices except IPS.

(IPS) Platform > Device Admin > Device Access > Allowed Hosts—The hosts that are allowed access to an IPS device.

For these policies, you can use the following techniques:

Simply add the IP address of the new server to the policy or in the case of Access Rules, to the applicable Permit rule.

Update an existing, or create a new, network/host object that will contain the list of all Security Manager server IP addresses, and use the object name in these policies.

Policies Where You Should Refer to A Single Security Manager Server

If you are using Security Manager to monitor events on ASA, IPS, or FWSM devices, the logging policies should point only to the Security Manager server that includes the device in the inventory. This is very important. Any events that the Security Manager server receives from devices that are not in its inventory will be discarded immediately, so there is no value in sending events to both servers. Additionally, because some processing must be done to discard "unmanaged" events, a high rate of unmanaged events could result in a server loosing the events from managed devices. Besides logging policies, there might be other policies that could fit in this category.

Following are some examples of policies where you should specify the IP address of at most one Security Manager server:

(ASA/FWSM) Platform > Logging > Syslog > Syslog Servers. For ASA and FWSM only. Do not configure the Security Manager server for PIX firewalls, and do not configure any of the IOS platform logging policies to specify the Security Manager server. Security Manager 4.1 can monitor events from ASA, FWSM, and IPS only.


Note Although Security Manager can manage events from IPS devices, there is no equivalent logging policy for IPS. Instead, Security Manager pulls the events from the IPS device. By including the server IP address in the Allowed Hosts policy for the IPS device as described above, you enable IPS event management. Because Security Manager pulls the events from the device, only the server that manages the device will attempt to retrieve events, even if both servers are identified in the Allowed Hosts policy.


For these policies, adding the new server IP address amounts to replacing the old server address. However, you probably do not want to replace the address before you complete the server split; otherwise, in the case of event logging, you will effectively stop logging events until you finish moving the devices. Thus, you might want to use one of the following approaches:

Create a separate shared policy for the new Security Manager server. You could have two shared policies, East Syslog Servers and West Syslog Servers, that point to the desired Security Manager server (and to other syslog servers, if you use other monitoring applications in addition to Security Manager). You would then wait until after importing the devices and policies into the new server to assign the new shared policy. This technique would also require that you export shared policies separately, because the new shared policy would not yet be assigned to any devices, so it would not be exported during a device plus policy export. Alternatively, you could assign it to a single device, or even create a dummy device solely for the purposes of assigning the policy to it, so that during export/import, the dummy device would carry with it the new policy.

Another option for using this approach is to initially specify the original server's IP address in the East Syslog Servers policy, and assign that policy to devices that you are moving. This would ensure that the policy is present on the new server after import. You would then have to change the address in the East Syslog Servers policy on both the original and new Security Manager servers, so that the policy is defined the same way on both servers.

For more information on using this technique, see Step 7.1: Assigning a New Shared Syslog Servers Policy.

Use device-level overrides for the Security Manager server network/host policy object. To use this technique, you need to define a network/host object that will contain the IP address of a single Security Manager server. You would then use this network/host object in the applicable policies, such as the Syslog Servers policy. When defining the network/host object, you must ensure that the Allow Value Override Per Device option is selected. For example, Figure 1 shows a host type network/host object named SecManEventServer that defines the IP address of the old (original) Security Manager server, and allows for device-level overrides.

This technique allows you to continue using a single policy instead of separate ones for East and West. After you import the devices into the new server, you would use the Policy Object Manager to create device-level overrides for each device that uses this object, replacing the IP address of the original server with the IP address of the new server. Thus, the same object name points to two different servers, allowing for a consistent policy that is fine-tuned for each device.

For more information on using this technique, see Step 7.2: Using a Device-Level Override to Specify the New Syslog Server Address.

Figure 1 Allowing Device-Level Overrides in Network/Host Objects

Splitting a Security Manager Server

After you have installed the new Security Manager server and decided how to handle policies that refer to the Security Manager server, you are ready to split the device inventory between the two Security Manager servers.

Keep in mind that you should manage a specific network device from a single Security Manager server, so you will delete the moved devices from the original server.

The following sections explain the steps involved in completing a server split:

Step 1 (Optional): Create a Device Group For Export Devices

Step 2: Submit and Deploy All Configuration Changes

Step 3: Create the Export File

Step 4: Copy the Export File to the New Server

Step 5: Import the Device Inventory

Step 6: Verify that You Can Configure the Imported Devices

Step 7: Update Policies to Point to the New Security Manager Server

Step 8: Delete Moved Devices from the Original Security Manager Server

Step 1 (Optional): Create a Device Group For Export Devices

Optionally, create a device group specifically to contain the 250 devices that you are exporting. This will simplify the task of selecting devices to export, because you can select them all at once by selecting the device group during the export process.

You can either create a group within one of your group types, or create a new group type. Because a device can belong to multiple device groups (although one per device group type), you should be able to set up a group specifically for your devices. The following steps show how to set up this group and move devices into the group.


Tip Device group assignments are not preserved in the export file. When you import devices, all devices are placed in the All group, and you need to manually configure new device groups if you use them.



Step 1 In Device view, select File > Edit Device Groups.

Step 2 In the Edit Device Groups dialog box, either click New Type to create a new group type, or select an existing group type. In this example, we assume that there are fewer than 8 group types, so we can create a new one. When you click New Type, a new group type is added to the list with the group type name selected; type in the name of the group type.

Step 3 With the group type selected, click Add Group to Type. A group is added under the group type with the group name selected; type in the name of the group. The following illustration shows the resulting Edit Device Groups dialog box with the new group type and group: Export > East Devices. Click OK to add the group.

Figure 2 Creating Device Group for Export Devices

Step 4 In Device view, select the new device group (not the group type) and select File > Add Devices to Group.

Step 5 In the Add Devices to Group dialog box, select the devices you are moving and click >> to move them to the list of selected devices.

Figure 3 Adding Devices to a Device Group

Step 6 When the list of selected devices contains the right devices, click OK. The selected devices are added to the new device group.


Step 2: Submit and Deploy All Configuration Changes

On the original server, ensure that all configuration changes for the devices you are moving have been submitted and deployed, as well as any changes for shared policies and policy objects used by the devices. You will need to ask the staff to submit and deploy their changes, there is no simple way to determine this status within Security Manager.

This step ensures that there are no pending uncommitted changes.


Step 1 Select File > Submit and Deploy to submit your changes to the database and to start a deployment job. During submission, the device policies are validated. Resolve any errors before deployment. Carefully consider whether you need to resolve warnings.

Step 2 In the Deploy Saved Changes dialog box, select all of the devices that you plan to move. You can select any other devices that you want to deploy to at the same time.


Tip If you created a device group for your export devices, you can select the group to deploy to all devices in the group.


The following illustration shows the selection if you created a device group for export devices.

Figure 4 Deploying Changes

Step 3 Click Deploy to start the job. The Deployment Status window opens to show you the progress of the deployment. Carefully examine the results and any error messages.


Step 3: Create the Export File

After you ensure that all configuration changes are submitted and deployed, you are ready to create the export file that contains the devices and their policies.

Export the devices with their assigned policies and policy objects from the original Security Manager server using the following steps. Note that in this example, we assume that you will create a single export file containing 250 devices. However, you can instead create several smaller files, for example, 5 files of 50 devices each. Because the import process is all or nothing, creating several smaller export files might be the more desirable approach.

Read the following topics for more detailed information about creating export files that contain device policies:

Information Included when Exporting Devices with Their Policies

Tips for Exporting Devices with Their Policies


Tip At this point, do not make policy changes to the exported devices in the original server, and do not deploy configurations to those devices. If you find that you need to make changes to the devices from the original server before you complete the split, create a new export file.



Step 1 In Device view, select File > Export > Devices to open the Export Inventory dialog box.

Step 2 Select Export Devices, Policies, and Objects.

Step 3 Select the devices that you want to include in the export file and click >> to add them to the Selected Devices list. If you created a device group to contain your export files, simply select the group and click >> to move all devices in the folder.

The list from which you choose contains only those devices to which you have Modify Device permissions. For more information about permission requirements, see Tips for Exporting Devices with Their Policies.

Step 4 Click Browse to select the folder on the Security Manager server in which to create the export file and to enter a name for the file.


Tip The file type should be .dev; if it is something else, click Cancel and ensure that you select Export Devices, Policies, and Objects in the Export Inventory dialog box.


Step 5 Click Save to return to the Export Inventory dialog box. The Export Inventory To field is updated with the export file information. The following illustration shows how the Export Inventory window might look at this point. In this example, the export file is EastDevices.dev, located in the Windows temporary folder.

Figure 5 Exporting the Inventory

Step 6 Click OK to create the export file.

A message indicates when the export completes and whether there were errors in the export. When you click OK, if there are problems during the export, a dialog box opens listing the messages. If there is a Details button in the dialog box, you can select a message and click Details to see the message in a more readable format.


Information Included when Exporting Devices with Their Policies

When you export the device inventory along with all device properties, policies, and policy objects used by the device, the exported information includes the following:

All local and shared policies assigned to the devices, including all policy objects used in the policies and any device-level overrides for the objects. Shared policy assignments are maintained.

Device properties and inventory.

Configuration Archive data for the devices.

History snapshots for the devices.

Device certificates.

IPS device license and certificate information. Applied signatures are not exported (when importing the device, you must have the same signature package registered on the server). IPS update settings are not included.

The VPN topologies in which the devices participate. However, a VPN topology is exported only if all devices that participate in the topology are included in the export. Extranet VPNs are always exported.

Thus, the export file includes the complete policy configuration for the selected devices. The file created has the extension .dev and can be read only by another Security Manager server (the file contents are compressed and uninterpretable, which preserves the security of your policy information). The import process is explained in Step 5: Import the Device Inventory.

Tips for Exporting Devices with Their Policies

Before you export devices with their policies, you might want to review the following tips. Some device configurations might require special handling.

For performance reasons, you might want to limit your selection to 500 devices or fewer when exporting devices with policies.

Exported devices are not deleted from the inventory. This allows you the opportunity to import the devices into the new server and verify that you can deploy to the devices. After verifying the import, delete the devices from the original server.

If you select a device that uses an AUS or Configuration Engine to manage its configuration, you should also select the server in the list of devices to export.

You can export unmanaged devices. You might be using unmanaged devices in a VPN topology to represent devices that lie outside of your management domain.

Only policies and policy objects that have been submitted and approved are included in the export file. Make sure that all desired submissions and approvals have occurred before exporting devices with policies and policy objects.

The export file does not include event and report data (that is, data that is available through Event Viewer or Report Manager). Thus, the event and report data that was already collected for the device will not be available on the new server.

The export file does not include device group information. You will have to manually recreate device groups and assign devices to them after importing devices.

When selecting security contexts or virtual sensors, be sure to select the host device as well.

If a device is part of a VPN, ensure that you select all devices in the VPN.

When selecting IPS or IOS IPS devices, make sure that you have already applied an IPS signature update to the device. Although you can export an IPS or IOS IPS device with the base sensor package (Sig0), you will not be able to import it. The import error will be "missing Sig0 package."

When you select the following types of device that are contained in another device, the hosting device is also automatically exported: any module in a Catalyst 6500/7600, an AIM or NME module in a router. You can separately export ASA devices and their IPS modules.

You cannot export devices with their policies while an activity or configuration session is being approved. All approvals must be complete before you can export devices with policies. In Workflow mode with an approver, contact the approver and ask that the approval be completed in a timely manner. In non-Workflow mode, or Workflow mode without an approver, wait a few minutes before retrying the export, because approvals happen automatically when changes are submitted.

While you are exporting devices with their policies, policy changes cannot be approved. Once the export file has been created, and the command finishes, users can again approve policy changes. In non-Workflow mode, or Workflow mode without an approver, this means that submissions are not allowed during the export process.

To export devices, policies, and policy objects, you must have Modify Policy and Modify Object privileges to the policy and object types, and Modify Device privileges. These privileges can be assigned for separate policies, objects, and devices when using ACS for authorization control. Having system administrator, network administrator, or security administrator privileges provide the required privileges.

Step 4: Copy the Export File to the New Server

Copy the export files (*.dev) to the new Security Manager server. The file must be on a local drive on the server to import it.

Security Manager does not include any file transfer facilities for this process. Use any Windows file copying technique that is appropriate for your organization.

Step 5: Import the Device Inventory

After moving the inventory file to the new Security Manager server, you can import it. For helpful tips on the import process, see Tips for Importing Devices with Their Policies.


Tip Device groups are not preserved during import. All devices are placed in the All group. You need to manually recreate the desired device group structure and add the devices to the appropriate groups.



Step 1 In Configuration Manager, select File > Import to open the Import dialog box.

Step 2 Click Browse to select the file on the Security Manager server. Make sure that you select the desired file type (either .pol or .dev) from the Files of Type list on the Select a File dialog box. Click OK when you have selected the file.

The following illustration shows the Import dialog box with the EastDevices.dev file selected:

Figure 6 Importing the Inventory

Step 3 Click OK in the Import dialog box.

You are warned that imported policies or policy objects will replace same-named policies and objects, as shown in the following illustration.

Figure 7 Import Warning

Step 4 If you have the required authorization privileges (system administrator or Modify Admin), you have the option to deselect Display a warning on all shared policies and imported objects. When selected, the banner for shared policies and imported objects warns users that shared policies might have been created during import, and that specific objects were in fact created during import. This warning provides notice that if the user changes the policy or object, those changes might be overridden by a subsequent policy import. Select whether you want to display a warning and click Yes.


Tip If you decide later that you want to change whether the warning is displayed, you can modify the Display a warning on all shared policies and imported objects option on the Tools > Security Manager Administration > Policy Management page.


The information is imported and you are informed of the results. If errors occur, nothing is imported and a dialog box opens that explains the errors. The most common errors include duplicate device display names when importing devices, or locks on shared policies or policy objects that have the same name as those being imported.

To resolve the duplicate display name problem, you must delete the device from the inventory or rename it. You cannot selectively import devices, you must import all or none.


Note Not all duplicate device names might be listed. When using AUS or Configuration Engine to manage configuration deployment, imported AUS and Configuration names are evaluated before managed device names. Thus, you might see new duplicate display name errors after fixing the first set of errors.


To resolve the locking problem, you must ensure that users submit their policy changes and have them approved. When importing devices, you might have to delete the imported devices before retrying the import.


Tip When importing devices, it might take some time for the devices to appear in the device list in Device view.


Step 5 Because policy changes are performed under an activity or configuration session, the imported policies and policy objects are not yet committed to the Security Manager database. You must submit and approve the changes. Select File > Submit.

If you are not happy with the import, you can discard the activity or configuration session. However, when importing devices, the devices are added outside an activity or configuration session. Therefore, if you discard the activity or configuration session, you discard the device policies and VPN topologies, but the devices remain in the inventory. You should also delete the devices by selecting File > Delete Devices in Device view.

Step 6 (Optional) If you want to structure the devices in device groups, create the groups and add the devices to the appropriate groups.


Tips for Importing Devices with Their Policies

Before you import devices with their policies, you might want to review the following tips. These tips also apply when you are simply importing shared policies, because you are also importing shared policies when you import devices (if the shared policy is assigned to an imported device).

When importing devices, the server must have a sufficient Security Manager license to support the number and types of devices that you are importing.

When importing policies, whether during device or shared policy import, only the policy types selected for management on the Security Manager Administration Policy Management page will be visible. However, all policies are imported. If you select a previously deselected policy type for management, those imported policies appear with their imported configurations. You select which policies will be managed in the Tools > Security Manager Administration > Policy Management page.

When importing shared polices and policy objects, if a policy or object on the server has the same name as an imported one, it is replaced by the imported policy or object. If there are locks on the policy or object, the import for that policy or object will fail. The message will indicate that the failure was due to a locking problem. To avoid problems, ensure that all users have submitted and approved any changes to shared policies or policy objects before doing an import.

When importing devices, any shared policies and policy objects assigned to the device are also imported, and these policies and objects replace existing policies and objects under the same conditions as used when importing shared policies.

To import policies and their policy objects, you must have Modify Policy and Modify Object privileges to the policy and object types. When importing devices, you must also have Modify Device privileges. These privileges can be assigned for separate policies, objects, and devices when using ACS for authorization control. Having system administrator, network administrator, or security administrator privileges provide the required privileges.

You can import a file only if it was exported from a server running the same release of Security Manager.

You cannot import a device if the device is already in the inventory. Thus, you cannot update device policies from an import file. If you want to re-import a device, first delete it from the inventory.

When importing devices that use AUS or Configuration Engine servers to manage configuration deployment, the servers must either be included in the import file or already be defined in the Security Manager server, but not both. You will get duplicate display name errors if the import file includes an AUS or Configuration Engine already defined in the inventory. You will get an "invalid server selection" error if you try to import a device that has an AUS or Configuration Engine server assigned to it, but the server is not included in the import file or defined in the inventory.

You can import unmanaged devices.

When importing IPS devices, the server must have the same signature levels as the imported devices. For example, if you import two IPS devices, one running signature level 481 and the other 530, you must have both 481 and 530 installed on the server. You might need to download signature packages before importing IPS devices using the Tools > Security Manager Administration > IPS Updates page or the Tools > Apply IPS Updates command. See Before the Split: Download IPS Updates to the New Security Manager Server.

Step 6: Verify that You Can Configure the Imported Devices

Verify that the new Security Manager server can manage the newly-imported devices. For example, you could do a deployment, even for unchanged devices, to ensure that the new server can successfully contact all devices and deploy configurations.

The online help and User Guide for Cisco Security Manager have chapters on troubleshooting device connectivity and deployment.

Tips

As explained in Step 5: Import the Device Inventory, you must submit policies before the changes are available for configuring devices. Submit policies before doing a deployment.

If you did not already add the new server's IP address to the Access Rules or Allowed Hosts policies before doing the export/import, the new server might not be able to successfully connect to the device. You will have to fix the device configuration using a device manager or the CLI before you can verify that you can manage the devices. For more information about policies that should include the new server's IP address, see Before the Split: Add New Security Manager Server to Applicable Device Policies.

Step 7: Update Policies to Point to the New Security Manager Server

At this point, you have a set of devices that are included in the device inventory of two Security Manager servers, and you know that the devices can be successfully managed through both servers.

However, as explained in Policies Where You Should Refer to A Single Security Manager Server, you might still have policies that should point to a single Security Manager server, but currently all of your devices point to the original server.

For purposes of example, we will assume that you were monitoring the imported devices using Event Viewer (and Report Manager, for ASA devices) on the original server. The original server is still receiving events from these devices. You now need to update the Syslog Servers policy on ASA and FWSM devices so that they start sending events to the new Security Manager server and stop sending them to the original server.


Tip None of the event or report data from the original server was transferred to the new server. You might also want to generate reports on the old server before you deploy changes to the Syslog Servers policy.


The following sections explain your options based on whether you chose to create a separate shared policy, or to use device-level overrides on a network/host object. The examples are specific to the Syslog Servers policy, but the concepts are the same for any other policy that falls into this category.

Step 7.1: Assigning a New Shared Syslog Servers Policy

Step 7.2: Using a Device-Level Override to Specify the New Syslog Server Address

Step 7.3: Verify that Syslog Events Start Appearing

Step 7.1: Assigning a New Shared Syslog Servers Policy

For purposes of this example, assume that you created the following shared ASA/FWSM Syslog Servers policies on the original server:

West Syslog Server—Specifies the original Security Manager server as a syslog server.

East Syslog Server—Specifies the new Security Manager server as a syslog server.

As explained in Policies Where You Should Refer to A Single Security Manager Server, you had the following options for getting the East Syslog Server policy added to the new Security Manager server:

1. Assign the East Syslog Servers policy to the devices you were going to move, while ensuring that the defined syslog server was the original server's IP address. If you used this technique, the policy assignment is already complete, and you simply need to update the East Syslog Servers policy to replace the IP address of the original server with the new server. Deploy the configuration and the change is complete.

2. Create a dummy device by adding an non-existent ASA device "by manual definition" (File > New Device, select Add New Device), then assign the East Syslog Servers policy to the device, and include the device in the export file. Assuming that you have a sufficient license count in the Security Manager license, this is probably the easiest of these techniques.

3. Do not assign the East Syslog Servers policy to any device, but do a separate shared policy export/import. You need to follow the shared policy export/import procedure described in Synchronizing Shared Policies Among Security Manager Servers before completing this procedure.

The following procedure assumes that the East Syslog Servers policy is now in the new Security Manager server's database, but that it is not yet assigned to the moved devices.


Step 1 In Policy view, select PIX/ASA/FWSM Platform > Logging > Syslog > Syslog Servers from the Policy Type selector.

Step 2 Select East Syslog Servers from the Policies selector. The policy is shown in the right pane.

Step 3 In the right pane, click the Assignments tab. This tab shows the devices to which the policy is assigned.

Step 4 In the available devices list, select all of the ASA or FWSM devices that should use the new Security Manager server as a syslog server and click >>.

Step 5 Click Save to save the assignment changes.

Step 6 Select File > Submit and Deploy to submit your changes and deploy them to the devices. See Step 2: Submit and Deploy All Configuration Changes.


Step 7.2: Using a Device-Level Override to Specify the New Syslog Server Address

As explained in Policies Where You Should Refer to A Single Security Manager Server, you could create a single network/host object to define the IP address of the Security Manager syslog server, and use device-level overrides to selectively change the address for specific devices.

Figure 1 shows an example of creating a host network/host object named SecManEventServer for this purpose. The following procedure shows how you would create the device-level override for your ASA or FWSM devices.


Step 1 Select Manage > Policy Objects to open the Policy Object Manager.

Step 2 Select Networks/Hosts in the Objects list. All IPv4 network/host objects are listed in the right pane.

Step 3 Right-click the SecManEventServer object in the right pane and select Edit Device Overrides. The Policy Object Overrides dialog box opens.

Step 4 Click the Create Override (+) button below the table to open the Create Overrides for Device dialog box.

Step 5 Select all of the available ASA or FWSM devices that should use the new Security Manager server as the syslog server and click >> to move them to the Overridden Devices list.

Figure 8 Selecting Devices for Object Override

Step 6 Click OK in the Create Overrides for Device dialog box. The Edit Host Multi Objects dialog box opens.

Step 7 In the Edit Host Multi Objects dialog box, change the IP address to the address of the new Security Manager server. The following illustration shows how the dialog box should look if 10.100.20.10 is the new server address.

Figure 9 Defining the Object Override for Multiple Devices

Step 8 Click OK in the Edit Host dialog box. The override is created for all selected devices and the Policy Object Overrides table is updated as shown in the following illustration.


Tip If you selected a large number of devices, it can take some time for the overrides table to update. Please be patient.


Figure 10 Updated Object Overrides List

Step 9 Click Close to close the dialog box, then click Close again to close the Policy Object Manager.

Step 10 Select File > Submit and Deploy to submit your changes and deploy them to the devices. See Step 2: Submit and Deploy All Configuration Changes.


Step 7.3: Verify that Syslog Events Start Appearing

Security Manager automatically selects supported devices for monitoring when you add them to the inventory. Thus, after changing the Syslog Servers policy to use the new Security Manager server, and deploying policies, the devices should start sending syslog events to Event Viewer. Event Viewer should also be retrieving events from IPS devices.

Give your devices some time to start generating and sending events (perhaps 30 minutes). Then, open the Event Viewer (for example, select Launch > Event Viewer from Configuration Manager) and verify that you are receiving the expected events.

Step 8: Delete Moved Devices from the Original Security Manager Server

On the original Security Manager server, select File > Delete Devices to delete the moved devices from the original server.


Tip Device deletion requires the removal of a lot of information from the database. If you delete a lot of devices at one time, it can take a while for the operation to complete. If you have a lot of devices to delete, consider deleting them in smaller groups.


Synchronizing Shared Policies Among Security Manager Servers

In this example, we are assuming that the two Security Manager servers manage devices of the same type; that is, the inventory split was not made along the lines of device technology. For example, there are ASA and IPS devices in the inventories of both servers.

In this case, there is a desire to maintain consistent policies across the servers, so that each server applies the same shared policy to devices. There might be more than one shared policy for a policy type, for example, there might be a set of shared access rules, so that the same set of mandatory and default access rules are inherited by all ASA devices.

When you have more than one Security Manager server, you can manually synchronize the shared policies among those servers. When you synchronize shared policies, the policy objects that are used by those shared policies are also synchronized. In this example, the West server is used to update policies, and they are then copied to the East server.

The following procedure is one that you should repeat on a regular basis to maintain shared policy consistency. You can do the procedure based on a set schedule or you can do it whenever you make changes to the shared policies, or both.

Tips

There is no programmatic way to identify a single Security Manager server as the "master" server, the one that contains the official version of shared policies. You must decide which server to use as the master and have the discipline to edit shared policies on that server only.

Use the same release of Security Manager software on all servers.

When importing shared policies and policy objects, the imported information always replaces any existing shared policies or policy objects of the same name. Therefore, if you allow users to create their own shared policies and objects on a server where you will import policies and objects, it is critical that you develop a policy and object naming standard so that user policies and objects are not accidentally overwritten by newly imported policies and objects.


Step 1 On the West (master) server, ensure that all configuration changes for the shared policies and policy objects have been submitted. You will need to ask the staff to submit their changes and have them approved, there is no simple way to determine this status within Security Manager.

When exporting shared policies, there is no need to ensure that new changes have been deployed to devices assigned to the policies. Device assignments and deployment status are not part of the exported information.

Step 2 Select File > Export > Policies to export the shared policies and any policy objects used by the policies. The export process creates a file with the extension pol. For this example, use SharedPolicies.pol.


Tip You cannot pick and choose which policies to export. You can select policy types only. All shared policies of a selected type are exported.


For more detailed information on the export steps, see the following topics:

Tips for Exporting Shared Policies

Exporting Shared Policies.

Step 3 Copy the export file to the East server. The file must be on a local drive on the server to import it.

Step 4 On the East server, select File > Import to import the shared policy information to the servers. Click Browse to select the SharedPolicies.pol file, then click OK to start the policy import.

The import process is identical to the device inventory import process, with the exception that only shared policies are being imported. Review the following topics for tips and details on the procedure:

Tips for Importing Devices with Their Policies

Step 5: Import the Device Inventory


Tip Any shared policies or objects that have the same name as imported ones are replaced. The import of a policy or object will fail if a user already has a lock on the policy or object.


Step 5 Because policy changes are performed under an activity or configuration session, the imported policies and policy objects are not yet committed to the Security Manager database. You must submit and approve the changes. Select File > Submit.

If you are not happy with the import, you can discard the activity or configuration session.

Step 6 If you do not want to import all of the shared policies, delete the ones you did not want to import on the East server. This is a manual process.


Tips for Exporting Shared Policies

Only shared policies and policy objects that have been submitted and approved are included in the export file. Make sure that all desired submissions and approvals have occurred before exporting policies.

All policy objects referenced by shared policies are also exported. However, if a policy object is not referenced, it is not exported. If there are unreferenced objects that you want to export, you can create a dummy shared policy that references the objects. You do not need to assign the policy to any device.

You cannot export policies while an activity or configuration session is being approved. All approvals must be complete before you can export policies. In Workflow mode with an approver, contact the approver and ask that the approval be completed in a timely manner. In non-Workflow mode, or Workflow mode without an approver, wait a few minutes before retrying the export, because approvals happen automatically when changes are submitted.

While you are exporting policies, policy changes cannot be approved. Once the export file has been created, and the command finishes, users can again approve policy changes. In non-Workflow mode, or Workflow mode without an approver, this means that submissions are not allowed during the export process.

To export policies and their policy objects, you must have Modify Policy and Modify Object privileges to the policy and object types. These privileges can be assigned for separate policies, objects, and devices when using ACS for authorization control. Having system administrator, network administrator, or security administrator privileges provide the required privileges.

Exporting Shared Policies

You can export shared policies and the policy objects that they use so that you can import them into another Security Manager server. This can help you maintain the same policies among a group of servers.


Step 1 In Configuration Manager, select File > Export > Policies to open the Export Shared Policies dialog box.

Before opening the dialog box, Security Manager must evaluate the shared policies that are defined.

Step 2 Select the types of shared policy you want to export from the Available Shared Policy Types list and click >> to move them to the selected list. You can select a folder to move all types within the folder to the selected list.

Only those policy types for which shared policies have been defined are listed.

Step 3 Click Browse next to the Export Shared Policies To field to select the folder on the Security Manager server where the export file should be created, and enter a name for the file. The file type is pre-selected as .pol; you cannot change the file type. Click OK to save the file name and location.

The following illustration shows how the Export Shared Policies dialog box would look for a small number of shared policies exported to the SharedPolicies.pol file in the Windows temporary directory.

Figure 11 Exporting Shared Policies

Step 4 Click OK in the Export Shared Policies dialog box to begin the export. When the export is completed, you are told how many shared policies were exported and if there are warnings or errors, a dialog box opens listing the problems.

You can now copy the export file to the other Security Manager server and import the policies as explained in Synchronizing Shared Policies Among Security Manager Servers.