Logical Security Zone Pattern

From The Secure Arc Wiki

Jump to: navigation, search

As described in the book, Voice Over IPv6: Architectures for Next Generation VoIP Networks Voice Over IPv6: Architectures for Next Generation VoIP Networks, "Companies typically see the environment comprised of the following zones (also known as domains)." This Design Pattern is based on our own extensions of this common approach and our experience in various organisations.


Design Pattern

Pattern Name

Logical Security Zone Pattern


The primary purpose of this architectural pattern is to ensure enterprise systems are designed with the big picture in mind in a secure manner.

This should be used as a guide in at least three points during the Software Development Lifecycle

  1. Infrastructure Design
  2. Application Architecture Design
  3. Application Component/Interface Design

This provides a template to guide all design decisions in the three areas identified above.

At every point a decision needs to be made about where a component, service or server should reside or how it should communicate with another, it just needs to be dropped in the appropriate zone and all of the rules satisfied.

Motivation (Forces)


This model should apply to all enterprise systems regardless of whether they are critical 3 tier systems or static content web servers. Any entry point into an organisations network is a potential point of attack and any system deployed in the same environment as another are inherently subject to the security vulnerabilities of the other.


The pattern consists of a set of pre-defined Logical Zones where servers reside. These typically mapped to physical networks and subnets.

Level of Trust

The underlying concept behind the zone model is the increasing Level of Trust from outside into the centre. On the outside is the the Internet. There is zero trust here. It's in the Internet that any anonymous attacker or Script Kiddie resides. In the centre is the Data Zone. It's in here that the most sensitive data is stored.

The Rules of the Logical Security Zone Model state that communication between Zones must only originate from an adjacent Zone. Within and between each Zone are countermeasures such as firewalls, URL based access controls, Mutually Authenticated SSL (MASSL) point-to-point connections and J2EE declarative and programmatic role based access controls. The granularity of the authorisation level typically increases from outer to inner zones, however in most cases the connection to the data repository in the Data Zone is as an application System User rather than an End User's level. This means that the finest grained authorisation is actually enforced in the Application Tier.

The Internal DMZ and Staff Intranet are analogs to the Internet DMZ and the Internet. The concentric zone model clearly reflects that the Staff Intranet is basically as untrusted as the Internet and consequently the enterprise systems need to be just as protected from the Staff Intranet as they do from the Internet.

Within the Global State of Information Security report for 2007, the following statement is made:

This year (2007) marks the first time “employees” beat out “hackers” as the most likely source of a security incident.

Many organisations consider the staff intranet to be sufficiently secured, but when you consider contractors, laptops moved between home and work, iPods and other mp3 players potentially infected with viruses plugged into work PCs and staff turnover, the chances of some form of compromise are very high. A google search for "disgruntled employee" network security returns around 10,000 results.

There are also some highly public multi-billion dollar cases in the news recently.


Each system resides in a Silo. The Silo cuts across the three primary Logical Security Zones and in a highly secure environment, are isolated from each other with firewalls. Generally speaking a lot of large enterprises do not isolate individual systems from each other in this way, doing so will depend both on the sensitivity of the assets that require protection, the paranoia level and ultimately the budget available. The primary goal of this is to compartmentalize separate systems to minimize the impact of a compromise of one on another.

If one system needs to handle credit card data and be PCI compliant and another only serves up marketing material, the former will need to be physically isolated from the latter with firewalls between them. The security employed on the marketing website will most likely only be to the extent required to protect publicly available information. If a compromise of one of these servers results in a compromise of one of the credit card processing servers, all the money spent on security of the other system is of little value as the weakest link in the chain isn't actually part of the same system, project or budget.

Logical vs Physical

Both the Logical Security Zones and the Silos need not necessarily be realized as physically separate environments. When designing a solution, regardless of whether each zone gets its own isolated subnet or not, the logical model should be adhered to. When that Logical model is then mapped to a physical Infrastructure design, an Architectural Decision will need to be made as to how many Logical Zones map to how many physical zones.

During the process of identifying potential Vulnerabilities, the Attack Surface Area will be assessed based on all of the potential entry points into the system. This will include the operating system level access from one host to another across Silos. If this ultimately identifies a substantial risk associated with a compromise of a less secure system in the same Zone, a decision to isolate the Silos should be made.

Demilitarized Zone (DMZ)

In a lot of organisations, the DMZ is referred to as a subnet isolated by firewalls. The definition of a DMZ as used in network security originally came from the military definition, which is basically an unoccupied area between two opposing forces.

The DMZ in network security context is an area between secure networks and untrusted networks. There should be a DMZ between the internet and the protected systems and the staff intranet and the protected systems. As described above, sensitive Information Assets and systems need to be protected from the staff intranet almost as much as they do from the internet.


The participants in this pattern are the Zones and Silos.

Zone Description Adjacent Zones Node Types
Internet aka: Uncontrolled. The vast majority of End Users in this Zone are unauthenticated and unidentifiable. This is where both legitimate End Users and Malicious Attackers are found. Trusted Third Parties,
Internet DMZ
Web Browsers, Hacker Tools
Trusted Third Parties aka: Externally Controlled . This represents a 3rd Party Business Partner Site. Business-to-Business (B2B) connections originate and terminate in this Zone. Outside of Service Level Agreements (SLAs), there is little or no control or visibility over the security policies of this environment. While it may be secured, it is not necessarily conforming with internal security policies. Internet,
Internet DMZ
3rd Party B2B Services
Internet DMZ aka: Controlled. This the no-mans-land between the untrusted networks and the trusted. All traffic should travel through the Internet DMZ to reach the Trusted Systems and vice versa. The Nodes deployed in this Zone should be kept to a minimum and be as simple as possible. Internet,
Trusted Third Parties,
Internal DMZ,
Web Servers, Reverse Proxies
Staff Intranet aka: Internally Uncontrolled. It’s within here that employees connect their desktop PCs and their laptops. Staff Intranet,
Internet DMZ
Staff PCs, iPods, Disgruntled Employees, Contractor Laptops, Home Laptops, USB Keys, Portable Hard drives
Internal DMZ aka: Internally Controlled. This is the equivalent of the Internet DMZ, but is specifically for the internal staff. It typically maps to an Internal DMZ separating the staff intranet from internal systems. Staff Intranet, Application Web Servers, Reverse Proxies
Application aka: Restricted. In order to access this Zone, an End User must have traversed the Internet DMZ or Internal DMZ and satisfied all of the authorisation constraints required to do so. With the exception of the Silo dedicated to the security sub-system required for authentication in the Internet DMZ, End Users should have been authenticated prior to initiating any requests in the Application Zone Internet DMZ, Internal DMZ, Data, Management Web Servers, Application Servers
Data aka: Secured.Database, LDAP Repositories and Access Control Policies Stores should be deployed into this Zone. The Data Zone requires the most effort to compromise, as an Attacker must compromise the access controls at all of the outer Zones before getting into this one. Application, Management User Repositories, Data Repositories, ACL Policy Stores
Management aka: Secured Management. Administrators and monitoring systems need access to all of the Zones. Having a physically separate Management network allows these administrative entry points to be locked down to specific rooms or floors in a building. Within the Management Zone, further controls can limit who and how administrators can access each of the Zones. For example, Database Administrators shouldn’t need access to the Internet DMZ or Application Zone. Controlled, Restricted, Secured Monitoring Tools, SSH Clients, Provisioning Servers

In addition to the Zones, there are also the Silos

Name Description
Silo(s) Each Silo defines the boundaries of a particular system, spans multiple Zones and may be also be nested. Nesting allows various sub-systems to be 'scoped' within an environment, such as Integration Test, User Acceptance Testing and Production. The Silos should be isolated from each other to prevent the compromise of one from impacting the other.


The Rules

In its simplest form, the rules are very simple. The rules basically state that Nodes in one Zone can only communicate directly with Nodes in the same or adjacent Zones. When a Node in one Zone needs to communicate with a Node in another Zone that is not adjacent, some form of proxy should be placed in the intermediate Zones.

The allowable communications paths are represented in the diagram to the left.

Some enterprises have strict rules around the allowable directions communications may be invoked. The model above allows bi-directional access between all zones. The second diagram to the left shows a more restrictive model where communications can not be established from one Zone to a less trusted Zone.

Silos should define the boundaries of each isolated system, however there are many cases where systems need to communicate with each other, particularly in a Service Oriented Architecture (SOA). As shown above, the Silos cross multiple Zones. The rules shown above apply within the Silos, however when a Node in one Silo needs to communicate with another Node in a different Silo, they both must reside in the same Zone.

The reasoning behind this is quite straight-forward. Within a Silo the level of Trust increases from outer most zone to the inner most zone and all of the access controls that have been put in place to establish that trust are tied to a particular system. This is due to the CVSS rating associated with that system, the budget given to it and the experience of the people who deliver it.

For example, if Silo 1 is extremely locked down and Silo 2 has very little in the way of security and is allowed access to the Data Zone of Silo 1 from its Application Zone, then an attacker could bypass all of the controls in Silo 1 by taking the path of least resistance through Silo 2.

Information Asset Classification

Asset Definition
Asset Definition

As the Logical Security Zone Model is created for a particular system, all of the Nodes, or Infrastructure Assets, identified should be tagged with the Information Assets that are stored on or pass through that Node.

The details on this procedure and how they fit in with the The Secure Arc Reference Architecture are detailed on the Asset Definition section.


This model has an impact on the network and firewall design, the structure of an application itself and can impact how the interfaces to Services in a Service Oriented Architecture should be designed. When deciding what servers are to be deployed where, a Logical Zone needs to be selected and considerations as to what other servers and nodes it needs to communicate with will implicitly need to be assessed. The same goes for application components and services.

Ultimately the Logical Security Zone Pattern helps to satisfy the Security Principles identified above. Defence in Depth is clearly enforced at each Compartmentalised section. As a result, the Attack Surface is significantly reduced, especially between systems and as a consequence, a Denial of Service attack on one system should not impact that of another (this is quite subjective).


A sample system Logical Security Architecture
A sample system Logical Security Architecture

Each node making up a system needs to be dropped into an appropriate Logical Zone. Once selected, the Flows between each Node must be identified and they must follow the Rules. Each Node and Flow needs to be tagged with a unique identifier so that they can be referenced in the various tables, specifically the Infrastructure Assets and everything that references them. By doing this, it is relatively safe to assume that the resulting architecture represents a secure design, at least at the big picture level. The diagram to the right represents a very simple and cut down Logical Security Architecture.

The Logical Security Architecture is primarily, but not entirely, realised as a network design. The network design to the left represents an ideal realisation of the sample system Logical Security Architecture above.
A sample system Physical Network Design
A sample system Physical Network Design

As per the sample system, this is not intended to be an exhaustive network design. It only attempts to highlight the network segmentation via firewalls representing each of the Logical Zones above. Note also that simpler, cheaper realisations are possible by enforcing the logical zone segmentation off the back of one or more firewalls rather than having separate physical firewalls for each one. There is an increased risk in taking this cheaper option as a compromise of that one firewall results in a compromise of all zones.

Related Patterns

As the template for most of the Secure Arc Security Reference Architecture, the majority of the Design Patterns are related. These include:


Personal tools