Baseline security requirements for network security zones (version 2.0) - ITSP.80.022

Foreword

ITSP.80.022 Baseline Security Requirements for Network Security Zones is an UNCLASSIFIED publication, issued under the authority of the Chief, Communications Security Establishment (CSE).

For more information or suggested amendments, contact the Canadian Centre for Cyber Security (Cyber Centre) Contact Centre:

Contact Centre
contact@cyber.gc.ca
613-949-7048 or 1-833-CYBER-88

This version of ITSP.80.022 supersedes previous versions of the document.

Effective date

This publication takes effect on January 12, 2021.

Revision history

Revision Amendments Date
1 Released version 2.0 January 12, 2021.

Overview

This document outlines network security zone models and architectures and provides technical guidance on implementing network security zones.

The guidance in this document is intended for information technology (IT) solutions operating at UNCLASSIFIED, PROTECTED A, and PROTECTED B levelsFootnote 1 (i.e. low sensitivity or partial sensitivity). Systems operating in PROTECTED CFootnote 2 or classified domainsFootnote 3 (i.e. highly sensitive) require additional design considerations that are not within the scope of this document. You can email or phone our Contact Centre for guidance on cryptographic solutions for PROTECTED C or classified domains.

Your organization is responsible for determining the security objectives that you require to protect information and services. Following only the guidance in this document does not adequately secure an IT environment.

This document is written for IT practitioners who are familiar with the principles, standards, and terminology of network engineering.

Table of contents

1. Introduction

This document explains zoning and the use of network security zones to take a layered approach to security. This document also outlines the functional model of these zones. This model covers the principles and the design philosophy for using different security zones to separate IT infrastructure.

To help you implement network security zones, this document includes the internal configuration and management issues for each zone and zone interface point (ZIP). The security objectives and requirements included in this document define how to connect one zone to another. They also define how to determine whether a direct connection between certain zones is recommended or permissible to maintain the required security level.

Network security zones are the foundations of a balanced and layered security architecture that can support a range of security solutions for your organization’s business needs. These zones also provide a common network infrastructure to support electronic service delivery, interconnectivity, and interoperability. If your organization shares a common infrastructure for online service delivery or other purposes, you must conform to all the security standards established for that infrastructure.

If you’re implementing IT solutions in a Government of Canada (GC) department or agency, you must follow all relevant Treasury Board of Canada Secretariat (TBS) policies, including the following:

  • Policy on Service and Digital [1] Footnote 4;
  • Policy on Government Security [2]; and
  • Directive on Security Management [3].

If your organization is not a GC department or agency, you can still refer to these policies for additional information.

1.1 Relationship to the IT Risk Management Process

Like any IT project or solution, when implementing network security zones, you should consider the IT security risk management activities described in ITSG 33 IT Security Risk Management: A Lifecycle Approach [4]. Figure 1 outlines these activities.

ITSG 33 [4] describes two levels of IT security risk management activities: organizational level activities (also referred to as departmental level activities) and information system level activities. You should include organizational level activities, which are described in Annex 1 of ITSG-33 [4], in your organization’s security programs. This level of activities helps you plan, manage, and assess IT security risks. You should include information system level activities, which are described in Annex 2 of ITSG 33 [4], in an information system’s lifecycle through the information system security implementation process (ISSIP).

Your organization’s implementation of network security zones should align with your current IT security risk management activities, specifically the following: defining organizational IT security needs and security controls, deploying security controls, and monitoring and assessing the performance of security controls. Your implementation should also align with your information system level activities to ensure the solution is dependable. Specifically, you should consider the following phases of the ISSIP: initiation, development and acquisition, integration and installation, and operations and maintenance.

Figure 1: IT Security Risk Management Activities

Long description immediatly follow
Long description

Figure 1 depicts the IT security risk management process that is suggested in ITSG-33 Annex 1 and 2. The figure shows that IT security risk management activities are orchestrated at two distinct levels: the organizational level and the information system level.

At the organizational level, the IT security risk management activities conducted by the organizational security authorities (e.g. CSO, ITSC) include:

  • Define organizational IT security needs and security controls
  • Deploy security controls
  • Monitor and Assess performance of security controls - maintain
  • Identify security control updates

The key deliverables of the deploy security controls activity are organizational control profiles and organizational IT threat assessment reports. These deliverables are key inputs into the security risk management activities at the information system level.

At the information system level, the IT security risk management activities conducted by IT project managers, security practitioners and developers include:

  • Define IT security needs and security controls
  • Design and develop or acquire information system with security
  • Integrate, test, and install information system with security
  • Operate, monitor, and maintain information systems with security
  • Dispose of IT assets securely at retirement

Information from the operations and maintenance activities provide feedback into the monitor and assess activity at the organizational level. The IT security performance feedback supports the maintain authorization activity under the monitor and assess.

2 Network security zones

2.1 Network security zone types

A zone is a networking environment with a well defined perimeter and connection points. This document defines the following types of zones:

  • Public zone;
  • Public access zone;
  • Operations zone;
  • Restricted zone;
  • Highly restricted zone;
  • Restricted extranet zone; and
  • Management zone.

The relationship between these zones is demonstrated in the zone implementation model, which is illustrated in Figure 5 of this document (see subsection 3.2.2).

2.1.1 Public zone

A public zone (PZ) is entirely open and includes public networks, such as the Internet, the public switched telephone network, and other public carrier backbone networks and services. Restrictions and requirements are difficult or impossible to set or enforce on this zone because it is usually outside the control of the GC or the organization. The PZ environment is assumed to be extremely hostile. Any systems delivered in or interfacing with the PZ should be hardened against attack.

Although the PZ is assumed to be extremely hostile, a network security zone authority (see subsection 2.3 for more information) is permitted to use security services from public providers. In fact, the use of security services from public providers is encouraged because it enhances the defence in depth posture. However, you should not discount a PZ’s threat level when developing baseline security requirements.

2.1.2 Public access zone

A public access zone (PAZ) mediates access between operational systems and the PZ. A PAZ is a tightly controlled environment that protects the internal network and applications from the hostile PZ. A PAZ also acts as a screen, hiding internal resources from the PZ and limiting the exposure of internal resources.

The interfaces to all online organizational services should be implemented in a PAZ. Proxy services that allow personnel to access Internet based applications should also be implemented in a PAZ, as should external email, remote access, and extranet gateways.

Extranets connecting via a PAZ are different than those connecting via a restricted extranet zone (REZ) (see subsection 2.1.6). Extranets connecting via a REZ differ mainly in the trust placed in the extranet partner. REZ partners are highly trusted and may connect directly to an internal, organization controlled zone.

2.1.3 Operations zone

An operations zone (OZ) is the standard environment for an organization’s routine operations. An OZ is where most end user systems, application servers, and file and print servers are installed. With the appropriate security controls on the end systems, this zone may be suitable for processing sensitive information. However, in general, this zone is not suitable for large repositories of sensitive data or critical applications.

Within an OZ, traffic is generally unrestricted and can originate internally (i.e. from other zones within an organization) or from authorized external sources (e.g. remote access, mobile access, extranets) via the PAZ and the REZ.

However, in the OZ, malicious traffic may originate from hostile insiders, hostile code imported from the PZ, or undetected malicious nodes on the network (e.g. a compromised host or unauthorized wireless attachment to the zone).

2.1.4 Restricted zone

A restricted zone (RZ) provides a controlled network environment, generally suitable for business critical IT services (i.e. services with medium integrity and availability requirements and that, if compromised, would cause disruption to a business). An RZ is also suitable for large repositories of sensitive information (e.g. in a data centre).

An RZ supports access from systems in the PZ via the OZ and the PAZ. All network layer entities in an RZ are authenticated, either explicitly through the implementation of a peer entity authentication service or implicitly through a combination of physical security and configuration control. The RZ reduces threats from system insiders by limiting access. Threats are also reduced through administrative monitoring. Data confidentiality services are implemented in an RZ to protect zone traffic from being eavesdropped by unauthorized nodes.

2.1.5 Highly restricted zone

A highly restricted zone (HRZ) provides a tightly controlled network environment that, in general, is suitable for safety critical applications (i.e. applications with high availability and integrity requirements that would endanger human health or safety if compromised). An HRZ is also suitable for extensive repositories of sensitive information.

Only other organization controlled zones may access an HRZ (i.e. there is no access by systems in the PZ). All network layer entities in an HRZ are authenticated, either explicitly through the implementation of a peer entity authentication service or implicitly through a combination of physical security and rigorous configuration control. In general, the HRZ has stricter requirements for end systems than the RZ. The HRZ also imposes stricter controls on system insiders, addressing threats from that source.

Data confidentiality services, which are suitable for protecting sensitive information, are also implemented in an HRZ. Data confidentiality services protect zone traffic against being eavesdropped by unauthorized nodes. These services can be implemented at either the network or the physical layer.

2.1.6 Restricted extranet zone

The restricted extranet zone (REZ) may support directly connected extranet services with highly trusted partners. The REZ is not necessarily connected via a PAZ (see Figure 3 in subsection 3.2.1.3).

When implementing a REZ, you need to follow the ISSIP (see Annex 2 of ITSG 33 [4]). Extra controls may be necessary to properly protect the zone connected to the REZ. The requirements and practices for this zone should be developed on a case by case basis and enforced through agreements with partners.

Note: In the context of the GC, connections between GC departments or agencies do not use a REZ; the REZ is only used for connections to organizations outside of the GC (e.g. outsourced IT environments, federal provincial interfaces, integrated services with financial institutions).

2.1.7 Management zone

The management zone (MZ) is an isolated zone, which is similar in build robustness to an RZ. With the MZ, network administrators have a dedicated and isolated administration network for configuring and monitoring network infrastructures. From a security perspective, this zone provides administrators with the capability to perform command and control operations while minimizing the risk of interception or compromise.

GC departments can manage zones remotely if GC approved means are used. In the GC context, zones should only be managed remotely if a department has GC approved, dedicated, and hardened management hosts that are authenticated to an MZ from GC approved locations. Remote management hosts should connect and authenticate through a remote management access zone (RMAZ). The RMAZ has the same networking components and characteristics as a PAZ, but the RMAZ operates on a physically isolated infrastructure.

2.2 Zone interface points

The demarcation area between zones is called the boundary (see Figure 2 below). The boundary contains zone interface points (ZIPs), which are the connecting points between zones. A ZIP is the logical construct used to describe the controlled interface connecting two zones, and it is the network interface between these zones.

ZIPs enforce zone communication policies between two zones. All data communication between zones must be through a ZIP, which exclusively connects these two zones through a unique communication path.

Figure 2: Example of a Zone Boundary

Long description immediatly follow
Long description

Image depicts two network security zones, Restricted Zone (RZ) and Operational Zone (OZ) separated by a Zone Interface Point (ZIP) where bi-directional traffic flows.

2.3 Network security zone authority

Each zone has an assigned network security zone authority, which is an entity accountable for developing, implementing, and maintaining zone security requirements and practices. As defined in ITSG 33 [4], a network security zone authority is one of the functions assigned to an IT security coordinator. The network security zone authority is responsible for the following tasks:

  • Reviewing zone security policies and standards;
  • Recommending zone security policies and standards for approval by the chief security officer;
  • Reviewing requests for proposals and other contracting documentation, including security requirements checklists, that affect their assigned zone(s);
  • Working with program and service delivery managers to ensure their IT security needs are met;
  • Providing advice on zone security controls and the implementation of these controls; and
  • Advising program and service delivery managers of the potential impact to the security posture due to changes to the network.

Detailed network security zone authority tasks, responsibilities, and roles are identified in Annexes A to F of this document.

A network security zone authority’s control comes from direct ownership of the network or binding relationships with service providers (e.g. contracts, memorandums of understanding) with defined service levels that ensure the zone’s baseline security requirements are met. Each zone should have its own network security zone authority. A single network security zone authority may be responsible for multiple zones.

3 High-level Security zone models

3.1 Overview

This section outlines a zone implementation model (see Figure 5 in subsection 3.2.2) to help you apply network security zones in your department or organization. You can apply the guidance in this section in either single or multi-tenant environments. In multi-tenant environments, you should consider additional design and security requirements to meet individual confidentiality, integrity, and availability requirements; these additional design and security requirements are not within the scope of this document.

3.2 Zone implementation model

3.2.1 Principles of network security zones

Zoning is a logical design approach used to control and restrict access and data communication flows to certain components and users. Zones establish the network perimeters and their associated boundary defence requirements through the following functions:

  • Defining the entities that populate zones;
  • Identifying discrete entry and exit points;
  • Filtering network traffic at entry and exit points;
  • Monitoring the state of the network;
  • Authenticating the identity of network entities; and
  • Monitoring network traffic at the entry and exit points.

A zone has an assigned network security zone authority. The network security zone authority is an entity that is accountable for developing, implementing, and maintaining the zone security requirements and practices. The zone security requirements and practices complement common network infrastructures in electronic service delivery, interconnectivity, and interoperability.

You can use zones to implement a network infrastructure that reduces security risks related to business processes and information. The zones are separated by ZIPs, which are implemented through security and network devices. Zones can be used to create a defence in depth architecture. In this architecture approach, layers of protection are added to a network so that sensitive data (whether being stored or processed) can be accessed only by a small group of users and applications.

Using a defence in depth architecture, the functions performed on selected data are organized into zones based on the users’ needs, the data sensitivity, and the expected threat environment. Different zones deliver different levels of security to the business processes within each zone. A new zone is needed when new policy requirements are established. For example, Internet accessible zones, which focus on user access to the Internet, require a greater number of controls because these zones have more users and a variety of data types and applications. As you progress through each connected zone, there is a decrease in the variety of applications, the users who can use the applications, and the functions that can be performed. Because there is a decrease in the variety of applications and data, the number of controls will appear to decrease as well. However, the assurance levels of the implemented controls will rise as the data sensitivity rises.

Zones in which all components are entirely within the control of your department are considered to be controlled zones. If your department does not control all zone components, the zone is considered to be uncontrolled. You should evaluate uncontrolled zones as part of your departmental or organizational risk management process.

3.2.1.1 Network Security and Information Security

Network security consists of the measures taken to reduce a network’s vulnerability to threats. Information security consists of the measures taken to reduce the vulnerability of information in its various forms (e.g. paper, electronic) and states (e.g. at rest, in transit).

While network security and information security address different issues, there is some overlap. For example, both network security and information security address the protection of electronic information transmitted across computer networks. With this overlap in mind, some security controls provide both types of security.

3.2.1.2 Information Security and Cryptography

We recommend using cryptography in a low threat environment; however, we do not include broad requirements for cryptography in this document. You should conduct a threat and risk assessment (TRA) to determine if your IT environment needs information security measures, such as cryptography.

Cryptography is an effective information security control. Cryptography protects confidentiality and integrity and supports other security services, such as non repudiation (i.e. preventing an information sender from successfully claiming to not have sent the information in question). Cryptography is also an effective network security control because it prevents certain network based attacks (e.g. eavesdropping and replaying messages). The benefits delivered by cryptography will vary, depending on the layer of the network stack in which it is implemented. Some cryptographic solutions, such as public key infrastructure (PKI) services, are implemented at the application layer.

Other cryptographic solutions (e.g. Type 1 encryption) are mandated because of information security considerations rather than network security considerations. These types of solutions protect the information, not the network. Because network security focuses on the transport layer and below, some cryptographic solutions are out of the scope of network security.

For more guidance on cryptographic solutions, contact our Contact Centre (see subsection 5.1 for contact information).

3.2.1.3 Network Implementation Options

You can physically or logically implement the separation and the security functions of a ZIP or a zone. You can also use a mix of physical and logical implementation methods. You should use the results of the ISSIP to decide whether to use physical or logical separation for zone boundaries. Using the ISSIP, security engineering artefacts (e.g. applicable domain security control profile, threat assessment, and information system security categorization) are developed to help determine security requirements. These security requirements specify the assurance level required by the physical and virtual network security mechanisms.

Physical Separation

Physical separation is recommended for all boundaries around the demilitarized zone (DMZ), which is the zone within the PAZ and around the MZs.

In the context of zones and ZIPs, physical separation is demonstrated in the following two situations:

  • A device is connected to another device through only a physical (wired or wireless) communication medium; and
  • A device is not connected to other systems.

The mechanisms within a device may perform multiple security operations or have multiple security appliances and functions on the same connected platform. Figure 3 depicts the physical separation model.

Figure 3: Physical Separation Model

Figure 3: Physical Separation Model

Long description immediatly follow
Long description

Image depicts one physical security appliance (e.g. firewall, IDS) installed on one separate physical hardware component.

Logical Separation

Virtualization can be used for logical separation within a boundary or a zone perimeter. Virtualization is a technology that allows one physical device (e.g. machines, networks, security devices, and other physical components) to behave as if it were two or more devices, virtualizing and consolidating these devices onto a single physical system. Network virtualization combines hardware and software network resources and functionality into a single software based administrative entity. Figure 4 depicts the logical separation model.

Logically implemented security mechanisms may not have the same assurance levels as comparable physical systems. The vulnerabilities of the host operating system and hypervisors must also be considered when choosing logically implemented security mechanisms.

Figure 4: Logical Separation Model

Long description immediatly follow
Long description

Image depicts three logical security appliances (e.g. firewall, IDS) installed on one common physical hardware component.

3.2.2 Implementation model

The network security zone implementation model is illustrated in Figure 5. Departments or organizations may implement multiple instances of each zone type based on their business requirements. Every zone contains one (or more) separate, routable network within its perimeter. Every separate, routable network should be entirely within a single zone. In certain circumstances, a single end system may participate in more than one zone through separate interfaces. See subsection 4.2.1 for an explanation of the end system.

This document provides a set of baseline security requirements for the following network security zones: PAZ, OZ, RZ, HRZ, MZ, and ZIPs. Other baseline security requirements may be added as needed. A network security zone authority may modify these requirements and practices to strengthen the baseline, meet particular business issues, or address a particular threat environment. However, some requirements will need to be standardized to ensure network interoperability.

A zone does not necessarily correspond to an organization’s branches or business and IT functions. Your organization could implement many zones like how it implements many physical security zones. Zones may also be shared between branches or business and IT functions.

Figure 5: Network Security Zone Implementation Model

Long description immediatly follow
Long description

Figure 5 is a diagram depicting external zones such as Public Zone (PZ) and Restricted Extranet Zone (REZ) connecting to an organization's network via Public Access Zone (PAZ) and Operational Zone (OZ), respectively. A Zone Interface Point (ZIP) separates the zones from each other.

The REZ is for authenticated end systems only from a trusted partner.

The PAZ is for internal services and applications such as service delivery applications, employee simple web access, email servers, public-facing web servers, extranet services, remote access services and application proxies.

The OZ is for the common office environment including application servers, file and print servers. It has no direct incoming traffic from the Internet.

The Restricted Zone (RZ) is for organizational servers, domain controllers, critical corporate applications, certificate authorities, corporate databases and segregated network (Vlan, subnet)

The diagram shows REZ connecting to the OZ but could potentially be connected directly to the RZ. For extremely limited traffic there is a connection from RZ to a Highly Restricted Zone (HRZ).

The external PZ connects to the PAZ and then to the OZ.

Each of the organization's internal zones, PAZ, OZ, RZ and HRZ are connected to the Management Zone (MZ).

4. Network security zone reference models

4.1 Overview

This section includes two reference models:

  • General reference model; and
  • Functional reference model.

The general reference model establishes the technical concepts and terminology needed to support the requirements specified in annexes A to F of this document. The general reference model describes the components within a single, generic zone. The detailed reference models and the zones’ required safeguards and capabilities are included in annexes A to E.

The functional model identifies five main security functions that the zones perform. These five functions are the basis for structuring the detailed zone requirements, which are detailed in annexes A to E.

4.2 General reference model

A generic zone has three component types:

  • End system;
  • Internetwork; and
  • Internal boundary system (IBS).

The internetwork component is divided into an internetwork access sub system, an internetwork core, and an edge interface.

Figure 6 below illustrates a logical topology of a generic zone, using the three main components and the ZIPs to other zones. ZIPs, end systems, and IBSs connect to internetworks via edge interfaces (shown as small circles in Figure 6 below). In general, an instance of a zone consists of one or more internetworks with end systems and IBSs. If connectivity is required between internetworks, the connections should go through an IBS (the requirement for such interconnection depends on your business needs). ZIPs provide network interfaces to other zones. Figure 6 also shows that an end system may be shared (i.e. connected to internetworks in two different zones). Shared end systems must not allow any traffic to pass between zones.

Figure 6: Network Security Zone Logical Topology

Long description immediatly follow
Long description

Figure 6 is a diagram depicting a generic network security zone which consists of end systems, internetworks and an Internal boundary system (IBS).

An internetwork can be connected to:

  • one or more end systems
  • shared end system
  • another internetwork via an IBS
  • other network security zones via ZIP

Each zone component and sub system is a logical construct that includes specific features and functions. These components do not necessarily correspond to physical devices. For example, a single physical device could incorporate the functionality of multiple zone components, or a single zone component could require multiple physical devices to implement all its features and functions.

4.2.1 End system

A zone end system is a computing platform that connects to an internetwork and either initiates or terminates a communication path. While an end system belongs to the zone, an end system administrator (rather than a network security zone authority) is usually responsible for the security of the end system. Although an end system typically consists of a single host, it may also consist of a network of hosts (e.g. storage area network, load balanced server cluster) connected to the internetwork. The internal networks of these complex end systems are beyond the recommendations of this document.

End systems fall into one of the following four categories listed in Table 1.

Table 1: End System Categories

End System Category Description
Simple host An end system consisting of a single host.
Mobile end system An end system (e.g. laptop) that sometimes connects to the zone and another zone (e.g. PZ).
Wireless end system An end system connecting to the internetwork by way of a wireless internetwork access sub system (an end system that has multiple interfaces with the internetwork is considered a wireless end system if any of these interfaces connect over a wireless internetwork access sub system).
Complex end system An end system consisting of a logical group of hosts and an internal private network between hosts (e.g. storage area network).

If end systems use internal wireless communications, you need to apply additional security measures to limit their exploitation as a backdoor to the zone.

When there is a business requirement to connect an end system to two or more zones simultaneously, this end system will be designated as a shared end system (see Figure 6 above). An example of a shared end system is a logically partitioned storage area network. Shared end systems must be configured and secured so they cannot route traffic between the zones. They can communicate with the zones to which they are connected, but those zones cannot exchange traffic with each other through the shard end system. Shared end systems must also meet the configuration requirements of all the zones to which they are connected. Due to the logical separation of shared end systems, the zone authorities for each zone need to understand and consider this additional risk to each connected zone.

A remote end system is an end system that belongs to a PZ and communicates logically with a GC controlled or an organization controlled zone through or to a PAZ. A remote end system is not considered part of the GC controlled or organization controlled zone. However, when a GC controlled or an organization controlled zone permits remote network access from PZs, the host configuration requirements for the remote end systems must comply with the GC controlled or the organization controlled zone’s security requirements.

4.2.2 Internetwork

Internetworks provide the network services to connect end systems, IBSs, and ZIPs. Internetworks may consist of any combination of local area networks (LANs), metropolitan area networks, or wide area networks. They may run over physical layer media (i.e. copper wire or optical fibre) or wireless links (e.g. wireless LANs, fixed wireless links, satellite uplinks). Internetworks provide a network distribution service (e.g. routing) between edge interfaces within a zone. An internetwork includes the sub systems listed in Table 2.

Table 2: Internetwork Sub Systems

Sub System Description
Internetwork access sub system Provides the physical layer and data link layer services that connect an edge interface to the internetwork core. Implementations of these services include bridges, Ethernet protocol, data link layer switches (including multiplexers), and gateways. The internetwork access sub system may also provide network layer and upper layer services. Virtual private network (VPN) access would be implemented in this sub system. An internetwork may have more than one internetwork access sub system.
Internetwork core Provides the core network services (e.g. backbone routing, address resolution) for the internetwork.
Edge interface The logical boundary between the internetwork and a ZIP, an end system, or an IBS. Examples of physical implementations of an edge interface include a network interface card in an end system, an interface port on a switch, and the connecting between them. An internetwork may have more than one edge interface.

The internetwork access sub system includes those internetwork entities that are always under the full control of the network security zone authority. By contrast, the internetwork core may include entities that are operated for or on behalf of the zone authority, but that are not under its direct control.

A zone will include at least one instance or an internetwork. If a zone includes more than one internetwork, then IBSs provide the required connectivity between the internetworks. A zone may use multiple internetworks to segregate traffic and provide additional defence in depth. Multiple internetworks may also exist within a zone when existing network infrastructures are combined to create a zone.

4.2.3 Internal boundary system

An IBS provides a network interface between internetworks and acts as a buffer, implementing traffic control and network configuration safeguards. An IBS connects to the internetworks through edge interfaces.

An IBS is required in a zone only if the zone has more than one internetwork; those interworks must be connected. Examples of IBSs include protection systems, such as screening routers, firewalls, intrusion prevention systems (IPS), and unified threat management (UTM) products.

An IBS could be a network, but such a network is not a distinct zone.

4.3 Functional reference model

