microsegmentation benefits and drawbacks.

It can be simple depending on how it is deployed. The trick is to not try to be too complex with it. I've done it in lots of networks using Cisco TrustSec technology and it is brilliant if you get the policy right, but can be catastrophic if you don't.

the term microsegmentation essentially is misused : it does not cover segmenting a huge network into smaller entities but rather adding a firewalling layer to individual hosts.

as such it can be utterly useless for servers that are already properly secured by not having radom daemons listening all over the place.

it can be essentially inefficient when it comes to machines in a domain as most attack vectors will not be impacted as they rely on regular domain operations.

it can be crazily dangerous when admins are ready to replace network level firewalling with microseg (seen in a goddamn bank)

it is a very useful complement to regular network security, though. for server platforms, most of the time, simple (often l2) policies that prevent unneeded communications with siblings allow to limit possible lateral moves withoug sticking each server in a dedicated network (which would be a much better approach security wise though often impractical)

Implement network segmentation: Network segmentation involves dividing the network into smaller segments or "zones" and limiting access to resources on a need-to-know basis. This can reduce the attack surface and minimize the risk of unauthorized access to sensitive resources.

Implement micro-segmentation: Micro-segmentation involves dividing the network into even smaller segments or "micro-zones" and limiting access to resources more granularly. This can be especially useful in cloud environments, where resources are often shared among multiple users and devices.


https://blog.isc2.org/isc2_blog/2022/08/effective-security-using-zero-trust-architecture.html

hmm .. that was actually my own understanding. real life experience prooved many/most people think differently. products such as illumio interpret it in this weird way.

please consider my previous answer as limited to hosts firewalling.

if it comes to actual network small segments, it merely boils to using perimeter firewalls or possibly virtual firewall instances. you will benefit from not too integrated solutions on large networks as multiple layers of errors would be required to poke holes though there will be a significant management cost. as such, ih merely is along the lines of both common sense and whitepapers from the 90s' so there is no point in introducing a new idiotic fancy word.

it does make sense when it comes to virual firewall instances administered by different people.

it also totally makes sense if you expect to use individual firewall or firewall instances with entrypoint vips for each service. both in terms of addressing and security. this does not exceed the bounds of regular network security and common sense either, though

the term microsegmentation essentially is misused : it does not cover segmenting a huge network into smaller entities but rather adding a firewalling layer to individual hosts.

as such it can be utterly useless for servers that are already properly secured by not having radom daemons listening all over the place.

Not all microsegmentation is implemented equally. For example, Cisco TrustSec microsegmentation doesn't touch the endpoint itself (unless it is applied to network devices too) - it is configured, controlled and enforced at the network level. Endpoints are given a tag value which identifies each category. Packets entering a switchport from an endpoint are tagged with the specific value (the SGT, or Scalable Group Tag) which is referenced throughout the network. The TrustSec policy then defines what each tag is allowed to talk to, in the form of a src/dst matrix. It can be as simple as permit/deny, or can be like an ACL which provides controls for ports and protocols. Cisco TrustSec microsegmentation is an extra layer of segmentation above and beyond a firewall policy on an endpoint, for example.

if it comes to actual network small segments, it merely boils to using perimeter firewalls or possibly virtual firewall instances.

As above. Perimeter firewalls are only part of macrosegmentation. They control north/south traffic. Microsegmentation deals with east/west traffic.

yes. as for most/all other cases, nothing new under the sun. we used to achieved the same feature with a combination of hooking macs to switch ports and using acls or 802.1X authentication.

basically, this is just yet another meaningless fancy word. but some of the market products do account for much easier management.

but we should not dream. vpc, shared docker platforms and the likes are basically a nightmare in terms of network security and the issues they produce are seldom solved trivially. in many cases, adding yet another tool merely hides the real world issues under the carpet.

regarding cisco microseg. this conceptually essentially boils to turning switches into naive firewalls that can rely on asics only to process traffic. one may argue that regular firewall rule syntax would be simple enough as long as said syntax allows to define groups. some of us implemented or approached that kind of granularity 15 years ago, admittedly with a significant performance and/or management cost.

we used to achieved the same feature with a combination of hooking macs to switch ports and using acls or 802.1X authentication.

Using ACLs would blow the TCAM extremely quickly with any meaningful ACL. Anything else wouldn't achieve the same as microsegmentation.

one may argue that regular firewall rule syntax would be simple enough as long as said syntax allows to define groups.

That's exactly what Cisco TrustSec does. It uses tags (groups) and permit/deny all or permit/deny based on port/protocol. The tag replaces the source/destination IP.

some of us implemented or approached that kind of granularity 15 years ago, admittedly with a significant performance and/or management cost.

There was nothing even remotely close to Cisco TrustSec 15 years ago.

@craig : not sure why we'd need to antagonize. we are mostly saying the same thing. our notion of regular firewall rules may differ though as i was never a big fan of cisco's syntaxes.

regarding the kind of granularity,
one way was running openbsd on hardware that was targeted for routers. basically a regular server with plenty of ethernet ports and a rather slow cpu (latency toll)
another way was to use separate network segments for each hosts or use a basic acl to only allow hosts to talk to their gateways (my often favorite for dmzs since lateral traffic is typically useless)
yet another way was to use scripts to populate acls (you typically do not need that many and the groups are in your scripts). used this in production at a major ISP.
yet another way was to play with custom macs and mac tables to keep the acls simpler or even in some cases replace them
...
and obviously running centrally managed firewalls on each host additionally to the above. this is arguably overkill with properly hardened OSes, though.
different situations yield different solutions

anyway i fail to see how this conversation helps so i will refrain from further posting. if you want to discuss this further, pm me.

I'm not antagonising. You don't seem to agree with what I'm saying and are wanting the last word.

feel free to believe that.
as my last word then, afaik the current microseg implementation translates to acls (though sometimes dynamically) so it is actually stored in tcam. the groups and rulesets are merely a very convenient configuration sugar. they also allow to recable without messing with the acls.

afaik the current microseg implementation translates to acls (though sometimes dynamically) so it is actually stored in tcam.

Cisco's TrustSec tech relies on UADP programmability and ASICs. No TCAM is required unless SXP is used (for SGT caching). Native SGT functionality doesn't require TCAM whatsoever.

good to know, thanks. how different would it be from acls in terms of performance ? limitations ?

It's done in hardware, so within the box it's line-rate. It's near line-rate for inline tagging too (between TrustSec-enabled devices), so performance is excellent.

The caveat is that it needs TrustSec-compatible hardware in order to enforce restrictions based on SGT/SXP IP-to-SGT mappings. Some hardware can only "see" the tag and pass it on to an adjacent device.

ok. so from what i gather, the performance is similar to acls but it just works across multiple devices out of the box without hassle... ?

It is better performance than ACLs where SGT is used as the tag is in the packet, so the lookup is quicker.

It can be complex to set up if you don't understand the concepts and compatibility. For example, SGT is native and can be passed in the frame between devices that support SGT imposition and enforcement. SXP maps IP to SGT for devices that don't receive a SGT in the frame. Inline tagging allows devices to honour received tags. Etc...

It's really an end-to-end system that needs to be planned well. You can't just put capable switches/routers/firewalls in and tag everything and expect it to work - this is Cisco, of course :-). You need Cisco ISE, which isn't a simple product to master at all. Within ISE you then need to define a policy of what can talk to what, and how, then define what tags you'll use, then configure the TrustSec matrix to suit the policy. If you speak to anyone that has implemented it they'll surely tell you that it's a massive learning curve and not without its issues, but when it works, it works well.

thanks for the infos. this is actually straightforwards enough past the numerous acronyms. i guess SXP maps are filled through passive learning. the rest is imho quite similar to vlan or rather vxlan tagging conceptually but allows to keep the routing simple and make unplanned changes quite easily.

have you tackled this in terms of security with basic attacks such as smurfs or arp mitm/spoofing ? ...which i would expect might lock smth rather than actually work

i guess SXP maps are filled through passive learning

SXP is the mechanism that exchanges IP-to-SGT mappings, so it's an active process on the device, which can be in Speaker or Listener mode, or both. Where a SGT can't be natively passed to the device, it can use SXP to learn the SGT that a particular device should use, based on info in ISE.

the rest is imho quite similar to vlan or rather vxlan tagging conceptually but allows to keep the routing simple and make unplanned changes quite easily.

Yes, to a degree.

have you tackled this in terms of security with basic attacks such as smurfs or arp mitm/spoofing ? ...which i would expect might lock smth rather than actually work

This generally wouldn't be used to protect against these types of attacks on its own. It would bolster existing techniques such as disabling directed broadcasts or using DAI, for example.

ok, thanks for the information.
my current clients have simple enough networks or industrialized process and/or use virual micromachines that would gain little benefit from said tech but this will probably come in handy some day.

No worries - glad to help :-)