Demystifying Network Isolation and Micro-segmentation
A project management approach to designing, implementing, and operationalizing network isolation and micro-segmentation
Network segmentation or often referred to as network isolation is the concept of taking your network and creating silos within it called VLANs (virtual local area networks) that separates assets in the networked environment based on the function of the asset within the organization or some other schema you define to separate lower security levels from higher more restricted levels. With the growing prevalence of companies that are required to be PCI compliant, more and more organizations are needing to design and implement a segmented network and unfortunately, despite the amount of information on the topic, many fail before even getting started.
A big misperception is that if you implement different VLANs in different CIDR blocks/network numbering, you’ve achieved network segmentation. This couldn’t be further from the truth. To achieve actual segmentation, the hosts in one VLAN should not be able to reach every port of every asset in the other VLANs. In true network segmentation, you would set the default gateway of the VLAN on the switch to the firewall where the traffic can be further scrutinized based on specific ports, protocols, and traffic direction. As an alternative, but less scalable, is using VACLs (VLAN Access Control Lists) but can quickly become unmanageable, especially in large-scale enterprise deployments. These are however, quite suitable for smaller networks that have 1 or 2 core switches.
Now that we’ve defined exactly what network segmentation is, let’s discuss why it’s needed.
IT security circa 1990s to mid-2000, was to secure the perimeter. To be fair, the edge of most networks was quite porous and patching and vulnerability management was practically non-existent with many ways into networks being through buffer overflows in daemons like WuFTPD or Apache (read: the era of mass-defacements).
Things however have changed. Many networks now have a very hardened exterior and “soft gooey” interior network relegating the majority of compromises to web application attacks and spear phishes. However, because our “early years” were focused on hardening the perimeter of our networks, little attention was paid to the internal network making it a virtual playground for any bad dudes (sorry, I swear that will be my only Trump reference) to do what they want on any server because a lack of vulnerability management and flat networks is more common than not.
If we look back to many of the advanced persistent threat (APT) attacks that have taken place over the past two decades, you can point to issues rooted (no pun intended) in flat networks. For example, the Target compromise where the HVAC assets were being maintained by outside suppliers was on the same network as the point of sale (POS) systems in the store network that were processing and transmitting cardholder data.
Moving away from a flat network to a properly segmented network will allow you to implement the lateral security controls you need to pigeonholed an attacker or malware to a particular area of the network where the initial foothold was gained. While not ideal, there may be servers that also may not be patched against certain vulnerabilities. As such, network isolation can be your hail Mary in these circumstances that will prevent compromise of those servers if the network where the attacker or malware is attempting to pivot from is prevented from accessing those servers. As a matter of fact, there have been numerous incident response investigations that Brier & Thorn has performed where it was network isolation, not vulnerability management, that prevented the compromise of some mission critical servers in the environment and prevented a much larger-scale network compromise.
Okay, so now that we’ve discussed what it is and you now understand why you need it, let’s discuss how to implement it.
First thing’s first. Is this a new network implementation or will you be restructuring an already existing flat network? If you are restructuring an existing network, understand that particularly impactful to your project timeline will be the size of the network itself.
Having said this, being the project-focused person that I am, my recommendation is that you manage this using a formal project schedule and work breakdown structure (WBS). I’m not saying you need to engage the Program Management Office (PMO) in your organization here. My recommendation is just use a freemium cloud app for project management or use Excel templates for project management freely available from numerous project management sites. My recommendation is since there will be other stakeholders in this project, that you do leverage a cloud-based project management app so everyone in the organization involved in the project have access to their tasks and the project timeline.
Let’s review the plan based on the PMBOK (Project Management Body of Knowledge) 5 phased project.
Initiation: In this phase you will put together a presentation to sell to management why the network rearchitecture needs to happen and why having a flat network is bad.
Output: Powerpoint presentation and project plan
Planning: Once you’ve received approval to move forward with the project, you’ll want to create a WBS (work breakdown structure), defining the tasks of the project, which will then be brought into creating a project schedule where you’ll define dates and timelines for each task.
Most important to this stage is identifying your project stakeholders. If you’re in the IT security department, you’ll need to rely heavily on network operations and server operations as new DHCP pools will need to be created and servers will need to be re-IP’ed with new static IPs based on the networks you create.
Since I’ll assume that you don’t yet have updated network drawings of your corporate network, this might be a great opportunity to properly document your network architecture and create at least a set of logical network drawings along with the spreadsheet of new network segments you’ll be creating in this project.
- Project stakeholders matrix
- Spreadsheet of new subnets being created
- Revised/new network architecture diagrams
- List of affected enterprise applications
- List of required ports and protocols for enterprise applications affected by the migration
Execution: Once you’ve created your WBS and project schedule and allocated tasks to task owners in IT security, network operations, and server operations, it’s now time to perform the work.
It’s important that all enterprise applications, especially those that reach into any newly isolated networks, such as a CDE are tested post-implementation. It’s very easy for a port to be left out in the new firewall rules that may be required by an application.
Output: Any change control requests/change management windows
Control: It’s important throughout the project that you setup weekly project meetings to ensure that all project stakeholders are on top of their tasks and doing what’s required so that progress is closely monitored. No one wants scope or date creep, so stay on top of the entire project.
Close: Close out the project once all enterprise applications have been tested to be functioning properly and systems in the enterprise are reachable that are supposed to be accessible from the different network segments that were created.
In-scope PCI network versus the Cardholder Data Environment (CDE)
A confusing topic for many is what the difference is between the in-scope PCI network and the CDE. The PCI (Payment Card Industry) DSS (Data Security Standard) defines in-scope PCI assets as anything that can affect the security of the cardholder data environment. The cardholder data environment or (CDE) are all systems that transmit, store, or process cardholder data. For companies under PCI compliance, isolation of the CDE is critical to you successfully passing your annual QSA audits and also to protect your crown jewels.
Having said that, a common network architecture is to put systems, such as Active Directory servers that handle authentication for users and applications in the CDE in the PCI in-scope network along with other systems, such as security controls and servers that supports the business to leverage for performing duties on systems inside the CDE.
A common architecture Brier & Thorn implements in its security architecture engagements for PCI networks will be discussed in a future article along with the associated network drawings. We will typically place business support systems inside the PCI zone that require reach-in access into the CDE from outside the network.
While there is no one right way to do this, make it yours and be creative. “Draw outside the lines” and create something that makes sense for your network and organization. Having said that, there are some general guidelines you should follow when designing your different network segments.
- DO separate user workstations from internal servers. It is very common to find organizations where user VLANs are on the same network as internal mission critical servers which allows for minimal to no network filtering between the hosts except on endpoints.
- DO separate printers onto their own network
- DO separate VOIP phones onto their own network
- DO only allow the ports needed by the applications. If you don’t know what they are, this is an opportune time to work more closely with the application owners more than you ever have before to better understand their applications and requirements. Schedule meetings with each app owner and document the ports and protocols and traffic direction for each of their enterprise applications.
- DO define network security controls beyond VACLs for inspecting and acting on suspect traffic entering each VLAN.
- DO NOT consider the user VLANs as being a trusted network
- DO consider architecting the network in layers of trust from high to low like layers of an onion.
The below diagram is of course logical and not physical. Each of the four firewalls below could easily be a single firewall that all VLANs are hanging off of. Please don’t email me telling me that my proposed architecture is cost prohibitive and stupid. I’m just always thinking linearly, thus I prefer to draw things out in a linear way to better understand and present my line of thinking (no pun intended).
In this blog we discussed the importance of network segmentation, isolating restricted networks, such as a cardholder data environment or PCI zone, and we also discussed how to do it. I presented a phased project management approach to implementing network segmentation and also discussed the importance of working with the other functional areas of the business, including network operations, application owners, server operations, and IT security in this effort. Because of how many functional areas of the business are impacted and needed for this to be done successfully as well as the potential for applications to break with the introduction of new firewalls and changes to IP addresses, it’s important that those areas of the business be brought in as stakeholders in this project. This cannot be done in a vacuum.
For more information on micro-segmentation, I urge you to see the references section below or contact me with any questions.
Sun Tzu once said, “The art of war teaches us to not rely on the likelihood of the enemy not coming, but on our own readiness to receive him; not on the chance of his not attacking, but rather on the fact that we have made our position unassailable.”
Micro-segmentation for Dummies, VMWare: http://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/vmware-micro-segmentation-for-dummies.pdf
Originally published at www.alissaknight.com on October 23, 2017.