Enduser/department segmentation

[killabee]

Hey all, long time no see! 

Have any of you done, or working on, segmenting end users, departments, or different business units within your company cannot communicate with each other?

I'm doing research into this now and I'm finding two ways that this can be done:
1. VRFs (EVN, VRF-Lite, etc) and firewalls
2. Cisco TrustSec using SGTs, ISE, etc
3. Lots of firewalls

I'm OK with #1, but I feel like it requires more work and consideration to create new VRFs.  On the other hand, it's well known and widely used.

I like #2 and I feel like it's easier and better at scaling, but its reliance on ISE scares me.  I also don't know how mature or widely deployed it is.

I don't really like #3, but it's the most well known method of segmenting users.

What did you choose and why?  What are your thoughts?

Thanks!

[deanwebb]

We go with 3. Because it works. I'll add more later... gotta roll home now.

[GeorgeS]

in my current company we are full of vrf , vrf for everything and a context fw also . When u understand how the network is build is getting easier, but i am not a big fan, it can be chaotic and very difficult to tshoot. Is more cost efficient for sure.

If it was up to me and i was free on budget, i would be going with multiple fw. Again here is a MUST to have standardized groups/rules etc. the only things that should be different are the specific rules for the business/unit. Of course you need very good documentation and if is not proper build, a lot of maintenance! Also is not so scalable as a solution but i prefer it. Maybe because i am a fw guy

as for the trustsec i have not worked with it and i do not have an opinion.

[routerdork]

I'm working on something similar. Right now the plan is to segregate by VLAN and use an ACL to restrict access. Then we'll decide more in depth as we look closer at a NAC solution. Currently we are leaning towards ISE but no one has had time to dive in and explore what all we want to do yet.

[deanwebb]

OK, time to pick things apart...

1. This one sounds like logical segmentation. This, to me, implies a mixed environment where segmented and normal devices share ports on the same switch. If there's a problem and the wrong device goes in the wrong port, then you can lose a production run due to a control getting hit with the wrong packet and freaking out. It's very clever trousers stuff, but far, far, far away from being idiot-proof. There's always a chance that things do not end well for it.

Logical segmentation can result in:


2. TrustSec... that means locking into a vendor (Cisco) that has had issues in the past with security not going 100% according to plan. SGT is basically putting AD permissions on packets in addition to the server access itself. So instead of denying an unauthorized user at the server, he gets denied at the switch... so the switches get to be mini-firewalls, as do the routers. The firewalls are already firewalls.

The cold, hard truth is that NAC solutions get ripped out of sites all. the. time. Tying all one's security to a NAC solution, no matter the vendor, is not a good idea in my opinion. Yes, NAC promises lots of ability to profile and zero in on access permissions, but so does an AD account administrator.

Segmentation is about blocking access between devices not just because engineers shouldn't be in accounting, but because there are networks of devices that should not be exposed to the general population because of the threat they pose to others or because of the threat others pose to them. If there's an issue with the NAC solution, then one's segmentation could then be in violation of regulations and that can result in lost production and/or fines.

I saw a few checkboxes about SGT in ForeScout CounterACT the other day. I had no desire to check them at any point in the future. I don't care who the vendor is, SGT to me is totally redundant application of AD permissions.

So what about the user that wants to be able to reach a segmented network from any workstation in the world? Let me show you to my jump box. Log in to THAT from anywhere in the world, AD determines if you should or should not be there, then the IP of that jump box is allowed to go to the segmented network.

Besides, the whole point about segmentation is to NOT allow access to a given network from just any old where. Those segmented devices will either kill 'em all or die an agonizing death if exposed to the world in an uncontrolled fashion. Yeah, use that authorized jump box that is severely restricted in what can and can not run on it.

TrustSec/SGT can result in:


3. Lots of firewalls:
To me, not as bad as it sounds. First, don't use big ol' honkin' 6TB throughput models that handle 18 gazillion packets/sec. There is no usage of YouTube or FaceBook in segmented networks, so models at the lowest end or second-lowest end from a vendor catalog will do just fine. That means cheaper firewalls, which makes purchasing happy to purchase them.

Yes, there are lots of firewalls and policies to manage. Also get a firewall management system. I am a strong proponent of Tufin, but there are others out there. But just get it, as it will make managing those rule sets much easier to do and will help keep things uniform.

It will result in static placements of jump boxes, routes, servers, and that brings stability to the network. These things are static assets, anyway, so we shouldn't be in a rush to make them mobile, agile, or fluid. They're like cities. Do you want your city to stay in one place or for it to be mobile, agile, or fluid? Me, I want my static assets to be reliably addressed with reliable routes to them so I can set baselines on access. That, in turn, makes setting up a behavior/traffic analysis system all the easier.

It's the easiest to troubleshoot, which means support costs will be much lower in the long run. Yes, maybe more up front cost relative to #1, and doesn't make your Cisco rep as happy as #2, but this may well be the one that you want most down the road.

Lots of firewalls can result in:


But, in the long run, it is:

[killabee]

Too many gifs, man...too many gifs!

Good points on everything.

Weren't you looking or testing a TrustSec system awhile ago? I remember you were deep into ISE, but had also investigated another system that had a client-based and clientless model for identity awareness and security? If so, what happened to that project?

Also, do you run IPS on your internal firewall?

[routerdork]

Too many gifs, man...too many gifs!

LOL nice write up Dean.

Good to hear it's not all butterflies and happiness. We are constantly tightening the knobs on everything due to all the PHI access and growth. Unfortunately for me something will happen sooner or later but luckily my boss always tell me to present the design that allows me to sleep at night.

[deanwebb]

A picture tells a story... an animated GIF writes a whole novel, my friend. A whole novel...

Our architecture team was pushing real hard for TrustSec, and I think they still are, but I don't think they've really looked at it through a sysadmin's eyes. They're coming at it from a network world, and it looks amazing from that angle. When I looked into it more, it seemed more like Cisco using hooks into Active Directory for them to be the wall-to-wall network solution. You want it to work? Gotta have all the Cisco, all the time. You get another vendor in there? Well... maybe things will work if it's not anywhere important.

I didn't like that kind of lock-in, and I liked it even less when I remembered my sysadmin skillz and how I would secure access to servers by setting permissions on directories. 

We compared ISE to ForeScout CounterACT for NAC. Both work way better with a client. Both can do horrible things to the network when first turned on. Recovery is faster with CounterACT in non-dot1x mode. It's also easier to use. We can also phase enforcement by device type, not just by switch.

We run IPS independently of the firewall. Go TippingPoint!

[killabee]

Cool, man.  Thanks for the feedback

[icecream-guy]

every user on their own network, in their own vlan, in their own VRF, connected to their own firewall, with their own IPS, and antivirus/mailware as well other things that I won't mention because the joke is getting too long...