Fri Dec 5 09:28:48 PST 2014

Zones: How should the enterprise separate parts of (zone) its network(s)?


Options:

Option 1: No zone separation.
Option 2: Several zones for different business functions.
Option 3: Many small zones for individual projects.
Option 4: Limited zoning with trusted mechanisms
Option 5: A small number of layered zones with subzones for risk disaggregation and functional separation.

Option A: Subzones should be used to disaggregate risks to the finest level feasible.
Option B: Subzones should be used to disaggregate risks to the management specified risk tolerance threshold.

No zone separations

Internet / Untrusted / Unknown
Perimeter (with possible built-in DMZ)
Everything the enterprise owns
No zone separation

Several zones for different business functions.

Users AP AR HR Web Backups Internet
Several zones are used for different business functions

Many small zones for individual projects.

P1a P2a P3a P4a P5a P6a P6a
P1b P2b P3b P4b P5b P6b P6b
P1c P2c P3c P4c P5c P6c P6c
P1d P2d P3d P4d P5d P6d P6d
Many small zones are used for individual functions

Limited zoning with trusted mechanisms

Internet Unknown and Internet partner connections
NAT gateway (out)Direct serversET terminations (in)
Trusted subzone 1...Trusted subzone N
Restricted self-protecting servers
Limited zoning with trusted mechanisms

Layered architecture

Internet Untrusted Dial-ins Unknown Internet connections to business partners
Control Zone
Changes
Patches
NOC
Terminal Services
Test
<- ->
<- ->
<- ->
<- ->
Perimeter (SYN only Inet to DMZ or T to Inet)
DMZ Proxies Web servers
NON INTERNET DIRECT CONNECTS
Subzones directly connected to business partners
Perimeter (SYN only DMZ to T or T to ANY)
Trusted Users App servers
Perimeter (only T to R or R to T, SYN only T to R)
Restricted Databases Repositories
>>
>>
>>
>>
Audit Zone
Audit
SOC
Forensics
Legal holds
Terminal Services
The layered architecture approach

Decision:

IF the enterprise is small and does not have differentiated services on dedicated platforms, THEN do not use zone separations,
OTHERWISE IF the enterprise is not large and has distinct enterprise-wide business functions, THEN use several zones for different business functions.
OTHERWISE IF the enterprise is composed of many small entities that work independently on different projects without centralized systems, THEN use many small zones for individual projects,
OTHERWISE IF the enterprise has the ability to build medium or high surety trusted mechanisms and costs or reliability favor such mechanisms, THEN use limited zoning with trusted mechanisms,
OTHERWISE use a small number of layered zones with subzones for risk disaggregation and functional separation.
IF High risk, THEN Subzones should be used to disaggregate risks to the finest level feasible.
OTHERWISE IF Risk aggregation exceeds management specified risk tolerance in any zone, THEN Subzones should be used to disaggregate risks to the management specified risk tolerance threshold.

Basis:

No zone separation.

Most small businesses have relatively few computer systems and they all work together to facilitate the same effort. Separation takes time, effort, and expertise. Little physical separation is typically in place, little expertise is available, and the cost is substantial, so at best there may be an Internet network address translation firewall in most small businesses. The computer-related issues are typically not so great that adequate backups and restoration times of days are not devastating to the business, so the costs do not justify the benefits for complex network separation.

Several zones for different business functions.

Several zones for different business functions typify medium sized businesses. They may have a manufacturing function, a financial function, a sales and marketing department, an HR department, and several other similar areas, each with its own user base and little common functionality crossing these boundaries. In this case, each department can have its own local area network (LAN) that runs more or less on its own. There is typically enough information technology expertise to allow for at least one full time employee dealing with networking issues and that employee can easily deploy a small number of internal network segments using VLAN technology, firewalls, or switch configurations to make the networks relatively independent of each other. This will also limit the spread of viruses and reduce the debugging effort when network problems occur.

Many small zones for individual projects.

As the number of zones increase, the management complexity also increases, especially for enterprises that grow to larger sizes. Sheer numbers make departmental separation as the sole means of protection hard to do. The need for internal applications to more highly integrate drives less separation between departments and even more complexity in dealing with the interactions. The management complexity also goes beyond what can be handled by a single individual, necessitating more group efforts and more unified and standardized approaches. At some point the transition has to be made to the large enterprise model.

Limited zoning with trusted mechanisms.

For organizations that have the ability to create medium and high surety special purpose mechanisms and in cases where those mechanisms are cost effective and/or improve reliability and/or availability, it is often more efficient and at least as effective to use higher surety mechanisms and place them directly in harm's way than to try to create larger infrastructures and support them in the hope that many layers of protection can be as effective as fewer layers of stronger protection. This is a tradeoff between fault tolerance and fault intolerance that more advanced organization often make. In these situations, commodity computers are put in subzones of the Trusted zone, which sits behind a NAT gateway and, optionally, allows inbound encrypted tunnels to contact internal assets. Direct servers provide direct Internet or external services and must protect themselves. Internal assets that need to communicate with Direct servers, do so through encrypted tunnels, usually through the NAT gateway, which is associated with an IP address for use by the Direct servers, which differentiate services based on this address as well as other mechanisms. Internal Restricted servers then protect themselves from Trusted systems based on subzoning and their own protective mechanisms. No internal perimeters are used other than possible Trusted zone separation mechanisms because self-protecting systems and servers have their own protective mechanisms adequate to meet the surety mandates.

A small number of layered zones with subzones for risk disaggregation and functional separation.

The typical large enterprise will have several zones of increasing business import including perhaps:

In addition, there may be:


Subzones should be used to disaggregate risks to the management specified risk tolerance threshold.
Within zones, which are typically separated by high complexity and heavily managed firewalls, reside subzones that are used for additional separation to limit the aggregation of risk, to group like with like, and to prevent outages or packet floods from interfering with other business functions. Depending on management tolerance for risk, subzoning should be applied to reduce aggregated risks.

Subzones should be used to disaggregate risks to the finest level feasible.
For high risk situations, making smaller subzones further disaggregates risks, so to the extent this is feasible within the specific situations, it is beneficial in terms of further isolating subsystems and components. However, at some point, the separation mechanisms add more complexity than the resulting benefit in risk disaggregation, and in many cases, they will also introduce common mode failures if not implemented with redundant (separate and different) methods.

Copyright(c) Fred Cohen, 1988-2015 - All Rights Reserved