Two Keys to Properly Paced Segmentation
Most of our customers are motivated to establish security segments in order to meet compliance, service assurance or data protection requirements. They typically don't have much choice given modern threats and regulatory requirements. However, it is interesting the number of organizations we run into that, despite significant motivation, are either completely frozen with no forward progress or, conversely, are moving entirely too fast. We see very few organizations that fall in between.
There is a proper balance that must be struck when establishing secure segments, and the two concepts below are key to finding the optimal pace of segmentation.
1. Architecture first. Product selection later.
The companies that move too fast often make the mistake of diving directly into a technology solution based solely on tactical enforcement. Committing too early to a product in this manner can lead directly to a self-inflicted wound of the foot.
If you forego the planning of a risk-based logical security architecture there is a high likelihood you will have the misfortune of ripping out your segmentation shortly after installing it. Segmentation won't match business requirements. Target environments won't be properly prioritized. It's tale as old as time (in technology years).
A proper security architecture includes logical zones, policy and security control definitions, not specific product selection. That comes later.
Or you might consider starting up the security architecture design in parallel with one or two no-brainer smaller tactical efforts that give you quick wins. That could work, but the idea is to formally start your logical security architecture from the beginning. When you do so, you glue the remaining future tactical efforts together and save yourself significant troubles.
2. Visibility
On the flip side, the companies that move too slowly are stymied much of the time because they can't really see what they're attempting to segment.
It's like when my kids come back from college for the summer. I do my best to never take a shower upstairs when they are doing the same downstairs. When I forget, I quickly transition from a relaxed man in a soothing hot shower to the Night King from "Game of Thrones." Just painful cold. You see, I have a plumbing problem. It's probably not even a big one, but because I can't see what's in my walls, it feels like a big problem, and I never do anything about it.
Similarly, one of the keys to moving forward in a segmentation project is full visibility. You need proper asset inventory. You often need application dependency mapping. You might need user dependency mapping. You probably have a large number of unmanaged devices you need to identify. You cannot segment what you cannot see. So, take off the blindfold and solve this problem early.
Solutions exist that make this much less painful. Cisco Tetration is an example. It is purpose built to provide a snapshot that de-risks efforts like segmentation that might result in a significant environment change. And as a bonus, it can supplement actual segmentation enforcement when you need it later on in the project.
Reality
Neither of these strategies is all that complicated, and yet they seem to be elusive. Sometimes they are blocked by a lack of experience. Sometimes they are blocked by internal politics. Sometimes they are blocked by a desperate need to get something segmented somewhere now. Regardless, have confidence that if you wish to implement a proper, long-lasting segmentation strategy these are great starting points.