May 24, 2018

CCIE Security v5 :: TrustSec Notes

(Last Updated On: 10th June 2017)

Notes taken below are not exhaustive and can/will be updated if required.

This is the first of many posts to come, where I share my CCIE Security v5 study notes. All posts are open for discussion, so feel free to add something you may have come across if related to the topic.

What is TrustSec? IETF Draft

Cisco TrustSec is known as the next generation Access Control Enforcement (ACE) and segmentation technology. The purpose of TrustSec is to address concerns of expanding traditional Access Control Lists and Firewall rules. TrustSec uses Security Group Access (SGA) and unlike Access Control Lists, SGA doesn’t fill up the Ternary Content Addressable Memory (TCAM).

How does TrustSec work?

TrustSec uses a 16-bit Security Group Tag (SGT) to classify traffic rather than using source and destination IP addresses, like traditional ACL’s. This tag can be assigned when users login with their credentials or devices authenticate onto the network. The SGT is considered Layer 2 and is inserted into the Cisco Meta Data (CMD) for each frame for a particular session. Layer 2 encryption known as MACSec 802.1AE can optionally be used to encrypt frames from switch to switch. Cisco Identity Services Engine (ISE) can be used to push SGT’s to capable network access devices and the tag is enforced on the egress interface of that device. Again, it is important to note that TrustSec does NOT work on the principle of source and destination IP addresses, it uses SGT’s.

Ethernet Frame with expanded CMD to show 16-bit SGT

The 16-bit SGT doesn’t cause impact to IP MTU fragmentation however there is a 40 byte L2 MTU impact. SGT’s can be applied in three different ways;

  • Dynamically downloaded with the ISE authorization policy
  • Manually configured at the port level (often for Data Center traffic)
  • Mapped to IP addresses and manually downloaded to SGT capable devices

Device configuration examples

Dynamically downloaded – N/A policy pushed from ISE

————————————————————————————————————————

Manual assignment –

nexus(config)#int e2/1

nexus (config-if)#cts manual

nexus (config-if-cts-manual)#policy static sgt 0x3

————————————————————————————————————————

Mapped IP address – N/A configured in ISE under Security Group Mappings

We can do role-based sgt for devices that don’t support SXP and SGT in two ways:

  1. Map subnets to SGT’s on the device
  2. Use of VLAN’s to map to SGT’s

Native tagging allows TrustSec to scale endlessly because the SGT tag is passed on hop-by-hop and it totally independent of IPv4 and IPv6. This also means policy can be enforced anywhere as the tag is applied at every layer 2 link.

What is SXP?

Source group tag eXchange Protocol (SXP) uses TCP 64999 as its transport to set up an SXP connection between two network devices. Each source group can be identified by a unique SGT value assigned to the device. SXP is used for network devices that don’t natively tag packets.

SXP devices can have the following role/s;

  • Speaker – A peer that sends IP-to-SGT bindings over the SXP connection
  • Listener – A peer that receives IP-to-SGT bindings over the SXP connection
  • Speaker & Listener – A peer that can send and receive IP-to-SGT bindings over the SXP connection

SXP peers can be configured as single hop or multi-hop as shown below

 

Cisco Study: State of Web Security from Cisco Canada
Like routing protocols, SXP has hop limitations. To overcome hop limitations we can configure multi-hop to an aggregation point such as a catalyst 6500.

SXP Versions

SXP has three different versions and it is worth noting the difference of each one.
 Image as shown on IETF Draft

SGACL’s & SG-FW

Security Group Access Control Lists consolidate Access Control Entries (ACE’s) when compared against traditional ACL’s. Conceptually, SGACL’s can be deployed two ways:
  • North-South: Is when a user/device is classified at the access layer but enforcement is done at the data center.
  • East-West: Is when you need to protect resources that exist on the same access switch. Also known as peer-to-peer we have the ability to stop guests talking to employees on the same VLAN.

Enforcement can also be done on Firewalls. Two types of Security Group Firewall functionalities exist, the ASA SG-FW and the Router based SG-FW. The router based SG-FW is used for situations where a Zone-Based Firewall is implemented.

  • ASA code 9.0 saw support for SG-FW functionality added
  • ASA SG-FW is supported using ASDM
  • ISR’s began supporting router based SG-FW in 15.2(2)T
  • ASR 1000 added support in 3.4

Additional Notes & Configurations

  • Starting from IOS XE 03.07.01E, source and destination TrustSec group tags can be exported in the NetFlow record
  • Access layer switches such as the 3650 and the 3750-X have the capability to use native tagging
  • The Catalyst 6500 switch can be used at the access or distribution layer. When configuring this witch for SGT propagation, it needs to be configured as egress (receiving the tag from another device) or as ingress (placed at the access layer). The two modes are also known as Reflector Modes.
  • The Catalyst 6500 cannot be configured both for ingress and egress
 ————————————————————————————————————————
  • To globally enable tagging of SGT’s and enforce Security Group Access Control Lists (SGACL’s) enter the following command:
    • switch(config)# cts role-based enforcement

  • We can also enforce SGT’s manually as mentioned earlier in this post. This is often used if we don’t want to use a NDAC. To do this, we need to enter the following interface level configuration.
    • switch(config-if)# cts manual

  • If security groups have been created, you can set up the NAD to be a trusted device for Security Group Tags. The ”Trusted” command in the following output tells the device not to make any changes to the tag as it has come from a trusted source.
    • switch(config-if-cts-manual)# policy static sgt 3 trusted

  • You can verify cts configurations using the #show cts ? commands. ”CTS” is short for Cisco TrustSec

 

Thank you for reading, please check back for any updates to this post. You can subscribe to future posts via email on our main page.

Previous «
Next »

Security Solutions Consulting Engineer @ Cisco - CCNA R&S/CCNA Security, CCDA & CCNP R&S - Currently working on CCIE Security. Sharing my knowledge and passion for technology. All views are mine and NOT of my company.

Leave a Reply

Subscribe to SYNACK via Email

%d bloggers like this: