cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2419
Views
0
Helpful
7
Replies

ISE Monitor and low-impact mode and trustsec

tomalexis
Level 1
Level 1

Hello

With ISE monitor mode and low impact mode, you can have a interface ACL on switch. 

When you switch to trustsec, how do you implement something like that. Is there a way to have a initial trustsec group for example for low impact mode to put the user into before they are authenticated or a device is profiled ? initially they would need minimal access in low impact mode - then they would get moved into the right SGT. 

Please share your thoughts on this

1 Accepted Solution

Accepted Solutions

You shouldn't change the process, monitor mode, low impact, and closed are related to traffic polices pre authentication. Everything we follow to get to those levels of deployment remain true. TrustSec and the "mode" should be treated independent of each other but in my opinion TrustSec complements the traditional. What I'm getting at here is that you shouldn't change the methodology just because you are adding TrustSec.
I would maybe consider that closed mode be handled slightly differently with TrustSec since profiling relies more and more on traffic flow to/from the endpoint. Maybe a MAB accept with a default SGT that with restricted sgacl privileges, being complimented with a DACL that also has restricted acesss.


Small deployments, like the 1000 endpoints you suggest are great candidates for SXP but it will come down to the total number of switches you want mappings on. It can take a beefy deployment to make sense if you leverage SXP.
Two node 3515 deployment, only 20 SXP connections and 3500 bindings are supported.
Two node 3595 deployment, only 30 SXP connections and 10,000 bindings are supported.

SXP scaling
https://community.cisco.com/t5/security-documents/ise-performance-amp-scale/ta-p/3642148#toc-hId-2000801297

View solution in original post

7 Replies 7

Damien Miller
VIP Alumni
VIP Alumni
You can still have the same ACL's of traditional ISE deployments, and also add TrustSec, they are independent and can compliment each other. In monitor mode I always like to create a default tag that can be carried forward through the project. If something doesn't hit one of my predefined rules, then you know you either need a more specific rule for it, or when you move to an enforcement sgacl deployment, then you know it will have very limited privileges.

My experience has been that most don't typically go straight in to an enforcement TrustSec deployment like you may be suggesting. I tend to lean the other way, start with a default permit all, authenticate and tag all endpoints adjusting groupings towards a desired end state, perform traffic analysis, then begin implementing specific SGACLs between groups.

In smaller environments you can maybe get away with a deny first then open it up, but huge potential impact to users on this. You have to be sure that endpoint group y doesn't need to talk to endpoint group x.

thx Damien. 

what I was implying is that I never saw any best practices doc on how to integrate the monitor mode, low impact, closed in a trustsec environment. 

I am not suggesting that I want to go to trustsec enforcement day 1. I just want to allow any to any for the most part. 

I am just looking for how others have implemented this. The way I see for example if I implement  low impact mode with a pre-auth ACL and then if I don't push a DACL after successful auth of the machine, then the pre-auth ACL will take precedence even if trustsec allows everything. So what I have to do is then have a DACL that allows the required traffic. Or a permit any, and then let trustsec block what it needs to block. 

 

My questions is around how others have implemented in the phased approach of monitor,low impact, and closed. 

 

Also, I know this discussion is around ISE, do you guys see that small deployment of trustsec can just do SXP (like less than 1000 endpoints) and not have to worry about inline tagging etc.. ? 

You shouldn't change the process, monitor mode, low impact, and closed are related to traffic polices pre authentication. Everything we follow to get to those levels of deployment remain true. TrustSec and the "mode" should be treated independent of each other but in my opinion TrustSec complements the traditional. What I'm getting at here is that you shouldn't change the methodology just because you are adding TrustSec.
I would maybe consider that closed mode be handled slightly differently with TrustSec since profiling relies more and more on traffic flow to/from the endpoint. Maybe a MAB accept with a default SGT that with restricted sgacl privileges, being complimented with a DACL that also has restricted acesss.


Small deployments, like the 1000 endpoints you suggest are great candidates for SXP but it will come down to the total number of switches you want mappings on. It can take a beefy deployment to make sense if you leverage SXP.
Two node 3515 deployment, only 20 SXP connections and 3500 bindings are supported.
Two node 3595 deployment, only 30 SXP connections and 10,000 bindings are supported.

SXP scaling
https://community.cisco.com/t5/security-documents/ise-performance-amp-scale/ta-p/3642148#toc-hId-2000801297

Looking for how others have implemented.
Like I said the only way I found was that - you need a pre-auth ACL for low -impact mode on the interface.
Once that's done and its profiled, then you have a push a DACL to allow everything, otherwise trustsec wont work.
So, If I understand correctly for low impact mode you need the following:
1) pre-auth interface ACL
2) DACL after MAB/DOT1x to allow everything
3) trustec SGT assigned will dictate now what the device can access based on SGACLS
 
is that the way others have done it ? 

 

Also for SXP, i would have a hierarchy. l2 only switches will be sxp speakers to a upstream dist/core switch. The dist/core will have entire SXP and also peer to ISE. 

Hello Tomase,

Trusec phase modes is explained below :

  • Monitor : This modes act in similar way as discovery devices on network with access even if they do not meet either MAB / 802.1x credential. This is achieved with the open command at the end of the authentication command, which means even if the device fails either of the aforementioned above , they will fail open not block.
  • Low Impact Mode : In this mode we have now pass the monitor mode , here we now know all devices on the network and access restriction is place on port base via DACL either to permit certain traffic for services or deny them . Example is phone , we will need to allow necessary udp traffic flow  such as DHCP , DNS etc . In this mode supplicant will either be authenticated or fail open but only to a limited network service define by the DACL.
  • Close Mode : In this mode the authentication open command is not use which is the normal 802.1x pre-connect behaviour , which means any traffic prior to authentication will be dropped which include all services mentioned in the Low Impact Mode , in this mode supplicant will need to be compliant with 802.1x (dot1x enabled) and if failed they will need to wait for the set timeout for MAB to run and this fails then the flow will be dropped.

So saying the above , TrustSec is independent of any predefined ACL , is role is to tag traffic according to function defined and apply applicable SGT policy (Role Base access ) to such flow. I guess this is why we normally permit all flow when in Low Impact mode and this is dependent on the SGT tag define on Radius Server.

@tomalexis  let me know if this has helped you

Not really (: .. I was hoping somebody who really implemented trustsec with low impact mode, would talk about their experience and how they implemented the ACLs either default interface ACL and then trustsec ACL migration. 

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: