Logical Security Zone Pattern

From The Secure Arc Wiki

Revision as of 03:38, 28 May 2008 by Tristan (Talk | contribs)
Jump to: navigation, search


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 left to right. On the far left is the Uncontrolled Zone, or the Internet. There is zero trust here. It's in the Uncontrolled Zone that any anonymous attacker or Script Kiddie resides. On the far right is the Secured 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 left to right, however in most cases the connection to the data repository in the Secured Zone is as an application System User rather than an End Users level. This means that the finest grained authorisation is actually enforced in the Restricted Tier.

An area of confusion with this model is always the Internally Uncontrolled and Internally Controlled Zones. These map one-to-one with the staff intranet and an internal DMZ respectively. Physically, the Staff Intranet often hangs off the back of the Secured Zone. Logically, it is only slightly more trusted than 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.

Stove Pipes

Each system resides in a Stove Pipe. The Stove Pipe 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 Stove Pipes 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.

When the Threat Modeling is performed, 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 Stove Pipes. 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 Stove Pipes should be made.

Demilitarized Zone (DMZ)

In a lot of organisations, the DMZ is referred to as a subnet isolated by firewalls. In the example above, the Controlled Zone, Restricted Zone and Secured Zone would each be referred to as a DMZ. 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 Stove Pipes.

Zone Description Adjacent Zones Node Types
Uncontrolled The Uncontrolled Zone is the Internet. 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. Externally Controlled, Controlled Web Browsers, Hacker Tools
Externally Controlled The Externally Controlled Zone represents a 3rd Party 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. Externally Controlled, Controlled 3rd Party B2B Services
Controlled The Controlled Zone is typically the DMZ. It is the no-mans-land between the untrusted networks and the trusted. All traffic should travel through the Controlled Zone 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. Uncontrolled, Externally Controlled, Internally Uncontrolled, Restricted, Secure Managed Web Servers, Reverse Proxies
Internally Uncontrolled This is the Staff Intranet. It’s from here that employees connect their desktop PCs and their laptops. Internally Controlled, Controlled Staff PCs, iPods, Disgruntled Employees, Contractor Laptops, Home Laptops, USB Keys, Portable Hard drives
Internally Controlled This is the equivalent of the Controlled zone, but is specifically for the internal staff. It typically maps to an Internal DMZ separating the staff intranet from internal systems. Internally Uncontrolled, Restricted Web Servers, Reverse Proxies
Restricted The Restricted Zone is often referred to as the Application Tier. In order to access this Zone, an End User must have traversed the Controlled Zone and satisfied all of the authorisation constraints required to do so. With the exception of the Stove Pipe dedicated to the security sub-system required for authentication in the Controlled Zone, End Users should have been authenticated prior to initiating any requests in the Restricted Zone Controlled, Internally Controlled, Secured, Secure Managed Web Servers, Application Servers
Secured The Secured Zone is often referred to as the Data Tier. Database, LDAP Repositories and Access Control Policies Stores should be deployed into this Zone. The Secured Zone requires the most effort to compromise, as an Attacker must compromise the access controls at all of the earlier Zones before getting into this one. Restricted, Secure Managed User Repositories, Data Repositories, ACL Policy Stores
Secure Managed 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 Secure Managed 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 Controlled or Restricted Zones. Controlled, Restricted, Secured Monitoring Tools, SSH Clients, Provisioning Servers

In addition to the Zones, there are also the Stove Pipes

Name Description
Stove Pipe(s) Each Stove Pipe defines the boundaries of a particular system and spans multiple Zones. The Stove Pipes 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 following diagram.

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

Stove Pipes 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 Stove Pipes cross multiple Zones. The rules shown above apply within the Stove Pipes, however when a Node in one Stove Pipe needs to communicate with another Node in a different Stove Pipe, they both must reside in the same Zone.

The reasoning behind this is quite straight-forward. Within a Stove Pipe the level of Trust increases from left to right 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 risk rating associated with that system, the budget given to it and the experience of the people who deliver it.

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

Nodes & Flows

Once a Logical Security Zone Model has been created for a particular system, all of the Nodes & Flows identified should be tagged with the Information Assets that either exist persistently or transiently at or across each one. The highest rated Information Asset for a particular Node or Flow becomes the Consequence rating for that particular Node or Flow.
Node Definition and Security Attributes
Node Definition and Security Attributes

These ratings are used to determine the Security Attributes that need to be applied to each Node & Flow, such as SSL, they are also fed into the Threat Model where a Risk Rating is determined for potential attack vectors associated with the logical design.

While some of these decisions can be made with just the Consequence rating of the Information Assets or just company security policies, some will involve a feedback loop from the Threat Model.

Flow Definition and Security Attribute
Flow Definition and Security Attribute
Where the cost of required countermeasures is significant, the Risk Rating needs to be taken into account and an Architectural Decision will need to be made before the Countermeasures can be applied.

When being tagged against Nodes and Flows, Information Assets need to be classified as either Transient or Persistent in that context. The Information Assets on a flow are always Transient, however on a Node an Information Asset may be either one. This distinction is important when considering what needs to be secured and how. For example, there is no point dictating that a particular database node needs to store its repository on an encrypted file system if sensitive assets that warrant such security are only ever stored in memory and less sensitive assets are stored in the repository.

It should be noted that the definition of Transient used here includes the likelihood of an in memory data structure implicitly being stored on disk in virtual memory, or swap space. In these scenarios and depending on the risk rating the swap space may need to be encrypted.

The Consequence Rating, Risk and Residual Risk associated with the Threats and Countermeasures (as selected via the Architectural Decisions) are identified for each Node and Flow. These will be realised via the Security Attributes section categorised into Data Protection, ID & AM and Event Management areas. It is ultimately in this section that will dictate what needs to be applied where.


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, including the Threat Model and the Architectural Decisions. 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, 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