Agencies intending to adopt public cloud technologies or services MUST develop a plan for how they intend to use these services.  This plan can be standalone or part of an overarching ICT strategy.

An agency’s cloud adoption plan SHOULD cover:

• Outcomes and benefits that the adoption of cloud technologies will bring;
• Risks introduced or mitigated through the use of cloud, and the agency’s risk tolerance;
• Financial and cost accounting models;
• Shared responsibility models;
• Cloud deployment models;
• Cloud security strategy;
• Resilience and recovery approaches;
• Data recovery on contract termination;
• Cloud exit strategy and other contractual arrangements; and
• A high level description of the foundation services that enable cloud adoption, including:
  • User, device and system identity;
  • Encryption and key management;
  • Information management;
  • Logging and alerting;
  • Incident management;
  • Managing privileged activities; and
  • Cost management.

Agencies intending to adopt public cloud technologies or services SHOULD incorporate Zero Trust philosophies and concepts.

Agencies SHOULD leverage public cloud environment native security services as part of legacy system migrations, in preference to recreating application architectures that rely on legacy perimeter controls for security.

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.

The CISO SHOULD work with system owners, system certifiers and system accreditors to determine appropriate information security policies for their systems and ensure consistency with the Protective Security Requirements (PSR) and in particular the relevant NZISM components.

An agency MUST undertake a risk assessment to determine which systems and services to include in the agency’s VDP.

An agency MUST develop and publish a VDP.

An agency’s VDP MUST contain at least the following core content:

• A scoping statement listing the systems the policy applies to;
• Contact details;
• Secure communication options (including any public keys);
• Information the finder should include in the report;
• Acknowledgement of reports and a response time;
• Guidance on what forms of vulnerability testing are out of scope for reporters/finders (permitted activities);
• Reporters/finders agreeing to not share information about the vulnerability until the end of the disclosure period, in order to allow the agency to address any issues before they become public;
• Illegal activities are not permitted (specifying the relevant legislation, such as the Crimes Act); and
• Either that “Bug bounties” will not be paid for any discoveries, or it should provide information about the agency’s bug bounty programme.

An agency SHOULD publish a security.txt to permit secure communications and direct any reports to a specific agency resource, in accordance with the agency’s VDP.

An agency MUST commit to addressing disclosed vulnerabilities within the timeframe it sets in its policy.

An agency’s vulnerability disclosure timeframe SHOULD be set to no more than 90 days.

Agencies MUST ensure they integrate their VDP with other elements of their information security policies.

Agencies MUST replace compromised cryptographic keys as a matter of urgency and record the replacement in the incident reporting.

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.

Because of the risks that data can be recovered from monitors, it is essential that any redeployment or disposal of monitors MUST follow the guidance in the NZISM.

Where a facility is NOT an approved facility, agencies MUST ensure any incineration equipment is rated for the destruction of electronic waste (WEEE) and the operator is properly authorised or licensed.

Where a facility is NOT an approved facility, agencies MUST ensure processes are in place for the safe handling of electronic waste (WEEE), including any residual material from the destruction process.

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.

Password and other authentication data SHOULD be hashed before storage using an approved cryptographic protocol and algorithm.

Agencies MUST establish a Privileged Access Management (PAM) policy.

Within the context of agency operations, the agency’s PAM policy MUST define:

• a privileged account; and
• privileged access.

Agencies MUST manage Privileged Accounts in accordance with the Agency’s PAM Policy.

Agencies MUST apply the Principle of Least Privilege when developing and implementing a Privileged Access Management (PAM) policy.

Agencies SHOULD use two-factor or Multi-Factor Authentication to allow access to Privileged Accounts.

As part of a Privileged Access Management (PAM) policy, agencies MUST establish and implement a strong approval and authorisation process before any privileged access credentials are issued.

Privileged Access credentials MUST NOT be issued until approval has been formally granted.

Agencies MUST establish robust credential suspension and revocation procedures as part of the agency’s Privileged Access Management (PAM) policy.

Agencies MUST create and maintain a comprehensive inventory of privileged accounts and the associated access rights and credentials.

Agencies MUST create, implement and maintain a robust system of continuous discovery, monitoring and review of privileged accounts and the access rights and credentials associated with those accounts.

Privileged account monitoring systems MUST monitor and record:

• individual user activity, including exceptions such as out of hours access;
• activity from unauthorised sources;
• any unusual use patterns; and
• any creation of unauthorised privileges access credentials.

Agencies MUST protect and limit access to activity and audit logs and records.

Agencies MUST develop and implement a response and remediation policy and procedure as part of an agency’s Privileged Access Management (PAM) policy.

Agencies MUST implement a Privileged Access Management (PAM) policy training module as part of the agency’s overall user training and awareness requirement.

Agencies MUST undertake a risk analysis before designing and implementing MFA.

The design of an agency’s MFA SHOULD include consideration of:

• Risk Identification;
• Level of security and access control appropriate for each aspect of an agency’s information systems (data, devices, equipment, storage, cloud, etc.)
• A formal authorisation process for user system access and entitlements;
• Logging, monitoring and reporting of activity;
• Review of logs for orphaned accounts and inappropriate user access;
• Identification of error and anomalies which may indicate inappropriate or malicious activity;
• Incident response;
• Remediation of errors;
• Suspension and/or revocation of access rights where policy violations occur;
• Capacity planning.

Where an agency has implemented MFA they SHOULD:

• Require MFA for administrative or other high privileged users; and
• Implement a secure, multi-factor process to allow users to reset their normal usage user credentials.

The design of an agency’s MFA system SHOULD be integrated with the agency’s Information Security Policy and the agency’s Privileged Access Management (PAM) Policy.

When agencies implement MFA they MUST ensure users have an understanding of the risks, and include appropriate usage and safeguards for MFA in the agency’s user training and awareness programmes.

Agencies using DSA, for the approved use of digital signatures, MUST use a modulus of at least 1024 bits.

Agencies using RSA, for the approved use of digital signatures and passing encryption session keys or similar keys, SHOULD use a modulus of at least 4096 bits.

Agencies using RSA keys within internet X.509 Public Key Infrastructure certificates MUST use a modulus of at least 2048 bits.

In all other cases when information requires integrity protection using hashing algorithms, Agencies MUST use a minimum of SHA-256.

Memorised secrets such as passwords MUST be stored in a form that is resistant to offline attacks.

Memorised secrets such as passwords SHOULD be salted and hashed using a suitable one-way key derivation function. See 17.2.14.

The salt SHOULD be at least 32 bits in length, be chosen arbitrarily, and each instance is unique so as to minimise salt value collisions among stored hashes.

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.