Docstoc

What zones of trust should organizations establish

Document Sample
What zones of trust should organizations establish Powered By Docstoc
					Security and Risk Management Strategies
Reference Architecture Technical Position

Zones
AUTHOR(S):
Dan Blum
(dblum@burtongroup.com)

Additional Input:
Eric Maiwald

Statement of Problem
What zones of trust should organizations establish to protect their information technology (IT) resources on communications networks?

103022

Publishing Information
Burton Group is a research and consulting firm specializing in network and applications infrastructure technologies. Burton works to catalyze change and progress in the network computing industry through interaction with leading vendors and users. Publication headquarters, marketing, and sales offices are located at: Burton Group 7090 Union Park Center, Suite 200 Midvale, Utah USA 84047-4169 Phone: +1.801.566.2880 Fax: +1.801.566.3611 Toll free in the USA: 800.824.9924 Internet: info@burtongroup.com; www.burtongroup.com Copyright 2007 Burton Group. ISSN 1048-4620. All rights reserved. All product, technology and service names are trademarks or service marks of their respective owners. Terms of Use: Burton customers can freely copy and print this document for their internal use. Customers can also excerpt material from this document provided that they label the document as Proprietary and Confidential and add the following notice in the document: Copyright © 2007 Burton Group. Used with the permission of the copyright holder. Contains previously developed intellectual property and methodologies to which Burton Group retains rights. For internal customer use only. Requests from non-clients of Burton for permission to reprint or distribute should be addressed to the Client Services Department at +1.801.304.8174. Burton Group's Security and Risk Management Strategies service provides objective analysis of networking technology, market trends, vendor strategies, and related products. The information in Burton Group's Security and Risk Management Strategies service is gathered from reliable sources and is prepared by experienced analysts, but it cannot be considered infallible. The opinions expressed are based on judgments made at the time, and are subject to change. Burton offers no warranty, either expressed or implied, on the information in Burton Group's Security and Risk Management Strategies service, and accepts no responsibility for errors resulting from its use.

If you do not have a license to Burton Group's Security and Risk Management Strategies service and are interested in receiving information about becoming a subscriber, please contact Burton Group.

Table Of Contents
Statement of Problem......................................................................................................................................................4 Typical Requirements..................................................................................................................................................... 5 Group Resources with Common Communication and Protection Requirements into Zones.....................................5 Balance Business Needs vs. Risk................................................................................................................................6 Separate Systems and Information in Accordance with Policy.................................................................................. 7 Set Perimeter Requirements for Zones....................................................................................................................... 8 Include Geographically Distributed or Mobile Systems in a Zone.............................................................................9 Alternatives................................................................................................................................................................... 10 Single or Multiple Network Security Architecture Scopes for Zoning.....................................................................10 Open, Closed, or Layered Architecture.....................................................................................................................10 Open Architecture................................................................................................................................................. 10 Closed Architecture...............................................................................................................................................11 Layered Architecture.............................................................................................................................................13 Subzones............................................................................................................................................................... 16 Control and Audit......................................................................................................................................................17 Control Zone......................................................................................................................................................... 19 Audit Zone............................................................................................................................................................ 20 Future Developments.................................................................................................................................................... 21 Evaluation Criteria........................................................................................................................................................ 22 Statement & Basis for Position..................................................................................................................................... 23 Scope Position...........................................................................................................................................................23 Create a separate perimeter architecture for each portion of the organization or subsidiary................................23 Use one perimeter architecture for the entire organization...................................................................................24 Open, Closed, or Layered Zone Architecture Position............................................................................................. 24 Use a closed architecture.......................................................................................................................................25 Use an open architecture....................................................................................................................................... 25 Use a layered architecture..................................................................................................................................... 25 Layered Network Security Zones Position............................................................................................................... 26 Create a perimeter between internal systems and all external systems.................................................................26 Create a demilitarized zone (DMZ)...................................................................................................................... 26 Create a trusted zone............................................................................................................................................. 27 Create a restricted zone......................................................................................................................................... 27 Subzones Position..................................................................................................................................................... 27 Create subzones.....................................................................................................................................................27 Do not create subzones......................................................................................................................................... 27 Control and Audit Zones Position.............................................................................................................................28 Control Zone Position........................................................................................................................................... 28 Use a control zone.............................................................................................................................................28 Control Zone Internal Structure Position.............................................................................................................. 28 Divide the control zone into subzones.............................................................................................................. 29 Do not divide the control zone.......................................................................................................................... 29 Audit Zone Position.............................................................................................................................................. 29 Use an audit zone.............................................................................................................................................. 29 Use other means to protect audit data and functions.........................................................................................29 Audit Zone Internal Structure Position................................................................................................................. 30 Divide the audit zone into subzones................................................................................................................. 30 Do not divide the audit zone............................................................................................................................. 30 Relationship to Other Components............................................................................................................................... 31 Revision History........................................................................................................................................................... 32 Notes............................................................................................................................................................................. 33 Author Bio ....................................................................................................................................................................34

3
BURTON GROUP 7090 Union Park Center Suite 200 Midvale · Utah 84047 · P 801.566.2880 · F 801.566.3611 · www.burtongroup.com

Statement of Problem
What zones of trust should organizations establish to protect their information technology (IT) resources on communications networks?

4
BURTON GROUP 7090 Union Park Center Suite 200 Midvale · Utah 84047 · P 801.566.2880 · F 801.566.3611 · www.burtongroup.com

Typical Requirements
Enterprise IT environments are composed of systems, sites, and other resources that vary in terms of the communications they should be allowed to perform over communications networks. The differences between resources and the risks associated with them necessitate the separation of systems and/or sites so that some can communicate in certain ways and others cannot. By defining and enforcing consistent policy for each set of resources with similar requirements, an enterprise can increase the efficiency and effectiveness of businessappropriate protection functions. As IT environments, threats, attacks and the network topologies in which they exist have become more complex, the need for explicitly grouping resources in terms of their communication and protection requirements has increased.

Group Resources with Common Communication and Protection Requirements into Zones
Burton Group defines a security “zone” as “a grouping of IT resources which may reside at multiple locations but have similar business communication and network protection requirements; the zone is demarcated by network perimeter boundaries that enforce common policy and may be further divided into subzones.” Business communication requirements may be to initiate communications, receive communications, or both, within the enterprise and/or with external business partners, outsourced service providers, or the general public. Protection requirements for resources stem from the security objectives: integrity, availability, confidentiality, use control, and accountability (IACUA). Resources with similar security requirements can be grouped together, and minor variations in requirements may be codified in zone rules. (For definitions of “zones,” “subzones,” “perimeter,” “availability,” “confidentiality,” “integrity,” “accountability,” “use control,” and other terms, see the Security and Risk Management Strategies overview “Concepts and Definitions.”) The zone construct does not, and is not intended to encompass all potential groupings of resources for all business protection and communication requirements. Many groupings may have no relationship to the structure of sites and networks, and many desired protection policies may not be appropriate to enforce at network policy enforcement points (PEPs). For example, a policy might state that all systems should encrypt their storage media, or that all the web services applications should be able to communicate with each other anywhere in the world using specific application trust mechanisms. Zones are intended to meet enterprise requirements for a relatively coarse-grained grouping of resources, such as systems and sites on IT networks and medium or high surety1 policy enforcement over how those resources communicate. Other kinds of resource groupings for the purpose of policy enforcement can and should be created where necessary and will be increasingly needed in addition to zones as business communication needs become more varied and complex. To model more fine grained and flexible groupings Burton Group defines the “enclave” as “any collection of resources or users that is isolated or separated from other environments by any isolation or separation mechanisms.” So, while a particular enclave could define the same grouping as a particular zone, it could also define other groupings not subject to the constraints of a zone. For example, an enclave could consist of resources in many separate zones belonging to separate organizations and it could enforce separation or access controls through mechanisms other than network perimeters. Further discussion of enclaves is out of scope for this technical position. Security zones must be separated from one another by network perimeter boundaries around the areas where the zone is exposed. In the past, it was sometimes sufficient to divide the IT environment into bi-polar “internal” and “external” zones, each containing the organization's private network and the Internet (plus all other networks) respectively. Most organizations were also forced to adopt an intermediate demilitarized zone (DMZ) where the organization's IT servers could interact with external users. But in recent years, the notion of a single firewall or perimeter surrounding a private network that contains all IT assets has become obsolete, at least for most large and complex organizations. 5
BURTON GROUP 7090 Union Park Center Suite 200 Midvale · Utah 84047 · P 801.566.2880 · F 801.566.3611 · www.burtongroup.com

