Working with Security Policies

Policy Enforcement Points

Components of a Security Policy

Conditional Evaluations

Non-Terminal Actions

Terminal Actions

Security Policy Scope

What Security Policies Cannot Control

What Security Policies Can Control

Checklist for Creating and Enforcing Policy

Working with Security Policies

Security policies are the means by which you configure your Policy Enforcement Points to permit or deny network traffic. In Cisco Secure Policy Manager, security policies take the form of graphical decision trees contained within a security policy abstract. The security policy abstract is then applied to network objects in the Security Policy Enforcement branch of the Network Policy tree.

Successfully building and applying security policies is a complex task. It requires careful planning, a thorough understanding of the policy development and deployment process, an understanding of what security policies can and cannot control, and a thorough understanding of how the security policies are evaluated. Only by understanding these concepts, and how they are interrelated, can you build effective, scalable security policies.

Policy Enforcement Points

Policy Enforcement Points are gateway devices for which you want Cisco Secure Policy Manager to generate and publish device-specific command sets. They act as regulators, controlling the flow of traffic from one network to another based on defined policies. Cisco Secure Policy Manager can manage the following Cisco devices as Policy Enforcement Points:

PIX Firewalls. PIX Firewalls provide perimeter security using access filters, address hiding, and stateful inspection for certain network services, which offers additional security features like Java blocking and TCP_SYN attack protection. In addition, later versions of the PIX Firewall software (5.0 and later) support IPSec to enable secure communications with other IPSec-compliant gateways and hosts.
IOS Routers. Within Cisco Secure Policy Manager, the IOS Router provides one or more functions, including acting as an IPSec gateway and endpoint, providing firewall features, and routing network traffic. The functions supported depend directly on the software image that is installed on the actual IOS Router.

You do not define your managed Policy Enforcement Points within security policies or the Security Policy Enforcement branch; they are defined within your network topology. For more information about configuring Policy Enforcement Points to be managed by Cisco Secure Policy Manager, see Cisco Secure Policy Manager Administrator's Guide: Network Topology Definition.

Components of a Security Policy

Security policies instruct Policy Enforcement Points to evaluate network sessions according to specified conditions, and then to take the appropriate action based on those conditions. There are three conditions that are evaluated: a source condition, a service condition, and a destination condition. On the basis of those conditions, the Policy Enforcement Point then dictates the parameters of the session with an optional non-terminal action and the disposition of that session with a terminal action.

Conditional Evaluations

The conditions provide the evaluative logic for a security policy. Each session passing through a Policy Enforcement Point is evaluated based on the settings for each of these conditions. If a match is made, the policy is enforced. If a match is not made, the session is either rejected or evaluated by another policy (see Policy Evaluation Rules for more information about how policies are evaluated).

Source Condition. The source condition specifies the source of the service that is being controlled by the security policy. Each source condition can refer to exactly one source object, although there are grouping methods that create logical entities that contain more than one object.

The following types of sources can be specified in a security policy:

External IP Address. You can specify particular external network addresses as the source of the session being controlled by the policy. This allows you to explicitly permit or deny particular services from that address (or list of addresses), or to force the use of tunnels or Java blocking from those addresses while allowing Java and non-tunnel traffic from others.
External Host Names. In the same way that you can specify particular network addresses, you can specify an external host name as a source condition. Unlike the External IP Addresses selection, however, you can specify only a single external host name.

Tips The External Host Name panel contains a DNS lookup function that returns the IP address for the host. To specify more than one host name, look up and note the IP address for each host name in the External Host Name panel and then switch to the External IP Address panel, where you can enter all discovered IP addresses.

You cannot use this workaround if one or more hosts use a dynamically assigned IP address.

Network Object Group. Network object groups are logical collections of items from your network topology tree that are treated as a single object within the source condition. They are useful for grouping similar items, such as FTP servers, from various areas in your network topology so that a single service/destination pair can refer to them collectively.

