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.
No zone separations
| |
Several zones for different business functions.
|
Many small zones for individual projects.
|
Limited zoning with trusted mechanisms
| |
| |||
| |||
Layered architecture
|
||||||||||||||||||||||||||||||||
Control Zone
|
<- -> <- -> <- -> <- -> |
|
>> >> >> >> |
Audit Zone
|
||||||||||||||||||||||||||||
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.