While today's physical network environments continue to provide perimeter protection for some sites and highvalue resources such as data centers, many systems used by employees will lack the perimeter protection that was once taken for granted. As perimeters continue to become more porous (a phenomena described as “deperimeterization” by the Jericho Forum, Burton Group, and others), security policy decisions must often be made by mechanisms installed on employee desktops and mobile systems. At the same time, more partners, suppliers, and contractors require direct connections to servers and repositories once considered to be for use internal only. De-perimeterization imposes further requirements on each system or site to protect its resources at a more granular level, thus moving enforcement points closer to (or even on) the individual target resources. Paradoxically, more porous perimeters in the age of de-perimeterization have created the need for more granular and better-defined zoning. This technical position helps organizations determine how to group IT resources into security zones demarcated by perimeters that include both PEPs at network access points and on the systems themselves. In general, architects should work through security Reference Architecture technical positions in the following order: • “Zones” to define how resources will be grouped into security zones, and what communications will be allowed between the zones • “System Placement” to define rules for placing different classes of clients, devices, servers, and other systems into zones • “Network Perimeters” (forthcoming) to specify architectural security requirements for the zone boundaries • Other technical positions and templates listed in the “Relationship to Other Components” section of this technical position

Balance Business Needs vs. Risk
Any network architecture must take into account the need for organizations to communicate to do business. This means that both internal and external connectivity are required for most systems. The communication may range over a wide spectrum of protocols and fulfill a wide spectrum of business needs. For example, many web servers have to communicate public information to anyone on the Internet, while most internal software development systems that are used to produce commercial software must not download software from the Internet because of possible tainting. However, these systems must be able to communicate internally with version control repositories, and their users must exchange e-mail internally with other developers. Many internal systems will need to communicate with external systems for e-mail and allow employees to access public information sources or systems belonging to business partners. The information flow over many of these connections will be bi-directional. Most current internal systems send information to and receive information from external sources, and external systems send information to and receive information from the internal systems. Information flow is likely to be important to business, and therefore, the security zones and their perimeter protections must allow business to continue in the face of equipment failures and security incidents (be they malicious or accidental). Generally, employees require access to internal systems, information, and resources whether they are on the organization's physical premises, at a remote office, at a home office, or traveling. In many cases, it is in the interests of the business to allow employees consistent access regardless of the location from which their connection originates. However, some critical business functions may be placed in security zones or portions of zones that require physical presence before access is allowed. In this case, the physical controls provide part of the perimeter protection for the zone.

6
BURTON GROUP 7090 Union Park Center Suite 200 Midvale · Utah 84047 · P 801.566.2880 · F 801.566.3611 · www.burtongroup.com

Portions of a zone may have similar communication and protection needs, yet be prohibited from communicating with each other. This may be due to business constraints and requirements such as those placed on a system by a business partner or customer. For example, a system used by a business partner must allow inbound connections from that partner. A second system used by a second business partner must also allow inbound connections, but only from the second business partner. The contracts with both business partners specify that the information on the respective systems must be kept separate and should only be accessible by the organization and not by other partners. While both systems may coexist in the same zone (due to similar connectivity requirements), they must be kept separate to satisfy business requirements. In another example, zoning can reduce the scope of compliance activities and audits, such as those related to the Sarbanes-Oxley Act (SOX) or Payment Card Industry (PCI) compliance. With accounting or credit card processes segregated, resources outside of the designated zones or subzones may not need to be audited. It is critical that the organization segregate resources (either using zones or other mechanisms) with an understanding of the risk posed by necessary communications to the resources or systems. The perimeter can only regulate what passes to and from the network security zone, and cannot regulate how it is interpreted. Given the same risk level1 and utility, systems within zones whose perimeters allow outside connections require more system-level protection than systems that have limited outside communications, because they face a broader spectrum of potential threats. Business requirements often result in perimeters that allow communications with substantial risks, and it is the proper role of the business to determine when to accept such risks, when to transfer them, when to avoid them, and when to mitigate them. Nonetheless, it is still possible to place an appropriate level of security around those resources. Figure 1 shows how systems may be divided within a zone due to business requirements.

Figure 1: Security Zones Are Defined Based on Business Requirements

Separate Systems and Information in Accordance with Policy

7
BURTON GROUP 7090 Union Park Center Suite 200 Midvale · Utah 84047 · P 801.566.2880 · F 801.566.3611 · www.burtongroup.com

Policy may require that any system that has certain types of information may not reside in a zone that allows direct external connectivity. This policy could be implemented through a layered application architecture (see Figure 2). In this case, a system that allows direct external connectivity (e.g., a web server) is placed in a zone that allows such connectivity. The application server is placed in a zone where it can connect to the web server but cannot be connected to from external sources. Finally, sensitive information (e.g., a list of credit card numbers) is placed in a zone with a perimeter that only allows access from the application server. Separating systems and information in this fashion will exact a cost; organizations must determine whether the risk warrants that cost through their risk management process. For more details on risk management, see the Security and Risk Management Strategies overview “Risk Management: Concepts and Frameworks.”

Figure 2: Network Security Zones Support Layered Application Architectures

Set Perimeter Requirements for Zones
The perimeter of each network security zone is governed by the organization's technical security policy. 1 The technical security policy for each zone may be different, but the zones may be interdependent. This means that inner zones that have more restrictive connection policies will be somewhat dependent on the perimeter protection mechanisms used on the outer zones, which thus form a defense in depth around the inner zones. (See the “ Layered Architecture” section of this technical position for more information about inner and outer zones.) This dependence may also affect the overall performance requirements of the perimeter devices. A zone's requirements determine the characteristics of perimeters that protect the zone, and must also include requirements of dependent zones. These include requirements for perimeter functionality; for example, some perimeters may enforce policies on Internet Protocol (IP) addresses and ports while others (e.g., Secure Sockets Layer [SSL] virtual private network [VPN] PEPs) may authenticate users and associate traffic with authenticated sessions. Requirements for perimeter integrity, detection of perimeter failure, policy management, and verification must also be defined for the zone boundary. 8
BURTON GROUP 7090 Union Park Center Suite 200 Midvale · Utah 84047 · P 801.566.2880 · F 801.566.3611 · www.burtongroup.com

Include Geographically Distributed or Mobile Systems in a Zone
Mobile systems and other systems in unprotected sites, or sites that aren't managed by the organization, physically reside in the Internet, which is an untrusted area (or zone). However, the employees, contractors, and partners that use these systems often need to access an organization's internal applications to perform business functions. The Jericho Forum (the organization founded to search for de-perimeterization solutions) started with the premise that users and organizations must have “secure endpoints and secure protocols.” Burton Group and others have described the notion of secure endpoints using secure protocols over untrusted networks as a security overlay. Using overlays, systems can communicate with each other regardless of location. While the systems using the security overlay may reside in different locations, they may logically be part of an enclave or a zone. For example, systems could use a VPN to pass traffic security to other systems in the zone even though that traffic must cross zones of lesser trust, such as the Internet. In this case, the VPN overlay acts like an extension cord for grouping mobile systems and the systems on the organization's internal network into a common zone of trust.

