It’s been a while, but we’re finally back to close this blog series on Cisco TrustSec (CTS). If you haven’t yet, go check out the other entries in this series.

Learn what Cisco TrustSec is and why we care here.

Dip your toes into the components involved here.

Begin your Cisco TrustSec classification journey here.

Propagate yourself over here to learn about Cisco TrustSec propagation.

Now that we’ve got that out of the way, LET’S GET IT!

A Brief Review

Since it has been a while, I think it will be helpful to have a quick reminder of how we made it to this point of being able to enforce policies with CTS.

• CTS Security Group is assigned to a user/server/thing defines what that user/server/thing is allowed to do on the network.

• CTS Security Groups (SGTs) are created/configured on Cisco ISE.

• SGTs are dynamically classified by Cisco ISE when an endpoint is authenticated by Cisco ISE (be it 802.1x or MAB).

• SGTs are statically classified by Cisco ISE when an endpoint does not authenticate through Cisco ISE (typically servers).

• SGTs get propagated through the network to all the useful places (enforcement points) by way of inline insertion into packet/frame headers or by way of out-of-band advertisement (SXP).

• ISE is our central repository for SGT assignment and propagation in this blog series. For dynamically classified SGT, ISE informs the authenticator (e.g., the switch that the endpoint is connecting to) of the endpoints SGT as a part of the RADIUS authorization. For statically classified SGT, ISE informs the appropriate network devices of the IP:SGT bindings via the Security Exchange Protocol (SXP).

One final thought here. This series in no way covers all the options for implementing CTS (i.e., your mileage may vary)! We are focusing on CTS capable networking equipment and using ISE as a central database for CTS classification!

TrustSec SGT Enforcement

This is a big bite. Talking about CTS enforcement in a general sense is more than we can possibly chew on in this write-up, so we will be specific regarding our topology. The reference topology is pictured below. Take a few minutes to soak it in. In short, we have two CTS domains (Alpha and Bravo) isolated from one-another by a non-CTS capable (it can’t carry SGT inline) WAN. Both Alpha and Bravo sites have a couple PC’s that get their SGT assigned dynamically from ISE as a part of RADIUS authorization. We also have a server (Static-Server-1) that has its SGT assigned statically by ISE, with the IP:SGT binding distributed via SXP to both Alpha and Bravo’s routers. That same SXP communication advertises Alpha’s dynamic bindings to Bravo’s router (Bravo-Router-1) and Bravo’s dynamic bindings to Alpha’s router (Alpha-Router-1).

Using the above topology as a reference, we will review the configuration necessary to apply an SGACL policy on the following flows.

• Alpha-PC-1 to Alpha-PC-2
• Alpha-PC-1 to Bravo-PC-1
• Alpha-PC-1 to Static-Server-1

CTS Environment Configuration

To limit the scope in this section, we will take some configuration items for granted. We have covered these bits in previous entries to this series. These items are:

• SGT creation on ISE
• The dynamic SGT classification in the ISE policy set
• The static SGT classification in the ISE admin UI
• The ISE SXP propagation configuration between the Alpha/Bravo router and ISE
• The inline SGT propagation between the devices inside each CTS domain
• Non-CTS related RADIUS and 802.1x configuration on ISE and the network devices
  •    includes interface configurations, AAA methods, AAA groups, CoA, device-      tracking, etc.
    
    

All the above taken for granted, let’s start with the configuration necessary to create the CTS connection from the CTS capable switch/router (e.g., Alpha-Switch-1) to ISE.

**Note** There is now an alternative to RADIUS for downloading the CTS environment data that uses HTTPS. Not covering that here, but it looks like an improvement!! **End Note**

The servers within “cts authorization list <AAA method name>” should be equal to:

Those things being taken care of, you should now have the “environment-data” from ISE downloaded locally onto the network device.

Now that our CTS capable device has the CTS environment-data, let’s confirm the CTS propagation has done its part.

This is great! We’ve got the environment-data, we’ve got the IP:SGT mappings, and now we can write a policy! Onward!

ISE TrustSec Policy Matrix

We will use the CTS Matrix on ISE to configure our policies between a given SGT source and SGT destination. From the previous section, we mentioned we would be looking at three flows. I’ll add some additional context to each of the flows.

• Alpha-PC-1 to Alpha-PC-2
  A. In IP terms, this flow is from 10.254.12.14 to 10.254.12.11
  B. In SGT terms, this flow is from ALPHA to ALPHA
  
  
• Alpha-PC-1 to Bravo-PC-1
  A. In IP terms, this flow is from 10.254.12.14 to 10.2.10.10
  B. In SGT terms, this flow is from ALPHA to BRAVO
  
  
• Alpha-PC-1 to Static-Server-1
  A. In IP terms, this flow is from 10.254.12.14 to 10.1.10.10
  B. In SGT terms, this flow is from ALPHA to STATIC

In all cases, we will write a CTS policy to block ICMP from Alpha-PC-1 to the above destinations. Before we write the policy, we’ll make sure all the destinations are pingable.

(Yes, you will have to believe me! 😀 )

Great, now let’s write our policy for the first flow. We will start by adding a Security Group ACL (SGACL) in ISE. Since we will be blocking the same traffic for each flow, we will use this same SGACL in each of our flow examples. Navigate in ISE as shown below and click “Add”.

Now fill out the ACE entries to block ICMP and permit IP. Remember, we don’t need to use IP addresses!! Submit!

Next navigate as shown below and click on the cell where our source SGT meets our destination SGT. In this case, they are the same!

Select the Block_ICMP SGACL and click Save!

We can now see the SGACL populated in the cell where source ALPHA meets destination ALPHA. Hurrah! Are we done? Nope! We need to push these changes to the CTS devices, using the “Deploy” option shown below. The result will be any CTS device that has an entry for the ALPHA (2) SGT in the output of the “show cts role-based sgt-map all” command will download this SGACL to be prepared to filter traffic destined to that SGT.

We can see below that Alpha-Switch-2 has not yet downloaded the SGACL. It would eventually download it the next time the environment data was set to refresh, but often in network security, you need a policy to take effect immediately. To that end, we will click the Deploy button from ISE.

It worked! We have the SGACL downloaded now. Let’s see if the ICMP is blocked now.

Wow. So, let’s review what happened here. You can refer to the topology as you ingest these bullet points.

1. Alpha-PC-1 authenticated through Alpha-Switch-1. The resulting authorization from ISE informed Alpha-Switch-1 that Alpha-PC-1 belongs to SGT ALPHA.
   
   
2. Alpha-PC-2 authenticated through Alpha-Switch-2. The resulting authorization from ISE informed Alpha-Switch-2 that Alpha-PC-2 belongs to SGT ALPHA.
   
   
3. Both Alpha-Switch-1 and -2 downloaded the SGACL for destination SGT ALPHA to be prepared to filter at egress for these SGT’s as they were now aware of ALPHA SGT destinations, based on 1-2 above.
   
   
4. Alpha-PC-1 sent an ICMP request to Alpha-PC-2 IP. Alpha-Switch-1 adds the ALPHA SGT into the L2 Ethernet header on Alpha-PC-1’s ICMP request packet.
   
   
5. Alpha-Switch-1 forwards the Ethernet frame with the SGT information inline to Alpha-Switch-2.
   
   
6. Alpha-Switch-2 looks at the destination IP in the L3 packet and finds a match in its SGT bindings for SGT ALPHA.
   
   
7. Alpha-Switch-2 enforces the policy for ALPHA-to-ALPHA traffic and as a result drops the ICMP request packet.

With this positive momentum in play, let’s write our policy for the second flow. Since we will be blocking the same traffic as in the first flow, we will use this same SGACL for traffic from ALPHA-to-BRAVO as shown below.

As to not repeat ourselves, we deployed this and validated that Alpha-Router-1 received this policy. Now, let’s jump straight to verification!

Wow times two. So, let’s review what happened here. You can refer to the topology as you ingest these bullet points.

1. Alpha-PC-1 authenticated through Alpha-Switch-1. The resulting authorization from ISE informed Alpha-Switch-1 that Alpha-PC-1 belongs to SGT ALPHA.
   
   
2. Bravo-PC-1 authenticated through Bravo-Switch-1. The resulting authorization from ISE assigned Bravo-PC-1 to BRAVO SGT. ISE sent this IP:SGT mapping to Alpha-Router-1 via SXP.
   
   
3. Alpha-Router-1 downloaded the SGACL for destination SGT BRAVO to be prepared to filter at egress for this SGT’s as it is now aware of a BRAVO SGT destination, based on 2 above.
   
   
4. Alpha-PC-1 sent an ICMP request to Bravo-PC-1 IP. Alpha-Switch-1 adds the ALPHA SGT into the L2 Ethernet header on Alpha-PC-1’s ICMP request packet.
   
   
5. Alpha-Switch-1 forwards the Ethernet frame with the SGT information inline to Alpha-Router-1.
   
   
6. Alpha-Router-1 looks at the destination IP in the L3 packet and finds a match in its SGT bindings for SGT BRAVO.
   
   
7. Alpha-Router-1 enforces the policy for ALPHA-to-BRAVO traffic and as a result drops the ICMP request packet.

Go! Go! Go! Go…to the third flow (that rhymed). Since we will be blocking the same traffic as in the first and second flows, we will use this same SGACL for traffic from ALPHA-to-STATIC as shown below.

As to not repeat ourselves, we deployed this and validated that Alpha-Router-1 received this policy. Now, let’s jump straight to verification!

Wow, wow, wow (that is x3 if you are paying attention). So, let’s review what happened here. You can refer to the topology as you ingest these bullet points.

1. Alpha-PC-1 authenticated through Alpha-Switch-1. The resulting authorization from ISE informed Alpha-Switch-1 that Alpha-PC-1 belongs to SGT ALPHA.
   
   
2. Static-Server-1 was statically mapped to SGT STATIC in the ISE administration portal. ISE sent this IP:SGT mapping to Alpha-Router-1 via SXP.
   
   
3. Alpha-Router-1 downloaded the SGACL for destination SGT STATIC to be prepared to filter at egress for this SGT’s as it is now aware of a STATIC SGT destination, based on 2 above.
   
   
4. Alpha-PC-1 sent an ICMP request to Static-Server-1 IP. Alpha-Switch-1 adds the ALPHA SGT into the L2 Ethernet header on Alpha-PC-1’s ICMP request packet.
   
   
5. Alpha-Switch-1 forwards the Ethernet frame with the SGT information inline to Alpha-Router-1.
   
   
6. Alpha-Router-1 looks at the destination IP in the L3 packet and finds a match in its SGT bindings for SGT STATIC.
   
   
7. Alpha-Router-1 enforces the policy for ALPHA-to-STATIC traffic and as a result drops the ICMP request packet.

What’s Next?

Hope you enjoyed this CTS series! Please comment below and let me know what YOU want to read up on next! Thanks for reading!

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!

Want the answers to the most asked questions about ISE? Check out our video below!