ASA and Cisco TrustSec

This chapter describes how to implement Cisco TrustSec for the ASA.

About Cisco TrustSec

Traditionally, security features such as firewalls performed access control based on predefined IP addresses, subnets, and protocols. However, with enterprises transitioning to borderless networks, both the technology used to connect people and organizations and the security requirements for protecting data and networks have evolved significantly. Endpoints are becoming increasingly nomadic and users often employ a variety of endpoints (for example, laptop versus desktop, smart phone, or tablet), which means that a combination of user attributes plus endpoint attributes provide the key characteristics (in addition to existing 6-tuple based rules), that enforcement devices such as switches and routers with firewall features or dedicated firewalls can reliably use for making access control decisions.

As a result, the availability and propagation of endpoint attributes or client identity attributes have become increasingly important requirements to enable security across the customers’ networks, at the access, distribution, and core layers of the network, and in the data center.

Cisco TrustSec provides access control that builds upon an existing identity-aware infrastructure to ensure data confidentiality between network devices and integrate security access services on one platform. In the Cisco TrustSec feature, enforcement devices use a combination of user attributes and endpoint attributes to make role-based and identity-based access control decisions. The availability and propagation of this information enables security across networks at the access, distribution, and core layers of the network.

Implementing Cisco TrustSec into your environment has the following advantages:

About SGT and SXP Support in Cisco TrustSec

In the Cisco TrustSec feature, security group access transforms a topology-aware network into a role-based network, which enables end-to-end policies enforced on the basis of role-based access control (RBAC). 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 a 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 occurs 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 mapping 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 TCP port 64999 to initiate a connection. Additionally, an SXP connection is uniquely identified by the source and destination IP addresses.

Roles in the Cisco TrustSec Feature

To provide identity and policy-based access enforcement, the Cisco TrustSec feature includes the following roles:

  • Access Requester (AR)—Access requesters are endpoint 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 requesters include endpoint 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 feature, 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, Sensor IPS, and Communication Manager.

  • Policy Administration Point (PAP)—A policy administration point defines and inserts policies into the 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 feature, 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 endpoint agents, authorization servers, peer enforcement devices, and network flows. In turn, PEP devices use SXP to propagate IP-SGT mapping 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 Cisco ASA serves the PEP role in the identity architecture. Using SXP, the ASA learns identity information directly from authentication points and uses it to enforce identity-based policies.

Security Group Policy Enforcement

Security policy enforcement is based on security group name. An endpoint device attempts to access a resource in the data center. 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 the following:

  • User group and resource are defined and enforced using single object (SGT) simplified policy management.

  • User identity and resource identity are retained throughout the Cisco TrustSec-capable switch infrastructure.

The following figure shows a deployment for security group name-based policy enforcement.

Figure 1. Security Group Name-Based Policy Enforcement Deployment

Implementing Cisco TrustSec allows you to configure security policies that support server segmentation and includes the following features:

  • 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 use 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.

To configure the ASA to function with Cisco TrustSec, you must import a Protected Access Credential (PAC) file from the ISE.

Importing the PAC file to the ASA establishes a secure communication channel with the ISE. After the channel is established, the ASA initiates a PAC secure RADIUS transaction with the ISE and downloads Cisco TrustSec environment data (that is, 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.

The first time that the ASA downloads the security group table, it walks through all entries in the table and resolves all the security group names included in security policies that have been configured on it; then the ASA activates those security policies locally. If the ASA cannot resolve a security group name, it generates a syslog message for the unknown security group name.

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

Figure 2. Security Policy Enforcement

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

  2. The access layer device authenticates the endpoint device with the ISE by using authentication methods such as 802.1X or web authentication. The endpoint device passes role and group membership information 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 and looks up the SGTs for the source and destination IP addresses using the IP-SGT mapping passed by SXP.

    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 plane, tracks IP-SGT mapping 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 mapped entry.

    If the ASA is configured as a Speaker, the ASA transmits all IP-SGT mapping entries to its SXP peers.

  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 include 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 to be unknown and generates a syslog message. After the ASA refreshes the security group table from the ISE and learns the security group name, the ASA generates a syslog message indicating that the security group name is known.

Effects of Changes to Security Groups on the ISE

The ASA periodically refreshes the security group table by downloading an updated table from the ISE. Security groups can change on the ISE between downloads. These changes are not reflected on the ASA until it refreshes the security group table.


Tip

We recommend that you schedule policy configuration changes on the ISE during a maintenance window, then manually refresh the security group table on the ASA to make sure the security group changes have been incorporated.

Handling policy configuration changes in this way maximizes the chances of security group name resolution and immediate activation of security policies.

The security group table is automatically refreshed when the environment data timer expires. You can also trigger a security group table refresh on demand.

If a security group changes on the ISE, the following events occur when the ASA refreshes the security group table:

  • Only security group policies that have been configured using security group names need to be resolved with the security group table. Policies that include security group tags are always active.

  • When the security group table is available for the first time, all policies with security group names are walked through, security group names are resolved, and policies are activated. All policies with tags are walked through, and syslogs are generated for unknown tags.

  • If the security group table has expired, policies continue to be enforced according to the most recently downloaded security group table until you clear it, or a new table becomes available.

  • When a resolved security group name becomes unknown on the ASA, it deactivates the security policy; however, the security policy persists in the ASA running configuration.

  • If an existing security group is deleted on the PAP, a previously known security group tag can become unknown, but no change in policy status occurs on the ASA. A previously known security group name can become unresolved, and the policy is then inactivated. If the security group name is reused, the policy is recompiled using the new tag.

  • If a new security group is added on the PAP, a previously unknown security group tag can become known, a syslog message is generated, but no change in policy status occurs. A previously unknown security group name can become resolved, and associated policies are then activated.

  • If a tag has been renamed on the PAP, policies that were configured using tags display the new name, and no change in policy status occurs. Policies that were configured with security group names are recompiled using the new tag value.

Speaker and Listener Roles on the ASA

The ASA supports SXP to send and receive IP-SGT mapping entries to and from other network devices. Using 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 mapping entries from upstream devices (such as data center devices) back to 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 mapping entries collected on the ASA to upstream devices for policy enforcement.

  • Listener mode—Configures the ASA so that it can receive IP-SGT mapping entries from downstream devices (SGT-capable switches) and use that information to create policy definitions.

If one end of an SXP connection is configured as a 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 fails and the ASA generates a syslog message.

Multiple SXP connections can learn IP-SGT mapping entries that have been downloaded from the IP-SGT mapping database. After an SXP connection to an SXP peer is established on the ASA, the Listener downloads the entire IP-SGT mapping database from the Speaker. All changes that occur after this are sent only when a new device appears on the network. As a result, the rate of SXP information flow is proportional to the rate at which end hosts authenticate to the network.

IP-SGT mapping entries that have been learned through SXP connections are maintained in the SXP IP-SGT mapping database. The same mapping entries may be learned through different SXP connections. The mapping database maintains one copy for each mapping entry learned. Multiple mapping entries of the same IP-SGT mapping value are identified by the peer IP address of the connection from which the mapping was learned. SXP requests that the IP-SGT Manager add a mapping entry when a new mapping is learned the first time and remove a mapping entry when the last copy in the SXP database is removed.

Whenever an SXP connection is configured as a Speaker, SXP requests that the IP-SGT Manager forward all the mapping entries collected on the device to the peer. When a new mapping is learned locally, the IP-SGT Manager requests that SXP forward it through connections that are configured as Speakers.

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

Register 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. To register the ASA with the ISE, perform the following steps:

Procedure

Step 1

Log into the ISE.

Step 2

Choose Administration > Network Devices > Network Devices.

Step 3

Click Add.

Step 4

Enter the IP address of the ASA.

Step 5

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

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

Step 6

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

Create 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. To create a security group on the ISE, perform the following steps:

Procedure

Step 1

Log into the ISE.

Step 2

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

Step 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.

Step 4

In the Security Group Access area, configure device ID credentials and a password for the ASA.

Generate the PAC File

To generate the PAC file, perform the following steps.


Note

The PAC file includes a shared key that allows the ASA and ISE to secure the RADIUS transactions that occur between them. For this reason, make sure that you store it securely on the ASA.

Procedure

Step 1

Log into the ISE.

Step 2

Choose Administration > Network Resources > Network Devices.

Step 3

From the list of devices, choose the ASA.

Step 4

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

Step 5

To encrypt the PAC file, enter a password.

The password (or encryption key) that 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 file from flash or from a remote server via TFTP, FTP, HTTP, HTTPS, or SMB. (The PAC file does not have to reside on the ASA flash before you can import it.)

Guidelines for Cisco TrustSec

This section includes the guidelines and limitations that you should review before configuring Cisco TrustSec.

Failover

  • You can configure security group-based policies on the ASA in both the Active/Active and Active/Standby configurations.

  • When the ASA is part of a failover configuration, you must import the PAC file to the primary ASA device. You must also refresh the environment data on the primary device.

  • The ASA can communicate with the ISE configured for high availability (HA).

  • You can configure multiple ISE servers on the ASA and if the first server is unreachable, it continues to the next server, and so on. However, if the server list is downloaded as part of the Cisco TrustSec environment data, it is ignored.

  • If the PAC file downloaded from the ISE expires on the ASA and it cannot download an updated security group table, the ASA continues to enforce security policies based on the last downloaded security group table until the ASA downloads an updated table.

Clustering

  • When the ASA is part of a clustering configuration, you must import the PAC file to the control unit.

  • When the ASA is part of a clustering configuration, you must refresh the environment data on the control unit.

IPv6

The ASA supports SXP for IPv6 and IPv6-capable network devices. The AAA server must use an IPv4 address.

Layer 2 SGT Imposition

  • Supported only on physical interfaces, subinterfaces, redundant interfaces, and EtherChannel interfaces.

  • Not supported on logical interfaces or virtual interfaces, such as a BVI.

  • Does not support link encryption using SAP negotiation and MACsec.

  • Not supported on failover links.

  • Not supported on cluster control links.

  • The ASA does not reclassify existing flows if the SGT is changed. Any policy decisions that were made based on the previous SGT remain in force for the life of the flow. However, the ASA can immediately reflect SGT changes on egress packets, even if the packets belong to a flow whose classification was based on a previous SGT.

  • Firepower 1010 switch ports and VLAN interfaces do not support Layer 2 Security Group Tagging Imposition.

Additional Guidelines

  • The ASA supports SXP Version 3. The ASA negotiates SXP versions with different SXP-capable network devices.

  • You can configure the ASA to refresh the security group table when the SXP reconcile timer expires and you can download the security group table on demand. When the security group table on the ASA is updated from the ISE, changes are reflected in the appropriate security policies.

  • Cisco TrustSec supports the Smart Call Home feature in single context and multi-context mode, but not in the system context.

  • The ASA can only be configured to interoperate in a single Cisco TrustSec domain.

  • The ASA does not support static configuration of SGT-name mapping on the device.

  • NAT is not supported in SXP messages.

  • SXP conveys IP-SGT mapping to enforcement points in the network. If an access layer switch belongs to a different NAT domain than the enforcing point, the IP-SGT map that it uploads is invalid, and an IP-SGT mapping database lookup on the enforcement device does not yield valid results. As a result, the ASA cannot apply security group-aware security policy on the enforcement device.

  • You can configure a default password for the ASA to use for SXP connections, or you can choose not to use a password; however, connection-specific passwords are not supported for SXP peers. The configured default SXP password should be consistent across the deployment network. If you configure a connection-specific password, connections may fail and a warning message appears. If you configure the connection with the default password, but it is not configured, the result is the same as when you have configured the connection with no password.

  • The ASA can be configured as an SXP Speaker or Listener, or both. However, SXP connection loops can form when a device has bidirectional connections to a peer or is part of a unidirectionally connected chain of devices. (The ASA can learn IP-SGT mapping for resources from the access layer in the data center. The ASA might need to propagate these tags to downstream devices.) SXP connection loops can cause unexpected behavior of SXP message transport. In cases where the ASA is configured to be a Speaker and Listener, an SXP connection loop can occur, causing SXP data to be received by the peer that originally transmitted it.

  • When changing the ASA local IP address, you must ensure that all SXP peers have updated their peer list. In addition, if SXP peers changes its IP addresses, you must ensure those changes are reflected on the ASA.

  • Automatic PAC file provisioning is not supported. The ASA administrator must request the PAC file from the ISE administrative interface and import it into the ASA.

  • PAC files have expiration dates. You must import the updated PAC file before the current PAC file expires; otherwise, the ASA cannot retrieve environment data updates. If the PAC file downloaded from the ISE expires on the ASA and it cannot download an updated security group table, the ASA continues to enforce security policies based on the last downloaded security group table until the ASA downloads an updated table.

  • When a security group changes on the ISE (for example, it is renamed or deleted), the ASA does not change the status of any ASA security policies that contain an SGT or security group name associated with the changed security group; however, the ASA generates a syslog message to indicate that those security policies changed.

  • The multi-cast types are not supported in ISE 1.0.

  • An SXP connection stays in the initializing state among two SXP peers interconnected by the ASA; as shown in the following example: 

    
(SXP peer A) - - - - (ASA) - - - (SXP peer	B)

    Therefore, when configuring the ASA to integrate with Cisco TrustSec, you must enable the no-NAT, no-SEQ-RAND, and MD5-AUTHENTICATION TCP options on the ASA to configure SXP connections. Create a TCP state bypass policy for traffic destined to SXP port TCP 64999 among the SXP peers. Then apply the policy on the appropriate interfaces.

    For example, the following set of commands shows how to configure the ASA for a TCP state bypass policy: 

    
access-list SXP-MD5-ACL extended permit tcp host peerA host peerB eq 64999
access-list SXP-MD5-ACL extended permit tcp host peerB host peerA eq 64999

tcp-map SXP-MD5-OPTION-ALLOW
 tcp-options range 19 19 allow

class-map SXP-MD5-CLASSMAP
 match access-list SXP-MD5-ACL

policy-map type inspect dns preset_dns_map
 parameters
  message-length maximum 512
policy-map global_policy
class SXP-MD5-CLASSMAP
  set connection random-sequence-number disable
  set connection advanced-options SXP-MD5-OPTION-ALLOW
  set connection advanced-options tcp-state-bypass
service-policy global_policy global

Configure the ASA to Integrate with Cisco Trustsec

To configure the ASA to integrate with Cisco TrustSec, perform the following tasks.

Before you begin

Before configuring the ASA to integrate with Cisco TrustSec, you must complete the following tasks in ISE:

Procedure

Step 1

Configure the AAA Server for Cisco TrustSec Integration

Step 2

Import a PAC File

Step 3

Configure the Security Exchange Protocol

This task enables and sets the default values for SXP.

Step 4

Add an SXP Connection Peer

Step 5

Refresh Environment Data

Do this as needed.

Step 6

Configure the Security Policy

Step 7

Configure Layer 2 Security Group Tagging Imposition

Configure the AAA Server for Cisco TrustSec Integration

This section describes how to integrate the AAA server for Cisco TrustSec. To configure the AAA server group to communicate with the ISE on the ASA, perform the following steps.

Before you begin

  • The referenced server group must be configured to use the RADIUS protocol. If you add a non-RADIUS server group to the ASA, the configuration fails.

  • If the ISE is also used for user authentication, obtain the shared secret that was entered on the ISE when you registered the ASA with the ISE. Contact your ISE administrator to obtain this information.

Procedure

Step 1

Choose Configuration > Firewall > Identity By TrustSec.

Step 2

Click Manage to add a server group to the ASA.

The Configure AAA Server Group dialog box appears.

Step 3

Enter the name of the security group that was created on the ISE for the ASA.

The server group name you specify here must match the name of the security group that was created on the ISE for the ASA. If these two group names do not match, the ASA cannot communicate with the ISE. Contact your ISE administrator to obtain this information.

Step 4

Choose RADIUS from the Protocol drop-down list.

To complete the remaining fields in the AAA Server Group dialog box, see the RADIUS chapter in the general operations configuration guide.

Step 5

Click OK.

Step 6

Select the AAA sever group that you just created and click Add in the Servers in the Selected Group area to add a server to a group.

The Add AAA Server dialog box appears.

Step 7

Select the network interface where the ISE server resides.

Step 8

Enter the IP address of the ISE server.

To complete the remaining fields in the AAA Server dialog box, see the RADIUS chapter in the general operations configuration guide.

Step 9

Click OK.

Step 10

Click Apply to save the changes to the running configuration.

Import a PAC File

This section describes how to import a PAC file.

Before you begin

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

  • Obtain the password used to encrypt the PAC file when generating it on the ISE. The ASA requires this password to import and decrypt the PAC file.

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

  • The server group has been configured for the ASA.

    To import a PAC file, perform the following steps:

Procedure

Step 1

Choose Configuration > Firewall > Identity By TrustSec.

Step 2

Check the Enable Security Exchange Protocol check box to enable SXP.

Step 3

Click Import PACto display theImport PAC dialog box.

Step 4

Enter the path and filename for the PAC file by using one of the following formats:

  • disk0: Path and filename on disk0

  • disk1: Path and filename on disk1

  • flash: Path and filename on flash

  • ftp: Path and filename on FTP

  • http: Path and filename on HTTP

  • https: Path and filename on HTTPS

  • smb: Path and filename on SMB

  • tftp: Path and filename on TFTP

Multi-mode

  • http: Path and filename on HTTP

  • https: Path and filename on HTTPS

  • smb: Path and filename on SMB

  • tftp: Path and filename on TFTP

Step 5

Enter the password used to encrypt the PAC file. The password is independent of the password that was configured on the ISE as part of the device credentials.

Step 6

Reenter the password to confirm it.

Step 7

Click Import.

Step 8

Click Apply to save the changes to the running configuration.

When you import the PAC file, the file is converted to ASCII HEX format and sent to the ASA in non-interactive mode.

Configure the Security Exchange Protocol

You need to enable and configure the Security Exchange Protocol (SXP) to use Cisco Trustsec.

Before you begin

At least one interface must be in the UP/UP state. If you enable SXP with all interfaces down, the ASA does not display a message indicating that SXP is not working or it could not be enabled. If you check the configuration by entering the show running-config command, the command output displays the following message: 

 
 “WARNING: SXP configuration in process, please wait for a few moments and try again.”

Procedure

Step 1

Choose Configuration > Firewall > Identity By TrustSec.

Step 2

Check the Enable Security Exchange Protocol check box to enable SXP. By default, SXP is disabled.

Step 3

(Optional; not recommended.) Enter the default local IP address for SXP connections. 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 syslog message. We recommend that you do not configure a default source IP address for SXP connections and allow the ASA to perform a route/ARP lookup to determine the source IP address for an SXP connection.

Step 4

(Optional.) Enter the default password for TCP MD5 authentication with SXP peers. By default, SXP connections do not have a password set.

Configure a default password if and only if you configure the SXP connection peers to use the default password. The password can be up to 80 characters. It is not encrypted.

Step 5

(Optional.) Change the time interval between ASA attempts to set up new SXP connections between SXP peers in the Retry Timer field.

The ASA continues to make connection attempts until a successful connection is made, waiting the retry interval before trying again after a failed attempt. You can specify a retry period from 0 to 64000 seconds. The default is 120 seconds. If you specify 0 seconds, the ASA does not try to connect to SXP peers.

We recommend that you configure the retry timer to a different value from its SXP peer devices.

Step 6

(Optional.) Change the reconcile timer value.

After an SXP peer terminates its SXP connection, the ASA starts a hold down timer. If an SXP peer connects while the hold down timer is running, the ASA starts the reconciliation timer; then, the ASA updates the SXP mapping database to learn the latest mappings.

When the reconciliation timer expires, the ASA scans the SXP mapping database to identify stale mapping entries (which were learned in a previous connection session). The ASA marks these connections as obsolete. When the reconciliation timer expires, the ASA removes the obsolete entries from the SXP mapping database.

You can specify a reconciliation period from 1 to 64000 seconds. The default is 120 seconds.

Step 7

(Optional.) In Network Map, configure the depth of IPv4 subnet expansion when acting as a speaker to peers that use SXPv2 or lower.

If a peer uses SXPv2 or lower, the peer cannot understand SGT to subnet bindings. The ASA can expand the IPv4 subnet bindings to individual host bindings (IPv6 bindings are not expanded). This command specifies the maximum number of host bindings that can be generated from a subnet binding.

You can specify the maximum number to be from 0 to 65535. The default is 0, which means that subnet bindings are not expanded to host bindings.

Step 8

Click Apply to save the changes to the running configuration.

Add an SXP Connection Peer

To add an SXP connection peer, perform the following steps:

Procedure

Step 1

Choose Configuration > Firewall > Identity By TrustSec.

Step 2

Click Addto display the Add Connection dialog box.

Step 3

Enter the IPv4 or IPv6 address of the SXP peer. The peer IP address must be reachable from the ASA outgoing interface.

Step 4

Indicate whether or not to use the authentication key for the SXP connection by choosing one of the following values:

  • Default—Use the default password configured for SXP connections.

  • None—Do not use a password for the SXP connection.

Step 5

(Optional) Specify the mode of the SXP connection by choosing one of the following values:

  • Local—Use the local SXP device.

  • Peer—Use the peer SXP device.

Step 6

Specify whether the ASA functions as a Speaker or Listener for the SXP connection:

  • Speaker—The ASA can forward IP-SGT mapping to upstream devices.

  • Listener—The ASA can receive IP-SGT mapping from downstream devices.

Step 7

(Optional) Click Advanced and enter the local IPv4 or IPv6 address of the SXP connection.

The ASA uses a route lookup to determine the right interface. If you specify an address, it must match the route lookup interface address of the outbound interface. We recommend that you do not configure a source IP address for an SXP connection and allow the ASA to perform a route/ARP lookup to determine the source IP address for the SXP connection.

Step 8

Click OK.

Step 9

Click Apply to save your settings to the running configuration.

Refresh Environment Data

The ASA downloads environment data from the ISE, which includes the Security Group Tag (SGT) name table. The ASA automatically refreshes its environment data that is obtained from the ISE when you complete the following tasks on the ASA:

  • Configure a AAA server to communicate with the ISE.

  • Import a PAC file from the ISE.

  • Identify the AAA server group that the ASA will use to retrieve Cisco TrustSec environment data.

Normally, you do not need to manually refresh the environment data from the ISE; however, security groups can change on the ISE. These changes are not reflected on the ASA until you refresh the data in the ASA security group table, so refresh the data on the ASA to make sure that any security group changes made on the ISE are reflected on the ASA.


Note

We recommend that you schedule policy configuration changes on the ISE and the manual data refresh on the ASA during a maintenance window. Handling policy configuration changes in this way maximizes the chances of security group names getting resolved and security policies becoming active immediately on the ASA.

To refresh the environment data, perform the following steps:

Procedure

Step 1

Choose Configuration > Firewall > Identity By TrustSec.

Step 2

Click Refresh Environment > Data in the Server Group Setup area.

The ASA refreshes the Cisco TrustSec environment data from the ISE and resets the reconcile timer to the configured default value.

Configure the Security Policy

You can incorporate Cisco TrustSec policy in many ASA features. Any feature that uses extended ACLs (unless listed in this chapter as unsupported) can take advantage of Cisco TrustSec. You can add security group arguments to extended ACLs, as well as traditional network-based parameters.

For example, an access rule permits or denies traffic on an interface using network information. With Cisco TrustSec, you can control access based on security group. For example, you could create an access rule for sample_securitygroup1 10.0.0.0 255.0.0.0, meaning the security group could have any IP address on subnet 10.0.0.0/8.

You can configure security policies based on combinations of security group names (servers, users, unmanaged devices, and so on), user-based attributes, and traditional IP-address-based objects (IP address, Active Directory object, and FQDN). Security group membership can extend beyond roles to include device and location attributes and is independent of user group membership.

Configure Layer 2 Security Group Tagging Imposition

Cisco TrustSec identifies and authenticates each network user and resource and assigns a 16-bit number called a Security Group Tag (SGT). This identifier is in turn propagated between network hops, which allows any intermediary devices such as ASAs, switches, and routers to enforce polices based on this identity tag.

SGT plus Ethernet Tagging, also called Layer 2 SGT Imposition, enables the ASA to send and receive security group tags on Ethernet interfaces using Cisco proprietary Ethernet framing (EtherType 0x8909), which allows the insertion of source security group tags into plain-text Ethernet frames. The ASA inserts security group tags on the outgoing packet and processes security group tags on the incoming packet, based on a manual per-interface configuration. This feature allows inline hop-by-hop propagation of endpoint identity across network devices and provides seamless Layer 2 SGT Imposition between each hop.

The following figure shows a typical example of Layer 2 SGT Imposition.

Figure 3. Layer 2 SGT Imposition

Usage Scenarios

The following table describes the expected behavior for ingress traffic when configuring this feature.

Table 1. Ingress Traffic

Interface Configuration

Tagged Packet Received

Untagged Packet Received

No command is issued.

Packet is dropped.

SGT value is from the IP-SGT Manager.

The cts manual command is issued.

SGT value is from the IP-SGT Manager.

SGT value is from the IP-SGT Manager.

The cts manual command and the policy static sgt sgt_number command are both issued.

SGT value is from the policy static sgt sgt_number command.

SGT value is from the policy static sgt sgt_number command.

The cts manual command and the policy static sgt sgt_number trusted command are both issued.

SGT value is from the inline SGT in the packet.

SGT value is from the policy static sgt sgt_number command.


Note

If there is no matched IP-SGT mapping from the IP-SGT Manager, then a reserved SGT value of “0x0” for “Unknown” is used.

The following table describes the expected behavior for egress traffic when configuring this feature.

Table 2. Egress Traffic

Interface Configuration

Tagged or Untagged Packet Sent

No command is issued.

Untagged

The cts manual command is issued.

Tagged

The cts manual command and the propagate sgt command are both issued.

Tagged

The cts manual command and the no propagate sgt command are both issued.

Untagged

The following table describes the expected behavior for to-the-box and from-the-box traffic when configuring this feature.

Table 3. To-the-box and From-the-box Traffic

Interface Configuration

Tagged or Untagged Packet Received

No command is issued on the ingress interface for to-the-box traffic.

Packet is dropped.

The cts manual command is issued on the ingress interface for to-the-box traffic.

Packet is accepted, but there is no policy enforcement or SGT propagation.

The cts manual command is not issued or the cts manual command and no propagate sgt command are both issued on the egress interface for from-the-box traffic.

Untagged packet is sent, but there is no policy enforcement. The SGT number is from the IP-SGT Manager.

The cts manual command is issued or the cts manual command and the propagate sgt command are both issued on the egress interface for from-the-box traffic.

Tagged packet is sent. The SGT number is from the IP-SGT Manager.


Note

If there is no matched IP-SGT mapping from the IP-SGT Manager, then a reserved SGT value of “0x0” for “Unknown” is used.

Configure a Security Group Tag on an Interface

To configure a security group tag on an interface, perform the following steps:

Procedure
Step 1

Choose one of the following options:

  • Configuration > Device Setup > Interfaces> Add Interface > Advanced

  • Configuration > Device Setup > Interfaces > Add Redundant Interface > Advanced

  • Configuration > Device Setup > Interfaces > Add Ethernet Interface > Advanced

Step 2

Check the Enable secure group tagging for Cisco TrustSec check box.

Step 3

Check the Tag egress packets with service group tags check box.

Step 4

Check the Add a static secure group tag to all ingress packets check box.

Step 5

Enter a secure group tag number. Valid values range from 2 - 65519.

Step 6

Check the This is a trusted interface. Do not override existing secure group tags check box.

Step 7

Click OK to save your settings.

Configure IP-SGT Bindings Manually

To configure IP-SGT bindings manually, perform the following steps:

Procedure
Step 1

Choose Configuration > Firewall Identity by TrustSec.

Step 2

Click Add in the SGT Map Setup area, or select an SGT map and click Edit.

Step 3

In the SGT Map dialog box, enter the SGT Map IP address and the SGT value in the appropriate fields.

SGT numbers can be from 2 to 65519.

To map a network to an SGT, select the Prefix check box and enter the subnet or IPv6 prefix. For example, enter 24 to map 10.100.10.0/24.

Step 4

Click OK, then click Apply to save your settings.

AnyConnect VPN Support for Cisco TrustSec

ASA supports security group tagging of VPN sessions. You can assign a Security Group Tag (SGT) to a VPN session using an external AAA server, or by configuring a security group tag for a local user or for a VPN group policy. This tag can then be propagated through the Cisco TrustSec system over Layer 2 Ethernet. Security group tags are useful on group policies and for local users when the AAA server cannot provide an SGT.

Following is the typical process for assigning an SGT to a VPN user:

  1. A user connects to a remote access VPN that uses a AAA server group containing ISE servers.

  2. The ASA requests AAA information from ISE, which might include an SGT.  The ASA also assigns an IP address for the user’s tunneled traffic.

  3. The ASA uses AAA information to authenticate the user and creates a tunnel.

  4. The ASA uses the SGT from AAA information and the assigned IP address to add an SGT in the Layer 2 header.

  5. Packets that include the SGT are passed to the next peer device in the Cisco TrustSec network.

If there is no SGT in the attributes from the AAA server to assign to a VPN user, then the ASA uses the SGT in the group policy. If there is no SGT in the group policy, then tag 0x0 is assigned.


Note

You can also use ISE for policy enforcement using ISE Change of Authorization (CoA). For information on how to configure policy enforcement, see the VPN configuration guide.

Add an SGT to Remote Access VPN Group Policies and Local Users

To configure an SGT attribute on remote access VPN group policies, or on the VPN policy for a user defined in the LOCAL user database, perform the following steps.

There is no default SGT for group policies or local users.

Procedure

Step 1

To configure an SGT on a remote access VPN group policy:

  1. Choose Configuration > Remote Access VPN > Network (Client) Access > Group Policies.

  2. Click the General tab, then click More Options.

  3. Enter a value in the Security Group Tag (STG) field, from 2 to 65519.

    You can also select None to set no SGT.

  4. Click OK.

Step 2

To configure an SGT on for a user in the LOCAL database:

  1. Choose Configuration > Remote Access VPN > AAA/Local Users > Local Users.

  2. Select a user, then click Edit.

  3. Click VPN Policy.

  4. Enter a value in the Security Group Tag (STG) field, from 2 to 65519.

    You can also select None to set no SGT.

  5. Click OK.

Monitoring Cisco TrustSec

See the following screens for monitoring Cisco TrustSec:

  • Monitoring > Properties > Identity By TrustSec > SXP Connections

    Shows the configured default values for the Cisco TrustSec infrastructure and the SXP commands.

  • Monitoring > Properties > Connections

    Filters the IP address-security group table mapping entries so that you view the data by security group table value, security group name, or IP address.

  • Monitoring > Properties > Identity By TrustSec > Environment Data

    Shows the Cisco TrustSec environment information contained in the security group table on the ASA.

  • Monitoring > Properties > Identity By TrustSec > IP Mapping

    Filters the IP address-security group table mapping entries so that you view the data by security group table value, security group name, or IP address. Click Where Used to show where the selected security group object is used in an ACL or nested in another security group object.

  • Monitoring > Properties > Identity By TrustSec > PAC

    Shows information about the PAC file imported into the ASA from the ISE and includes a warning message when the PAC file has expired or is within 30 days of expiration.

History for Cisco TrustSec

Table 4. History for Cisco TrustSec

Feature Name

Platform Releases

Description

Cisco TrustSec

9.0(1)

Cisco TrustSec provides access control that builds on an existing identity-aware infrastructure to ensure data confidentiality between network devices and integrate security access services on one platform. In the Cisco TrustSec feature, enforcement devices use a combination of user attributes and endpoint attributes to make role-based and identity-based access control decisions.

In this release, the ASA integrates with Cisco TrustSec to provide security group-based policy enforcement. Access policies within the Cisco TrustSec domain are topology-independent, based on the roles of source and destination devices rather than on network IP addresses.

The ASA can use Cisco TrustSec for other types of security group-based policies, such as application inspection; for example, you can configure a class map that includes an access policy based on a security group.

We introduced or modified the following screens:

Configuration > Firewall > Identity By TrustSec
Configuration > Firewall > Objects > Security Groups Object Groups
Configuration > Firewall > Access Rules > Add Access Rules
Monitoring > Properties > Identity By Tag.

Layer 2 Security Group Tag Imposition

9.3(1)

You can now use security group tagging combined with Ethernet tagging to enforce policies. SGT plus Ethernet Tagging, also called Layer 2 SGT Imposition, enables the ASA to send and receive security group tags on Ethernet interfaces using Cisco proprietary Ethernet framing (EtherType 0x8909), which allows the insertion of source security group tags into plain-text Ethernet frames.

We modified the following screens:

Configuration > Device Setup > Interfaces > Add Interface > Advanced
Configuration > Device Setup > Interfaces > Add Redundant Interface > Advanced
Configuration > Device Setup > Add Ethernet Interface > Advanced.

Cisco Trustsec support for Security Exchange Protocol (SXP) version 3.

9.6(1)

Cisco Trustsec on ASA now implements SXPv3, which enables SGT-to-subnet bindings, which are more efficient than host bindings.

We modified the following screens: Configuration > Firewall > Identity By TrustSec and the SGT Map Setup dialog boxes.

Trustsec SXP connection configurable delete hold down timer

9.8(3)

The default SXP connection hold down timer is 120 seconds. You can now configure this timer, between 120 to 64000 seconds.

New/Modified commands: cts sxp delete-hold-down period , show cts sxp connection brief , show cts sxp connections

No ASDM support.