The desired effects of microsegmentation are clear. They include:
- Limiting the “blast radius” of a data center or cloud environment compromise
- Preventing lateral movement of threats within the environment (which often facilitates an attack)
- Supplying fine-grained controls to applications running in the environment (which prevent lateral movement)
An effective microsegmentation project defines and analyzes the inherent characteristics of its workloads so that the IT organization can describe what each cloud/data center workload will manage (i.e., what type of data or applications), and how and by whom it will be used. This process allows the organization to accomplish granular segmentation through individual controls that are based on the nature of each workload.
Though microsegmentation is an architectural model created to ensure security in the cloud or data center, its implementation and management are not as clear as its intended goals. For one thing, any impact on the network means that networking teams must be involved, and while microsegmentation that is based on software identity does not require any architectural changes, any excess pathways that are not used by the application will be removed. Therefore, any organization considering a microsegmentation project needs to decide who is involved and at what level.
The argument for infrastructure
Network operations teams are responsible for network, data, and application management inside the organization's network environment. This responsibility is not abdicated when the networking occurs inside a third-party provider environment, in other words, in a public or private cloud. The challenges may be different, but the burden remains the same.
Traditionally, networking teams define policies for routers and switches. In the cloud, where a physical boundary isn’t present, NetOps is still required to define rules and policies for how applications and services communicate, even when the tools and techniques differ. Under NetOps’ charge is asset inventory, policy configuration and ongoing management, and traffic analysis, among other things. Accompanying these responsibilities is a requirement to maintain network performance and uptime, whether the infrastructure is on-premises or virtual.
It’s these two latter responsibilities which often put networking teams directly into conflict with security teams, and also why the oversight and implementation of microsegmentation projects can be controversial. Microsegmentation projects using traditional tools like firewalls and other address-based technologies are complex and costly.
Some of the more common “headwinds” to starting or applying microsegmentation include:
- Translating network speak into application speak to apply effective policies
- Managing thousands of policies
- Managing different sets of policies for on-prem and cloud environments
- Understanding application dependencies
The above bullet points fall under the authority of NetOps, even though SecOps will likely have to be involved.
The argument for security
Microsegmentation was originally devised as a way to compensate for the vulnerability of flat and overly permissive networks by creating “microperimeters” around critical applications or collections of like data, such as “HR data” or “finance data.” Moving perimeters inside the network allows security practitioners to measure and reduce risk and conduct vulnerability assessments for the environment. These are clear security responsibilities.
Similarly, the goals of microsegmentation listed in the bullet points at the top of this document fit squarely into security’s realm. There is, however, significant crossover between SecOps and NetOps. This has been the case for as long as security became its own domain expertise. Security is responsible for what happens when policies are applied to the environment, but networking is responsible for applying the rules. In today’s hyper-aware cyber-incident world, SecOps teams have become more heavily involved in creating and monitoring rules, but the fact remains that security teams will always favor the confidentiality and integrity of workloads over availability. NetOps is the exact opposite.
Can’t we all just get along?
Zero trust networking is the backbone of many microsegmentation projects, and ironically it’s zero trust that allows for speed and efficiency and optimal security. With least-privileged access at the heart of zero trust, cloud and data center workloads can communicate as intended and necessary while remaining protected. Microsegmentation facilitates cloud workload protection but also means that NetOps and SecOps must come together more closely than ever before to meet business objectives (not just IT and/or security objectives).
Many microsegmentation projects fail because they’re too complex, costly, and often the network constructs on which controls are based don’t work well in a virtual environment. As a result, networking and security teams must work together to choose the tools and techniques best suited to implementation and management of microsegmentation. Contrary to industry lore, there is no one or “preferred” way to conduct a microsegmentation project, and few of these projects can be taken on wholesale by any organization.
Though improved cybersecurity control—especially for cloud environments—was the desired intention of microsegmentation, networks and networking teams will be affected in terms of resources and performance, understanding baselines, identifying and visualizing abnormal traffic and application flow patterns, and configuring and managing policies. Security teams will need to remain consistently involved with advising on policy refinements to reduce risk of exposure, detecting and responding to possible policy infringements and security incidents, and ensuring technologies and processes are compliant with cybersecurity best practices.
OK, so maybe this quick blog post is a bit of a copout. Then again, at the foundation of cybersecurity is NetOps-SecOps collaboration and cooperation. Security grew out of networking, after all, and now as its own, much more complicated discipline, security teams cannot forget that the systems and data they’re charged with protecting are reliant upon good networking practices.