The functional reference model describes how the requirements for zones are structured. The model identifies and defines the different types of requirements. The requirements structure is the basis for annexes A to E of this document.

The functional reference model includes the security requirement components listed in Table 3.

Table 3: Functional Reference Model: Security Requirement Components

Security Requirement Component Description
Network interface requirements The set of security requirements governing the types of interfaces permitted with other zones. Network interface requirements delineate the perimeter of a zone. These requirements address issues such as the permitted interfaces to other zones, the use of common infrastructure, and the sharing of end systems with other zones.
Traffic control requirements The set of security requirements governing the flow of network traffic within a zone and between a zone and other zones. These requirements address issues such as types of traffic, network access control requirements, non-interference rules, quality of service, traffic content rules, and resource consumption constraints.
Network configuration requirements The set of security requirements governing the connection of devices to a zone. These requirements address the management of associations between network entities, data link entities, and physical interfaces and nodes. The management and control of physical transmission media are also included in these requirements.
Host configuration requirements The set of security requirements governing the configuration management of the hardware and software load on each host. These requirements ensure that each host operates within a known security state and does not pose a threat to the other hosts in the network. These requirements do not address which software may be on a host. However, they do address the actions necessary to ensure the software load is in a secure state (e.g. properly patched and configured).
Data protection requirements The set of security requirements governing the assignment and use of security services to provide data protection services.

4.3.1 Network interface requirements

Network interface requirements define constraints on the perimeter of a zone. You can think of network interface requirements as a set of connection rules for a zone. The following requirements are the basis for Annex F of this document. These requirements fall into one of the following categories:

  • Requirements for ZIPs (see section 3.2.1) that define the controls on network layer interfaces with other zones;
  • Requirements for interfaces to underlying communications infrastructure (e.g. interfaces to data communications carriers); or
  • Requirements for end system interfaces that define the types of end systems that may be attached to the zone and the constraints on these interfaces.

Network interface requirements address the following needs:

  • Delineate the zone perimeter to ensure that the scope of the network security zone authority’s accountability is clear; and
  • Limit the types of interfaces supported by a zone to reduce the threat environment to which the zone is exposed.

4.3.2 Traffic control requirements

Traffic control requirements specify safeguards that control the flow of traffic within a zone and between zones. Traffic control requirements also specify network capabilities that should be present to support the implementation of measures for platform, application, and system management. Table 4 includes the traffic control safeguards.

Traffic control requirements also specify the network capabilities needed to support platform, application, and operational security safeguards. For example, an RZ should be able to support Internet protocol security (IPSec) between any two edge interfaces. Any zone should support the attachment of intrusion detection sensors within the zone.

Table 4: Traffic Control Safeguards

Traffic Control Safeguard Description
Access control Controls traffic based on source and destination addresses and types of service. Access controls are used to limit access to sensitive resources, limit the data communication protocols used within the zone, ensure non interference between communities of interest, and localize the impact of security failures.
Entity authentication Validates the authenticity of entities and establishes a security association between them. The primary purpose of entity authentication is to support access controls.
Data origin authentication Validates the authenticity of entities participating in a security association throughout the life of the security association. Within traffic control, data origin authentication is primarily used to support access controls.
Data integrity verification Verifies that network traffic has not been modified or replayed. It protects assets attached to the zone by ensuring that content from a source arrives at its destination without modification.
Traffic filters Filter or block traffic based on properties of the data communications stream, including traffic control protocol (TCP) state, source and destination, conformance with authorized communications protocols, data types embedded within the data communications stream, and contents of the data communications stream. For example, filters can block traffic to or from prohibited Internet protocol (IP) or media access control (MAC) addresses or TCP ports. Filters can block prohibited protocols (e.g. firewall products) and stop malicious traffic that contains exploits or potential exploits (e.g. IPS products). They may also be used to filter traffic containing malware (e.g. anti-malware products) or dangerous or illicit content (e.g. web and email filtering products).
Intrusion detection and audit support Provide the services and attributes that support the implementation of security functions, such as intrusion detection, audit, and incident responseFootnote 5. This support may include traffic logs or attachment points for traffic monitoring sensors (e.g. a mirror port on a switch).
Address and name resolution security Refers to a collection of safeguards to protect the integrity of the association between resources and their identifiers.
Resource encapsulation Refers to the mechanisms that allow the zone to hide its internal structure. These mechanisms include network and port address translation and service mapping. Resource encapsulation supports access control and survivability.

4.3.3 Network configuration requirements

Network configuration requirements specify the safeguards and the capabilities necessary to control the attachment and the removal of devices, such as end systems and networking equipment, from a zone. A zone offering a very high level of network security should implement mechanisms to authenticate all network and end system interfaces before permitting the interface to participate in communications. A zone with a minimal level of security should implement safeguards to deter the attachment of unauthorized devices.

Network configuration safeguards include the following:

  • Administrative controls (e.g. configuration identification, change control, configuration status reporting, and configuration audit);
  • Physical security;
  • Authentication; and
  • Event logging.

To attack a network, a threat actor needs access to the network interface. A threat actor can access a network interface by attaching an unauthorized device to the network, exploiting an established host, or using an external interface. Network configuration controls either limit an attacker’s ability to attach an unauthorized device to the network and to do so without detection.

4.3.4 Host configuration requirements

Host configuration requirements govern the configuration of the hosts that are attached directly and indirectly to a zone. Host configuration requirements do not specify measures to protect assets managed by the host. Rather, host configuration requirements specify the minimum requirements to ensure that hosts attached to the zone do not compromise the security of the network or the end systems.

Host configuration requirements include the following safeguards:

  • Administrative controls (e.g. configuration management, vulnerability management, and security audit);
  • Access controls (including entity authentication);
  • Platform security measures; and
  • Event logging.

4.3.5 Data protection requirements

Within the context of this document, data protection requirements specify the safeguards and capabilities needed to protect the confidentiality, integrity, and availability of data during its transmission within and between zones.

5 Summary

This document outlines the security objectives, along with the inherent configuration and management issues, related to applying a network security zone architecture to departmental or organizational networks.

The functional reference model included in this document describes how the requirements for the zones are structured and identifies and defines the different types of requirements. This reference model is the basis for a defence in depth architecture approach, which, when implemented rigorously, provide secures data and processes against cyber threats.

Your organization can use the guidance in this document to implement a network security zoning model that offers a structured approach, which you can tailor to meet your security needs.

5.1 Contact information

Contact us for more information on network security zones:

Contact Centre
cyber.gc.ca
contact@cyber.gc.ca
Local: 613-949-7048
Toll-Free: 1-833-CYBER-88

6 Support content

6.1 List of abbreviations

Term Definition
CMVP Cryptographic Module Validation Program
COMSEC Communications Security
CSE Communications Security Establishment
CSO Chief security officer
DDoS Distributed denial of service
Dept. Department (appears only in figures)
DMZ Demilitarized zone
DNS Domain name service
DoS Denial of service
DSA Director service agent
EAN External access network
FIPS Federal Information Processing Standard
FTP File Transfer Protocol
GC Government of Canada
HRZ Highly restricted zone
HTTP Hypertext transfer protocol
HTTPS Hypertext transfer protocol secure
IAN Internet area network
IBS Internal boundary system
ICMP Internet control message protocol
IDS Intrusion detection system (appears only in figures)
IP Internet protocol
IPS Intrusion prevention system
IPSec Internet protocol security
ISO International Organization for Standardization
ISSIP Information system security implementation process
IT Information technology
ITS Information technology security
KVM Key video mouse
LAN Local area network
MAC Media access control
MITS Management of information technology security
MZ Management zone
NTP Network time protocol
OSI Open systems interconnection (model)
OZ Operations zone
PAZ Public access zone
PKI Public key infrastructure
PoP Point of presence
PZ Public zone
RCMP Royal Canadian Mounted Police
REZ Restricted extranet zone
RMAZ Restricted management access zone
RZ Restricted zone
SA&A Security assessment and authorization
SNMP Simple network management protocol
SSL Secure sockets layer
SVPN Secure virtual private network
TBS Treasury Board of Canada Secretariat
TCP Transmission control protocol
TLS Transport layer security
TRA Threat risk assessment
URL Uniform resource locator
UTM Unified threat management
VA Vulnerability assessment
VLAN Virtual local area network (appears only in figures)
VPN Virtual private network
ZIP Zone interface point

6.2 Glossary

Some of the definitions used in this glossary have been adopted from recognized sources, which are referenced.

Term Definition
Authentication The process of verifying an identity claimed by or for a system entity [14].
Authorization Access privileges granted to a user, program, or process [15].
Baseline security requirements Minimum security functionality required to meet the requirements of the TBS Policy on Government Security [2] and its associated operational standards and technical documentation.
Boundary A portion of the perimeter of a zone or network that is the point of connection between two zones or networks.
Demilitarized zone (DMZ) A part of the network that is located between any two policy-enforcing components of the network (typically between the Internet and internal networks) and that enables an organization to host its own Internet services without risking unauthorized access to its private network.
Denial-of-service (DoS) attack The prevention of authorized access to a system resource or the delaying of system operations and functions [14].
Distributed denial-of-service (DDoS) Attack An attack in which multiple systems, usually compromised, are used to target a single system, causing a denial of service. Victims of a DDoS attack consist of both the end targeted system and any systems maliciously used in the distributed attack [7].
Edge interface A network-layer service interface point through which an end system, IBS, or ZIP attaches to a zone internetwork.
Electronic service delivery The provision of GC information and transaction services online to citizens, businesses, other governments, non-governmental organizations, and employees.
Encapsulation The ability to provide users with a well-defined interface to a set of functions in a way that hides their internal workings.
End system A system that, for an instance of communication, is the ultimate source or destination of the communication.
End-to-end encryption Confidentiality service provided by encrypting data within, or at the source of, an end system with corresponding decryption occurring only within or at the destination end system [9].
Entity An active element of a system (e.g. an automated process, a sub system, a person, or a group of persons) that incorporates a specific set of capabilities [14].
Extranet A constrained extension of a private GC network used to share information and resources for specific business needs with specific partners, including other governments (international or domestic), industry, and non-governmental organizations.
Firewall A gateway that enforces a boundary between two networks and that is used to isolate, filter, and protect local system resources from external connectivity by controlling the amount and the kinds of traffic that may pass between the two.
Gateway An intermediate system that is the interface between two computer networks [14].
Guard A gateway that is interposed between two networks (or computers, or other information systems) operating at different security levels (one level is usually higher than the other) and is trusted to mediate all information transfers between the two levels, either to ensure that no sensitive information from the first (higher) level is disclosed to the second (lower) level, or to protect the integrity of data on the first (higher) level [14].
Host A computer that is attached to a communication subnetwork or internetwork and that can use network services to exchange data with other attached systems [14].
Interface A boundary across which two systems communicate. An interface might be a hardware connector used to link to other devices, or it might be a convention used to allow communication between two software systems. Often, there is some intermediate component between the two systems that connects their interfaces together.
Internal boundary system A gateway that connects two or more internetworks within a network security zone.
Internet The single, interconnected, worldwide system of commercial, governmental, educational, and other computer networks that share the set of protocols specified by the Internet Architecture Board and the name and address spaces managed by the Internet Corporation for Assigned Names and Numbers. (Definition adapted from [14]).
Internetwork Any combination of local, metropolitan, or wide area networks providing some or all network services to a network security zone.
Intrusion detection A security service that monitors and analyzes network or system events for the purpose of finding and providing real time, or near real time, warning of attempts to access network or system resources in an unauthorized manner. (Definition adapted from [14]).
Least Privilege Principle requiring that each subject be granted the most restrictive set of privileges needed for the performance of authorized tasks. Application of this principle limits the damage that can result from accidental, erroneous, or unauthorized use of an information system [15].
Malware Short for malicious software. Software (e.g. logic bomb, trojan, virus, worm) that is intentionally included or inserted in a system for a harmful purpose. (Definition adapted from [14]).
Mobile code Software modules obtained from remote systems, transferred across a network, and then downloaded and executed on local systems without explicit installation or execution by the recipient [14].
Need to know Access to (including knowledge of) sensitive information, which is restricted to those whose duties require such access.
Network security zone authority The person(s) responsible and accountable for the security of the network security zone.
Node An addressable device attached to a computer network. If the node is a computer, it is more often called a host. The term node includes devices, such as routers and printers, that would normally not be called hosts.
Peer entity authentication The corroboration that a peer entity in an association is the one claimed [14].
Platform Specific computer hardware, as in the term, platform independent. It may also refer to a specific combination of hardware and operating system or compiler (e.g. this program has been ported to several platforms). It is also used to refer to support software for an activity (e.g. this program provides a platform for research into routing protocols).
Perimeter An imaginary connecting line around a set of network components that defines the components contained in the zone.
Point of presence An artificial demarcation point or interface point between communications entities [5].
Protocol A set of rules (i.e. formats and procedures) to implement and control some type of association (e.g. communication) between systems. A series of ordered steps involving computing and communication that are performed by two or more system entities to achieve a joint objective [14].
Proxy service An application service internetworking function, which may be incorporated in a firewall, and which provides, to the client, replication of services available on other servers. To the client, the proxy appears to be the server, and to the server, it appears to be the client (when incorporated in a firewall, a proxy service is often referred to as an application gateway firewall.)
Restricted extranet A highly constrained extension of a private GC network, used to share information and resources with highly trusted, non-GC partners. The restricted extranet may terminate in any GC controlled zone (unlike the generic extranet, which must terminate in the PAZ). Management and control of the interface should be mutually agreed upon by the two trusted parties involved.
Secure virtual private network (SVPN): A virtual private network (VPN) that uses cryptography (e.g. Internet protocol security [IPSec]) rather than a VPN based on logical isolation (e.g. multi-protocol label switching or Ethernet virtual local area networking).
Security audit An independent review and examination of the system records and activities to test for adequacy of system controls, ensure compliance with established policy and operational procedures, detect breaches in security, and recommend any indicated changes in control, policy and procedures [9].
Security domain An environment or context that is defined by a security policy, security model, or security architecture to include a set of system resources and a set of system entities that have the right to access the resources [14].
Security perimeter The boundary of the domain in which a security policy or security architecture applies (i.e. the boundary of the space in which security services protect system resources) [14].
Sensitive (information) Information is sensitive if disclosure, alteration, destruction, or loss of the information would adversely affect the interests or business of its owner(s) or user(s) [14].
Separation of duties A security principle requiring that the responsibilities for an activity of a sensitive or critical nature be distributed among multiple entities (e.g. staff, processes) to prevent a breach of security by a lone entity with control over the entire activity.
Shared end system An end system that is connected to two or more network security zones, does not route traffic between the zones, and meets the configuration requirements of all the zones in which it participates.
Strong authentication An authentication process that uses cryptography (particularly public key certificates) to verify the identity claimed for an entity [14].
Stateful inspection Packets are intercepted at the network layer for best performance (as in packet filters), but then data derived from all communication layers is accessed and analyzed for improved security (compared to layers 4-7 in application layer gateways). Stateful inspection introduces a higher level of security by incorporating communication- and application derived state and context information, which is stored and updated dynamically. This provides cumulative data against which subsequent communication attempts can be evaluated.
Subnet Short for subnetwork. A portion of a network, which may be a physically independent network segment, that shares a network address with other portions of the network and is distinguished by a subnet number. A subnet is to a network what a network is to an internetwork.
Threat Any potential event or act that could cause one or more of the following to occur: unauthorized disclosure, destruction, removal, modification, or interruption of sensitive or critical information, assets, or services. A threat can be natural, deliberate, or accidental [4].
Two factor authentication A form of user authentication that requires two different ways (factors) of verifying a claimed identity. The three most commonly recognized factors are: (1) something you know (e.g. a password), (2) something you have (e.g. a physical authentication token), and (3) something you are (e.g. a biometric). Note that two factor authentication can be applied only to users; it cannot be applied to devices or peer entities.
Unified threat management A network firewall that has many features in one product, including email filtering, anti malware capability, intrusion detection or prevention, and World Wide Web content filtering, along with the traditional activities of a firewall. (Definition adapted from [6]).
Virtual private network (VPN)

A restricted use, logical (i.e. artificial or simulated) computer network that is constructed from the system resources of a relatively public, physical (i.e. real) network (e.g. the Internet), often by using encryption (located at hosts or gateways), and tunnelling links of the virtual network across the real network [14].

In general terms, a VPN often refers to a network that emulates a private network, although it runs over public network lines and infrastructure.

Vulnerability A weakness or gap in protection efforts of a network, a system, or an IT asset [4].
Zone interface point An interface between two network security zones through which traffic may be routed.

6.3 References

Number Reference
[1] Treasury Board of Canada Secretariat. Policy on Service and Digital. 1 April 2020.
[2] Treasury Board of Canada Secretariat. Policy on Government Security. 1 April 2012.
[3] Treasury Board of Canada Secretariat. Directive on Security Management. 1 July 2019.
[4] Canadian Centre for Cyber Security. ITSG-33 IT Security Risk Management: A Lifecycle Approach. 30 June 2015.
[5] Canadian Centre for Cyber Security. TRA-1 Harmonized Threat and Risk Assessment Methodology. 23 October 2007.
[6] Wikipedia. “Unified threat management”.
[7] Webopedia. IT Business Edge. “DDoS attack – Distributed Denial of Service”. 2015.
[8] Department of Defense (U.S.). Department of Defense Instruction 8500.01: Cybersecurity. 14 March 2014.
[9] International Organization for Standardization. ISO 7498-2:1989 Information Processing Systems – Open Systems Interconnection – Basic Reference Model – Part 2: Security Architecture. February 1989.
[10] SHIREY, Robert W. The Internet Society. “Request for Comments: 4949 – Internet Security Glossary, Version 2”. Aug 2007.
[11] Committee on National Security Systems. National Counterintelligence and Security Center. National Information Assurance (IA) Glossary, CNSS Instruction No. 4009. 26 April 2010.
[12] Canadian Centre for Cyber Security. ITSG-31 User Authentication Guidance for IT Security.
[13] Rekhter, Y., Moskowitz, B., Karrenberg, D. et al. The Internet Society. “Request for Comments: 1918 – Address Allocation for Private Internets”. February 1996.
[14] Royal Canadian Mounted Police. G1-026 Guide to the Application of Physical Security Zones. September 2005.
[15] Treasury Board of Canada Secretariat. Guidelines on the Management of Public Key Infrastructure in the Government of Canada. January 2011.
[16] Treasury Board of Canada Secretariat. Operational Security Standard on Physical Security. 18 February 2013.

Lists of annexes

Annex A - Baseline Security Requirements for a Public Access Zone

Foreword

ITSP.80.022 Baseline Security Requirements for Network Security Zones V2 – Annex A – Public Access Zone is an UNCLASSIFIED publication.

This version of ITSP.80.022 V2 – Annex A supersedes previous versions.

EFFECTIVE DATE

This publication takes effect on January 12, 2021.

REVISION HISTORY

Revision Amendments Date
1 Version 2 released. January 12, 2021.

1 Introduction

This annex lists the baseline security requirements for a public access zone (PAZ). A PAZ mediates access between organizational internal networks and a public zone (PZ). As a tightly controlled domain, a PAZ protects internal networks and applications from hostile PZ environments (e.g. the Internet). A PAZ also acts as a screen that hides internal resources from a PZ and limits the exposure of internal resources. Interfaces to all external services are implemented through a PAZ.

A PAZ can provide services such as proxy services, email and other message gateways and proxies, service delivery applications, remote access, extranet access, and common support services.

Sensitive information may transit or be collected in a PAZ, but it should not be stored in a PAZ. To limit the amount of sensitive information that could be exposed if a compromise occurred, all sensitive information should be transferred to databases in an operations zone (OZ), or an restricted zone (RZ) via the OZ, and accessed through applications in a PAZ.

A PAZ’s target security state mitigates against Td4 threat actorsFootnote 6. You should assume that Td5Footnote 7 threat actors would be able to defeat the network based security controls within a PAZ. If a Td5 threat actor is of concern to portions or all the data, you should consider implementing a highly restricted zone (HRZ).

A.2 PAZ Reference Model

This section describes a reference model for a PAZ that is based on the general network security zone reference model. A PAZ consists of the components listed in Table 5.

Table 5: PAZ Components

Component Description
End systems The end systems typically connect to the internetwork component (see subsection A.2.1) and provide a buffer between a PZ and organizational internal zones. Network traffic originating from a PZ is processed by end systems attached to the internetwork (e.g. demilitarized zone [DMZ]) before it is forwarded to the OZ zone interface point (ZIP).
Internetworks The number of internetworks depends on the types of services supported and the level of separation required between the services in the PAZ. For example, one internetwork could address the Internet service model (public facing application services), while the second internetwork addresses the organization’s network enterprise services. Providing separation between these services improves service resiliency. A DMZ is a specialized internetwork.
Internal boundary systems (IBS) The IBS separates internetworks, but it also separates services, as depicted in Figure 7 below.

A PAZ may have more than one of each of the components listed above. In addition, a PAZ may support an organization, in part or in its entirety, or multiple organizations.

Note: In the context of the GC, a PAZ may support a GC enterprise, a department, or an agency.

Figure 7 illustrates the logical topology for a PAZ. A PZ (e.g. Internet or other external networks) is connected to a PAZ through a PZ PAZ ZIP. Internal zones are accessed through a PAZ OZ ZIP that connects the internal OZs.

Figure 7: PAZ Logical Topology

Long description immediatly follow
Long description

Figure 7 illustrates the logical topology for a PAZ. A PZ (e.g. Internet or other external networks) is connected to a PAZ through a PZ-PAZ ZIP. Internal zones are accessed through a PAZ-OZ ZIP that connects the internal OZs.

A.2.1 End Systems and Hosts

PAZ end systems and hosts attach to the internetworks (see subsection A.2.4). They host application resources, which are connected to a PZ (e.g. Internet systems). You should not store critical data on an end system or host in a PAZ. Instead, use proxies in a PAZ to mediate access control between the PZ hosts and the services located in the other zones that are authorized for external accessibility. To mediate access controls, the hosts that are used in a PAZ terminate TCP/IP sessions initiated from the PZ hosts and initiate new TCP/IP sessions to the services within other zones.

The PAZ may support the generic services listed in Table 6. These generic services each have specific security objectives and requirements.

Table 6: Generic Services Supported by a PAZ

Generic Service Description
Email services Email services are accessed by external users through remote access services.
Web services
(employee web access)
Web services provide employees with access to public Internet sites.
Common support services Common support services provide the services required to run a secure network (e.g. external domain name service [DNS], directory service agent [DSA], network time protocol [NTP]).
Employee remote and mobile access Employee remote and mobile access, which includes mobile and wireless remote access and a secure virtual private network (SVPN), gives employees access to business resources.
Extranet services Extranet services provide a secure method of interfacing with partner organizations that are external to your organization.
Service delivery applications Service delivery applications provide a web based interface for the public to access your organization’s services and departments.

An individual PAZ does not need to implement all generic services. An individual PAZ will likely implement only a small subset of these services. For example, employee access services (e.g. outgoing proxies, voice over Internet protocol [VoIP]-to-public switched telephone network [PSTN], and remote access) are a valid grouping. Online service delivery to the public is another valid grouping of services. Therefore, the size and the complexity of the PAZ will vary considerably, depending on the organization’s business requirements.

Common support services provide infrastructure functions that are necessary for the network’s operation. These services may be a public service (e.g. public key infrastructure [PKI] user interface, privilege management infrastructure user interface), a private service (e.g. intrusion detection, network time), or a border service (e.g. DNS, DSA).

An extranet provides a constrained extension of a private organizational network to share information and resources (for specific business needs) with specific partners. An extranet should terminate in a PAZ. It should also be governed by standardized agreements with limited organizational control over its external configuration. Note that this general extranet differs from the restricted extranet zone (REZ) described in Section 2.1.6. A restricted extranet with highly trusted partners may terminate on an organization controlled OZ ZIP and should be governed by an agreement that is specific to the instance of the extranet and that has controls that are mutually agreed upon.

Figure 8 depicts a potential DMZ with traffic routed through these services.

Figure 8: Examples of a DMZ

Long description immediatly follow
Long description

Figure 8 depicts a potential DMZ with traffic routed through the following services: email proxy services, common support services, reverse proxy services, extranet, and service delivery application.

A.3 PAZ Security Objectives

In general, a PAZ provides a security service to other organization controlled zones, protecting them from threats that originate in the PZ.

Each objective and requirement specified in this annex is labelled according to the following notation:

  • The first set of letters refers to the zone (e.g. PAZ).
  • The second set of letters designates either an objective (OBJ) or a requirement (REQ).
  • Requirements are grouped into the following categories, as applicable:
    • Network interface (NI);
    • Traffic control (TC);
    • Network configuration (NC);
    • Host configuration (HC); and
    • Data protection (DP).
  • Each objective or requirement is sequentially numbered within its group.
    Note: Objectives and requirements are not sequential; some requirements have been removed or changed from the previous versions of this document.

A.3.1 Traffic Control Objectives

[PAZ-OBJ-100] A PAZ should mediate the flow of all traffic types between internal networks and a PZ.

[PAZ-OBJ-101] All traffic types to and from a PZ should be controlled through PZ ZIPs.

[PAZ-OBJ-103] A PAZ should protect itself against unauthorized changes to the network configuration.

[PAZ-OBJ-104] A PAZ should provide the first line of protection against malicious traffic and mobile code.

[PAZ-OBJ-105] A PAZ should reduce authorized users’ illegal or illicit use of Internet resources.

Note: Network security measures are limited in their ability to protect end systems from compromises through valid application interfaces. You should use platform, application, and operational security measures to address the risks associated with this type of threat.

[PAZ-OBJ-107] A PAZ should permit enhancements to security measures as a response to increased threat levels (e.g. during a time of crisis). These measures include the following:

  • Flexible, dynamic traffic controls based on the community of interest; and
  • Increased surveillance of outsourced network infrastructure by network service providers.

A.3.2 Network Availability and Integrity Objectives

[PAZ-OBJ-108] A PAZ should protect the integrity and the availability of end systems attached to the zone. A PAZ should perform the following functions:

  • Reduce the impact of network-based DoS attacks on end systems from all threat sources;
  • Prevent threat actors categorized up to the Td4 level from carrying out network intrusions (e.g. attaching an unauthorized device to an existing interface, adding an unauthorized edge interface) to access end systems;
  • Reduce the impact of network intrusions carried out by all other threat sources;
  • Contain the impact of a compromised end system;
  • Prevent threat actors categorized up to the Td4 level from exploiting end systems as staging points for attacks on other systems;
  • Reduce the ability for all other threat sources to exploit end systems as staging points for attacks on other systems;
  • Prevent the spread of malicious traffic from other zones to a PAZ; and
  • Stop the spread of malware.

A.3.3 Data Protection Objectives

[PAZ-OBJ-109] A PAZ should reduce the zone traffic’s vulnerability to interception by threat actors categorized up to the Td4 level. It should also be able to prevent the undetected interception of zone traffic by all other threat sources.

[PAZ-OBJ-110] A PAZ should support measures to protect the confidentiality and the integrity of data. These measures include the following:

  • SVPN within the internetwork;
  • SVPN as an optional data service; and
  • Upper layer security protocols.

A.3.4 Security Objectives for DMZ Functional Services

Each function provided through a DMZ has a distinct set of security objectives. This section describes the high level security objectives that are achieved by applying security measures to each service.

[PAZ-OBJ-111] The security objectives for email services from a PZ are as follows:

  • Separate internal networks from a PZ through email gateways;
  • Permit incoming and outgoing mail traffic through tightly controlled interfaces;
  • Protect the internal network from malware;
  • Protect external recipients from malicious email traffic originating from your organization; and
  • Protect internal and external networks from spamming and other email attacks.

[PAZ-OBJ-112] The security objectives for forward and reverse proxies used for web services are as follows:

  • Separate internal networks from a PZ through proxy services;
  • Terminate established connections within a DMZ;
  • Protect external networks from malware; and
  • Protect the internal network from malware.

[PAZ-OBJ-113] The security objectives for common support services are as follows:

  • Provide continuous availability of infrastructure services, such as naming and directory services, to support dependency of higher-level services and applications;
  • Ensure integrity of the common support services that are provided to higher-level services and applications;
  • Protect private information used by and transported through common support services; and
  • Ensure authentication of peer services.

[PAZ-OBJ-114] The security objectives for extranet services are as follows:

  • Provide mutual authentication of extranet interfaces;
  • Provide access controls to restrict access to internal organizational resources;
  • Protect against malicious traffic originating from partners;
  • Ensure accountability of extranet partners;
  • Protect partner network from malicious traffic originating from your organization; and
  • Protect data exchanged with extranet users during transmission.

[PAZ-OBJ-115] The security objectives for employee remote and mobile access are as follows:

  • Provide strong authentication of remote and mobile users;
  • Permit access to internal organizational zones for authorized users; and
  • Secure all remote and mobile access traffic with an SVPN.

[PAZ-OBJ-116] The security objectives for service delivery applications are as follows:

  • Provide entity authentication of peer services and individuals as needed;
  • Provide confidentiality and privacy appropriate for the sensitivity of delivered information and services;
  • Protect against malicious traffic originating from service delivery peers and users;
  • Protect information repositories by separating them from public facing service delivery applications;
  • Provide availability of infrastructure services according to availability agreements (e.g. high availability);
  • Protect service delivery peers and users against malicious traffic originating from your organization; and
  • Support service delivery accountability.

Note: Security services that are specific to service delivery applications (e.g. access control and non-repudiation services) should be provided by the application specific components deployed in a DMZ.

A.4 Security Requirements

This section describes the baseline security requirements for a PAZ. These requirements are categorized by operational requirement (i.e. network interface, traffic control, network configuration, host configuration, and data protection). Each operational requirement category has the following sub-categories:

  • Common requirements that apply across the entire OZ;
  • Internetwork requirements;
  • IBS requirements; and
  • End system requirements.

To achieve all the security objectives listed in section A.3, you should implement the complete set of baseline security requirements listed in Table 7.

Table 7: PAZ Baseline Security Requirements

Objective Number Requirement Number Zone Requirement Related ITSG 33 Control IBS Internetwork End System
Network Interface
PAZ-OBJ-108 PAZ-NI-100

Except as noted below, PAZ nodes are not connected, either simultaneously or periodically, to any other zone except the management zone (MZ).

PAZ nodes include devices such as, but not limited to, laptops, printers, gateways, switches, multiplexers, routers, and computers.

AC 5
AC 6 (1)
AC 6 (5)
CM 3
X X X
PAZ OBJ 101 PAZ NI 102

To protect a DMZ from interference and tampering by untrusted subjects, a DMZ isolates its internal network from any other network infrastructure.

A DMZ does not share the following infrastructure:

  • Any network layer infrastructure with any other zone or internetwork component;
  • Any data link layer infrastructure with any zone or internetwork component; and
  • Any physical layer infrastructure with any PZ.

Note: A DMZ may share physical layer infrastructure with organization controlled zones.

SC 7 X X -
PAZ-OBJ-101 PAZ-NI-107

PAZ internetworks are separate networks. They maintain traffic interfaces only with the following components:

  • ZIP(s);
  • IBS(s) to other internetwork(s); and
  • PAZ end systems.
AC 4 - X -
PAZ-OBJ-108 PAZ-NI-108 IBSs (if present) and internetwork components support the attachment of network based intrusion detection sensors (e.g. monitors) and the collection of data from these sensors. SI 4 (4) X X -
Traffic Control
PAZ OBJ 108 PAZ TC 100

All network paths destined for or originating from a PZ (e.g. Internet) pass through a PAZ.

The only exception is a REZ, which could connect directly to an OZ or an RZ.

There are no direct connections between a PZ and internal networks located in zones other than the PAZ.

SC 7 X X -
PAZ OBJ 108 PAZ TC 101

A PAZ defines requirements for its access control based on the following principles:

  • Restrict paths to vulnerable end systems in adjacent zones;
  • Limit available network paths for end systems accessible by extranet; and
  • Enforce based on network layer source, network layer destination, transport protocol, and transport layer service interface.
AC 4
SC 7
SC 7 (5)
X X -
PAZ OBJ 108 PAZ TC 103 IBSs implement network layer and upper layer controls to protect DMZ hosts from traffic originating from other zones and to protect other zones if malicious traffic originates from within a DMZ. SC-7 X - -
PAZ OBJ 108 PAZ TC 104

PAZ management traffic (other than traffic related solely to device status) is segregated from operational traffic.

Refer to Annex E for more detail on separating management traffic in zones.

AC 4
SC 37
X X X
PAZ OBJ 107 PAZ TC 106

In case of an emergency and increased threat, a PAZ can respond quickly to heightened security levels, as authorized to do so. For example, a PAZ can improve the network security posture by increasing the level of security measures, such as the following:

  • Filtering at each PAZ interface;
  • Monitoring (active and passive);
  • Protecting the continuous delivery of critical services, including reconfiguring or blocking non essential services if required; and
  • Auditing.

Before implementing these measures, carefully test them to ensure they cannot be exploited in a DoS attack.

Personnel are trained and authorized to initiate such a response.

AC 4
IR 4
SC 7
SI 4
AU 6
X X X
PAZ OBJ 108 PAZ TC 107

A PAZ network security authority defines a PAZ’s required access control policy as follows:

  • The access control policy supports community of interest separation (i.e. where network traffic is divided into natural communities of interest, the access control policy enforces these natural traffic flows);
  • The access control policy restricts available network paths to vulnerable or sensitive end systems (e.g. test and development sub networks and application servers supporting public applications);
  • The access control policy is configured to limit the available network paths for end systems accessible by extranets;
  • The access control policy is constructed to deny all traffic unless it is explicitly permitted;
  • Traffic to and from application servers is restricted to addresses and protocols necessary to support communication with the application servers; and
  • If a PAZ network security zone authority permits connection to a PAZ via remote access hosts with operating systems that do not separate user and administrator roles, the access control policy limits access to other end systems by remote access hosts.
AC-2
AC-3
AC-4
AC-17
SC-7
SC-7 (5) SC-7 (11)
X X X
PAZ OBJ 108 PAZ TC 108 If a PAZ supports more than one class of service, the internetworks implement mechanisms to ensure non interference between classes of service. AC-4 - X -
PAZ OBJ 108 PAZ TC 109 The internetworks use an addressing model that facilitates detection and diagnosis of malicious traffic. CA 3
SC 7
SI 3
- X -

PAZ OBJ 109
PAZ OBJ 110

PAZ TC 110 A PAZ supports IPsec traffic between any pair of edge interfaces. SC-8 X X X
PAZ OBJ 100 PAZ TC 111 All network paths between hosts in a PZ and hosts in an internal zone pass through a ZIP and are subject to mediation by security services located within a PAZ. SC-7 X X -
PAZ OBJ 108 PAZ TC 112 Audit relevant traffic control and data flow information is recorded in the security audit log according to the requirements of the security audit service. AU 1
AU 2
- X X
PAZ OBJ 100 PAZ TC 113 All connections that enter a PAZ from a PZ ZIP or an OZ ZIP terminate in a DMZ. SC-7 - X X
PAZ OBJ 100 PAZ TC 114

Within a DMZ, traffic is segregated to flow only between related nodes.

Segregation within a DMZ limits the impact of a compromised DMZ host. For example, a threat actor should not be able to use a compromised web server to attack other hosts within a DMZ.

SC 7
AC 4
- X X
PAZ OBJ 108 PAZ TC 115 Traffic associated with different service classes is strictly segregated. Any requested communication between the service classes flow through well defined interfaces. SC-7 X X X
PAZ OBJ 100 PAZ TC 116

If a DMZ supports more than one function (as defined in subsection A.2.1) or security domain, it separates the functions and security domains for the following purposes:

  • Prevent interference between security domains;
  • Support specific access policies;
  • Protect sensitive or critical functions on dedicated hosts;
  • Ensure continued delivery of critical services; and
  • Ensure that any compromises of the DMZ end systems are contained within a DMZ.
SC 7
AC 4
X X X
PAZ OBJ 101 PAZ TC 117 Traffic rules do not conflict. Where a potential conflict exists, you may need to physically separate functions or security domains, and the associated IBSs, into dedicated DMZ clusters. SC-7 X X -
PAZ OBJ 112 PAZ TC 119

To provide employee web access, functionality, such as Hypertext Transfer Protocol (HTTP), Hypertext Transfer Protocol Secure (HTTPS), and File Transfer Protocol (FTP), originating from your employees is processed within a PAZ network.

While employees may require web access to perform job functions, the normal limits on available protocols must be used. You may implement additional access controls based on job functions. However, to support common implementation requirements, a PAZ supports the above protocols.

SC-7 X X -
PAZ OBJ 112 PAZ TC 120

All employee web access traffic is processed by a proxy service. Proxy services support the following functions:

  • Content filtering and scanning;
  • Web access management (i.e. Uniform Resource Locator filtering);
  • Quarantine or removal of illicit traffic;
  • Notification; and
  • Logs and audits.
AC 4
SC 7 (8)
AU 2
AU-3
X X -
PAZ OBJ 112 PAZ TC 122 A DMZ supports the detection and the blocking of malware and mobile code. SI-3 X X -
PAZ OBJ 112 PAZ TC 123 A PAZ network security zone authority administers malware detection and content filtering. SI-4 X X -
PAZ OBJ 111 PAZ TC 124 Monitoring and content filtering are consistent with the Policy on Service and Digital [1]. SI-4 X X -
PAZ OBJ 111 PAZ TC 128 All inbound and outbound email traffic is mediated in a DMZ on a proxy server. AC 4
SC 7
X X -
PAZ OBJ 111 PAZ TC 129 All email traffic is mediated and processed by an email gateway that can provide content filtering and protecting against mobile code and malware. Footnote 8 SC 7
SI 3
SI 4
X X -
PAZ OBJ 111 PAZ TC 131 Inbound email traffic is only relayed to a restricted list of peer email servers. AC 4 X X -
PAZ OBJ 111 PAZ TC 132 All inbound and outbound email traffic and attachments are scanned for malware, unless end to end encryption is used. SI 3
SI 15
X X -
PAZ OBJ 111 PAZ TC 134

The PAZ network security zone authority, guided by the Policy on Service and Digital [1], determines the following:

  • A content scanner is used in a PAZ to detect, quarantine, and delete emails that may contain sensitive data, offensive content, or illicit language;
  • Attachments that may, for example, contain audio, video, or executable code are to be blocked;
  • Extra-large emails are stored for delivery at off peak hours; and
  • Spam is blocked.
AC 4
SI 3
SI 4
SI 8
X X -
PAZ OBJ 111 PAZ TC 135

Incoming email traffic (from another zone) with a “From:” address belonging to an entity within the zone is blocked.

-

Outgoing email traffic (to another zone) with a “From:” address that belongs to an entity outside of the zone is blocked.

-

Measures (e.g. digital signature) are taken to ensure the legitimacy of the email source and the destination addresses. These measures will block spoofed email addresses.

-

SI 15 X X -
PAZ OBJ 115 PAZ TC 136 To enable your employees to access internal resources in an OZ or an RZ, remote access is permitted from a PZ through tightly controlled interfaces in a PAZ. SC-7 X X -
PAZ OBJ 115 PAZ TC 137

Remote access is restricted to traffic originating from authorized and authenticated network entities. The following security services are used at the network layer:

  • Peer entity authentication is enforced at the PAZ using strong authentication. This includes support for both host and user mobility; and
  • Data origin authentication.
For further requirements on authentication, refer to ITSG-31 User Authentication Guidance for IT Systems

-

[12].
IA 2 (11)
AC 17
X X X
PAZ OBJ 115 PAZ TC 138 PKI is used to provide strong authentication for peer entity authentication (GC departments use GC PKI). SC 12
IA 2
- - X
PAZ-OBJ-115 PAZ-TC-139 Access controls to another organization zone are enforced based on the authenticated identity of the remote access client. IA-2 X X X
PAZ-OBJ-115 PAZ-TC-140

All mobile access SVPN traffic originating from a PZ should terminate at an SVPN gateway. The SVPN gateway is located within a PAZ. It is recommended that this traffic is decrypted at the SVPN gateway.

Remote and mobile access traffic supports employee access to internal zones. In most cases, this traffic would not need to be encrypted inside the destination zone. As such, it is recommended that this traffic is decrypted at the SVPN gate to apply traffic controls within a PAZ.

In some cases, requirements exist to provide end to end encryption. To do so, use nested tunnels so that authentication can be performed in a PAZ. The next requirement addresses remote and mobile access points to support nested tunnels.

SC-8
SC-13
X X X
PAZ-OBJ-115 PAZ-TC-141 Subject to the above requirements, remote and mobile access points support secure end to end communications using nested tunnels from the client to the destination host within another zone. AC-17 (2) - X X
PAZ-OBJ-115 PAZ-TC-142 Organization sponsored services, such as remote access service servers, are in a PAZ. AC-17 (3) X X X
PAZ-OBJ-116 PAZ-TC-143 All inbound and outbound service delivery traffic terminates in a DMZ. AC-4
SC-7
X X X
PAZ-OBJ-116 PAZ-TC-144 Security associations between service delivery end systems and application components that are installed in a DMZ and back end servers, or databases, are tightly controlled. These security associations are established using strong peer entity authentication. IA-3 - - X
PAZ-OBJ-116 PAZ-TC-145 All service delivery traffic is mediated and processed by application processes in a DMZ. SC-7 X X X
PAZ-OBJ-108 PAZ-TC-146 The DMZ supports the detection and blocking of malware and mobile code. SI-3 X X X
PAZ-OBJ-114 PAZ-TC-147 Extranet traffic is restricted to traffic originating from authorized and authenticated network entities. AC-3
IA-3
SC-7
X X X
PAZ-OBJ-114 PAZ-TC-148 At a minimum, strong peer entity authentication at the network layer is used between an external party’s extranet point of presence (PoP) and a PAZ. IA-3 - - X
PAZ-OBJ-110 PAZ-TC-150 PKI is used to provide strong authentication for peer-entity authentication (GC departments use GC PKI). Please refer to ITSG-31 User Authentication Guidance for IT systems [18] for further details on authentication. SC-12
IA-3
- - X
PAZ-OBJ-114 PAZ-TC-151

Access controls to another organization zone are enforced based on the authenticated identity of the extranet PoP.

Note: The extranet agreement requires the partner to restrict access to authorized hosts within its own network.

AC-3
IA-3
- X X
PAZ-OBJ-114 PAZ-TC-152

All extranet SVPN traffic originating from a PZ terminates at an SVPN gate. The SVPN gate is located within a DMZ (i.e. behind an external access network [EAN] or DMZ boundary system), or the SVPN gate should act as an EAN or a DMZ boundary system.

The SVPN device is in the DMZ to protect an unauthorized connection to an OZ or an RZ.

SC-8
SC-13
X X X
PAZ-OBJ-114 PAZ-TC-153

Subject to the above requirements, the extranet PoP supports secure end to end communications using nested tunnels from the client to the destination host within another organization zone.

Note: The above requirements limit the ability of the PAZ to identify malware and malicious traffic. Organization hosts participating in an extranet need additional intrusion detection and malware detection.

AC-20
CA-3
- - X
PAZ-OBJ-113 PAZ-TC-154 The PAZ naming service instance logically separates internal organization naming information from PZ naming information. SC-22 X X X
PAZ-OBJ-113 PAZ-TC-155 All naming service traffic from a PZ is directed to the border naming service instance located in a PAZ. SC-22 X X X
PAZ-OBJ-113 PAZ-TC-156 Transfer of internal organization naming service configurations to a PZ is permitted. SC-22 X X X
PAZ-OBJ-113 PAZ-TC-157 Transfers of organization naming configurations to the PAZ border naming service instance are only permitted from organization naming service peers. < SC-22 X X X
PAZ-OBJ-113 PAZ-TC-158 Transfers of PZ naming configurations are permitted from the PZ service provider naming service. SC-22 X X X
PAZ-OBJ-113 PAZ-TC-159 A PAZ time service instance logically separates the internal organization time service from a PZ time service. AU-8 X X X
PAZ-OBJ-113 PAZ-TC-160 Transfer of network time protocol (NTP) from a PZ is directed to the time service instance located in a PAZ. AU-8 X X X
PAZ-OBJ-108 PAZ-TC-162 A PAZ network security zone authority is responsible for ensuring that only permitted traffic types (i.e. associated ports and services) are those that are essential to the organization and their activities. SC-7 (5) X X X
PAZ-OBJ-108 PAZ-TC-163

All IP packets originating from a PZ are filtered at a PAZ to ensure that only appropriate packet types and packets with appropriate service access points and source and destination addresses are permitted to enter a PAZ. At a minimum, traffic originating from a PZ is filtered to block the following:

  • Traffic containing directed broadcast addresses;
  • Traffic containing network loop back addresses;
  • Traffic destined to RFC 1918 [13] reserved addresses;
  • Network traffic containing a source or destination address of 0.0.0.0;
  • Traffic with an internal source IP address;
  • Traffic containing IP source routing information;
  • Management traffic (e.g. simple network management protocol [SNMP]);
  • Internet control message protocol (ICMP) broadcasts; and
  • Traffic determined to have malicious intent against a PAZ.

This filtering will protect a PAZ from DoS attacks and spoofing.

SC-7 X X X
PAZ-OBJ-101 PAZ-TC-164 Once filtered, traffic originating from a PZ is routed to the specific DMZ interface based on a specific destination and service. SC-7 X X X
PAZ-OBJ-108 PAZ-TC-165 IP packets destined for a PZ are filtered to prevent any packets with invalid or incorrect addresses from leaving a PAZ. SC-5 X X X
PAZ-OBJ-108 PAZ-TC-166 IP packets destined for a PZ are filtered to block packets containing a private IP address as their source IP address. SC-22 X X X
PAZ-OBJ-101 PAZ-TC-167 Unless specifically required by an application, a PAZ only allows protocols that can be examined with a proxy service. SC-7 X X X
PAZ-OBJ-116 PAZ-TC-168 A PAZ can mediate and examine inbound and outbound packets up through the application layer (i.e. up to layer 7) of the open systems interconnection (OSI) model. SI-4 X X X
PAZ-OBJ-104 PAZ-TC-170 A PAZ can reject all malformed service requests. SI-4 X X X
PAZ-OBJ-108 PAZ-TC-176

IP packets originating from an internal zone are filtered to ensure that only appropriate packet types and packets with appropriate service access points and source and destination addresses are permitted to enter a PAZ. At a minimum, filtering blocks the following:

  • Traffic containing directed broadcast addresses;
  • Traffic containing network loop-back addresses;
  • Traffic destined to RFC 1918 [20] reserved addresses;
  • Network traffic containing a source or destination address of 0.0.0.0;
  • Traffic containing IP source routing information;
  • ICMP broadcasts; and
  • Traffic determined to have malicious intent against the Internet area network (IAN).
SC-7 X X X
PAZ-OBJ-116 PAZ-TC-177

Unless specifically required by an application, a PAZ only allows protocols that can be examined with an application proxy. All outbound traffic (i.e. traffic originating from an RZ or an OZ) is mediated and processed by application proxies.

AC-4 - X -
PAZ-OBJ-101 PAZ-TC-179 Traffic originating from an internal zone is routed to the appropriate DMZ interface based on destination and service. SC-7 - X -
Network Configuration
PAZ-OBJ-103 PAZ-NC-100 A PAZ network configuration is monitored to detect additions, deletions, or changes to edge interfaces. Unauthorized changes are reported to a PAZ network security zone authority. CM-2
CM-3
SI-4
X X X
PAZ-OBJ-103 PAZ-NC-101 All edge interfaces are registered with and approved by a PAZ network security zone authority before they are attached to the zone. CM-8 X X X
PAZ-OBJ-103 PAZ-NC-102 PAZ edge interfaces are registered with a PAZ network security zone authority. CM-8 X X X
PAZ-OBJ-103 PAZ-NC-103 A PAZ network security zone authority periodically verifies the network topology. CM-2
CM-9
X X X
PAZ-OBJ-103 PAZ-NC-104 A PAZ network security zone authority periodically assesses the network configuration for unauthorized external interfaces. SI-4 (4) X X -
PAZ-OBJ-108 PAZ-NC-105 A PAZ implements the following constraints on address space for interfaces:
  • Edge interface addresses are distinct and dedicated, but not necessarily private; and
  • DMZ interface addresses are distinct and assigned from a private non routable address space.
SC-7 X X -

PAZ-OBJ-109
PAZ-OBJ-110

PAZ-NC-106

Edge interfaces establish security associations with other edge interfaces, and all communications are authenticated (either explicitly or implicitly) within the context of these security associations. The security associations permitted are determined by traffic control requirements.

The type and strength of authentication are implementation dependent. The goal is to prevent a threat actor from attaching a network layer entity in the core and masquerading as an edge interface.

IA-3
AC-4
- X -
PAZ-OBJ-103 PAZ-NC-109 A service level agreement requires a network service provider to control changes to core interfaces and report to a network security zone authority any changes that affect the security association between edge devices. CM-8 X X -
PAZ-OBJ-108 PAZ-NC-110

A service level agreement requires a network service provider to show evidence that the security controls used to enforce the security within a core network are effective. A service level agreement also requires that all security incidents that could impact a PAZ are reported to a PAZ network security zone authority.

A network service provider must also grant a PAZ network security zone authority the capability to verify the effectiveness of the controls on a quarterly basis, at least.

CA-1
CA-2
X X -
PAZ-OBJ-103 PAZ-NC-111 All interfaces in a DMZ are registered with a PAZ network security zone authority before they are attached to a PAZ. CM-1 - X X
PAZ-OBJ-103 PAZ-NC-112

A change to a DMZ interface address assignment constitutes a configuration change that requires approval.

Approval may be given in advance to permit dynamic reconfiguration; however, you must clearly delineate the conditions under which such a change may be made.

