Segmentation with VLANs or SGT, which do you prefer?

[deanwebb]

I've got a customer that is looking to do some massive segmentation of different device types across multiple sites. Rather than create VLANs for each device type and then provision layer 3 services for every VLAN, they're opting instead to go with SGT. On paper, it looks like a good idea, but I was wondering if anyone else here has SGT experience that might be able to inform me on any possible gotchas.

[Otanx]

I really depends on why they want to segment the devices. Remember segmenting and using multiple VLANs does not give you any security. It is just a administrative, and network hygiene thing. If you want security you then have to put ACLs on top of that. Then keep them up to date. SGT is a security tool from the start. It also decouples the design of the network from the security requirements. You let the NAC profile a device, and assign an SGT based on what it sees. I no longer need to do VLAN changes depending on device types. We do something similar with 802.1x and downloadable ACLs.

-Otanx

[deanwebb]

You are correct about the VLANs and the ACL to go with them.

Which is why the customer is going with SGTs, much less work to do.

Next question: do they work the same on wireless as they do on wired?

[Dieselboy]

I was going to post pretty much what Otanx said. SGT is trustsec? I looked this up yesterday and it adds a tag to the traffic somehow, looks like in the MACsec bits. But in short - segmentation is really just an admin thing, that costs effort hours to admin without any gain (unless youre doing some sort of ACLs / security). Downsides is if someone plugs in a device into the wrong vlan for example, plus all the admin effort burden that comes with maintaining it.

Really, you need an automated way (eg SGT) that does the above for you.

I think Cisco DNA can do this also. There is also another Cisco product that might also do this or aid this called "ISE"

To answer your question - I would expect it to work the same way... you may need supported wifi AP's / controller though, unless you can tag at the access switch where the APs are connected. The doc below says "layer 2 tagging need hardware support"

trustsec: https://www.cisco.com/c/dam/en/us/solutions/collateral/borderless-networks/trustsec/C07-730151-00_overview_of_trustSec_og.pdf

Page 7 explains where the tag goes. I Think this is much better because then you dont need to redesign the network to support it. 1 VLAN for all access devices and then different devices get different tags, depending on their security level.

[Dieselboy]

PS - I am keen to know if we can do this with cisco hardware (switches for example) and Microsoft AD / NAP ?

[Otanx]

I have not seen any discussion on the wireless side, but I would guess it would. However, the one downside I did not mention with SGT is I believe it is a Cisco only thing. So you need a full Cisco stack to take advantage of it. I think they are going to (or already have) opened it up and let others do SGT. Even if it is open I doubt the support is there yet. How long has EIGRP been open, and I can't name anyone but Cisco that supports it.

This is the main reason we didn't go down this path. I really hate getting tied to one vendor. Especially when that feature needs a significant portion of my network to be their hardware to work.

-Otanx

[deanwebb]

Customer is wall-to-wall Cisco for networking, so we're good there. Forescout can also set the SGT tags, so we don't need ISE to do that, which is good since I work for Forescout.

[NetworkGroover]

I'd love to know how this all goes.  I hear a lot about SGTs but hear little about it in actual production.  Any of you guys leveraging it anywhere today?  How has it worked out for you?

[deanwebb]

Did the testing, I'll update the fun times after I'm off today's calls.

Short version: we got it working.

[deanwebb]

I got a short window before my next call, so here goes.

1. Set up SXP on the switch and point it at the ISE server as the device that will resolve the SGT tags.
2. Go into the Forescout GUI and edit the switch's SGT tab - activate SGTs and specify that, when removing an SGT, clear the tag - don't set it to reset it to the original tag.
3. Get the hotfix for the Switch plugin that deals with SGT functionality. <- things work REALLY good when you have the hotfix in place!
4. Build a policy that assigns an SGT to an endpoint.

In this case, Forescout assigns all the SGTs and ISE will provide the ACL that goes with each tag. This works only from Forescout to switches, not yet available with WLCs, but hopefully coming soon.

If we wanted to send SGT info directly to ISE, that is possible, but only with the OIM module on Forescout and pxGrid on ISE to allow those API calls. If the customer does not have pxGrid, then we can't talk to ISE that way.

Once the switch pulls the ACL for the SGT, which is pretty fast, you have the endpoint limited by that ACL. They store nicely in TCAM memory and I'm quite impressed with how smoothly it works, once it gets working.

[wintermute000]

1.) You need to pass that SGT tag end to end. I'll just leave that one there
2.) The big micro-segmentation sell is enforcing the SGT tags in dumb switch silicon and that valuable expensive SRAM based TCAM. Do you think its capable of any kind of layer-7 or even stateful inspection? (clue: look at how ACI does it) How valuable is your fancy micro-segmentation if its basically ACLs? How useful are the examples they always parrot, e.g. servers from Dept X can't talk to servers from Dept Y - what do the actual application requirements look like in the real world?
3.) Tags with real FWs - now you're cookin' - but wait, identity based (Radius or AD or whatever driven) firewalling has been a thing for a long time

Its a good idea at a high level but look into the details, and be aware of the actual limitations you'll run into in the real world.
https://www.cisco.com/c/dam/en/us/td/docs/solutions/CVD/Campus/CVD-Software-Defined-Access-Segmentation-Design-Guide-2018MAY.pdf
https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst9300/software/release/16-10/configuration_guide/cts/b_1610_cts_9300_cg/configuring_security_group_acl_policies.html


BTW stay as far away from the switching fabric and the WAN and any SGT OTT solution to cover SGT non-capable black spots in the network as possible. As the NAC vendor you're relatively protected haha. But honestly I'm surprised you're involved as if its SGT then surely its SDA and hence DNA driven and hence ISE driven.

[deanwebb]

Customer has ISE on prem for wireless authentication, so there's that. They are Cisco wall to wall, except at one site where we'll do VLANs with ACLs.

And for segmentation of headless/IoT devices, we only want those to talk on particular ports so if an attacker impersonates one such device, he only gets like port 3833 in general and 443 to the one IP for the management server, stuff like that.

[wintermute000]

sure, its just weird that they want SGTs without the whole SD-Access play which obviously means DNA centre and ISE. Inserting Forescout in the middle forgoes any DNA driven automation of identity/trustsec. Good luck

[deanwebb]

Budget concerns... and when the network team brings in ISE and the security team brings in Forescout, they usually tell us to play nice together.