Micro-segmentation is regarded as one of the most effective methods to reduce attack surfaces, and a lack of it has often been cited as a contributing factor in some of the largest data breaches. Organizations have been discussing it for a long time, and there were good reasons to be apprehensive.
However, many of the barriers that once caused micro-segmentation to be a costly, complex process have been eliminated with SDN-enabled data centers: it is now a viable architecture.
Organizations implement micro-segmentation to block lateral movement within their networks. Two common types of lateral movements are insider threats, where employees or contractors gain access to data that they are not authorized to access, and ransomware.
SDN-Enabled Micro-segmentation
In traditional, on-premise data centers, companies had to rely on installing extra firewalls to segment their network - an expensive and time-consuming process. Fast forward a few years, and many organizations have moved to using virtualized data centers that employ Software-Defined networking (SDN). Because these data centers are software-driven, the fabric has built-in filtering capabilities, making internal network segmentation much more accessible.
With SDN, micro-segmentation can be achieved without adding new hardware. SDN’s flexibility enables advanced, granular zoning: In principle, data center networks can be divided into hundreds, or even thousands, of microsegments. This offers levels of security that were previously prohibitively expensive and complicated to implement in traditional data centers.
However, to capitalize on this great potential requires the organization to deploy a filtering policy that the micro-segmented fabric will enforce. Writing such a policy is the first, and largest, micro-segmentation challenge that organizations must address.
The requirements from a Micro-segmentation Policy
A correct micro-segmentation filtering policy has three high-level requirements:
It allows all business traffic – The last thing you want is to write a micro-segmented policy and have it block necessary business communication, causing applications to stop functioning.
It allows nothing else – By default, all other traffic should be denied.
It is future-proof – ‘More of the same’ changes in the network environment shouldn’t break rules. If you write your policies too narrowly, when something in the network changes, such as a new server or application, something will stop working. Write with scalability in mind.
A Micro-segmentation Blueprint
Now that you know what you are aiming for, how can you actually achieve it? First of all, your organization needs to know what your traffic flows are – what is the traffic that should be allowed. To get this information, you can perform a ‘discovery’ process. Only once you have this information can you establish where to place the borders between the microsegments in the data center and how to devise and manage the security policies for each of the segments in their network environment. Let’s break it down into some simple steps.
Carry out the discovery process
The process of micro-segmentation starts with mapping the application flows in your SDN environment. An automated discovery tool can identify, and group together flows that have logical connections to each other, such as those based on shared IP addresses, which indicates the flows that may support the same business application.
This discovery creates a map that identifies the flows, servers, and security devices within the data center that your business applications rely on to function correctly.
Define logical segments
Once you have discovered and mapped your business application traffic flows, you can define your segments, deciding which servers and systems should be placed in which network segment. This is done by identifying and grouping together servers that support the same business intent.
Create the filtering policy
Now that the segmentation scheme is outlined, you need to write the security policies. Traffic confined to a segment is automatically allowed, so you just need to write policies for traffic crossing micro-segment boundaries. There are two types of flows that require rules to be written: cross segment flows and flows to and from outside the data center.
Gradually building the policy
To avoid major connectivity disruptions, you need to gradually build the policies. You do so by writing a default “allow” rule at the end of the policy, and turning on logging for this “allow” rule. You then go over the applications you discovered earlier, write the specific policy rules that support each application’s cross-segment flows, and place them above the default “allow“ rule. Each application’s rule you add to the policy should decrease the amount of logs triggered by the default “allow” rule. You need to keep adding rules, application by application, until the final “allow” rule stops generating additional logs, and you are ready for D-Day (“D” for “deny”).
Micro-segmentation D-Day
This is the day when you flip the switch: you change the action of the final default rule to be “deny” and enforce your new micro-segmentation policy. Once you do this, all undiscovered traffic will be denied by the filtering fabric, and you will finally have a secure, micro-segmented, data center, which is a big deal.
It’s important to keep in mind that D-Day is going to cause a big organizational shift. From that day forward, every application developer whose application requires new traffic to cross the data center will need to ask for permission to allow this traffic.
Manage change requests
After D-Day, any changes in application connectivity will require filing a change request. To carry out a change request, your security team has to establish which specific policy rules need to be changed and what those rules should be. It’s also necessary to run a what-if risk-check, which compares each change-request with the acceptable policy, and flags any discrepancies before the new rules are deployed.
Continually maintain your network
Implementing micro-segmentation isn’t the end of the story. Once you have deployed your micro-segmentation scheme, you will need to manage and maintain it, ensuring it works in harmony with security across your entire network. Application traffic needs to flow seamlessly across both your SDN, on-premise and cloud environments, and over your wide-area networks, so it is critical to ensure that your processes support this.
Whilst network maintenance is a labor intensive process when carried out manually, an automated solution can take away much of the work from you, managing all the security controls in your SDN environment and making sure that the security policies governing your segmentation strategy are consistently applied and managed across your entire network estate. An automation solution will also track any changes for audit purposes.
This in itself can be a complex and time-consuming process, especially with multiple change requests per day. However, as with security control management, the change request process can also be fully automated. Automation solutions proactively check every proposed rule change request against the segmentation strategy to ensure that the change doesn’t break the segmentation strategy, introduce risk, or violate compliance requirements.
The bottom line is that implementing an effective network micro-segmentation strategy is now possible. It requires careful planning and implementation, but when carried out following a proper blueprint with the right automation systems, it provides you with stronger security without sacrificing any business agility.