SISE (300-715) | TrustSec / by MBNE

What is TrustSec?

TrustSec is Cisco's policy-defined segmentation solution, which has a primary goal of simplifying the classification of different types of endpoints on the network, so that consistent segmentation policies can be enforced across intra and internetwork domains. It was formerly known as Security Group Access (SGA).

The goal of TrustSec is to assign a tag known as a Security Group Tag (SGT) to endpoint traffic flows at ingress, then enforce access control elsewhere on the network based on this tag. The enforcement can happen at the egress of the first SGT-enabled device or at the destination network device that is directly attached to the intended recipient for the traffic, depending on the scope and design of the TrustSec domain.

What is Segmentation?

You are likely already familiar with segmentation, even if you don't use the term on a regular basis when you discuss enterprise networks and security concepts. You may be used to traditional segmentation methods, using things like VLANs, VRFs or ACLs. These are typically configured on a hop-by-hop basis across your network infrastructure, in order to segment different traffic flows based on your security requirements.

TrustSec also performs logical segmentation, but using the concept of SGTs. The difference with SGTs is that these segmentation policies are centrally configured on Cisco ISE and pushed out to the network as TrustSec policy. This is a more flexible and manageable way to segment the network than individually touching the CLI or GUI of tens or even hundreds of network devices whenever your organisation has a new VLAN or ACL change it wants to roll out across the network.

SGTs should be generally configured with bulk access control in mind - we use a term called Macro Segmentation to define at a high level which groups of users or devices should be segmented. If we wish to fine-tune the access permissions within the policies themselves, we can write specific rules that permit or deny individual types of traffic - we can think of this as Micro Segmentation.

It's important to understand that we are not using traditional constructs, like IP addresses or MAC addresses, to identify the endpoint. We are dispensing with these in favour of SGTs in the context of classifying endpoints. That is the key component of the TrustSec solution that makes it as scalable as it is. With SGTs, we can now use the power of Cisco ISE profiling, posture assessment, the 802.1X NAC framework, PKI and other advanced ISE features to help classify many types of endpoints, wherever they choose to connect - wired, wireless or VPN. With such a high degree of visibility, we can be sure that the endpoint is valid, and security policy is applied consistently.

So, at a basic level, we use TrustSec to simplify our segmentation strategy, enforce segmentation policies consistently and we achieve this with the concept of a Security Group Tag.

What are Security Group Tags?

A Security Group Tag is a 16-bit value assigned to a user or endpoint Layer 2 frames when logging into the network, by Cisco ISE and the registered Network Access Devices. This tag is assigned dynamically or statically to all traffic in that session and is used to enforce security policy in a consistent manner. The SGT can represent the result of a simple or sophisticated authorisation policy that takes into consideration the context of an endpoint or user, making full use of the advanced features of Cisco ISE. For example, we may utilise functions such a profiling the endpoint, performing a posture assessment, completing certificate validation and other important mechanisms to verify the identity of an endpoint, using a defence-in-depth approach.

When a given user and/or endpoint meeting the authorisation policy requirements, we assign the SGT to it, to provide the permissions required. SGTs are not known to the endpoint itself, but are considered attributes used by the network infrastructure used to ensure TrustSec-enabled traffic flows are treated according to your organisational security policy.

SGTs should represent an overarching role or function within an organisation. An SGT could be applied to a GUEST user or to BYOD endpoints, for example. Some common Security Groups exist, which can be used to build TrustSec policy including:

  • Network Infrastructure - SGTs are assigned to your switches, routers, WLCs and firewalls, which ensures that your management traffic is not impacted by SGT enforcement.
  • Network Services - SGTs are assigned to specific servers or infrastructure which provide common network services such DNS, DHCP or NTP.
  • Organisational / Departmental - SGTs are assigned to groups of employees within an organisation such as HR, Finance, Sales or Executives who may require differentiated access to specific servers, data or other resources that you wish to secure.
  • Business Units - SGTs are applied to business units, so that they may not be permitted to communicate with each other on the network.

These Security Groups are defined on Cisco ISE in order to lay the foundations for SGT-based network segmentation. Now we know what they are for from a high-level, let's try to understand what we can do with them.

What is the use case for TrustSec?

To understand the use case for TrustSec, let's split it into a few parts:

  • First, we will briefly detail what the challenges are with traditional segmentation and legacy network access control policy enforcement.
  • Then, we'll define Segmentation Basics so we can compare the different segmentation options.
  • Finally, we'll review the TrustSec policy framework and how it addresses these challenges.

By the end of this section, hopefully it will be clear what TrustSec is used for and how it might help address some of the challenges you may already face on the networks you manage day to day.

Traditional Network Access Control

As we touched on earlier, you are likely already familiar with some traditional access control constructs like VLANs, VRFs and ACLs. For a long time, we have used methods of controlling network access based on the context of a user or device, such as:

  • VLAN Assignment - We put users or devices into VLANS, and we restrict access at the L3 edge. You see this a lot with multilayer switches with ACLs applied to VLAN SVIs - this way, we can control what traffic is allowed to ingress or egress the VLAN. This needs to be configured on each network segment. This is virtual segmentation at Layer 2 of the OSI model.
  • VRFs - This is where we use separate logical routing domains, called Virtual Routing and Forwarding instances in order to logically separate traffic. Your traffic can be forwarded within a given VRF instance only if your routing policy applies within that VRF. You typically need to configure this on a hop-by-hp basis. This is virtual segmentation at Layer 3 of the OSI model.
  • ACLs/dACLS - ACLs are normally manually configured at ingress or egress from a subnet to control access in both directions. Alternatively, downloadable ACLs can be delivered to a switch (NAD) from ISE as part of an authorization policy.

There are others that you may be aware of, such as Firewall Contexts. Ingress access control has worked well for a long time, but it does pose some challenges in modern networks.

To describe the challenge with access control based on VLAN Assignment, let's think about how we traditionally break up our networks. We normally do VLAN assignment based on the context of a user or device. We want to keep IP Phones separate from desktops, separate from printers and so on. Thus, we go ahead and assign unique VLANs and subnets for IP Phones, Servers, Printers, Cameras, Guest users and many other groups of users requiring differentiated access control policies. We also have to do this at every Policy Enforcement Point (to use a better term). In other words, every large office or branch site you have which has segmentation enforced with a static VLAN configuration in place needs to be individually managed.

We typically need to control access to those VLANs as well - we can't have the Guest VLAN able to reach our Servers, can we. Restrictions for access to or from a given VLAN needs to be enforced somewhere, such as on a firewall or an access switch SVI. How do we do that traditionally? Well we use ACLs. Each and every change to your business requirements or segmentation strategy must be reflected in the associated firewall or ACL rules to maintain that security policy.

Got a new endpoint type that needs a new VLAN? Well, you are likely going to have to touch everything that will need to be permitted or denied access to this VLAN if you want to continue to enforce your segmentation policy using this construct. And of course, the larger the network, the more effort is required to maintain the security posture. As you can imagine, this can quickly become administratively difficult to maintain and this is where a need for a scalable solution starts to make sense.

There are many other challenges, but VLAN Assignment and ACL management are some of the clearest examples of where a different approach should help, which is where TrustSec fits into the story of network access control.

Segmentation Basics

Now we understand some of the challenges, let's think about segmentation options.

There are two ways to segment a modern network:

  • Physical Segmentation - This is where we create a separate network domain using separate interfaces, network appliances and choke points in the network. They are physically separate, and this is still popular in military grade or highly-secure networked systems that demand this for compliance or risk purposes.
  • Virtual Segmentation - We create logical segmentation with the use of VLANs, VRFs, Firewall Contexts, ACLs and even SGTs (which is Packet Level Segmentation). Virtual segmentation is very common because we can have many logically separate traffic flows existing on the same physical infrastructure simultaneously. It is the basis on converged networks and an important concept to understand.

Segmentation can be consider in the following terms:

  • Macro Segmentation - High level groupings of devices that typically share similar access permissions. For example, in an SD-Access deployment, we might have IOT devices in a distinct, separate VN from Campus Endpoints. We also might enforce general rules that say BYOD devices cannot talk to any other group of devices but they can access the internet
  • Micro Segmentation - Low level access control within a macro level segmentation domain. This is what we might do to prevent specific devices from communicating with each other (such as IOT devices communicating directly with other IoT devices or with the network infrastructure).

Segmentation can also be considered by the constructs that are used to define the segmentation policy itself:

  • Traditional Segmentation - Based on the network topology, with ACLs, VRFs, VLANs in place in a hop-by-hop design. This method uses IP Addresses and MAC Addresses as the Identity. As you have seen thus far, this is not particularly scalable and is difficult to manage in larger networks.
  • TrustSec Segmentation - Segmentation is performed at a Ethernet Frame level - traffic is classified at ingress when a user logs in, it's associated with a SGT added to the Layer 2 frame and this SGT is propagated and enforced across the TrustSec domain. It is topology independent and pervasive, regardless of factors such as client mobility. The correct access is enforced whether the user is in the Data Centre, HQ, Branch Office, or working at home.

TrustSec Policy Framework

The TrustSec policy-defined segmentation framework can be split into three general phases:

  • Classification - This is the phase where we assign SGTs to a given session based on the configured authorisation policy result on ISE. It can be done dynamically or statically.
  • Propagation/Transport - This is how TrustSec-enabled networks propagate SGT information - it can be done natively/in-line or with a peering protocol called Security Group Tag Exchange Protocol or SXP.
  • Enforcement - This is the phase where the enforcement of policy is applied on the network - it can be done directly on the switching infrastructure with SGACLs or with a dedicated appliance using a SGFW.

When all three phases are configured appropriately, a TrustSec Policy Matrix is used on ISE to build the policy needs between different SGTs. This allows macro and micro segmentation to be enforced on those SGTs, no matter where there appear in the network - Wired, Wireless or VPN connections.

What's the big benefit? Scalable, centralised management of network access control configured on ISE and deployed to the network, independent of IP subnet and MAC address identity. More importantly, no need to update dozens of devices hop by hop with your new VLANs, ACLs or other configurations - let ISE deliver it for you by enforcing SGTs along with your authorisations for every endpoint.

Now that we have a good understanding of the use case, and why we might consider using TrustSec, let's dive a bit deeper and look at this TrustSec components more carefully.

What protocols and components are involved in TrustSec?

TrustSec has a number of physical and logical components in play which work together to deliver policy-based segmentation - we can loosely group these as Cisco ISE Configurations and Network Access Device Configurations.

Cisco ISE Configurations

  • Cisco ISE - Your one stop shop for all things TrustSec. You configure your authentication and authorisation policies on ISE, including your SGTs as Results. You also setup your TrustSec-enabled NADs, create SGTs, SGACLs and the Policy Matrix (or matrices) on ISE.
    • SGTs - These are the groupings of endpoints, users, lines of business or otherwise that form the building blocks of your macro segmentation strategy.
    • SGACLs - These are the micro segmentation rules that provide for granular control of your network access control policy.
    • Authorisation Policies - SGTs are delivered as Authorisation Policy Results - when an endpoint matches an authorisation policy, it is granted specific permissions and a corresponding SGT.
    • SXP - If we are using SXP peering to propagate SGTs through the network, SXP will need to be enabled on ISE for the NADs involved.

Network Access Device Configurations

  • Network Access Devices - NADs are your network switches, firewalls, wireless LAN controllers and other devices used to enforce TrustSec policy. Wherever you have NADs, you need to provide them some configuration from the outset so that they can perform the tasks at hand. Different NADs will have different configurations, and some planning is required based on the technical goals and constraints of your particular network device types and software versions. The good news is that most modern Cisco network devices support at least one method of deploying TrustSec and some third-party devices are supported, via Network Device Profiles. Other components that are integrated are:
  • 802.1X - You will likely be using 802.1X to control the access to your network, as well as perform certificate-based authentications which are used to classify traffic in the TrustSec model.
  • MAB - We may use MAB to perform non-802.1X authentication as part of the classification phase.
  • WebAuth - We may use WebAuth configuration to classify different types of traffic and assign SGTs.
  • Change of Authorisation - You will likely be using RADIUS CoA to perform dynamic authorisations of endpoints based on the known context of the device as it joins and interacts with your network.
  • IP Device Tracking - This is a key component of many deployments, providing ISE with IP-to-MAC bindings, and used with functions like Dynamic ACLs, WebAuth and TrustSec SGACLs.

