To ensure that gateways are properly configured to protect agency systems and information transferred between systems from different security domains.

]]> Gateways can be considered to be information flow control mechanisms operating at the Network layer and may also control information flow at the Transport, Session, Presentation and Application layers of the Open Systems Interconnection model (OSI).  Specific controls for different technologies can be found in:

]]> Additional information relating to topics covered in this section can be found in the following sections of this manual:

]]> This section provides a baseline for agencies deploying gateways.  Agencies will need to consult additional sections of this manual depending on the specific type of gateways deployed.

]]> For network devices used to control data flow in bi-directional gateways, Section 19.3 – Firewalls will need to be consulted. Section 19.4 – Diodes will also need to be consulted for one-way gateways.  Additionally, for both types of gateways, Section 20.1 - Data Transfers and Section 19.2 - Cross-Domain Solutions, will need to be consulted for requirements on appropriately controlling data flows.

]]> The requirements in this manual for content filtering, data import and data export apply to all types of gateways.

]]> For the purposes of this chapter, the gateway assumes the highest classification of the connected domains.

]]> Further references can be found at:

Reference Title Publisher Source
  Gateway / Cross Domain Solution Audit Guide, Australian Government ASD https://www.cyber.gov.au/acsc/view-all-content/advice/guidelines-gateways
  Good Practices for deploying DNSSEC, ENISA ENISA https://www.enisa.europa.eu/publications/gpgdnssec
ISO/IEC 27033-4:2014 Information technology -- Security techniques -- Network security -- Part 4: Securing communications between networks using security gateways ISO https://www.iso.org/standard/51583.html

ISO/IEC 7498-1:1994

The OSI model

Information Technology – Open Systems Interconnection: The Basic Model

 ISO https://www.iso.org/standard/20269.html 

NIST Special Publication 800-41, September 2009

Guidelines on Firewalls and Firewall Policy

 NIST https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-41r1.pdf [PDF, 331 KB]
]]> Relevant PSR requirements can be found at:

Reference Title Source

PSR Mandatory Requirements

GOV5, GOV6, INFOSEC1, INFOSEC2, INFOSEC3 and INFOSEC4

Home | Protective Security Requirements

Security governance (GOV) | Protective Security Requirements

Information security (INFOSEC) | Protective Security Requirements
]]> Protecting a cascaded connection path with the minimum assurance requirement of a direct connection between the highest and lowest networks ensures appropriate reduction in security risks of the extended connection.  An illustration of a cascaded connection can be seen below.

19.1.8.R.01 Cascading Connections

]]> When agencies have cascaded connections between networks involving multiple gateways they MUST ensure that the assurance levels specified for network devices between the overall lowest and highest networks are met by the gateway between the highest network and the next highest network within the cascaded connection.

]]> Physically locating all gateway components inside a secure server room will reduce the risk of unauthorised access to the device(s).

]]> The system owner of the higher security domain of connected security domains would be most familiar with the controls required to protect the more sensitive information and as such is best placed to manage any shared components of gateways.  In some cases where multiple security domains from different agencies are connected to a gateway, it may be more appropriate to have a qualified third party manage the gateway on behalf of all connected agencies.

