Welcome back!  In our previous entry on Cisco TrustSec (CTS) we answered the question of why CTS is needed in the first place.  Now that we understand why we need it; we need to understand how to do it!  So how do you do it?  In short, first you classify, then you propagate, and finally enforce.  In this entry to our ISE blog series we are going to cover some baseline context on all three of these in order to prime your understanding for more detailed blogs to follow on each classification, propagation, and enforcement.

Terms and Acronyms Apply

Before we dive in, let’s make some acronym soup!  We’ll cover much and more on all of these later, but for now I wanted to give you a decoder ring for some of the acronyms that we’ll be spewing in these blog posts on Cisco TrustSec.

• This is the term that represents this entire suite of micro-segmentation technologies. All of the acronyms that follow in this list are architectural components within CTS itself.

• This is the term that represents the tag identifying what CTS Security Group something/someone belongs to. This is what we use to define the source and destination for policy matching in CTS, instead of IP addressing.

• This is the term for a group-based (as opposed to IP based) ACL. It is (currently) capable of filtering Layer 3 and Layer 4 traffic.  These are, ideally, provisioned centrally on ISE and pushed on demand to the network devices that are SGACL capable, however, they can be statically provisioned on SGACL capable network devices as well. 

• This is a term for a firewall capable of using SGT’s in its firewall policy. SG Firewalls maintain their existing policy engines and syntax with the addition of being able to use SGT’s as source/destination matching criteria.  Most SG Firewalls are capable of filtering all the way up to Layer 7.  SG Firewall policies cannot be configured centrally on ISE in the way that SGACL’s can be.  Centralized management of SG Firewall policies will be left to the centralized policy tools available to your firewall.

• This is the term for the protocol used to propagate SGT to IP bindings out-of-band when traversing a network incapable of inline SGT propagation. We’ll cover this protocol extensively in our entry on CTS SGT propagation. 

•  A Cisco developed and now IETF standards driven API used to share security context between varying Cisco and third-party security products. Cisco pxGrid is particularly useful in the context of CTS as it allows Cisco FirePOWER Threat Defense (FTD) firewalls and third-party security products to obtain SGT to IP mapping information.

Primer – Filtering Traffic with Cisco TrustSec Security Groups

In order to achieve your goal of filtering traffic with TrustSec SGT’s (that is your goal, isn’t it?), you’ll need to classify the network connected “things” into groups, propagate those groups to you policy enforcement points, and finally write some policies to be enforced!  What follows is a baseline of what you need to understand about these three critical components of Cisco CTS based filtering.

Classification

Today, the things (users, personal computers, servers, printers, phones, and literal “things”) connected to your network are (mostly) classified, from a network security perspective, by the VLAN/subnet they belong to.  As a result, when you want to implement policy in the network layer, you implement policy based on IP addressing.  We want to implement policy based on groups of like devices/users, not IP addresses.  This is where CTS comes in with a new network layer classification system; CTS Security Groups (SGTs).  We will leverage ISE to dynamically classify authenticating endpoints/users into those SGTs based on any number of factors (AD group, device type, posture status, location, etc..).  However sad it may be, there are instances where ISE is not authenticating an endpoint on the network, and for those instances we’ll use static SGT assignment.  This static SGT assignment is ideally centrally managed by ISE, but we’ll get to that later.  That’s enough on classification for the moment as we’ll cover this in great detail soon.  For the time being, it is enough that you are now aware that a new network security classification system was needed to replace IP addresses and CTS Security Groups (SGTs) are just that!

Propagation

What is this propagation you speak of?  We never had to do that before!  True.  True.  We’ve gone over the drawbacks of a policy based on IP addresses, but we neglected one massive, yet unintentional benefit; the matching criteria (the source/destination IP address) for our security policy were carried inside every packet (in the data plane)!  We didn’t need to modify the packet format in order to apply policy, we simply created our policies on top of information that already existed inside the data plane!  Brilliant in a way, and at the same time, short-sighted.  So, back to the propagation problem.  It is a two-part problem. 