How does TrustSec work?

As we touched on earlier, the TrustSec model falls into three phases:

  • Classification - Traffic ingresses into a network device and based on the identity, will be tagged with a specific SGT.
  • Transport/Propagation - As the traffic makes its way across the network, this SGT is propagated in the L2 Frame (using Cisco Metadata - CMD)
  • Enforcement - Policy is applied typically at the destination network device, ensuring that the traffic reaches only the destination permitted by the authorisation policy.

It's worth bearing in mind that some NADs can perform any or all of the phases of TrustSec enforcement, such as SGFW devices like the Cisco ASA.

Let's look at each phase more carefully so that we can understand how TrustSec actually works.

Classification

Classification is performed either dynamically (via 802.1X, MAB or Web Auth) or statically on the NADs (on a L3 interface, L2 interface, VLAN interface or using an IP address binding). Classification is performed on the ingress NAD where the L2 frame enters the TrustSec domain. Static bindings are normally performed on devices that do not or should not be authenticated, such as Data Centre servers, or non-authenticating endpoints such as printers, IoT devices or IP cameras.

Let's summarise some different classification methods that you can use to plan out your TrustSec design:

  • Dynamically assigning SGTs via 802.1X - With this method, an authenticating endpoint will be dynamically assigned the SGT by ISE alongside an authorisation profile result. The logic here is that you will get both your authorisation permissions and a corresponding SGT assigned at the same time. The TrustSec aware NADs will then use the assigned SGT to perform classification. If a specific NAD isn't part of the domain, the authorisation result still applies to the endpoint.
  • Manually assigning SGTs at the switchport - Manual assignment sounds more like the traditional method of manually configuring network devices, but in this case it is appropriate in specific network locations, like the Data Centre. Dynamic classification methods (802.1X, MAB or Web Auth) are not used here, typically, as the deployment is static and housed in a secure facility. The servers are still destinations for traffic coming from the TrustSec domain, and thus we will need to ensure that they are classified appropriately so that they can be referenced in policy.
  • Manually binding IP Addresses to SGTs on the NAD - With this method, you configure a list of IP addresses and their associated SGTs on ISE and make it downloadable - this is called a Security Group Mapping. The TrustSec-aware NADs can download that list from ISE and use it for TrustSec classification purposes. The use case for this method is when you have devices with static IPs or DNS names that will not change. The NAD needs to be capable of downloading the mapping
  • Statically Assigning Subnets or VLANs to SGTs - Most networks have some legacy or third-party NADs in them, which may not support the full TrustSec feature set. However, you can still make them TrustSec aware if the NAD can support the mapping of VLANs or Subnets to SGTs. A VLAN list or subnet is mapped statically to an SGT which is used to classify the traffic.

Transport/Propagation Basics

Propagation is done either in the data plane (native tagging/inline) or the control plane (using SXP). Both options have benefits and drawbacks that should be considered as you start to plan your TrustSec design.

Let's summarise the options for the transport or propagation of SGTs in the TrustSec domain first:

  • Data plane tagging - Tagging methods include Ethernet, MACSec, LISP/VXLAN, IPSec, DMVPN and GETVPN.
    • Benefits - This is the most scalable way to propagate SGTs. Is it enabled hop-by-hop on each device in the TrustSec domain, meaning a more involved initial setup is required. However, capable switches process this at line rate as the Layer 2 information is in the data plane. This also means there is no impact to other networking functionality such as QoS, IP MTU/fragmentation.
    • Caveats - The L2 overhead, however, is around 40 bytes (recommended 1600 bytes with 1552 bytes MTU) - this must be understood by inline devices. Cisco Nexus switches and Catalyst 6500/6800 require manual MTU adjustment to support this. Also, Layer 3 links must have both sides adjusted. If you have Port channels, then member links must be adjusted. Global config changes are required on Catalyst 3K/9K families to support the larger MTU. It also requires hardware/software support end to end. This is the trade-off for having virtually endless scalability but may still be valid for specific deployments or specific places in the network.
  • Control plane tagging - Tagging methods include SXP, SXP multi-hop and pxGrid.
    • Benefits - In this method, IP-to-SGT mapping data is shared over a TCP control protocol called SXP. This conveys an IP-to-SGT map of endpoints to enforcement points. There is no impact to data plane traffic and therefore you can accelerate deployments of SGTs using this method. You can also support single hop and multi-hop implementations, using common aggregation points and the SXP speaker and listener roles.
    • Caveats - The trade-off with this flexibility is that it requires additional configuration on the NADs, and a plan for the SXP roles defined.