Gateway components may also reside in a virtual environment – refer to Section 22.2 – Virtualisation and Section 22.3 – Virtual Local Area Networks

]]> Agencies MUST ensure that:

  • all agency networks are protected from networks in other security domains by one or more gateways;
  • all gateways contain mechanisms to filter or limit data flow at the network and content level to only the information necessary for business purposes; and
  • all gateway components, discrete and virtual, are physically located within an appropriately secured server room.
]]> For gateways between networks in different security domains, any shared components MUST be managed by the system owners of the highest security domain or by a mutually agreed party.

]]> Gateways are essential in controlling the flow of information between security domains.  Any failure, particularly at the higher classifications, may have serious consequences.  Hence mechanisms for alerting personnel to situations that may give rise to information security incidents are especially important for gateways.

]]> Agencies MUST ensure that gateways:

  • are the only communications paths into and out of internal networks;
  • by default, deny all connections into and out of the network;
  • allow only explicitly authorised connections;
  • are managed via a secure path isolated from all connected networks (i.e.  physically at the gateway or on a dedicated administration network);
  • provide sufficient logging and audit capabilities to detect information security incidents, attempted intrusions or anomalous usage patterns; and
  • provide real-time alerts.
]]> Providing an appropriate logging and audit capability will help to detect information security incidents and attempted network intrusions, allowing the agency to respond and to take measures to reduce the risk of future attempts.

]]> Storing event logs on a separate, secure log server will assist in preventing attackers from deleting logs in an attempt to destroy evidence of any intrusion.

]]> Agencies MUST ensure that all gateways connecting networks in different security domains:

  • include a firewall of an appropriate assurance level on all gateways to filter and log network traffic attempting to enter the gateway;
  • are configured to save event logs to a separate, secure log server;
  • are protected by authentication, logging and audit of all physical access to gateway components; and
  • have all controls tested to verify their effectiveness after any changes to their configuration.
]]> Demilitarised zones are used to prevent direct access to information and systems on internal agency networks.  Agencies that require certain information and systems to be accessed from the Internet or some other form of remote access, should place them in the less trusted demilitarised zone instead of on internal agency networks.

]]> Agencies MUST use demilitarised zones to house systems and information directly accessed externally.

]]> Agencies SHOULD use demilitarised zones to house systems and information directly accessed externally.

]]> Performing a risk assessment on the gateway and its configuration prior to its implementation will assist in the early identification and mitigation of security risks.

]]> Agencies MUST perform a risk assessment on gateways and their configuration prior to their implementation.

]]> Gateways could connect networks with different domain owners, including across agency boundaries.  As a result, all domain and system owners MUST understand and accept the risks from all other networks before gateways are implemented.

]]> All domain and system owners connected through a gateway MUST understand and accept the residual security risk of the gateway and from any connected domains including those via a cascaded connection.

]]> Agencies SHOULD annually review the security architecture of the gateway and risks of all connected domains including those via a cascaded connection.

]]> Changes to a domain connected to a gateway can affect the security posture of other connected domains.  All domains owners should be considered stakeholders in all connected domains.

]]> Once connectivity is established, domain owners MUST be considered information stakeholders for all connected domains.

]]> Once connectivity is established, domain owners SHOULD be considered information stakeholders for all connected domains.

]]> It is important that system users are competent to use gateways in a secure manner.  This can be achieved through appropriate training before being granted access.

]]> All system users MUST be trained on the secure use and security risks of the gateways before being granted access.

]]> All system users SHOULD be trained in the secure use and security risks of the gateways before being granted access.

]]> Application of role separation and segregation of duties in administration activities will protect against security risks posed by a malicious system user with extensive access to gateways.

]]> Agencies MUST limit access to gateway administration functions.

]]> Agencies MUST ensure that system administrators are formally trained to manage gateways by qualified trainers.

]]> Agencies MUST ensure that all system administrators of gateways that process NZEO information meet the nationality requirements for these endorsements.

]]> Agencies MUST separate roles for the administration of gateways (e.g.  separate network and security policy configuration roles).

]]> Agencies SHOULD separate roles for the administration of gateways (e.g. separate network and security policy configuration roles).

]]> Authentication to networks as well as gateways can reduce the risk of unauthorised access and provide an audit capability to support the investigation of information security incidents.

]]> Agencies MUST authenticate system users to all classified networks accessed through gateways.

]]> Agencies MUST ensure that only authenticated and authorised system users can use the gateway.

]]> Agencies SHOULD use multi-factor authentication for access to networks and gateways.

]]> Authenticating IT equipment to networks accessed through gateways will assist in preventing unauthorised IT equipment connecting to a network.

]]> Agencies SHOULD authenticate any IT equipment that connects to networks accessed through gateways.

]]> To avoid changes that may introduce vulnerabilities into a gateway, agencies should fully consider any changes and associated risks.  Changes may also necessitate re-certification and accreditation of the system, see Chapter 4 – System Certification and Accreditation.

]]> Agencies MUST undertake a risk assessment and update the SRMP before changes are implemented.

]]> Agencies MUST document any changes to gateways in accordance with the agency’s Change Management Policy.

]]> Agencies SHOULD undertake a risk assessment and update the SRMP before changes are implemented.

]]> The testing of security measures on gateways will assist in ensuring that the integrity of the gateway is being maintained.  An attacker who is aware of the regular testing schedule may cease malicious activities during such periods to avoid detection.  Any test should, therefore, be unannounced and conducted at irregular intervals.

]]> Agencies SHOULD ensure that testing of security measures is performed at random intervals no more than six months apart.

]]>