Network segmentation has been a recommended network security practice for many years. The concept of segmenting a network into small chunks grew from the need to provide processing speed and power, uptime, and availability of network resources. Years later, security architects recognized how this idea of segmentation could also be beneficial from a cybersecurity standpoint. Somewhere along the line, as network segmentation evolved into microsegmentation, features became fused with benefits, and the endgame was distorted as vendors vied to position their technologies as the very best microsegmentation solution on the market. This only served to pile on confusion for end users who tried to implement microsegmentation but abandoned ship when it became too complex and didn’t deliver expected results.
Now, one might argue that the endgame of microsegmentation is pretty clear: breaking down a large, sprawling network into manageable bits. But is that explanation enough to sell your executive team on the thousands of dollars and hundreds of hours it takes to evaluate, implement, and manage a microsegmentation program?
Probably not. Particularly not when using traditional methods of microsegmentation that use legacy tooling, which is kludgy and was originally designed to protect the perimeter, meaning that the benefits are counterbalanced by the challenges of retrofitting an “outside” security control for internal network purposes.
As I sit at my desk and contemplate how to explain the benefits of microsegmentation, I find it’s helpful to fall back on non-security examples that everyone can relate to. After all, no two security or networking programs are the same and no two organizations have carbon copy business requirements, data, or systems that influence how microsegmentation is accomplished. Yet most people can relate to examples taken from daily life. If you’re the security or infrastructure person trying to garner non-techie budget and/or support for a microsegmentation project, focusing on the “why”—in simple terms, as opposed to “you can restrict this host from talking to that server”—can be extremely useful.
In security’s view, the goal of microsegmentation is to implement fine-grained control across collections of hosts, servers, databases, applications, etc., which prevent attackers from exploiting an entire network once they’ve compromised one endpoint, user, or other vulnerability.
However, that doesn’t sound super sexy or make mountains of money appear from the CFO’s coffers. The business benefit can be inferred, but it’s neither explicitly stated nor easily understood if networking isn’t one’s gig. It’s also helpful to separate the “how” from the “why,” or the features from the benefits.
For our first example, let’s pretend you’re driving from Boston to Buffalo. At first blush, this seems fairly straightforward: hop on I-90W and drive for seven or eight hours. Depending on where in the Boston area you’re starting from and where in the Buffalo area you need to go, it might take you more or less time. A few variables, but this plan is simple and focused. But how does the route change if you’re the kind of person who hates driving on highways? What happens to your plan if a portion of the interstate is under construction or a major crash backs up traffic for hours? What if you want to stop along the way to have a nice meal instead of zipping in and out of a rest stop along the side of the highway?
Upon further thought, A straight line from east to west may not be the best option. It is most certainly not the only option, in any case. And if you input your travel requirements and preferences into three different GPS services, you may very well end up with multiple but divergent routes. There isn’t any “one” way to get from Boston to Buffalo; the “best” travel route depends on various factors.
The same is true for network traffic between hosts, applications, servers, etc. Any given network may have dozens or even hundreds of network paths on which communication can travel. Many of those network traffic routes are unnecessary for normal business operations, but they exist (just like some dirt roads between Boston and Buffalo surely exist).
If you’re an infrastructure/operations or security professional and you consider how to protect every single traffic route between apps/hosts/services on your networks, it quickly becomes overwhelming—just like if you were to thoughtfully evaluate every highway/street/backroad between Boston and Buffalo. At some point, before your car trip begins, you have to decide which route you’ll take. Identifying the “best” route means incorporating your endgame (“driving from Boston to Buffalo”) while avoiding the interstate around Albany during rush hour and allowing you to stop at Dinosaur Bar-B-Que in Syracuse before finishing your trip. By defining your goals for the trip, you can then reduce the number of viable routes and focus your planning on only the routes that fit your requirements while taking into account time-to-destination and avoidance of construction.
In a network, you can’t limit the available paths to one (that would destroy processing), but you can limit the number of traffic routes networked resources can use by blocking unnecessary network paths and creating secure zones (i.e., microsegments or “collections”) inside which only verified applications and services can communicate. This, in turn, reduces the network attack surface, which results in a focused strategy for protecting the organization’s “crown jewels,” a.k.a., its data-rich applications.
The “how” is using microsegmentation to shrink the attack surface and the “why” is to achieve a targeted security strategy that protects your communicating assets.
If you’re in a situation where you’re trying to figure out if microsegmentation is the “best” strategy to protect your networks, pondering your options at a high level may lead you to conclude that microsegmentation is too complex (“there are too many traffic routes attackers can use to access my crown jewels!”), too costly (“I have to secure all the routes!”), and not scalable (“there are too many networked resources to protect across disparate environments!”). But if you stop for a moment and consider your use cases—decreased operational complexity and/or ubiquitous application-centric control across networking environments—it’s easy to think of other things (like driving to Buffalo for chicken wings) that simplify the decision process and make a thorny subject seem easier to navigate.
When trying to garner budget or support from a business-focused exec for a microsegmentation project, use an analogy to explain your request. You just might find it’s the best tactic for explaining “why.”