9
BURTON GROUP 7090 Union Park Center Suite 200 Midvale · Utah 84047 · P 801.566.2880 · F 801.566.3611 · www.burtongroup.com

Alternatives
Organizations must investigate a number of alternative approaches when deciding how to aggregate and separate their resources into zones. This technical position considers the following categories of alternatives: • Single or multiple network security architecture scopes for zoning • Open, closed, or layered zone architecture position • Control and audit

Single or Multiple Network Security Architecture Scopes for Zoning
Organizations must determine how to apply architectural decisions across their various business units, divisions, and subsidiaries. In some cases, it may be best to centralize policy and architectural decisions. These decisions then apply to the entire organization. If the IT department is also centralized, a single approach to zoning and network perimeter architecture may be defined and established for the entire organization. Other organizations have multiple business units, divisions and subsidiaries that are allowed or, in some cases, required to operate independently. The security requirements may also differ widely across the organization. In this case, each independent unit (business unit, division, subsidiary, etc.) should determine the appropriate perimeter architecture for its particular security requirements and policies. For example, an organization that performs work for a government entity may be required to process classified information. The portion of the network that processes the classified information will need to operate under a different perimeter architecture than the rest of the organization. Another example is an organization that has decentralized network and IT functions. The divisions and subsidiaries of the organization operate as independent business units. Each business unit then makes its own architectural decisions and may even consider other portions of the organization to be untrusted. When multiple scopes for architecture are defined, there will be inefficiencies in communication between the various business units. This is caused by different perimeter requirements, security mechanisms, and policies. Organizations that merge with other organizations or that acquire other organizations may suddenly be forced to deal with multiple scopes and vastly different security policies and requirements.

Open, Closed, or Layered Architecture
The overall security architecture determines how resources are protected and how systems are classified within the network. Some organizations are required to function in a very open environment where many unknown systems are authorized to connect to what would normally be considered internal systems. Other organizations fall to the opposite extreme, where the environment is completely closed and no external connections are allowed. Between these two extremes, we find a layered architecture that attempts to balance the security requirements of the organization with the other, sometimes competing, business needs.

Open Architecture
The early Internet is a good example of an open architecture. Systems connected directly to the Internet with little or no protection against malicious activity. Each host or network resource was open to any type of communication (assuming that the service existed on the system), and the security of the system relied upon the security mechanisms inherent in the operating system itself. The open architecture is depicted graphically Figure 3.

10
BURTON GROUP 7090 Union Park Center Suite 200 Midvale · Utah 84047 · P 801.566.2880 · F 801.566.3611 · www.burtongroup.com

Figure 3: Open Architecture with no Security Zones Some organizations have substantial components that require the open architecture approach. For example, institutions that research new protocols may be adversely affected by perimeter protection systems whose security mechanisms might prevent the use of experimental protocols. In other cases, the organization may require that a large number of previously unknown individuals be granted access to a majority of systems within the organization's network. Internet groups and other communities of interest are good examples of this. In this case, managing perimeter configurations (other than those provided by a service provider) may be too costly or inflexible for an organization. This type of environment may also be described as a “collaboration stew,” where anything that is not specifically prohibited is allowed. Many small to medium-size businesses (SMBs) operate in this way. It may make sense for parts of larger organizations to operate like SMBs and have separate perimeter scopes that use the open architecture. On the other hand, this could create too much inconsistency in IT security policies and increase exposure. In an open architecture environment, each system must be able to protect itself from attack or the organization must be able to survive the failure of such systems with no significant consequence. Each system must protect itself from malicious attacks and from accidental violations of security. If the network and the systems in it cannot be secured, whether to allow the transmission of sensitive information must be carefully considered. It is likely that any transmission of unprotected sensitive material will be intercepted by unauthorized individuals.

Closed Architecture

11
BURTON GROUP 7090 Union Park Center Suite 200 Midvale · Utah 84047 · P 801.566.2880 · F 801.566.3611 · www.burtongroup.com

A closed architecture approach reflects a business policy of no external communication. In this environment, none of the systems is considered sufficiently trustworthy to communicate outside the zone in a risk-appropriate fashion. These are generally high-surety environments (e.g., some military or sensitive research, financial, and medical environments) where all systems and much of the information itself must be under the complete control of the organization. Systems on the network cannot be accessed from outside the closed community of the organization. For any information to come into the network or go out of the network, it must be manually carried on some type of media (magnetic disk or tape, optical disk, memory stick, or other memory device) so that there is no direct connection between the sensitive systems and external, untrusted systems. Alternatively, digital diodes can be used to implement one-way communications into or out of the environment. Typically, information is allowed to enter, and nothing is allowed to leave; but, in some cases, the path is reversed. This approach is often called an “air gap.” The transfer of information in this manner is tightly controlled and, in some cases, any media is inspected before it may enter or leave the environment. The closed architecture is depicted graphically in Figure 4.

Figure 4: Closed Architecture Perimeter security is handled primarily through physical controls. Normally, the personnel who staff this type of facility are also tightly controlled, and their backgrounds are screened before they are granted access privileges. Physical controls are used to prevent the unauthorized removal or introduction of storage media. In some cases, media devices, such as floppy drives and CD-ROM drives, can be removed or disabled from computer systems. Additionally, portable devices capable of recording information (e.g., personal digital assistants, cell phones, and digital cameras) may be banned. The environment is constantly checked for unauthorized systems or communications such as wireless networks. If an unauthorized connection is identified, it is immediately tracked down and removed; a root cause analysis is typically undertaken; individuals responsible are normally punished or even jailed, depending on the particulars; and changes are made so that the same cause cannot result in the same consequences again. In some cases, extraneous external signals, both entering and leaving, are also tracked and shielding and noise-generating techniques may be used to prevent such signals from meaningfully entering or leaving the environment.

12
BURTON GROUP 7090 Union Park Center Suite 200 Midvale · Utah 84047 · P 801.566.2880 · F 801.566.3611 · www.burtongroup.com

Because all systems within the organization's security perimeter are considered untrustworthy relative to the risks involved, communication between systems is typically watched closely, and the systems are compartmentalized so that they cannot communicate with each other unless they are of the same sort and contain sharable content. System configurations may be constantly verified to detect the introduction of unauthorized software or changes to critical configuration parameters. The cost of security for this type of network is primarily in the physical and procedural security mechanisms. In addition to the facility itself, guards, surveillance, and other technical countermeasures are often required to verify that unauthorized removal or introduction of media or portable devices does not occur, that operation remains within requirements, and that individuals do not act inappropriately. Consequently, the cost to perform authorized business interactions in such an environment can be high in terms of time and money, but is worth it because of the high consequences associated with protection failure.

Layered Architecture
A layered architecture (aka a zones-of-trust model) is often used to provide for gradations of protection against risk. The theory is one of defense in depth. By providing concentric layers of protection, where attempted entry into the next inner layer depends on successful entry and exploitation of the previous layer, the complexity and time of attack increases along with the chance of detection. In this type of architecture, the organization defines several layers, or zones, each with a distinct perimeter (see Figure 5). The perimeter that surrounds each layer defines the network traffic that is allowed to pass into and out of the zone. While it is possible to define zones by the systems that we place in them, it is most appropriate to define zones by the network traffic that is allowed to pass through the perimeter. If we were to define zones by the risk that the systems pose to the organization, the function of the systems, or the sensitivity of information contained on the systems, we could create additional risk for some of these systems. For example, if all systems that contain sensitive information were grouped into a single zone, systems that require communication from outside the organization could be in the same zone with systems that should not have any communication with external systems. The perimeter would need to allow traffic into the zone from external systems, thus increasing the risk to systems that do not require such communication. In fact, implementing perimeters and zones in this manner might negate the security protections provided by the zone perimeters and lead to requiring additional security mechanisms on each host. Therefore, we define zones based on the communications that are required across the zone's perimeter.