Items in a network object group are treated as if they are connected by "or" statements. For example, if you have a source condition of "if source is FTP Servers," and FTP Servers is a network object group containing FTP Server 1, FTP Server 2, and FTP Server 3, the source condition would be interpreted as "if source is FTP Server 1 or if source is FTP Server 2 or if source is FTP Server 3." When you add another network object to your topology, for example, FTP Server 4, you can update the policy to include the new server simply by adding it to the network object group that contains the other servers.
Policy Domain/Perimeter. A policy domain represents a collection of one or more perimeters. A perimeter represents a network or collection of networks that is bounded by one or more gateways. Perimeters do not appear in the network topology tree; they are defined when setting up your network topology and appear in the Policy Domains branch of the Tools and Services tree. Only one perimeter or policy domain can be specified for each source condition node in a security policy.
Interface. An interface is a single IP address or a collection of IP addresses assigned to an interface on a Policy Enforcement Point. Although interfaces do not appear in the Network Topology tree, they are defined when setting up your network topology. Only one interface can be specified for each source condition node in a security policy.
This Network Object. This Network Object is a special source condition. When security policies are applied to objects in the Security Policy Enforcement branch, they must be either source-based or destination-based policies. When a security policy is source-based, the source condition is always set to This Network Object. This means that the security policy being enforced is evaluating network traffic that is being initiated by the object on which the policy is applied.

Destination Condition. The destination condition specifies the destination of the service that is being controlled by the security policy. Each destination condition can refer to exactly one destination object, although there are grouping methods that create logical entities that contain more than one object.

The following types of destinations can be specified in a security policy:

External IP Address. You can specify particular external network addresses as the destination of the session being controlled by the policy. This allows you to explicitly permit or deny particular services to that address (or list of addresses), or to force the use of tunnels or Java blocking to those addresses while allowing Java and non-tunnel traffic to others.
External Host Names. In the same way that you can specify particular network addresses, you can specify an external host name as a destination condition. Unlike the External IP Addresses selection, however, you can specify only a single external host name.

Network Object Group. Network object groups are logical collections of items from your Network Topology tree that are treated as a single object within the destination condition. They are useful for grouping similar items, such as FTP servers, from various areas in your network topology so that a single service/source pair can refer to them collectively.

Items in a network topology group are treated as if they are connected by "or" statements. For example, if you have a destination condition of "if destination is FTP Servers," and FTP Servers is a network object group containing FTP Server 1, FTP Server 2, and FTP Server 3, the destination condition would be interpreted as "if destination is FTP Server 1 or if destination is FTP Server 2 or if destination is FTP Server 3." When you add another network object to your topology, for example, FTP Server 4, you can update the policy to include the new server simply by adding it to the network object group that contains the other servers.
Policy Domain/Perimeter. A policy domain represents a collection of one or more perimeters. A perimeter represents a network or collection of networks that is bounded by one or more gateways. Perimeters do not appear in the network topology tree; they are defined when setting up your network topology and appear in the Policy Domains branch of the Tools and Services tree. Only one perimeter or policy domain can be specified for each source condition node in a security policy.
Interface. An interface is a single IP address or a collection of IP addresses assigned to an interface on a Policy Enforcement Point. Although interfaces do not appear in the Network Topology tree, they are defined when setting up your network topology. Only one interface can be specified for each destination condition in a security policy.
This Network Object. This Network Object is a special destination condition. When security policies are applied to objects in the Security Policy Enforcement branch, they must be either source-based or destination-based policies. When a security policy is destination-based, the destination condition is always set to This Network Object. This means that the security policy being enforced is evaluating network traffic that is being received by the object on which the policy is applied.

Service Condition. The service condition specifies the service being evaluated by the security policy. Each service condition can refer to exactly one service, although there are grouping methods that create logical entities that contain more than one service.

Valid services include the following:

Individual Network Services. You can specify that the policy evaluates the network session based on an individual network service, such as HTTP. You can also add several individual network services to the service condition, such as HTTP, FTP, and SMTP. This option provides you with fine granularity for controlling the network services that you permit or deny to specific areas of your network.

Note When you add more than one service to a service condition, Cisco Secure Policy Manager automatically creates a network service bundle containing those services.

