Cisco TrustSec changes segmentation from an address-centric problem into an identity and group-policy problem. Cisco ISE can classify users, endpoints, and network devices into security groups and assign a Security Group Tag (SGT). TrustSec-capable infrastructure can then carry or learn that group identity and enforce Security Group Access Control Lists (SGACLs) between source and destination groups. Policy can follow the role of the endpoint instead of depending only on where its IP address happens to live.<\/p>\n
The current 300-715 SISE<\/a> v1.2 blueprint explicitly includes configuring Cisco TrustSec. Cisco’s current ISE 3.4 documentation describes SGTs, SGACLs, SXP, IP-to-SGT mappings, authorization-based assignment, environment data, and policy deployment. The practical skill is understanding the lifecycle of the tag: classify, assign, propagate, enforce, and verify.<\/p>\n A security group represents a class of users, endpoints, devices, or resources that should share access policy. Examples might include employees, contractors, point-of-sale systems, development servers, production servers, guests, or quarantine endpoints. The group name should communicate business or security function rather than a location such as \u201cfloor-3-vlan-210.\u201d<\/p>\n The SGT is the numeric identifier associated with that group inside the TrustSec domain. Cisco ISE can generate values or let administrators manage reserved ranges for specific mapping needs. Humans should design policy around meaningful group names; the numeric tag is the data-plane label that lets infrastructure carry that classification efficiently.<\/p>\n This abstraction is what makes TrustSec useful. If an employee moves from wired access to wireless or receives a new address, the policy can still be based on the Employee security group. Addressing remains necessary for forwarding, but it no longer has to encode every security role.<\/p>\n ISE can assign a security group as part of an authorization policy. The decision can use authenticated identity, endpoint classification, device attributes, location, or other policy conditions. When the conditions match, the authorization result tells the network infrastructure which SGT should represent that session.<\/p>\n Dynamic assignment is powerful because the classification can change with context. A corporate laptop used by an employee can receive one tag, while an unknown device connected to the same access switch receives another. The VLAN does not have to be the only segmentation boundary.<\/p>\n The Cisco ISE network access control<\/a> provides the surrounding context: authentication and authorization must already work correctly before TrustSec policy can be trusted. If the wrong identity store or authorization rule matches, the resulting SGT can be perfectly enforced and still represent the wrong role.<\/p>\n Not every resource authenticates through ISE. Servers, infrastructure services, legacy systems, or external destinations may need an IP-to-SGT mapping so the TrustSec domain can associate their addresses with a security group. ISE can manage static mappings and deploy them to supported devices or mapping groups.<\/p>\n Static mappings should be governed like routing or firewall objects. Document ownership, address range, expected security group, and expiration or review date. Stale mappings are dangerous because an IP address can be reassigned while the old security classification remains.<\/p>\n Use the narrowest correct prefix. Mapping a large subnet to one SGT is simple but may destroy the policy distinction TrustSec was intended to create. If only three services belong to a sensitive group, do not classify an entire shared server network that way for convenience.<\/p>\n TrustSec-capable links can carry SGT information with traffic, allowing downstream enforcement points to make decisions based on the source group. In environments where inline tagging is not available end to end, the Security Group Tag Exchange Protocol (SXP) can propagate IP-to-SGT bindings from one device to another.<\/p>\n SXP propagates mappings, not application traffic. It helps a device learn that a particular IP address corresponds to an SGT so it can apply group-based policy even when the packet itself did not arrive with an inline tag. This distinction matters during troubleshooting: an SXP session can be up while the expected mapping is absent, and a correct mapping can exist while enforcement policy is missing.<\/p>\n Choose propagation methods from platform capability and topology. Mixed environments often use a combination of dynamic assignment, inline tagging, static mapping, and SXP. Document where each transition occurs so operators know which table or protocol to inspect at each hop.<\/p>\n A Security Group Access Control List describes traffic permitted or denied for a source-to-destination group relationship. ISE stores SGACL objects and uses them in TrustSec policy. The policy matrix can express that Employees may reach Shared-Services using selected protocols, Contractors may reach a narrower service set, and Quarantine endpoints may reach only remediation systems.<\/p>\n SGACLs should be as specific as operationally practical. A broad permit-any rule between groups may make the matrix look complete while providing little segmentation. Conversely, hundreds of tiny rules with unclear ownership can become difficult to audit. Group design and service design should reduce the matrix to understandable business relationships.<\/p>\n Cisco ISE documentation notes that SGACL syntax is not validated in every way by ISE before devices apply it. Treat SGACL content as network configuration: use peer review, lab validation, explicit catch-all behavior, and platform compatibility checks before broad deployment.<\/p>\n TrustSec policy is often visualized as an egress matrix. The source security group identifies who or what initiated the traffic, the destination security group identifies the protected resource group, and the matrix cell references the SGACL that should govern that relationship. This makes policy intent readable at the group level.<\/p>\n Direction is crucial. A rule from Employee to Production-Server is not automatically the same as Production-Server to Employee. Return traffic behavior depends on the enforcement implementation and ACL semantics, so design each required direction explicitly rather than assuming a symmetric matrix.<\/p>\nStart with the policy question, not the tag number<\/h3>\n
Assign SGTs from identity and authorization context<\/h3>\n
Use static IP-to-SGT mappings only where dynamic classification is not available<\/h3>\n
Understand how SGT information propagates through the network<\/h3>\n
Use SGACLs to define permissions between security groups<\/h3>\n