13
BURTON GROUP 7090 Union Park Center Suite 200 Midvale · Utah 84047 · P 801.566.2880 · F 801.566.3611 · www.burtongroup.com

Figure 5: Layered Architecture Zones are defined by the sequences of protective measures employed at their perimeters. Zones that do not allow direct connections from outside the organization are considered further inside the organization than zones that allow connections from the outside. Zones that do not allow any traffic (inbound or outbound) to systems outside the organization are considered the furthest inside. In effect, the perimeter protections of a zone build on those of zones farther outside, creating a defense in depth. Thus, as we move into the organization, the susceptibility of each zone to successful attack and exploitation from outside the organization is likely to be lower than that of the next zone out on the ring of trust. Conversely, outer zones are subject to more attacks and must provide appropriate security for resisting those attacks. However, the larger the zone, the more likely it is that unauthorized penetration or other activity may occur. This technical position models the following four-zone topology to give a sense of how an organization might define a layered perimeter architecture: • Untrusted zone: The untrusted zone (formerly known as external zone) comprises systems unknown to the organization or known to be a serious security risk, so there should be limited reliance placed on the information provided by the systems. They could be compromised by malicious code or an individual who is attempting to compromise the organization or its systems. Most of the Internet is a good example of an untrusted zone for most organizations. Other examples include sites that belong to business partners who must connect to the organization, or sites that belong to the organization's other divisions or subsidiaries. • Demilitarized zone (DMZ): The DMZ (formerly known as the outer zone) comprises systems known to the organization and controlled by it. In order to limit liability and provide useful service with high integrity and availability to those within this and the untrusted zone, these systems are carefully configured and operated. Normally, DMZs are physically protected because they tend to be located next to the core of the information infrastructure, have to operate over redundant communications links, and have high integrity and availability requirements. These systems pose a risk to the organization due to the potential for direct compromise and their critical role as portals to internal systems and application servers (as for layered applications) as well as internal networking resources. DMZ-resident systems typically allow either outbound initiation of sessions to the untrusted zone (e.g., e-mail or web access), or inbound connections of limited types (e.g., e-mail, web services, or business partner connections). Alternatively, a system may be known to the organization, but the user cannot be authenticated; or the system could be identified as a potential threat because protective anti-malware or other mechanisms are 14
BURTON GROUP 7090 Union Park Center Suite 200 Midvale · Utah 84047 · P 801.566.2880 · F 801.566.3611 · www.burtongroup.com

missing or not up-to-date. Thus, that system may be dynamically placed in the DMZ to obtain some limited services and/or remediation of its security problems, but it cannot be fully trusted with access to internal networks or zones where more sensitive systems or information may reside.The Reference Architecture templates for the data center (e.g., “AFE/Server/Storage Sub-Template: Inline Firewalls”) depict the typical physical topologies recommended for deployment of a DMZ. • Trusted zone: This zone (formerly known as the business zone) typically contains systems owned and controlled by the enterprise as well as systems used, and, in some limited cases, owned by visitors. This zone is where most day-to-day business activities with low individual but high aggregate value take place. The zone may allow certain classes of users to connect to the Internet via web gateways or other proxy servers, allow file transfer protocol and similar access, and may even allow instant messaging and other related services. Enterprise-controlled systems in this zone are configuration controlled to ensure that virus protection and similar measures are in place, to detect illegal software and peer-to-peer connections, and for other similar purposes. Physically, the trusted zone may include resources hosted at multiple sites, such as data centers or office facilities. Various Reference Architecture templates for the data center (e.g., “AFE/Server/Storage SubTemplate: Inline Firewalls”) as well as the templates for smaller and larger sites (e.g., “Larger Site: VPN Private/Network VPN, Split Tunnel”) depict the typical physical topologies recommended for deployment of a trusted zone. Trusted zone systems are not open to direct connection from the untrusted zone, because either network security mechanisms or endpoint security mechanisms are in place to limit communications. However, trusted zone systems may connect to systems in the untrusted zone for legitimate business purposes. Such connections open these systems to compromise by malicious code and other intrusions, so additional security mechanisms are placed within the perimeter and on the systems themselves. Systems such as fixed desktops in firewallprotected facilities may not be susceptible to direct compromise from the Internet and, if any of these individual systems should fail, it is not usually of high consequence to the enterprise. Therefore, the need for endpoint security mechanisms on some trusted zone members is not as strong as for systems in the DMZ. However, laptop or home systems placed temporarily or permanently outside the enterprise network may require protections such as VPNs and system firewalls to maintain their zone integrity from the remote location. The trusted zone may also be subzoned to disaggregate risk or to meet other security requirements (see the “Subzones” section of this technical position). • Restricted zone: The systems in this zone are known to and controlled by the organization. They pose a significant risk to the enterprise if they fail to perform their business functions properly and in a timely fashion, or if the information residing on them is compromised or changed in an unauthorized manner. Higher levels of configuration and change control are associated with these systems. They are only open to connections from a limited number of other systems, if any, which are themselves carefully controlled. Typically, they only connect to systems in the trusted zone, and perhaps then only through a proxy. Physical security measures are used to insulate these systems from various hazards, and they are replicated to ensure availability and business continuity. Systems in the restricted zone pose a significant risk to the organization because of the critical or sensitive information they store, or because of the functions they perform; therefore, they are protected to a higher degree than other systems. Database servers, data center operations, security policy servers or repositories, and other critical facilities should reside in the restricted zone. The restricted zone may itself be divided into subzones to reduce the risk of unnecessary interaction between unrelated systems. The Reference Architecture templates for the data center (e.g., “AFE/Server/Storage Sub-Template: Inline Firewalls”) depict the typical logical and physical topologies recommended for deployment of a restricted zone. The actual number, type, and topology of zones depend on the business requirements as well as the complexity of the resources and security requirements within the scope of an organization's perimeter architecture. Recall that an organization may have multiple architecture scopes for zones ranging from simple to complex. For example, a small business or business unit with a single, simple perimeter architecture scope may not require both a trusted zone and a restricted zone. However, many organizations use zone architectures similar to the one shown above. One customer said their “mission critical zone” was like a “restricted zone” and that some other zones that had similar connectivity requirements to one another could instead have been modeled as subzones.

15
BURTON GROUP 7090 Union Park Center Suite 200 Midvale · Utah 84047 · P 801.566.2880 · F 801.566.3611 · www.burtongroup.com

Perimeter security mechanisms are used between each layer to control the flow of connections and information. Functional paths are made available based on business requirements, and those paths are controlled based on business risk. The standards enforced by the perimeter security mechanisms reflect the business needs and risks associated with the systems in the different zones. A three-tier application architecture (e.g., the one shown inFigure 2) can overlay zones of trust such that the presentation functionality is in the DMZ, the business logic is in the trusted zone, and the information resides in the restricted zone. This meets the application's connectivity requirements while protecting sensitive information from direct compromise. Clearly, not all systems that have an affinity should be required to reside in the same zone, and in many cases, probably should not be in the same zone. The layered application scenario is shown in logical diagram inside of the Reference Architecture templates for the data center (e.g., “AFE/Server/Storage SubTemplate: Inline Firewalls”). Network security zones should be viewed as logical partitions that may span physical locations in such a way that they are connected by a communication path traversing a zone of lesser trust. For example, an organization may have a trusted zone in many locations that are connected by a VPN. All of these locations apply the same or equivalent perimeter security controls so, logically, there is a single trusted zone within the organization. For example, the logical sub-templates inside of the Reference Architecture templates “Smaller Site: Internet VPN Split Tunnel” and “Larger Site: Private VPN Forced Backhaul” show examples of multiple physical locations spanning a trusted zone. Great care must be taken in this approach, however, because different but seemingly equivalent protective barriers in different locations may combine to create vulnerabilities that are not obvious. The layered approach provides the combination of communications and control that is lacking in the other two approaches. In addition to perimeter security mechanisms that allow or deny connections and monitor, filter, or control the network, internal detection and reaction mechanisms may be appropriate to monitor or control content and activities that do not pass zone perimeters, such as paths through routers within a zone.

Subzones
“Subzones” are defined as “a subset of a zone demarcated by a network perimeter or a virtualized perimeter solution.” Subzones need to be separate from other parts of their containing zone but should still maintain the same basic connectivity characteristics as the rest of the zone. For example, a subzone of the DMZ will still allow some connections from the untrusted zone, but the systems in the subzone may be limited in terms of which external systems can initiate connections and which other systems in the DMZ or other internal zones can communicate with them. It may be inappropriate for organizations to group all of the systems within a zone together. Some reasons include: • Risk aggregation: Placing too many systems of the same type, or systems that can interact with each other, in the same zone might result in higher consequences if a single system is compromised. For example, if all client systems are members of the same zone, a single malicious code event may be able to disrupt all client systems, thus causing significant harm to the organization. It may be more appropriate to divide the client systems into subzones so that the damage a single event might do is limited. Such subzones might be created on a regional basis, by business unit, or some other criteria. • Business requirements: Agreements between an organization and its business partners may require that certain information or systems be kept confidential or be protected from compromise by events on unrelated systems while, at the same time, allowing communication between business partners and the organization. Because the business partners are in the untrusted zone, these systems should be placed in the DMZ. However, because the systems must be further protected to meet the terms of the contract, the systems should be placed in a subzone that allows connections from an individual business partner but not from other portions of the DMZ or from other systems in the untrusted zone. A service provider might find that subzones are an appropriate way to separate client systems. • Regulatory requirements: Regulations that require separation of sensitive information such as health or financial data may mandate the creation of subzones in order to comply with the requirements, or to reduce the scope and cost of auditing. 16
BURTON GROUP 7090 Union Park Center Suite 200 Midvale · Utah 84047 · P 801.566.2880 · F 801.566.3611 · www.burtongroup.com

Subzones may exist within any of the internal zones (DMZ, trusted, or restricted) such that systems in one subzone may not communicate with systems in another subzone without crossing some type of perimeter security mechanism (for example, see the subzone in the DMZ in Figure 6). Subzones may also exist in the closed architecture. In some cases, the perimeter security mechanisms might use strong firewall security mechanisms to completely disallow communication between subzones. In other cases, network segments or virtual local area networks (VLANs) may create subzones in a relatively inexpensive but weak manner using routers with access control lists (ACLs), provided the risk is low or the most serious threats crossing subzones are mitigated by other means. The number of subzones and the security policies applied at the perimeters are governed by business requirements. There may be any number of subzones within each zone, depending on how the organization sees fit to separate systems. However, the number of subzones is tied to the costs associated with perimeter protection mechanisms. The larger the number of required perimeters, the higher the cost in terms of mechanisms and management. Organizations should examine their systems to identify the most appropriate way to divide them into subzones in order to minimize overall risk and to control costs. Depending on the agreements in place, it may be necessary to further divide a subzone. In this case, one or more systems require additional protection from other systems within the subzone, and another perimeter is established to separate the systems within the subzone (see Figure 6). However, it is rare for this recursion to go very far. Logical controls at the identity or system layers can also be used to create access control overlays (sometimes referred to as enclaves) within or across zones and subzones. Within these areas, databases may enforce additional separation based on query controls. Beyond that level of granularity, the principle is rarely carried further, largely because no meaningful separation has been identified below the level of the individual field within a record.

Figure 6: Subzones Within Subzones

Control and Audit
The control and audit functions for an IT environment are different from the normal network and system activities of transporting, processing, and storing content. Organizations may choose to create separate parts of the network to contain these functions. Control and audit zones may exist in any of the three architectures (open, closed, or layered) used by an organization. The control and audit zones are depicted graphically in Figures 7 and 8.

17
BURTON GROUP 7090 Union Park Center Suite 200 Midvale · Utah 84047 · P 801.566.2880 · F 801.566.3611 · www.burtongroup.com

Figure 7: Control and Audit Zones Added to the Layered Architecture

18
BURTON GROUP 7090 Union Park Center Suite 200 Midvale · Utah 84047 · P 801.566.2880 · F 801.566.3611 · www.burtongroup.com

Figure 8: Control and Audit Zones Added to the Closed Architectures

Control Zone
A control zone is used to separate the functions associated with network and security management from the normal activities of endpoints and servers. Due to the nature of the control zone, it must touch all the devices on the network to some extent and this causes the zone to include both physical and virtual perimeters. Some devices (e.g., routers or network intrusion detection and response systems [NIDRS]) may include separate network interfaces for control and monitoring. (More detailed positions on the use of NIDRS can be found in the Reference Architecture technical position “Network Intrusion Detection and Response.”) When these devices are available and are physically located near the control and management systems, they may directly connect to a separate control network. Devices that are not physically co-located with the control and management systems generally use the network as the transport mechanism to communicate with the appropriate control system. In these cases, the network traffic is virtually separated through the use of encryption (often a VPN). While it is possible to attach additional network interfaces to servers and other managed devices for the specific purpose of management, this is rarely done. Instead, the management functions are limited through the use of strong authentication and access control mechanisms within the system and encryption across the network. If the mechanisms of the system are not sufficient, third-party software mechanisms can be used to limit connectivity to the system. These mechanisms provide some assurance of separation, but that level of assurance is less than what can be achieved through network separation mechanisms.

19
BURTON GROUP 7090 Union Park Center Suite 200 Midvale · Utah 84047 · P 801.566.2880 · F 801.566.3611 · www.burtongroup.com

The control zone itself can be divided into subzones so that the risk associated with combining all network and system control functions does not exceed risk aggregation thresholds. (More information on risk aggregation can be found in the Security and Risk Management Strategies overview “Risk Aggregation: The Unintended Consequence.”) Subzones can be created to control the network and perimeter security devices that make up the various security zones. An additional zone may be created for server management functions so that they are separated from the network device management. Security functions may also be separated from other network operations functions. Systems in the control zone will generate audit information that may be passed to an audit zone for storage and analysis. Also, see the logical flow diagram for systems/network management and control in the Reference Architecture templates for the data center (e.g., “AFE/Server/Storage Sub-Template: Inline Firewalls”).

Audit Zone
An audit zone or subzone can be used to separate the monitoring and verification function from the main portion of the network as well as from the control function. Audit event information from all kinds of systems is passed to the audit zone. Once into the audit zone, the information is protected (for confidentiality, integrity, and use control) and is not passed back to other zones of the network in its original state. Individuals charged to perform audit functions are provided access to the information and may choose to allow some information out of the audit zone once it has been filtered to remove sensitive information. As surety requirements for the audit zone increase, additional mechanisms must be put in place to control the use of covert channels that might be used to pass sensitive information out from the audit zone. The use of an audit zone may slow the response to network and system events as the event information may take time to arrive at the control systems or the operations staff charged with responding to the event. In these cases, the audit zone may capture and retain the authoritative copy of the event information but various control and monitoring systems may also receive a copy of the event thus allowing a faster response to be initiated. In some environments, the audit zone may be divided into subzones (that may be implemented as subzones within the DMZ, trusted, and restricted zones of the network) so as to reduce the risk associated with the aggregation of functions and information. Correlating events across systems and security zones is difficult if not impossible in such cases. However, if the necessary information can be safely aggregated to a security information and event management (SIEM) system in the audit zone, this zone is a good place for the correlation function as it is separated from the other zones, and separation from the control zone in particular reduces the aggregated risk of putting a great deal of security information in one place. Once the event information is correlated and examined, filtered reports may be passed out of the audit zone so that action can be taken. The audit information and functionality can also be separated from other zones by placing it inside one or more subzones of the control zone.

20
BURTON GROUP 7090 Union Park Center Suite 200 Midvale · Utah 84047 · P 801.566.2880 · F 801.566.3611 · www.burtongroup.com

Future Developments
The future of the well-defined, hard perimeters that have surrounded organizations in the past is seriously in doubt. As perimeters continue to become more porous, security policy decisions that have traditionally been enforced by perimeter systems will migrate into mechanisms installed on desktop computers and mobile systems. At the same time, more partners, suppliers, and contractors will require interaction with systems that have normally been considered to be internal. This trend imposes further requirements on each system to protect its resources at a more granular level, thus moving enforcement points closer to (or even onto) the individual target resources. PEPs at internal network perimeters will become more identity and web services aware. They will be able to grant or refuse access based on various criteria such as user ID, system type, system compliance with policy, and security mechanisms enabled. This capability will increase the organization's ability to place systems into appropriate zones and enforce more complex zone boundary rules. Zones themselves will begin to look more logical, and less physical, as increasingly zone perimeter enforcement uses secure protocols and VPNs as overlay mechanisms crossing many sites and untrusted networks. The overlay model will also necessitate that network perimeter systems become more integrated with security mechanisms placed on the endpoint systems themselves so that the perimeter mechanisms can make appropriate, policy-based decisions about how a particular system should be protected, and whether that system poses a danger to other systems within the zone.

21
BURTON GROUP 7090 Union Park Center Suite 200 Midvale · Utah 84047 · P 801.566.2880 · F 801.566.3611 · www.burtongroup.com

Evaluation Criteria
In addition to the Reference Architecture principles, the following evaluation criteria should guide an organization's perimeter and zoning architecture decisions about the position statements found in the “Statement & Basis for Position” section of this technical position: What business requirements are placed on systems and their ability to communicate? Business requirements drive network and security architecture. Therefore, the organization must understand how the systems will be used in order to properly develop a perimeter and zone architecture. An understanding of the consequences of failure (either perimeter devices that fail or communications that fail because of a false positive) must also be understood. Does the organization have contractual requirements to separate systems or information? Contractual requirements may drive separation requirements especially when contracts dictate specific protective measures or specific consequences if a breach should occur. In most cases, contractual requirements will impact subzoning decisions. What laws and regulations govern the organization's business? Regulations may impact security requirements and consequences and thus may either impose particular mechanisms, or may impact the surety levels required. Audit considerations may make it desirable to separate systems that are within scope of a particular regulation so that other systems will not be affected by an audit. Does the network and application infrastructure have the flexibility to separate systems into zones? Organizations may have networks that were designed many years ago and legacy servers, control mechanisms, or applications that rely on particular network protocols or hard coded IP addresses in order to function. Some organizations have outsourced the management of internal networks. In either case, changes to the network (e.g., adding perimeters or moving systems between network segments) may be difficult, expensive or both. Proper planning is required to identify alternatives to physically moving systems that will meet surety requirements.

22
BURTON GROUP 7090 Union Park Center Suite 200 Midvale · Utah 84047 · P 801.566.2880 · F 801.566.3611 · www.burtongroup.com

Statement & Basis for Position
Position statements for perimeters and zones are first defined by scope. For each defined scope, the other positions should then be considered. • Scope How many instances of zoning architecture does the organization require? For each scope identified in the above question, all of the following positions apply: • Open, Closed, or Layered Zone Architecture Should the architecture be open, closed, or layered? • Layered Network Security Zones Should untrusted, DMZ, trusted, or restricted zones be used within the organization? • Subzones Should the organization create subzones within zones? • Control and Audit Zones Should the organization use a control zone? Should the control zone be divided internally? Should the organization use an audit zone? Should the audit zone be divided internally? Positions on the perimeter mechanisms that should be deployed to protect the zone boundaries are provided in the forthcoming Reference Architecture technical position “Network Perimeters.” Questions about placing systems into the zones defined in this technical position (and the trust mechanisms that should be deployed on those systems) are provided in the closely related Reference Architecture technical position “System Placement.”

Scope Position
How many instances of zoning architecture does the organization require? The logic for choosing zoning architecture scope, or the number of zone architectures that are required for an organization, is as follows: IF business requirements or constraints dictate that portions of the organization use a different architecture OR IF the organization has divisions, business units, or subsidiaries with specific security requirements or separate security controls THENcreate a separate perimeter architecture for each portion of the organization or subsidiary. OTHERWISEuse one perimeter architecture for the entire organization. Alternative Scope position statements (important: choose only one):

Create a separate perimeter architecture for each portion of the organization or subsidiary.

23
BURTON GROUP 7090 Union Park Center Suite 200 Midvale · Utah 84047 · P 801.566.2880 · F 801.566.3611 · www.burtongroup.com

Organizations today are very complex in terms of how their components relate to each other and to the organization as a whole. Some organizations have very distributed control structures. In such a case, it may not be appropriate to have a single perimeter architecture for the organization. Each division or portion of the organization must make its own architectural decision. Likewise, divisions or subsidiaries that perform functions requiring separate network architectures should make their own architectural decisions. For example, an organization that performs classified work for a national government may be required to segregate the network with the classified information and create a closed environment that is separate from the rest of the organization. Organizations also create joint ventures with partners. In such a case, the control of the joint venture may not be under the sole control of the organization, so it is appropriate for the joint venture to determine its own architecture. In a case where an organization provides common network services to divisions or subsidiaries, depending on the control exercised by the central organization, the subsidiaries may choose their own architectures and may decide to view the other parts of the organization as external to them. It may also make sense for parts of larger organizations to operate like SMBs and have separate perimeter scopes that use the open architecture, which offers considerable flexibility. On the other hand, creating many architecture scopes to increase openness might lead to inconsistency in IT security policies and increase exposure; another choice that allows for communications autonomy is to let small groups use the overlay model with split tunneling and no firewalls at their smaller sites. Or…

Use one perimeter architecture for the entire organization.
When the entire organization is under centralized control, and similar security requirements are placed on all portions of the organization's network, a single scope can be defined. In this case, a single architecture is identified as being appropriate for the organization's networks, and that architecture is implemented.

Open, Closed, or Layered Zone Architecture Position
Should the architecture be open, closed, or layered? For each scope defined within an organization, a separate zoning architecture decision should be made. The choice of architecture is an important global decision that affects the entire outlook of the organization. Once chosen, it is not easy to change, and, in fact, may be very expensive or even infeasible to change due to the farreaching effects that the choice of architecture has on the organization's infrastructure and people. The primary factors to consider when choosing an architecture are the business requirements (including how the organization uses its network), what types of information or capabilities are available, and who uses these systems. The logic for choosing open, closed, or layered perimeter architecture is as follows: IF the confidentiality, integrity, use control, and/or localized availability of all the systems on the internal network is more important than communication to outside parties THENuse a closed architecture OTHERWISE IF collaboration and convenient global and mobile access is of primary importance, and the user community uses systems that are independent of any central control scheme (for example, the systems may be geographically distributed) THENuse an open architecture OTHERWISEuse a layered architecture

24
BURTON GROUP 7090 Union Park Center Suite 200 Midvale · Utah 84047 · P 801.566.2880 · F 801.566.3611 · www.burtongroup.com

Alternative Open, Closed, or Layered Zone Architecture position statements (important: choose only one per scope):

