Defining an Achievable Network Segmentation Process

The modern enterprise network has undertaken massive changes over recent years. The adoption of cloud computing, consumerization, mobilization, and the explosion of the “app” markets, has driven us all to use technology in new ways. We must embrace these new technologies and the business edge that they can offer, but all the while we need to recognize that just below all of this new technology there is something supporting it that hasn’t changed. The security infrastructure they depend on to deliver safe and controlled service.

While networking technologies continue to innovate and push new boundaries in regards to throughput and speed, the network architecture we design and implement to deliver these new services to the enterprise has not evolved at the same rate. Security teams are consistently forced to make trade-offs between what they can and cannot achieve in terms of monitoring and control over new network services where they have not been able to provide design input. If network security continues to be simply thought of as a bolt-on technology to networking this negative trend will only continue.

John Kindervag from Forrester recently introduced the concept of the “Zero Trust Network”. This is an idea that I like because it is driven by complete segmentation, and I believe segmentation is critical for any manageable, and therefore potentially defensible, network. Kindervag’s approach doesn’t take segmentation to an extreme as such; it drives the segmentation concept to a level where it should ideally operate. Complete segmentation of all resources where all communication is undertaken through a “secure segmentation gateway”. Moving to this model will however take time, and much planning, but in the shorter term there are things that can be done to get quicker segmentation “wins” for the business and security group wile building the foundations that can be used in the future as part of a “Zero Trust Networking” implementation.

Network segmentation is the process of logically grouping network assets, resources, and applications together into compartmentalized areas that have no trust of each other. There has been a recent drive towards retrofitting network segmentation into flat networks over recent months due to PCI DSS (Payment Card Industry Data Security Standard) projects. This has primarily been a financially motivated segmentation decision, as the scope of the PCI DSS requirements can be reduced to specific areas (or segments) of the company network rather than apply to all of it. Certification can then be granted based on that segment alone. Although I strongly stand behind the concept of segmenting for security, creating only a single secure segment while ignoring everything else is in my opinion far from good practice. It may deliver to a compliance tick, but not security.

When looking to introduce network segmentation there are some key requirements to take into consideration:

• Gain visibility of traffic, users and assets
• Protect communications and resources on both inbound and outbound requests
• Implement granular controls on traffic, users and assets
• Set a default deny policy on all inter-segment connections

Any phased approach of network segmentation should follow these four steps in order, and focus on only a single segment at a time. Start off with areas that look simpler to segment away from the wider network such as development or test areas. Pick the lowest hanging fruit first, and learn small lessons on they way to the more complex areas.

Step 1) Gain Visibility:
If you don’t understand the traffic profile for a proposed segment in regards to ingress/egress communications, any access controls implemented will fail. You must understand how the network you are looking to segment is actually used. Expect a disconnect between what you may believe is occurring, and what in fact is occurring.

Step 2) Protect Communications and Resources on Both Inbound and Outbound Requests:
The primary goal of segmenting for security is of course security. If you have no ability to exert protection of resources within a segment your objectives will not be met. Simple access controls between segments is not enough, you need the ability to react quickly to any detected threat. This protection can of course be delivered through application network level security controls.

Step 3) Implement Granular Controls on Traffic, Users and Assets:
All data entering and leaving a segment should be controlled. As protection has already been implemented (in the previous step), we know that any communications that enter or leave the segment will have had a level of security protection applied to it. We are now in a situation where a company’s communication policy can be implemented with granular access controls. Even though there should be a good level of understanding of the communications that take place with the segment from outside (achieved in step 1), these controls should be implemented in a two-step process. Detective controls, followed by preventative controls. I recommend that initially a default-allow control is implemented while a company works through understanding and investigating the traffic they find that is unexpected, and sure enough you will find the unexpected.

Step 4) Set a Default Deny on all Inter-Segment Communications:
Now that visibility is achieved, communications are protected, an access policy has been implemented in a default-allow state, it’s time for the last step. Move to a default-deny security posture for all inter-segment traffic. Only when a default-deny policy is in place is the segment successfully separated from the rest of the network and able to operate as it’s own logical unit.

Implementing the first few segments in a large network will be a daunting task, but the long term rewards in regards to simplified management and a deeper understanding on inter-segment traffic are there. One such benefit is the compartmentalization of each segment. If, or rather when, a security compromise is detected, controls are in place and ready to be used to limit the scope of that compromise.