Feedback
Table Of Contents
Settings-Based Policies vs. Rule-Based Policies
Service Policies vs. Platform-Specific Policies
Local Policies vs. Shared Policies
Discovering Policies on Devices Already in Security Manager
Viewing Policy Discovery Task Status
Frequently Asked Questions about Policy Discovery
Managing Policies in Device View
Performing Basic Policy Management
Configuring Local Policies in Device View
Copying Policies Between Devices
Working with Shared Policies 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
Managing Shared Policies in Policy View
Filtering the Shared Policy Selector
Modifying Policy Assignments in Policy View
Understanding Rule Inheritance
Managing Policies
The following topics describe the concept of policies in Cisco Security Manager and how to use and manage them.
•
Managing Policies in Device View
•
•
Understanding Policies
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, and security contexts) 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
Security Manager policies are structured as either rule-based policies or settings-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, 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.
When you define certain types of rule-based policies, such as firewall policies, you can create a policy hierarchy in which policies located at lower levels in the hierarchy acquire properties from the policies 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 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
Service Policies vs. Platform-Specific Policies
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:
•
•
•
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 Defining Policy Management Settings, page 2-63.
Related Topics
Local Policies vs. Shared Policies
All policies that you configure on a device or VPN topology can be local or shared. Local policies are particular to the device or VPN on which they are configured. Any changes you make to these policies affect only this device or VPN. 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 BGP routing policy than the one used by the other routers in your network.
As your network grows, having local policies on each device greatly complicates the task of properly managing these policies in a comprehensive and efficient manner. To meet this challenge, Security Manager features policy sharing. Sharing a policy makes it possible for you to assign the configuration defined by the policy to multiple devices or VPN topologies. Any changes to a shared policy affect the configuration of each device or VPN topology to which it is assigned.
For example, if you want all the Cisco IOS routers in your network to implement the same Network Admission Control policy, you need to define the shared policy only once. You can then assign the shared policy to all routers with a single action. Any updates you make to the shared policy are immediately reflected in the planned configurations maintained by Security Manager for each device to which the shared policy is assigned. For more information, see Working with Shared Policies in Device View.
Related Topics
Policy Management and Objects
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 the accepts an object as a value. For more information, see Selecting Objects for Policies, page 8-256. You can also create and manage objects system-wide from the Policy Object Manager Window, page C-29.
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 Overriding Global Objects for Individual Devices, page 8-250.
For more information about objects and how to use them when defining policies, see Managing Objects, page 8-1.
Related Topics
Discovering Policies
Policy discovery enables you to bring your existing network configuration into Security Manager to be managed. 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.
Policy discovery can be performed by importing the configuration of a live device or by importing a configuration file. Security Manager supports only device-generated configuration files for discovery. For more information, see Adding Devices from a Configuration File, page 5-44.
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 PIX Object Groups, page 8-264.
Note
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 Security Manager Inventory, page 5-29.
You can also initiate policy discovery for existing devices from Device view. For more information, see Discovering Policies on Devices Already in Security Manager.
After performing policy discovery, you must submit your changes to make the information available to other users. For more information, see Chapter 7, "Managing Activities." If you make any changes to the discovered policies, you must deploy the changes to the device. For more information, see Chapter 15, "Managing Deployment."
Related Topics
•
•
•
Discovering Policies on Devices Already in Security Manager
This procedure describes how to discover policies on devices that were already added to Security Manager.
You might initiate policy discovery on existing devices when:
•
•
•
Caution
For example, if you select the option to discover platform-specific settings, the resulting configuration overwrites any platform-specific policies you configured in Security Manager. This is true even if the discovered configuration does not include the specific platform-specific policy you configured. To take one possible case, discovering platform-specific settings overwrites any routing policies you have configured for the device in Security Manager, even if the configuration you discover does not contain any routing information.
Another result of rediscovery is that any shared policies that were configured on the device are replaced by the local policies that are discovered.
Procedure
Step 1
Step 2
•
•
The Create Discovery Task dialog box is displayed. See Table C-12 on page C-16 for a description of the fields in this dialog box.
Step 3
Step 4
•
•
•
Tip
Step 5
•
•
•
Note
By default, all options relevant to the device type are selected.
Step 6
Note
When the task is complete, a message box is displayed. Click OK to close this message box or click Status Detail to view the Discovery Status window. For more information, see Viewing Policy Discovery Task Status.
Related Topics
•
•
•
Viewing Policy Discovery Task Status
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 C-18.
To view information about previous discovery tasks, open the Policy Discovery Status dialog box. For more information, see Policy Discovery Status Page, page E-2.
Related Topics
•
•
Frequently Asked Questions about Policy Discovery
These questions and answers describe how policy discovery processes your device configurations into Security Manager policies:
•
•
•
•
•
•
•
•
•
•
Q.
A.
Q.
A.
Q.
A.
Q.
A.
Q.
A.
Q.
A.
Q.
A.
Q.
A.
Q.
A.
Q.
A.
Q.
A.
Q.
A.
Q.
A.
Q.
A.
Q.
A.
Q.
A.
Q.
A.
Q.
A.
Managing Policies in Device View
You can use Device view to manage both local policies and shared policies, as described in the following sections:
•
•
To access Device view, select View > Device View or click the Device View button on the toolbar.
Related Topics
•
•
Performing Basic Policy Management
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.
Related Topics
•
•
Configuring Local Policies in Device View
Use Device view to configure local platform and service policies on individual firewall devices and Cisco IOS routers. 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 Setting Up User Permissions, page 2-2.
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 15, "Managing Deployment."
Procedure
Step 1
Note
Step 2
•
•
•
•
•
•
Step 3
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 Table 6-1.
Note
Related Topics
•
•
•
Policy Status Icons
You can learn the status of any policy in Security Manager at a glance by viewing the icon displayed next to the policy name, as shown in Table 6-1.
Related Topics
Copying Policies Between Devices
Security Manager enables you to streamline device configuration by copying multiple policies, or even a complete set of policies, from one device to others of the same type. 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.
Tip
•
Note
Procedure
Step 1
Step 2
•
•
The Copy Policies wizard is displayed.
Step 3
Note
Step 4
Step 5
Note
Step 6
Note
Related Topics
•
•
Unassigning a Policy
If you unassign a policy that has already been deployed to a device, all 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 of this type that already exists on the device is removed.
If you unassign a mandatory policy from a VPN topology (such as the IPSec proposal), Security Manager substitutes a default policy in its place. However, if you unassign an optional policy from a VPN topology, the policy is erased.
Unassigning a policy from a remote access VPN erases the policy, even if it is a mandatory policy. In such cases, deployment will fail unless you create a new definition for the mandatory policy.
Procedure
Step 1
Step 2
Note
A message is displayed, warning that you are about to unassign the current policy.
Step 3
Related Topics
•
•
•
Working with Shared Policies in Device View
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.
Note
The following topics describe how to share policies and the operations that can be performed on them:
•
•
•
•
•
Shared policies can also be created and managed at the network level using Policy view. For more information, see Managing Shared Policies in Policy View.
Related Topics
•
Sharing a Local Policy
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. 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.
Procedure
Step 1
Step 2
•
•
The Share Policy dialog box is displayed. See Table C-1 on page C-2 for a description of the fields in this dialog box.
Step 3
Step 4
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 Table 6-1.
Additionally, a header is added to the work area above the policy definition details. This header contains several important pieces of information: the name of the policy (and its inheritance, if applicable) and the number of devices to which the policy is assigned (including the selected device), as well as user privilege and lock indicators (see Understanding Locking), where applicable. You can use the links contained in the header as follows:
•
•
Related Topics
•
•
•
Sharing Multiple Policies of a Selected Device
With one procedure, you can share multiple local policies configured on a particular device. When you perform this procedure, you can choose to share all the local 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
Note
Procedure
Step 1
Step 2
•
•
The Select Policies from this Device page of the Share Policies wizard is displayed. See Table C-6 on page C-10 for a description of the fields in this page.
Step 3
The Select Policies to Share page of the Share Policies wizard (Table C-7 on page C-11) is displayed. By default, all local policies on the device are selected for sharing.
Note
Step 4
Step 5
Step 6
Related Topics
•
•
Unsharing a Policy
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.
Procedure
Step 1
Note
Step 2
•
•
Step 3
Related Topics
•
•
Assigning a Shared Policy to a Selected Device
You can replace any policy (local or shared) assigned to a selected device 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.
Tip
Procedure
Step 1
Step 2
•
•
The current policy is unassigned from the device and the Assign Shared Policy dialog box is displayed. See Table C-2 on page C-4 for a description of the fields in this dialog box.
Step 3
Note
Step 4
Related Topics
•
•
•
Adding Local Rules to a Shared Policy
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
•
Procedure
Step 1
Step 2
•
•
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
Step 3
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
Note
Related Topics
•
•
Copying a 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.
Procedure
Step 1
Step 2
•
•
The Save Policy As dialog box is displayed. See Table C-9 on page C-13 for a description of the fields in this dialog box.
Note
Step 3
Step 4
Related Topics
•
Renaming a Shared Policy
You can rename a shared policy. The new name is immediately reflected in all devices and VPN topologies to which the policy is assigned.
Procedure
Step 1
Step 2
•
•
The Rename Policy dialog box is displayed. See Table C-10 on page C-14 for a description of the fields in this dialog box.
Note
Step 3
Step 4
Related Topics
•
Modifying Shared Policy Definitions in Device View
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.
Note
Procedure
Step 1
Step 2
Step 3
Tip
Step 4
Related Topics
•
•
•
Modifying Shared Policy Assignments in Device View
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.
Caution
Policy assignment can also be modified from Policy view. For more information, see Modifying Policy Assignments in Policy View.
Procedure
Step 1
Step 2
•
•
Tip
Step 3
•
•
Step 4
Related Topics
•
•
•
Managing Shared Policies in Policy View
Policy view enables you to manage shared policies in Security Manager at the system level. With Policy view you can quickly view all the shared policies that are defined for a particular policy type, edit their definitions, and modify their device assignments. Additionally, you can create a new shared policy for later assignment to devices.
To access Policy view, select View > Policy View or click the Policy View button on the toolbar.
Policy view is divided into the following sections:
•
•
•
Figure 6-1 Policy View
Related Topics
•
•
Policy View Selectors
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. Options are:
•
•
•
•
•
•
•
•
You can expand and collapse the selector as required to view all the available policy types and subtypes. The Policy Type selector also includes a shortcut menu for creating a new shared policy of a selected type.
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
Related Topics
•
Filtering the Shared Policy Selector
You can filter the list of policies displayed in the Shared Policy selector according to the policy name. For example, if you have dozens of access rule policies, you can create and apply a filter so that only those access rule policies having a certain name are displayed in the selector.
Each user can define a maximum of 10 filters for the Shared Policy selector. After that, creating an additional filter replaces the oldest one in the list. In other words, the 11th filter replaces the first filter.
Filters are created and applied from the Filter list displayed above the Shared Policy selector.
Procedure
Step 1
Step 2
a.
b.
c.
For example, if you define the criteria as Name begins with HQ, the filter will include only those shared policies whose names begin with HQ.
d.
Note
e.
Step 3
•
•
Step 4
Step 5
Related Topics
•
Policy View Work Area
The work area in Policy view contains the following tabs:
•
–
–
–
–
–
–
•
Related Topics
•
Creating a New Shared Policy
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
Procedure
Step 1
Step 2
•
•
•
The Create a Policy dialog box is displayed. See Table C-20 on page C-28 for a description of the fields in this dialog box.
Step 3
Step 4
To configure a definition for the new shared policy, see Policy View Work Area. To assign the new shared policy, see Modifying Policy Assignments in Policy View.
Related Topics
•
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.
Note
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
Procedure
Step 1
Step 2
Step 3
•
•
Step 4
Related Topics
•
•
Deleting a Shared Policy
Use Policy view to delete a shared policy from Security Manager. You can delete a policy only if it is not assigned to any devices or VPN topologies. For more information, see Modifying Policy Assignments in Policy View.
Procedure
Step 1
Step 2
Step 3
•
•
A confirmation message is displayed.
Step 4
Related Topics
•
Advanced Policy Features
The following sections describe advanced policy features available in Security Manager:
•
•
Customizing Policy Management
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
To customize policy management of Cisco IOS routers, see Defining Policy Management Settings, page 2-63.
Related Topics
Understanding Rule Inheritance
Inheritance refers to the capability of Security Manager to enforce hierarchical lists of first-match, rule-based policies such as access rules. Within the hierarchy, rules defined in policies at a lower level in the hierarchy (called child policies) extend or override the properties of rules defined in policies that are directly above them in the hierarchy (called parent policies).
This policy hierarchy can extend to multiple levels. For example, you can define an access rule policy for the routers at branch offices 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 certain rules at the corporate level. This ability to define rule-based policies in a hierarchical manner gives you great flexibility when defining your rule sets.
Inheritance determines the ordering of rules inside a rule-based policy. Individual rules are defined as either mandatory or default, and are ordered as follows:
1.
2.
3.
4.
Structuring inheritance in this manner enables you to define mandatory rules at the global level that cannot be superseded by any rules defined within policies located at a lower level in the policy hierarchy. For example, you can define a mandatory rule at the highest level in the policy hierarchy denying all HTTP traffic. If all other access rule policies inherit rules from this parent policy, the mandatory rule denying HTTP traffic will always appear at the top of the access rules list. If another user attempts to define an access rule in a child policy that overwrites this mandatory rule by permitting HTTP traffic, the rule will have no effect. Mandatory rules defined within a child policy are always placed after mandatory rules defined in a parent policy.
Default rules always appear after the mandatory rules in the table. With default rules, the order is reversed—default rules defined in a child policy appear before default rules inherited from the parent policy. 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.
Security Manager displays separate rule tables for mandatory and default rules inside all rule-based policies. An inherited rule can be modified only inside the parent policy in which it was defined. It cannot be modified inside a child policy.
Related Topics
•
Inheriting Rules
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.
Note
You can edit rule inheritance from either Device view or Policy view.
Procedure
Step 1
•
•
Step 2
•
•
Step 3
Step 4
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 5
Related Topics
•
Understanding Locking
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.
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 2-40.
Locking and Devices
When you perform any sort of configuration on a device, a lock is placed on that device to prevent other users from making changes to that device.
Locking and Policies
When you define a policy, the policy is locked. This prevents other users from modifying this policy or assigning it to other devices. They may, however, unassign the policy from a different device.
In the case of a rule-based policy that is a parent to other policies that inherit rules from it, the policy and all its descendants are locked. In certain cases, locking a policy also locks related policies located within the same policy domain.
When you assign a policy to a device without changing its definition, other users are prevented from modifying the definition of that policy. They may, however, assign or unassign this policy from other devices.
When you modify the definition of a policy and change its assignments, other users are prevented from making any changes to this policy or assigning the policy to additional devices. They may, however, unassign the policy from other devices.
Table 6-2 summarizes the effects of policy locks in Security Manager.
Note
Locking and VPN Topologies
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 Setting Up User Permissions, page 2-2.
Locking and Objects
When you create or modify a reusable object, that object is locked to prevent other users from modifying or deleting the same object. However, an object lock does not prevent you from modifying the definition or assignment of a policy that uses that object. Similarly, the lock placed on a policy does not prevent you from making changes to an object that is included in the policy definition.
When an object makes use of other objects (such as network/host objects, service group 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
