Mon Sep 29 18:52:10 PDT 2014

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


Options:

Option 1: No zone separation.
Option 2: Several zones for different business functions.
Option 3: Many small zones or microzones for individual projects.
Option 4: Limited inside-out zoning with trusted mechanisms.
Option 5: Cloud-based zones and temporal microzones.
Option 6: Fully layered architecture.
Option 6: POSet-based zones with high surety separation

Option A: Subzones and/or microzones used to disaggregate risks to the finest level feasible.
Option B: Subzones and/or microzones 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 or microzones 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 or microzones are used for individual functions

Limited inside-out zoning with trusted mechanisms

Internet Unknown and Internet partner connections
Direct serverDirect server...Encrypted Tunnel terminations (in)?
Perimeter (SYN only inside to out, NAT gateway [inbound tunnel bypass?])
Trusted subzone 1...Trusted subzone NEncrypted tunnel to Restricted?
Perimeter (SYN only inside to out, NAT gateway [inbound tunnel bypass?])
Restricted self-protecting servers (archives, audit, backups, etc.)
Limited inside-out zoning with trusted mechanisms

Cloud-based zones and temporal microzones.

Cloud service 1...Cloud Service N
Internet
NAT
Devices
Internet
NAT
Devices
Internet
NAT
Devices
Internet
Provider
Mobile
Internet
Provider
Mobile
Internet
Provider
Mobile
Internet
3rd party
Internet
3rd party
Cloud-based zones and temporal microzones

Fully 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
History
Terminal Services
The layered architecture approach

POSet-based zones with high surety separation

Source zone
Physical perimeter using Digital Diodes (inbound), Guards (outbound), FSMs for select functions
Destination zone
POSet-based zones with high surety separation

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 or microzones 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. However, the use of microzones may allow this strategy to be applied further with less central control, and it may also be applied within zones or subzones of other more well structured zone architectures.

Limited inside-out 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.

Cloud-based zones and temporal microzones.

For startups, rapid or highly flexible scalable deployments, enterprises highly dependent on existing outside services, or activities (typically service delivery or marketing) supporting social media, cloud-based zones and temporal microzones provide a protective architecture that, while limited in effectiveness, is an improvement over protection-free environments, and is very inexpensive to deploy. In this approach, (cloud) service provider protection is trusted (justifiably or not) to provide for the functions required of it, and risk is disaggregated by having users on endpoints rely on NAT gateways or mobile provider gateways and temporal separation for risk disaggregation. Users are given either virtual machines or hardware devices that use cloud services, and told not to use more than one cloud service on the same (virtual or real) machine at the same time. The effect is that (1) cloud services are separated from each other in time to limit risk aggregation, (2) each cloud service user has independent identity and authorization for each service, which also limits risk aggregation and allows some control over who accesses what enterprise service, (3) users who also access enterprise higher-valued assets can do so on a separate device or in a separate virtual machine than is used for cloud services, and (4) external (3rd party) users, interaction with whom the service is designed to facilitate, are entirely independent of enterprise systems. While risk is transferred to and accepted from the cloud providers, in many cases, for the services they provide, they are better at protection than the enterprise. In addition, there is a form of social risk mitigation in the fact that, from a public perception standpoint, it is not the enterprise that has failed when service provider protection fails, particularly if many others in the same industry or across many industries use the same service provider. Key things that cannot be avoided are (a) if the service provider holds enterprise data, the data should be independently secured by the enterprise if and to the extent that the data is worth protecting when the provider fails, and (b) the functions provided by the provider should be replaceable and redundantly operated if and to the extent they are vital to business continuity.

Temporal microzones can also be used for periods processing with optional color changes for higher surety of separation against covert channels. While these are not typically available or used in public cloud-based systems today, historically, they were used in distributed computing environments - the prececessor to modern cloud computing environments - and can still be found from time to time.

Fully Layered architecture (a small number of layered zones with subzones and/or microzones 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:


POSet-based zones with high-surety separation.

High surety environments that need to control information flows commonly use digital diodes to force one-way information flow and, optionally, guard systems for limited reverse flows. For example, a special purpose trusted guard system may use human inspection to review content for possible release. Otherwise, inbound content will pass whtough a diode or be provided on media that physically enters and cannot leave without being cleansed of content. In some cases, a finite state machine may be used for special purpose access or actions, such as to allow limited function access to a control system within a POSet area from another POset area (e.g., specification of an action and confirmation of its completion).


Subzones and/or microzones 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 (1) 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; and/or (2) direct or subzone embedded microzones, used to limit the aggregation of risk, for finer granularity separation, and for safer untrusted content, application, and access use at lower cost. Depending on management tolerance for risk, subzoning and/or microzones should be applied to reduce aggregated risks.

Subzones and/or microzones should be used to disaggregate risks to the finest level feasible.
For high risk situations, making smaller subzones and/or microzones further disaggregates risks, so to the extent this is feasible within the specific situation, it is beneficial in terms of further isolating subsystem, components, content, etc. 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. Microzones today are not adequately trustworthy for high surety separation, but may be used to augment higher surety methods at finer granularity and lower cost.

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