WHY SHOULD WE SEGMENT OUR NETWORKS?

WHY SHOULD WE
SEGMENT OUR NETWORKS?

Written by
Adrian Azar
Senior Consultant III                       

Jose Arteaga Portillo
Senior Consultant III

Donald Meza
Senior Network Engineer

Peter Shand
Chief Technology Officer, Americas

As cyber threats continue to increase exponentially, and the concept of cyber-risk becomes a constant concern even in less sophisticated IT environments; there are quite a few priorities from a technology procurement as well as a project perspective that IT executives tend to focus on:

  • Managing event logs solutions (SIEM) or external SOC services
  • Data Loss Prevention / Data Encryption
  • Vulnerability Management / Intrusion Detection Systems / Intrusion Prevention Systems
  • Anti-spam / Anti-spyware / Anti-phishing /Anti-Virus solutions
  • Next Generation Firewalls
  • Backup and Disaster Recovery

This list is not complete but represents some of the more prevalent concerns of IT executives and SecOps teams. However, when discussing security operations and corresponding “internal” projects; network segmentation invariably gets raised as a topic for discussion or as a “frustrating” initiative that was started and was never completed.

Segmentation is the division of a network into smaller groupings of interfaces that can be referred to as zones. These zones consist of IP ranges, subnets, and/or security groups designed to improve performance and reduce the attack surface by limiting lateral movement across the network.

In greenfield environments, it is easier to plan and deploy a properly segmented network. However, it is much more difficult to do in flatly designed existing environment. The main difficulty is that it usually requires IP address changes, which in many environments, can cause application failures/outages if not properly planned and executed. Despite the possible hurdles, implementing a properly designed network is necessary, as a basis on which to incorporate the security controls required to protect data assets in an increasingly dangerous threat landscape.

Unified Tech has a cornucopia of talent, so as part of the exercise of preparing the report, we incorporated the thoughts of some of the senior resources -regarding how segmentation affected their specific area of expertise:

Our Senior Collaboration SME had these key points to share:

  • Network segmentation helps keep collaboration traffic very controlled as this traffic is very sensitive to delay and congestion.
  • It also helps with quality of service (QoS), as most network switches can control traffic using hardware as well as software and the segmentation helps with the management of this traffic QoS policies.
  • Collaboration traffic has very well-known patterns, so segmenting the network properly allows for creating very specific baselines. These baselines can be used to detect anomalous behavior and thereby identify and stop threats from using the collaboration network as an attack vector.
  • Path isolation is of uttermost importance given the nature of collaboration traffic. Doing unequal cost load balancing through the network or having asymmetric routing can have unexpected and unwanted behavior for this traffic.

We typically consider our edge and demilitarized zone (DMZ) networks to be protected and by their very nature, segmented; however, our Senior Financial Services Technology Architect had these thoughts:

To achieve the highest levels of protection, even the DMZ should be properly segmented. This could be based on the nature of the asset being secured or the nature of the resources accessing that resource. Below are some considerations for resource/network segmentation:

  • The External DMZ
  • This DMZ is used to publish all services that need external access. It is called the external DMZ because it has public IPs addresses without NAT’ing (network address translation). If a resource (e.g. router, or load balancer), needs external public IP, the external interface is connected here.
  • The Standard DMZ with external public services
  • This range includes the NAT’ed public addresses used to publish services/resources externally.
  • The Internal DMZ
  • This range has the internal interface for the devices that interact with external resources (e.g., management interfaces for load balancers and routers). In this environment, the firewall can check all traffic from the internet as well as traffic that may be destined for the more highly protected internal resources.
  • The Vendor DMZ
  • This is DMZ for the LAN interface of the vendor or partner devices. This configuration allows the network and CyberOps teams to control what the vendor/partners can access and allows for the option to hide internal network using the NAT’ing. It provides an added layer of protection if a partner/vendor gets compromised in some way.

Additionally, one of our Senior Security SME’s had these notes:

Segmentation is critical, but it can introduce management and operational overhead as networks become more complex.

  • Campus networks should seek to employ automation where possible, by leveraging software that can implement and enforce segmentation rules dynamically based on device type, device behavior, threat detection etc. as opposed to only at the point of provisioning when a more manual approach is used. This is increasingly critical as a significant percentage of cyber breaches originate from internal resources such as compromised workstations and mobile devices.
  • In the Datacenter automation should also be leveraged, because it can separate and protect critical resources based on the nature of the communication with other assets. Also leveraging technologies like private VLANs could provide added layers of protection so these important data assets are truly isolated from the rest of the network but still allow only needed access for applications and users, etc.

 

There are many ways to achieve good segmentation and there are a plethora of good reasons to achieve this initial goal. It is, however, a moving target because as the needs of the business change the network must evolve (usually first) to support it. The first step is to categorize your assets e.g. (usersdevicessystems and applications) as well as define the network locations to which these assets belong or need to communicate with (e.g. insideoutsidecloud or vendor). Based on these categories, we can develop the process of creating a design and the corresponding policies for protecting the different classes of assets. This is just an introduction as the topic can become very complex very quickly, but this is one instance where a little complexity may go a long way in helping to secure our networks.