Agencies SHOULD ensure they are aware of the latest developments in post-quantum cryptography.  GCSB is tracking these developments and will continue to provide advice through the NZISM.

Agencies SHOULD maintain an inventory of sensitive and critical datasets that must be secured for an extended amount of time.  This will ensure datasets that may be at risk now and decrypted once a cryptographically relevant quantum computer is available are not secured solely through the use of quantum vulnerable cryptography.

Agencies SHOULD conduct an inventory of systems using cryptographic technologies to determine the potential size and scope of future transition work once post-quantum cryptographic systems become available.

Agencies SHOULD identify which systems in their inventory rely on public key cryptography and note them as quantum vulnerable in agency risk assessments.

Agencies SHOULD determine a priority order for quantum vulnerable systems to be transitioned from classical cryptography to post-quantum cryptography.

Agencies SHOULD consider the following factors when prioritising the quantum vulnerable systems:

• Is the system a high value asset based on agency requirements?
• Does the system protect sensitive information (e.g., key stores, passwords, root keys, signing keys, personal information, and classified information)?
• Do other systems (internal or external to the agency) depend on the cryptographic protections in place on the quantum vulnerable system?
• How long does the data need to be protected?

Using the inventory and prioritisation information, agencies SHOULD develop a plan for system transitions upon publication of the new post-quantum cryptographic standard.

Agencies wishing to permit the use of Bluetooth MUST develop a policy that details the circumstances under which Bluetooth usage is permitted, and situations where it is not to be used.

The policy position MUST include information about Bluetooth security controls that are to be used, and methods for verifying that the controls are in place and are effective.

Agencies MUST ensure that Bluetooth pairing is only established between authorised devices. (Unless a gateway is being used, paired devices are considered to operate at the same security classification level).

Agencies SHOULD ensure that Bluetooth discovery of devices is disabled unless a new pairing connection is being established.

Agencies SHOULD ensure that Bluetooth device pairing only occurs at a location where only authorised persons have access.

Agencies SHOULD ensure that Bluetooth pairings are removed when they are no longer required.

Agencies using Bluetooth MUST use the most secure configuration supported by the paired devices.

Agencies SHOULD identify the:

• Bluetooth type (BR/EDR or LE), 
• version, and
• security capabilities;

for devices used to form Bluetooth connections, and ensure they are used to inform risk decisions on the use of Bluetooth.

Agencies SHOULD ensure that new Bluetooth connections between devices are authenticated using explicit user actions, such as entry of a numeric code, confirmation of a matching PIN, or other affirming action, such as challenge-response process.

Agencies using Bluetooth between devices to transfer UNCLASSIFIED or IN-CONFIDENCE information SHOULD ensure that connections meet NZISM standards for authentication and use Approved Cryptographic Algorithms for encryption and message integrity. 

Agencies using Bluetooth between devices to transfer RESTRICTED or SENSITIVE information MUST ensure that connections meet NZISM standards for authentication and use Approved Cryptographic Algorithms for encryption and message integrity.

If Bluetooth specifications do not support these approved encryption methods, organisations MUST do a risk assessment and use the exception or waiver process to accept this risk.

Agencies MUST manage “received DMARC messages” in accordance with the agency’s published DMARC policy.

Agencies SHOULD produce failure reports and aggregate reports according to the agency’s DMARC policies.

Agencies SHOULD enable MTA-STS to prevent the unencrypted transfer of emails between complying servers.

Agencies MUST use TLS 1.2 or above when implementing MTA-STS.

Agencies SHOULD enable TLS reporting when implementing MTA-STS.

Agencies MUST undertake a threat and risk assessment on the use of inverse split tunnelling prior to enabling the functionality in remote access VPN systems.

When providing inverse split-tunnelled access to internet based services (“directly accessed services”), the following aspects SHOULD be considered as part of the threat and risk assessment:

• How do directly accessed services authenticate agency device identities prior to granting access to the service?
• How do agency devices securely resolve internet addresses for directly accessed services?
• How are the communications between the devices and directly accessed services secured?
• How does an agency monitor and account for access made to directly accessed services?
• How does an agency protect devices from compromise if they are able to directly access internet based resources, or be directly accessed from the internet?
• How do directly accessed services authenticate the user of the agency device prior to granting access to the service (this is separate to authenticating the agency device itself)?
• How does an agency enforce the use of multi-factor authentication with directly accessed services?
• How does an agency authorise access to directly accessed services, and does this include from devices that are not authorised to connect to agency remote access services (authorisation and authentication are separate activities)?
• How is access to directly accessed cloud services removed when staff no longer require access or leave the agency?

Agencies MUST clearly identify and understand where classification, security domain, and trust zone boundaries exist prior to implementation or adoption of public cloud services.

Where multiple identity systems under different security policies are used to control access to an agency’s instance of a public cloud service, the instance MUST be considered to be in a separate security domain from services where access control is managed solely by the agency’s identity system.

Agencies MUST clearly identify and understand their cloud service provider’s security responsibilities for each service consumed, and the aspects of security that the agency is responsible for, prior to implementation or adoption of the service.

Agencies SHOULD clearly document the aspects of security they and their provider are responsible for.

Agencies SHOULD review existing security processes to ensure compatibility with their cloud service provider’s responsibilities.

Agencies SHOULD deploy and manage their cloud infrastructure using automation, version control, and infrastructure as code techniques where these are available.

Agencies MUST update their risk assessment process to account for public cloud specific risks, prior to implementation or adoption of public cloud services.

Agencies MUST undertake a cloud specific risk assessment in line with the process outlined by the GCDO for each public cloud service, prior to implementation or adoption of public cloud services.

Agencies MUST NOT accredit public cloud services for use with data classified CONFIDENTIAL, SECRET, or TOP SECRET.

Agencies MUST NOT accredit public cloud services to host, process, store, or transmit NZEO endorsed information.

Agencies MUST consider risks to the availability of systems and information in their design of cloud systems architectures, supporting controls, and governance processes prior to implementation or adoption of public cloud services.

Agencies SHOULD obtain regular assurance checks on cloud service providers, ensuring they have been undertaken by a suitably qualified assessor.

Agencies MUST obtain assurance that cloud service providers undertake appropriate software and operating system patching and maintenance.

Agencies MUST obtain assurance that technical protections exist to adequately isolate tenants.

Agencies SHOULD make use of the GCSB endorsed baseline security templates where applicable.  

Accounts used to perform privileged actions SHOULD NOT be synchronised between environments.

Where administration interfaces or portals are accessible from the internet, privileged accounts MUST be configured to use multiple factors of authentication.

Where cloud service interfaces or portals are accessible from the internet, user accounts SHOULD be configured to use multiple factors of authentication.

Staff offboarding processes MUST be updated to include removing all access to public cloud based services, prior to implementation or adoption of public cloud services.

Agencies MUST ensure that relying parties continually verify the authenticity of their identity provider’s responses, through for example, cryptographic signing of authentication requests and responses.

Agencies SHOULD ensure that relying parties use all available information from the identity provider to inform access control decisions.

For each cloud service, agencies MUST ensure that the mechanisms used to protect data meet agency requirements.

Agencies MUST update key management plans to account for differences in public cloud before storing organisational data in a public cloud environment.

Agencies MUST ensure their key management plan includes provision for migrating data from the cloud environment where it was created.

Agencies MUST apply the principle of least privilege and configure service endpoints to restrict access to authorised parties.

Agencies MUST identify where data used in conjunction with a public cloud service is stored or processed, including any replicas or backups that may be created.

Agency risk assessments of public cloud services MUST include any risks arising from data location. Any actions required to mitigate these risks must be identified and documented prior to implementation or adoption of public cloud services.

Agencies MUST update their disaster recovery plans prior to storing or replicating data in public cloud services, to ensure these plans address any cloud-specific aspects of backup and recovery.

When planning tests of disaster recovery processes in accordance with 6.4.6 Backup strategy, agencies MUST include tests of any cloud-specific data recovery processes.

Agencies MUST have a defined exit strategy for each public cloud service they consume, including a process by which their data can be retrieved and erased from the cloud service as part of contract termination.

Agencies MUST ensure all data they need to retain is retrieved from the cloud service provider prior to decommissioning.

Agencies MUST have assurance that no agency-owned data is retained on the cloud service being decommissioned.

Agencies MUST understand the range of logging capabilities provided by their cloud service providers and determine whether they are sufficient for agency needs.

Agencies MUST ensure that logs associated with public cloud services are collected, protected, and that their integrity can be confirmed in accordance with the agency’s documented logging requirements.

Agencies MUST ensure that cloud service provider logs are incorporated into overall enterprise logging and alerting systems or procedures in a timely manner to detect information security incidents.

Agencies SHOULD ensure that tools and procedures used to detect potential information security incidents account for the public cloud services being consumed by the agency.