In this blog post, we're going to go over the configuration of TrustSec in ISE 2.1. This configuration also applies to ISE 2.0 as well for the most part. While TrustSec is not a required configuration for a secure ISE deployment, it definitely has some great advantages. It's a security architecture utilizing security group tags (SGTs) that allows that network to enforce access control policy, reduce ACL complexity, and can be utilized for policy in other security devices which I will go into further in later blog posts when I go over pxGrid on different systems.
I am going to break down the different components of TrustSec:
- Network Access Device (NAD) - This is the network device the endpoint connects to. Endpoint Admission Control (EAC) happens when the device connects and after authentication and authorization, the EAC process assigns an SGT to the user or device. EAC can use 802.1X , MAB and WebAuth as access methods for authentication and authorization
- Security Group (SG) - Groups of users, endpoints, and resources that share access control policies and are defined in ISE.
- Security Group Tags (SGT) - Each security group has it's own unique 16-bit security group number within a TrustSec domain. The numbers are automatically generated when you create a named SGT in ISE.
- Security Group Access Control List (SGACL) - Allows control for the access and permissions based on the SGTs assigned.
- Security Exchange Protocol (SXP) - Protocol developed for TrustSec service to propagate IP-SGT bindings across network devices that do not have SGT-capable hardware that supports SGT/SGACL
- Environment Data Download - TrustSec devices get the environment data from ISE when it first joins the trusted domain. The data could also be manually configured on the device. The environment data is refreshed before it expires and it obtains the following information: servers that the client can use for future RADIUS requests, security group that the network device itself belongs to, and the interval of how often the TrustSec device should download or refresh its environment data
- Identity-to-Port Mapping - Method for switches to define the identity on a port which an endpoint is connected and use this identity to look for an SGT value on ISE.
Let's dig into TrustSec a little bit more to understand what we're getting out of this architecture and why we would use it. The purpose is to establish secured networks based on identity and device information and that can be dynamic - regardless of subnet, location, or MAC address. Based on the policy, identity and device information, packets are tagged with a SGT upon ingress and policy can be built either in ISE or in other devices that share contextual information with ISE. This can reduce ACL complexity, simplify policy across platforms and grant a more cohesive security posture.
For example, lets say you have 100 sites with 3 subnets per site and you needed to write rules on a firewall to get really granular on what can communicate to what. You could object groups to make it look easier:
object-group network denied
network-object host 10.1.1.4
network-object host 10.1.1.78
network-object host 10.1.1.89
object-group network web
network-object host 209.165.201.29
network-object host 209.165.201.16
network-object host 209.165.201.78
access-list ACL_IN extended deny tcp object-group denied object-group web eq www
access-list ACL_IN extended permit ip any any
While that looks neater for the human eye, the IOS actually breaks it out when processing the ACL so internally, you will actually really have the ASA processing this:
access-list ACL_IN extended deny tcp host 10.1.1.4 host 209.165.201.29 eq www
access-list ACL_IN extended deny tcp host 10.1.1.78 host 209.165.201.29 eq www
access-list ACL_IN extended deny tcp host 10.1.1.89 host 209.165.201.29 eq www
access-list ACL_IN extended deny tcp host 10.1.1.4 host 209.165.201.16 eq www
access-list ACL_IN extended deny tcp host 10.1.1.78 host 209.165.201.16 eq www
access-list ACL_IN extended deny tcp host 10.1.1.89 host 209.165.201.16 eq www
access-list ACL_IN extended deny tcp host 10.1.1.4 host 209.165.201.78 eq www
access-list ACL_IN extended deny tcp host 10.1.1.78 host 209.165.201.78 eq www
access-list ACL_IN extended deny tcp host 10.1.1.89 host 209.165.201.78 eq www
While this is a rather simple example, depending on the size of the object groups or the ACL, it could get pretty long and resource intensive - even for the larger firewalls. Not to mention that if your company is changing (add/removing subnets), there's a lot of potential manual configuration or the potential of config bloat if subnets aren't removed that should be.
With SGTs, one could potentially remove subnets from the ACL altogether and as long as the packets were tagged and the ASA knew the destination SGT mapping (we will get to that later), it could make a decision based on the tag, not the subnet or IP. So the same ACL above would look something like this for both the human eye and the internal ASA:
access-list ACL_IN deny tcp security-group name DENIED-SGT any security-group name WEB-SGT any eq www
You can also create the SGACL above using the tag number instead of the name but I think using the names can make it eaiser to read and logically understand. Since the ASA is waiting for the tag information, it's not worrying about subnet or requiring manual updates to add IP addresses or subnets to object groups.
Utilizing TrustSec, you can also utilize it to replace your dACLs with SGACLs instead. When the packet is tagged in ingress, the infrastructure devices will be able to download the SGACL that applies to the source and destination tags and enforce policy. If a device's policy needs to change (i.e. fails posture, user logs out, etc), the SGTs that are tagged on the packets would change and
Outside of ACLs, the SGTs can be used to apply policy on other appliances as well. For example, with pxGrid integration, SGT information can be shared with a WSA, Firepower, StealthWatch, etc. For example:
On Firepower, you could create rules in your access policy based on the source SGT or device type as shared by ISE instead of source subnet or AD group since policy might change for a user depending on a change in posture:
On the WSA, you could create you Access Policies based on SGT so if you have SGTs for Admin, Employee, Guest, Non-Compliant, and Quarantined_Systems, you might want to allow different levels of access based on those:
For the above examples, if the SGT changes for any reason - i.e device is quarantined or determined to be non-compliant - the user's access changes dynamically on the security appliances as well since it's not limited to just the user's IP address or AD group anymore.
On StealthWatch, Netflow can sent SGT information on certain platforms and those flows can be searched by subject or peer SGT in the Flow Query and in the flow information, one can see the SGT tags as well:
These aren't the only devices that SGTs can be used to search or define policy. Click here to see the entire growing list of ISE ecosystem partners.
Now I'm going to move onto the different configuration options and information in ISE. Navigating to Work Centers>TrustSec>Overview, you can see the overview of what needs to be configured for TrustSec:
Clicking on Dashboard, you can view the SGT dashboard which is useful for administration and troubleshooting:
In order to utilize TrustSec, I'm going to make sure that my ISE nodes has the SXP service running. Navigate to Administration>System>Deployment and click on the ISE hostname and save when completed:
We're going to follow the overview instructions to set this up in ISE.
Prepare:
TrustSec AAA Servers -
This is where you add the AAA servers that will be used for TrustSec. If you have a standalone deployment, your existing ISE server should be in here
You may click Add if you would manually like to add more AAA servers:
Network Devices
Next we will configure the NADs. On this page, click the name of the NAD one-by-one to configure for TrustSec:
Check the box next to Advanced TrustSec Settings:
Some of the different settings detailed here:
- Use Device ID for TrustSec Identification - Checking this uses the Device Name listed as the identifier in the Device ID field
- Device ID - Use the Device Name as a logical identifier
- Password - Password to authenticate the TrustSec device. Must be the same password you've configured on the command-line interface for cts credentials
- Download data and re-authentication settings - I usually leave these at the default
- Other TrustSec Devices to Trust This Device (TrustSec Trusted) - Check box if you want peer devices to trust this device. If this remains unchecked, the peer devices don't trust it and all packets arriving from this device will be colored or tagged accordingly
- Send Configuration Changes to Device - Check if you want ISE to send TrustSec CoA notifications to the device
- Include this device when deploying Security Group Tag Mapping Updates - only check this box if you want the TrustSec device to obtain the IP-SGT mappings using device interface credentials.
Ignore the Out Of Band (OOB) TrustSec PAC unless you're configuring an ASA. In that case, you would want to generate the PAC and download it:
General Trustsec settings
In this menu, you can configure the general settings for TrustSec:
These settings include:
- Tunnel PAC Time to Live - Expiry time for PAC which generates the tunnel for the EAP-FAST protocol
- Proactive PAC Update Will Occur After - ISE will provide new PAC to the client after successful authentication when a configured percentage of the Tunnel PAC TTL remains
- System Will Assign SGT Numbers + Except Numbers in Range + User Must Enter SGT Numbers Manually - Choose whether or not all SGT numbers will be automatically generated by ISE and if a range can be configured manually
- Security Group Tag Numbering for APIC EPGs - Check box and specify range of numbers to be used for SGTs created based on EPGs learned from APIC
- Auto Create Security Groups When Creating Authorization Rules - Check box to create SGTs automatically while creating authorization policy rules. Auto-created SGTs are named based on rule attributes.
- SGT Number Range for Auto-Creation - Check box and specify range of numbers to be used for the auto-created SGTs
- Automatic Naming Options - Options to define naming convention for auto-created SGTs
Workflow process
This is a new feature in ISE 2.1 that helps you test a new policy on a limited set of devices using a staging matrix before deploying it to the rest of the network devices. This gives you the option to stage your policies a bit better than just deploying them if you have an existing brownfield deployment or would like to test new policies on a subset of devices
Define:
Security Groups
This is where we would create the security groups and the system will assign an SGT number. By default, there should already be some existing groups:
For the sake of keeping the complexity down, I would recommend keeping your security groups as basic as possible. While it might be tempting to create groups for every department in your company or type of device, I would recommend grouping everything together based on how you will be assigning policies in ISE. To keep it simple, I'm going to delete a lot of my SGTs and usethe following:
Network device authorization
This is where we will assign a SGT to the actual TrustSec Network Access Devices themselves. To keep it simple, I inserted a rule above the default and defined the condition as any device where the location matches the Security Lab location, then assign the TrustSec_Devices tag.
Define the SGACLs
This is where you configure the SGACLs that will be later used in your policy. Click Add to start creating the SGACLs:
The SGACL's syntax is a little different that what you're used to in dACLs. They are written without SGT tags or IPs defined:
permit | deny [ ip | tcp | udp | icmp] {dst eq <port-num>}
I'm going to create the following SGACLs:
Trustsec matrix
The TrustSec matrix is where we can easily apply the SGACLs and contains two axis - the source axis and destination axis:
By clicking on the cell, you can add a SGACL and it will basically read from source (right) to destination (top). If you previously enabled the Workflow process, it'll change you to the Staging Matrix when you go to edit a cell.
First, click on the pencil in the cell:
From the pop-up, choose from an SGACL you previously created or click on the gear to create a new SGACL:
If you would like to choose simply deny ip or permit ip, you could change the final catch all rule in the field instead:
Continue to populate the TrustSec matrix until you have all the permissions set as it makes sense for your policy. With the SGACLs you created before, you're basically inserting them between the source and the destination in the matrix so when you see the following:
It's the equivalent of allowing Admin SGTs are permitted to communicate with Admin SGTs but Admin SGTs denied to BYOD SGTs.
If you've configured workflows and you've finished adding your SGACLs to the matrix, click on Workflow at the top and choose Select Network Devices
On the pop-up, you can choose which network devices to apply this config to if you want to test only a small subset of devices before rolling it out to the rest of the network or phase your deployment:
For my lab, I'm going to go ahead and just push this out to all devices and submit for approval. Your approver would login and submit the following approval:
After the requestor deploys it, the approver can set the workflow as production and it will move this workflow from the staging matrix to the production matrix.
SXP
As previously mentioned, Security Group Tag (SGT) Exchange Protocol (SXP) is used to propagate the SGTs across network devices that don't have hardware support for TrustSec to devices that are SGT-aware. SXP uses TCP to set up the connection between the two separate devices and there are two roles that SXP assigns a device:
- SXP Speakers - Peer that sens the IP-SGT mappings over the SXP connection
- SXP Listener - Peer that receives IP-SGT mappings over the SXP connection
Some newer devices such are capable of bidirectional mode where they both act as speaker and listener. Starting in ISE 2.0 and above, ISE could be configured as a SXP peer and propagate the IP-SGT bindings instead of directly peering the networking devices. Tagging the SGTs on the packets requires hardware support for it so while a device may have software support but not hardware support, SXP can pass this IP-SGT mapping from that non-hardware supported device to the next hardware supported device that will tag the packets once it receives it.
On the SXP Devices page, click Add to add a new SGT device:
In the above window, you fill in the following:
- Name of the peer device
- IP address of the peer
- Peer Role - this could be speaker, listener, or both
- Connected PSN that will be forming the SXP connection
- SXP domain - session bindings are always propagated on the default domain
- Whether the status of this SXP connection is enabled or disabled
- Password type - can choose a global default password you configure in settings, none or custom which you would enter below
- Version of SXP - There are currently 4 versions of SXP
- v1 - Supports IPv6 bindings
- v2 - Supports IPv4 and IPv6 bindings
- v3 - Supports IPv4and IPv6 bindings and subnet binding expansion
- v4 - Supports IPv4 and IPv6 bindings, subnet binding expansion, loop detection, SXP capability exchange and bidirectional support
Under the Advanced Settings for the SXP device, you can configure the minimum acceptable hold time in which a speaker will send keepalive messages for keeping the connection alive and the keep alive timer which is used by a speaker to trigger the dispatch of keepalive messages. I don't usually modify these and keep them at the default.
After you've entered your device information, click Save. If you peer device is configured for an SXP connection, you'll see the connection as on. I'll go into configuring the peer devices in another blog post.
Go Live & Monitor:
Adjusting Authorization Policies
Even with the SGT matrix fully populated, ISE still needs to know what to assign which tag to. Navigate to your Policy Sets in ISE and replace or add the Security Group of choice under the Permissions. You may add it on top of an authorization profile you previously configured or you may replace it depending on what you choose for your deployment.
pushing the policy
After you're done configuring your policy and SXP connections, you can click the Deploy button on the Production Matrix to push this policy:
After this is done, you can view the SGT sessions in the dashboard I previously mentioned above and if you choose, you can also create reports based on TrustSec: