Introduction to Microsegmentation
This blog begins an introductory series of moderately long blogs, covering key aspects of Microsegmentation and Zero Trust.
The key point to Microsegmentation and Zero Trust is that security is tied to device type, identity, trust status, and other attributes, as opposed to IP address or MAC address.
The series will use graphics from Elisity because:
Cisco ISE and DNAC/CCC can do many similar things and a lot more. But:
Other vendors: I lack data, have no experience of their products. Feel free to add value and share your experience / knowledge by commenting on the blogs! What do other vendors products do especially well? What are they good or bad at?
I’ve included the following Elisity graphic to represent the goal of micro-segmentation. In this case: securing OT manufacturing line controls, user and IT devices, and IOT devices, across multiple switches in one or several sites or buildings.
Micro-Segmentation Topics
Here is a list of some of the things one needs to address when implementing micro-segmentation. I intend to cover these in a few blogs.
This first blog in the series covers the first two items above.
The blog series may combine some of these topics, and also will likely cover some of these in more detail than others. Experience also says that the topics will likely shift as writing the series progresses. Hey, my crystal ball is cloudy, and things evolve as the blog sequence gets written.
Anyway, let’s get started …
About Micro-Segmentation
Remember firewalls with un-manageable 70,000 or 100,000 entry access lists with seemingly random address ranges and ports? Long disorganized access lists (“ACL’s”) which nobody understood? I still recall the pain.
Those access lists had some real challenges, including:
That made maintenance slow and error-prone. And easy-to-make errors then would cause inappropriate traffic blocking and outages, requiring scrambling to fix them.
Just say no to bloated, unreadable access lists!
The firewalls were also a problem. Stateful enforcement: good. But backhauling traffic to secure it also aggregated traffic, complicated the network topology and flows, and required buying one or several massive and very costly firewalls. Now with Cisco announcing DSP’s in switches, you can (for a price) distribute that firewalling workload. (“Every switch a firewall”?).
Another aspect prior to Microsegmentation was VLANs. You typically ended up mapping devices to VLANs, to separate traffic from groups of devices up to the router and/or firewall. That made the network more complex to deploy and manage. Having logical tags to separate traffic rather than on-the-wire tagging makes it a lot easier to deploy the network and add security incrementally.
Thank goodness all that has changed, as sites have moved on to better tools!
Doing Micro-Segmentation and switches that can enforce ACL’s based on Security Group Tags has moved the goalposts!
I’m going to assume if you’re reading this, you have some idea what micro-segmentation IS, and why you’re doing it. Having said that...
So What IS Microsegmentation?
For what it’s worth, my latest definition is that micro-segmentation is about grouping devices and device types and providing finely-grained control over flows between those groupings.
If you think of a segment as a piece of network with devices attached, micro-segmentation is about logically taking that piece of network and logically sub-dividing it into micro-segments. The old way of doing this may have used VLANs, or security group tags embedded in headers (Cisco). More recently, doing identity (MAC or current IP) to logical group tag is what I suspect vendors are doing.
Micro-segmentation shifts the focus from IP addresses to device types and other information. By tying in Identity-based tools, micro-segmentation can be based on user or device identity, and even on a dynamic behavioral trust score for that identity.
That (in principle) enables you to segment without creating VLANs and related configuration for different device types. I.e. just have all devices on one VLAN and the switches enforce micro-segmentation rules as to which device groupings can talk to each other.
Thus microsegmentation provides security enforcement on traffic going between the different micro-segments. It may or may not be stateful enforcement, but how critical is that, really? (Philosophical debate lurking there, I’m going to duck it.)
Most vendors have put out good sales documents about what Microsegmentation is, and its advantages. I’ve included some such links below for your further reading, in the first of two Links sections.
What Does Microsegmentation Look Like?
Elisity starts by classifying devices into approximately 15 dynamic global Policy Groups. That’s enough to start putting a fairly robust initial Microsegmentation policy in place.
The following Elisity graphic suggests what those representative groups might be:
IdentityGraph is Elisity’s term for what the controller knows about a device. That can include lots of information imported dynamically from other security products, especially Identity and Trust related products.
The following image shows a deny-all policy for traffic between two device groups.
The graphic suggests what I call “The Matrix”, common to both Elisity and Cisco SDA/DNAC/CCC. The matrix shows source vs. destination security group, and each box in the matrix grid links to the security policy for traffic from that source to that destination. In the above graphic, the policy controls traffic from CT Scanners to Streaming Media Players. There is of course a related matrix cell (box) with policy for the reverse flow.
Part of micro-segmentation ideally includes replacing ACL’s with sanity and readability, organizing security policies in structured form around named groups of devices and users, address blocks, ports and port groups, rather than raw IP addresses or address blocks, TCP/UDP ports, etc. That is, achieving a degree of self-documentation!
That definition may be a bit optimistic, as far as named ports/port groups. After all, which ports each app uses may change over time, is likely poorly documented, and probably overlaps with the port ranges many other apps use.
For comparison with my list of topics above, Elisity has a good document summarizing how to implement: Implementing Microsegmentation: A Practical Guide. Here is their list of steps:
That list of tasks is aligned with working with their product. Whereas I’m trying to cover some of the broader project scope. Hence my earlier list of topics is a bit broader.
The Elisity blog also notes some Best Practices:
There are some key points there that sites often have to learn by experience.
Segmentation and especially Microsegmentation are not going to be one-and-done. So you need to think ongoing updates, manageability, and not going off the deep end. One sign you’ve over-done it is ongoing outages due to complexity and human error, difficulty updating the policy to accomodate new needs, etc.
Getting Started Doing Micro-Segmentation
So if you’re getting started, you presumably have a mandate or approval from management, funding, etc.
It is good to pause for a moment, ask yourself, and document: Why are you doing Micro-Segmentation?
Hopefully not because you’re a masochist!
Key questions:
If you are doing micro-segmentation, you will need to know the goal, the definition of success, and how soon results are needed. You will have talked to peers in networking, security, operations, or across other organization boundaries, to make sure they’re aware of your efforts, approve, won’t react angrily over control, fear, or surprise reaction issues, etc.
Put differently, who is the team that will be working to gather the necessary information, work out the security rules and policies, and prevent as well as deal with any adverse impacts. Usually the working group with include some combination of network and security staff, depending staffing availability and interests, team structures, and management choices.
You’ll also need to know priorities. Are there any glaring security problems?
Plan An Incremental Approach
It’s important to recognize that you cannot achieve full control all at once. Also that Micro-Segmentation is not just technical: it requires coordinating deployment and policy planning with staff across the organization. And taking judicious incremental steps to minimize breaking things, and so as to have good reversibility of changes should there be surprise problems.
Does management understand you will be taking an incremental approach, in order to minimize outages? I.e. get started at small scale, get experience with the tools and new approach, provide some level of critical segmentation, then broaden the network scope? Then perhaps start a second pass, increasing the policy granularity? If management doesn’t understand this, ask them how they feel about outages caused by going too fast?
Startups talk about Minimum Viable Product. What’s yours? What’s the simplest micro-segmentation you can deliver that provides solid value, and a basis for more finely-grained security controls in follow-on phaes?
You will have to discover devices, come up with a draft policy, validate it, deploy it, fix problems and broaden scope. Sometimes all at the same time, e.g. if the company failed a security audit and management is in a hurry.
This is a big task, for at least three reasons:
The only way to succeed is to:
If the project is super-rushed, you can perhaps do “widening circles”. Do a less-critical site, learn, make the inevitable learning mistake or two, refine, get it to a good point. Then task a large staff group to do more sites, perhaps in order of less-critical to more-sensitive. Meanwhile the original team can be deepening the policy, providing finer granularity where needed. But always think: no more complexity than absolutely needed, or your job will become very painful!
So does one start with:
Short answer: yes. You need to find out what’s out on the network, device-wise, but at the same time it would be a good idea to start having security rule discussions.
The key point here is to keep making progress on multiple fronts, and to start providing results while recognizing there may be some unknowns and ambiguities that will take longer to sort out.
At one site I worked with, it took over a year to discover that beside some encrypted credit card transaction traffic, there were cash transactions being carried unencrypted over the network. Someone had a vendor add something without network/security being aware of it. And my guess is they told the vendor the network was secure, or the vendor didn’t care (“not their problem”).
Picking and Deploying a Micro-Segmentation Product
According to my list far above, picking and deploying a micro-segmentation product comes next.
I intend to NOT blog about product selection.
In part because I’m in no position to critique all the products that are out there. But also because I want this blog series to cut to the chase, and focus on what you do, rather than on product per se.
A lot of the Elisity materials lead with the deployment aspect, in part because they need to introduce some terminology relating to their solution.
I also intend to minimize the product installation and setup aspect of micro-segmentation. That’s product-specific. This blog series intends to focus more on the logic and process of implementing micro-segmentation.
In the next blog, I will very briefly describe the Elisity components, because that will be needed to understand some of the subsequent discussion and graphics. I’m going to assume you’ve licensed and installed some product that will provide information similar to what Elisity does. Or you have some other way to get such information.
Conclusion
Micro-segmentation provides finely-grained security enforcement comparable to deploying devices on different network segments (VLANs) and applying security controls on traffic between the device groupings.
Micro-segmentation enforcement is generally done in the network switches for scalability. It may or may not be stateful, depending on the switch capabilities. Along those lines, I’ll note in passing that Cisco recently announced switches with DPU’s built-in, enabling line-rate stateful enforcement.
Follow this blog series as I delve into some of the details of micro-segmentation. My overall objective is to leave you with a better idea of what micro-segmentation entails and what it can do. While touching on some interesting nuances but not getting bogged down in detail!
Links re Microsegmentation
Here are some links covering WHAT Microsegmentation is, and WHY do it. Pre-sales / decision-making.
Other Microsegmentation Links
And here are more technical inks that assume you’re doing Microsegmentation, and describe various aspects of implementation.
Miscellany
Reminder: you may want to check back on my articles on LinkedIn to review any comments or comment threads. They can be a quick way to have a discussion, correct me, or share you perspectives on technology.
Hashtags: #PeterWelcher #CCIE1773 #Microsegmentation #Elisity #Cisco
FTC disclosure statement: https://www.dhirubhai.net/pulse/ftc-disclosure-statement-peter-welcher-y8wle/
Twitter: @pjwelcher
LinkedIn: Peter Welcher
Mastodon: @[email protected]
HPE Aruba has the CX 10000 for a few years already, based on the same Pensando switch as Cisco uses. These are ToR/EoR switches not as far as I know for Campus-based stateful enforcement. In the Campus similar to SDA/ISE they create role based policies in Aruba central through Netconductor. The roles are assigned and monitored through Clearpass and the switches use SGTs for the microsegmentation.
I am going to read this! Very relevant ;-) thanks Pete