Establishing isolated security zones within an enterprise network is an effective strategy for reducing many types of risk, and this is especially obvious when one considers how permeable networks are today.  The old perimeter defense model is no longer sufficient.  Some would argue it is no longer necessary — that de-perimeterization is inevitable, we should prepare for a future of blended networks without clear boundaries and security should be moved inward.  Ultimately, all security is about protecting a valuable asset – data – but that protection involves a defense-in-depth strategy that includes all layers.

Security at each of these layers is important, since weaknesses and vulnerabilities can be exploited at each one to affect the confidentiality, integrity, or availability of the information we strive to secure.

A true defense-in-depth approach goes far beyond the typical “hard outer shell, soft gooey center” approach common in so many enterprises.  While strengthening application security, and setting up monitoring services to establish data access baselines or detect data leakage are front-and-center in many organizations (and these are important efforts), network and host layer security is no less important to reduce attack surface and minimize risks.  If organizations acknowledge that insider threats are real, then internal security zones are extremely valuable and produce excellent long-term returns for the initial level of effort required for setup and ongoing maintenance.

What is a security zone?

A security zone is an area within a network occupied by a group of systems and components with similar requirements for the protection of information and the attendant characteristics associated with those requirements.  These shared requirements and characteristics will include:

  • A common data classification, including shared…
    • Data confidentiality and integrity requirements
    • Access controls
    • Audit, logging, and monitoring requirements

These common characteristics and requirements inherently lead to some level of isolation, but this isolation occurs not just between security zones, but also within security zones.  Remember, this is all about data.

Security zones are often layered as trust zones such that resources in higher trust zones may communicate with resource in lower trust zones, but not the other way around.  In the diagram below, security zone #1 is at the lowest level of trust, while security zone #4 is at the highest.

The most common intra-zone isolation is based on application architecture tiers.  These tiers can be thought of as subzones, but the same principals apply.  For example, the presentation tier (web servers) needs to communication with the business logic tier (application servers), which in turn needs to communication with the data tier (database servers).  However, application servers do not initiate communication with web servers, etc.

The Goals of Security Zones

In a nutshell, security zones are put in place to:

  1. Control inter-zone communications (including between subzones).
  2. Monitor inter-zone communications using IDS/IPS, correlate and elevate alerts for events using a SIEM, monitor for and prevent inter-zone data leakage using a DLP solution, etc.
  3. Control management access into, out of, and within a zone (e.g., controlled with jump hosts or jump networks).
  4. Enforce data confidential and integrity rules for data stored within a zone, as well as for replication and backup.

How are security zones established?

As I see it, there are several steps to establishing security zones.

Per-Zone Requirements

The first step must identify the unifying, but coarse-grained attributes that lead to a natural grouping of systems and applications.  These attributes should coalesce first around the value of the information that is stored and then exposed through applications, and second around the requisite communication patterns that need to be supported for proper functioning of the systems and applications.  One method for identifying candidate zones is a risk-based approach that correlates closely with data classification levels.  The communication patterns are generally dictated by business requirements, but should be as general as possible to reduce complexity and risk while maintaining a level of control that adds value.  Carefully mapping these communication patterns is crucial to the success of any segregation into security zones.

If systems or applications have very specific requirements, then this is a good indication that they require special treatment in their own security zone.  These could be certain financial systems, human resources systems, source code repositories, etc., but their treatment will no doubt center on the value of the information held within those systems.  A shared services zone is probably required with services needed by all other zones such as authentication, directory, general file services, etc.

Enterprise IP Address Schema

To efficiently support the use of security zones, a well thought out IP address schema must be in place.  This provides the underpinning for true network segregation and the creation of the access controls and network models that will be used in security policy enforcement points, auditing and logging, and monitoring solutions.  It is important to recognize that this is not just for firewall rules or router ACLs.  If security zones cannot be cleanly covered by adjacent address space, everything becomes more difficult to implement and maintain.  If you are fortunate enough to have the opportunity to fix problems with inconsistent or poorly organized address space, seize it!  This may only come along once in your entire career — don’t let it pass by without making the most of it!  See this post for more details and sample approaches.

Network Segmentation

A common misconception is that security zones and network segmentation are one and the same.  Network segmentation is just one of the building blocks of security zones.  It can create isolation at one or more layers using physical or logical separation.  For example, separate hardware and network pathways can establish physical separation, VLANs can establish layer 2 separation, and the use of VRFs, for example, can establish layer 3 separation, but none of this is really effective without access controls to enforce acceptable communication patterns, i.e. controlled isolation, not just separation without restrictions.  Subzones are just further subdivisions of the address space set aside for a larger security zone.  Not all workstations and servers need to communicate with each other, so why should we allow them to do so without restriction?  Of course there is operational risk associated with establishing restrictions, but with a quickly evolving threat landscape at different layers, the consequences of maintaining the status quo could be costly, and this alone can tip the balance of the risk-reward equation.

Identifying Control Points

If you have established cleanly segmented areas of your network for different zones, then next step involves identifying the interfaces between different zones or subzones.  It also involves identifying zones or subzones of interest — that is, places where you may wish to deploy additional instrumentation for monitoring and alerting.  When unusual events occur near the crown jewels, you need to pay attention!

These interfaces or specific areas are where various controls can be established.  Where and how depends on the what exactly is needed, but these will relate closely to the communication patterns discovered while establishing per-zone requirements.

Implementing Access Controls

Some controls will be active (e.g., actually block network traffic) while others will be passive (e.g., monitoring).  Many active controls can be initially deployed in a passive many such that they do not alter communications patterns.  For example, instead of following all of your expected permit rules with a ‘deny all‘ rule, add an ‘allow any‘ rule with logging.  This way you can discover what traffic will be blocked if you converted it to a ‘deny all‘ rule, determine if legitimate traffic patterns have been overlooked and iteratively make adjustments.  It may be important to operate in this manner for a good amount of time so that the controls can be fine-tuned before being made active.

Virtualization – the fly in the ointment?

Most data centers are making increasing use of virtualization technologies to achieve better economies of scale, reduce deployment times, and make efficient use of hardware.  What impact does this have on security zones?  Components that would normally be separate physical instantiations can now exist within the confines of a single physical platform.  The principles are much the same.  VMware has a whitepaper that lays out the issues and some approaches — it’s worth reading.  An ideal approach involves assigning physical virtualization servers to one zone, rather than allow VMs from different zones to co-exist on the same hardware.  However, this may not be achievable in the short-term. VM-to-VM traffic can be controlled, but with added complexity.  Teasing apart VMs onto different physical servers carries its own risks.   Choose a balanced approach that is best suited for your situation.


There are different approaches to security zones and many more ways of implementing them.  The days are gone when enterprises can assume that all the bad stuff happens outside of their network.  Perimeters are porous and the threat landscape is changing rapidly.  My mantra is simple:

Prevention is the goal, but detection is a must!

Breaking up a network into security zones helps to provide better visibility into places of greater importance, and without visibility there can be no control (or detection), and therefore no real security.