SXP can also integrate with pxGrid so that pxGrid clients can subscribe to published SGT tables and bindings, as an alternative to SXP.

Now that we have a summary of the basics of SGT propagation, we can take a closer look at the two types.

Transport/Propagation - Native Tagging (Inline) Method

Native tagging is ideal from the networks point of view, because the L2 frame has the SGT applied directly and doesn't rely on any other constructs to understand which SGT is applied to a given flow. Each NAD simply sees the SGT in the Layer 2 frame at ingress and applies the same SGT on egress. The benefit of this is that it is entirely independent of the Layer 3 network, supports both IPv4 and IPv6 and the SGT can be carried anywhere in the network natively, so long as the infrastructure is configured to support it.

In other words, you can roll out end to end packet-based network segmentation at a local, regional or global level, and enforce policy anywhere, without traditional concerns about resource utilisation, because the SGTs are embedded natively in the traffic flows.

Chassis-Based Switches and Native Tagging

Certain types of Cisco switches, such as chassis-based switches, have some complexities to consider:

  • Topology - The location of the chassis switch in the network needs to be considered in terms of the hierarchical network design. If the chassis operates at the access layer, it will see SGT-enabled traffic arriving and leaving on different ports that it would expect to see if it was in the distribution layer or data centre.
  • Line Cards - Line Cards may or may not be SGT-capable or fully supported. There may be multiple line-cards with different capabilities in the same chassis which can cause issues maintaining the SGT tags, depending on the direction traffic flows through the chassis.

In order to plan for this, Cisco allows you to apply a specific role to the switch, which applies some logic to how the chassis should handle SGTs. This is known as the reflector mode. Put simply:

  • Ingress reflector mode should be used at the access layer - SGTs are applied on the egress from uplink ports only.
  • Egress reflector mode should be used at the distribution/DC - SGTs are seen on ingress and applied on egress.

Transport/Propagation - SXP Method

Using a control-plane protocol to peer with other TrustSec devices facilitates a faster rollout of TrustSec in your network. In order to do so, you need to define on ISE which NADs are SXP-enabled and you need to configure SXP on the NADs in either the speaker role or listener role. The idea is that a given network can have a SXP speaker which receives SGT mappings from ISE, and then distributes these mappings to any SXP listeners who are peered with it.

  • SXP Speaker - This NAD role will send IP-to-SGT bindings received from ISE to the listeners.
  • SXP Listener - This NAD role will receive IP-to-SGT bindings from the speaker, over SXP.

Communication between SXP peers happens over TCP, inferring that you can have a SXP peers that are adjacent at Layer 3, or several hops away. This is known as a SXP Multi-hop design and works exactly as the name suggests. As an example, you could have your aggregation switches in a large campus act as Speakers, and all other network devices downstream can peer with those aggregation switches to receive their SGT mappings. Following your already established network chokepoints, the SXP design can ideally be broken up into suitable blocks, ensuring that your IP-to-SGT mappings tables don't get too large. Just like routing protocols, the versatility of breaking up the network with speaker and listener roles makes the design very deterministic and reduces the amount of SXP chatter on the network as a result.

To configure SXP, you need to follow these general steps for all NADs:

  • Enable SXP globally on the NAD.
  • Configure a password for the SXP domain - this needs to be the same on all devices (think VTP).
  • Configure the SXP mode - either a local configuration or a peer configuration.
  • Configure the SXP role - either speaker or listener.

Enforcement

Enforcement is the final phase of the TrustSec model. It is applied the destination network device, before the traffic is forwarded to the destination interface. For most traffic types, the first packet has to get across the network in order to be enforced, therefore connections such as the TCP three-way handshake will not complete.

