Publication Date: May 2009
The Network Security Zoning is an unclassified publication, issued under the authority of the Chief, Communications Security Establishment Canada (CSEC).
For further information or suggestions for amendments, please contact CSEC's IT Security Client Services by e-mail at itsclientservices@cse-cst.gc.ca or call (613) 991-7654 or (613) 991-8495.
This publication takes effect on (01/03/2009).
Gwen E. Beachemin
Director, IT Security Mission Management
© 2009 Government of Canada, Communications Security Establishment Canada
This guideline is intended to assist network architects and security practitioners with the appropriate placement of services (for example, domain name service, email service, and web proxy service) into network security zones.
A service is a logical construct that represent a set of functional requirements in an information technology architecture. These functional requirements can be simple such as providing resolution of domain names, or complex such as processing and transmitting email. Services can be physically implemented in many ways, for example, a single process on server, multiple processes on a virtual machine, or distributed processes among pool of servers.
Concepts used in this document are based on the Baseline Security Requirements for Network Security Zones in the Government of Canada (ITSG-22), which describes the concepts of network security zones and specifies baseline security requirements for zone.
The network security zones in ITSG-22 covered in this guideline are:
To assist in determining the appropriate placement of services, two typical logical zone architectures are illustrated: Internet Service network zone architecture and Departmental network zone architecture.
The primary purpose of the Internet Services network is to provide Unclassified (Protected B and below) business application delivery via the Internet to the public.
The primary purpose of the Departmental network is to deliver Unclassified (Protected B and below) business applications to public servants.
This document is a companion to Baseline Security Requirements for Network Security Zones in the Government of Canada (ITSG-22). This document is an input into the design process not a prescriptive design for all GC networks. The examples described in this guideline are examples only and should not be copied verbatim in any network design.
An element of the design for an IT security infrastructure is the zoning, which segments similar information technology assets (hardware, software, and data) into logical groupings that have the same security policies and security requirements.
A zone, as defined and used in this guideline, is a construct to define standard baseline security requirements that if adopted by GC departments will lead to consistency in their implementation of network security. It demarcates a logical area within a networking environment with a defined level of network security. Zones define the network boundaries and their associated perimeter defence requirements by:
This document is a companion to the CSEC publication, Baseline Security Requirements for Network Security Zones in the Government of Canada (ITSG-22), which describes the concepts of network security zones and specifies baseline security requirements for zones.
The purpose of this document is to assist network architects and security practitioners with the appropriate placement of infrastructure services (for example, domain name service, email service, and web proxy service) into zones. To assist in the understanding of appropriate placement of infrastructure services, two typical logical zone architectures are illustrated:
The primary purpose of the Internet services network is to provide Unclassified (Protected B and below) business application delivery via the Internet to the public.
The primary purpose of the Departmental network delivers Unclassified (Protected B and below) business applications to public servants.
The scope of this document is limited to network security zones, zone interface points (ZIPs), perimeters, and infrastructure services required for the design of zoning architecture (logical) that does not constrain the physical design.
This document addresses the following zones as specified in ITSG-22 [Reference 1]:
This document is written for network architects and security practitioners within the Canadian federal government.
Zoning is used to mitigate the risk of an open network by segmenting infrastructure services into logical groupings that have the same communication security policies and security requirements. The zones are separated by perimeters (Zone Interface Points) implemented through security and network devices.
Zoning is a logical design approach used to control and restrict access and data communication flows only to those components and users as per security policy. A new zone is defined by a logical grouping of services under the same policy constraints, driven by business requirements. When a new set of policy constraints are established, then a new zone is required.
Baseline Security Architecture Requirements for Network Security Zones in the Government of Canada (ITSG-22) identifies seven zones, however this guideline only covers the four most common zones shown in Figure 1:
Each zone has the following fundamental characteristics:
Zones where all components are entirely within or under the control of the GC department are considered controlled zones. In the case where the GC does not control all zone components, the zone is considered uncontrolled.
Data communications entering and leaving a zone must conform to the data communication control requirements set by the policy for that zone.
A zone is a construct to define standard baseline security requirements that if adopted by GC departments will lead to consistency in their implementation of network security. It demarcates a logical area within a networking environment with a defined level of network security. Zones define the network boundaries and their associated perimeter defence requirements. As described in ITSG-22, zones achieved these network boundaries by:
The public zone is entirely open and includes public networks such as the public Internet, the public switched telephone network, and other public carrier backbone networks and services. Restrictions and requirements are difficult or impossible to place or enforce on this zone because it is normally outside the control of the GC. The public zone environment is assumed extremely hostile. [Reference 4]
A PAZ mediates access between operational GC systems and the public zone. The interfaces to all government on-line services should be implemented in a PAZ. Proxy services that allow GC personnel to access Internet-based applications should be implemented in a PAZ, as should external e-mail, remote access, and extranet gateways. [Reference 4]
A demilitarized zone (DMZ) is a component within a PAZ and is not discussed in this guideline.
An OZ is the standard environment for routine GC operations and is where most end-user systems and workgroup servers are installed. With appropriate security controls at the end-systems, this zone may be suitable for processing sensitive information; however, it is generally unsuitable for large repositories of sensitive data or critical applications without additional strong, trustworthy security controls that are beyond the scope of this guideline.
Within an OZ, traffic is generally unrestricted and can originate internally or from authorized external sources via the PAZ. Examples of external traffic sources include remote access, mobile access, and extranets. Malicious traffic may also originate from hostile insiders, from hostile code imported from the public zone, or from undetected malicious nodes on the network (for example, compromised host, or unauthorized wireless attachment to the Zone). [Reference 4]
An RZ provides a controlled network environment generally suitable for business-critical IT services (that is, those having medium reliability requirements, where compromise of the IT services would cause a business disruption) or large repositories of sensitive information (for example, a data centre). It supports access from systems in the public zone via a PAZ. [Reference 4]
A ZIP provides a network interface between a zone and another zone. ZIPs are the logical construct used to describe the controlled interfaces connecting the zones. ZIPs enforce zone data communication policy through perimeter security measures. ZIPs are only discussed in this guideline to bridge the understanding from ITSG-22 ZIPs to perimeters.
ZIPs have the following fundamental characteristics:
The exception to these characteristics is the ZIP required between the PZ and PAZ. The PAZ ZIP must enforce the zone policy requirements for both inbound and outbound traffic because the GC has no control over the PZ and there is no PZ ZIP. This key point is illustrated in Figure 3 below.
In this guidance, a logical construct called a perimeter contains the ZIPs.
As shown in Figure 4 below, the perimeter contains both ZIPs (OZ and RZ ZIPs) and controls the data communication in both directions.
A perimeter is composed of security devices and network devices and represents the ZIPs of each adjacent zone as shown in Figure 5 below.
Using the concept of a perimeter that contains the two ZIPs simplifies the architecture diagrams, but does not change the requirements of ITSG-22 to control data communication in both directions (inbound and outbound) for each zone.
Physical implementations of perimeters (or ZIPs) can be accomplished using a single component or a combination of components as shown in Figure 6. Figure 6 also shows the perimeter is equivalent to the two ZIPs (for example, RZ connecting to the OZ) and the sample physical implementation (for example, firewall, IPS, IDS, and Routers). For example, a router (a network device) may implement part of the perimeter, but it must be used in conjunction with an intrusion prevention system (a security device) and other security devices, which together provide appropriate security safeguards.
Physical representations provided in Figure 6 are examples only and do not indicate a preference of design or approach.
A service is a logical construct that represent a set of functional requirements in an information technology architecture. These functional requirements can be simple such as providing resolution of domain names, or complex such as processing and transmitting email. Services can be physically implemented in many ways, for example, a single process on server, multiple processes on a virtual machine, or distributed processes among pool of servers.
A service can be accessed from other adjacent zones and not just the zone in which it resides.
The following list of services represents the most typical required for an IT infrastructure. The list is not exhaustive.
This section presents the Internet services network zone architecture and the Departmental network zone architecture to illustrate the placement of services.
The example architectures describe the purpose of the network, placement of services, context of the zones within the network zone architecture, and communication policies implemented in the perimeters.
The primary purpose of the internet services network is to provide Unclassified (Protected B and below) business application delivery via the Internet to the public. The Internet services network, illustrated in Figure 7, is built with four controlled zones consisting of the following:
In this architecture, business applications are hosted within GC departments and accessed by the public through the Internet and the SCNet.
In section 3, a list of services was defined. For the Internet services network zone architecture, the following service are typically required:
In the list below, the placements of services in the four zones of Internet Services Network are listed.
The departmental network delivers Unclassified (including Protected A or Protected B) business applications to public servants. The departmental network is built with the following zones:
The network zone architecture for the departmental network is illustrated in Figure 8, where business applications are hosted within GC departmental networks and accessed by public servants. The public servants typically access their business applications from within their departmental network, or over the Secure Channel Network (SCNet) Virtual Private Network (VPN).
In section 3, a list of services was defined. For the departmental network zone architecture, the following services are required:
In the list below, the placement of service in the four zones is shown for the departmental network:
For the zone architecture for Departmental and Internet services networks, each zone has a specific purpose and defined set of characteristics. In the following sub-section, the four types of zones will be described in the context of the Departmental network zone architecture and Internet services network zone architecture. These architectures are illustrated in Figure 9 and Figure 10 respectively.
Public zones are part of the global information infrastructure (Internet). Public carrier backbone networks like the Secure Channel Network and private lines are considered uncontrolled and are therefore treated as public zones because these networks are not owned, managed, and physically controlled by the GC.
The public access zone (PAZ) contains internet related services for external clients. It does not retain any sensitive information, but passes it across the network to other zones. Sensitive information is stored in other zones that are not directly connected to the public zone. The PAZ perimeter to the public zone implements security safeguards that protect PAZ services in the controlled zones (PAZ, OZ, and RZ).
All inbound communication terminates at a service such as a proxy service or email service within the PAZ after being processed at the perimeter.
All other inbound communication that does not terminate at an IT service within the PAZ is blocked.
In some circumstances there may be no proxy service available to terminate specific protocols in the PAZ. This circumstance applies primarily, but not exclusively, to encrypted protocols such as TLS (Transport Layer Security) and SFTP (Secure File Transfer Protocol). A risk assessment should be performed to determine the risks associated with terminating such traffic in the OZ, and the requirement for additional security controls.
All inbound and outbound communication to the public zones should be restricted by blocking network addresses using a black list. Black lists contain a list of public zone network addresses which are unallocated, or are a well-known source of malicious data and/or communication. Black lists are provided through commercial vendors, carriers, and government agencies.
All outbound communications must be filtered so that only valid internal department address ranges are allowed to communicate to the PZ.
All communication between the PAZ and the other controlled zones (OZ and RZ) should be processed by the perimeter and white listed. In case of a departmental network, the OZ email service can only communicate with the PAZ email proxy service. The OZ desktop service must use the PAZ web proxy service, which in turn communicates with the PZ web services. Figure 11 below illustrates the communications paths from the PZ to the RZ.
All communication between the RZ management zone and the other controlled zones (PAZ, OZ, and RZ) should be processed by the perimeter and white listed. Figure 11 illustrates the communications paths from the PZ to the RZ.
Most government activities take place in the controlled zone. OZ systems are allowed filtered access to the PZ for legitimate government activities. OZ computer platforms accessing the PZ will be filtered by Internet proxy services and perimeters in the PAZ.
For example, workstations, printers, and VoIP terminals would be located in the OZ.
OZ services do not communicate directly with the public zone. Encrypted IT service examples such as SSH and HTTPS cannot be properly proxied through the PAZ and should either be denied or white listed using access controls.
White listing is enforcing a set of approved addresses and protocols. A risk assessment should be performed to assess the risk to the network if a protocol cannot be terminated within the PAZ through a proxy.
If the risk assessment results are acceptable to the department, then communications may go through the PAZ and terminate within the OZ.
All communication between the OZ and other controlled zones (RZ and PAZ) should be processed by the perimeter and white listed. The desktop service (web browsing for example) should only communicate with the PAZ web proxy service.
Restricted zones (RZs) contain services for the Departmental and Internet services network operations that require additional safeguards from threats originating from the controlled zones.
For the departmental network, critical data services that need to be protected from the OZ are located in the restricted zone.
The data tier internet services are located in the restricted zone (3rd layer)[Note 3]. This configuration was illustrated in Figure 10. In certain commercial-off-the-shelf applications, the application and data tier services may be bundled in a single product. This restriction would necessitate that the application and data service be deployed in the RZ (2nd tier) instead of an RZ (3rd Tier). The three layer approach is the preferred security architecture because a perimeter can be placed between the application and the database services.
RZ services do not communicate with the public zone directly.
All communication between the RZ and other controlled zones should be processed by the perimeter and white listed. RZs only communicate directly with the OZ and the other RZs. The exception is if the RZ is the management RZ which also communicates with the PAZ.
Departmental and Internet services network architectures have a restricted zone designed specifically for management called the management RZ. This zone contains IT administration related services for the Departmental and Internet services network operations.
Services located in the management RZ only communicate with the public zone via the PAZ for updates from a vendor network sites using appropriate security safeguards that protect integrity and confidentiality of the communication and authenticate the vendor network address.
All communication between the RZ and other controlled zones should be processed by the perimeter and white listed. The management RZ communicates with all controlled zones (OZ, RZ, and PAZ).
Departmental and Internet services network architectures have a restricted zone designed specifically for the application tier internet services called the application tier internet services RZ. This zone contains application tier internet services.
Management RZ services only communicate with the public zone via the PAZ for updates from controlled vendor network sites using appropriate security controls that protect integrity and confidentiality of the communication and authenticate the controlled vendor network address.
All communication between the RZ and other controlled zones should be processed by the perimeter and white listed. The management RZ communicates with all controlled zones (RZs and PAZ).