: You can specify any network service that appears in the Network Services branch of the Tools and Services tree. Additional services are stored in the Network Services Library and can be added to the Network Services branch, or you can use the Network Service Wizard to define new services.

Network Service Bundles. A network service bundle is a logical collection of network services. Many applications, such as electronic mail, rely on more than one service to operate, or you may have a set of common services that you want to allow globally to all your users. By creating a network service bundle that contains these services, and then referring to the bundle in your service condition, you save yourself the time it would take to add each service individually to the service condition.

: Network service bundles are created and stored in the Network Service Bundles branch of the Tools and Services tree. Several pre-configured network service bundles are available for you to choose upon installation. You can also create new network service bundles to satisfy the needs of your particular applications.

Non-Terminal Actions

Non-terminal actions are used to modify the parameters of a particular network session. They do not terminate the security policy, and therefore can be followed by one of two terminal action nodes.

Block Java. The Block Java action is used to prevent potentially malicious Java applications from reaching a protected host. If the Block Java action is not followed by a terminal action, the Java blocking is passed to the parent policy.
Use Tunnel. The Use Tunnel action is used to force a particular source/service/destination combination to use an IPSec secure tunnel. To use the Use Tunnel action within a security policy, you must first have set up your tunnel groups in the IPSec Tunnel Groups branch of the Network Policy tree (refer to Cisco Secure Policy Manager Administrator's Guide: IPSec Tunnel Implementation for information about creating tunnel groups). If the Use Tunnel action is not followed by a terminal action, the tunnel usage is passed to the parent policy.

Terminal Actions

Terminal actions define the final disposition of a network session.

Permit. The Permit action tells the Policy Enforcement Point to allow a particular source/service/destination combination.
Deny. The Deny action causes the Policy Enforcement Point to reject the source/service/destination combination. Cisco Secure Policy Manager has the default security stance of denying all network traffic unless expressly permitted.

Security Policy Scope

A security policy defines the rules for permitting or denying a specific type of network traffic for a specific user or group of users under specific conditions. Security policies are not device configuration tools. Some settings that you may attempt to control through policy are actually device-specific settings that should be configured when setting up your devices in the Network Topology tree.

This topic lists the items you cannot control with policies as well as the items that you can. Where possible, links to additional information about achieving the desired configuration are provided.

What Security Policies Cannot Control

Global session settings

: The Policy Enforcement Points managed by Cisco Secure Policy Manager enforce many session settings, such as the Idle Timeout setting, as global, rather than session specific, settings. These settings are configured at the device level. Refer to Cisco Secure Policy Manager Administrator's Guide: Network Topology Definition for information about configuring global session settings.

Routes

: Security policies do not determine routing for any network session. They do, however, determine if that session is permitted to pass through a Policy Enforcement Point. Specific routing rules are set up at the device level when you define your network topology.

Network Address Translation (NAT)

: NAT is configured at the device level when you define your network topology.

Network traffic between two points that do not have a Policy Enforcement Point between them

: Although you are creating end-to-end security policies, the policies are enforced by a Policy Enforcement Point and not by the endpoints. Therefore, you cannot control network sessions between two hosts on the same network segment, or between two network segments, that do not have a Policy Enforcement Point between them.

What Security Policies Can Control

Note This assumes that the network traffic being controlled passes through a managed Policy Enforcement Point (see above).

Basically, security policies can control whether specific network sessions are permitted or denied between a specified source and destination when passing through a managed Policy Enforcement Point. Additionally, security policies can control some parameters of those sessions:

Java in HTTP sessions

: The security policy can configure the Policy Enforcement Point to block or permit Java applications in HTTP sessions.

The use of tunnels

: Cisco Secure Policy Manager can force specific sessions between two Policy Enforcement Points to be routed through IPSec tunnels. To create a policy that forces the use of tunnels, you must specify IPSec support on the Policy Enforcement Points and you must have the IPSec Tunnel Group defined in the Security Policy Enforcement branch. Refer to Cisco Secure Policy Manager Administrator's Guide: IPSec Tunnel Implementation for more information about using Cisco Secure Policy Manager to implement IPSec.

Checklist for Creating and Enforcing Policy

The following checklist provides an overview of the policy development and deployment process. Before you begin developing your security policies within Cisco Secure Policy Manager, you should become familiar with these steps and the various options for performing them.

Each step, described in the Step column, may contain several sub-steps and should be performed in the order presented. References to the specific procedures used to perform each step appear in the Reference column.

Table 1-1: Security Policy Definition Checklist

Step Reference

1. Populate the Network Topology Tree (prerequisite)

Before you can begin to build security policies in Cisco Secure Policy Manager, you must populate your Network Topology tree. The Network Topology tree performs three main functions in the construction and deployment of security policies. First of all, it provides source and destination objects within the security policies. Secondly, it provides the objects used to populate the Security Policy Enforcement branch (where security policies are applied to network objects). Finally, it provides the topology and routing information for the device-specific command sets generated by the system.

Cisco Secure Policy Manager Administrator's Guide: Network Topology Definition

2. Populate the Security Policy Enforcement Branch

The Security Policy Enforcement branch is where the security policies are applied to network objects. It is a good idea to populate the Security Policy Enforcement branch before you begin to build security policies. The way you populate your Security Policy Enforcement branch will determine the syntax for your security policies. Also, you will be better able to visually identify the policies that are required to meet your business objectives, as well as identify the policy constructors and decisions you will need to make to build the security policies.

"Security Policy Enforcement"

3. Develop Policy Components

Before you begin to develop your policies, you should plan and develop the components of those policies. These components include the following:

Network Protocols. While the network protocol settings do not directly affect the creation of security policy, they are used in developing another policy component, network services.

Network Services. You should determine what services you are going to regulate (permit or deny) on your network. The default stance of Cisco Secure Policy Manager is to deny anything that is not expressly permitted, so you will need to define the services that you want to permit across your Policy Enforcement Points. Cisco Secure Policy Manager comes with many common network services pre-defined, and the ability to define any custom services that you may need.

Network Service Bundles. Network service bundles are logical collections of network services that can be used, as a whole, as the service being referenced by the security policy. They provide a shortcut method for referencing a group of common services (such as web and mail services) without having to create complex decision trees. Before building your security policies, you should determine if you will have common groups of services that you will be permitting for destinations, groups of destinations, sources, or groups of sources. You can be fairly liberal with the services you include in network service bundles, because policy evaluation and inheritance enable you to create specific exceptions for more permissive policies that apply to a higher level group (for example, denying Telnet sessions to a particular host that is part of a group of hosts with a policy that permits Telnet sessions).

Policy Domains. Policy domains are logical collections of perimeters that can be used as the source or destination of network services in a security policy. You can also place policy domains in the Security Policy Enforcement branch of the Network Policy tree and apply policies to them.

"Protocol Definitions"

"Network Services"

"Network Service Bundles"

"Network Object Groups"

Network Object Groups. Network object groups are logical collections of network objects from your network topology that can be used, as a whole, as the source or destination of network services in a security policy. You should group common network objects, such as web servers, that may be scattered throughout your network topology, in network object groups to facilitate referencing them in common security policies.

4. Develop Security Policy Abstracts

After you have formulated your overall security strategy, built your network topology, populated your Security Policy Enforcement branch, and created the necessary policy components, you then construct the actual policies that will be applied to the objects in your Security Policy Enforcement branch. You create and manage your policies on the Security Policy Abstracts branch of the Tools and Services tree and use Policy Builder to develop and modify the contents of each security policy.

"Security Policy Abstracts"

"Policy Builder"

5. Assign Policy

After creating and populating your security policies, you assign your policies to the objects in the Security Policy Enforcement branch.

"Security Policy Enforcement"

6. Generate and Publish the Command Sets

The final step in the policy development and deployment process is the generation of device-specific command sets and publication of those command sets to the Policy Enforcement Points. You generate the command sets from the Command Console panel. After generating the command sets, you have the opportunity to review each Policy Enforcement Point's device-specific command set. You can also define commands that are not automatically derived by Cisco Secure Policy Manager either as a prologue or epilogue command set and import and export your custom commands sets to ease administration of like Policy Enforcement Points.

"Generating, Verifying, and Publishing Command Sets"

	Step	Reference
	1. Populate the Network Topology Tree (prerequisite) Before you can begin to build security policies in Cisco Secure Policy Manager, you must populate your Network Topology tree. The Network Topology tree performs three main functions in the construction and deployment of security policies. First of all, it provides source and destination objects within the security policies. Secondly, it provides the objects used to populate the Security Policy Enforcement branch (where security policies are applied to network objects). Finally, it provides the topology and routing information for the device-specific command sets generated by the system.	Cisco Secure Policy Manager Administrator's Guide: Network Topology Definition
	2. Populate the Security Policy Enforcement Branch The Security Policy Enforcement branch is where the security policies are applied to network objects. It is a good idea to populate the Security Policy Enforcement branch before you begin to build security policies. The way you populate your Security Policy Enforcement branch will determine the syntax for your security policies. Also, you will be better able to visually identify the policies that are required to meet your business objectives, as well as identify the policy constructors and decisions you will need to make to build the security policies.	"Security Policy Enforcement"
	3. Develop Policy Components Before you begin to develop your policies, you should plan and develop the components of those policies. These components include the following: Network Protocols. While the network protocol settings do not directly affect the creation of security policy, they are used in developing another policy component, network services. Network Services. You should determine what services you are going to regulate (permit or deny) on your network. The default stance of Cisco Secure Policy Manager is to deny anything that is not expressly permitted, so you will need to define the services that you want to permit across your Policy Enforcement Points. Cisco Secure Policy Manager comes with many common network services pre-defined, and the ability to define any custom services that you may need. Network Service Bundles. Network service bundles are logical collections of network services that can be used, as a whole, as the service being referenced by the security policy. They provide a shortcut method for referencing a group of common services (such as web and mail services) without having to create complex decision trees. Before building your security policies, you should determine if you will have common groups of services that you will be permitting for destinations, groups of destinations, sources, or groups of sources. You can be fairly liberal with the services you include in network service bundles, because policy evaluation and inheritance enable you to create specific exceptions for more permissive policies that apply to a higher level group (for example, denying Telnet sessions to a particular host that is part of a group of hosts with a policy that permits Telnet sessions). Policy Domains. Policy domains are logical collections of perimeters that can be used as the source or destination of network services in a security policy. You can also place policy domains in the Security Policy Enforcement branch of the Network Policy tree and apply policies to them.	"Protocol Definitions" "Network Services" "Network Service Bundles" "Network Object Groups"
	Network Object Groups. Network object groups are logical collections of network objects from your network topology that can be used, as a whole, as the source or destination of network services in a security policy. You should group common network objects, such as web servers, that may be scattered throughout your network topology, in network object groups to facilitate referencing them in common security policies.
	4. Develop Security Policy Abstracts After you have formulated your overall security strategy, built your network topology, populated your Security Policy Enforcement branch, and created the necessary policy components, you then construct the actual policies that will be applied to the objects in your Security Policy Enforcement branch. You create and manage your policies on the Security Policy Abstracts branch of the Tools and Services tree and use Policy Builder to develop and modify the contents of each security policy.	"Security Policy Abstracts" "Policy Builder"
	5. Assign Policy After creating and populating your security policies, you assign your policies to the objects in the Security Policy Enforcement branch.	"Security Policy Enforcement"
	6. Generate and Publish the Command Sets The final step in the policy development and deployment process is the generation of device-specific command sets and publication of those command sets to the Policy Enforcement Points. You generate the command sets from the Command Console panel. After generating the command sets, you have the opportunity to review each Policy Enforcement Point's device-specific command set. You can also define commands that are not automatically derived by Cisco Secure Policy Manager either as a prologue or epilogue command set and import and export your custom commands sets to ease administration of like Policy Enforcement Points.	"Generating, Verifying, and Publishing Command Sets"

Table of Contents

Working with Security Policies