User Guide for Cisco Security Manager 4.4

Understanding SGT and SXP Support in Cisco TrustSec

In the Cisco TrustSec solution, security group access transforms a topology-aware network into a role-based network, thus enabling end-to-end policies enforced on the basis of role-based access-control (RBACL). Device and user credentials acquired during authentication are used to classify packets by security groups. Every packet entering the Cisco TrustSec cloud is tagged with an security group tag (SGT). The tagging helps trusted intermediaries identify the source identity of the packet and enforce security policies along the data path.

An SGT can indicate a privilege level across the domain when the SGT is used to define a security group ACL. An SGT is assigned to a device through IEEE 802.1X authentication, web authentication, or MAC authentication bypass (MAB), which happens with a RADIUS vendor-specific attribute. An SGT can be assigned statically to a particular IP address or to a switch interface. An SGT is passed along dynamically to a switch or access point after successful authentication.

The Security-group eXchange Protocol (SXP) is a protocol developed for Cisco TrustSec to propagate the IP-to-SGT mapping database across network devices that do not have SGT-capable hardware support to hardware that supports SGTs and security group ACLs. SXP, a control plane protocol, passes IP-SGT mappings from authentication points (such as legacy access layer switches) to upstream devices in the network.

The SXP connections are point-to-point and use TCP as the underlying transport protocol. SXP uses the well known TCP port number 64999 when initiating a connection. Additionally, an SXP connection is uniquely identified by the source and destination IP addresses.

Roles in the Cisco TrustSec Solution

To provide identity and policy-based access enforcement, the Cisco TrustSec solution includes the functionality:

• Access Requestor (AR): Access requestors are end-point devices that request access to protected resources in the network. They are primary subjects of the architecture and their access privilege depends on their Identity credentials.

Access requestors include end-point devices such PCs, laptops, mobile phones, printers, cameras, and MACsec-capable IP phones.

• Policy Decision Point (PDP): A policy decision point is responsible for making access control decisions. The PDP provides features such as 802.1x, MAB, and Web authentication. The PDP supports authorization and enforcement through VLAN, DACL, and security group access (SGACL/SXP/SGT).

In the Cisco TrustSec solution, the Cisco Identity Services Engine (ISE) acts as the PDP. The Cisco ISE provides identity and access control policy functionality.

• Policy Information Point (PIP): A policy information point is a source that provides external information (for example, reputation, location, and LDAP attributes) to policy decision points.

Policy information points include devices such as Session Directory, Sensors IPS, and Communication Manager.

• Policy Administration Point (PAP): A policy administration point defines and inserts policies into authorization system. The PAP acts as an identity repository, by providing Cisco TrustSec tag to user identity mapping and Cisco Trustsec tag to server resource mapping.

In the Cisco TrustSec solution, the Cisco Secure Access Control System (a policy server with integrated 802.1x and SGT support) acts as the PAP.

• Policy Enforcement Point (PEP): A policy enforcement point is the entity that carries out the decisions (policy rules and actions) made by the PDP for each AR. PEP devices learn identity information through the primary communication path that exists across networks. PEP devices learn the identity attributes of each AR from many sources, such as end-point agents, authorization servers, peer-enforcement devices, and network flows. In turn, PEP devices use SXP to propagate IP-SGT mappings to mutually-trusted peer devices across the network.

Policy enforcement points include network devices such as Catalyst switches, routers, firewalls (specifically the ASA), servers, VPN devices, and SAN devices.

The ASA serves the role of the PEP in the identity architecture. Using SXP, the ASA learns identity information directly from authentication points and uses that to enforce identity-based policies.

Security Group Policy Enforcement

Security policy enforcement is based on security group name. Compared to traditional IP-based policies configured on firewalls, identity-based policies are configured based on user and device identities. For example, mktg-contractor is allowed to access mktg-servers; mktg-corp-users are allowed to access mktg-server and corp-servers.

The benefits of this type of deployment include:

• User group and Resource is defined and enforced using single object (SGT) - simplified policy management.
• User identity and resource identity are retained throughout the Cisco Trustsec capable switch infrastructure.

Figure 14-1 Security Group Name Based Policy Enforcement Deployment