Use a closed architecture.
A closed architecture relies upon physical security for perimeter control of the environment. While the architecture of such an environment is relatively simple, the policies and procedures can be onerous. The physical measures employed prevent all unauthorized access to the environment, so there must be a means for users to be properly identified and cleared to enter the facility. Systems and storage media must undergo the same type of process before they can enter the facility. Once in the facility, the media are tightly controlled, and the procedures for removing them may be extensive and require significant approvals. Particular attention is usually paid to the lifecycles of systems and data in this environment. Facilities that process classified information are an example of the appropriate use of a closed architecture. Business may be hampered by the lack of communications available between such a facility and the rest of the world, but that is the price paid for this level of protection. Few if any communication lines are available, and available lines have extremely tight security surrounding their use. While the costs of IT security mechanisms may be low, the overall cost of building this type of facility (in terms of physical security, personnel security, and business impact) must be carefully weighed. Given these issues, this architecture is only appropriate for very-high-security environments in which communications takes a back seat to integrity, local availability, confidentiality, or use control. Note that control and audit zones still apply to the closed architecture and are held within the physical enclosure. With approved cryptographic or physical controls, multiple locations of a closed architecture may also be connected together, but only if each of them and the communications between them meets the requirements of the enclosure. This extension of trust is in tension with the high-surety requirements of separation for these environments. Or…

Use an open architecture.
An open architecture relies upon each individual system to protect (or forgo protection of) the information or capabilities that reside there. The open architecture provides maximum flexibility in connectivity and access for users. However, an open architecture does introduce additional risk if systems are not properly configured for security. In this architecture, the organization does not exert direct control over system configuration. Therefore, monitoring for system compliance may be critical to managing risk because any system could be attacked and compromised if not properly secured. The potential for systems to be added to the community of interest without the organization's knowledge is also something that must be considered. If an open architecture is used, careful consideration must be given to how the systems will be individually secured to levels commensurate with their risks, and how other measures (e.g., virtual desktops, authentication/authorization and/or rights management) may be used to manage risk in the open, distributed environment. Or…

Use a layered architecture.
If extreme circumstances don't dictate an open or closed architecture, then a layered architecture approach is likely to be the best choice for protecting sensitive systems while providing appropriate access.

25
BURTON GROUP 7090 Union Park Center Suite 200 Midvale · Utah 84047 · P 801.566.2880 · F 801.566.3611 · www.burtongroup.com

A layered zone architecture enables the organization to balance business requirements with the need to protect sensitive systems from attack (and thus manage the risk to the organization). However, the organization must determine the appropriatezones and perimeter security mechanisms. A layered architecture allows different security requirements to be accommodated within an interconnected network. Perimeters are established between and within layers, and appropriate policy technical controls and technical security policies are applied at each of these perimeters. Differing business requirements for confidentiality, integrity, availability, use control, and connectivity can be accommodated by using zones and perimeter mechanisms. This architecture should be used for most of the computing resources of large enterprises.

Layered Network Security Zones Position
Should demilitarized, trusted, or restricted zones be used within the organization? The logic for choosing which types of zones to create in a layered architecture is as follows: IF the organization connects to networks that are not controlled by it THENcreate a perimeter between internal systems and all external systems IF the organization allows connections from external or untrusted users to some internal systems THENcreate a demilitarized zone (DMZ) IF the organization has a set of systems that is not required to accept connections directly from the untrusted zone and that should only be used by known, relatively trusted users or systems THENcreate a trusted zone IF the organization has systems that should only be available to a subset of employees OR that contain especially sensitive information or capabilities THENcreate a restricted zone Alternative Layered Network Security zones position statements (choose all that apply):

Create a perimeter between internal systems and all external systems.
Because the untrusted, or external, zone exists regardless, the organization must create the perimeter that defines how far into the organization the untrusted zone extends. It should include the Internet (if connected) and any other networks that are outside the organization's control, such as business partners or portions of the organization that have no perimeter security mechanisms. While outermost perimeters between the organization's facilities and the untrusted zone may have multiple “holes” to admit communications needed for the business, these perimeters may still be effective in creating a legal boundary for the organization, thwarting denial of service (DoS) attacks and stopping obviously malicious traffic such as worms and attacks with recognizable signatures. Or…

Create a demilitarized zone (DMZ).
The DMZ (formerly known as the outer zone) contains systems that receive connections originated by systems outside the organization's control or systems that allow access by untrusted users. A perimeter is established between the untrusted zone and the DMZ. This perimeter only allows connections that are appropriate for the business functions of the systems in the DMZ. A perimeter is also established between the DMZ and any zones further inside the organization's environment. 26
BURTON GROUP 7090 Union Park Center Suite 200 Midvale · Utah 84047 · P 801.566.2880 · F 801.566.3611 · www.burtongroup.com

Or…

Create a trusted zone.
The trusted zone (formerly known as the business zone) contains systems that do not receive connections directly from systems in the untrusted zone. Systems in the trusted zone may initiate connections to systems in the untrusted zone. A perimeter separates the trusted zone from the DMZ. Or…

Create a restricted zone.
The restricted zone contains systems that are especially sensitive because of either the information they contain or the functions they perform. Only a limited number of users and systems are allowed to access these systems, and no connections are allowed between these systems and other zones except the trusted zone. A perimeter separates the restricted zone from the trusted zone.

Subzones Position
Subzones can be created to separate functions and information within a zone from the rest of the zone. The subzones position should be considered for each zone in the organization's IT environment. Should the organization create subzones within zones? The logic for determining the need for subzones within zones is as follows: IF business, contractual, or regulatory requirements mandate that certain information or systems be separated from other systems in the same zone OR IF enabling connectivity among all the systems in the zone would exceed risk aggregation thresholds THENcreate subzones OTHERWISEdo not create subzones Alternative Subzones position statements (important: choose only one):

Create subzones.
Subzones are created within any zone (except the untrusted zone) for which it is required or desired to separate some systems from others in that zone. The subzone is separated from the other systems in the zone by a perimeter that enforces an appropriate policy as defined by the business, contractual, and/or regulatory restrictions. Any number of subzones can be created based on the organization's needs. In some cases, subzones themselves may be further divided. However, organizations must ensure that—in the target architecture timeframe—it is desirable to replace, or reasonable to work around, any constraints imposed by certain brands of servers and authentication services, such as older Windows servers, which may create issues with usage and control in a subzoned environment. Or…

Do not create subzones.

27
BURTON GROUP 7090 Union Park Center Suite 200 Midvale · Utah 84047 · P 801.566.2880 · F 801.566.3611 · www.burtongroup.com

Not every organization requires subzones. In many cases, contractual obligations and regulatory requirements do not require separation. Also, subzoning may not be required to disaggregate risks when an entire zone is contained in a small or medium site, or where the zone contains non-essential functions with very low risks. In these cases, the creation of subzones would increase the number of perimeter mechanisms required and increase the overall cost for little benefit.

Control and Audit Zones Position
Control and audit functions and their attendant data often should be separated from other zones in the organization's IT infrastructure. There are four position statements for control and audit zones: • Control Zone Should the organization use a control zone? • Control Zone Internal Structure Should the control zone be divided internally? • Audit Zone Should the organization use an audit zone? • Audit Zone Internal Structure Should the audit zone be divided internally?

Control Zone Position
Should the organization use a control zone? The position statement for control zones is:

Use a control zone.
Control zones are used to separate the functions associated with network and security management from the normal activities of end points and servers that use the network. Control zones are separated through physical and/or virtual means—routers may have a separate management interface that connects to a physical control network, while servers may use agents that limit access to certain management functions using identity-based or cryptographic controls. Control traffic that flows over the network may also be separated through the use of encryption such as in the case of a VPN, by controls over media access control (MAC) address and IP address, by locality on a network, network distance, or other characteristics.

Control Zone Internal Structure Position
Should the control zone be divided internally? The logic for choosing to divide the control zone internally is as follows: IF combining all control functions would exceed risk aggregation thresholds OR violate strong separation of duty requirements OR there are strong requirements to prevent privileged administrators from having the ability to examine, alter, use, or make unavailable all content in the control zone or systems controlled from the control zone THENdivide the control zone into subzones OTHERWISEdo not divide the control zone

