-
null
The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
The following topics describe the concept of policies in Cisco Security Manager and how to use and manage them.
•Managing Policies in Device View
•Working with Shared Policies in Device View
•Managing Shared Policies in Policy View
In Security Manager, a policy is a set of rules or parameters that define a particular aspect of network configuration. You configure your network by defining policies on devices (which includes individual devices, service modules, security contexts, and virtual sensors) and VPN topologies (which are made up of multiple devices), and then deploying the configurations defined by these policies to these devices.
Several types of policies might be required to configure a particular solution. For example, to configure a site-to-site VPN, you might need to configure multiple policies, such as IPsec, IKE, GRE, and so forth.
Policies are assigned to one or more devices. After a policy is assigned to a device, any changes to the policy definition change the behavior of the device.
The following topics describe policies in more detail:
•Settings-Based Policies vs. Rule-Based Policies
•Service Policies vs. Platform-Specific Policies
•Local Policies vs. Shared Policies
•Understanding Rule Inheritance
•Policy Management and Objects
•Customizing Policy Management for Routers
Security Manager policies are structured as either rule-based policies or settings-based policies.
Rule-Based Policies
Rule-based policies contain one or more rules that govern how to handle traffic on a selected device, such as the access rules and inspection rules defined as part of a firewall service. Rule-based policies can contain hundreds or even thousands of rules arranged in a table, each defining different values for the same set of parameters. The ordering of the rules is very important, as traffic flows are assigned the first rule whose definition matches the flow (known as first matching).
The structure of the rules table depends on whether you configure a local policy or a shared policy (see Local Policies vs. Shared Policies). If you configure a local rule-based policy for a single device, the policy contains a flat table of local rules. If you configure a shared rule-based policy (either in Device view or Policy view), the table is divided into two sections, Mandatory and Default. Mandatory rules always precede the default rules. You can define rules in either section and move rules between sections using cut-and-paste.
When you define certain types of rule-based policies, such as firewall service policies, you can create a policy hierarchy in which rules located at lower levels in the hierarchy acquire properties from the rules located above them. This is known as rule inheritance. For example, you can define a set of inspection rules that apply globally to all firewalls, while supplementing these rules with additional rules that can be applied to a subset of devices. By maintaining common rules in a parent policy, inheritance enables you to reduce the chance of introducing configuration errors that will cause deployment to fail. For more information, see Understanding Rule Inheritance.
Settings-Based Policies
Settings-based policies contain sets of related parameters that together define one aspect of security or device operation. For example, when you configure a Cisco IOS router, you can define a quality of service (QoS) policy that defines which interfaces are included in the policy, the type of traffic on which QoS is applied, and the definition of how this traffic should be queued and shaped. Unlike rule-based policies, which can contain hundreds of rules containing values for the same set of parameters, you can define only one set of parameters for each settings-based policy defined on a device.
Related Topics
Security Manager policies are divided into several domains, each of which represents a major policy category. These domains can be divided into two categories: service policies and platform-
specific policies.
Service policies are divided into the following policy domains:
•Firewall
•Site-to-site VPN
•Remote Access VPN
•IPS service policies
For example, the firewall policy domain contains policies for access rules, inspection rules, and transparent rules, among others. The site-to-site VPN policy domain contains policies for IKE proposals, IPsec proposals, and preshared keys, among others. Service policies can be applied to any kind of device, regardless of platform, although there may be some variation in policy definition depending on the device type.
Platform-specific policy domains exist for firewall devices (PIX/ASA/FWSM) and Cisco IOS routers. These two domains contain policies that configure features that are specific to the selected platform. Not all platform-specific policies are directly related to security. For example, the Router policy domain contains routing policies, identity policies (Network Admission Control and 802.1x), policies related to device administration (DHCP, SNMP, device access), and other policies such as QoS and NAT.
In the case of Cisco IOS routers, you can choose whether Security Manager should manage all platform-specific policies. For more information, see these topics:
•Customizing Policy Management for Routers
•Policy Management Page, page A-33
Related Topics
The policies that you configure on devices can either be local or shared. Local policies refer to policies that are defined for a single device. Any changes that you make to a local policy affect only that device. Local policies are well-suited to smaller networks and to devices requiring nonstandard configurations. For example, you might configure a local policy on a router that requires a different OSPF routing policy than the one used by the other routers in your network. For more information about the actions you can perform on local policies, see Performing Basic Policy Management.
As your network grows, maintaining local policies on each device greatly increases the effort required to manage these policies in a comprehensive and efficient manner. To meet this challenge, Security Manager features policy sharing. With policy sharing, you can create a single policy and assign it to multiple devices. For more information, see Sharing a Local Policy.
Figure 6-1 Local vs. Shared Policies
For example, if you want all the Cisco IOS routers in your network to implement the same Network Admission Control (NAC) policy, you need only define a single NAC policy and share it. You can then assign the shared policy to all the routers in your network with a single action. For more information, see Modifying Shared Policy Assignments in Device View.
Any changes that you make to a shared policy are automatically applied to all the devices to which it is assigned. As a result, shared policies both streamline the process of policy creation and help maintain consistency and uniformity in your device configurations.
For more information about the actions you can perform on shared policies, see Working with Shared Policies in Device View.
Tip In addition to sharing policies, you can choose to inherit the rules of a rule-based policy when defining another policy of the same type. This makes it possible, for example, to maintain a set of corporate access rules that apply to all firewall devices while providing the flexibility to define additional rules on individual devices as required. For more information, see Understanding Rule Inheritance.
Shared Policies and VPNs
In the same way that shared policies facilitate device configuration, they also facilitate the configuration of VPNs. For example, you can create a shared IPsec proposal policy and assign it to multiple site-to-site VPNs. Any changes that you make to the shared policy affect all the VPNs to which the policy is assigned. For more information, see Managing Shared Site-to-Site VPN Policies in Policy View, page 9-44.
Related Topics
As described in Local Policies vs. Shared Policies, shared policies enable you to configure and assign a common policy definition to multiple devices. Rule inheritance takes this feature one step further by enabling a device to contain the rules defined in a shared policy in addition to local rules that are specific to that particular device. Using inheritance, Security Manager can enforce a hierarchy where policies at a lower level (called child policies) inherit the rules of policies defined above them in the hierarchy (called parent policies).
Rule Order When Using Inheritance
As described in Understanding Access Rules, page 11-17, an access list (ACL) consists of rules (also called access control entries or ACEs) arranged in a table. An incoming packet is compared against the first rule in the ACL. If the packet matches the rule, the packet is permitted or denied, depending on the rule. If the packet does not match, the packet is compared against the next rule in the table and so forth, until a matching rule is found and executed.
This first-match system means that the order of rules in the table is of critical importance. When you create a shared access rule policy, Security Manager divides the rules table into multiple sections, Mandatory and Default. The Mandatory section contains rules that cannot be overridden by the local rules defined in a child policy. The Default section contains rules that can be overridden by local rules.
Figure 6-2 describes how rules are ordered in the rules table when using inheritance.
Figure 6-2 Order of Rules When Using Inheritance
Benefits of Using Inheritance
The ability to define rule-based policies in a hierarchical manner gives you great flexibility when defining your rule sets, and the hierarchy can extend as many levels as required. For example, you can define an access rule policy for the device at a branch office that inherits rules from a parent policy that determines access at the regional level. This policy, in turn, can inherit rules from a global access rules policy at the top of the hierarchy that sets rules at the corporate level.
In this example, the rules are ordered in the rules table as follows:
Mandatory corporate access rules
Mandatory regional access rules
Local rules on branch device
Default regional access rules
Default corporate access rules
The policy defined on the branch device is a child of the regional policy and a grandchild of the corporate policy. Structuring inheritance in this manner enables you to define mandatory rules at the corporate level that apply to all devices and that cannot be overridden by rules at a lower level in the hierarchy. At the same time, rule inheritance provides the flexibility to add local rules for specific devices where needed.
Having default rules makes it possible to define a global default rule, such as "deny any any", that appears at the end of all access rule lists and provides a final measure of security should gaps exist in the mandatory rules and default rules that appear above it in the rules table.
Inheritance Example
For example, you can define a mandatory worm mitigation rule in the corporate access rules policy that mitigates or blocks the worm to all devices with a single entry. Devices configured with the regional access rules policy can inherit the worm mitigation rule from the corporate policy while adding rules that apply at the regional level. For example, you can create a rule that allows FTP traffic to all devices in one region while blocking FTP to devices in all other regions. However, the mandatory rule at the corporate level always appears at the top of the access rules list. Any mandatory rules that you define in a child policy are placed after the mandatory rules defined in the parent policy.
With default rules, the order is reversed—default rules defined in a child policy appear before default rules inherited from the parent policy. Default rules appear after any local rules that are defined on the device, which makes it possible to define a local rule that overrides a default rule. For example, if a regional default rule denies FTP traffic to a list of destinations, you can define a local rule that permits one of those destinations.
IPS Policy Inheritance
Event action filter policies for IPS devices can also use inheritance to add rules defined in a parent policy to the local rules defined on a particular device. The only difference is that although active and inactive rules are displayed together in the Security Manager interface, all inactive rules are deployed last, after the inherited default rules.
Signature policies for IPS devices use a different type of inheritance that can be applied on a per-signature basis. See Configuring Signatures, page 12-7.
Related Topics
•Settings-Based Policies vs. Rule-Based Policies
•Understanding Access Rules, page 11-17
It is important to understand the difference between rule inheritance and policy assignment:
•Inheritance—When you inherit the rules from a selected policy, you do not overwrite the local rules that are already configured on the device. Instead, the inherited rules are added to the local rules. If the inherited rules are mandatory rules, they are added before the local rules. If the inherited rules are default rules, they are added after the local rules. Any changes that you make to the inherited rules in the parent policy are reflected in the policy that inherits those rules.
Note Inheritance works differently for IPS signature policies and signature event actions. For more information, see Understanding Signature Inheritance, page 12-8.
•Assignment—When you assign a shared policy to a device, you replace whatever was already configured on the device with the selected policy. This holds true whether the device previously had a local policy or a different shared policy of that type.
Therefore, when working with rule-based policies such as access rules, you must use discretion when choosing these options. Use inheritance to supplement the local rules on the device with additional rules from a parent policy. Use assignment to replace the policy on the device with a selected shared policy.
Tip To prevent overwriting your local rules by mistake, Security Manager displays a warning message when you select the Assigned Shared Policy option for a rule-based policy. The message provides you the option of inheriting the rules of the policy instead of assigning it. Choose the inheritance option if you want to preserve your local rules.
Related Topics
•Understanding Rule Inheritance
•Local Policies vs. Shared Policies
•Settings-Based Policies vs. Rule-Based Policies
Objects make it easier to configure policies in Security Manager by providing a set of values with a logical, easy-to-remember name that can be applied wherever it is needed. For example, you can define a network/host object called MyNetwork that contains a set of IP addresses in your network. Whenever you configure a policy requiring these addresses, you can simply refer to the MyNetwork object instead of manually entering the addresses each time.
When you define a policy, you can create objects on the fly by clicking the Select button next to any field that accepts an object as a value. For more information, see Selecting Objects for Policies, page 8-2. You can also create and manage objects system-wide from the Policy Object Manager Window, page F-1.
Policy objects also are created when you discover policies that already exist on a device. You can discover policies when you add a device to the Security Manager inventory, or you can discover policies on devices that are already in the inventory, as described in Discovering Policies. You can configure Security Manager to reuse already-defined policy objects for newly-discovered policies. For more information on configuring policy object settings for discovery, see Discovery Page, page A-16.
Certain types of objects enable you to override their predefined values at the device level, which enables you to use an object in a policy while retaining the ability to customize particular values. For more information, see Understanding Policy Object Overrides for Individual Devices, page 8-9.
For more information about objects and how to use them when defining policies, see Chapter 8, "Managing Policy Objects."
Related Topics
Security Manager has a locking mechanism that is useful in organizations where several people have the authority to make configuration changes. It prevents a potential situation in which two or more people are making changes to the same device, policy, policy assignment, or object at the same time. When a lock is applied, a message is displayed across the top of the work area to other users who access that device or policy.
Lock Types
Security Manager uses two different types of locks:
•Policy content locks—Locks the content of a particular policy. The banner displayed above the work area reads:
This data for this policy is locked by activity/user: <name>.
The content lock prevents other users from making any changes to the configuration of the locked policy.
•Assignment locks—Locks the assignment of a policy type to a particular device. The banner displayed above the work area reads:
The assignment of this policy is locked by activity/user: <name>.
For a local policy, an assignment lock prevents other users from unassigning the policy or assigning a shared policy of the same type in place of the local policy. For a shared policy, an assignment lock prevents other users from assigning a different shared policy of the same type in place of one already assigned.
These locks can either work together or independently of one another, depending on the actions being performed by the user. If both locks are active at the same time, the banner displayed above the work area reads:
This policy is locked by activity/user: <name>.
See Understanding Locking and Policies for a summary of the effects locking has on the actions you can perform.
Releasing Locks
After is locked is enabled, it remains in place until you either submit your changes (when working in non-Workflow mode) or submit and approve the activity (when working in Workflow mode). If you discard the activity, any locks generated by the activity are also discarded. For more information about workflow modes, see Selecting a Workflow Mode, page 1-12.
Keep in mind that:
•Locks are based on the device name, not the IP address of the device. Therefore, we recommend that you avoid defining two devices with different names but the same IP address in Security Manager. Any attempt to deploy to both devices, especially at the same time, leads to unpredictable results.
•In addition, locks do not extend across different operations. For example, locking does not prevent one user from deploying to the same device that is being discovered by a different user.
Additional details about locking can be found in the following sections:
•Understanding Locking and Policies
•Understanding Locking and VPN Topologies
•Understanding Locking and Objects
Table 6-1 summarizes the effects of policy locks in Security Manager.
Note The ability to modify policies and policy assignments is dependent on the user permissions assigned to the user. See the Installation Guide for Cisco Security Manager.
Related Topics
When you change the device assignment for a VPN topology, or make changes to a specific VPN policy, a lock is placed on the complete topology. This means that other users cannot make changes to the device assignment, nor can they make changes to any of the VPN policies defined for that topology.
In order to view and modify VPN policies, you must have the required permissions for each of the devices that make up the VPN topology. Permissions are also required to add a device to a VPN topology. If you have different levels of permissions to the devices that make up the VPN topology, the lowest permission level is applied to the entire topology.
For example, if you have read/write permissions to the devices that comprise the spokes in a hub-and-spoke VPN, but read-only permissions to the device serving as the hub, you are granted read-only permission to the policies and composition of the hub-and-spoke topology. For more information about permissions, see the Installation Guide for Cisco Security Manager.
Related Topics
•Chapter 9, "Managing Site-to-Site VPNs"
When you create or modify a reusable object, that object is locked to prevent other users from modifying or deleting the same object. Additional rules for object locking include:
•An object lock does not prevent you from modifying the definition or assignment of a policy that uses that object.
•The lock placed on a policy does not prevent you from making changes to an object that is included in the policy definition.
•You can change the definition of any object even if it is part of a policy assigned to a device to which you do not have permissions.
•When an object makes use of other objects (such as network/host objects and AAA server group objects), the lock on the object does not prevent another user from modifying those other objects. For example, when you modify a AAA server group object, the lock on that object does not prevent another user from modifying any of the AAA servers that make up the AAA server group.
When an object is locked, users who try to modify that object see a read-only version of the relevant dialog box. When you are working in Workflow mode, a message indicates which activity has locked the object.
Related Topics
•Chapter 8, "Managing Policy Objects"
When you manage Cisco IOS routers, you have the option of selecting which policy types to manage with Security Manager and which policy types to leave unmanaged. Managing a policy type means that Security Manager controls the configuration of the policy and considers the information that it stores in its database about that policy to be the desired configuration. Security Manager does not configure unmanaged policy types, nor does it track configurations of these types that were configured using other methods. For example, if you decide not to manage SNMP policies, any SNMP configurations that you configured using CLI commands are unknown to Security Manager.
The ability to customize policy management on a Cisco IOS router makes it possible, for example, to use Security Manager to manage DHCP and NAT policies on Cisco IOS routers while leaving routing protocol policies, such as EIGRP and RIP, unmanaged. These settings, which can be modified only by a user with administrative permissions, affect all Security Manager users.
Unmanaged policies are removed from both Device view and Policy view. Any existing policies of that type, local or shared, are removed from the Security Manager database.
You cannot unmanage a policy type if you have configured and assigned policies of that type in Security Manager. You must first remove the assignments and then unassign the policy type. If the configurations defined by those policies have already been deployed, these configurations are left in place on the devices, but the policies will no longer be stored in the database or accessible from the Security Manager interface. Configurations that were defined using CLI commands or FlexConfigs are left in place.
If you change a particular policy from unmanaged to managed, you can again modify the configuration of that policy using Security Manager.
Note Features that are unmanaged by Security Manager can still be modified manually with CLI commands or FlexConfigs. For more information about FlexConfigs, see Chapter 18, "Managing FlexConfigs".
To customize policy management of Cisco IOS routers, select Tools > Security Manager Administration > Policy Management. Select or deselect policy types as desired and click Save. For more information, see Policy Management Page, page A-33.
Related Topics
Policy discovery enables you to bring your existing network configuration into Security Manager to be managed. Policy discovery can be performed by importing the configuration of a live device or by importing a configuration file. If you import a configuration file, the file must have been generated by the device (for example, by using the show run command on Cisco IOS Software devices); you cannot discover configuration files in any other format.
You can initiate policy discovery when you add a device by selecting the relevant options in the New Device wizard. For more information, see Adding Devices to the Device Inventory, page 5-7.
You can also initiate policy discovery on existing devices from Device view. For more information, see Discovering Policies on Devices Already in Security Manager.
When you initiate policy discovery on a device, the system analyzes the configuration on the device and then translates this configuration into Security Manager policies and policy objects so that the device can be managed. Warnings are displayed if the imported configuration completes only a partial policy definition. If additional settings are required, you must go to the relevant page in the Security Manager interface to complete the policy definition. Warnings and errors are also displayed if the imported configuration is invalid.
After performing policy discovery, you must submit your changes (or approve your activity when working in Workflow mode) to have the information included in change reports and to make the information available to other users. If you make any changes to the discovered policies, you must deploy the changes to the device for them to take effect. For more information, see Chapter 17, "Managing Deployment".
Tip Use the Security Manager Administration window to configure discovery-related settings that apply to all devices. For more information, see Discovery Page, page A-16.
Policy Discovery and VPNs
In addition to performing discovery on individual devices, Security Manager allows you to discover the VPNs that are already deployed in your network. How you discover VPNs depends on the type of VPN being discovered:
•Site-to-Site VPNs—A wizard walks you through the discovery procedure step by step. For more information, see Site-To-Site VPN Discovery, page 9-8.
Tip We recommend that you deploy to a file immediately after discovering a Site-to-Site VPN. This enables Security Manager to assume full management of the relevant CLI commands that are configured on the device.
•IPSec and SSL Remote Access VPNs—You can discover IPSec and SSL VPNs when you discover policies on the device, either when you add the device to the inventory or if you discover policies on a device already in the inventory. Policies related to these VPNs are treated as regular device policies. However, when selecting discovery options, you must specifically select to discover RA VPN policies. For more information, see Adding Devices to the Device Inventory, page 5-7 and Discovering Policies on Devices Already in Security Manager.
Policy Discovery and Cisco IOS Routers and Catalyst Devices
Security Manager supports a subset of the complete list of commands available in the Cisco IOS software, mostly centered on security-related commands. You can discover all supported Cisco IOS commands. Commands that are not supported are left in place unless they conflict directly with a policy configured in Security Manager. For more information about performing policy discovery on Cisco IOS routers, see Discovering Router Policies, page 13-3. For more information about performing policy discovery on Catalyst devices, see Discovering Policies on Cisco Catalyst Switches and Cisco 7600 Series Routers, page 15-2.
Tip We recommend that you deploy to a file immediately after discovering a Cisco IOS router or Catalyst device. This enables Security Manager to assume full management of the relevant CLI commands that are configured on the device.
When you add a device that has security contexts, you should discover all contexts and policies at the same time; otherwise, you will have to discover policies for each context separately. When you add the device, select MULTI for Context and do not select Security Context of Unmanaged Device. (If you select this option, only the admin context is imported, and it has no relationship to other security contexts on the device; select this option only if you want to manage the security context independently from the parent device.) Depending on how you add the device, you might need to select the option to discover security contexts. During discovery, Security Manager identifies each security context and adds it as a separate device to the device list, appending the security context name to the end of the parent's name; for example, if the parent is pix_141, the admin context would be pix_141_admin. (You can control the naming convention for security contexts; for more information, see Discovery Page, page A-16). You can create new security contexts, or delete existing contexts, as well as create and delete policies for those contexts.
If you create multiple security contexts on FWSM, which are contained in Catalyst 6500 devices, and you are running IOS software on the chassis, add the chassis device using the SSH credentials for the chassis. Then Security Manager can identify each FWSM on the chassis, and give you the option to add each of them. During FWSM discovery, Security Manager discovers the security contexts for each FWSM, including the policies for the FWSM and for each context. However, if you are using the Catalyst OS on the device, you must discover each FWSM individually.
For more information about adding devices to the inventory, see Adding Devices to the Device Inventory, page 5-7.
Policy Discovery and IPS Devices
When you discover policies on an IPS device, the virtual sensors defined on the device are also discovered along with the policies defined for the virtual sensors. If more than one virtual sensor uses the same policy, that policy is created as a shared policy and is assigned to the virtual sensors. Policies defined for a single virtual sensor, or only for the parent device, are created as local policies. You cannot discover policies just for an individual virtual sensor; you can discover policies only on the parent device. If policies are discovered on the parent device that are not assigned to any virtual sensors, those policies are created as shared policies that are not assigned to any device or virtual sensor.
After discovering an IPS device that contains virtual sensors, you must submit your changes to the database for the virtual sensors to appear in the device selector.
Policy Discovery and Object Groups
When you perform policy discovery, any object groups already configured on firewall devices (PIX, ASA, and FWSM) are brought into Security Manager as policy objects. For more information about how Security Manager policy objects are translated into object groups and vice-versa, see How Policy Objects are Provisioned as ASA/PIX/FWSM Object Groups, page 8-96.
Policy Discovery and Security Manager Policy Objects
When you perform policy discovery, Security Manager tries to reuse the policy objects that you have already created in Security Manager. Based on the contents of the device configuration, the following are the possible actions:
•Named policy objects in the configuration—Existing policy objects are reused if their content matches the configuration on the device.
If the contents of the named policy object does not match, the policy object is reused and a device-level override is created if Allow Device Override for Discovered Policy Objects is selected on the Discovery administration page. For more information, see these topics:
–Understanding Policy Object Overrides for Individual Devices, page 8-9
•Unnamed policy objects in the configuration—Existing policy objects are used if their content matches the configuration on the device. You can control this behavior by changing the value of the Reuse Policy Objects for Inline Values setting on the Discovery administration page.
•You can discover objects that have the same definition as existing objects, regardless of the setting you have defined for detecting redundant objects. For more information about this setting, see Policy Objects Page, page A-35.
For more information on policy objects, see Chapter 8, "Managing Policy Objects."
Policy Discovery and Access Control Lists
Certain policies in Security Manager support only standard or only extended ACLs, even if both types are supported by the CLI. In such cases, policy discovery works as follows:
•If the Security Manager policy supports only extended ACLs (for example, firewall service policies), any standard ACLs configured on the device for that policy are imported as extended ACLs.
•If the Security Manager policy supports only standard ACLs (for example, SNMP traps on IOS routers), any extended ACLs configured on the device for that policy are imported as standard ACLs.
During the discovery process, Security Manager will show any inactive ACLs that are imported as disabled. If you later deploy these disabled ACLs, they are removed from the device configuration.
Related Topics
•Frequently Asked Questions about Policy Discovery
•Viewing Policy Discovery Task Status
•Understanding Policy Object Overrides for Individual Devices, page 8-9
When you add a device to the inventory, you can discover policies at the same time that you add the device. However, you can skip policy discovery and do it later, or rediscover policies after adding the device.
You might initiate policy discovery on existing devices when:
•You discover out-of-band changes in the network, for example, changes to device configurations using CLI commands. In such a situation, you can rediscover existing policies on the device to make sure that the Security Manager database has the most current information. However, we recommend that you enter out-of-band changes in Security Manager rather than perform rediscovery.
•You want to discover a subset of policies (for example, platform-specific settings) that was not discovered when you first added the device to Security Manager.
•You want to import the factory-default configuration of a firewall device. For more information, see Default Firewall Configurations, page 14-1.
Before You Begin
Ensure that no one is configuring policies on the device or deploying configurations to the device. If you rediscover policies on a device while a deployment job is deploying configurations to the device, you might not be able to see the deployed changes after the rediscovery. Use the Deployment Manager to determine if there are active jobs that include the device before you rediscover policies (select Tools > Deployment Manager). If you inadvertently rediscover policies during a deployment job, wait until the deployment job is completed and then discover policies again to ensure that Security Manager is synchronized with the device.
Related Topics
•Viewing Policy Discovery Task Status
•Frequently Asked Questions about Policy Discovery
•Managing Policies in Device View
•Managing Shared Policies in Policy View
Step 1 In Device view, select a device from the Device selector and do one of the following:
•Select Policy > Discover Policies on Device.
•Right-click the device in the Device selector and select Discover Policies on Device.
Tip You can also right click a device in Map view and select Discover Policies on Device.
The Discover Policies on Device dialog box is displayed (see Discover Policies On Device Dialog Box, page D-10).
Step 2 (Optional) Modify the default name assigned to the discovery task. The default name is based on the date and time the task is initiated.
Step 3 Select the type of policy discovery to perform:
•Live Device—Discovery is performed on the live device.
•Config File—Discovery is performed using a configuration file. Enter the path to the file, or click Browse to select the file.
•Factory Default Configuration—Discovery is performed using a file containing the factory-default configuration for the selected device. You can discover the default configuration only for devices that run in single-context mode or for individual security contexts.
Tip We recommend that you use the Factory Default Configuration settings when you add PIX, ASA, and FWSM devices manually (as described in Adding Devices by Manual Definition, page 5-11). You should discover the default configuration for single-context mode devices and for each security context on a multiple-context mode device. For more information about factory-default policies, see Default Firewall Configurations, page 14-1.
Step 4 (Optional) Under Policies to Discover, refine the scope of the discovery task by selecting or deselecting the following check boxes:
•Inventory—Discovers basic device information (such as hostname and domain name), interfaces, and security contexts on devices running in multiple-context mode. On Cisco IOS routers, this option also discovers all interface-related policies, such as DSL, PPP, and PVC policies.
•Platform Settings—Discovers platform-specific policies, such as routing policies.
•Firewall Services—Discovers firewall service policies, such as access rules and inspection rules, on all platforms.
•RA VPN—Discovers IPSec and SSL remote access VPN policies, such as IKE proposals and IPsec proposals.
•IPS—Discovers IPS policies, such as signatures and virtual sensors.
Tip For more information about the difference between different types of policies, see Service Policies vs. Platform-Specific Policies.
Step 5 Click OK. The discovery task is initiated and the Discovery Status dialog box opens so you can view the task status (see Discovery Status Dialog Box, page D-12). You cannot perform other tasks in Security Manager while discovery is in progress.
When you initiate policy discovery a discovery task is created. For each policy discovery initiation, only one task is created regardless of the number of devices being discovered.
You can view the status of the current policy discovery task in the Discovery Status dialog box, which opens automatically when the task is initiated. This dialog box provides updated status information about the discovery task, including summary information about the task and details about each device being discovered.
You can abort a discovery task, if required. When you perform policy discovery on a single device, aborting the task results in partial discovery. In such cases, we recommend deleting the information and starting again. When you perform policy discovery on multiple devices, any devices for which discovery was completed before you aborted the operation are fully discovered. Security Manager automatically discards the information for any partially discovered device.
The Discovery Status dialog box also displays the appropriate warning and error messages if any problems are encountered during the discovery process. For example, if the CLI commands in a configuration file do not define a complete Security Manager policy, a warning message is displayed that you must complete the policy definition in the relevant Security Manager policy page.
For more information, see Discovery Status Dialog Box, page D-12.
To view information about previous discovery tasks, select Tools > Policy Discovery Status to open the Policy Discovery Status window. Select the discovery task in the top pane of the window, and the results of the task are displayed in the lower panes. For more information about using the Policy Discovery Status window, see Policy Discovery Status Page, page D-14.
Related Topics
•Discovering Policies on Devices Already in Security Manager
•Frequently Asked Questions about Policy Discovery
These questions and answers describe how policy discovery processes your device configurations into Security Manager policies.
Question: How does policy discovery work?
Answer: After you select the device whose policies, settings, and interfaces (inventory) you want to discover, Security Manager obtains the running configuration (from live devices) or the supplied configuration (when discovering from configuration files) and translates the CLI into Security Manager policies and objects. The imported configuration is added to the Configuration Archive as the initial configuration for the device. After discovery, you can review the discovered policies and objects and decide whether to commit them to the database. If you dislike them, you can discard them instead. Please note that commit and discard affect all discovered devices as a group and cannot be implemented on a per-device basis.
Question: When should I discover policies?
Answer: Typically, you should discover policies when you add devices to Security Manager. However, if you are creating devices in Security Manager (instead of importing live devices or configuration files), you must perform policy discovery after adding the device. You should also perform policy discovery in order to synchronize Security Manager with any out-of-band changes that have been made to the device, for example through the CLI.
Question: How can I determine the results of the discovery?
Answer: When you initiate a discovery task, a window opens that shows you the discovery status and results. You can also view a history of discovery task results on the Policy Discovery Status page (select Tools > Policy Discovery Status).
Question: Does Security Manager show which commands are not discovered, and what can I do about them?
Answer: In the task status window, go to the Message Summary section, then select Commands Not Discovered. Any undiscovered commands are listed in the Description field.
Question: How are discovered policies reflected in the user interface?
Answer: Security Manager converts the device commands into policies. There is no difference in appearance between a policy discovered from a device configuration and one defined directly in Security Manager.
Question: I am using Auto Update Server for my PIX or ASA devices. How do I discover policies?
Answer: If a device has a static IP address, you can discover policies from the device. If it has a dynamic IP address, you must discover policies from the device's configuration file (offline).
Question: I am using Cisco Secure ACS to manage authentication and authorization to Security Manager. How does this affect policy discovery?
Answer: You must add all managed devices to Cisco Secure ACS before you can perform policy discovery and manage these devices in Security Manager. This includes security contexts on PIX/ASA/FWSM devices. For more information, see the Installation Guide for Cisco Security Manager.
Question: What should I do after discovering VPN or router platform policies?
Answer: Due to the way these features are discovered, Security Manager does not assume management of discovered VPN and router platform policies until after it deploys them. This means that if you discover a router, unassign one of its policies and deploy, no commands are removed from the router's configuration. We recommend, therefore, that you perform deployment to a file immediately after discovering VPN or router platform policies, before you make any changes to those policies. After this initial deployment, you can reconfigure these policies and deploy your changes as required.
Question: If I discover policies on a device and then deploy the policies from Security Manager without changing them, what is the difference between the original configuration on the device and the one that exists after the deployment?
Answer: Typically, there will be no differences between the new configuration and your original one, assuming you set up FlexConfigs for any unsupported CLI commands (since they are not displayed in Security Manager). However, in certain cases minor changes might occur in your ACL or object-group naming schemes. For more information, see How Policy Objects are Provisioned as ASA/PIX/FWSM Object Groups, page 8-96. In addition, any discovered objects that are not being used by a policy are removed from the configuration. There can also be instances where the new configuration is functionally equivalent to the old one but does not use the same commands.
Question: How does Security Manager handle my current CLI naming schemes for ACLs and object groups?
Answer: When you discover policies from a device, Security Manager tries to use the same names you have used. However, depending on your naming scheme, some minor differences might occur between what you defined on your device and the policies created through discovery. Additionally, there is a possibility that a naming conflict can occur between an existing ACL or object on the device and the name required for the new policy or object; in this case, Security Manager generates a different name so as not to misconfigure the device. For example, if the name of a discovered object conflicts with an object of the same type that already exists in Security Manager, a suffix is added to the name of the new object to make it unique or a device-level override is created.
Question: Are all configuration commands discovered and brought into Security Manager?
Answer: No. Security Manager does not discover all device configuration commands. Instead, it discovers security policies. For any configuration commands not discovered, use the FlexConfig feature to include the commands that Security Manager does not support.
Question: If I rediscover policies on a device already in Security Manager, what happens to the policies assigned to the device?
Answer: If you rediscover policies on a device that you are already managing with Security Manager, the newly discovered policies replace the ones assigned to the device. All policies within the selected policy domain (firewall services, platform settings, or both) are replaced, not just the ones that are different on the device compared to the ones in the Security Manager database. If you assigned shared policies to the device, the assignment is removed and the shared policy is left unchanged (so that other devices that use the shared policy are not affected). After policy discovery, all policies assigned to the device are specific to that device; none of them are shared with other devices. If you want to use shared policies with the device, you must redo the assignments after policy discovery.
Question: Does Security Manager use existing policies and objects during policy discovery?
Answer: During policy discovery, Security Manager uses existing policy objects (ones that you already defined in Security Manager) when creating policies for the device. However, Security Manager does not reuse existing policies; all policies created during discovery are local to the device being discovered. Thus, you might find it beneficial to define your policy objects (such as network objects) before adding devices to Security Manager.
Question: After adding a device and discovering policies, I cannot submit my changes to the database; instead I get warnings such as "Connection Policies Not Set." What must I do to complete the device addition?
Answer: When you add a device and discover policies (particularly when you add devices from configuration files), Security Manager warns you if the resulting configuration is incomplete in ways that will prevent it from successfully managing the device. Connection policies, for example, are simply the device credentials (user names and passwords) required to log into the device, as well as other connection-related configuration settings (such as HTTP settings). Because these missing settings result in an invalid configuration or prevent Security Manager from contacting and managing the device later, you are prevented from submitting the changes to the database. Ensure that you have complete and valid configurations for these settings, then resubmit your changes to the database.
Question: Why does the AAA policy not show the AAA configuration that I discovered on the device?
Answer: The AAA policy contains the default configurations for authentication, authorization, and accounting. Other AAA commands that specify a particular list name are mapped to the policies that reference them. If the list name is not referenced by a policy, it is not discovered.
Question: Can I discover AAA servers on devices running IOS software that were configured using the server-private command?
Answer: Yes, you can discover these servers. However, Security Manager converts them into standard AAA servers that can be used globally or in multiple AAA server groups. The server-private command is not supported.
Question: What do I need to know about discovery and device hostnames?
Answer: When you discover a device, the hostname policy is populated with the hostname discovered on the device. However, the hostname listed in Device Properties is not updated with this value. For more information, see Understanding Device Properties, page 5-6.
You can use Device view to manage both local policies and shared policies, as described in the following sections:
•Performing Basic Policy Management
•Working with Shared Policies in Device View
To access Device view, select View > Device View or click the Device View button on the toolbar.
Related Topics
•Understanding the Device View, page 5-1
•Managing Shared Policies in Policy View
You can learn the status of any policy in Security Manager at a glance by viewing the icon displayed next to the policy name.
Related Topics
The following topics describe the operations you can perform on local policies in Device view. Local policies are policies that are specific to the device or VPN topology on which they are configured. They are not shared by other network elements.
•Configuring Local Policies in Device View
•Copying Policies Between Devices
Related Topics
•Working with Shared Policies in Device View
•Managing Shared Policies in Policy View
Use Device view to configure local platform and service policies on individual devices. Each policy defines a particular configuration or security task that the device can perform, such as NAT, OSPF routing or inspection rules. Local policies are unnamed and are particular to the individual device on which they have been defined. Any changes that you make to a local policy do not affect other devices that Security Manager is managing.
When you configure a policy, a lock is placed on that policy to prevent other users from making changes to the same policy at the same time. See Understanding Locking.
You can modify any local policy assigned to a particular device provided you have permissions to modify policies and to access that device. For more information about permissions, see the Installation Guide for Cisco Security Manager.
After configuring a policy, you must deploy the changes to the device in order to make them active on that device. For more information, see Chapter 17, "Managing Deployment"
Related Topics
•Understanding the Device View, page 5-1
•Managing Policies in Device View
•Copying Policies Between Devices
•Working with Shared Policies in Device View
Step 1 In Device view, select a device from the Device selector, then select a policy for that device from the Device Policies selector. The details of the policy appear in the work area.
Step 2 Modify the definition of the policy as required. Click the Help button to access information specific to the selected policy. For more information, see:
•Chapter 9, "Managing Site-to-Site VPNs"
•Chapter 10, "Managing Remote Access VPNs"
•Chapter 11, "Managing Firewall Services"
•Chapter 12, "Managing IPS Services"
•Chapter 13, "Managing Routers"
•Chapter 14, "Managing Firewall Devices"
•Chapter 15, "Managing Cisco Catalyst Switches and Cisco 7600 Series Routers"
•Chapter 16, "Managing IPS Devices"
Step 3 Click Save to save your changes.
If this is the first time you are configuring this policy on this particular device, the icon next to the selected policy changes to indicate that the policy is configured and assigned locally to the device. For more information about policy status icons, see Policy Status Icons.
After you save the policy, the policy is configured but you are the only one who can view the changes. There are additional steps to take to commit your changes and to deploy them to the device. The exact changes depend on whether you are working in Workflow or non-Workflow mode. Before taking the additional steps, configure all of the policies that you want to deploy; you are not required to deploy policy changes one at a time.
Following is a summary of the additional steps you need to take:
•Submit your changes. Submission updates the database on the Security Manager server with your changes.
–In non-Workflow mode, you submit changes by selecting File > Submit. You can also submit your changes and deploy them in a single step by selecting File > Submit and Deploy.
–In Workflow mode, if you are working with an activity approver, you submit your activity, and the changes are committed when the activity is approved. If you are not working with an activity approver, your changes are committed when you approve your own activity. For more information, see Submitting an Activity for Approval, page 7-12 and Approving or Rejecting an Activity, page 7-13.
•Deploy your changes. Deployment either updates the devices directly with the new configuration, creates configuration files that you can deploy yourself, or copies the configuration files to an intermediate server (Auto Update Server, Configuration Engine, or Token Management Server) from which the device retrieves the updates. The method you use depends on the requirements of your organization, and you can select different methods for each device. For general information about deployment, see Working with Deployment and the Configuration Archive, page 17-15. For the specific steps based on workflow mode, and information on the deployment methods, see the following topics:
–Deploying Configurations in Non-Workflow Mode, page 17-17
–Deploying Configurations in Workflow Mode, page 17-19
–Deploying Configurations Using an Auto Update Server or CNS Configuration Engine, page 17-25
–Deploying Configurations to a Token Management Server, page 17-26
–Deploying Directly to a Device, page 17-10
–Deploying to a Device through an Intermediate Server, page 17-11
–Deploying to a File, page 17-12
Security Manager enables you to streamline device configuration by copying multiple policies, or even a complete set of policies, from one device to other devices that support the selected policies. This makes it easy, for example, to quickly configure a new firewall device with the same policies configured on an existing firewall device.
When you copy policies between devices, those policies that are local on the source device are copied locally to the target device. Shared policies assigned to the source device are copied as shared policies to the target device as well.
Tips
•If your intention is to assign a single shared policy to additional devices, we recommend that you use the assignment feature, rather than copying the policies. For more information about sharing policies in Device view, see Modifying Shared Policy Assignments in Device View.
•To create a new device of the same type that shares the same configuration and properties (including the operating system version, credentials, and grouping attributes) as the source device, use the Clone Device feature. For more information, see Cloning a Device, page 5-24.
Related Topics
•Managing Policies in Device View
•Configuring Local Policies in Device View
•Understanding the Device View, page 5-1
•Chapter 8, "Managing Policy Objects"
Step 1 In Device view, do one of the following:
•Select Policy > Copy Policies Between Devices. The Copy Policies wizard starts at step 1, the Copy Policies from this Device page (see Copy Policies Wizard—Copy Policies from this Device Page, page D-4). Select the device that has the policies you want to copy and click Next.
•Right-click a device in the Device selector, then select Copy Policies Between Devices. The Copy Policies wizard selects the device as the source device and starts at step 2, the Select Policies to Copy page (see Copy Policies Wizard—Select Policies to Copy Page, page D-4). You can change the source device by clicking Back.
Tip You can also right click a device in Map view and select Copy Policies Between Devices.
Step 2 Select the policies you want to copy. By default, most policies from the source device (both local and shared) that can be copied are selected. You can change the selection, however, if you select a policy that depends on another policy, you must select the dependant policies. Security Manager will prompt you if your selections are not valid.
Consider the following when selecting policies:
•When you copy policies between firewall devices, copying the failover policy automatically copies the interface policy and vice-versa.
•It is usually not a good idea to copy interface policies, because these policies can have specific IP addresses.
•If you select the security contexts policy (for FWSM, PIX Firewall, or ASA devices), you must submit your changes after copying the devices for the contexts to appear in the device selector. In non-Workflow mode, select File > Submit. In Workflow mode, submit your activity.
Step 3 Use the policy object copy options to determine how policy objects are handled. These options are not mutually exclusive, and the combination you select has important implications on how the policies are defined on the target devices.
•To ensure that the target devices have the same policy object settings as the source device, select both Copy the Global Values of Policy Objects and Copy the Overridden Values of Policy Objects.
•To ensure that if a policy object is used on the target device, its value is not overridden, select neither option.
•To ensure that any policy objects on the target device use the policy object's global values, select Copy the Global Values of Policy Objects but deselect Copy the Overridden Values of Policy Objects.
•To ensure that only policy objects with local values on the source device are copied to the target device, deselect Copy the Global Values of Policy Objects but select Copy the Overridden Values of Policy Objects.
Click Next.
Step 4 Select the target devices to which you want to copy policies on the Copy Policies to these Devices page (see Copy Policies Wizard—Copy Policies to these Devices Page, page D-6). This page displays only those devices that can support every policy you selected to copy.
Step 5 Click Finish. You are asked to confirm that you want to copy policies.
The policies are copied to the target devices. If the copy operation fails for any target device, the copy is undone for successful devices, and you are shown a list of reasons why the copy failed for each problem device. Typically, copy failures are because someone else has a lock on a policy or device, or you do not have the required permissions to a device.
If you unassign a policy that has already been deployed to a device, in most cases the values that are defined for the policy are erased, effectively removing the policy from the device's planned configuration. When you perform deployment, the configuration for this feature that already exists on the device is removed.
The exact behavior depends on the type of policy that you unassign:
•Firewall service policies—If you unassign a policy, Security Manager erases the policy from the device.
•VPN policies:
–Site-to-site VPN policies—You cannot unassign mandatory site-to-site VPN policies from the devices in the topology. If you unshare a mandatory policy, Security Manager assigns default values to the affected device. If you unassign an optional policy, Security Manager erases the configuration from the device. For more information, see Understanding IPsec Technologies and Policies, page 9-5.
–IPSec remote access VPN policies—If you unassign a policy, Security Manager erases the policy from the device, even if it is a mandatory policy. In most cases, deployment fails if you do not create a new definition for the mandatory policy. In those cases where deployment does not fail, the device will fail to establish VPN tunnels.
–SSL VPN policies—If you unassign a policy, Security Manager erases the policy from the device.
•Catalyst 6500/7600 or Catalyst switch policies—Interface and VLAN policies cannot be shared or unassigned. If you unassign a platform policy (such as IDSM settings or VLAN access lists) Security Manager removes the policy from the device.
•IPS policies—For all IPS device and service policies, a default policy is assigned to the device.
•PIX/ASA/FWSM policies—Policies that you cannot share with other devices cannot be unassigned from the device on which they are created. This includes interface, failover, security context, and resource policies. For other policy types (such as timeout policies), Security Manager makes a best effort to restore the system default configuration on the device.
•IOS router policies—Core connectivity policies, such as basic interface settings and accounts and credentials policies cannot be unassigned from the device on which they are created. If you unassign a device access policy that was used to define the password for configuring the device, you might prevent Security Manager from configuring that device in the future. For more information, see User Accounts and Device Credentials on Cisco IOS Routers, page 13-48.
If you unassign a VTY or console policy, Security Manager restores a default configuration to ensure continued communication with the device. For all other policy types, if you unassign the policy, Security Manager erases the configuration from the device.
Related Topics
•Configuring Local Policies in Device View
•Copying Policies Between Devices
•Managing Policies in Device View
Step 1 Select a device from the Device selector.
Step 2 Right-click a local policy assigned to the device from the Device Policies selector, then select Unassign Policy.
You are asked to confirm that you wan to unassign the current policy.
Sharing policies makes it possible to configure multiple devices with common policies, which provides greater consistency in your policy definitions and streamlines your management efforts. Any changes to a shared policy affect all the devices and VPN topologies to which the policy is assigned. This makes it easy, for example, to update all of your Cisco IOS routers with new quality of service policies by updating the shared Quality of Service policy assigned to these devices.
When working in Device view, you can take a local policy (such as a policy created during device discovery) and share it. You can then assign the shared policy to as many devices as you want (provided they are not locked by another user; see Understanding Locking), and you can change these assignments at any time.
In addition, you can take a shared policy that is assigned to a device and turn it into a local policy for that particular device. This enables you to create a special configuration that affects only that device. Other devices assigned the shared policy continue to use the shared policy as before.
As an alternative to sharing local policies, you can create new shared policies and manage them at the network level using Policy view. For more information, see Managing Shared Policies in Policy View. After creating the shared policy and assigning it to devices in Policy view, you can return to Device view and perform additional operations on the policy as described in the sections that follow.
The following topics describe how to share policies and the operations that can be performed on them in Device view:
•Sharing Multiple Policies of a Selected Device
•Assigning a Shared Policy to a Selected Device
•Adding Local Rules to a Shared Policy
•Modifying Shared Policy Definitions in Device View
•Modifying Shared Policy Assignments in Device View
Related Topics
•Managing Policies in Device View
When you view a device policy in Device view, or a site-to-site VPN policy in the Site-to-Site VPN Manager, there is a banner above the content of the policy in the work area. The banner provides information about whether the policy is local to the device or a shared policy. For shared policies, the banner also indicates the number of devices that use the policy. For policies that allow inheritance, the banner includes information about inheritance. If a policy is locked by another user, this information is displayed in the banner area.
You can use the links in the banner to create shared policies, assign a shared policy, and configure policy inheritance. Figure 6-3 shows an example of a device policy banner.
Figure 6-3 Policy Banner Example
The fields in the policy banner have the following meanings and uses:
•Policy Assigned—The name of the policy assigned to this device or VPN. If the name has a link, you can assign a shared policy to the element by clicking the link. If there is no link, a shared policy cannot be assigned to this particular type of policy.
–Local—The policy is a local policy rather than a shared policy.
–Specific policy name—The shared policy is assigned to the policy.
•Assigned To—If a shared policy is assigned, the number of devices or VPNs to which the policy is assigned. If no shared policy is assigned, local device or this VPN is indicated. If the name has a link, you can do the following:
–Local Device or This VPN links—Click the link to create a shared policy from this local policy. You can then assign the shared policy to other devices or VPNs.
–Number of Devices or VPNs links—Click the link to change the devices or VPNs assigned to the shared policy.
•Inherits From—The name of the policy from which this policy inherits rules. This field appears only for policies that allow inheritance. Click the link to specify a policy or set of policies from which the policy will inherit rules. For more information about inheritance, see Understanding Rule Inheritance.
The field can contain these entries:
–None—The policy does not inherit rules from any other policy.
–Single policy name—The policy inherits rules from this policy.
–Multiple policy names separated by > signs—The policy inherits rules from the indicated hierarchy of policies.
Related Topics
•Managing Policies in Device View
•Assigning a Shared Policy to a Selected Device
•Adding Local Rules to a Shared Policy
•Modifying Shared Policy Definitions in Device View
•Modifying Shared Policy Assignments in Device View
As your network grows, you might decide to convert a local policy into a shared policy that you can assign to multiple devices. Sharing a policy provides a streamlined management approach that ensures that all devices assigned to the policy are configured in a consistent manner. For example, if you configure a set of firewall inspection rules on a particular device, sharing that device's inspection rules policy makes it possible to assign that policy to other devices, eliminating the need to configure each device individually. See Assigning a Shared Policy to a Selected Device.
In addition, having a shared policy enables you to update the configurations of each assigned device at one time, saving time and promoting greater consistency across your set of managed devices.
When you share a policy, you must name the policy. (Local policies do not have names, because they are associated with only a single device.) This enables you to identify this policy when managing shared policies in Policy view.
Related Topics
•Understanding the Device View, page 5-1
•Assigning a Shared Policy to a Selected Device
•Adding Local Rules to a Shared Policy
•Sharing Multiple Policies of a Selected Device
•Working with Shared Policies in Device View
Step 1 In Device view, select a device from the Device selector, then select a local policy for that device from the Device Policies selector. The details of the policy appear in the work area.
Step 2 Do one of the following:
•Select Policy > Share Policy.
•Right-click the local policy, then select Share Policy.
•Click the local device link in the Assigned To field in the policy banner, then click Share Policy in the message dialog box that is opened.
The Share Policy dialog box is displayed.
Step 3 Enter a name for the shared policy. Policy names can contain up to 255 characters, including spaces and special characters.
Step 4 Click OK to save the policy as a shared policy.
In the Device Policies selector, the icon next to the selected policy type changes to show that the policy is now a shared policy. For more information about policy status icons, see Policy Status Icons.
With one procedure, you can share multiple policies configured on a particular device. When you perform this procedure, you can choose to share all the policies configured on the device or only some of them. For example, you can take all the firewall service policies defined on an ASA device and share them.
Initially, the resulting shared policies are assigned only to the device from which the procedure was performed. You can then however, assign these shared policies to additional devices, as required. See Modifying Shared Policy Assignments in Device View.
This feature provides a convenient way to take the policies configured on a single device and use them as a template for configuring similar devices. For example, after you discover the devices at your branch offices, you can take all the local access rules that you have configured on a similar device and share them with a single procedure so that you can assign them to the branch office devices.
Tip To create a new device of the same type that shares the same configuration and properties (including device operating system version, credentials, and grouping attributes) as the source device, create a clone of the device. For more information, see Cloning a Device, page 5-24.
Related Topics
•Understanding the Device View, page 5-1
•Copying Policies Between Devices
•Working with Shared Policies in Device View
Step 1 (Optional) In Device view, select a device from the Device selector.
Step 2 Do one of the following:
•Select Policy > Share Device Policies.
•Right-click the device and select Share Device Policies.
Tip You can also right click a device in Map view and select Share Device Policies.
If you did not select a device, the Select Policies from this Device page of the Share Policies wizard is displayed (see Share Policies Wizard—Share Policies from this Device Page, page D-7). If you selected a device, you go automatically to the second page of the wizard. You can click Back to return to the first page to select a different device.
Step 3 If necessary, select the device from the tree whose policies you want to share, then click Next.
The Select Policies to Share page of the Share Policies wizard is displayed (see Share Policies Wizard—Select Policies to Share Page, page D-7).
Step 4 Select the policies you want to share. By default, all policies configured on the device (local and shared) are selected for sharing. Deselect the check box next to each policy that you do not want to share. For example, local policies that are not checked remain local to the selected device.
Step 5 Enter a name for the shared policies. This name will be used by all the policies you are sharing.
If you select a policy that is already shared, Security Manager creates a copy of that policy using this name.
Step 6 Click Finish. The selected policies become shared policies, which you can then assign to additional devices as needed. For more information, see Modifying Shared Policy Assignments in Device View.
When you unshare a shared policy assigned to a particular device, you create a copy that becomes a local policy for that device. This means that any subsequent changes made to the local policy affect only this particular device. Other devices assigned the original shared policy continue to use the shared policy as before.
For example, Security Manager might be managing a BGP routing policy called MyBGP, which is assigned to 20 routers. If you decide that one of the routers (Router1) requires a variation of this policy, you can select the device, unshare the policy, and make the changes you need for that router. From that point on, Router1 has a local BGP policy while the other 19 routers continue to use the original shared policy, MyBGP.
Related Topics
•Understanding the Device View, page 5-1
•Managing Policies in Device View
•Working with Shared Policies in Device View
Step 1 In Device view, select a device from the Device selector, then select a shared policy for that device (as shown by the shared policy icon) from the Device Policies selector. The details of the policy appear in the work area. For more information about policy status icons, see Policy Status Icons.
Step 2 Do one of the following:
•Select Policy > Unshare Policy.
•Right-click the selected shared policy, then select Unshare Policy.
Step 3 Click OK. The shared policy is converted into a local policy for the selected device. The shared policy icon in the Device Policies selector is replaced by the local policy icon.
You can replace any policy (local or shared) assigned in Device view with a shared policy of the same type. For example, if you have a local NAT policy assigned to a Cisco IOS router, you can assign a shared NAT policy in its place. Similarly, if a shared NAT policy was assigned to the router, you can replace it with a different shared NAT policy.
If you are assigning a shared policy to replace a local, rule-based policy (for example, an inspection rules policy), any local rules that you configured are replaced by the rules defined in the shared policy. A warning message gives you the opportunity to preserve the local rules by inheriting the rules of the shared policy instead of assigning the shared policy in place of the local policy. For more information, see Inheritance vs. Assignment.
Tip If you want to use the rules defined in the shared policy and still keep your local rules, we recommend that you select the Inherit Rules option instead of assigning the policy. For more information, see Inheriting Rules.
Related Topics
•Understanding the Device View, page 5-1
•Adding Local Rules to a Shared Policy
•Copying Policies Between Devices
•Working with Shared Policies in Device View
Step 1 In Device view, select a device from the Device selector, then select a policy for that device from the Device Policies selector. The details of the policy appear in the work area.
Step 2 Do one of the following:
•Select Policy > Assign Shared Policy.
•Right-click the policy, then select Policy > Assign Shared Policy.
•Click the local device link in the Policy Assigned field in the policy banner.
The current policy is unassigned from the device and the Assign Shared Policy dialog box is displayed (see Assign Shared Policy Dialog Box, page D-2).
Step 3 Select a shared policy from the displayed list to assign to the device and click OK. The shared policy is assigned to the selected device.
Tip If you are assigning a rule-based policy in place of a local policy, a message is displayed warning that the shared policy will replace the local policy. If you want to preserve the local rules, select the option to inherit the rules of the selected policy instead of the assignment option.
After you assign a shared rule-based policy, such as access rules, to a device, you can define additional rules in the policy that are local to that device. Selecting this option creates an inheritance relationship, where the policy defined on the device inherits rules from the shared policy while adding rules that affect only this particular device. For more information about inheritance, see Understanding Rule Inheritance.
Local rules that you add to a device do not affect the shared policy from which the device inherits its remaining rules. For example, if the shared policy Access_Rules_South is assigned to five devices and you define local rules on one of those devices, the access rules policy on that device consists of the rules defined in Access_Rules_South plus the local rules; the other four devices continue to use only the rules defined Access_Rules_South.
Before You Begin
Assign a shared, rule-based policy to the device as described in Assigning a Shared Policy to a Selected Device.
Related Topics
•Understanding the Device View, page 5-1
•Assigning a Shared Policy to a Selected Device
•Working with Shared Policies in Device View
Step 1 In Device view, select a device from the Device selector, then select a shared policy assigned to that device from the Device Policies selector. You must select a rule-based policy, such as access rules. The details of the policy appear in the work area.
Step 2 Do one of the following:
•Select Policy > Add Local Rules.
•Right-click the policy, then select Add Local Rules.
A message is displayed indicating that the policy on this device is now defined as a child policy that inherits rules from the shared policy. If the shared policy in turn inherits rules from a different shared policy, those rules are automatically inherited as well.
Note To change the parent policy from which this policy inherits rules, see Inheriting Rules.
Step 3 Click OK to confirm. In the work area, headings are added for local mandatory and default rules in addition to the mandatory and default rules inherited from the shared policy.
In the Device Policies selector, the status icon changes to the icon for a local policy. For more information, see Policy Status Icons.
Step 4 Define local rules as required.
Tip If you assign a shared policy after adding local rules, both the inherited rules and your local rules are replaced with the selected shared policy.
This procedure describes how certain types of rule-based policies, such as access rules, can inherit rules from shared policies of the same type. Child policies inherit both the mandatory rules and default rules that are defined in the parent policy.
When working in Device view, you can then define additional rules that are local to the selected device. For more information, see Adding Local Rules to a Shared Policy.
You can edit rule inheritance from either Device view or Policy view.
Related Topics
•Understanding the Device View, page 5-1
•Managing Shared Policies in Policy View
•Understanding Rule Inheritance
Step 1 Do one of the following:
•From Device view, select a device from the Device selector, then select a rule-based policy from the Device Policies selector.
•From Policy view, select a rule-based policy type from the Policy Type selector, then select a policy from the Shared Policy selector.
Step 2 Do one of the following:
•Select Policy > Inherit Rules.
•Right-click the policy, then select Inherit Rules.
•Click the link in the Inherits From field in the policy banner.
The Inherit Rules dialog box is displayed, containing a list of all shared policies of the selected type, including any inheritance relationships among them. (See Inherit Rules Dialog Box, page D-10.)
Step 3 Select the policy from which to inherit rules, or select No Inheritance to remove any inheritance from the child policy. The name of the parent policy is displayed below the selector.
For example, if you select an access rules policy called West Coast, your access policy inherits the rules of the West Coast policy. If the West Coast policy is a child policy of another access rules policy called US, your policy inherits the properties of the West Coast policy, which in turn inherits the properties of the US policy.
Step 4 Click OK to save your definitions. The work area displays the inherited rules under the name of the parent policy and any local rules, if defined, under the name of the original shared policy.
You can save an existing shared policy under a new name. This provides a useful shortcut for creating a new policy that contains the same definitions as an existing one. You can then change the policy definition as required.
If you save a rule-based policy with inheritance under a new name, the new policy contains the same inheritance properties as the policy from which it was created. For more information, see Understanding Rule Inheritance.
Related Topics
•Understanding the Device View, page 5-1
•Managing Shared Policies in Policy View
Step 1 In Device view, select a device from the Device selector, then select a shared policy assigned to that device from the Device Policies selector. The details of the policy appear in the work area.
Step 2 Do one of the following:
•Select Policy > Save Policy As.
•Right-click the policy, then select Save Policy As.
The Save Policy As dialog box is displayed.
Note You can also rename a policy from Policy view by selecting a policy type from the Policy Type selector, then right-clicking a policy in the Shared Policy selector.
Step 3 Enter a name for the new policy and click OK.
The new policy is saved and appears in the selector next to the policy from which it was created. You can then modify the definition of the policy as required.
You can rename a shared policy. The new name is immediately reflected in all devices and VPN topologies to which the policy is assigned.
Related Topics
•Understanding the Device View, page 5-1
•Managing Shared Policies in Policy View
Step 1 In Device view, select a device from the Device selector, then select a shared policy assigned to that device from the Device Policies selector. The details of the policy appear in the work area.
Step 2 Do one of the following:
•Select Policy > Rename Policy.
•Right-click the policy, then select Rename Policy.
The Rename Policy dialog box is displayed.
Note You can also rename a policy from Policy view by selecting a policy type from the Policy Type selector, then right-clicking a policy in the Shared Policy selector.
Step 3 Enter a new name for the selected policy and click OK.
You can modify any shared policy in Device view by selecting one of the devices to which the policy is assigned, making the necessary changes, and then saving these changes to the Security Manager server. By default, any changes made to a shared policy in Device view automatically affect all devices to which the shared policy is assigned.
Tip To apply your changes only to the device that you are modifying, you must first unshare the policy (see Unsharing a Policy). This action converts the policy to a local policy and prevents your changes from affecting other devices in the network.
Related Topics
•Understanding the Device View, page 5-1
•Modifying Shared Policy Assignments in Device View
•Configuring Local Policies in Device View
•Managing Policies in Device View
Step 1 In Device view, select a device from the Device selector, then select a shared policy for that device from the Device Policies selector. The details of the policy appear in the work area.
Step 2 Redefine the policy as required.
Step 3 Click Save. You are asked to confirm that you want to save your changes, reminding you that the changes you made will be applied to all devices to which the policy is assigned.
You can modify the list of devices assigned a particular shared policy as required. If you remove a device from a policy assignment, that policy is effectively removed from the device's planned configuration. Upon deployment, any configuration of that type that exists on the device is removed. For more information, see Unassigning a Policy.
Policy assignment can also be modified from Policy view. For more information, see Modifying Policy Assignments in Policy View.
Related Topics
•Understanding the Device View, page 5-1
•Modifying Shared Policy Definitions in Device View
•Copying Policies Between Devices
•Working with Shared Policies in Device View
Step 1 In Device view, select a device from the Device selector, then select a shared policy for that device from the Device Policies selector. The details of the policy appear in the work area.
Step 2 Do one of the following:
•Select Policy > Edit Policy Assignments.
•Right-click the policy, then select Edit Policy Assignments.
•Click the n device link in the Assigned To field in the policy banner.
Step 3 Modify the list of devices to which the policy is assigned, as follows:
•To assign the selected policy to additional devices, select one or more devices from the Available Devices list, then click >> to move them to the Assigned Devices list.
•To unassign the selected policy from devices, select one or more devices from the Assigned Devices list, then click << to return them to the Available Devices list. Devices that are unassigned from the policy remove this policy from their running configuration during deployment.
Tip To assign a policy to all the devices in a device group, select the name of the device group, then click >>.
Step 4 Click OK to save your assignment changes.
Use Policy view to globally manage all the shared policies configured in Security Manager. Unlike Device view, which you use to manage all the policies configured on a selected device, Policy view enables you to manage all shared policies of a particular type regardless of device.
Policy view enables you to:
•Create new shared policies.
•Edit any policy configuration.
•Modify the list of devices or VPNs to which shared policies are assigned.
•Delete shared policies that are not assigned to any devices or VPNs.
To access Policy view, select View > Policy View or click the Policy View button on the toolbar.
Figure 6-4 shows the main areas of Policy view.
Figure 6-4 Policy View
1 |
Assignments tab |
5 |
Shared Policy selector |
2 |
Work area |
6 |
Shared Policy filter |
3 |
Save button |
7 |
Policy Type selector |
4 |
Create a Policy and Delete a Policy buttons |
•(7) Policy Type Selector—Lists the policy types available in Security Manager, divided by category. Clicking a policy type in the selector displays all the shared policies defined for that type in the Shared Policy selector. To create a new policy, right click the policy type and select New [policy type] Policy or click the Create a Policy button in the shared policy selector. For more information, see Policy View Selectors.
•(4, 5, 6) Shared Policy Selector—Lists the shared policies that are defined for the selected type. Clicking a policy in the selector displays the definition of that policy on the Details tab of the work area. You can modify the definition as required; click Save in the work area to save your changes. Changes affect all devices or VPN topologies to which the policy is assigned. For more information, see Policy View Selectors.
Right-click a policy in the selector to perform actions on the policy. For more information on the available commands, see Policy View—Shared Policy Selector Options, page D-16.
Use the Filter field to filter the list of policies displayed in the selector. For more information about creating filters, see Filtering Items in Selectors, page 2-14.
The list of devices or VPN topologies to which the policy is assigned is displayed on the Assignments tab. For more information, see Policy View—Assignments Tab, page D-17.
•(1, 2, 3) Work Area—Contains two tabs:
–Details—Use this tab to view and edit the definition of the selected policy. Any changes you make to a policy affect every device or VPN to which the policy is assigned. See Policy View Selectors.
–Assignments—Use this tab to view and edit the list of devices or VPNs to which a shared policy is assigned. See Policy View—Assignments Tab, page D-17.
Related Topics
•Managing Policies in Device View
•Working with Shared Policies in Device View
Policy view contains two selectors. The upper selector displays all the policy types available for a selected policy domain. The root of the policy type selector is the policy domain name. To display the policy types for a different policy domain, click the root of the tree and select a different domain from the list.
Policy domains include:
•Firewall—Lists all policy types for configuring firewall services. See Chapter 11, "Managing Firewall Services".
•NAT (PIX/ASA/FWSM)—Lists all NAT policies configured on PIX, ASA, and FWSM devices. See Configuring NAT Policies on Firewall Devices, page 14-17.
•NAT (Router)—Lists all NAT policies configured on Cisco IOS routers. See NAT on Cisco IOS Routers, page 13-4.
•Site-to-Site VPN—Lists all policy types for configuring site-to-site VPNs. See Chapter 9, "Managing Site-to-Site VPNs".
•Remote Access VPN—Lists all policy types for configuring remote-access IPsec and SSL VPNs. See Chapter 10, "Managing Remote Access VPNs".
•Catalyst Platform—Lists all policy types for configuring Catalyst switches and 7600 routers. See Chapter 15, "Managing Cisco Catalyst Switches and Cisco 7600 Series Routers".
•IPS—Lists all policy types for configuring IPS devices. See Chapter 12, "Managing IPS Services" and Chapter 16, "Managing IPS Devices".
•IPS (Router)—Lists all policy types for configuring IPS policies on IOS routers. See Chapter 12, "Managing IPS Services" and Chapter 16, "Managing IPS Devices".
•PIX/ASA/FWSM Platform—Lists all policy types for configuring PIX/ASA/FWSM platform-specific policies. See Chapter 14, "Managing Firewall Devices".
•Router Interfaces—Lists all policy types for configuring platform-specific Cisco IOS router interface policies. See Chapter 13, "Managing Routers".
•Router Platform—Lists all policy types for configuring platform-specific Cisco IOS router policies. See Chapter 13, "Managing Routers".
•FlexConfigs—Lists all FlexConfig policies. See Chapter 18, "Managing FlexConfigs".
You can expand and collapse the selector as required to view all the available policy types and subtypes. To create a new policy, right click the policy type and select New [policy type] Policy or click the Create a Policy button in the shared policy selector.
Selecting a policy type from the Policy Type selector displays all the shared policies of that type in the Shared Policy selector. Local policies configured in Device view are not displayed.
For example, when you select a configuration policy type, such as NAT translation rules, the Shared Policy selector displays a flat list of each shared policy of that type. If you select a rule-based policy type, such as firewall access rules, the Shared Policy selector displays a hierarchical tree of shared policies. This enables you to view the inheritance relationships among the various policies. The Shared Policy selector includes a shortcut menu with options for actions that can be performed on that policy, such as renaming it.
Tip You can create and apply a filter to shorten the list of policies displayed in the Shared Policy selector. For more information about filters, see Filtering Items in Selectors, page 2-14.
Related Topics
•Managing Shared Policies in Policy View
The work area in Policy view contains the following tabs:
•Details—Contains the definition of the selected policy. The information displayed on the Details tab is identical to the information displayed in Device view and can be modified in exactly the same way. For more information about configuring policies, see:
–Chapter 9, "Managing Site-to-Site VPNs"
–Chapter 10, "Managing Remote Access VPNs"
–Chapter 11, "Managing Firewall Services"
–Chapter 12, "Managing IPS Services"
–Chapter 13, "Managing Routers"
–Chapter 14, "Managing Firewall Devices"
–Chapter 15, "Managing Cisco Catalyst Switches and Cisco 7600 Series Routers"
–Chapter 16, "Managing IPS Devices"
•Assignments—Contains the device assignments for the selected policy, enabling you to add and remove devices as required. For more information, see Modifying Policy Assignments in Policy View and Policy View—Assignments Tab, page D-17.
Related Topics
•Managing Shared Policies in Policy View
Use Policy view to create a new shared policy. In most cases, the new policy starts out undefined, but in certain cases (for example, many site-to-site VPN policies, such as IPsec proposals and GRE modes) default values are supplied. In all cases, the new policy is not initially assigned to any devices. If the new policy is a rule-based policy that supports inheritance, it can be created as a child of an existing shared policy of the same type. For more information, see Understanding Rule Inheritance.
Tip You can also create shared policies by converting local policies in Device view. For more information, see Sharing a Local Policy.
Related Topics
•Managing Shared Policies in Policy View
Step 1 In Policy view, select a policy type in the Policy Type selector.
Step 2 Do one of the following:
•Right-click the policy type in the Policy Type selector, then select New [policy type] Policy.
•Right-click a policy in the Shared Policy selector, then select New [policy type] Policy.
•Click the Create a Policy button beneath the Shared Policy selector.
The Create a Policy dialog box is displayed.
Step 3 Enter a name for the new policy. Policy names can contain up to 255 characters, including spaces and special characters.
Step 4 Click OK. The new policy appears in the Shared Policy selector.
To configure a definition for the new shared policy, click the Help button in the toolbar with the Details tab open to see information specific to the type of policy you are creating. To assign the new shared policy, see Modifying Policy Assignments in Policy View.
Use the Assignments tab in Policy view to modify the list of devices or VPN topologies to which you assigned a selected shared policy. Assigning a policy to a device or VPN overwrites any policy of the same type (local or shared) that was previously assigned to the device in Security Manager. When deployed, the newly assigned policy overrides any policy of the same type that is already configured on the device, whether it was configured using Security Manager or using another method, such as the CLI.
When you unassign a shared policy from a device or VPN topology, Security Manager removes the policy from the planned configuration of that device or VPN topology. When the configuration defined by the policy is deployed, any configuration of the same type that is already configured on the device (including the devices in the VPN topology) is removed. For more information, see Unassigning a Policy.
Therefore, if your intention when performing unassign is to assign a different shared policy to a particular device or VPN topology, it is important to select the replacement policy and perform the assignment before performing deployment.
Tip Assigning a replacement policy is particularly important when you use a device access policy to configure the enable password or enable secret password on a Cisco IOS router. If you unassign this policy and fail to define a different password in its place before deployment, Security Manager might be unable to configure this device in the future. For more information, see User Accounts and Device Credentials on Cisco IOS Routers, page 13-48.
Alternatively, you can return to Device view and replace the shared policy assigned to the device with a different shared policy. For more information, see Assigning a Shared Policy to a Selected Device.
Note If you unassign a mandatory site-to-site VPN policy, such as an IKE proposal policy, Security Manager automatically replaces it with a default policy. If you unassign a mandatory remote access VPN policy, you must manually configure a new policy of that same type or deployment will fail.
Related Topics
•Modifying Shared Policy Assignments in Device View
•Managing Shared Policies in Policy View
Step 1 In Policy view, select a policy type from the Policy Type selector, then select a policy from the Shared Policy selector. For more information about using these selectors, see Policy View Selectors.
Step 2 Click the Assignments tab in the work area (see Policy View—Assignments Tab, page D-17).
Step 3 Modify the list of devices or VPNs to which the policy is assigned, as follows:
•To assign the selected policy to additional devices or VPNs, select one or more items from the Available Devices/VPNs list, then click >> to move them to the Assigned Devices/VPNs list.
Tip To assign a policy to all the devices in a device group, select the name of the device group, then click >>.
•To unassign the selected policy from devices or VPNs, select one or more items from the Assigned Devices/VPNs list, then click << to return them to the Available Devices/VPNs list.
Step 4 Click Save to save your assignment changes.
Use Policy view to delete a shared policy from Security Manager.
Before you delete a shared policy, you should unassign it from any devices that use it, and configure replacement policies for those devices. If a shared policy is assigned to a device, when the policy is deleted the device no longer has a policy configured for the deleted shared policy, other than whatever defaults might exist for the policy type. For more information about removing assignments, see Modifying Policy Assignments in Policy View.
Related Topics
•Managing Shared Policies in Policy View
Step 1 In Policy view, select a policy type from the Policy Type selector, then select the policy to delete from the Shared Policy selector. For more information about using these selectors, see Policy View Selectors.
Step 2 Do one of the following:
•Right-click the policy, then select Delete Policy.
•Click the Delete a Policy button beneath the Shared Policy selector.
You are asked to confirm the deletion.