Implementing Cisco TrustSec allows for configuration of security policies supporting server segmentation.

• A pool of servers can be assigned an SGT for simplified policy management.
• The SGT information is retained within the infrastructure of Cisco Trustsec capable switches.
• The ASA can leverage the IP-SGT mapping for policy enforcement across the Cisco TrustSec domain.
• Deployment simplification is possible because 802.1x authorization for servers is mandatory.

How the ASA Enforces Security Group Based Policies

Note User-based security policies and security-group based policies, can coexist on the ASA. Any combination of network, user-based and security-group based attributes can be configured in a security policy.

After the ASA establishes a secure communication channel with the Cisco Identity Services Engine (ISE), the ASA initiates a PAC secure RADIUS transaction with the ISE and downloads Cisco TrustSec environment data; specifically, the ASA downloads the security group table. The security group table maps SGTs to security group names. Security group names are created on the ISE and provide user-friendly names for security groups.

Note For more information about the Cisco Identity Services Engine, see http://www.cisco.com/en/US/products/ps11640/index.html.

The first time the ASA downloads the security group table, it walks through all entries in the table and resolves all the security group names contained in security policies configured on the ASA; then, the ASA activates those security policies locally. If the ASA is unable to resolve a security group name, it generates a system log message for the unknown security group name.

The following figure shows how a security policy is enforced in Cisco TrustSec.

Figure 14-2 Security Policy Enforcement

1. An end-point device connects to an access layer device directly or via remote access and authenticates with Cisco TrustSec.

2. The access layer device authenticates the end-point device with the ISE by using authentication methods such as 802.1X or web authentication. The end-point device passes role and group membership to classify the device into the appropriate security group.

3. The access layer device uses SXP to propagate the IP-SGT mapping to the upstream devices.

4. The ASA receives the packet. Using the IP-SGT mapping passed by SXP, the ASA looks up the SGTs for the source and destination IP addresses.

If the mapping is new, the ASA records it in its local IP-SGT Manager database. The IP-SGT Manager database, which runs in the control plan, tracks IP-SGT mappings for each IPv4 or IPv6 address. The database records the source from which the mapping was learned. The peer IP address of the SXP connection is used as the source of the mapping. Multiple sources can exist for each IP-SGT mapping.

If the ASA is configured as a Speaker, the ASA transmits all IP-SGT mappings to its SXP peers. See About Speaker and Listener Roles.

5. If a security policy is configured on the ASA with that SGT or security group name, the ASA enforces the policy. (You can create security policies on the ASA that contain SGTs or security group names. To enforce policies based on security group names, the ASA needs the security group table to map security group names to SGTs.)

If the ASA cannot find a security group name in the security group table and it is included in a security policy, the ASA considers the security group name unknown and generates a system log message. When it becomes know after the ASA refreshes the security group table from the ISE, the ASA generates a system log message indicating that the security group name is known.

About Speaker and Listener Roles

The ASA supports SXP to send and receive IP-SGT mappings to and from other network devices. Employing SXP allows security devices and firewalls to learn identity information from access switches without the need for hardware upgrades or changes. SXP can also be used to pass IP-SGT mappings from upstream devices (such as datacenter devices) back to the downstream devices. The ASA can receive information from both upstream and downstream directions.

When configuring an SXP connection on the ASA to an SXP peer, you must designate the ASA as a Speaker or a Listener for that connection so that it can exchange identity information:

• Speaker mode—configures the ASA so that it can forward all active IP-SGT mappings collected on the ASA to upstream devices for policy enforcement.
• Listener mode—configures the ASA so that it can receive IP-SGT mappings from downstream devices (SGT-capable switches) and use that information in creating policy definitions.

If one end of an SXP connection is configured as Speaker, then the other end must be configured as a Listener, and vice versa. If both devices on each end of an SXP connection are configured with the same role (either both as Speakers or both as Listeners), the SXP connection will fail and the ASA will generate a system log message.

Configuring the ASA to be both a Speaker and a Listener for an SXP connection can cause SXP looping, meanings that SXP data can be received by an SXP peer that originally transmitted it.