1. We need to somehow inform the network access devices (switches and wireless AP’s or controllers) which SGT the endpoints connected to it belong to.
2. We need some method to carry this information over the network to the places we have designed to enforce policy, our policy enforcement points.

I know what you are thinking, “let’s just put it back in the data plane!”.  You are not wrong, that is the best idea.  It is also a massive, multi-vendor undertaking.  I do think it will happen, eventually, somewhere over the rainbow.  I’m not suggesting that the industry will adopt Cisco’s terminology, but they will adopt the concept.  Similar to what needed to be done to modify the packet formats for MPLS, or VXLAN (both of which Cisco hand a hand in inventing).  In fact, a quick search provides this IETF draft.  However, the status on the draft states that it merely exists, not that anyone is actively working on it!  While the IETF drafts work themselves out, Cisco has introduced a new header into its own networking devices; the “Cisco Metadata” header, which contains, amongst other things, the source SGT.  Even so, there will be filtering use-cases that we will talk about later, which cannot be satisfied by data plane SGT propagation alone.  Enter pxGrid and the Security Group Exchange Protocol, or SXP.  SXP provides a control plane that we can use to propagate endpoint to SGT mapping information across networks that do not support data plane SGT headers.  While SXP is also currently Cisco proprietary, the same endpoint to SGT mapping information can be consumed by any vendors application via ISE’s pxGrid API!  Feeling primed on propagation?  Nice!  We will go deep into the weeds on both the data plane and control plane propagation methods in another blog soon to come.

Enforcement

All is well that ends well.  And in our case, nothing ends well without leveraging all that work we put into classifying and propagating those SGTs by writing a policy to do so!  So, what kind of policies can we write?  And what information does the policy enforcement point need in order to instantiate a policy based on SGTs?  The answer is, it depends…on what kind of device your policy enforcement point is!  Broadly speaking, there are two different kinds of SGT policy enforcement points; those that support SGACL’s and those that do not (SG Firewalls)!  At minimum, both kinds of policy enforcement points need to support the consumption of SGT’s via either the data plane “Cisco Metadata” header, a control plane SXP connection, or ISE pxGrid API integration.  Check out this bulletin on Cisco TrustSec 6.5 to see which of your network devices support SGACL or SG Firewall enforcement!

If your device supports SGACL’s, you’ll be able to filter based at layer 3 (deny IP, permit IP, etc..) or layer 4 (permit tcp, deny udp, etc..).  You’ll need to make sure your policy enforcement point that you use for SGACL’s is aware of both source and destination SGT as matching the correct SGACL will require both.  What follows is an example of what one of these would contain.  Notice that the do not contain any source or destination IP addressing!

From SGT_Employee to SGT_WebApp:

permit tcp src gt 1024 dst eq 80

permit tcp src gt 1024 dst eq 443

deny ip

If your device supports SG Firewalls, you’ll more than likely be able to filter all the way up to layer 7 (application filtering, URL filtering, etc..).  SG Firewall policy implementations vary but typically you can write policies using only the source SGT information, using only the destination SGT information, or both.  See the screenshot below for an example of where this SGT information would surface on a Cisco FirePOWER Threat Defense access control policy.

Ready to enforce?  No, you are not!  We’ll get into many more details on enforcement after we cover classification and propagation in the next couple posts!

What’s Next?

I think we’ve covered SGT classification, propagation, and enforcement from a high level.  What do you think?  Let me know in the comments!  In the next entry to the TrustSec mini-series, we’ll dive in into the dark art of CTS classification! 

Check out our awesome tech talk on ISE:

As always if you have any questions on getting Cisco's ISE set up for you and your business and would like to schedule a free consultation with us, please reach out to us at sales@lookingpoint.com and we’ll be happy to help!