CM-3 - X X
PAZ-OBJ-108 PAZ-NC-113 Only authenticated and authorized administrators can manage PAZ nodes, and only from a PAZ MZ. AC-5
IA-5
- - X
PAZ-OBJ-103 PAZ-NC-114 Edge interface addresses are visible to other organization zones but are not visible to the PZ. SC-7 X X -
PAZ-OBJ-103 PAZ-NC-115 A change to a PAZ edge interface address assignment constitutes a configuration change that requires approval by a PAZ network security zone authority. CM-3
CM-9
- X -
PAZ-OBJ-103 PAZ-NC-116 A PAZ network security zone authority maintains current configuration information for all edge interfaces. CM-2
CM-6
- X -
PAZ-OBJ-103 PAZ-NC-117 A PAZ network security zone authority approves all changes to a PAZ before they are implemented. CM-3 (4)
CM-9
X X X
PAZ-OBJ-110 PAZ-NC-118 Connections within a PAZ have established security associations. All communications are authenticated (either explicitly or implicitly) within the context of these security associations. The permitted security associations are determined by the traffic control requirements. AC-4
IA-3
SC-23
X X -
PAZ-OBJ-110 PAZ-NC-119 Internetwork edge interfaces are authenticated to each other through cryptographic authentication mechanisms. IA-3 (1) - X -
PAZ-OBJ-103 PAZ-NC-120

End systems maintain the integrity of edge interfaces with other organization zones while connected to a PAZ.

Do not permit PAZ end systems to dual home, split tunnel, or share other network paths with a PZ.

SC-7 (7) - - X
Host Control
PAZ-OBJ-108 PAZ-HC-100 All nodes in a PAZ configure features to maximize protection against intrusion, including, but not limited to, the following features:
  • Ensuring that the number of operating system accounts is strictly limited;
  • Ensuring that the security principle of least privilege is strictly applied to each operating system account;
  • Ensuring the most appropriate authentication is used for all accounts, depending on organizational business requirements and risk assessments (refer to ITSG-31 [12] for authentication requirements); and
  • Disabling all unnecessary services (i.e. the software load configuration is the minimum necessary to provide required functions).
Ensuring only authorized administrators are given user accounts for perimeter and boundary nodes (e.g. DMZ access devices, routers, intrusion detection systems), according to the principle of need to know.
- - - -
PAZ-OBJ-103 PAZ-HC-101

A PAZ network security zone authority maintains a host configuration policy that is consistent with applicable baseline security requirements, standards, and guidance.

This policy applies to all hosts attached to a PAZ.

- - - -
PAZ-OBJ-103 PAZ-HC-102 The host is configured with the following policies:
  • Specification of prohibited and mandated software and hardware configurations;
  • Minimum maintenance procedures for all software; and
  • Specific maintenance procedures for software that provides client access to Internet based resources and software that provides back end services to public clients (e.g. mail services).
- - - -
PAZ-OBJ-108 PAZ-HC-105

All nodes are subject to regular vulnerability assessments (VAs). A network security zone authority determines the frequency of the VAs, and the frequency is documented in the zone procedures.

The PAZ VA procedures are appropriate for critical hosts that have a high level of exposure. Results of all VAs are managed in the framework of continuous risk management. These results provide feedback to the threat risk assessment (TRA) process described in ITSG-33 [4].

PAZ nodes are exposed to significant threats from the Internet. With regular VAs, the window of exposure from configuration errors and new exploits is reduced.

The frequency of such VAs sufficiently supports trend analysis.

The results of the VAs are managed within the framework of continuous risk management. These results provide feedback to the security assessment and authorization (SA&A) process.

After configuration changes, individual nodes are subject to VAs.

- - - -
PAZ-OBJ-108 PAZ-HC-109 All hosts use controls that implement continuous protection against malware at start up. SI-3
SI-7
X X X
PAZ-OBJ-108 PAZ-HC-110 All hosts that provide applications to permit client access to public resources (e.g. Internet web browsers and email clients) use operating systems that separate duties and administration. These hosts are configured to operate any applications that provide access to public resources in user mode. AC-5
AC-6
X X X
PAZ-OBJ-103 PAZ-HC-111 A shared end system, whether shared permanently or periodically, complies with the following requirements:
  • An operating system that supports the separation of users and administrators (i.e. enforces the principles of separation of duties and least privilege) is used;
  • Any changes to the network configuration require administrative privileges; and
  • The end system configuration, and the procedures for maintaining that configuration, are approved by a PAZ network security zone authority.
The end system is subject to regular VAs (results to be provided to the TRA process). The network security zone authority determines the frequency of these VAs and documents the frequency in the PAZ VA procedures.
AC-5
AC-6
CM-3
RA-5
- - X
PAZ-OBJ-103 PAZ-HC-114 An end system includes a personal firewall and a configuration integrity mechanism capable of identifying changes to the configuration and notifying the end system administrator of these changes. SC-7 (12)
SI-7
- - X
PAZ-OBJ-108 PAZ-HC-115 Operating systems for all nodes (i.e. for internetwork edge and core devices) are hardened based on documented best practices. CM-6
CM-7
X X -
PAZ-OBJ-109
PAZ-OBJ-110
PAZ-HC-116 VPN products, if used, are validated to Federal Information Processing Standard (FIPS) 140-2 (or subsequent FIPS 140 release) at a minimum of Security Level 2 through the Cryptographic Module Validation Program (CMVP). SC-13 X X X
PAZ-OBJ-108 PAZ-HC-117 Internetwork devices are physically secured to limit access to only authorized personnel who have an ongoing need to access the equipment, according to the principles of least privilege and need to know. PE-2
PE-3 (1)
X X -
PAZ-OBJ-108 PAZ-HC-118 A complex end system undergoes the SA&A process before it is attached to an edge interface. CA-1
CA-6
- - X
PAZ-OBJ-108 PAZ-HC-119 A comprehensive process for managing software updates is implemented to ensure the most up to date, approved patches and application updates are installed for all authorized software that exists on nodes. SI-2 X X X
PAZ-OBJ-108 PAZ-HC-120 An intrusion detection capability is implemented on all critical hosts. SI-4 X X X
PAZ-OBJ-103 PAZ-HC- 121

Each PAZ node is subject to regular configuration audits. The frequency of such audits is determined by a network security zone authority and documented in the PAZ configuration management procedures.

The frequency of these configuration audits sufficiently identifies configuration errors. The configuration audit includes, but is not limited to, the following considerations:

  • Verification of the node configuration against the network topology design;
  • Verification of the hardware devices and the physical interfaces;
  • Verification of the traffic control configuration, including permissions and access controls; and
  • Verification of the permitted software load and functions.
Configuration errors are a significant source of exploitable vulnerabilities. Regular configuration audits limit the window of exposure from configuration errors.
AU-1
AU-6
X X X
PAZ-OBJ-103 PAZ-HC-122 System and network management processes and technology are implemented within a PAZ to detect changes in node configurations. CM-1
CM-2
X X X
PAZ-OBJ-108 PAZ-HC-123 PAZ nodes can generate and maintain audit log records, as required by the security audit service. AU-2 X X X
PAZ-OBJ-108 PAZ-HC-124 Audit log files are backed up to secured storage before they are overwritten (thereby overwriting potential evidence). AU-9 X X X
PAZ-OBJ-108 PAZ-HC-125 PAZ nodes maintain locally stored security audit log records that are accessible to authorized security audit administrators, as required by the security audit service. AU-9 X X X
PAZ-OBJ-108 PAZ-HC-126 The PAZ nodes mark time stamps on audit records, and the RZ internal system clocks are synchronized to an authoritative time source. AU-8 (1) X X X
PAZ-OBJ-108 PAZ-HC-127 Regular back ups of system files and system configuration parameters are performed for every node contained in a PAZ. The frequency and the retention period of these back ups are consistent with business needs. CP-9 X X X
PAZ-OBJ-108 PAZ-HC-128 All PAZ nodes are within an area that, at a minimum, meets the physical security requirements of an OZ, as defined in the RCMP publication, G1-026 Guide to the Application of Physical Security Zones [14]. Exceptions may be permitted for core devices owned by public network service providers. PE-3 X X X
PAZ-OBJ-110 PAZ-DP-100 The internetworks can support VPN data traffic connections between edge interfaces. SC-8 - X -
PAZ-OBJ-108 PAZ-DP-101

Although traffic of all sensitivity levels may be handled by a PAZ, data protection measures may be required, depending on the security categorization and the TRA.

Data protection services may be applied at either the network layer or higher layers, depending on the implementation requirements.

SC-8 X X -
PAZ-OBJ-109
PAZ-OBJ-110
PAZ-DP-102 Where encryption or a digital signature is required, products (whether software, firmware, or hardware) must incorporate a Cyber Centre approved algorithm and Cyber Centre approved key management processes, such as those products validated to FIPS 140-2 (or subsequent FIPS 140 releases) by our CMVP. SC-13 X X X
PAZ-OBJ-109
PAZ-OBJ-110
PAZ-DP-103 To protect sensitive data from disclosure and modification, consider the following:
  • Data encryption is used when partially sensitive (i.e. Protected B) information is exchanged with end systems in other zones, or where portions of the internetwork are outsourced to a network service provider; and
  • Data encryption is used when wireless media is used.