As part of configuring SXP on the ASA, you configure an SXP reconcile timer. After an SXP peer terminates its SXP connection, the ASA starts a hold down timer. Only SXP peers designated as Listener devices can terminate a connection. If an SXP peer connects while the hold down timer is running, the ASA starts the reconcile timer; then, the ASA updates the IP-SGT mapping database to learn the latest mappings.

Prerequisites for Integrating an ASA with Cisco TrustSec

Before configuring the ASA to integrate with Cisco TrustSec, you must perform the following prerequisites:

• Register the ASA with the ISE.
• Create a security group for the ASA on the ISE.
• Generate the PAC file on the ISE to import into the ASA.

Registering the ASA with the ISE

The ASA must be configured as a recognized Cisco TrustSec network device in the ISE before the ASA can successfully import a PAC file.

1. Log into the ISE.

2. Choose Administration > Network Devices > Network Devices .

3. Click Add .

4. Enter the IP address of the ASA.

5. When the ISE is being used for user authentication in the Cisco TrustSec solution, enter a shared secret in the Authentication Settings area.

When you configure the AAA sever on the ASA, provide the shared secret you create here on the ISE. The AAA server on the ASA uses this shared secret to communicate with the ISE.

6. Specify a device name, device ID, password, and a download interval for the ASA. See the ISE documentation for the details to perform these tasks.

Creating a Security Group on the ISE

When configuring the ASA to communicate with the ISE, you specify a AAA server. When configuring the AAA server on the ASA, you must specify a server group.

The security group must be configured to use the RADIUS protocol.

1. Log into the ISE.

2. Choose Policy > Policy Elements > Results > Security Group Access > Security Group .

3. Add a security group for the ASA. (Security groups are global and not ASA specific.)

The ISE creates an entry under Security Groups with a tag.

4. Under the Security Group Access section, configure a device ID credentials and password for the ASA.

Generating the PAC

Before generating the PAC file, you must have registered the ASA with the ISE.

1. Log into the ISE.

2. Choose Administration > Network Resources > Network Devices .

3. From the list of devices, select the ASA device.

4. Under the Security Group Access (SGA), click Generate PAC .

5. To encrypt the PAC file, enter a password.

The password (or encryption key) you enter to encrypt the PAC file is independent of the password that was configured on the ISE as part of the device credentials.

The ISE generates the PAC file. The ASA can import the PAC from flash or from a remote server via TFTP, FTP, HTTP, HTTPS, or SMB. (The PAC does not have to reside on the ASA flash before you can import it.)

Configuring Cisco TrustSec Services

This procedure explains how to enable and configure Cisco TrustSec in Cisco Security Manager and on the required security devices.

Before You Begin

Before configuring an ASA to integrate with Cisco TrustSec, you must meet the prerequisites explained in Prerequisites for Integrating an ASA with Cisco TrustSec.

To configure Cisco TrustSec, perform the following tasks:

Step 1 Configure communication between Cisco Security Manager and the Cisco Identity Services Engine (ISE). See ISE Settings Page.

Step 2 Enable and set the default values for the Security Exchange Protocol (SXP). See Configuring Security Exchange Protocol (SXP) Settings.

Step 3 Add SXP connection peers for the Cisco TrustSec architecture. See Defining SXP Connection Peers.

Step 4 Configure the Security Policy. See Configuring TrustSec-Based Firewall Rules.

Step 5 Monitor the TrustSec firewall system. See Monitoring TrustSec Firewall Policies.

Configuring Security Exchange Protocol (SXP) Settings

Configuring the Security Exchange Protocol (SXP) involves enabling the protocol on the ASA and setting the following default values for SXP:

• The retry interval for SXP connections
• The Cisco TrustSec SXP reconcile period
• The RADIUS server group defined on the ISE.

Navigation Path

• (Device view) Select an ASA device, then select TrustSec > SXP Settings from the Policy selector.
• (Policy view) Select TrustSec > SXP Settings from the Policy selector. Select an existing policy or create a new one.

Related Topics

• Prerequisites for Integrating an ASA with Cisco TrustSec
• Defining SXP Connection Peers

Field Reference

Defining SXP Connection Peers

