It seems like the idea of micro-segmentation is everywhere today. Considering that the modern corporate perimeter is vastly different than that of the past, with our dependence on cloud based resources, mobile devices and third party vendors, what worked to protect it back then is no longer sufficient. It’s becoming clear that micro-segmenting networks is the way forward in a security landscape where traditional tools are failing to protect whatever is left of the disappearing perimeter.
In Forrester’s 2017 Gauge Your Zero Trust Maturity report, they detail how micro-segmentation has become a crucial element in any security architecture, but they aren’t the only ones praising the model. The concept is garnering more and more attention by leading security experts because it’s one of the most effective means of preventing lateral movement within networks and it’s time and cost effective too — a typical VLAN segmentation deployment for a small number of applications can take many months months and eats up hundreds of hours of IT staff time; a properly deployed micro-segmentation deployment of similar parameters takes about a month and consumes far less time to set up.
Getting it right, the first time
Before you begin your micro-segmentation journey however, there are some aspects to consider. Establishing a solid micro-segmentation deployment isn’t a 1-2-3 process. It needs to be approached with deliberate forethought and cannot be slapped together. Doing it the right way the first time ensures that your micro-segmentation project will remain cost and time effective when viewed against other extended projects that don’t effectively segment, let alone secure, networks.
Here are some of the most important things you need to think about as you embark on your micro-segmentation project. This post will focus on the ‘before implementation’ stage to help facilitate your journey to a successful micro-segmentation deployment.
Micro-segmentation considerations – Before deployment
Understand what you want to segment:
Before you do anything, decide what needs segmenting and why you want to segment it. This is critical because what you are going to segment will impact how you do it. For example, if you need to comply with industry regulations like HIPAA, SWIFT or PCI, your micro-segmentation project must start with ensuring that the areas in which those asset are housed are ringed off immediately. On the other hand, if you’re considering micro-segmentation with an end goal of general risk reduction, you’ll need to start with segmenting your most sensitive assets first and then move on to segmenting the less sensitive areas in a phased approach.
Go after short term, then long term, priorities:
Yes, you already know that your long term priority is improving your overall security posture and reducing your organizational risk. But to get there, you need to prioritize your segmentation goals. Start with simple micro-segmentation tasks which significantly reduce risk (for example, blocking insecure protocols such as telnet or FTP, or forcing SSH traffic through a specific jumpbox), and then proceed to a more thorough policy (such as application and tier segmentation).
So start with identifying and prioritizing and prioritizing your goals — then you can put the plans to implement them into action.
Build a picture of your environment for visibility:
Building a clear visualization of your environment will help you roll out your robust micro-segmentation implementation. The initial picture of what you think you have running and connected is inherently limited — so be aware, as you build out that detailed plan, you’re likely to discover connections and dependencies you had not thought of before. With this in mind, you may need backtrack just a bit to incorporate the aspects that were initially missed to create that comprehensive and accurate map. Once you’ve got this picture, you can begin to map all your dependencies which will help you understand where you need to create and enforce rules.
Decide which labels you’re going to use:
Based on the goals you established, figure out which labels you need. Labels are snippets of metadata attached to workloads, which provide context regarding that specific workload. For example, a server might be labeled with “Production Environment”, “PCI compliant” and “ERP application” labels.
Properly labeling your workloads is critical to the success of your microsegmentation deployment. Thus, it’s important to have flexibility in this process, instead of trying to force yourself into existing, limited options. Labels can and should be adapted to your specific organizational needs — for example, if you need application segmentation, use the “Application” label type. Need to segment your PCI compliant machines from others? You probably need a “PCI compliant” label. The important part is that they can be augmented to reflect your unique business requirements.
ID your information sources:
Identify the sources of information from which labels are going to be imported to your micro-segmentation solution. Labels can be found in various places: Public Cloud instance tags, Kubernetes labels, orchestration platforms, CMDB systems and more. Once this is done effectively, you can plan (and later implement) a way to extract the information from these sources into your micro-segmentation solution. At first this might be a semi-manual process, but long term, the goal is to create a fully automated, reliable solution here.
Further considerations for a successful micro-segmentation deployment
Congratulations – you’ve laid the groundwork out for your micro-segmentation project. But there is more to be considered to make sure your deployment is solid and seamless. Want to find out about the next set of key considerations for ensuring micro-segmentation success?