SC-8
AC-18 (1)
X X X
PAZ-OBJ-108 PAZ-DP-108 A PAZ implements controls that protect against the reuse and the replay of user authentication data. IA-2 - X X
PAZ-OBJ-112 PAZ-DP-110 A DMZ allows the use of upper layer security mechanisms (e.g. transport layer security [TLS], secure sockets layer [SSL]) for employee web access. SC-13 - X -
PAZ-OBJ-110 PAZ-DP-111 Network layer encryption between a remote and mobile access client and a PAZ is used for remote and mobile access via a PZ. SC-13 - X -
PAZ-OBJ-110 PAZ-DP-112 Remote clients are authenticated to SVPN devices before establishing a connection to an internal zone (e.g. OZ or RZ). IA-2
IA-3
AC-17
- X -
PAZ-OBJ-115 PAZ-DP-113 For remote access via the PZ, use strong user authentication that is supported by a PKI (GC departments use GC PKI). Refer to ITSG 31 [12[] for further authentication requirements. AC-17
IA-2
- X X
PAZ-OBJ-110 PAZ-DP-114 Encrypt data flowing in the SVPN tunnel between a remote user’s computer and the SVPN device. SC-13 - X -
PAZ-OBJ-110 PAZ-DP-115 User and SVPN device PKI certificates meet all applicable policies and practices. SC-12
IA-3
X X X
PAZ-OBJ-115 PAZ-DP-116 The network security zone authorities of each zone must agree on the security access privileges of remote and mobile users for another zone (i.e. OZs or RZs). SC-7 X X X
PAZ-OBJ-110 PAZ-DP-117 Remote access data is encrypted between the host and the remote access server. This data is configured according to applicable standards for remote access. SC-13 - - X
PAZ-OBJ-110 PAZ-DP-118 To protect sensitive data from disclosure and modification, use data encryption in the following scenarios:
  • When protected data is transmitted between end systems in a PZ and end systems in a DMZ;
  • When wireless media is used to transmit protected data; and
  • When Protected B data is transmitted between public end systems and a DMZ or between a DMZ and back end servers.

For information that is being transmitted and that is not governed by the first two scenarios above, data encryption is based on a continuous risk management approach.

Protection may be required when data is exchanged with end systems that are in other zones or where portions of the internetwork are outsourced to a network service provider.

SC-13 - X X
PAZ-OBJ-114 PAZ-DP-119 To support extranet services, use the following network layer security services:
  • Peer entity authentication;
  • Data origin authentication;
  • Data confidentiality;
  • Data integrity; and
  • Data availability.
IA-2
IA-3
- - X
PAZ-OBJ-114 PAZ-DP-120 Data confidentiality services provide isolation between the partners using an extranet. SC-13 - - X
PAZ-OBJ-110 PAZ-DP-121 The following considerations are applied if remote management is allowed:
  • Use strong authentication and integrity protection mechanisms; and
  • Encrypt all network traffic dealing with remote management of PAZ hosts, including identification and authentication traffic.
IA-2
IA-3
SC-13
- - X
PAZ-OBJ-113 PAZ-DP-122 Strong peer entity authentication is used when naming service configurations are transferred between naming services. SC-23 X X X
PAZ-OBJ-108 PAZ-DP-123 Access to management agents on PAZ devices are only permitted from authenticated organization hosts. IA-2 - - X

Annex B - Baseline Security Requirements for an Operations Zone

Foreword

ITSP.80.022 Baseline Security Requirements for Network Security Zones V2 – Annex B – Operations Zone is an UNCLASSIFIED publication.

This version of ITSP.80.022 V2 Annex B supersedes previous versions.

EFFECTIVE DATE

This publication takes effect on January 12, 2021.

REVISION HISTORY

Revision Amendments Date
1 Version 2 released. January 12, 2021.

1 Introduction

-

This annex lists the baseline security requirements for an operations zone (OZ). An OZ is the standard environment for routine business operations and is the primary environment in which end-user systems are installed. With the appropriate security controls applied to the end systems, an OZ is suitable for processing sensitive information; however, in general, the OZ is not a suitable environment for large repositories of sensitive data or critical applications. Using a defence in depth approach to security, the OZ should be capable of mitigating threats categorized up to, and including, the Td4 level. Footnote 9

Within an OZ, traffic is generally unrestricted and can originate internally, from a restricted extranet zone (REZ), or from other authorized external sources (e.g. remote access, mobile access, extranets) via the public access zone (PAZ). Malicious traffic can come from hostile insiders, hostile code imported from the public zone (PZ), or malicious nodes on the network (e.g. a compromised host, an unauthorized attachment to the zone).

B.2 OZ Reference Model

This section describes a reference model for an OZ. See section 4.2 for more information on the general reference model for a zone and its components.

An OZ provides a private and general purpose network environment that is under the single or shared control of your organization. In general, the OZ is the zone to which most information technology resources are connected. Through an OZ, employees can access your organization’s private services.

Typically, an OZ provides attachment points for work stations used by an organization’s employees and contractors to access private services in internal zones and public services in a PZ. An OZ may also provide attachment points for servers that deliver back end services to a PAZ and private services to an organization.

An OZ may support the functions listed in Table 8. These functions have specific security objectives and requirements.

Table 8: Functions Supported by an OZ

Function Description
Internal organizational applications Provide access to internal services and business applications.
Employee file and print services Provide employees and contractors with access to private file and print resources.
Employee simple and rich media web access Provides employees and contractors with access to private and public websites and media streaming through a PAZ.
Email access Provides common communications tools, such as email, for employees.
Interorganizational applications Provide employees with access to interorganizational information and services from other organizations.
Employee remote and mobile access Includes mobile and wireless remote access and a secure virtual private network (SVPN). Provides employees with access to selected OZ resources through a PAZ.
Extranet services Provide a secure method of communications with external partner organizations.
Service delivery applications Provide back end services to the publicly accessible PAZ hosted web interface for your organization’s services.
Common support services Provide the common services required to run a modern, secure network (e.g. DNS, DSA, NTP).

An OZ is intended for organizational information services that are routine and categorized as low sensitivity. However, if additional security measures are applied, an OZ can process and distribute sensitive organizational information using appropriately configured hosts, upper layer security protocols, and application security controls.

In general, sensitive information repositories (e.g. large enterprise databases or databases containing sensitive information) should not be maintained in an OZ.

High availability applications on critical end systems should be in a restricted zone (RZ) or a highly restricted zone (HRZ) to limit their vulnerability to denial-of-service (DoS) attacks. OZ network services are not typically designed to provide high availability. These services should not be used as the only communication channel to support high availability applications. However, the OZ can be used as the primary communications path to support high-availability applications if the overall system availability requirements are met (e.g. providing secondary communications channels).

Interfaces to all public services are implemented through a PAZ. External access from the OZ to the Internet is provided through an interface from the OZ to the PAZ. Interfaces to sensitive services or repositories are implemented through tightly controlled zone interface points (ZIPs) to RZs or HRZs.

Note: For GC departments or agencies, access to other departments is provided through ZIPs to peer OZs or RZs.

An OZ has the structure of a generic zone (see Figure 9 below). It is composed of the three classes of components described in Table 9.

Table 9: OZ Components

Component Description
Internetwork Provides the internal network for an OZ to aggregate and distribute traffic between end systems and ZIPs.
Internal boundary systems (IBSs) Control and monitor traffic between connected internetworks (if more than one implemented).
End systems Provide localized processing and storage of organizational information.

Figure 9 provides a logical view of an OZ and the relationships between the components in an OZ. It also demonstrates a high-level view of an OZ’s connection to other zones. To simplify the diagram, the management zone (MZ) and the MZ connections are not shown. See Annex E for MZ requirements and connection recommendations.

Where a node is shared between two zones (like the shared end system in Figure 9), both network security zone authorities should agree on the management and the oversight of the node. OZ entities communicate to other zones through ZIPs, which provide ingress and egress controls on traffic flows.

Figure 9: OZ Logical Topology

Long description immediatly follow
Long description

Figure 9 provides a logical view of an OZ and the relationships between the components in an OZ. It also demonstrates a high-level view of an OZ’s connection to other zones. To simplify the diagram, the management zone (MZ) and the MZ connections are not shown in Figure 9.

B.3 OZ Security Objectives

In general, the target security state of an OZ is a network environment that prevents (i.e. removes vulnerability to) network-based attacks from threat actors categorized as Td4. An OZ’s target security state should also reduce vulnerabilities exploited by threat actors categorized as Td5Footnote 10 and above. The assumption is that Td5 threat actors could defeat the network-based security controls within an OZ; therefore, additional security measures are required to protect sensitive assets within an OZ.

Each security objective and requirement specified in this annex is labelled according to the following notation conventions:

  • The first set of letters refers to the zone (OZ).
  • The second set of letters designates either an objective (OBJ) or a requirement (REQ).
  • Requirements (REQs) are grouped into the following categories, as applicable:
    • Network interface (NI);
    • Traffic control (TC);
    • Network configuration (NC);
    • Host configuration (HC); and
    • Data protection (DP).
  • Each objective or requirement is sequentially numbered within its group, beginning at 100.
    Note: Objectives and requirements are not sequential; some requirements have been removed or changed from the previous versions of this document.

B.3.1 Traffic Control Objectives

[OZ-OBJ-100] An OZ should protect the integrity and availability of end systems attached to the zone. An OZ aims to do the following:

  • Prevent threat actors categorized up to the Td4 level from carrying out network based DoS attacks (e.g. SYN flood, DDoS attack) on end systems;
  • Reduce the impact of network based DoS attacks on end systems carried out by all other threat sources;
  • Prevent threat actors categorized up to the Td4 level from using network intrusions (e.g. attaching an unauthorized device to an existing interface, adding an unauthorized edge interface) to access to end systems;
  • Reduce the impact of network intrusions carried out by all other threat sources; and
  • Contain the impact of a compromised end system;
  • Prevent threat actors categorized up to Td4 from exploiting end systems as staging points for attacks on other systems;
  • Prevent other threat sources from exploiting end systems as staging points for attacks on other systems;
  • Prevent the spread of malicious traffic from other zones to the OZ; and
  • Stop the spread of malware.

[OZ-OBJ-102] An OZ should be able to respond to increased threat levels (e.g. time of crisis) by permitting enhancements to security measures, such as the following:

  • Flexible and dynamic traffic controls; and
  • Increased surveillance of network infrastructure that is outsourced to network service providers.

Note: Network security measures are limited in their ability to protect end systems from compromises through valid application interfaces. You should implement platform, application, and operational security measures to address the risks associated with threats of this type.

[OZ-OBJ-103] A PAZ implements safeguards to protect the zone against malicious network traffic that originates from public networks. However, there are residual risks from a PAZ that should be addressed by an OZ. The objective of an OZ is to reduce the following threats:

  • Attacks originating from compromised remote access and extranet end systems;
  • Attacks originating from a compromised host in a PAZ and failures in PAZ traffic control measures; and
  • Malicious traffic originating from compromised service delivery application servers a PAZ.

Note: The threat of malicious track originating from compromised service delivery application services can be reduced by limiting their access to designated resources and protocols.

B.3.2 Network Availability and Integrity Objectives

[OZ-OBJ-104] An OZ should protect the integrity and the availability of network services by reducing vulnerabilities to a variety of attacks. An OZ should take the following protection measures:

  • Prevent threat actors categorized up to Td4 from carrying out network based DoS attacks (e.g. SYN flood, DDoS attack) on end systems;
  • Reduce the impact of network based DoS attacks on end systems from all other sources;
  • Prevent threat actors categorized up to Td4 from using network intrusions (e.g. attaching an unauthorized device to an existing interface, adding an unauthorized edge interface) to access end systems;
  • Reduce the impact of network intrusions from all other sources;
  • Contain the impact of a compromised end system;
  • Prevent threat actors categorized up to Td4 from exploiting end systems as staging points for attacks on other systems;
  • Prevent other sources from exploiting end systems as staging points for attacks on other systems;
  • Prevent the spread of malicious traffic from other zones to an OZ; and
  • Stop the spread of malware.

B.3.3 Data Protection Objectives

[OZ-OBJ-105] An OZ should prevent threat actors categorized up to the Td4 level from intercepting zone traffic. An OZ should also be able to prevent the undetected interception of zone traffic by other threat sources.

[OZ-OBJ-106] An OZ should support the following measures to protect the confidentiality and the integrity of data:

  • SVPN within the internetwork;
  • SVPN as an optional data service; and
  • Upper layer security protocols.

Note: Employees from another organization may need to access network services and their home networks securely. In these situations, temporary access through an access point located in a boardroom, or permanent access for employees assigned to the host organization may be required.

B.4 OZ Baseline Security Requirements

Table 10 describes an OZ’s baseline security requirements, which are categorized by operational requirement (i.e. network interface, traffic control, network configuration, host configuration, and data protection). To achieve all the security objectives for this zone, the complete set of security requirements must be implemented.

At a minimum, we recommend implementing the baseline security requirements. However, you should consult the referenced ITSG-33 [4] controls to determine whether you need to implement additional technical, management, and operational mechanisms to mitigate against expected Td4 level threats.

Table 10: OZ Baseline Security Requirements

Objective Number Requirement Number Zone Requirement Related ITSG 33 Control Internal boundary system (IBS) Internetwork End System
Network Interface
OZ OBJ 100 OZ NI 100 All network paths between an OZ and other zones pass through a ZIP. SC 7 X X -
OZ OBJ 103 OZ NI 102

All network paths destined for, or originating from, a PZ (e.g. the Internet), pass through a PAZ.
An OZ does not have direct network connections to a PZ.

SC 7 (8)
SC 7 (C)
X X -
OZ OBJ 104 OZ NI 103

An OZ internetwork is a logically separated network. It maintains traffic interfaces with only the following components:

  • ZIPs;
  • IBS(s) to other internetworks; and
  • OZ end systems.
AC 4 - X -
OZ OBJ 103 OZ NI 105 IBSs and internetwork components support the attachment of network-based intrusion detection sensors (e.g. monitors) and the collection of data from these sensors. SI 4 (4) X X -
Traffic Control
OZ OBJ 102 OZ TC 102

In the event of an emergency or an increased threat and when authorized, an OZ can respond quickly to heightened security levels. For example, an OZ can improve the network’s security posture by increasing the level of security for the following measures:

  • Filtering;
  • Monitoring (active and passive);
  • Protecting the continuous delivery of critical services (e.g. reconfigure or block non essential services if required); and
  • Auditing.

Authorized personnel are trained on how to initiate such a response.

Before implementing these security measures, they are tested to ensure that these capabilities cannot be exploited to cause a DoS.

AC-4
AU-6
IR-4
SC-7
SC-10
SI-4
X X X
OZ-OBJ-103 OZ-TC-103 The identities of both zones are authenticated prior to communication between these zones. IA-3 X X -
OZ-OBJ-100 OZ-TC-104 The internetwork provides an access control service capable of enforcing access control policies between edge interfaces based on network layer source, network layer destination, transport protocol, and transport layer service interface. AC-3
AC-4
SC-10
- X -
OZ-OBJ-100 OZ-TC-105

An OZ network security zone authority defines requirements for the OZ’s internetwork access control service. These requirements are based on the following principles:

  • The access control policy is constructed to deny all traffic that is not explicitly permitted;
  • The access control policy supports community of interest separation (i.e. where network traffic is divided into natural communities of interests, the access control policy enforces these natural traffic flows);
  • The access control policy restricts available network paths to vulnerable or sensitive end systems (e.g. test and development sub networks and application servers supporting public applications);
  • The access control policy is configured to limit available network paths for end systems accessible by extranets;
  • The access control policy limits access to other end systems via remote access hosts if an OZ network security zone authority permits connection to an OZ by remote access hosts with operating systems that do not separate user and administrator roles; and
  • The access control policy supports separation between classes of service if the internetwork provides more than one class of service.
AC-2
AC-3
AC-4
AC-17
IA-3
SC-7 (11)
X X X
OZ-OBJ-104 OZ-TC-106 If an OZ supports more than one class of service, the internetwork implements mechanisms to ensure non interference between classes of service. AC-4 - X -
OZ-OBJ-103 OZ-TC-107 The internetwork uses an addressing model that helps detect and diagnose malicious traffic. CA-3
SC-7
SI-3
- X -
OZ-OBJ-105 OZ-TC-108 An OZ supports SVPN traffic between any pair of edge interfaces. SC-8 X X -
obj req

The network security zone authority defines an access control policy, which is enforced by the access control service, based on the following principles:

  • The access control policy denies all traffic unless explicitly permitted;
  • All outgoing traffic is restricted to destination addresses corresponding to designated proxy servers in a PAZ;
  • Extranet hosts are restricted to a defined set of internal addresses, which contain the resources required by the extranet; and
  • Remote access clients are restricted to addresses and protocols necessary to support communication with the services if the network zone authority permits remote access hosts with open configurations (see host configuration).

Traffic to and from servers is restricted to addresses and protocols necessary to support communication with the servers.

AC-4
SC-7 (5)
SC-7 (8)
SC-7 (11)
X X X
OZ-OBJ-100 OZ-TC-121 Record the audit relevant traffic control and data flow information in the security audit log, according to the requirements of the security audit service. AU-1
AU-2
X X -
Network Configuration
OZ-OBJ-104 OZ-NC-100 The OZ network configuration is monitored to detect additions, deletions, or changes to edge interfaces. Unauthorized changes are reported to an OZ network security zone authority. AU-1
CM-2
CM-3
SI-4
X X -
OZ-OBJ-104 OZ-NC-101 OZ edge interfaces are registered with the OZ network security zone authority. CM-8 - X -
OZ-OBJ-104 OZ-NC-103 An OZ network security zone authority periodically verifies the network topology. AU-1
CM-2
CM-9
X X -
OZ-OBJ-105 OZ-NC-104 An OZ network security zone authority periodically assesses the network configuration for unauthorized external interfaces. AU-1
SI-4 (4)
X X -
OZ-OBJ-104 OZ-NC-105 Only authenticated and authorized administrators can manage OZ nodes and only from the OZ MZ. AC-5
IA-5
- - X
OZ-OBJ-104 OZ-NC-106 Edge interface addresses are distinct and dedicated. SC-7 - X -
OZ-OBJ-105 OZ-NC-107 Edge interface addresses are visible to other organization zones, but they are not visible to a PZ. SC-7 - X -
OZ-OBJ-104 OZ-NC-108 A change to an OZ edge interface’s address assignment constitutes a configuration change, which requires approval by an OZ network security zone authority. CM-3
CM-9
- X /td>
OZ-OBJ-104 OZ-NC-109 An OZ network security zone authority maintains current configuration information for all interfaces within the internetwork. CM-2
CM-6
- X -
OZ-OBJ-104 OZ-NC-110 Changes to an OZ are approved by an OZ network security zone authority before they are implemented. CM-3 (4)
CM-9
X X X
OZ-OBJ-104 OZ-NC-111 Connections within an OZ have established security associations. All communications are authenticated (either explicitly or implicitly) within the context of these security associations. The permitted security associations are determined by traffic control requirements. AC-4
IA-3
SC-23
X X X
OZ-OBJ-104 OZ-NC-112 Internetwork edge interfaces are authenticated to each other using cryptographic authentication mechanisms approved by the Cyber Centre. IA-3 (1) - X -
OZ-OBJ-104 OZ-NC-121 Service level agreements for outsourced networks require that an OZ network security zone authority approves any changes to internetwork interfaces under a network service providers’ control. CP-8 X X X
OZ-OBJ-104 OZ-NC-122

Service level agreements for outsourced networks require the following:

  • A network service provider provides evidence that the security controls used to enforce the security within the internetwork core are effective;
  • All security incidents that could impact an OZ are reported to an OZ network security zone authority; and
  • A network service provider gives an OZ network security zone authority the capability to verify the effectiveness of the controls.
CP-8 X X X
OZ-OBJ-104 OZ-NC-123

End systems maintain the integrity of network interfaces with organization zones while connected to an OZ.
OZ end systems do not permit dual homing, tunnel splitting, or other shared network paths with a PZ.

SC-7 (7) - - X
Host Configuration
OZ-OBJ-104 OZ-HC-100 An OZ network security zone authority maintains a node and host configuration policy that is consistent with applicable baseline security requirements, standards, and guidance. This policy applies to all hosts attached to an OZ. CM-1
CM-2
X X X
OZ-OBJ-104 OZ-HC-101

The node and host network configuration policy should contain the following:

  • A specification of prohibited and mandated networking software and hardware configurations; and
  • Minimum maintenance procedures for all networking software.
CM-1
CM-6
CM-7
MA-2
MA-6
SI-2
X X X
OZ-OBJ-104 OZ-HC-103

Regular network vulnerability assessments (Vas) of all nodes and hosts are conducted to assess trends in the effectiveness of the host configuration policy.

The frequency of these VAs is enough to support trend analysis.

All VA results are managed within the framework of continuous risk management and, as such, provide feedback to the security assessment and authorization (SA&A) process.

CA-7
RA-5
X X X
OZ-OBJ-104 OZ-HC-104 All nodes invoke controls that implement continuous protection against malware at start up. SI-3
SI-7 (1)
X X -
OZ-OBJ-104 OZ-HC-105 All hosts that provide applications to permit client access to public resources (e.g. Internet web browsers and email clients) use operating systems that separate duties and administration. They are also configured to operate any applications that provide access to public resources in user mode. AC-5
AC-6
X X X
OZ-OBJ-104 OZ-HC-106 System and network management processes and technology is implemented within an OZ to detect changes in node configurations. SI-7 (7) X X -
OZ-OBJ-104 OZ-HC-107 Regular back ups of system files and system configuration parameters are performed for every node contained in an OZ. The frequency and the retention period of back ups are consistent with business needs. CP-9 X X -
OZ-OBJ-104 OZ-HC-108 The failure of an OZ node does result in the compromise of its resources or the resources of any connected network. SC-24 X X -
OZ-OBJ-104 OZ-HC-109 All OZ nodes and hosts are within an area that meets the physical security requirements determined by the information system security implementation process (ISSIP). For GC department requirements, see the Operational Security Standard on Physical Security [16]. PE-18 X X X
OZ-OBJ-104 OZ-HC-111 Operating systems and necessary applications for all nodes are hardened based on documented best practices. CM-6
CM-7
X X -
OZ-OBJ-106 OZ-HC-112 SVPN products, if used, are validated to FIPS 140-2, at a minimum of Security Level 2, through the Cryptographic Module Validation Program (CMVP). SC-13 X X X
OZ-OBJ-104 OZ-HC-113 Nodes are physically secured to limit access to only authorized personnel who have a need to access the equipment, according to the principles of least privilege and the need to know. PE-2
PE-3 (1)
PE-18
X X -
OZ-OBJ-100 OZ-HC-114 An end system includes a personal firewall, a configuration integrity mechanism capable of identifying changes to the configuration and notifying the end system administrator of these changes. SC-7 (12)
SI-7
- - X
OZ-OBJ-104 OZ-HC-115

A shared end system, whether shared permanently or periodically, complies with the following requirements:

  • An operating system that supports the separation of users and administrators (i.e. enforces the principles of separation of duties and least privilege) is used;
  • Changes to network configuration require administrative privileges;
  • The end system configuration, and the procedures for maintaining that configuration, is approved by an OZ network security zone authority; and
  • The end system is subject to regular VAs (results to be provided to the threat risk assessment [TRA] process). The network security zone authority determines the frequency of the VAs and documents the frequency in the zone’s VA procedures.
AC-5
AC-6 (1)
AC-6 (5)
CM-3
- - X
OZ-OBJ-104 OZ-HC-116 A complex end system undergoes a SA&A before it can be attached to an edge interface. CA-1
CA-6
- - X
OZ-OBJ-105 OZ-HC-122 Host based intrusion detection sensors are placed on all critical hosts. SC-7(12) - - X
OZ-OBJ-105 OZ-HC-123 OZ nodes generate and maintain audit log records, as required by the security audit service. AU-2 X X X
OZ-OBJ-105 OZ-HC-124 OZ nodes ensure that locally stored security audit log records are accessible to authorized security audit administrators, as required by the security audit service. AU-6(3)
AU-6(4)
X X X
OZ-OBJ-105 OZ-HC-125

Each OZ node is subject to regular configuration audits. The network security zone authority determines the frequency of these audits and documents the frequency in the zone’s configuration management procedures.

Configuration audits are conducted frequently enough to identify configuration errors. The configuration audit includes, but is not limited to, the following checks:

  • Verifies node configuration against network topology design;
  • Verifies hardware devices and physical interfaces;
  • Verifies traffic control configuration, including permissions and access controls; and
  • Verifies permitted software load and permitted functions.
AU-1
AU-6
AU-6(1)
AU-6(2)
AU-6(3)
AU-6(4)
AU-6(7)
X X X
OZ-OBJ-105 OZ-HC-126 The OZ nodes mark time stamps on audit records. The OZ internal system clocks are synchronized to an authoritative time source. AU-8 (1) X X X
Data Protection
OZ-OBJ-106 OZ-DP-100 The internetwork supports SVPN data traffic connections between edge interfaces. SC-8 - X -
OZ-OBJ-106 OZ-DP-101 An OZ supports SVPN data traffic connections between ZIPs. SC-8 X X -
OZ-OBJ-106 OZ-DP-103

Although traffic at all sensitivity levels may be handled by an OZ, data protection measures may be required, depending on the security categorization and the TRA results.

Data protection services may be applied at either the network layer or higher layers, depending on the implementation requirements.

SC-8 X X -
OZ-OBJ-106 OZ-DP-104 Where encryption or digital signature is required, products (whether software, firmware, or hardware) must incorporate a Cyber Centre-approved algorithm and Cyber Centre-approved key management processes, such as those products validated to FIPS 140 2 (or subsequent FIPS 140 releases) by the Cyber Centre’s CMVP. SC-13 X X X
OZ-OBJ-106 OZ-DP-105 Data encryption is used when partially sensitive (i.e. Protected B) information is exchanged with end systems in other zones or where portions of the internetwork are outsourced to a network service provider. AC-18 (1)
SC-8
X X X

Annex C - Baseline Security Requirements for a Restricted Zone

Foreword

ITSP.80.022 Baseline Security Requirements for Network Security Zones V2: Annex C – Restricted Zone is an UNCLASSIFIED publication.

This version of Annex C supersedes previous versions of the document.

EFFECTIVE DATE

This publication takes effect on January 12, 2021.

Revision history

Revision Amendments Date
1 Version 2 released. January 12, 2021.

Annex C - Baseline Security Requirements for a Restricted Zone

Introduction

This annex lists the baseline security requirements for a restricted zone (RZ), which is the standard environment for concentrations of end systems. Server farms, storage networks, and management servers are installed primarily in an RZ. This zone may also contain enclaves of end systems that require higher levels of protection than those provided in an operations zone (OZ).

An RZ is suitable for processing sensitive information, storing large repositories of sensitive data, and running critical applications. By using a defence in depth approach to security and increasing the robustness levels of the zone’s security mechanisms, an RZ is expected to mitigate threats that are categorized up to and including the Td4 level. Footnote 11

An RZ supports interfaces to organization controlled zones, OZs, and highly restricted zones (HRZs). End systems within an RZ may serve public applications (mediated through an OZ and a public access zone [PAZ]). Traffic is restricted within an RZ, and it should be constrained to limit the potential for interference between platform or application security domains. Review the results of the information system security implementation process (ISSIP) to determine whether you need additional security controls and increased levels of robustness in selected devices that implement these controls.

C2 RZ Reference Model

An RZ provides a general purpose, private network environment under the single or shared control of an organization. For many organizations, the bulk of sensitive IT resources will be stored on an RZ.

An RZ’s network environment supports the deployment of high availability applications and sufficiently protects them from DoS attacks. However, the guidance in this annex does not require an RZ to be designed for high availability or high integrity.

Interfaces to all public services are implemented through an OZ and a PAZ. External access from an RZ to the Internet is provided through an interface from an RZ to a PAZ through an OZ. Access to an RZ from another organization is provided by interfaces to peer zones (i.e. OZ, RZ, HRZ). Interfaces to sensitive services or repositories are implemented through tightly controlled interfaces.

An RZ has the structure of a generic zone, and it includes the three classes of components described in Table 11.

Table 11: RZ Components

Component Description
Internetwork Provides the internal network for an RZ to aggregate and distribute traffic between end systems and zone interface points (ZIPs).
Internal boundary systems (IBSs) Provides the means to control and monitor traffic between connected internetworks if more than one internetwork is implemented.
End systems Locally process and store organizational information.

Figure 10 depicts a logical view of an RZ and its connection with other zones. To simplify the diagram, the management zone (MZ) and the MZ connections are not shown in Figure 10. See Annex E for MZ requirements and connection recommendations.

As in the case of the shared end system shown in Figure 10, where a node is shared between two zones, both network security zone authorities should agree on the node’s management and oversight.

As described in Annex F, a ZIP provides the interface between RZ entities and other zones. The ZIPs provide ingress and egress controls on traffic flows at the points where an RZ connects with other zones.

Figure 10: RZ Logical Topology

Long description immediatly follow
Long description

Figure 10 depicts a logical view of an RZ and its connection with other zones. To simplify the diagram, the management zone (MZ) and the MZ connections are not shown in Figure 10.

C.3 Security Objectives

An RZ’s target security state is to be a controlled network environment that is suitable for the following functions:

  • Enterprise platform and application services; and
  • Client enclaves that require higher levels of protection.

An RZ is characterized by rigorous network configuration controls and carefully controlled traffic flow. Traffic control measures in an RZ are designed to contain security failures.

An RZ’s target security state is also to mitigate against threat actors categorized up to the Td4 level. However, the assumption is that Td5Footnote 12 threat actors could defeat an RZ’s network based security controls. An HRZ may be implemented to mitigate against threat actors categorized up to the Td5 level.

Each objective and requirement specified in this annex is labelled according to the following notation conventions:

  • The first set of letters refers to the zone (RZ).
  • The second set of letters designates an objective (OBJ) or a requirement (REQ).
  • Requirements are grouped into the following categories, as applicable:
    • Network interface (NI);
    • Traffic control (TC);
    • Network configuration (NC);
    • Host configuration (HC); and
    • Data protection (DP).
  • Each objective or requirement is sequentially numbered within its group, beginning at 100.

    Note: Objectives and requirements are not sequential; some requirements have been removed or changed from the previous versions of this document.

C.3.1 Traffic Control Objectives

[RZ-OBJ-100] An RZ should protect the integrity and the availability of end systems that are attached to the zone. An RZ should have the following objectives:

  • Prevent threat actors categorized up to the Td4 level from carrying out network based DoS attacks (e.g., SYN flood, DDoS attack) on end systems;
  • Reduce the impact on end systems if network-based DoS attacks are carried out by other threat sourcesFootnote 13;
  • Prevent threat actors categorized up to the Td4 level from using network intrusions (e.g. attaching an unauthorized to an existing interface, adding an unauthorized edge interface) to access end systems;
  • Reduce the impact of network intrusions from all other threat sources;
  • Contain the impact of a compromised end system;
  • Prevent threat actors categorized up to the Td4 level from exploiting end systems as staging points for attacks on other systems;
  • Prevent all other threat sources from exploiting end systems as staging points for attacks on other systems;
  • Prevent the spread of malicious traffic from other zones to an RZ; and
  • Stop the spread of malware.

[RZ-OBJ-102] An RZ should respond to increased threat levels (e.g. time of crisis) by allowing the following enhancements to security measures:

  • Flexible and dynamic traffic controls; and
  • Increased status monitoring.

[RZ-OBJ-103] The zones and the ZIPs implement safeguards to protect against malicious network traffic that originates in public networks; however, the RZ should address any residual risks with the following objectives:

  • Reduce vulnerability to attacks that originate from compromised remote access and extranet end systems;
  • Reduce vulnerability to malicious traffic from compromised service delivery application servers in the zones by implementing enough safeguards (e.g. limiting access from these servers to designated resources and protocols);
  • Reduce vulnerability to attacks resulting from compromised hosts, other than a service delivery application server, in the OZ or the PAZ; and
  • Reduce vulnerability to failures in the RZ’s traffic control measures, including intrusions through other zones’ internetworks.

C.3.2 Network Availability and Integrity Objectives

[RZ-OBJ-104] An RZ should protect the integrity and the availability of network services by reducing their susceptibility to a variety of attacks. An RZ should achieve the following objectives:

  • Prevent threat actors categorized up to the T4d level and all other threat sources from carrying out network based DoS attacks by filtering malicious attacks from outside the RZ;
  • Prevent threat actors categorized up to the T4d level from carrying out network intrusions (e.g. attaching an unauthorized device to an existing interface, adding an unauthorized edge interface, or compromising an attached end system);
  • Reduce vulnerability to network intrusions carried out by all other sources;
  • Prevent threat actors categorized up to the T4d level from exploiting end systems as staging points for attacks on network services; and
  • Prevent all other sources from exploiting end systems as staging points for attacks on network services.

C.3.3 Data Protection Objectives

[RZ-OBJ-105] An RZ should prevent threat actors categorized up to the T4d level from intercepting zone traffic and detect traffic interception by all other sources.

[RZ-OBJ-106] An RZ should support measures to protect the confidentiality and the integrity of data, such as the following:

  • Secure virtual private network (SVPN) within the internetwork;
  • SVPN as optional data service; and
  • Upper-layer security protocols.

C.4 Baseline Security Requirements

This section describes the baseline security requirements for an RZ. These requirements are categorized by operational requirement (i.e. network interface, traffic control, network configuration, host configuration, and data protection).

To achieve all the security objectives for this zone, you must implement the complete set of security requirements listed in Table 12. Although these requirements are the minimum baseline requirements for an RZ, you should consult the referenced ITSG-33 [4] controls to determine if additional technical, management and operational mechanisms are required to mitigate against the expected Td4 threat level.

Table 12: RZ Baseline Security Requirements

Objective Number Requirement Number Zone Requirement Related ITSG-33 control IBS Internetwork End System
Network Interface
RZ OBJ 100 RZ NI 100 All network paths between the RZ and other zones pass through a ZIP. SC 7 X X -
RZ OBJ 103 RZ NI 102

An RZ does not have direct network connections to a PZ.

All network paths destined for, or originating from, a PZ (e.g. Internet) pass through a PAZ.

SC 7 (8) X X -
RZ OBJ 104 RZ NI 103

An RZ internetwork is a logically separate network. It maintains traffic interfaces with only the following components:

  • ZIPs;
  • IBS(s) to other internetwork(s); and
  • RZ end systems.
AC 4 - X -
RZ-OBJ-103 RZ-NI-105 IBSs and internetwork components support the attachment of network based intrusion detection sensors (e.g. monitors) and the collection of data from these sensors. SI-4 (4) X X -
Traffic Control
RZ-OBJ-102 RZ-TC-102

An RZ responds quickly to heightened security levels (e.g. emergency and increased threat) when authorized to do so. For example, an RZ improves the network security posture by increasing the level of security for the following measures:

  • Filtering;
  • Monitoring (active and passive);
  • Protecting the continuous delivery of critical services (e.g. reconfigure or block non essential services if required); and
  • Auditing.

Before implementing these security measures, they are carefully tested to ensure they cannot be exploited to cause a denial of service.

Personnel are trained and authorized to initiate a response to heightened security levels.

AC-4
AU-6
IR-4
SC-7
SC-10
SI-4

X X X
RZ-OBJ-103 RZ-TC-103 The identity of both zones is authenticated prior to communication between the zones. IA-3 X X -
RZ-OBJ-100 RZ-TC-104 The internetwork provides an access control service that can enforce access control policies between edge interfaces. These policies are based on network layer source, network layer destination, transport protocol, and transport layer service interface. AC-3
AC-4
SC-10
- X -
RZ-OBJ-100 RZ-TC-105

An RZ network security zone authority defines requirements for an RZ internetwork access control service, which is based on the following principles:

  • The access control policy denies all traffic that is not explicitly permitted;
  • The access control policy supports community of interest separation (i.e. where network traffic is divided into natural communities of interest, the access control policy enforces these natural traffic flows);
  • The access control policy restricts available network paths to vulnerable or sensitive end systems (e.g. test and development sub networks and application servers that support public applications);
  • The access control policy limits available network paths for end systems that are accessible by extranets; and
  • The access control policy limits access to other end systems via remote access hosts if an RZ network security zone authority permits connection to an RZ by remote access hosts with operating systems that do not separate user and administrator roles.

The access control policy supports separation between classes of service if the internetwork provides more than one class of service.

AC-2
AC-3
AC-4
AC-17
IA-3
SC-7 (11)
X X X
RZ-OBJ-104 RZ-TC-106 The internetwork implements mechanisms to ensure non interference between classes of service if the RZ supports more than one class of service. AC-4 - X -
RZ-OBJ-103 RZ-TC-107 The internetwork uses an address model that helps detect and diagnose malicious traffic. CA-3
SC-7
SI-3
- X -
RZ-OBJ-105 RZ-TC-108 The RZ supports SVPN traffic between any pair of edge interfaces. SC-8 X X -
RZ-OBJ-104 RZ-TC-110

The network security zone authority defines an access control policy, which is enforced by the access control service, based on the following principles:

  • The access control policy denies all traffic unless it is explicitly permitted;
  • All outgoing traffic is restricted to destination addresses that correspond to designated proxy servers in the PAZ;
  • Extranet hosts are restricted to a defined set of internal addresses, which contain the resources required by the extranet; and
  • Remote access clients are restricted to a defined set of internal addresses if the network security zone authority permits remote access hosts with open configurations (see host configuration); and
  • Traffic to and from servers is restricted to addresses and protocols that are necessary to support communication with the servers.
AC-4
SC-7 (5)
SC-7 (8)
SC-7 (11)
X X X
RZ-OBJ-100 RZ-TC-121 All audit relevant traffic control and data flow information is recorded in the security audit log, according to the security audit service requirements. AU-1
AU-2
X X -
Network Configuration
RZ-OBJ-104 RZ-NC-100

The RZ network configuration is monitored to detect additions, deletions, or changes to edge interfaces.

Unauthorized changes are reported to an RZ network security zone authority.

AU-1
CM-2
CM-3
SI-4
X X -
RZ-OBJ-104 RZ-NC-101 RZ edge interfaces are registered with an RZ network security zone authority. CM-8 - X -
RZ-OBJ-104 RZ-NC-103 An RZ network security zone authority periodically verifies the network topology. AU-1
CM-2
CM-9
X X -
RZ-OBJ-105 RZ-NC-104 An RZ network security zone authority periodically assesses the network configuration for unauthorized external interfaces. AU-1
SI-4 (4)
X X -
RZ-OBJ-104 RZ-NC-105 Only authenticated and authorized administrators can manage RZ nodes, and only from an RZ MZ. AC-5
IA-5
- - X
RZ-OBJ-104 RZ-NC-106 Edge interface addresses are distinct and dedicated. SC-7 - X -
RZ-OBJ-105 RZ-NC-107 Edge interface addresses are visible to other zones, but they are not visible to a PZ. SC-7 - X -
RZ-OBJ-104 RZ-NC-108 A change to an RZ edge interface’s address assignment constitutes a configuration change that requires approval by an RZ network security zone authority. CM-3
CM-9
- X -
RZ-OBJ-104 RZ-NC-109 An RZ network security zone authority maintains the current configuration information for all interfaces within the internetwork. CM-2
CM-6
- X -
RZ-OBJ-104 RZ-NC-110 Changes to an RZ are approved by an RZ network security zone authority before they are implemented. CM-3 (4)
CM-9
X X X
RZ-OBJ-104 RZ-NC-111

Connections within an RZ have established security associations.

All communications are authenticated (either explicitly or implicitly) within the context of these security associations.

The permitted security associations are determined by traffic control requirements.

AC-4
IA-3
SC-23
X X -
RZ-OBJ-104 RZ-NC-112 Internetwork edge interfaces are authenticated to each other using cryptographic authentication mechanisms approved by the Cyber Centre. IA-3 (1) - X -
RZ-OBJ-104 RZ-NC-121 Service level agreements for outsourced networks require that before any changes can be made to internetwork interfaces that are under the control of a network service provider, approval is required from an RZ network security zone authority. CP-8 X X X
RZ-OBJ-104 RZ-NC-122

Service level agreements for outsourced networks should include the following requirements:

  • The network service provider must provide evidence of the effectiveness of the security controls used to enforce the security within the internetwork core; and
  • All security incidents that could impact an RZ must be reporting to an RZ network security zone authority; and
  • The network service provider must give an RZ network security zone authority the capability to verify the effectiveness of the security controls.
CP-8 X X X
RZ-OBJ-104 RZ-NC-123 End systems maintain the integrity of network interfaces with organization zones while connected to an RZ. RZ end systems are not permitted to use dual homing, tunnel splitting, or other shared network paths with a PZ. SC-7 (7) - - X
Host Configuration
RZ-OBJ-104 RZ-HC-100 An RZ network security zone authority maintains a node and host configuration policy that is consistent with applicable baseline security requirements, standards, and guidance. This policy applies to all hosts attached to the zone. CM-1
CM-2
X X X
RZ-OBJ-104 RZ-HC-101

The node and host network configuration policy addresses the following considerations:

  • A specification of prohibited and mandated networking software and hardware configurations; and
  • Minimum maintenance procedures for all networking software.
CM-1
CM-6
CM-7
MA-2
MA-6
SI-2
X X X
RZ-OBJ-104 RZ-HC-103

Regular network vulnerability assessments (VAs) of all nodes and hosts are conducted to assess trends in the effectiveness of the host configuration policy.

The frequency of VAs is enough to support trend analysis.

The results of all VAs are managed within the framework of continuous risk management and provide feedback to the security assessment and authorization (SA&A) process.

CA-7
RA-5
X X X
RZ-OBJ-104 RZ-HC-104 All nodes invoke controls that implement continuous protection against malware at start up. SI-3
SI-7 (1)
X X -
RZ-OBJ-104 RZ-HC-105 All hosts that provide applications to permit client access to public resources (e.g. Internet web browsers and email clients) use operating systems that separate duties and administration. These hosts are configured to operate any applications that provide access to public resources in user mode. AC-5
AC-6
X X X
RZ-OBJ-104 RZ-HC-106 System and network management processes and technology are implemented within an RZ to detect changes in node configurations. SI-7 (7) X X -
RZ-OBJ-104 RZ-HC-107

Regular back-ups of system files and system configuration parameters are performed for every node contained in an RZ.

The frequency and the retention period of these back-ups are consistent with business needs.

CP-9 X X -
RZ-OBJ-104 RZ-HC-108 The failure of an RZ node does not result in the compromise of its resources or the resources of any connected network. SC-24 X X -
RZ-OBJ-104 RZ-HC-109 RZ nodes and hosts are within an area that meets the physical security requirements as determined by the ISSIP. GC departments must align with the Operational Security Standard on Physical Security [16]. PE-18 X X X
RZ-OBJ-104 RZ-HC-111 Operating systems and necessary applications for all nodes are hardened based on documented best practices. CM-6
CM-7
X X -
RZ-OBJ-106 RZ-HC-112 SVPN products, if used, are validated to FIPS 140-2, at a minimum of Security Level 2, through the Cyber Centre’s Cryptographic Module Validation Program (CMVP). SC-13 X X X
RZ-OBJ-104 RZ-HC-113 Nodes are physically secured to limit access to only authorized personnel who have a need to access the equipment, according to the principles of least privilege and the need to know. PE-2
PE-3 (1)
PE-18
X X -
RZ-OBJ-100 RZ-HC-114 An end system should include a personal firewall, a configuration integrity mechanism capable of identifying changes to the configuration and notifying the end system administrator. SC-7 (12)
SI-7
- - X
RZ-OBJ-104 RZ-HC-115

A shared end system, whether shared permanently or periodically, should comply with the following requirements:

  • Use of an operating system that supports the separation of users and administrators (i.e. enforces the principles of separation of duties and least privilege);
  • Changes to the network configuration require administrative privileges to make changes to network configurations;
  • End system configuration and procedures for maintaining that configuration are approved by an RZ network security zone authority; and
  • End system is subject to regular VAs (results are provided to the threat risk assessment [TRA] process).

The network security zone authority determines the frequency of end system VAs and documents the frequency in the zone’s VA procedures.

AC-5
AC-6 (1)
AC-6 (5)
CM-3
- - X
RZ-OBJ-104 RZ-HC-116 A complex end system undergoes the SA&A process before it can be attached to an edge interface. CA-1
CA-6
- - X
RZ-OBJ-105 RZ-HC-122 Host based intrusion detection sensors are placed on all critical hosts. SC-7(12) - - X
RZ-OBJ-105 RZ-HC-123 RZ nodes can generate and maintain audit log records, as required by the security audit service. AU-2 X X X
RZ-OBJ-105 RZ-HC-124 RZ nodes make locally stored security audit log records accessible to authorized security audit administrators, as required by the security audit service. AU-6(3)
AU-6(4)
X X X
RZ-OBJ-105 RZ-HC-125

Each RZ node is subject to regular configuration audits. The network security zone authority determines the frequency of these audits and documents the frequency in a RZ configuration management procedures.

The frequency of these audits is enough to identify configuration errors. The configuration audit includes, but is not limited to, the following checks:

  • Verification of node configuration against network topology design;
  • Verification of hardware devices and physical interfaces;
  • Verification of traffic control configuration, including permissions and access controls; and
  • Verification of permitted software load and permitted functions.
AU-1
AU-6
AU-6(1)
AU-6(2)
AU-6(3)
AU-6(4)
AU-6(7)
X X X
RZ-OBJ-105 RZ-HC-126 The RZ nodes mark time stamps on audit records, and those RZ internal system clocks are synchronized to an authoritative time source. AU-8 (1) X X X
Data Protection
RZ-OBJ-106 RZ-DP-100

The internetwork supports SVPN data traffic connections between edge interfaces.

SC-8 - X -
RZ-OBJ-106 RZ-DP-101

An RZ supports SVPN data traffic connections between ZIPs.

SC-8 X X -
RZ-OBJ-106 RZ-DP-103

Traffic at all sensitivity levels may be handled by an RZ. However, data protection measures may be required depending on the security categorization and the results of a TRA.

Data protection services may be applied at either the network layer or higher layers, depending on the implementation requirements.

SC-8 X X -
RZ-OBJ-106 RZ-DP-104 Where encryption or digital signature is required, products (whether software, firmware, or hardware) must incorporate a Cyber Centre approved algorithm and Cyber Centre approved key management processes, such as those products validated to FIPS 140 2 (or subsequent FIPS 140 releases) through the CMVP. SC-13 X X X
RZ-OBJ-106 RZ-DP-105 Data encryption is used when partially sensitive (i.e. Protected B) information is exchanged with end systems in other zones, or where portions of the internetwork are outsourced to a network service provider. AC-18 (1)
SC-8
X X

Annex D - Baseline Security Requirements for a Highly Restricted Zone

Foreword

ITSP.80.022 Baseline Security Requirements for Network Security Zones V2: Annex D – Highly Restricted Zone is an UNCLASSIFIED publication.

This version of Annex D supersedes previous versions of the document.

Effective date

This publication takes effect on January 12, 2021.

Revision history

Revision Amendments Date
1 Version 2 released January 12, 2021.

Annex D Baseline Security Requirements for a Highly Restricted Zone

D.1 Introduction

This annex includes the baseline security requirements for a highly restricted zone (HRZ). An HRZ is designed for enterprise platform and application services and client enclaves that require the highest levels of protection.

An HRZ provides a tightly controlled network environment for three types of services:

  1. Safety critical applications (i.e. applications that have high availability and integrity requirements to prevent injury to human health or safety if the IT systems are compromised);
  2. Partially sensitive information (i.e. business or personal information categorized up to Protected B) and unclassified information that is collected in an extensive repository, which, if compromised, has an injury level of high; and
  3. Highly sensitive information (i.e. business or personal information categorized as Protected C) and classified information (e.g. Confidential, Secret, or Top Secret information of national interest to Canada).

This annex includes the requirements for an HRZ for the first two service types mentioned above. Email or call our Contact Centre for guidance on requirements for an HRZ that processes classified information and information categorized as highly sensitive (Protected C).

D.2 HRZ Reference Model

An HRZ provides a purpose specific private network environment under the single or shared control of an organization. An HRZ’s network security controls sufficiently protect high availability applications from denial-of-service (DoS) attacks. By using a defence in depth approach to security and increasing the robustness levels of security mechanisms, an HRZ can mitigate threat actors categorized up to and including the Td5 level threats. Footnote 14

Interfaces to all public services should be justified by the information system security implementation process (ISSIP) and implemented through a restricted zone (RZ) and then through an operations zone (OZ) to a public access zone (PAZ). Access to other organizations may be provided through interfaces to peer HRZs or RZs. Interfaces to sensitive services or repositories should be implemented through tightly controlled interfaces provided by zone interface points (ZIPs).

This section describes a model for an HRZ that is based on the general network security zone reference model. An HRZ includes the components listed in Table 13.

Table 13: HRZ Components

Component Description
Internetwork Provides the internal network for an HRZ to aggregate and distribute traffic between end systems and ZIPs.
Internal boundary systems (IBSs) Provide the means to control and monitor traffic between connected internetworks if more than one internetwork is implemented.
End systems Locally process and store organizational information.

Figure 11 depicts a logical view of an HRZ and its connection to other zones. To simplify the diagram, the management zone (MZ) and the MZ connections are not shown. See Annex E for MZ requirements and connection recommendations.

As in the case of the shared end system shown in Figure 11, where a node is shared between two zones, both network security zone authorities need to agree on the node’s management and oversight.

As described in Annex F, a ZIP provides the interface between HRZ entities and other zones. The ZIPs provide ingress and egress controls on traffic flows at the points where the HRZ connects to other zones.

Figure 11: HRZ Logical Topology

Long description immediatly follow
Long description

Figure 11 depicts a logical view of an HRZ and its connection to other zones. To simplify the diagram, the management zone (MZ) and the MZ connections are not shown.

D.3 HRZ Security Objectives

In general, an HRZ’s target security state is a tightly controlled network environment that is suitable for sensitive enterprise platform and application services and client enclaves that require higher levels of protection. These objectives are applicable to the following two types of services:

  • Safety-critical applications (i.e. applications that have high availability and integrity requirements to prevent injury to human health or safety if the IT systems are compromised); and
  • Partially sensitive information (i.e. personal or business information categorized as up to Protected B) and unclassified information that is collected in an extensive repository, which, if compromised, has an injury level of high.

An HRZ is characterized by rigorous network and host configuration controls and carefully controlled traffic flow. An HRZ’s traffic control measures are designed to contain security failures.

Each objective and requirement specified in this annex is labelled according to the following notation conventions:

  • The first set of letters refers to the zone (HRZ).
  • The second set of letters designates either an objective (OBJ) or a requirement (REQ).
  • Requirements are grouped into the following categories, as applicable:
    • Network interface (NI);
    • Traffic control (TC);
    • Network configuration (NC);
    • Host configuration (HC); and
    • Data protection (DP).
  • Each objective or requirement is sequentially numbered within its group.

Note: Objectives and requirements are not sequential, as some requirements have been removed or changed from the previous versions of this document.

D.3.1 Traffic Control Objectives

[HRZ-OBJ-100] An HRZ should protect the integrity and the availability of end systems attached to the zone by preventing the spread of malicious network traffic, including network traffic, originating from a small population of system staff or from compromised applications. An HRZ has the following objectives:

  • Prevent threat actors categorized up to and including the Td5 threat level from carrying out network based DoS attacks (e.g. SYN flood, distributed DoS [DDoS] attack) on end systems;
  • Reduce the impact on end systems if other threat sourcesFootnote 15 carry out network-based DoS attacks;
  • Prevent threat actors categorized up to and including the Td5 threat level from using network intrusions (e.g. attaching an unauthorized device to an existing interface, adding an unauthorized edge interface) to access end systems;
  • Reduce vulnerability of end systems to network intrusions carried out by all other threat sources;
  • Contain the impact of a compromised end system;
  • Prevent threat actors categorized up to and including the Td5 threat level from exploiting end systems as staging points for attacks on other systems;
  • Prevent all other threat sources from exploiting end systems as staging points for attacks on other systems;
  • Prevent the spread of malicious traffic from other zones to an HRZ; and
  • Stop the spread of malware.

Network security measures are limited in their ability to protect end systems from compromises through valid application interfaces. Platform, application, and operational security measures can address the risks associated with these types of threats. The only malicious network traffic expected to occur within an HRZ would come from the system staff or any compromised applications.

[HRZ-OBJ-101] An HRZ should provide the ability to continuously assess traffic at the interfaces to neighbouring zones (e.g. other HRZs, RZs, and MZs) and validate assumptions concerning the security environment provided by neighbouring zones.

[HRZ-OBJ-102] An HRZ should permit enhancements to security measures, such as the following, as a response to increased threat levels (e.g. time of crisis):

  • Flexible and dynamic traffic controls based on communities of interest; and
  • Increased status monitoring.

[HRZ-OBJ-103] The RZ and the OZ implement safeguards that protect against malicious network traffic originating from public networks. However, there are residual risks from the other zones that should be addressed by the HRZ through the following objectives:

  • Reduce an HRZ’s vulnerability to attacks originating from compromised remote access and extranet end systems;
  • Reduce an HRZ’s vulnerability to malicious traffic from compromised service delivery application servers in the other zones by limiting these servers’ access to designated resources and protocols;
  • Reduce an HRZ’s vulnerability to attacks originating from compromised hosts in other zones; and
  • Protect an HRZ from failures in other zones’ traffic control measures, including intrusions through other zones’ internetworks.

D.3.2 Network Availability and Integrity Objectives

[HRZ-OBJ-104] An HRZ should protect the integrity and the availability of network services by reducing their susceptibility to a variety of attacks. To protect these network services, an HRZ has the following objectives:

  • Filter malicious attacks from outside of an HRZ to reduce the network services’ vulnerability to DoS attacks carried out by threat sources;
  • Eliminate vulnerability to network intrusions (e.g. attaching an unauthorized device to an existing interface, adding an unauthorized edge interface, or compromising an attached end system) from up to and including Td5 threat actors;
  • Reduce the network services’ vulnerability to network intrusions carried out by all threat sources;
  • Prevent threat actors categorized up to and including the Td5 level from exploiting end systems as staging points for attacks on network services; and
  • Prevent other threat sources from exploiting end systems as staging points for attacks on network services.

D.3.3 Data Protection Objectives

[HRZ-OBJ-105] An HRZ should protect zone traffic from being intercepted by threat actors categorized up to and including the Td5 level. An HRZ should also detect when traffic is intercepted by other threat sources.

[HRZ-OBJ-106] An HRZ should support the following measures to protect the confidentiality and the integrity of data:

  • Secure virtual private network (SVPN) within the internetwork;
  • SVPN as an optional data service; and
  • Upper layer security protocols.

Employees from another organization may be required to securely access network services and their home networks. In these situations, temporary access through an access point located in a boardroom, or permanent access for employees assigned to the host organization may be required.

D.4 HRZ Baseline Security Requirements

This section describes the baseline security requirements for an HRZ. These requirements, which are listed in Table 14, are categorized by operational requirement (i.e. network interface, traffic control, network configuration, host configuration, and data protection). To achieve all the security objectives for an HRZ, as detailed above, you should implement the complete set of security requirements.

These requirements are the minimum set of security requirements for this zone. Consult the ITSG 33 [4] controls referenced in this table to determine whether any additional technical, management, and operational mechanisms are required to mitigate against expected Td5 level threats.

Table 14: HRZ Baseline Security Requirements

Objective Number Requirement Number Zone Requirement Related ITSG 33 Control IBS Internetwork End System
Network Interfaces
HRZ-OBJ-100 HRZ-NI-100 All network paths between an HRZ and other zones pass through a ZIP. SC-7 X X -
HRZ-OBJ-103 HRZ-NI-102

An HRZ does not have direct network connections to a PZ.

All network paths destined for, or originating from, a PZ (e.g. Internet) pass through a PAZ.

SC-7 (8) X X -
HRZ-OBJ-103 HRZ-NI-103

An HRZ internetwork is a logically separate network that maintains traffic interfaces only with:

  • ZIPs;
  • IBS(s) to other internetwork(s); and
  • HRZ end systems.
AC-4 - X -
HRZ-OBJ-103 HRZ-NI-105 IBSs and internetwork components support the attachment of network-based intrusion detection sensors (e.g. monitors) and the collection of data from these sensors. SI-4 (4) X X -
Traffic Control
HRZ-OBJ-102 HRZ-TC-102

In the event of an emergency or an increased threat level, an HRZ can respond quickly to heightened security levels as authorized to do so. For example, an HRZ can improve the network security posture by increasing the level of security for the following measures:

  • Filtering;
  • Monitoring (active and passive);
  • Protecting the continuous delivery of critical services (e.g. reconfigure or block non essential services, if required); and
  • Auditing.

Before implementing any of these measures, test them carefully to ensure that they cannot be exploited to cause a DoS.

Personnel are trained and authorized to initiate responses to heightened security levels.

AC-4
AU-6
IR-4
SC-7
SC-10
SI-4
X X X
HRZ-OBJ-103 HRZ-TC-103 The identity of both zones is authenticated prior to communication between them. IA-3 X X -
HRZ-OBJ-100 HRZ-TC-104 The internetwork provides an access control service that enforces access control policies between edge interfaces, which are based on network layer source, network layer destination, transport protocol, and transport layer service interface. AC-3
AC-4
SC-10
- X -
HRZ-OBJ-100 HRZ-TC-105

An HRZ network security zone authority defines the requirements for an HRZ internetwork access control service that is based on the following principles:

  • The access control policy is constructed to deny all traffic that is not explicitly permitted;
  • The access control policy supports community of interest separation (i.e. where network traffic is divided into natural communities of interest, the access control policy enforces these natural traffic flows);
  • The access control policy restricts available network paths to vulnerable or sensitive end systems (e.g. test and development sub-networks and application servers supporting public applications);
  • The access control policy is configured to limit available network paths for end systems accessible by extranets;
  • The access control policy limits access to other end systems by remote access hosts if the HRZ network security zone authority permits connection to the HRZ by remote access hosts with operating systems that do not separate user and administrator roles; and
  • The access control policy supports separation between classes of service if the internetwork provides more than one class of service.
AC-2
AC-3
AC-4
AC-17
IA-3
SC-7
X X X
HRZ-OBJ-104 HRZ-TC-106 The internetwork implements mechanisms to ensure non-interference between classes of service if the HRZ supports more than one class of service. AC-4 - X -
HRZ-OBJ-103 HRZ-TC-107 The internetwork uses an addressing model to detect and diagnose malicious traffic. CA-3
SC-7
SI-3
- X -
HRZ-OBJ-105 HRZ-TC-108 An HRZ supports SVPN traffic between any pair of edge interfaces. SC-8 X X -
HRZ-OBJ-104 HRZ-TC-110

The network security zone authority defines an access control policy, which is enforced by the access control service, that is based on the following principles:

  • The access control policy denies all traffic unless it is explicitly permitted;
  • All outgoing traffic is restricted to destination addresses corresponding to designated proxy servers in a PAZ;
  • Extranet hosts are restricted to a defined set of internal addresses, which contain the resources required by the extranet;
  • Remote access clients are restricted to a defined set of internal addresses if a network security zone authority permits remote access hosts with open configurations (see host configuration); and
  • Traffic to and from servers is restricted to addresses and protocols necessary to support communication with the servers.
AC-4
SC-7 (5)
SC-7 (8)
SC-7 (11)
X X X
HRZ-OBJ-100 HRZ-TC-121 Audit relevant traffic control and data flow information is recorded in the security audit log, according to security audit service requirements. AU-1
AU-2
X X -
Network Configuration
HRZ-OBJ-104 HRZ-NC-100 The HRZ network configuration is monitored to detect additions, deletions, or changes to edge interfaces. Unauthorized changes are reported to an HRZ network security zone authority. AU-1
CM-2
CM-3
SI-4
X X -
HRZ-OBJ-104 HRZ-NC-101 The HRZ edge interface are registered with an HRZ network security zone authority. CM-8 - X -
HRZ-OBJ-104 HRZ-NC-103 An HRZ network security zone authority periodically verifies the network topology. AU-1
CM-2
CM-9
X X -
HRZ-OBJ-105 HRZ-NC-104 An HRZ network security zone authority periodically assesses the network configuration for unauthorized external interfaces. AU-1
SI-4 (4)
X X -
HRZ-OBJ-104 HRZ-NC-105 Only authenticated and authorized administrators can manage HRZ nodes and only from an HRZ MZ. AC-5
IA-5
- - X
HRZ-OBJ-104 HRZ-NC-106 Edge interface addresses are distinct and dedicated. SC-7 - X -
HRZ-OBJ-105 HRZ-NC-107 Edge interface addresses are visible to other internal zones, but they are not visible to a PZ. SC-7 - X -
HRZ-OBJ-104 HRZ-NC-108 A change to an HRZ edge interface’s address assignment is a configuration change that requires approval by the HRZ network security zone authority. CM-3
CM-9
- X -
HRZ-OBJ-104 HRZ-NC-109 An HRZ network security zone authority maintains current configuration information for all interfaces within the internetwork. CM-2
CM-6
- X -
HRZ-OBJ-104 HRZ-NC-110 Changes to an HRZ are approved by an HRZ network security zone authority before they are implemented. CM-3 (4)
CM-9
X X X
HRZ-OBJ-104 HRZ-NC-111 Connections within an HRZ have established security associations. All communications are authenticated (either explicitly or implicitly) within the context of these security associations. The permitted security associations are determined by the traffic control requirements. AC-4
IA-3
SC-23
X X -
HRZ-OBJ-104 HRZ-NC-112

Internetwork edge interfaces are authenticated to each other in one of the following two ways:

  • Cyber Centre approved cryptographic authentication mechanisms; and
  • Physical controls over the edge interfaces and all media connecting these interfaces.
IA-3 (1) - X -
HRZ-OBJ-104 HRZ-NC-121 Service level agreements for outsourced networks require approval from an HRZ network security zone authority approval for any changes to internetwork interfaces that are controlled by a network service provider. CP-8 X X X
HRZ-OBJ-104 HRZ-NC-122

Service level agreements for outsourced networks should include following requirements:

  • A network service provider must provide evidence that the security controls used to enforce the security within the internetwork core are effective;
  • All security incidents that could impact the HRZ are reported to the HRZ network security zone authority; and
  • A network service provider gives an HRZ network security zone authority the capability to verify the effectiveness of the controls.
CP-8 X X X
HRZ-OBJ-104 HRZ-NC-123 End systems maintain the integrity of network interfaces with organization zones while connected to an HRZ. The HRZ end systems are not permitted to dual home, tunnel split, or use other shared network paths with a PZ. SC-7 (7) - - X
Host Configuration
HRZ-OBJ-104 HRZ-HC-100 An HRZ network security zone authority maintains a node and host configuration policy that is consistent with applicable baseline security requirements, standards, and guidance. This policy applies to all hosts attached to the zone. CM-1
CM-2
X X X
HRZ-OBJ-104 HRZ-HC-101

The node and host network configuration policy includes the following requirements:

  • A specification of prohibited and mandated networking software and hardware configurations; and
  • Minimum maintenance procedures for all networking software.
CM-1
CM-6
CM-7
MA-2
MA-6
SI-2
X X X
HRZ-OBJ-104 HRZ-HC-103

Regular vulnerability assessments (VAs) of all nodes and hosts are conducted to assess trends in the effectiveness of the host configuration policy. The frequency of the VAs is enough to support trend analysis.

All VA results are managed within the framework of continuous risk management and provide feedback to the security assessment and authorization (SA&A) process.

CA-7
RA-5
X X X
HRZ-OBJ-104 HRZ-HC-104 All nodes invoke controls that provide continuous protection against malware at start-up. SI-3
SI-7 (1)
X X -
HRZ-OBJ-104 HRZ-HC-105 All hosts that provide applications to permit client access to public resources (e.g. Internet web browsers and email clients) use operating systems that separate duties and administration and are configured to operate any applications that provide access to public resources in user mode. AC-5
AC-6
X X X
HRZ-OBJ-104 HRZ-HC-106 System and network management processes and technology is implemented within an HRZ to detect changes in node configurations. SI-7 (7) X X -
HRZ-OBJ-104 HRZ-HC-107

Regular back-ups of system files and system configuration parameters are performed for every node contained in an HRZ.

The frequency and the retention period of these back-ups are consistent with business needs.

CP-9 X X -
HRZ-OBJ-104 HRZ-HC-108 The failure of an HRZ node does not result in the compromise of its resources or any connected network’s resources. SC-24 X X -
HRZ-OBJ-104 HRZ-HC-109 HRZ nodes and hosts are within an area that meets the physical security requirements as determined by the ISSIP. GC departments must also align with the Operational Security Standard on Physical Security [16]. PE-18 X X X
HRZ-OBJ-104 HRZ-HC-111 Operating systems and necessary applications for all nodes are hardened based on documented best practices. CM-6
CM-7
X X -
HRZ-OBJ-106 HRZ-HC-112 SVPN products, if used, are validated to FIPS 140-2, at a minimum of Security Level 2, through the Cyber Centre’s Cryptographic Module Validation Program (CMVP). SC-13 X X X
HRZ-OBJ-104 HRZ-HC-113 Nodes are physically secured to limit access to only authorized personnel who have a need to access the equipment, according to the principles of least privilege and need to know. PE-2
PE-3 (1)
PE-18
X X -
HRZ-OBJ-100 HRZ-HC-114 An end system includes a personal firewall, a configuration integrity mechanism capable of identifying changes to the configuration and notifying the end system administrator. SC-7 (12)
SI-7
- - X
HRZ-OBJ-104 HRZ-HC-115

A shared end system, whether shared permanently or periodically, complies with the following requirements:

  • The use of an operating system that supports the separation of users and administrators (i.e. enforces the principles of separation of duties and least privilege);
  • Changes to network configuration should require administrative privileges;
  • The end system configuration, and the procedures for maintaining that configuration, are approved by an HRZ network security zone authority; and
  • The end system is subject to regular VAs (results are provided to the threat risk assessment [TRA] process). An HRZ network security zone authority determines the frequency of the VAs and documents the frequency in the zone’s VA procedures.
AC-5
AC-6 (1)
AC-6 (5)
CM-3
- - X
HRZ-OBJ-104 HRZ-HC-116 An end system undergoes the SA&A process before it is attached to an edge interface. CA-1
CA-6
- - X
HRZ-OBJ-105 HRZ-HC-122 Host based intrusion detection sensors are placed on all critical hosts. SC-7(12) - - X
HRZ-OBJ-105 HRZ-HC-123 HRZ nodes generate and maintain audit log records, as required by the security audit service. AU-2 X X X
HRZ-OBJ-105 HRZ-HC-124 HRZ nodes ensure that locally stored security audit log records are accessible to authorized security audit administrators, as required by the security audit service. AU-6(3)
AU-6(4)
X X X
HRZ-OBJ-105 HRZ-HC-125

Each HRZ node is subject to regular configuration audits. The network security zone authority determines the frequency of these audits and documents the frequency in the configuration management procedures for an HRZ.

The frequency of these audits is enough to identify configuration errors. The configuration audit includes, but is not limited, to the following checks:

  • Verification of node configuration against network topology design;
  • Verification of hardware devices and physical interfaces; and
  • Verification of traffic control configuration (e.g. permissions and access controls).

Verification of permitted software load and functions.

AU-1
AU-6
AU-6(1)
AU-6(2)
AU-6(3)
AU-6(4)
AU-6(7)
X X X
HRZ-OBJ-105 HRZ-HC-126 The HRZ nodes mark time stamps on audit records. The HRZ internal system clocks are synchronized to an authoritative time source. AU-8 (1) X X X
Data Protection
HRZ-OBJ-106 HRZ-DP-100 The internetwork can support SVPN data traffic connections between edge interfaces. SC-8 - X -
HRZ-OBJ-106 HRZ-DP-101 An HRZ can support SVPN data traffic connections between ZIPs. SC-8 X X -
HRZ-OBJ-106 HRZ-DP-103 Although traffic at all sensitivity levels may be handled by an HRZ, data protection measures may be required depending on the security categorization and the TRA results. Data protection services may be applied at either the network layer, or higher layers, depending on the implementation requirements. SC-8 X X -
HRZ-OBJ-106 HRZ-DP-104 Where encryption or digital signature is required, products (whether software, firmware, or hardware) must incorporate a Cyber Centre approved algorithm and Cyber Centre approved key management processes, such as those products validated to FIPS 140-2 (or subsequent FIPS 140 releases) by the Cyber Centre through the CMVP. SC-13 X X X
HRZ-OBJ-106 HRZ-DP-105 Data encryption is used when partially sensitive personal or business (i.e. Protected B) information is exchanged with end systems in other zones, or where portions of the internetwork have been outsourced to a network service provider. AC-18 (1)
SC-8
X X X

Annex E - Baseline Security Requirements for a Management Zone

Foreword

ITSP.80.022 Baseline Security Requirements for Network Security Zones V2 – Annex E – Management Zone is an UNCLASSIFIED publication.

This version of Annex E supersedes previous versions of the document.

Effective date

This publication takes effect on January 12, 2021.

Revision history

Revision Amendments Date
1 Version 2 released. January 12, 2021.

Annex E Baseline Security Requirements for a Management Zone

E.1 Introduction

This annex includes a set of baseline security requirements for a management zone (MZ), which is a special environment for concentrations of management end systems. This zone is used to separate management services and activities from business services and activities.

An MZ is a physically isolated zone with a build robustness equivalent to a restricted zone (RZ) or a highly restricted zone (HRZ), as determined by the results of the information system security implementation process (ISSIP). An MZ provides IT and security administrators with a dedicated, isolated administration network for configuring and monitoring network infrastructures and IT services. An MZ also provides the infrastructure, the platform, and the application for security administrators and operators to manage associated networks while minimizing the levels of risk related to interception and compromise.

This annex describes the following two architectural approaches to implementing an MZ:

  • Isolated MZ approach: Implement multiple MZs, but each MZ is dedicated to managing one zone and has no direct network connections to other MZs; and
  • Consolidated MZ approach: Implement a single MZ instance, which enables the management of multiple zones.

Refer to your ISSIP results to decide whether to use an isolated or a consolidated MZ architecture. Based on these results, MZ instances may be virtualized if the following two conditions are met:

  • The assurance level of the logical separation is satisfactory; and
  • The stakeholders recognize, and are willing to accept, the risks associated with potential compromises of virtualized MZs.

An MZ provides a unique and isolated network environment under the single or shared control of an organization or a contracted entity.

An MZ provides a network security environment that delivers enough protection to support the deployment of high availability management services.

E.2 MZ Reference Model

This section describes an MZ model that is based on the general network security zone reference model. An MZ separates management services and activities from business services and activities. Executing management activities in a separate environment comes with the following benefits:

  • The level of risk relating to a compromised MZ, which could result from vulnerabilities (including insider threats) in other zones, is reduced;
  • Network security zone authorities can better detect and investigate network compromises; and
  • IT administrators can better maintain, recover, and restore IT services.

An MZ has three classes of components, which are listed in Table 15.

Table 15: MZ Components

Component Description
Internetwork components Provide networking services for the MZ to aggregate and distribute traffic between MZ end systems.
Internal boundary systems (IBSs) Provide the means to control and monitor traffic between connected internetworks if more than one internetwork is implemented. For example, if multiple RZs are implemented, multiple internetworks within the RZ MZ should be implemented to interface with the associated RZs.
MZ end systems Locally process and store IT and security management information for a specific zone.

E.3 MZ Architectural Approaches

This section covers the following two architectural approaches for implementing an MZ:

  • Isolated MZ approach; and
  • Consolidated MZ approach.

In the isolated MZ approach, multiple MZs are implemented, and each MZ manages one type of zone. The isolated MZ approach is recommended for sections of an organization that have business requirements to process sensitive information. In the consolidated MZ approach, one MZ instance is implemented to manage multiple zones in an IT environment. You should use the results of the ISSIP process to determine whether using a consolidated MZ approach is appropriate.

Figure 12: MZ Architectural Approaches

Long description immediatly follow
Long description

Figure 12 depicts two architectural approaches to implementing an MZ: an isolated MZ approach and a consolidated MZ approach. In the isolated MZ approach, multiple MZs are implemented, and each MZ manages one type of zone. In the consolidated MZ approach, one MZ instance is implemented to manage multiple zones in an IT environment.

E.3.1 Isolate Management Zone Architecture

The isolated MZ model is the recommended security approach for information systems processing sensitive information. In general, the robustness level of an isolated MZ is higher than the robustness level of a consolidated MZ.

In the isolated MZ approach, separate MZ instances are implemented to manage network security zones. The separate MZs interact with the zones (i.e. public access zone [PAZ], operations zone [OZ], RZ or HRZ) through the zone interface points (ZIPs) that are specifically deployed to support the management functions. For example, the OZMZ communicates with the OZ through the OZ-MZ ZIP, and the RZMZ communicates with the RZ through RZ-MZ ZIP. These MZ connected ZIPs are separate deployments from the ZIPs that support the communications between the network security zones (e.g. OZ PAZ ZIP, RZ OZ ZIP). The MZ connected ZIPs provide ingress and egress controls on traffic flows at the points where the MZs connect with their respective zones.

Management traffic from MZs to the zones should be physically isolated from the data traffic (i.e. separated network infrastructure and out of band management). MZs should never have direct PZ network connectivity.

Figure 13 illustrates the MZs, and the respective ZIPs, in an isolated approach. For example, the PAZMZ interfaces with a PAZ through the PAZ-MZ ZIP. The RZ interfaces with an OZ through the RZ-OZ ZIP.

Figure 13: Isolated MZ Approach

Long description immediatly follow
Long description

Figure 13 illustrates the MZs, and the respective ZIPs, in an isolated approach. For example, the PAZMZ interfaces with a PAZ through the PAZ-MZ Zip. An RZ interfaces with an OZ through the RZ-OZ ZIP.

In an isolated MZ approach, virtualization of the MZs (e.g. PAZ MZ, OZ MZ and RZ MZ), as illustrated in Figure 14, could be considered if the assurance of the logical separation provided by the underlying platform meets the assurance level identified by the ISSIP process.

The MZ connected ZIPs could be virtualized based on the results of the ISSIP process. The data path ZIPs could also be virtualized. However, the virtualization of the MZ connected ZIPs and the data path ZIPs should be conducted on physically separated platforms (see Annex F for detailed ZIP guidance).

Figure 14: MZ Virtualization

Long description immediatly follow
Long description

Figure 14 illustrates MZ virtualization in an isolated MZ approach.

E.3.2 Consolidated MZ Architecture

The consolidated MZ approach implements an MZ that spans multiple zones (see the left portion of Figure 14 above).

The PAZ contains Internet-facing services and is the most vulnerable zone in network security zoning. The PAZ is the most likely zone to be compromised by deliberate threat actors. These threat actors may then traverse, gain access to, and compromise the consolidated MZ management services and take control of other zones. Refer to the results of the ISSIP to determine if it’s appropriate to use a consolidated MZ architecture.

E.4 Separation of Administrative Roles

There are specific security concerns relating to the management of networks, virtualization, databases, and applications due to the potential for unparalleled access to large concentrations of sensitive data and administrative privileges. Sophisticated threat actors who cannot gain logical access (e.g. through the Internet) seek to exploit other access modes, including management personnel and management networks.

Management roles should be identified, and their span of control and access should be limited, especially if large quantities of sensitive data are accessible. The separation of roles and duties mitigates against the abuse of authorized privileges and reduces the risk of malicious activity. The principle of least privilege should also be considered to ensure roles, system accounts, and processes operate at privilege levels no higher than necessary to accomplish required functions.

Figure 15: Management Roles

Long description immediatly follow
Long description

Figure 15 identifies some key roles that require management access in an IT environment, including infrastructure management, VM management, security management, application management, and OS, server, and database management.

Figure 15 identifies some key roles that require management access in an IT environment. These roles are described in Table 16.

Table 16: Management Roles

Role Description
Infrastructure management Configure core routing and switching infrastructure, provide and monitor hardware platforms.
Application and operating system management Configure, provide, and manage the operating system, the directory, and the server management, as well as application and database management.
Security management Configure and maintain security appliances and applications, collect, analyze, and protect security event logs.
Hypervisor management Configure, provide, and manage virtual platforms, which may include provisioning baseline resident operating systems and applications (e.g. databases, web servers).

The hypervisor management interface is one of the most critical interfaces within a virtualized infrastructure. Using this interface and associated management software, it is possible to physically and virtually shut servers down, migrate virtual machines, take virtual machine snapshots, and insert virtual machines into IT operations. Compared to traditionally hardware-based IT operations, provisioning a virtual infrastructure can be fast, flexible, and easy. However, these characteristics also make the hypervisor administrative function a significant target to threat actors and can make it difficult to detect the unauthorized access to information or the insertion of malicious content.

Hypervisor management should be a strictly segregated role (i.e. a dedicated hypervisor management system per network security management zone). Further segregation of roles may also be necessary. Segregating the role limits the span of control of each hypervisor management system. Each of the associated network security zone authorities must approve any hypervisor management activities across multiple zones.

There are additional management roles, such as storage management, service management, and account management. Your organization may wish to refine the management roles based on your business needs for security and your understanding of the threats and the risks in their IT environments. The identified management roles should be assigned to distinct entities who would only have enough privileges to perform assigned administrative duties within a clearly defined boundary of responsibilities in an IT environment.

E.5 Isolation of MZs

To ensure the availability of management services and to better protect MZs from interference and tampering that originates in the zones they manage, consider the following factors:

  • MZs should not share any network layer infrastructure with any other zones, including the zones they manage;
  • MZs should not share any data link layer infrastructure with any other zones, including the zones they manage; and
  • MZs should not share any physical layer infrastructure with any other zones.

MZs should be implemented on infrastructure that is physically separated from the managed zones and other MZs (i.e. each MZ is on a separate physical infrastructure). However, based on the results of the ISSIP, security architects may choose to implement the MZs, other than the PAZMZ, on the same physical infrastructure and use virtualization technologies to separate them.

In the isolated MZ approach (see Figure 12) the PAZMZ is always physically separated from other MZs due to its proximity to the PZ.

In MZ architectures that use virtualization technologies to separate the MZs, security assessments must demonstrate that there is enough robustness in the separation mechanisms.

Whether the MZs are physically or logically separated, each zone specific MZ should only communicate to and accept connections originating from the zone that it manages. For example, an OZMZ can communicate to its OZ, but not an RZ or a PAZ. An OZMZ only accepts communications originating from its OZ, not an RZ or a PAZ.

E.6 Management Approaches

This section describes the different management approaches depicted in Figure 16.

Figure 16: Management Approaches

Long description immediatly follow
Long description

Figure 16 shows the different management approach, such as direct console management, remote management, in-band management, and out-of-band management.

E.6.1 In Band Management

The network infrastructure is managed via the data network. The management traffic traverses on the same network as the operational data traffic and terminates on the network adapters that are configured for the operational data. Cryptography may be used to protect the confidentiality and the integrity of the management traffic. However, if there are any issues with the network, the availability of the management traffic to the infrastructure may be affected. For example, if there’s a network congestion issue, caused by a misconfiguration or a DoS attack, it may be difficult to respond and reconfigure the network infrastructure because the network components are busy, and the bandwidth is consumed. The management traffic is essentially blocked. The administrators can no longer reach and manage the network infrastructure.

E.6.2 Out of Band Management

Separate management network infrastructures and dedicated network adapters should be implemented to enable out of band management of the IT network infrastructure in the zones. Network and security management traffic initiated from the MZs traverse over separate management network infrastructures to the zones and terminates on the network adapters that are configured and dedicated for management purposes. For virtualized environments in which dedicated network adapters are not available, management isolation should be enforced logically in the network stack. However, the availability of management traffic may be at risk.

Out of band management is not dependent on the business activity data network. Out-of-band management systems are unaffected by data network failures or congestion. These systems are less susceptible to compromises originating from the non management networks. These systems improve a network security zone authority’s ability to detect and investigate network compromises. They also improve the IT administrators’ ability to maintain, recover, and restore IT services.

E.6.3 Direct Console Management

Direct console management, sometimes called console terminal access, refers to the management of resources through a direct connection rather than over the network. The direct connection can be through keyboard video mouse (KVM) ports, a KVM switch, a serial port, a console port, or a network adapter of IT systems using a cross over cable.

Direct console management can be from a console or a fully functioning administrative workstation. This management approach requires physical access to the IT systems residing in the zones. Direct console management can be used as a back up management mechanism if the data network or management networks are unavailable. Physical security should also be considered to prevent threat actors from using direct console management to compromise critical IT systems.

E.6.4 Remote Management

Remote management refers to the off site management of IT systems. Remote management should be carried out by having approved, dedicated, and hardened management hosts authenticate (i.e. device authentication and administrative role authentication) to an MZ from approved locations, using approved means. Decisions to use remote management systems should be based on your ISSIP results.

Remote management hosts should connect and authenticate through a RMAZ as shown in Figure 17 below. An RMAZ has the same networking components and characteristics as a PAZ, but it operates on a physically isolated infrastructure. Services in an RMAZ are dedicated to authenticating and mediating connections to an MZ. If remote management is used for more than one zone, a separate RMAZ should be set up for each managed zone.

Figure 17: Logical MZ Architecture with Remote PAZ Management

Long description immediatly follow
Long description

Figure 17 depicts a logical MZ architecture with remote PAZ management. Icons and colours are used to indicate separate physical ZIP deployments.

E.7 MZ Security Objectives

An MZ is a physically isolated zone that is a unique environment for the concentration of management end systems. An MZ is characterized by rigorous network configuration controls and carefully controlled traffic flows. The target security state for all MZ instances (i.e. PAZMZ, OZMZ, RZMZ and HRZMZ) is to mitigate attacks conducted by threat actors categorized up to and including the Td5 level.Footnote 16 MZ security measures should also reduce the impact of attacks from threat actors categorized at the Td6 levelFootnote 17 and above.

Each objective and requirement specified in this annex is labelled according to the following notation conventions:

  • The first set of letters refers to the zone (MZ).
  • The second set of letters designates either an objective (OBJ) or a requirement (REQ).
  • Requirements are grouped into the following categories as applicable:
    • Network interface (NI);
    • Traffic control (TC);
    • Network configuration (NC);
    • Host configuration (HC); and
    • Data protection (DP).
  • Each objective or requirement is sequentially numbered within its group, beginning at 100.

Note: Objectives and requirements are not sequential, as some requirements have been removed or changed from the previous versions of this document.

E.7.1 Traffic Control Objectives

[MZ-OBJ-100] An MZ should protect the integrity and the availability of the management end systems attached to the zone by preventing the occurrence of malicious network traffic. An MZ has the following traffic control objectives:

  • Prevent threat actors categorized up to and including the Td5 level from carrying out network based DoS attacks (e.g. SYN flood, DDoS attack) on management end systems;
  • Reduce the management end systems’ vulnerabilities to network-based DoS attacks carried out by all other threat sourcesFootnote 18;
  • Prevent threat actors categorized up to and including the Td5 level from using network intrusions (e.g. attaching an unauthorized device to an existing interface, adding an unauthorized edge interface) to access management end systems;
  • Reduce the management end systems’ vulnerabilities to network intrusions carried out by all other threat sources;
  • Contain the impact of a compromised management end system;
  • Prevent threat actors categorized as up to and including the Td5 level from exploiting management end systems as staging points for attacks on other systems;
  • Prevent all other threat sources from exploiting management end systems as staging points for attacks on other systems; and
  • Reduce the spread of malware.

Network security measures are limited in their ability to protect end systems from compromises through valid application interfaces. Use platform, application, and operational security measures to mitigate the risks associated with these threats.

[MZ-OBJ-102] An MZ should allow security measures enhancements, such as the following, to respond to increased threat levels (e.g. during a time of crisis):

  • Flexible and dynamic traffic controls; and
  • Increased status monitoring.

[MZ-OBJ-103] Zones and ZIPs use safeguards to protect against malicious network traffic that originates in public networks. However, the MZ needs to address the residual risks through the following objectives:

  • Reduce vulnerabilities to attacks that originate from compromised remote access and extranet end systems;
  • Reduce vulnerabilities to malicious traffic from compromised service delivery application servers in the zones by limiting these servers’ access to designated resources and protocols; and
  • Reduce vulnerabilities to attacks that originate from compromised hosts in the zones and to failures in zone traffic control measures, including intrusions through other zones’ internal access networks.

E.7.2 Network Availability and Integrity Objectives

[MZ -OBJ-104] An MZ should protect the integrity and the availability of management services by reducing their vulnerability to a variety of attacks. An MZ should have the following network availability and integrity objectives:

  • Reduce management services’ vulnerability to DoS attacks from all threat sources (e.g. dedicated adversaries, infrastructure insiders, and network users) by filtering malicious attacks from outside the MZ;
  • Eliminate vulnerability to network intrusions (e.g. attaching an unauthorized device to an existing interface, adding an unauthorized edge interface, or compromising an attached management end system) carried out by threat actors categorized up to and including the Td5 level;
  • Reduce vulnerabilities to network intrusions carried out by all other threat sources;
  • Prevent threat actors categorized up to and including the Td5 level from exploiting management end systems as staging points for attacks on other management services;
  • Prevent all other threat sources from exploiting management end systems as staging points for attacks on management services; and
  • Reduce the spread of malware.

E.7.3 Data Protection Services

[MZ -OBJ-105] An MZ should reduce the zone traffic’s vulnerability to being intercepted by threat actors categorized up to and including the Td5 threat level. An MZ should also detect whether the zone’s traffic is intercepted by other threat sources.

[MZ -OBJ-106] An MZ should support measures, such as the following, to protect the confidentiality and the integrity of data:

  • Secure virtual private network (SVPN) within the internetwork;
  • SVPN as an optional data service; and
  • Upper layer security protocols.

E.8 MZ Baseline Security Requirements

This section describes an MZ’s baseline security requirements, which are categorized by operational requirement (i.e. network interface, traffic control, network configuration, host configuration, and data protection).

To achieve all the MZ security objectives above, you should implement the complete set of baseline security requirements listed in Table 17. You should consult the referenced ITSG-33 [4] controls to determine whether additional technical, management, and operational mechanisms need to be implemented to mitigate against the expected Td5 threat level.

Table 17: MZ Baseline Security Requirements

Objective Number Requirement Number Zone Requirement Related ITSG 33 Control IBS Internetwork End System
Network Interface
MZ OBJ 100 MZ-NI-100 All network paths between an MZ and the zones they manage pass through ZIPs. SC-7 X X -
MZ-OBJ-103 MZ-NI-102 An MZ does not have direct network connections to a PZ. SC-7 X X X
MZ-OBJ-103 MZ-NI-103

To protect an MZ from interference and tampering, the MZ infrastructure is separate from the data path network infrastructure.

An MZ does not share the following infrastructure:

  • Any network layer infrastructure with any other zone;
  • Any data link layer infrastructure with any other zone; and
  • Any physical layer infrastructure with any other zone.
AC-4
SC-32
X X -
MZ-OBJ-104 MZ-NI-105 IBSs and internetwork components support the attachment of network based intrusion detection sensors (e.g. monitors) and the collection of data from these sensors. SI-4 (4) X X -
MZ-OBJ-100 MZ-NI-106 Zone specific MZs do not have network connections to each other (e.g. PAZMZ does not communicate with the OZMZ). AC-4 X X X
MZ-OBJ-100 MZ-NI-107 Zone specific MZ instances are implemented on separate infrastructures with either physical or logical separation mechanisms, which are based on the ISSIP results. AC-4
SC-7
SC-39
X X X
Traffic Control
MZ-OBJ-102 MZ-TC-102

In an emergency or an increased threat, the MZ responds quickly to heightened security levels, as authorized to do so. For example, the MZ can improve the network security posture by increasing the level of the following security measures:

  • Filtering;
  • Monitoring (active or passive);
  • Protecting the continuous delivery of critical services, (e.g. reconfigure or block non essential services if required); and
  • Auditing.

Before implementing these measures, test them carefully to ensure they cannot be exploited to cause a DoS.

Personnel are trained and authorized to initiate responses to heightened security levels.

AC-4
AU-6
IR-4
SC-7
SC-10
SI-4
X X X
MZ-OBJ-103 MZ-TC-103 The identity of both zones is authenticated before the zones can communicate. IA-3 - X -
MZ-OBJ-100 MZ-TC-104 The internetwork provides an access control service that enforces access control requirements between edge interfaces. This service is based on a network layer source, a network layer destination, a transport protocol, and a transport layer service interface. AC-3
AC-4
SC-10
- X -
MZ-OBJ-100 MZ-TC-105

An MZ network security zone authority defines requirements for an MZ internetwork access control service based on the following principles:

  • The access control policy denies all traffic that is not explicitly permitted;
  • The access control policy supports community of interest separation (i.e. where network traffic is divided into natural communities of interest, the access control policy enforces these natural traffic flows);
  • The access control policy limits available network paths for management end systems;
  • The MZ network security zone authority denies all connections to an MZ by remote access hosts that are not connections from an RMAZ; and
  • The access control policy supports separation between classes of service if the internetwork provides more than one class of service.
AC-2
AC-3
AC-4
AC-17
IA-3
SC-5 (3)
SC-7 (5)
SC-7 (11)
X X -
MZ-OBJ-104 MZ-TC-106 If an MZ manages more than one class of service, the internetwork implements mechanisms to ensure non interference between classes of service. AC-4
SC-5 (2)
- X -
MZ-OBJ-103 MZ-TC-107 The internetwork uses an addressing model that detects and diagnoses malicious traffic.
  • word
CA-3
SC-7
SI-3
- X -
MZ-OBJ-105 MZ-TC-108 An MZ supports SVPN traffic between any pair of edge interfaces. SC-8 X X -
MZ-OBJ-104 MZ-TC-110

An MZ network security zone authority defines an access control policy, which is enforced by the access control service, that is based on the following principles:

  • The access control policy denies all traffic unless it is explicitly permitted; and
  • Outgoing management traffic is restricted to destination addresses of the infrastructure of the zone which it manages.
AC-4
SC-7 (5)
SC-7 (8)
SC-7 (11)
X X X
MZ-OBJ-100 MZ-TC-121 Audit relevant traffic control and data flow information is recorded in the security audit log according to the requirements of the security audit service. AU-1
AU-2
- X -
Network Configuration
MZ-OBJ-104 MZ-NC-100 The MZ network configuration is monitored to detect additions, deletions, or changes to edge interfaces. Unauthorized changes are reported to an MZ network security zone authority. AU-1
CM-2
CM-3
SI-4
X X -
MZ-OBJ-104 MZ-NC-101 The MZ edge interfaces are registered with an MZ network security zone authority. CM-8 - X -
MZ-OBJ-104 MZ-NC-103 An MZ network security zone authority periodically verifies the network topology. AU-1
CM-2
CM-2 (1)
CM-9
X X -
MZ-OBJ-105 MZ-NC-104 An MZ network security zone authority periodically assesses the network configuration for unauthorized external interfaces. AU-1
SI-4 (4)
X X -
MZ-OBJ-104 MZ-NC-106 MZ edge interface addresses are distinct and dedicated. SC-7 - X -
MZ-OBJ-105 MZ-NC-107 MZ edge interface addresses are visible only to the zone to which the zone specific MZ is accountable. SC-7 - X -
MZ-OBJ-104 MZ-NC-108 A change to an MZ edge interface address assignment constitutes a configuration change and requires approval by an MZ network security zone authority. CM-3
CM-9
- X -
MZ-OBJ-104 MZ-NC-109 An MZ network security zone authority maintains current configuration information for all interfaces within the internetwork. CM-2
CM-6
- X -
MZ-OBJ-104 MZ-NC-110 Changes to an MZ are approved by a MZ network security zone authority before they are implemented. CM-3 (4)
CM-9
X X X
MZ-OBJ-104 MZ-NC-111 Connections within an MZ have established security associations. All communications are authenticated (either explicitly or implicitly) within the context of these security associations. The permitted security associations are determined by traffic control requirements. AC-4
IA-3
SC-23
X X -
MZ-OBJ-104 MZ-NC-112 Internetwork edge interfaces are authenticated to each other using Cyber Centre approved cryptographic authentication mechanisms. IA-3 (1)
SC-23 (5)
- X -
MZ-OBJ-104 MZ-NC-121 Service level agreements for outsourced networks require that any changes to internetwork interfaces that are controlled by network service providers must be approved by an MZ network security zone authority. CP-8 X X X
MZ-OBJ-104 MZ-NC-122

Service level agreements for outsourced networks include the following requirements:

  • The network service provider gives evidence of the effectiveness of the security controls used to enforce the security within the internetwork core;
  • All security incidents that could impact an MZ are reported to an MZ network security zone authority; and
  • The network service provider gives an MZ network security zone authority the capability to verify the effectiveness of the controls.
CP-8 X X X
MZ-OBJ-104 MZ-NC-123

An MZ allows only authorized administrators to remotely connect to MZ management end systems through an organization-controlled zone (i.e. RMAZ) if remote management is allowed.

The access is controlled and protected. Access is restricted by IP address, port, and protocol.

AC-2
AC-3
AC-17
IA-3
IA-5
X X X
Host Configuration
MZ-OBJ-104 MZ-HC-100 An MZ network security zone authority maintains a node and host network configuration policy that is consistent with applicable baseline security requirements, standards, and guidance. This policy applies to all nodes and hosts attached to the zone. CM-1
CM-2
X X X
MZ-OBJ-104 MZ-HC-101

The policy on node and host network contains the following considerations:

  • A specification of prohibited and mandated networking software and hardware configurations; and
  • The minimum maintenance procedures for all networking software.
CM-1
CM-6
CM-7
MA-2
MA-6
SI-2
X X X
MZ-OBJ-104 MZ-HC-103

Regular network vulnerability assessments (VAs) of all nodes and hosts are conducted to assess trends in the effectiveness of the node and host network configuration policy.

The frequency of the VAs is enough to support trend analysis. The results of all VAs are managed within the framework of continuous risk management and provide feedback to the security assessment and authorization (SA&A) process.

CA-7
RA-5
X X X
MZ-OBJ-104 MZ-HC-104 All nodes apply controls that implement continuous protection against malware at start up. SI-3
SI-7 (1)
X X -
MZ-OBJ-104 MZ-HC-106 System and network management processes and technology are implemented to detect changes in node configurations. SI-7 (7) X X -
MZ-OBJ-104 MZ-HC-107 Regular back-ups of system files and system configuration parameters are performed for every node contained in an MZ. The frequency and the retention period of back-ups are consistent with business needs. CP-9 X X -
MZ-OBJ-104 MZ-HC-108 The failure of an MZ node does not result in the compromise of its resources or the resources of any connected network. SC-24 X X -
MZ-OBJ-104 MZ-HC-109 MZ nodes and hosts are within an area that meets the physical security requirements as determined by the ISSIP. GC departments must also align with the Operational Security Standard on Physical Security [16]. PE-18 X X X
MZ-OBJ-104 MZ-HC-111 Operating systems and necessary applications for all nodes are hardened based on documented best practices. CM-6
CM-7
X X X
MZ-OBJ-106 MZ-HC-112 SVPN products, if used, are validated to Federal Information Processing Standard (FIPS) 140-2, at a minimum of Security Level 2, through the Cyber Centre’s Cryptographic Module Validation Program (CMVP). SC-13 X X X
MZ-OBJ-104 MZ-HC-113 Nodes are physically secured to limit access to only authorized personnel who need to access the equipment, according to the principles of least privilege and the need to know. PE-2
PE-3 (1)
PE-18
X X -
MZ-OBJ-100 MZ-HC-114 An end system includes a personal firewall, a configuration integrity mechanism that can identify changes to the configuration and notify the end system administrator. SC-7 (12)
SI-7
- - X
MZ-OBJ-104 MZ-HC-115 An end system undergoes the SA&A process before it is attached to an edge interface. CA-1
CA-6
- - X
MZ-OBJ-105 MZ-HC-116 Host based intrusion detection sensors are placed on all critical hosts. SC-7 (12) - - X
MZ-OBJ-105 MZ-HC-117 MZ nodes generate and maintain audit log records, as required by the security audit service. AU-2 X X X
MZ-OBJ-105 MZ-HC-118 MZ nodes ensure that locally stored security audit log records are accessible to authorized security audit administrators, as required by the security audit service. AU-6 (3)
AU-6 (4)
X X X
MZ-OBJ-105 MZ-HC-119

Each MZ node is subject to regular configuration audits. The network security zone authority determines the frequency of these audits and documents the frequency in the MZ configuration management procedures. The frequency of configuration audits is enough to identify configuration errors.

The configuration audit includes, but is not limited to, the following checks:

  • Verification of node configuration against network topology design;
  • Verification of hardware devices and physical interfaces;
  • Verification of traffic control configuration, including permissions and access controls; and
  • Verification of permitted software load and permitted functions.
AU-1
AU-6
AU-6(1)
AU-6(2)
AU-6(3)
AU-6(4)
AU-6(7)
X X X
MZ-OBJ-105 MZ-HC-120 The MZ nodes record time stamps on audit records. The MZ internal system clocks are synchronized to an authoritative time source. AU-8 (1) X X X
Data Protection

MZ-OBJ-105
MZ-OBJ-106

MZ-DP-100 The internetwork can support SVPN data traffic connections between edge interfaces. SC-8 - X -

MZ-OBJ-105
MZ-OBJ-106

MZ-DP-102 An MZ should be capable of supporting data protection services at the network layer or higher. SC-8 X X -

MZ-OBJ-105
MZ-OBJ-106

MZ-DP-104 Where encryption or digital signature is required, products (whether software, firmware or hardware) incorporate a Cyber Centre approved algorithm and Cyber Centre approved key management processes, such as those products validated to FIPS 140-2 (or subsequent FIPS 140 releases) by the Cyber Centre’s CMVP. SC-13 X X X

Annex F - Baseline Security Requirements of a Zone Interface Point

Foreword

ITSP.80.022 Baseline Security Requirements for Network Security Zones V2 – Annex F – Zone Interface Point is an UNCLASSIFIED publication.

This version of Annex F supersedes previous versions of the document.

Effective date

This publication takes effect on January 12, 2021.

Revision history

Revision Amendments Date
1 Version 2 released. January 12, 2021.

F.1 Introduction

This annex includes a reference model, the security objectives, and a set of baseline security requirements for zone interface points (ZIPs), which are the systems between two zones that enforce inter zone communication policies. A ZIP is a bi directional system between two zones that contains boundary systems. A ZIP can be in either an adjacent zone or a separate location, as agreed upon by the network security zone authorities of the adjacent zones.

Since two zones are connected by a shared ZIP, the network security zone authorities of these zones are responsible for managing the ZIP. In this document, this shared responsibility is referred to as the joint authority for ZIPs (JAZ).

In this document, the ZIPs are named according to the zones to which they connect. For example, a ZIP that connects the operations zone (OZ) to the public access zone (PAZ) is referred to as the OZ PAZ ZIP.

F.2 ZIP Reference Model

A ZIP is the logical construct used to describe the controlled interface connecting two zones. It provides a network interface and the perimeter security between the zones. A ZIP also enforces inter zone communication policies; all communications between zones must pass through a ZIP.

A ZIP is a system (made up of at least one sub system) that implements the boundary protection services. Examples of sub systems include screening routers, firewalls, guards, and intrusion detection systems.

A ZIP filters packets based on defined characteristics. It implements proxy services and should reject all malformed service requests. The ZIP should only present the services necessary for communication between the two zones.

Figure 18 below illustrates two distinct paths between Zone A and Zone B. These two paths are required to address the different inbound and outbound security policies for the connected zones. For example, data loss prevention may only be done on outgoing traffic, while deny listing is mostly done on inbound traffic.

Figure 18: Logical Depiction of a ZIP

Long description immediatly follow
Long description

Figure 18 is a logical depiction of a ZIP. It illustrates two distinct paths between Zone A and Zone B. These two paths are required to address the different inbound and outbound security policies for the connected zones. For example, data loss prevention may only be done on outgoing traffic, while deny listing is mostly done on inbound traffic.

Table 18 lists examples of a ZIP’s security functions.

Table 18: ZIP Security Functions

Security Function Description
Access control Controls traffic based on the source and the destination addresses and the type of service.
Entity authentication Validates the authenticity of entities and establishes a security association between them.
Data origin authentication Validates the authenticity of the entities participating in a security association.
Data integrity verification Verifies that network traffic has not been modified or replayed.
Traffic filters Filter or block traffic based on properties of the data communications stream, including transmission control protocol (TCP) state, source and destination, conformity with authorized communications protocols, data types embedded within the data communications stream, and contents of the data communications stream.
Intrusion detection and audit support Provide the services and attributes that support the implementation of security functions, such as intrusion detection, audit, and incident response.
Resource encapsulation Refers to the mechanisms that allow the zone to hide its internal structure. These mechanisms include network address translation, port address translation, and service mapping. Resource encapsulation supports access control and survivability.

The design of the public zone to PAZ (PZ PAZ) ZIP deployment varies somewhat from an internal zone to an internal zone ZIP. These variances are based on the unique requirements to obfuscate the internal network structure and addressing (see F.2.1 for more information).

F.2.1 PZ ZIP

A PZ ZIP controls all types of traffic between the PZ and the PAZ. A PZ ZIP should filter packets based on defined characteristics. A PZ ZIP hides the details of the network services from the PZ and presents only those services needed to communicate with the PZ.

F.2.2 Internal Zone ZIP

An internal zone ZIP controls and filters all traffic between the PAZ and the internal zones. An internal zone ZIP should filter packets based on defined characteristics and support the implementation of proxy services. It should also reject all malformed service requests. It hides the details of the PAZ network services from the internal zones and presents only those services necessary for communications with internal zones.

F.3 ZIP Implementation Considerations

There are two types of ZIP deployments (see Figure 19):

  • ZIPs that are deployed in the data path to support communication between zones; and
  • ZIPs that are deployed in the management path to support management functions.

Figure 19: ZIP Deployment Options

Long description immediatly follow
Long description

Figure 19 depicts two types of ZIP deployments: ZIPs that are deployed in the data path to support communication between zones and ZIPs that are deployed in the management path to support management functions. Figure 19 illustrations the distinction between management zone-connected ZIPs and data path ZIPs. For example, a PAZ MZ would interface with a PAZ through a PAZ-MZ ZIP, and a restricted zone (RZ) would interface with an OZ through an RZ-OZ ZIP. Figure 19 also shows that the separation of the various ZIP functions may be virtualized.

Figure 19 illustrates the distinction between management zone connected (MZ) ZIPs and data path ZIPs. For example, a PAZ MZ would interface with a PAZ through a PAZ MZ ZIP, and a restricted zone (RZ) would interface with an OZ through an RZ OZ ZIP.

MZ connected ZIPs are managed from the respective MZ, such as the following examples:

  • The RZMZ manages the RZ-MZ ZIP;
  • The OZMZ manages the OZ-MZ ZIP; and
  • The PAZMZ manages the PAZ-MZ ZIP.

The data path ZIPs should be managed by the MZ of the higher security zone or as agreed upon by the JAZ of the connected zones, such as in the following example:

  • The OZ MZ manages OZ PAZ ZIPs, OZ OZ ZIPs; and
  • The RZ MZ manages RZ OZ ZIPs, RZ RZ ZIPs.

As shown in Figure 19, the separation of the various ZIP functions may be virtualized. A single virtualized instance should not contain both MZ connected and data path ZIPs. Virtualization of the MZ connected ZIPs or the data path ZIPs may be considered if the assurance of the separation mechanisms, which are provided by the underlying platform, meets the requirements identified in the information system security implementation process (ISSIP).

A ZIP should be designed and implemented to provide at least the same level of security assurance as the highest level of assurance of the two zones that it connects.

F.4 ZIP Security Objectives

A ZIP is a collection of security mechanisms designed to prevent network based attacks (i.e. reduce vulnerabilities to these attacks) from spreading between zones.

It is assumed that a sophisticated threat actor could defeat the security mechanisms within a ZIP. Therefore, additional security measures are required to protect sensitive assets within the zones.

The level of threat that each ZIP needs to mitigate depends on the results of the ISSIP.

Each objective and requirement specified in this annex is labelled according to the following notation convention:

  • The first set of letters refers to the ZIP (ZIP).
  • The second set of letters designates either an objective (OBJ) or a requirement (REQ).
  • Requirements are grouped into the following categories as applicable:
    • Network interface (NI);
    • Traffic control (TC);
    • Network configuration (NC);
    • Host configuration (HC); and
    • Data protection (DP).
  • Each objective or requirement is sequentially numbered within its group, beginning at 100.
    Note: Objectives and requirements are not sequential, as some requirements have been removed or changed from the previous versions of this document.

F.4.1 Traffic Control Objectives

[ZIP-OBJ-100] A ZIP should protect the integrity and the availability of the network traffic by reducing the occurrence of malicious traffic. A ZIP has the following traffic control objectives:

  • Prevent threat sources from accessing zones through network intrusions;
  • Prevent threat sources from exploiting ZIPs as staging points to attack zones; and
  • Reduce the spread of malware.

[ZIP-OBJ-102] A ZIP should permit enhancements to security measures, such as the following, to respond to increased threat levels (e.g. time of crisis):

  • Flexible and dynamic traffic controls; and
  • Increased status monitoring.

[ZIP-OBJ-103] A ZIP should implement the following safeguards to prevent malicious network traffic between zones:

  • Reduce a zone’s vulnerability to malicious traffic from compromised hosts and nodes in adjacent zones; and
  • Reduce a zone’s vulnerability caused by failures in zone traffic control measures.

F.4.2 Network Availability and Integrity Objectives

[ZIP-OBJ-104] A ZIP should protect the integrity and the availability of network services by reducing their vulnerabilities to a variety of attacks and achieving the following objectives:

  • Reduce network-based denial-of-service DoS attacks (e.g. SYN flood, distributed DoS [DDoS] attack) on zones;
  • Reduce the network services’ vulnerabilities to network intrusions (e.g. attaching an unauthorized device to an existing interface); and
  • Prevent threat sources from exploiting zones as the staging points to attack other network services.

F.4.3 Data Protection Objectives

[ZIP-OBJ-105] A ZIP should prevent threat actors categorized up to and including the Td3 levelFootnote 19 from intercepting a zone’s traffic. A ZIP should also detect if other threat sources intercept the traffic.

[ZIP-OBJ-105] A ZIP prevents external adversaries from intercepting zone traffic.

[ZIP-OBJ-106] A ZIP should support the following measures to protect the confidentiality and the integrity of data:

  • Secure virtual private network (SVPN) within the ZIP; and
  • Upper layer security protocols.

F.5 ZIP Baseline Security Requirements

This section lists a ZIP’s baseline security requirements, which are categorized by operational requirements (i.e. network interface, traffic control, network configuration, host configuration, and data protection). To achieve all the ZIP security objectives, you should implement the complete set of baseline security requirements listed in Table 19.

Table 19: ZIP Baseline Security Requirements

Objective Number Requirement Number ZIP Requirement Related ITSG 33 Control
Network Interface
ZIP-OBJ-103 ZIP-NI-100 All network paths between zones pass through a ZIP. SC-7 (C)
ZIP-OBJ-103 ZIP-NI-101 The number of ZIPs between any two zones is limited. SC-7
ZIP-OBJ-100 ZIP-NI-105 A ZIP supports the attachment of network based intrusion detection sensors (e.g. monitors). A ZIP provides interfaces to support the collection of data from these sensors. SI-4 (4)
Traffic Control
ZIP-OBJ-102 ZIP-TC-101 ZIP management traffic, other than traffic related solely to device status, is segregated from operational traffic. AC-4
SC-37
ZIP-OBJ-102 ZIP-TC-102

In an emergency or an increased threat, the ZIP responds quickly to heightened security levels, as authorized to do so. Personnel are trained and authorized to initiate such a response. For example, the ZIP can improve the network security posture by increasing the levels of the following security measures:

  • Filtering;
  • Monitoring (active and passive);
  • Protecting the continuous delivery of critical services (e.g. reconfigure or block non essential services if required); and
  • Auditing.

Before implementing these measures, test them carefully to ensure that they cannot be exploited to cause a DoS.

Personnel are trained and authorized to initiate a response to heightened security levels.

AC-4
AU-6
IR-4
SC-7
SI-4
SC-5
ZIP-OBJ-104 ZIP-TC-103 A ZIP authenticates the edge interfaces of the zones to which it connects. Authentication can be completed through physical control over the media between the edge interfaces. IA-3
ZIP-OBJ-100 ZIP-TC-105

A JAZ should define requirements for its ZIP access control service that are based on the following principles:

  • Restrict paths to vulnerable end systems in adjacent zones;
  • Limit available network paths for end systems that are accessible by extranet; and
  • Enforce the control service based on network layer source, network layer destination, transport protocol, and transport layer service interface.
AC-4
SC-7
SC-7 (5)
ZIP-OBJ-102 ZIP-TC-106 If a ZIP supports more than one class of service, it implements mechanisms to ensure non interference between these classes. AC-4
ZIP-OBJ-100 ZIP-TC-107 A ZIP uses an addressing model that detects and diagnoses malicious traffic. CA-3
SC-7
SI-3
ZIP-OBJ-103 ZIP-TC-110

The JAZ defines an access control policy, which is enforced by the access control service, that is based on the following principles:

  • The access control policy denies all traffic unless it is explicitly permitted;
  • Extranet hosts are restricted to a defined set of internal addresses, which contain the resources required by the extranet;
  • Remote access hosts are restricted to a defined set of internal addresses, which contain the resources required by the remote access host, when remote access is permitted by the JAZ; and
  • Encrypted traffic is permitted to designated addresses.
AC-4
SC-7 (5)
SC-7 (8)
SC-7 (11)
ZIP-OBJ-103 ZIP-TC-111

A ZIP can filter packets based on the following characteristics and the ISSIP:

  • Statefulness;
  • Protocols;
  • Source and destination address (e.g. IP, MAC);
  • Source and destination ports; and
  • Packet’s source address.
AC-4
ZIP-OBJ-100 ZIP-TC-112 An intrusion detection capability is implemented at the ZIP and configured to provide an alert if traffic contains malware or malicious behaviour. SI-4 (4)
SI-4 (5)
ZIP-OBJ-103 ZIP-TC-113 A content filter is implemented at the PAZ OZ ZIP to enforce the Internet use policy. AC-4 (8)
SC-7 (8)
ZIP-OBJ-104 ZIP-TC-120 The ZIP interface to common infrastructure may share traffic control functionality with a service provider. A service level agreement includes the baseline requirements for both sides of the interface. CA-3
ZIP-OBJ-104 ZIP-TC-122 The ZIP should be capable of rejecting all malformed service requests. AC-4 (1)
ZIP-OBJ-104 ZIP-TC-123 The ZIP uses network layer and upper layer controls to protect hosts from malicious traffic from the connected zone. AC-4 (1)
SC-7
ZIP-OBJ-104 ZIP-TC-124
(PZ PAZ ZIP only)

All IP packets from the PZ are filtered at the PZ PAZ ZIP as follows:

  • Block any traffic containing directed broadcast addresses;
  • Block any traffic containing a network loop back address;
  • Block traffic destined to an RFC 1918 reserved address;
  • Block network traffic containing a source or destination address of 0.0.0.0;
  • Block inbound traffic with an internal source IP address;
  • Block any traffic containing IP source routing information;
  • Block any management traffic (i.e. Simple network management protocol [SNMP]);
  • Block any Internet control message protocol (ICMP) broadcasts; and
  • Block any traffic determined to have malicious intent.
AC-4
SC-7
ZIP-OBJ-103 ZIP-TC-125
(PZ PAZ ZIP only)

The JAZ for the PZ PAZ ZIP defines an access control policy, which is to be enforced by the access control service, that is based on the following principles:

  • All outgoing traffic is restricted to destination addresses that correspond with designated proxy servers in the PAZ; and
  • Traffic to and from application servers is restricted to addresses that correspond with front end servers in the PAZ and the protocols needed to support communication with those servers.
AC-4
Network Configuration
ZIP-OBJ-104 ZIP-NC-100 The ZIP network configuration is monitored to detect additions, deletions, or changes to the configuration. Unauthorized changes are reported to the JAZ. CM-2
CM-3
SI-4
ZIP-OBJ-104 ZIP-NC-103 The JAZ periodically verifies the network topology. The JAZ determines the frequency of such verifications and documents the frequency in the ZIP configuration management procedures. CM-2
CM-9
ZIP-OBJ-104 ZIP-NC-104 The JAZ periodically assesses the network configuration for unauthorized external interfaces. The JAZ determines the frequency of the assessments and documents the frequency in the ZIP configuration management procedures. SI-4 (4)
ZIP-OBJ-104 ZIP-NC-105 Only authenticated and authorized administrators can manage ZIP nodes. The ZIP is managed from the MZ of the connected zone that has the highest security requirements. For example, if a ZIP connects the OZ to the RZ, the ZIP is managed from the RZ MZ. AC-5
IA-5
ZIP-OBJ-104 ZIP-NC-109 The JAZ maintains current configuration information for the ZIP. CM-2
CM-6
ZIP-OBJ-104 ZIP-NC-110 The JAZ approves any changes to a ZIP before they are implemented. CM-3 (4)
CM-9
Host Configuration
ZIP-OBJ-104 ZIP-HC-100 The JAZ maintains a node and host configuration policy that is consistent with applicable baseline security requirements, standards, and guidance. This policy applies to all nodes and hosts within the ZIP. CM-1
CM-2
ZIP-OBJ-104 ZIP-HC-101

The node and host network configuration policy should contain the following considerations:

  • A specification of prohibited and mandated networking software and hardware configurations; and
  • The minimum maintenance procedures for all software.
CM-1
CM-6
CM-7
MA-2
MA-6
SI-2
ZIP-OBJ-104 ZIP-HC-103

Regular network vulnerability assessments (VAs) of all nodes and hosts are conducted to assess trends in the effectiveness of the node and host network configuration policy.

The frequency of these VAs is enough to support trend analysis. The VA results are managed within the framework of continuous risk management and provide feedback to the security assessment and authorization (SA&A) process.

CA-7
RA-5
ZIP-OBJ-100 ZIP-HC-104 All nodes should apply controls that implement continuous protection against malware at start up. SI-3
SI-7 (1)
ZIP-OBJ-100 ZIP-HC-105 Operating systems and necessary applications for all nodes are hardened based on documented best practices. CM-6
CM-7
ZIP-OBJ-104 ZIP-HC-106 System and network management processes and technology is implemented to detect changes in node configurations. SI-7 (7)
ZIP-OBJ-104 ZIP-HC-111 Operating systems for all nodes are hardened based on documented best practices. CM-6
CM-7
ZIP-OBJ-106 ZIP-HC-112 VPN products, if used, are validated to the Federal Information Processing Standard (FIPS) 140-2 (or subsequent FIPS 140 release), at a minimum of security level 2, through the Cyber Centre’s Cryptographic Module Validation Program (CMVP). SC-13
Data Protection
OZ-OBJ-106 ZIP-DP-101 A ZIP can support encrypted data traffic connections between zones. SC-8
ZIP-OBJ-106 ZIP-DP-103 Data protection measures may be required depending on a ZIP’s security categorization and the results of the ISSIP. Data protection services may be applied at either the network layer or higher layers, depending on the implementation requirements. SC-8
ZIP-OBJ-106 ZIP-DP-104 Where encryption or digital signature is required, products (whether software, firmware, or hardware) must incorporate a Cyber Centre approved algorithm and Cyber Centre approved key management processes, such as those products validated to FIPS 140-2 (or subsequent FIPS 140 releases) by the Cyber Centre’s CMVP. SC-13
Report a problem on this page
Please select all that apply:

Thank you for your help!

You will not receive a reply. For enquiries, please contact us.

Date modified: