No zone separations
| |
Several zones for different business functions.
|
Many small zones or microzones 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 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 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 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:
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,
applicaiton, 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 feaible within the
specific sisutation, it is beneficial in terms of further isolating
subsystem, components, content, etc. However, at some point, the
separaiton mechanisms add more complexity than the resulting benefit
in risk disaggregation, and in many cases, they will also introduce
common mode faulures 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
methoids at finer granularity and lower cost.