The Security-group eXchange Protocol (SXP) is a protocol developed for Cisco TrustSec to propagate the IP-to-SGT mapping database across network devices that do not have SGT-capable hardware support to hardware that supports SGTs and security group ACLs. SXP, a control plane protocol, passes IP-SGT mappings from authentication points (such as legacy access layer switches) to upstream devices in the network. SXP connections between peers are point-to-point and use TCP as the underlying transport protocol.

Note ASA Software 9.0(1)+ is required for TrustSec firewall.

Related Topics

• Prerequisites for Integrating an ASA with Cisco TrustSec
• About Speaker and Listener Roles
• Configuring Security Exchange Protocol (SXP) Settings

Step 1 Do one of the following:

• (Device view) Select an ASA device, then select TrustSec > SXP Connection Peers from the Policy selector.
• (Policy view) Select TrustSec > SXP Connection Peers from the Policy selector. Select an existing policy or create a new one.

Step 2 In Default Source , enter the default local IP address for SXP connections. You can enter an IP address or the name of a network/host object, or click Select to select the object from a list or to create a new one. The IP address can be an IPv4 or IPv6 address.

Note The ASA determines the local IP address for an SXP connection as the outgoing interface IP address that is reachable by the peer IP address. If the configured local address is different from the outgoing interface IP address, the ASA cannot connect to the SXP peer and generates a system log message.

Step 3 In Default Password and Confirm , enter the default password for TCP MD5 authentication with SXP peers. By default, SXP connections do not have a password set.

You can specify the password as an encrypted string up to 162 characters or an ASCII key string up to 80 characters.

Step 4 Configure the SXP Peers:

You can do the following:

• To add an entry, click the Add Row (+) button and fill in the Add Connection Peer dialog box. See Add/Edit Connection Peer Dialog Box.
• To edit an entry, select it and click the Edit Row (pencil) button.
• To delete an entry, select it and click the Delete Row (trash can) button.

Step 5 Click Save to save your changes.

Add/Edit Connection Peer Dialog Box

Use the Add/Edit Connection Peer dialog box to define the settings for an SXP Connection.

Navigation Path

• (Device view) Select an ASA device, then select TrustSec > SXP Connection Peers from the Policy selector.

– To add an entry, click the Add Row (+) button.

– To edit an entry, select it and click the Edit Row (pencil) button.

• (Policy view) Select TrustSec > SXP Connection Peers from the Policy selector. Select an existing policy or create a new one.

– To add an entry, click the Add Row (+) button.

– To edit an entry, select it and click the Edit Row (pencil) button.

Related Topics

• About Speaker and Listener Roles
• Prerequisites for Integrating an ASA with Cisco TrustSec

Field Reference

Creating Security Group Objects

You can create security group object groups for use in features that support Cisco TrustSec by including the group in an extended ACL, which in turn can be used in an access rule, for example.

When integrated with Cisco TrustSec, the ASA downloads security group information from the Cisco Identity Services Engine (ISE). The ISE acts as an identity repository, by providing Cisco TrustSec tag to user identity mapping and Cisco TrustSec tag to server resource mapping. You provision and manage security group access lists centrally on the ISE.

However, the ASA might have localized network resources that are not defined globally that require local security groups with localized security policies. Local security groups can contain nested security groups that are downloaded from the ISE. The ASA consolidates local and central security groups.

To create local security groups on the ASA, you create a local security object group. A local security object group can contain one or more nested security object groups or Security IDs or security group names. Users can also create a new Security ID or security group name that does not exist on the ASA.

You can use the security object groups you create to control access to network resources. You can use the security object group as part of an access group or service policy.

Tips

• Use of these objects is supported on ASA 9.0(1)+ only.
• You must configure the TrustSec policy on the ASA to enable the use of these objects.
• You can create security group objects when defining policies or objects that use this object type. For more information, see Selecting Security Groups in Policies.

Related Topics

• Selecting Security Groups in Policies
• Creating Policy Objects

Step 1 Select Manage > Policy Objects to open the Policy Object Manager (see Policy Object Manager).

Step 2 Select Security Group from the Object Type selector.

Step 3 Right-click in the work area, then select New Object to open the Add Security Group dialog box.

