|
|
To use Cisco Security Manager effectively, you must understand the terminology that is used throughout the product. This section identifies key terms and concepts to help you develop a model that matches the one used by Cisco Security Manager.
Table 1-1 presents the key words that we use to describe different objects within the user interface and explains their role within the system. It also identifies terms that may be familiar to you if you have used command line interfaces (CLIs) to configure routers and firewalls.
| Security Manager Term | Common Terms | Correct Interpretation |
|---|---|---|
rules that are common to more than one network device | A concept that enables you to define a high-level network policy and enforce it universally across your network devices without having to understand all the device-specific rules and settings required to enforce that policy (policy vs. mechanism). You can, for example, manage 50 PIX Firewalls using policy management without having to define unique rules for each PIX Firewall and download them one at a time. This concept helps you work better by enabling you to specify what you want to do, the end result, without having to know how to accomplish it for the specific devices. | |
In the Network Topology tree, this concept signifies the flow of network packets away from the Internet node toward your networks. It is the opposite of downstream. | ||
firewalls, routers, proxy servers, PIX Firewall | An abstract term used to identify a network device that accepts a policy (configuration rules) from the Policy Distribution Point component of Cisco Security Manager and enforces that policy against the network traffic traversing that network device. | |
protocol, service | A network service identifies that service used by a network application. It specifies the protocol and port number used by the service. Policy abstracts use network services as service-based condition nodes. | |
templates, conduits, filters, access control lists, access filter | A template that identifies the rules about whether or not you want to allow network services, such as HTTP and FTP, across your network. These templates are abstract in that they are not dependent on the PEP that actually enforces the rules. Policy abstracts represent a collection of condition branches. A security policy abstract has two states: active and inactive. An active security policy abstract is one that is applied to network objects within the Security Policy Enforcement branch of the Network Policy tree. Active security policy abstracts are enforced by PEPs. An inactive security policy abstract is one that is defined under the Security Policy Abstracts branch of the Tools and Services tree, where it represents a template for a specific implementation. Saved changes to the templates are reflected in the active policies. | |
session start | A session request is the initial request by a network object to begin a session with another network object. | |
A condition branch represents a test that a PEP performs against a session request to determine whether to allow that session. A condition branch comprises one or more conditions terminated by two terminal nodes. Depending on whether the session request parameters satisfy the condition, the request is either accepted, rejected, processed by the next condition branch, or passed up to the next policy for evaluation to find a condition that more closely matches the parameters of a particular session request. | ||
condition | evaluation | A comparative test between administrator-defined values (values acceptable according to corporate policy) and the actual values of a session request. |
An action is a terminal node (resolution) in a condition branch. A PEP will enforce a specific action against any session requests that satisfy the condition branch leading to that action. Only two actions exist: ACCEPT and REJECT. A condition evaluates a session request to determine whether that session satisfies the constraints identified by the user. The action determines whether to accept or reject the session. | ||
multiple protocols/services | A bundle represents a collection of two or more network services. You can use bundles to organize the network services that you use most so that when you define a policy abstract, you do not have to include multiple service condition nodes in the policy definition. | |
network address translation (NAT), port address translation (PAT) | A dynamic mapping of addresses for a set of real addresses on network objects to a set of alias addresses on a PEP. | |
N/A | Policy inheritance refers to the ability of Cisco Security Manager to use hierarchical lists of policies. If a policy on a lower node of a tree has the action Use Next Policy applied to a condition branch, then the next policy up and in the direct path of that node is applied. This ability is transferred all the way up to the Policy Enforcement branch if the policies below that branch use the Use Next Policy action. Dominance is an attribute of the lowest node to which a policy is applied. If the parameters of a session request match two policies within a direct path, the one applied to the lowest node in that path is applied to that session. | |
A fixed one-to-one mapping from a set of real addresses on network objects to a set of alias addresses on a PEP. | ||
| Identifies the set of devices that control access to an area of the network topology. The Perimeter icon in the Policy Manager represents a defensible boundary that provides complete control of traffic between network objects inside the perimeter and network objects outside of the perimeter. The term perimeter is also used to mean the boundary and everything inside that boundary. | |
| The boundary formed by the set of farthest downstream PEPs. It is often used to refer to everything inside that boundary, including the Internet node. This term differs from the Internet node in that it includes those networks shared between the Internet node and the farthest downstream PEPs. It is a higher-level grouping construct than the Internet node. | |
| A cloud represents a contiguous part of a network topology that can route network packets, but for which the internal structure is not important. Cisco Security Manager models a cloud as a gateway with internal networks. | |
The Internet node represents the interconnected global network outside the control of the Cisco Security Manager installation. In Cisco Security Manager, this concept is modeled as a special type of cloud because it acts like one. From this perspective, the Internet node is a gateway with a set of access points to the controlled networks where a network packet enters from one access point and leaves out another access point. This node is also a cloud because it can contain internal networks for which the internal structure is not important. It is a special node because it is the unique root of the network topology. Note You must attach at least one network to the Internet. Most commonly, this network identifies the network that you share with your Internet Service Provider (ISP). In addition, you must attach a gateway device, either a router or firewall, to that network. This gateway device is usually one that you own. | ||
| A cloud network is a special type of network that resides inside of a cloud. The primary distinction from a normal network is that it exists only as part of a cloud, not as a network in the Network Topology tree. | |
| A server that is exposed to users who are not members of the perimeter on which it resides. The feature lets users access the server even though it resides on a network that is hidden via address hiding rules. It is primarily used in conjunction with address hiding rules. | |
Cisco Security Manager servers | Depending on whether you have a standalone or distributed installation, one or more of these servers must be defined in the Network Topology tree. These servers are responsible for generating and distributing network policies and for monitoring network traffic for suspicious activities and reporting about such activities. | |
Policy Distribution Point |
| An abstract term used to identify an installed subsystem in the Cisco Security Manager architecture. This subsystem accepts intermediate policy descriptions from a Policy Generation Point, translates the policy description into a device-specific command set, and publishes the device-specific command sets to the PEPs for which it is responsible. Policy Distribution Points are responsible for one or more PEPs on the network. |
Policy Monitor Point |
| An abstract term used to identify an installed subsystem in the Cisco Security Manager architecture. This subsystem monitors event streams produced by one or more PEPs. |
| An agent based on the public domain Apache Web server code that is part of the Reporting Subsystem. The reporting agent (Examiner.exe) is responsible for displaying scheduled and on-demand reports to web browsers that request information about the system. | |
| A proprietary knowledge-based subsystem that persistently stores configuration information, as well as information and the audit records generated by the Cisco Security Manager system about network service and system activities. The configuration information includes network objects, policies, administrative and user authentication accounts, as well as settings for the various Cisco Security Manager architecture subsystems and components, such as the Policy Monitor Point and Policy Database. Each time an agent connects to the Policy Database, the agent and the Policy Database authenticate to each other using a bi-directional authentication method (a public-private key handshake). This authentication method uses the Microsoft Crypto API to perform the handshakes. This authentication also occurs between any two Policy Databases (for example, secondary to primary). | |
A physical piece of hardware that connects a host system to a network medium. | ||
| The relationship defined by a network adapter and a network protocol. An interface is the relationship of hardware, software, and configuration data that allows a host to send and receive network packets to/from a physical network wire. | |
network address | subnet address, network number | A number that InterNIC assigns to your network. The network number forms the first part of a host's IP address. |
network mask | A number used by software applications to separate additional network information (called the "subnet") from the host part of an IP address. The network mask is also referred to as a subnet mask or netmask. | |
network object | host, IP address, server, node, network device | A network object is either a logical or physical representation of a network device, or collection of network devices, defined in the Network Topology tree. Because we use logical concepts to represent network devices, such as domain users and hostnames, we use the term network object to encompass these abstract terms and common physical terms of identifying network devices, such as an IP address. Typically, a network object is an entity on a network that is addressable via an IP address, an IP address and subnet mask, or a hostname. |
IP address | A unique number that identifies each node on a network. Each node must be assigned a unique IP address. The address is made up of two distinct parts: a network ID, which identifies the network, and a host ID, which is typically assigned by the administrator. These addresses are typically represented in dotted-decimal notation, such as 192.168.11.27. See network mask. |
Six key concepts exist within Cisco Security Manager:
The following sections explain these concepts.
Instead of viewing your network from the perspective of a particular PIX Firewall when you define your network topology, you must begin with the outermost connection to the network. First, you define your access network and the default route (the IP address on the default gateway of your access network) on the Internet node. From here, you define the network objects and networks that populate your network, from the outside to the inside.
Unlike other management tools, Cisco Policy Manager (the user interface for Cisco Security Manager) does not require you to configure permit/deny lists directly for any particular network device, such as a PIX Firewall. Instead, you develop a higher-level security policy that defines service and destination conditions and the actions that you want to effect against network session requests that satisfy those conditions. Security policy abstracts represent templates that you define and later apply to network objects within the Security Policy Enforcement branch of the Network Policy tree.
Cisco Security Manager follows a minimalist and reductionist approach. This approach dictates that simplicity is best, and it follows the paradigm of "that which is not expressly permitted is prohibited." The default security policy applied to all PEPs is "reject." Therefore, unless you explicitly define a security policy that allows a network service to originate from a specific source, the session request will be denied by the PEP.
The Security Policy Enforcement branch is where you actually apply security policies, or in other words, the place where you define the rules that the actual PEPs will enforce. Within this branch, a network object represents the source of the network traffic. You can only implement security policies against the objects represented in this branch; however, you can represent logical network objects like networks and IP ranges, which reduce the number of hosts that you must identify. Unlike other models, the Security Policy Enforcement branch enables you to express your network security policy logically. Two other concepts are important for understanding how the Security Policy Enforcement branch works:
The next two sections describe these concepts.
After you have populated your Security Policy Enforcement branch and enforced security policies on those network objects, Cisco Security Manager issues commands to the enforcement points specifying which security policy applies to each network object. The rule of policy enforcement is that the most specific security policy in relation to the network object is enforced first.
This rule, that of the most specific match, means that the security policy that references the network object most specifically with the implicit If Source is statement (remember that this implicit statement derives from applying a security policy directly to a network object) is the one that regulates it. Therefore, a security policy applied directly to a host (say Workstation Bob) is more specific than one applied to the parent node under which Workstation Bob is situated in the Security Policy Enforcement tree, and that security policy takes control. Now, if Workstation Bob has a security policy enforced on it that contains a Use Parent Policy node, or if Workstation Bob has no security policy enforced on it directly, the next security policy up and in the direct path of Workstation Bob (the next most specific security policy) regulates network traffic originating from it. So, if Workstation Bob is situated within a folder called Engineering, and if the folder has a security policy enforced on it but Workstation Bob does not, the security policy attached to the folder takes control.
This process continues up the Security Policy Enforcement branch, where the more general policies are enforced. A security policy attached to the Trusted Networks folder at the top of the Security Policy Enforcement branch is the most general (the "umbrella") security policy, except in the instance that no security policy has been attached to it, in which case the default policy of reject all services applies.
Policy inheritance refers to the use of recursive lists of security policies. When a security policy applied to a child node in the Security Policy Enforcement branch has the Use Parent Policy terminal action node at the end of a condition branch (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 all the way up the Security Policy Enforcement branch.
All nodes within the Security Policy Enforcement branch are children of the branch itself. By default, these children have an implicit security policy attached to them that contains only the Use Parent Policy action. The Security Policy Enforcement branch has a different implicit security policy attached to it that contains only the Reject action. Therefore, if no security policy has been enforced on Workstation Bob, which is under a Trusted Network node in the Security Policy Enforcement branch, any request for network services coming from Workstation Bob is handled by the next security policy up (the one applied to the Trusted Network node). If none of the nodes in the Security Policy Enforcement branch has a security policy enforced on it, the service request from Workstation Bob is rejected. This approach is minimalist, meaning that no service is permitted unless specifically stated by a security policy.
You can, though, use the Use Parent Policy node to control policy inheritance. The Use Parent Policy node defers permitting or denying any network traffic to another security policy. If all conditions of the branch ending with a Use Parent Policy node are fulfilled, the next security policy up (the policy applied to the parent object) and in the direct path in the Security Policy Enforcement branch determines any action. 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 (child 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).
The settings that you define for logging and notification (administrator alerts) apply to all PEPs managed by Cisco Security Manager. However, the ability of the PEP to generate the requisite Syslog events depends on the particular device's log settings.
Cisco Security Manager can be distributed for the purposes of reducing server burden for specific types of services, such as network monitoring, and to ensure more secure distribution of security policy. In some network topologies, it is necessary to distribute these Cisco Security Manager servers to publish the device-specific command sets to multiple PIX Firewalls. The important things to remember are that the Cisco Security Manager servers must reside on a network upstream from the "inside" interface, each Cisco Security Manager server must be represented in your Network Topology tree, and each Cisco Security Manager server that runs a Policy Distribution Point must have Telnet access to the inside interface.
Posted: Wed Aug 18 19:24:55 PDT 1999
Copyright 1989-1999©Cisco Systems Inc.