28
BURTON GROUP 7090 Union Park Center Suite 200 Midvale · Utah 84047 · P 801.566.2880 · F 801.566.3611 · www.burtongroup.com

Alternative Control Zone Internal Structure position statements (important: choose only one):

Divide the control zone into subzones.
Subzones can be created in the control zone as required. Separate subzones can be created to manage devices and systems within a zone (e.g., one subzone for the restricted zone, one for the trusted zone, and one for the DMZ), to separate the management of network devices from systems from data, or to separate network operations from security operations. The internal structure of the control zone reflects the complexity of managing a large network. Perimeter mechanisms for the control subzones must be at least the same level of surety as that of the layered architecture the subzone supports. Or…

Do not divide the control zone.
In some cases, an organization may be able to maintain a single control zone to manage the entire IT environment. This normally occurs when the network is not inordinately large or complex or when closed or open architectures are used.

Audit Zone Position
Should the organization use an audit zone? The logic for determining the need for an audit zone is as follows: IF risk management or regulatory requirements dictate that audit data and functions should be strongly separated from all other control and management functions THENuse an audit zone OTHERWISEuse other means to protect audit data and functions Alternative Audit Zone position statements (important: choose only one):

Use an audit zone.
The integrity and confidentiality of audit information must be protected, in some cases even from the staff that manage and control the organization's IT environment. Audit repositories should essentially support only “append” and “read only” operations, with no capacity for anyone, including systems and network administrators, to alter information once placed there. In some cases, the requirement to protect audit information is so strong that full perimeter protection should be used in addition to identity based access controls, system level protection and application level protection around the audit information. In such cases, audit information should be segregated in its own zone, and audit information that flows over the network should be transformed and separated from other traffic by secure protocols. While audit information and functions should be separated, event information may be needed by the control systems so that proper and timely responses can be mounted. Event information can be copied to the control zone for this purpose, but the authoritative copy of the information resides in the audit zone. The information can be filtered (so that sensitive information is no longer included) and then passed back out of the audit zone to be used for other purposes. Or…

Use other means to protect audit data and functions.
29
BURTON GROUP 7090 Union Park Center Suite 200 Midvale · Utah 84047 · P 801.566.2880 · F 801.566.3611 · www.burtongroup.com

The integrity and confidentiality of audit information must be protected. Audit repositories should essentially support only “append” and “read only” operations, with no capacity for anyone, including systems and network administrators, to alter information once placed there. Separation of audit data and functionality may also be implemented by placing it in a subzone of the control zone, or entirely through non-perimeter layer mechanisms such as encryption and access control.

Audit Zone Internal Structure Position
Note: The logic regarding whether to divide the audit zone into subzones can also apply when an audit subzone of the control has been selected per the position above; in such a case, a second level of subzones could be used. Should the audit zone be divided internally? When an audit zone or subzone is required, the logic for choosing to divide it internally is as follows: IF combining all audit functions would exceed risk aggregation thresholds, violate separation of duties, or otherwise run afoul of business requirements OR there are individuals who have access to the audit zone and are not authorized to examine all content that may be stored there THENdivide the audit zone into subzones OTHERWISEdo not divide the audit zone Alternative Audit Zone Internal Structure position statements (important: choose only one):

Divide the audit zone into subzones.
Subzones can be created in the audit zone as required. Separate subzones can be created to receive audit information from devices and systems within a zone (e.g., one subzone for the restricted zone, one for the trusted zone, and one for the DMZ) or they can be created to group audit information by other criteria. The organization of the audit zone reflects the duties and divisions of the audit function of the organization. Perimeter mechanisms for the audit subzones must provide at least the same level of surety as that of the layered architecture the subzone supports. Or…

Do not divide the audit zone.
In some cases, an organization may be able to maintain a single audit zone for the entire network. This normally occurs when the network is not inordinately large or complex or when closed or open architectures are used.

30
BURTON GROUP 7090 Union Park Center Suite 200 Midvale · Utah 84047 · P 801.566.2880 · F 801.566.3611 · www.burtongroup.com

Relationship to Other Components
The Reference Architecture technical position “Network Perimeters,” discusses the perimeter mechanisms used to protect logical zone boundaries and physical site topologies. The following Reference Architecture templates provide logical and physical views of various perimeter and zone topologies: • • • • • • • • • • “Smaller Site Internet VPN Forced Backhaul” “Smaller Site Internet VPN Tunnel” “Smaller Site Private VPN Split Tunnel” “Smaller Site Private VPN Forced Backhaul” “Larger Site Internet VPN Forced Backhaul” “Larger Site Internet VPN Tunnel” “Larger Site Private VPN Forced Backhaul” “AFE/Server/Storage Sub-Template: Inline Firewalls” “AFE/Server/Storage Sub-Template: Reusable Switched” “AFE/Server/Storage Sub-Template: Replicated Switched”

The Reference Architecture technical position “System Placement,” discusses how systems are placed into zones. The Reference Architecture technical position “Information Confidentiality,” discusses the appropriate layers at which to deploy confidentiality mechanisms. The Reference Architecture technical position “Information Integrity,” discusses the appropriate layers at which to deploy integrity mechanisms. The Reference Architecture templates “Protecting Data in Motion,” “Protecting Data at Rest,” “Discovering Sensitive Resources,” and “Mitigating Malware and Spam” depict and discuss how PEPs (including those in the perimeter layer) can be used to manage the risk to systems and to the organization.

31
BURTON GROUP 7090 Union Park Center Suite 200 Midvale · Utah 84047 · P 801.566.2880 · F 801.566.3611 · www.burtongroup.com

Revision History
November 2007: • The document was modified to reflect changes in zone naming. • Audit zone was made optional. • All detailed discussion of perimeter mechanisms will be split out into a separate “Network Perimeters” technical position. April 2006: • Added positions and alternatives for control and audit zones. • Changed the “Perimeter Mechanisms” section and positions to focus on the functions of the perimeters and how various devices may meet those functions rather than on the devices themselves. • Changed the term “compartments” to “subzones.” • Updated the “Typical Requirements” section. • Updated the scope discussion. • Updated the “Future Developments” section.

32
BURTON GROUP 7090 Union Park Center Suite 200 Midvale · Utah 84047 · P 801.566.2880 · F 801.566.3611 · www.burtongroup.com

Notes
1 Burton Group. Security and Risk Management Strategies “Concepts and Definitions.” 1 May 2007. http://www.burtongroup.com/Client/Research/Document.aspx?cid=644.

33
BURTON GROUP 7090 Union Park Center Suite 200 Midvale · Utah 84047 · P 801.566.2880 · F 801.566.3611 · www.burtongroup.com

Author Bio
Dan Blum Senior Vice President and Principal Analyst Emphasis: Security Technologies; Background: Daniel Blum is the senior vice president and principal analyst for Burton Group’s Security and Risk Management Strategies service. He covers security architecture, identity management, federated identity, and security technologies. Daniel has consulted many Global 1000 companies on key strategic architecture and technology decisions. He has participated and contributed to standards organizations such as the International Information Integrity Institute (I4), Electronic Authentication Partnership (EAP), Internal Standards Organization (ISO), and National Institute of Standards (NIST). He works with the Organization for the Advancement of Structured Information Syntaxes (OASIS), and the Liberty Alliance to promote the use of federated identity management through interoperability demonstrations. With XX years of experience, Daniel has co-authored The EMail Frontier, published by Addison-Wesley, 1994 and authored Understanding Microsoft Active Directory Service,” published by Microsoft press, 2000.

34
BURTON GROUP 7090 Union Park Center Suite 200 Midvale · Utah 84047 · P 801.566.2880 · F 801.566.3611 · www.burtongroup.com


				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:197
posted:9/8/2009
language:English
pages:34