Step 4 Enter a name for the object and optionally a description of the object.

Step 5 Add and remove items in the Members in Group list to identify the users and user groups defined in the object.

To populate the list, do any combination of the following:

• In Available Security Group , select an existing object and click the Add >> button between the lists.
• In Search name/tag , select a security group from the ISE server configured in the ISE Settings administrative options. You must configure the settings before you can select a name or tag.

To find a security group, enter a search string. Then, click Search to find matches. A name is considered a match if the string appears anywhere within the security group name.

To add the security group, select it in the list and click the Add >> button between the lists.

• In Type in comma separated (Name or Tag) , first select the type of entry you are making, Name or Tag. Type in a valid security group name or tag number, then click the Add >> button between the lists. Separate multiple names or tags with commas; they are added as separate lines in the members list.
• To remove an item from the object, select it in the Members list and click the << Remove button between the lists.

Step 6 (Optional) Under Category, select a category to help you identify this object in the Objects table. See Using Category Objects.

Step 7 (Optional) Select Allow Value Override per Device to allow the properties of this object to be redefined on individual devices. See Allowing a Policy Object to Be Overridden.

Step 8 Click OK to save the object.

Selecting Security Groups in Policies

In any policy or policy object that allows the specification of security groups, whether directly or through the selection of a TrustSec security group object, you can click the Select button next to the Security Groups field to help you enter the information.

In the Security Group Selector dialog box, you can define the content of the Security Groups field by populating the Members in Group list. To populate the list, do any combination of the following:

• In Available Security Group , select an existing object and click the Add >> button between the lists. If the desired object does not exist, you can click the Add (+) button below the list to create a new object. You can also select an object and click the Edit (pencil) button to modify it or to examine its contents.
• In Search name/tag , select a security group from the ISE server configured in the ISE Settings administrative options. You must configure the settings before you can select a name or tag, so that Security Manager knows which ISE server to use.

To find a security group, enter a search string. Then, click Search to find matches. A name is considered a match if the string appears anywhere within the security group name.

To add the security group, select it in the list and click the Add >> button between the lists.

• In Type in comma separated Security name or tag , first select the type of entry you are making, Name or Tag. Type in a valid security group name or tag number, then click the Add >> button between the lists. Separate multiple names or tags with commas; they are added as separate lines in the members list.
• To remove an item from the object, select it in the Members list and click the << Remove button between the lists.

Configuring TrustSec-Based Firewall Rules

Security group awareness is integrated into the access control entries, or rules, in the ACLs used to provide firewall services. Because the feature is integrated into the ACL, the techniques for adding security group awareness to a firewall policy are the same for all types of firewall policy. This topic provides general guidance on how to incorporate security group awareness into your existing policies, and directs you to more specific information on configuring each type of policy that supports security groups.

Firewall Policies That Support Security Groups

Security group rules are allowed on ASA 9.0.1+ only. The following policies allow you to configure security groups:

• AAA Rules—Select Firewall > AAA Rules and see Configuring AAA Rules for ASA, PIX, and FWSM Devices.
• Access Rules—Select Firewall > Access Rules and see Configuring Access Rules.
• Inspection Rules—Select Firewall > Inspection Rules and see Configuring Inspection Rules.
• Policies that use extended ACL policy objects—Several firewall policies use extended ACL policy objects to define traffic matching criteria instead of incorporating a rule table directly in the policy. You can configure extended ACL policy objects to include security group specifications (see Creating Extended Access Control List Objects). You can then use these extended ACL objects in the following policies:

– Botnet Traffic Filter Rules—Select Firewall > Botnet Traffic Filter Rules and see Enabling Traffic Classification and Actions for the Botnet Traffic Filter. You can use security groups as part of the traffic classification for Enable and Drop rules.

– IPS, QoS, and Connection Rules (service policy rules)—Select Platform > Service Policy Rules > IPS, QoS, and Connection Rules and see IPS, QoS, and Connection Rules Page.

Traffic match criteria in this policy is based on extended ACL policy objects that are incorporated into traffic flow policy objects. You must select one of the options for specifying an ACL in the traffic flow object to incorporate security group traffic classification. For more information, see Configuring Traffic Flow Objects.