There are two types of enforcement methods:

  • SGACL - These are enforced using switches, and configured centrally on ISE.
  • SGFW - If your security design requires enforcement on a dedicated network device such as a firewall, you can perform enforcement there as well.

SGACLs

TrustSec enforcement with ACLs is configured on ISE using a policy matrix, with SGACLs applied to manage the security between a source SGT and a destination SGT. SGACLs do not contain IP address information; remember, we are not using IP addresses as the identity, therefore sources and destinations for the SGACLs are security groups, not subnets or hosts. This is a huge benefit and a plus for TrustSec - your SGACLs are configured and enforced centrally, without concern about the IP or MAC address of the endpoint.

TrustSec SGACL policy changes are propagated network wide with one click, due to the centralised policy engine of ISE. You simply make your policy change, hit Deploy, and ISE pushes the updated ACLs to your TrustSec-aware NADs.

When creating your SGACLs, you need to consider the segmentation of devices and the location of the enforcement relating to what you are trying to segment. For example, to segment guest traffic, you need to classify on ingress and ensure that classification is handled at your chosen enforcement point. If you use a central SGFW to perform enforcement (i.e. North/South) traffic flows, then this model works well. However, if you need to perform micro-segmentation within a Data Centre, you will need to ensure that your SGACLs are enforced locally on that switch, and make sure that the classifications for your source and destination endpoints are applied correctly.

SGFWs

NADs like the Cisco ASA are often deployed specifically to perform traffic filtering and segmentation, along with other features like Intrusion Prevention. The SGFW functionality can be enforced on both Cisco ASA and on Cisco ISR and ASR routers. The difference between the two options is that SGTs are enforced as part of a Zone-Based Firewall configuration on a router, and on the ASA, your firewall ACL ruleset can use SGTs as the source and destination, instead of traditional 5-tuples.

Just like switches, depending on the model of router you deploy as a SGFW, different TrustSec capabilities are supported for each of the classification, propagation and enforcement phases.

Multi-Domain Enforcement

TrustSec segmentation policies can be leveraged enterprise wide, with common policy groups in the data centre, campus and branch networks, and the cloud. This is done by using consistent security policy group schemas across different network solutions like Cisco SD-Access and Cisco ACI. With planning, the same security groups from your SD Access deployment in the campus can be used in your ACI policy in the data centre, and vice versa. This allows for a seamless and consistent security posture, whilst reducing the complexity of the configurations required to do so

Troubleshooting TrustSec

Finally, let's take a look at common issues with TrustSec deployments and talk about where you can start to look to solve problems.

In the first instance, the best place to start with troubleshooting is the Live Logs - they will confirm the following:

  • TrustSec Connectivity - Live Logs can highlight that there is TrustSec communication between the NADs and ISE. Look for the #CTSREQUEST# keyword in the logs.
  • TrustSec Policy Results - Live Logs can highlight what Policy Results are being returned to the NADs.

If TrustSec Connectivity fails, then check the following:

  • Check the CTS Credentials - they must match.
  • Ensure network authorization is enabled - cts authorization list and aaa authorization network commands should be present
  • Check AAA RADIUS server status - show aaa servers

If TrustSec Policy is not downloading, then check the following:

  • Ensure CoA is enabled on the NAD
  • Check ISE Live Logs for #CTSREQUEST# - these are attempts to download the policy.
  • Policies are downloaded only on the egress NAD - i.e. the NAD that is attached to the destination device. Verify on this, not on the ingress (source) switch.

If SXP Connectivity fails, then check the following:

  • Is there IP connectivity? SXP works on TCP port 64999 and this must be allowed.
  • Check SXP passwords - they must match.
  • Check speaker / listener configuration - speakers are sending the policy, listeners are receiving it.

In general, ISE is the speaker, and the NADs are the listeners. SXP multi-hop config may have both speaker and listener config depending on the design.

If ACLs are not being applied, then check the following:

  • Verify the source and destination tags for the flow - the correct tags should be applied.
  • Verify RBACL has been downloaded to the NAD - it may require a refresh on the NAD or Deployed from ISE.
  • Verify IP Device Tracking has been enabled, if needed - needed for IP-to-SGT bindings, check the IPDT database.

This completes a review of TrustSec for SISE (300-715). As always, feedback is appreciated. Thanks for reading!