|
|
Within the Security Policy Enforcement branch, you organize only those network objects for which you want to enforce security policies directly. You can also create Security Policy folders that define high-level logical groups of network objects to which you can apply a single security policy.
The Security Policy Enforcement branch displays the network objects on which you want to enforce security policies directly. By performing a drag-and-drop operation to move network objects from the Network Topology tree onto this branch, you can construct a logical tree that determines which security policy applies to any given network object. When a network object in this branch has a policy enforced on it, the scroll icon beside it is yellow.
By default, Cisco Secure Policy Manager includes a Trusted Networks folder, a Cisco System Folder, and a Default Policy node in the Security Policy Enforcement branch. Additionally, you can create more folders on this branch in which you can logically group network objects.
The Trusted Networks folder is simply a top-level user folder that you can delete, rename, and store objects in as you would the folders that you create.
The Cisco System Folder is a special system folder. You cannot delete or rename this folder, nor should you place any of your network objects in this folder. When you create specific types of network objects, like a policy server, the network objects are automatically added to this folder with a system policy attached to each. The system policy ensures that the various components of Cisco Secure Policy Manager are not cut off from one another or from the Policy Enforcement Points.
The Default Policy node acts as the top-level point where you can define policy. You cannot delete this node. The Default Policy node is the only node on the Security Policy Enforcement branch where you can attach a policy that does not have either an "If source is this object" or an "If destination is this object" condition. It is a global policy point, which is evaluated if there is no specific policy match farther down in the Security Policy Enforcement branch. If the policy applied to the Default Policy node still does not match the evaluation criteria for the packet being analyzed, the default security stance of "deny all traffic that is not expressly permitted" applies.
User folders, which are folders that you can create on the branch or under other folders or network objects, can contain other folders or an assortment of network objects. Policies applied to those folders affect the objects each folder contains (unless a more specific policy is applied to the object itself).
The following subtopics explain the concepts and guidelines that you need to know before you can effectively populate the Security Policy Enforcement branch with network objects and apply security policies to those network objects:
After you have populated your Security Policy Enforcement branch with network objects and applied security policies to those network objects, Cisco Secure Policy Manager publishes lists of commands to the Policy Enforcement Points specifying which security policy applies to each network object. It generates the lists of commands using a "first and all" match semantic.
Cisco Secure Policy Manager searches for the first network object match from a top-down, right-to-left (or depth) perspective of the Security Policy Enforcement branch. It continues the traversal of all branches in the Security Policy Enforcement branch in this manner, generating rule lists from the policy attached to each network object (or parent object if no policy is attached to the network object) (for more information see Policy Inheritance) until all instances of that network object are added to the rule list. After all the branches have been traversed, the policy (if any) applied to the Default Policy node is added to the rule list. When evaluating policies (or rule lists), if Cisco Secure Policy Manager finds no matches for a specific network object or in the Default Policy, it applies the default security stance of "deny all network traffic that is not expressly permitted."
 |
Note For Users of Cisco Security Manager version 1.x In version 1.x of Cisco Security Manager, all policies were source-based policies, containing an implicit "If source is this network object" source condition. This precluded the use of the same network object on multiple branches of the Security Policy Enforcement branch. The policy evaluation rule used a "best match" semantic for policy evaluation, which meant that the most specific security policy in relation to the network object was enforced first, followed by the security policies enforced on any parent objects (until it reached the top level of the Security Policy Enforcement branch, where the default stance of "deny all traffic that is not expressly permitted" was applied). After the source condition was matched, only the security policy on that object (or its parent objects) was evaluated; the system did not look for matches on other branches. With the addition of the explicit source condition, the preclusion of repeated network objects was removed to enable multiple instances of the same network object in the Security Policy Enforcement branch. In this way, both source-based and destination-based policies could be enforced on a network object (by creating two instances of that network object and putting a single policy on each). The best match policy evaluation semantic was replaced with the "first and all" match semantic. |
Policy inheritance refers to the use of recursive lists of security policies. The Security Policy Enforcement branch is a hierarchal structure in which network objects are placed in a logical, rather than physical, arrangement as siblings or children of one another. Inheritance means that children objects inherit the security policies applied to their parent objects if the child object does not have a security policy applied to it or if the evaluation of the decision tree contained by an applied policy does not result in a terminal action (Permit or Deny).
When the evaluation of a security policy applied to a child node in the Security Policy Enforcement branch does not reach a terminal action (or if the node has no policy attached), the next security policy up in the Security Policy Enforcement branch and in the direct path of that node is applied. In other words, policy inheritance enables one security policy to defer permitting or denying requested network services to another security policy (one that has been applied to the parent node). This process can proceed through all branches of the Security Policy Enforcement branch until, if no matches are found or terminal actions reached, the default security stance of "deny all traffic that is not expressly permitted" is applied. In this way, no service is permitted to traverse the Policy Enforcement Point unless explicitly permitted by a security policy.
Depending on how you populate your Security Policy Enforcement branch, you can create a "chain" of policy inheritance (the term we use for the act of deferring to another security policy) whereby the most specific security policies are enforced on specific objects deep in the branch (such as a particular workstation), while more general security policies are enforced on more general parent objects (such as a network or a Security Policy folder).
This concept becomes clearer with an example. Let's say that in your Security Policy Enforcement branch you have put a trusted network (parent node represented by A in Figure 9-1), and under that trusted network you have positioned numerous workstations (sibling nodes underneath the trusted network in the graphic below) on that network. Furthermore, you know that the person working at one of those sibling workstations (see B in Figure 9-1) has a need to access a particular server out on the Internet (such as an FTP server) that you want to prevent all other sibling workstations from accessing. You could construct two security policy abstracts to allow the person at workstation Bob to access the server while restricting all other FTP services.
You could construct a security policy abstract specifying that FTP traffic destined for that server on the Internet is accepted (see Figure 9-2).
You could construct another security policy abstract specifying that all FTP traffic (see Figure 9-3) destined for the Internet is rejected.
Applying the first security policy to Workstation Bob (the sibling) and then applying the second security policy to the trusted network (the parent) creates an instance where policy inheritance applies. If the person working at Workstation Bob tries to access the specified FTP server on the Internet, the Policy Enforcement Point permits the network service. If that person tries to access another FTP server on the Internet, the security policy applied to that workstation does not apply, and the policy processing is deferred to the next security policy up (the security policy attached to the parent node). In our example, the next security policy up denies all FTP traffic to the Internet; therefore no other FTP server can be accessed from Workstation Bob except the one specified by the security policy attached to it.
|
Note For Users of Cisco Security Manager version 1.x In version 1.x of Cisco Security Manager, the Use Parent Policy node was used to force policy inheritance. In Cisco Secure Policy Manager version 2.x, the Use Parent Policy node was removed from the decision tree, and policy inheritance occurs whenever policy evaluation does not result in a terminal action. |
The following strategies will assist you in populating the Security Policy Enforcement branch.
1. Keep your planned policies in mind.
2. Think network traffic endpoints, not Policy Enforcement Points.
3. Use folders to group network objects.
4. Start populating the branch with the more general objects and work down toward the specific ones.
5. Be careful where you place policies that reference the Internet node.
See Policy Evaluation Rules, and Policy Inheritance, for more information about how security policies are evaluated in the Security Policy Enforcement branch.
Before you can enforce a security policy on a network object (from the Network Topology tree), you must add that network object to the Security Policy Enforcement branch of the Network Policy tree. Where you place the network object in the Security Policy Enforcement branch does affect which security policies apply to it (policy inheritance).
To add a network object to the Security Policy Enforcement branch, perform the following task:
Step 2 Click the object in the Network Topology tree, and while holding down the mouse button, drag the network object over the node in the Security Policy Enforcement branch under which you want to place the network object, and then release the mouse button.
Result: The network object appears in the Security Policy Enforcement branch underneath the parent node on which you dropped the object. Also, an empty scroll icon appears beside the new network object node.
Step 3 To save any changes that you have made, click Save on the File menu.
|
Note When you make a change to a network object in the Network Topology tree, such as renaming it, that change automatically propagates up to the representation of that object in the Security Policy Enforcement branch. |
To create a Security Policy folder, perform the following task:
|
Note You can also define a folder just below the Security Policy Enforcement branch. |
Step 2 Right-click the icon under which you want to define a new folder.
Step 3 Point to New, and then click Security Policy Folder on the shortcut menu.
Result: A new node named Security Policy Folder # appears under the selected node.
Step 4 Type the new name in the Name box and press Enter.
Result: The new name appears in the Name box of the selected node.
The name of the folder may include up to 256 alphanumeric characters, but it may not include quotation marks (") or semicolons (;).
 |
Tips If you cannot edit the name, right-click the new Security Policy Folder node, and click Rename on the shortcut menu. |
Step 5 To save any changes that you have made, click Save on the File menu.
A network object in the Security Policy Enforcement branch cannot access any network service until you enforce a security policy on it. The reason for this is that Cisco Secure Policy Manager forces a minimalist stance on any enforcement point (PIX Firewall) that it manages. This minimalist stance means that every request for network service is rejected unless specifically permitted with a security policy. You can see this minimalist approach represented by the default state of any new security policy abstract, which rejects all IP-based traffic outright. "Policy Builder," discusses these issues in more detail.
To apply a security policy to a network object, perform the following task:
Step 2 Click the security policy abstract in the Security Policy Abstracts branch of the Tools and Services tree, and while holding down the mouse button, drag the policy over the network object in the Security Policy Enforcement branch, and then release the mouse button.
Result: A yellow scroll icon appears beside the network object node, signifying that a security policy has been enforced on it.
Step 3 To save any changes you have made, click Save on the File menu.
|
Note You can apply security policies to network objects in the Security Policy Enforcement branch in two other ways: you can use the Policy Assignment utility listed on the Tools menu, or you can create the security policy by right-clicking the network object in the Security Policy Enforcement branch, which opens Policy Builder and enables you to create a security policy that is automatically enforced on that network object. |
|
Note If you are going to apply another security policy abstract to the node, you do not need to remove the existing security policy abstract from it. Instead, you can simply apply the new security policy abstract over the existing one on the node. The new security policy abstract will replace the one that was previously applied. |
To remove a security policy abstract from a node, perform the following task:
Step 2 Right-click the icon of the network object that contains the security policy abstract you want to remove, point to Policy, and then click Remove on the shortcut menu.
Result: The security policy abstract is removed from the network object.
Step 3 To save any changes you have made, click Save on the File menu.
Posted: Thu May 25 13:28:15 PDT 2000
Copyright 1989 - 2000©Cisco Systems Inc.