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

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

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

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 actors^{Footnote 6}. You should assume that Td5^{Footnote 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

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.

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

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

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

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

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

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

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.

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

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

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 Td5^{Footnote 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

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

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

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

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 Td5^{Footnote 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 sources^{Footnote 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

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

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

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

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 sources^{Footnote 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

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

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

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

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

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

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

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

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

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

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 level^{Footnote 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 sources^{Footnote 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

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

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

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

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

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 level^{Footnote 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