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, 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
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, and cannot be overridden by local or default rules. The Default section contains rules that can be overridden by mandatory and local rules. You can define rules in either the Mandatory or Default 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
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:
-
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 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.
For routers and firewalls (ASA, PIX, FWSM), you can choose which platform-specific policies to manage. For more information, see Customizing Policy Management for Routers and Firewall Devices.
Local Policies vs. Shared Policies
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.
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 or the Site-to-Site VPN Manager.
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 or the Site-to-Site VPN Manager.
Tips
-
Shared policies can be grouped together to form policy bundles. Policy bundles make managing the assignment of shared policies easier especially when working with a large number of devices. For more information, see Managing Policy Bundles.
-
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.
-
If you use more than one Security Manager server, you can maintain a consistent set of policies among the servers by regularly exporting shared policies from your primary server and importing them into the other servers. You must decide which server to use as the official policy source. For more information, see Exporting Shared Policies and Importing Policies or Devices.
-
In Version 4.7, Cisco Security Manager has added a new option to the available filtering choices in the Device Filter. This new option provides a filter for devices that have shared policies applied. To see this in the Security Manager GUI, navigate to
... [in the dropdown list]. When the Create Filter dialog box appears, use the dropdown lists to select "Device," "has," and "Shared Policy," for a resulting filter of "Device has ’Shared Policy’".
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.
You can assign the shared policies to an existing VPN using the Site-to-Site VPN Manager; right-click a shareable policy and select Assign Shared Policy. This is done in much the same way as assigning shared policies in Device view. You can also configure shared policies as the default policies to use in the Create VPN wizard, as described in Understanding and Configuring VPN Default Policies.
Related Topics
Understanding Rule Inheritance
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).
Note |
If a policy bundle includes a shared policy that inherits from other shared policies, those inherited rules are also applied to any devices on which the policy bundle is applied. |
Rule Order When Using Inheritance
As described in Understanding Access Rules, 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.
The below figure describes how rules are ordered in the rules table 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.
Related Topics
Inheritance vs. Assignment
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. |
-
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
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 that accepts an object as a value. For more information, see Selecting Objects for Policies. You can also create and manage objects system-wide from the Policy Object Manager.
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.
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.
For more information about objects and how to use them when defining policies, see Managing Policy Objects.
Related Topics
Understanding Policy Locking
Security Manager has a policy 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.
Tip |
Security Manager also obtains activity (or configuration session) locks, which are broader in scope than policy locks, when users perform some actions. For more information, see Activities and Locking. |
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 Workflow and Activities Overview.
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
The following table 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. |
If Another User or Activity... |
You Cannot... |
You Can... |
||
---|---|---|---|---|
Changes a policy definition |
|
Unassign the policy from any device (if it is shared). |
||
Changes the definition of a rule-based policy with descendants |
|
Unassign the policy from any device. |
||
Changes a policy assignment without changing its definition |
Modify the policy.
|
Assign and unassign the policy from other devices. |
||
Changes a policy definition and changes its assignment |
Modify the policy or assign it to other devices. |
Unassign the policy from any device. |
Related Topics
Understanding Locking and VPN Topologies
If you change the device assignment for a VPN topology, or make changes to a specific VPN policy, a lock is placed on the whole VPN topology, and on any other topologies in which the policy is shared. 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 those VPN topologies.
In order to view and modify site-to-site VPN policies, you must have the required permissions for each device in the VPN topology. You also need permissions to add a device to a VPN topology. If you have different levels of permissions to the devices in the VPN topology, the lowest permission level is applied to the entire topology. For example, if you have read/write permissions to the spokes in a hub-and-spoke topology, but read-only permissions to the device serving as the hub, you are granted read-only permission to the policies and devices in the hub-and-spoke topology. For more information about permissions, see Installation Guide for Cisco Security Manager .
Note |
Unassigning devices from a VPN topology also creates device locks in the VPN topology, which means that these devices cannot be deleted from the inventory. Other users cannot edit the device assignments for the topology until you deploy configurations to all affected devices, including those you remove. The device is not actually removed from the topology until you deploy configurations. |
Related Topics
Understanding 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. 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
Customizing Policy Management for Routers and Firewall Devices
When you manage Cisco IOS routers or ASA, PIX, or FWSM firewall devices, 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.
Caution |
If you use AUS or CNS to deploy configurations to ASA or PIX devices, be aware that the device downloads a full configuration from AUS or CNS. Thus, reducing the policies managed by Security Manager actually removes the configurations from the device. If you intend to deselect some ASA/PIX policies for management to use other applications along with Security Manager to configure devices, do not use AUS or CNS. |
The ability to customize policy management on routers and firewalls makes it possible, for example, to use Security Manager to manage DHCP and NAT policies 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.
To customize policy management for routers and firewalls, select Policy Management Page. The policy types are organized in folders, with router and firewall (which includes all ASA, PIX, and FWSM devices) handled separately. Select or deselect policy types as desired and click Save. Subsequent processing depends on whether you are changing a policy type to be managed or unmanaged:
to open the-
Unmanaging a policy type—If you unmanage a policy type, and any device of that type has that policy configured, you must unassign the policies before unmanaging them. Security Manager displays a list of all devices that have assigned policies of that type, including the policy name, device name, and the user or activity that has a lock on the policy. If you click Yes to continue unmanaging the policy, Security Manager obtains the required locks, unassigns the policies, and then unmanages the policy type.
If a lock could not be obtained for even one device, no policies are unassigned, the policy type is not unmanaged, and you are told of the problem. You can then either manually unassign the policies from the affected devices, or release the user or activity locks, and try again to unmanage the policy type.
Note |
Unmanaging a policy has no effect on the active configuration running on the device; Security Manager does not remove the configuration from the device. Instead, unmanaging the policy removes it from the database, and Security Manager no longer considers that part of the device configuration. |
-
Managing a previously-unmanaged policy type—If you start managing a policy type that you previously did not manage using Security Manager, it is possible that the active configuration on the device has commands controlled by the newly-managed policy type. It is therefore important that you rediscover policies on all devices of that type (either all routers or all ASA, PIX, FWSM devices). This ensures that Security Manager has the current configuration for these policies.
If you do not rediscover policies and leave the newly-managed policies unconfigured, on the next deployment to the device, the existing settings configured on the device are removed. For more information on discovering policies on devices already managed, see Discovering Policies on Devices Already in 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 Managing Flexconfigs. |