Guidance — risk discovery tool for public cloud

This tool helps you to discover and record the information needed to do a risk assessment for public cloud services. The tool itself is not the risk assessment.

Create or improve your organisation’s process for assessing risks

Questions in the risk discovery tool

The tool is split into 2 stages, each with steps to help you identify risks and controls when using a public cloud service.

1. The first stage’s questions help you with general risks and sets up which questions you’ll need to answer in the second stage.
2. The second stage’s questions identify specific risks based on your situation.

Download the risk discovery tool for public cloud services

Cloud Risk Discovery Tool (ZIP, 1.1 MB)

Finding information to answer the questions

There’s a mix of questions about the government organisation and the service provider.

Help with answering the questions about government organisations

Direct contracts — check for information you can use

Another NZ government organisation may have previously assessed the public cloud service you’re looking to use. See which organisation to contact for information by:

• joining the Cloud Capabilities Network (CCN) if you’re not already a member
• searching the CCN’s chart of risk assessments for public cloud services.

NZ government agreements and contracts — check for certification documents you can use

You can use certification documents to help with your risk assessment of using either:

• an all-of-government agreement
• a Marketplace contract
• a public-cloud data centre located in New Zealand — also called ‘onshore’.

For the agreement and contract, email the security team at the Department of Internal Affairs at ictassurance@dia.govt.nz.

For information on certificates of onshore public-cloud data centres, contact gcdo.dc@dia.govt.nz.

Where to find the service provider’s answers

You can get the answers to the service provider’s questions from a combination of:

• direct communication with the provider
• the provider’s policies and audit reports on their website
• previous assessments by other government organisations.

If you do not have the service provider’s answers

If you need higher assurance for the information, consider a different public cloud service if:

• you cannot get acceptable third-party assurance
• the provider does not give you their answers or other information you need for your risk assessment
• there are no ways to lessen the risk of this incomplete information.

Independent assurance reports — New Zealand Information Security Manual

Business context for the information

Before checking the value of the information, it’s important to know the business context of the information.

The Government Chief Digital Officer’s guidance on risk assessments shows the most common areas of concern for information when using public cloud services.

You might have other risks in your context or choice of public cloud service that you need to consider.

Business context of an information system

Technical owner and context

The business owner should check with the technical owner of the information.

They’ll know the answers to many of the questions in the risk discovery tool — or may know who can answer them in your organisation.

Consulting the technical owner, subject matter experts or development and operations (DevOps) team will help you to answer the other questions in the risk discovery tool for public cloud services.

Technical context of an information system

Classify information

Consider the value of the information you’re looking to use with a public cloud service. Know how important the information is to your organisation, the NZ government and New Zealanders.

Why government organisations must classify information

If you do not classify data that will be stored, processed and sent in a public cloud service, there may be a mismatch between the information’s classification level and a public cloud service’s:

• security controls
• cost
• availability to help in achieving your organisation’s business objectives.

Work out the classification level for the information

To do a risk assessment, the business owner and stakeholders need to classify the information they’re planning to use with a public cloud service.

Classify information

How to avoid mistakes in classifying information

The business owner leads the classification of the information and should make sure to:

• consult the right stakeholders
• use 2-way communication to learn the details needed for classifying the information.

Setting up a successful risk assessment

Classification levels that can use public cloud services

Government organisations are encouraged, with appropriate security controls, to use public cloud services for information that is:

• unclassified
• in-confidence
• sensitive
• restricted.

Classification levels that cannot use public cloud services

Government organisations, as decided by Cabinet, cannot use public cloud services for information that is:

• confidential
• secret
• top-secret.

Cabinet minutes and papers for public cloud services

Under-classifying information

If you wrongly classify information at a lower level than it is in reality, the public cloud service might:

• not have the needed security controls
• be used insecurely — the proper security controls exists, but you do not set them up because you think the information has less value and risk than it does in reality.

Be careful — confidential, secret and top-secret

If under-classifying information that’s actually confidential, secret or top-secret, you might end up using a public cloud service when it’s inappropriate to do so.

Over-classifying information

If you wrongly classify information at a higher level than it is in reality, the public cloud service might:

• have unnecessary security controls, increasing its cost for no reason
• be rejected.

Be careful — unclassified, in-confidence, sensitive and restricted

If over-classifying information that’s actually unclassified, in-confidence, sensitive or restricted, you might end up turning down public cloud services that could actually help your organisation to achieve its business objectives.

Criticality of the information

Thinking through the worst-case scenarios is essential for assessing the information’s criticality.

Why government organisations must check the criticality of the information

The business owner and stakeholders need to know:

• the importance of the information being used in a public cloud service
• what business processes will be using the service and information
• how critical those business processes are
• who would be impacted if those processes were disrupted
• the consequences of different kinds of disruption.

Identify and analyse the risks

How you do this depends on if you do or do not know the risks and controls.

You know the risks and controls

The business owner should already know the risks to and controls for their information by using their organisation’s approved processes, scales and matrices for assessing risks.

Using risk scales and matrices for your organisation

When you do not know the risks and controls

If the business owner and organisation do not have complete information about the risks to and controls for their information, the Government Chief Digital Officer (GCDO) has guidance to help them to:

• identify the risks to an information system
• analyse the risks to an information system.

Risk rating

Using the risk matrix approved by your organisation, find out how severe (or not) these risks are to your organisation, the NZ government and New Zealanders.

The GCDO has an example of a risk matrix and how to use it.

Find the initial risk rating

Confidentiality of the information

Understand how to assess and ensure information in a public cloud service is secure.

Authentication and access control

Use a strong approach for identity management. Make sure your practices for identity lifecycle management are well-established and reliable. See if the provider audits user accounts and has access controls and passwords for authentication that meet your security needs.

How public cloud affects identity and access management

As the number of public cloud services your organisation is using increases, so too does the administrative overhead for identity management. This overhead can be minimised by configuring the cloud services for single sign-on.

Have an approach to identity and access management

Make sure your government organisation has an approach to identity and access management that:

• supports your organisation’s adoption and use of public cloud services
• takes into account security controls and risks.

Identification management

Broad network access

The broad network access characteristic of public cloud services creates more need for government organisations to have strong management practices for identity life cycles.

Users can typically access the information held in a public cloud service from any location. This can present a significant risk as employees or contractors may still be able to access the service after they have stopped being employed by your organisation.

Manage the life cycle of identities

Government organisations should maintain a strong process for managing the life cycle of identities and make sure that:

• permissions are approved at the right level within your organisation
• role-based access control is detailed enough to properly control permissions
• users are only granted the permissions they need to perform their duties
• users do not accumulate permissions when they change roles within your organisation
• user accounts are removed in a timely manner when someone’s employment ends.

Audit user accounts regularly

Government organisations should regularly audit user accounts to check the permissions granted are still appropriate.

Remove:

• accounts that are no longer needed
• permissions that are not needed for staff to perform their regular duties.

Security controls for bring-your-own-device

Users can also access the information held in a public cloud service from many different devices — sometimes called bring-your-own-device (BYOD). Government organisations must carefully consider the security risks and controls needed to protect their information in BYOD situations.

Passwords for authentication

Government organisations need to see whether:

• passwords are a sufficient level of assurance that the person authenticating to the service is the owner of the user account, or
• they need stronger authentication — for example, multi-factor authentication.

Access control and passwords — NZISM

Multi-tenancy — multiple customers sharing a pool of computing resources

Check if the provider has security controls for virtualisation and separating customer data, and will allow you to test its access controls.

Resource pooling

The resource-pooling characteristic of public cloud services means there is typically some form of multi-tenancy — multiple customers are sharing a pool of computing resources.

Benefit of resource pooling

Resource pooling allows service providers to deliver their services at lower costs than traditional delivery models for information technology systems.

Security for resource pooling

The risks of multi-tenancy are typically related to either:

• infrastructure virtualisation, or
• data commingling — data being stored in a way that could make it accessible by other customers.

Virtualisation allows information systems to be abstracted from the underlying hardware using a hypervisor.

Access to other customers’ information

A malicious party could exploit a vulnerability within the hypervisor to gain access to other customers’ information. These are done, for example, by attacks that are:

• guest-to-host
• guest-to-guest.

Snapshots of a server’s memory and disk

Virtualisation has made it easy to take a snapshot. This is a copy of a running server’s memory and disk at a point in time for:

• backup
• redundancy.

If the snapshots are not protected well, a malicious party may be able to gain unauthorised access to the:

• information stored on the virtual machine’s local drives
• encryption keys and data stored in its memory.

Protect snapshots

For the virtualisation environment, find out:

• its architecture
• how it’s implemented — that is, put into use
• how the service provider manages and monitors it.

These details, along with the practices for patch and vulnerability management, help government organisations to put the proper information security controls in place.

Platform, Infrastructure and other types of service models

The customer with the weakest security practices and controls may determine the security of the entire environment for:

• Platform as a Service (PaaS)
• Infrastructure as a Service (IaaS)
• other types of service models.

This is called the problem of the lowest common denominator.

Software and Platform service models

Data is usually commingled within the application, database and backup media for:

• SaaS
• PaaS.

SaaS and PaaS services use logical controls to isolate access to each customer’s data within the:

• application or platform
• supporting infrastructure.

Logical controls place complete reliance on the quality of the design, implementation and enforcement of access controls within the platforms and applications.

On-demand self-service

The on-demand self-service characteristic of public cloud services can introduce security concerns. The registration processes to become a customer are not always robust in confirming a customer’s identity — for example, web-based self-registration.

A malicious party can register for a service to then use it for malicious or fraudulent activities. This can include attempts to subvert the access controls to gain unauthorised access to other customers’ data.

Government organisations must be sufficiently assured that other customers using a public cloud service cannot subvert the service provider’s controls to gain access to its data.

Third-party audit reports and penetration testing

There is a strong dependency on third-party audit reports and penetration testing.

The as-a-service nature of public cloud often means a lack of transparency around the security controls and practices that the service provider has in place to protect their customers’ data.

Make sure the service provider:

• is willing to make third-party audit reports available to you
• has credible third-party reports
• allows you to undertake your own security testing — including penetration tests.

Operating environments for public cloud

Identify who is responsible for the components in the service model you’re using. Properly configure and manage components of the public cloud service.

Hardening

A process intended to eliminate a means of attack by:

• turning off nonessential services
• patching vulnerabilities.

Hardening — National Institute of Standards and Technology

Proper configuration and management

One of the biggest causes of information security incidents is poorly configured and managed information systems. Public cloud services are no different — you need to set up proper security configurations.

Security ownership in public cloud services

Government organisations always own the risks of their information in public cloud services — regardless of which service model is used.

Security ownership in all service models

Service models — configure and manage

Government organisations and service providers share responsibilities for configuring and managing security in the different service models for public cloud.

Shared responsibilities for security in each service model

Software as a Service

Even though government organisations have the fewest hands-on security responsibilities in Software-as-a-Service models, they:

• still own the risk
• must make sure their security controls are set up properly — this often means getting help from the technical owner of your information or a subject matter expert.

SaaS

Platform, Infrastructure and other types of service models

Government organisations have more hands-on security responsibilities in:

• PaaS
• IaaS
• other types of service models.

Get the build and hardening standards

For the service models that need more involvement from government organisations, get the build and hardening standards for the operating systems and applications you’re planning to use.

The standards should be defined and documented. They help you to protect your systems against unauthorised access while using the operating systems and applications that you deploy in public cloud services.

Provider’s standards or define your own

In your agreement with the service provider, determine who is responsible for the build and hardening of the operating systems and applications. If you choose to delegate this to the service provider, you’ll need to see if it’s best to:

• accept the provider’s standards
• define your own standards.

Test the services before deploying them

In all cases, it’s important to carry out a penetration test. This way, you can be sure the services are safely deployed in the service model you’re using.

Patch and vulnerability management

Identify who is responsible for patching each component and make sure patches for vulnerabilities happen quickly.

Patch management

The National Institute of Standards and Technology (NIST), defines patch management as the systematic notification, identification, deployment, installation and verification of code revisions for:

• operating systems
• application software.

These code revisions are known as:

• patches
• hot fixes
• service packs.

Patch management — NIST

Vulnerability management

This is part of your organisation’s continuous monitoring of information security. It identifies vulnerabilities that are likely to be used by attackers to compromise a device and use it as a platform from which to extend compromise to the network.

Vulnerability management — NIST

Broad network access and timely patches

One of the benefits of adopting and using public cloud services is improved management of patches and vulnerabilities.

Vulnerabilities exist in all types of information systems. However, public cloud has a characteristic of broad network access — your people have access to the services from any location and many different devices.

This means that government organisations need to make sure that patches are done in a timely manner.

Who patches each component

Government organisations need to be sure they know who is responsible for patching each component of a public cloud service — for example, the:

• application
• operating system
• hypervisor software
• application programming interfaces (APIs).

The type of service model you’re using usually determines who is responsible for the management and maintenance of each component. It’ll be either:

• the government organisation
• the service provider
• or both.

Service models for public cloud

When the service provider is responsible

Government organisations need to make sure that the terms of service and service level agreement specify the maximum time period allowed between a patch being:

• released by a vendor
• applied to all affected systems.

This is called the maximum exposure window.

When the government organisation is responsible

Government organisations need to make sure that it:

• has an effective patch management process
• monitors appropriate sources for vulnerability alerts.

These ensure that you can identify and deploy patches in a timely manner.

Encryption

Check your requirements for encryption — the why, how, who, where and when of the information you need to encrypt.

Limits of encryption for confidentiality

Encryption is often presented as the solution for addressing risks to confidentiality in public cloud services. However, there are important limits to encryptions that government organisations need to consider by determining their encryption requirements.

Requirements for encryption

Government organisations must work out their specific requirements for protecting information using encryption. Think about the following points.

What information needs to be encrypted

For the information you’re holding in a public cloud service, see if you need to encrypt:

• all information
• only certain data types
• just specific database rows, columns or entities.

Why the information needs to be encrypted

You might need to encrypt information to meet the requirements of a policy or standard. Make sure you know which policies or standards apply to your information and organisation.

Government organisations must, for example, meet their obligations under the:

• Official Information Act 1982
• Public Records Act 2005
• Privacy Act 2020.

How the information should be encrypted

See which protocols, algorithms and key lengths you should use to encrypt your information.

Cryptography — NZISM

The interception of data in transit is an inherent risk whenever information goes through a network — especially when it’s not owned or managed by the government organisation, such as the internet or a service provider’s network.

Government organisations must ensure that the public cloud service encrypts all sensitive data, including authentication credentials, in transit. Use only the encryption protocols, algorithms and key lengths approved in the New Zealand Information Security Manual (NZISM).

Who encrypts the information and manages the keys

This will either be your organisation or the service provider.

If a public cloud service is capable of storing data in an encrypted format, government organisations must know if it’s them or the service provider who is responsible for managing the encryption keys — also called cryptographic keys. The NZISM details the practices required to effectively manage cryptographic keys.

Cryptography: key management  — NZISM

If the service provider has access to or manages the cryptographic keys, they’ll be able to decrypt and access the information you’re holding in the public cloud service. This affects jurisdictional risk if encryption is used to treat risks related to information being stored outside New Zealand.

The party that manages the cryptographic keys must have an effective key management plan. This protects the encryption keys from being compromised, which might otherwise lead to the:

• unauthorised disclosure of information
• government organisation no longer being able to access its information
• government organisation not meeting its obligations to certain NZ legislation.

Where the information should be encrypted and decrypted

Work out if the encryption and decryption should be done within:

• your organisation
• the client devices
• the service provider.

When the information needs to be encrypted and decrypted

See if the encryption and decryption need to happen:

• in transit
• by the application — for example, message encryption
• at rest.

While encryption is an effective control for protecting the confidentiality of data at rest, there are limits when the data needs to be processed by a business rule.

Data needs to be unencrypted for business rules in an information system to process it. This may make it impractical or impossible to encrypt data stored within a public cloud service that processes information — instead of just storing it.

Insider threat from the cloud service provider

Check if the service provider has security controls to prevent unauthorised access to your information by the people working there.

Unauthorised access to information

A common concern for government organisations planning to use public cloud services is the unauthorised access to information by the service provider’s employees.

The controls required to manage this risk are no different from those used to protect against malicious insiders within your organisation or a traditional outsource provider.

Find out whether the service provider has these controls in place to ensure its people are reliable, trustworthy and do not pose a security risk to its clients.

Service provider’s location

The level of assurance your organisation can get varies depending on the physical location of the provider’s services and employees.

Limitations of criminal record checks

Criminal record checks are limited because they will not identify job applicants who:

• are untrustworthy but have never been caught or have not been convicted
• were previously trustworthy but have become untrustworthy because they are unhappy at work or their personal circumstances have changed.

Log and monitor employees’ activities

The service provider can manage the limitations of criminal record checks by also logging and monitoring employees’ activities. The provider needs to enforce separation of duties so that any malicious activity requires collusion — people working together for ill-meaning aims. Separation makes malicious activity less likely.

Logging should cover all relevant activities performed by the service provider’s employees that have logical or physical access to equipment or media that has customer data.

The service provider should monitor and review logs to identify any suspicious activity that requires investigation. Duties should also be separated to ensure that logs are protected from unauthorised modification and deletion.

Data persistence — are you able to delete information?

To keep information secure, make sure the service provider offers ways to delete information when it:

• scales down or stops the use of its service
• reuses or throws away equipment.

Equipment is reused or thrown away

See if the service provider has a process to make sure that, when reusing or disposing of equipment, it securely wipes data from:

• ICT equipment
• storage media — such as hard disk drives and backup tapes.

Integrity of the information

There are different levels of protection against data loss and corruption — find out if a service provider meets your organisation’s requirements.

No protection against data loss and corruption

Some service providers do not offer protection against data loss or corruption. Do not use their public cloud services.

Meet the requirements of NZ legislation

Government organisations in New Zealand must meet their obligations under the:

• Public Records Act 2005
• Official Information Act 1982.

If your organisation lacks the specialised knowledge of these Acts, seek advice from either, or both:

• Archives New Zealand
• Ministry of Justice.

Protection against data loss and corruption

When service providers have data backup, they offer it as either:

• part of the base service
• an additional-cost service.

Analyse how the provider protects data

Looking into how the service provider protects data from loss or corruption helps you understand if it can meet your requirements.

Develop and use your strategy for data backups

Government organisations need to have their own strategy for backing up data. Use and test your strategy so you can recover from an incident that results in data loss or corruption. Make sure it can restore to a point that meets your requirements.

Availability of the information

See if the provider meets your organisation’s requirements for keeping its service and your information online.

Service level agreement

Check if the level of availability stated and detailed in the service level agreement meets your requirements.

Define the level of availability

The service level agreement typically specifies the level of expected availability as a performance percentage. Make sure you understand exactly what the defined percentage means and see whether or not these levels meet your requirements for availability.

Scheduled outage windows

Review any scheduled outage windows that are defined in the service level agreement. Make sure they will not harm your business operations.

Some providers can do maintenance activities without needing an outage to their services. If this is the case, make sure the service level agreement says this.

If there’s no mention of outages in the service level agreement, you should not assume they will not happen.

Remedies or compensation for outages

If the service level agreement is breached, you need to know the:

• range of remedies available — this helps the service provider and government organisation to work out a solution
• minimum remedy for an outage
• compensation clauses that take into account the impact on your government organisation if the service is unavailable.

While it’s rare to be able to negotiate contracts for public cloud services, the Government Chief Digital Officer’s examples of terms and conditions can help you to understand what you should be looking for in contracts.

Pay attention to what is best practice for government organisations.

Terms and conditions for negotiating contracts for public cloud services

Denial-of-service attacks

See how your service provider protects its services from denial-of-service attacks, both distributed and economic, and whether they meet your requirements.

Why DoS attacks happen

Any service delivered over the internet has an inherent risk of DoS attacks.

A DoS attack may be launched against the service provider or government organisation.

How public cloud services are at risk of DoS attacks

For DoS attacks, public cloud services can:

• be more visible and attractive targets — multiple organisations using a single service can be seen as a worthwhile opportunity for attackers
• cause collateral damage — government organisations might experience damage from attacks on the service provider or another organisation using the service.

How public cloud services lessen the risk of DoS attacks

Using public cloud services may lessen the impact of some forms of DoS attacks. Service providers often:

• have spare network bandwidth and computing capacity
• use data centres in different locations in the world, paired with protocols and technologies, to distribute network traffic and computer processing.

Distributed denial-of-service attacks

It’s difficult to protect against traffic-based DoS attacks — called distributed denial-of-service (DDoS) attacks. This is because:

• they consume all the available resources
• effective defences against them rely on blocking the source of the attack as close to the attackers’ location as possible.

How to lessen the risk of DDoS attacks

Service providers use protocols and technologies, such as:

• Anycast
• application delivery networks
• content delivery networks.

Economic denial-of-service attacks

One of the benefits of public cloud services is that government organisations can pay for only what they’re using in a service. This can be turned into a disadvantage by economic denial-of-service (EDoS) attacks — also called bill shocks.

A successful EDoS attack may force a service to scale exponentially to the increased demand it’s creating. This results in unusually high charges for resource use.

How to lessen the risk of EDoS attacks

You can reduce the risk of unexpected charges by setting limits in the service’s security configurations. Set the limits for resources used to be near your government organisation’s expected peak usage for a service.

The technical owner or subject matter experts of the current information system can help to properly set these configurations.

Technical context of an information system

Network availability and performance

Check if your network, either directly managed or subscribed to by your organisation, supports using the public cloud service.

Check your network

The availability and performance of public cloud services depends heavily on the supporting network infrastructure. Check that the network services, whether local or international, have adequate levels of:

• bandwidth availability
• latency — this should be low
• packet loss — this should be low.

Business continuity and disaster recovery

See if the plans for business continuity and disaster recovery meet your requirements. Check both your organisation and the service provider.

Check the service provider’s plans

See if the service provider has plans in place that meet the levels you require for:

• business continuity
• disaster recovery.

Check your organisation’s plans

Government organisations must also have plans in place for business continuity and disaster recovery. They should be tested regularly to make sure your organisation can keep offering its services during an outage.

Backup plan — data

Government organisations must meet their obligations under NZ legislation, which requires them to backup their data to keep its integrity.

Backup plan — public cloud service

Another reason for backing up data is so you can change to using another service provider. This can happen because:

• you’ve found a better option — one of the benefits of public cloud services
• the provider has either stopped trading or is withdrawing the service.

Jurisdictional risk

Jurisdictional risk is the risk of lawful access by other governments to NZ data, including NZ government data, held in their jurisdictions. This will apply if the cloud services are provided from locations outside of New Zealand.

Territorial reach

Although often described as part of jurisdictional risk, territorial reach is different in that it is the potential for lawful access by other governments to data held by companies based in other countries and operating in New Zealand. The data may be held within New Zealand, but the cloud service provider may be subject to the legal requirements of their home country.

Factors for assessing jurisdictions and service providers

For jurisdictional risk, there are different factors for assessing jurisdictions and service providers.

Factors — jurisdictions

When looking at jurisdictions, government organisations should consider the following factors.

• Lawful access — the laws that regulate a government’s legal access to data.
• Legal institutions — the robustness of legal institutions that oversee a government’s lawful requests for access to data.
• Privacy frameworks — the protections available for personally identifiable information.

Factors — service providers

When looking at the providers of public cloud services, government organisations should consider the following factors. They should make sure the provider:

• identifies where customer data is stored and backed up — location factor
• informs its customers when it gets unlawful requests to access customer data — informed factor
• only discloses customer data when required by a warrant — disclosure factor
• dedicates resources to reviewing lawful requests to access customer data — review factor
• deletes customer data after the contract is terminated — deletion factor.

Signs of best practice for jurisdictional risk

While it’s rare to be able to negotiate contracts for public cloud services, the Government Chief Digital Officer’s examples of terms and conditions can help you to understand what you should be looking for in contracts.

Terms and conditions for negotiating contracts for public cloud services

Pay attention to what is best practice for NZ government organisations — referred to here as customers. For jurisdictional risk and territorial reach, it’s best practice when the service provider does the following.

Not disclosing customer data

It’s best practice when the service provider, in its service terms, commits to never disclose customer data except when:

• directed by the customer
• required by the law
• defined exceptions happen, such as life-threatening situations — the provider should describe the processes that must be followed in these cases.

Processes for government requests

It’s best practice when the service provider, in its service terms, defines its processes for responding to government requests. The service provider should:

• always redirect the requesting government to contact the customer — in this case, your government organisation
• if possible, narrow the scope of government demands
• always contact the user when information is released — unless legally stopped from doing so
• disclose only the information that is specified in the legal order.

Resources for reviewing government demands for user data

It’s best practice for the service provider to have a dedicated team to review any government demands for user data.

Public reporting

It’s best practice for the service provider to report publicly on the:

• frequency of data requests by country
• results of data requests — especially for commercial services.

Security options for data location

It’s best practice for the service provider to allow its customers to:

• determine where their content will be stored
• specify the circumstances when it may be moved to another jurisdiction.

Jurisdictions commonly used by NZ government organisations

This is not an approved list and it can change to adapt to new legal and privacy conditions. Government organisations can use it as a helpful signpost in their case-by-case risk assessments of public cloud services.

Geographically close — in terms of latency

NZ government organisations tend to use public cloud services that are hosted close to New Zealand:

• Australia
• Singapore
• the United States.

Delays to network availability and performance are part of the risk assessment tool for public cloud services.

Other jurisdictions

Latency is not the only factor when considering jurisdictions. NZ government organisations also tend to use public cloud services that are hosted in:

• the Netherlands
• Germany
• the United Kingdom
• Ireland
• Canada.

Government organisations can use public cloud services hosted in other jurisdictions.

Māori interests in public cloud

If the information you’re looking to use with a public cloud service has information from or about Māori, follow guidance on how to work together on cloud-adoption decisions.

Māori interests in public cloud

Privacy Act 2020 and public cloud

Good privacy practice for public cloud usually looks the same as good privacy practice for any system.

• Only collect the information you need.
• Be clear with people about what you are doing with their information.
• Keep that information safe.
• Make sure the information is accurate and fit for purpose.
• Only use and disclose it for the reason you collected it — unless 1 of the exceptions in the privacy principles applies.

Privacy Act 2020 and the Privacy Principles — Privacy Commissioner

Privacy requirements and public cloud

Here are some specific topics to consider, which can sometimes cause problems in practice with public cloud services.

Privacy Impact Assessments (PIAs)

Do a Privacy Impact Assessment (PIA), sometimes called a privacy risk assessment, before adopting any public cloud service that involves or might involve:

• personal information
• aggregated data derived from personal information.

Doing a PIA ensures that all potential privacy problems have been identified and mitigated.

Public cloud services are often dynamic. Make sure you will be aware of any changes. Also make sure that the PIA is updated when things change, so any new risks are spotted and fixed early.

A PIA should be a ‘living’ document, not something that is done once and forgotten.

Privacy Impact Assessment Toolkit — Privacy Commissioner

Provider contracts

Check provider contracts carefully to make sure they’ll meet the standards expected under New Zealand law. If a contract does not meet New Zealand law, and the provider will not change it, do not engage that provider.

Help with negotiating contracts for public cloud services

Examples of contract provisions

The Privacy Act makes it compulsory for agencies to notify the Privacy Commissioner (and, often, affected individuals) if there is a breach that might create a risk of serious harm.

Contracts should specify that the government organisation will be told if the cloud provider suffers a data breach that either has compromised or may have compromised personal information that the government organisation is responsible for.

Some contracts may specify that any complaints or disputes have to be dealt with in overseas courts. However, any provider that is doing business in New Zealand must comply with New Zealand privacy law.

The New Zealand Privacy Commissioner is the privacy regulator here: it is able to investigate complaints or conduct ‘own motion’ inquiries, and take compliance action as necessary. Any contract provision that attempts to cut off access to the Commissioner is unlikely to be enforceable.

Personal information offshore

If you are sending personal information offshore when using a cloud provider, check whether that provider will be using the information for its own purposes, or whether it’ll only be acting on your organisation’s behalf. If the provider is only acting on your organisation’s behalf, principle 12 of the Privacy Act will not apply, since you are not ‘disclosing’ the information.

Principle 12: Disclosure outside New Zealand — Privacy Commissioner

Due diligence

Do due diligence. Regardless of whether the provider is storing or processing personal information onshore or offshore, make sure the provider has appropriate security safeguards in place to protect the personal information that you entrust to it. The privacy of that information remains your responsibility.

Privacy breaches — Privacy Commissioner

Personally identifiable information (PII) and other information

Check the terminology carefully to make sure you understand what protections are in place. American providers of public cloud services often have privacy policies that distinguish between ‘personally identifiable information’ (PII) and other information.

PII is not a term that is used in New Zealand law. It’s sometimes restricted to certain types of information, rather than including everything that the NZ Privacy Act 2020 calls ‘personal information’.

How long information is stored

Think about how long the information needs to be kept for and make sure it can be deleted from the cloud service once the purpose for using that service has been fulfilled and any archiving requirements are met. This includes deletion of all copies. Indefinite retention is unlikely to comply with New Zealand law.

Clear records of information storage

Keep clear records of what information is stored in the cloud system, and make sure it can be promptly retrieved if a person asks for access to their information. There are strict timeframes for responding to such requests, and the fact the information is stored off premises is not an excuse for delay.

More information

Privacy, security and risk

Public Records Act 2005 and public cloud

Understand the legislation and requirements for managing the data and records you keep.

Using public cloud services to create, store and manage information and records means public-sector organisations’ are subject to the legal responsibilities under the:

• Public Records Act 2005 — New Zealand Legislation
• Information and Records Management standard — Archives NZ.

These requirements apply to information being stored, processed and sent using public cloud services.

Requirements for public records and public cloud

Here are some specific topics to consider, which can sometimes cause problems in practice with public cloud services.

Disposal

Cloud systems used to store and manage public records must be able to:

• identify how long records should be kept
• show what happens once the retention period is met — for example: transfer, destroy or other disposal actions
• carry out full and accurate disposal of public records and associated metadata.

It’s strongly recommended that the ability to dispose of public records be in place before using a public cloud service. Agencies lacking this capability will be unable to meet the disposal requirements of legislation and the mandatory standard.

At a minimum, the business rules of the General Disposal Authorities should be integrated into the cloud system. There should be the intention to incorporate sector or agency-specific disposal rules in the long term.

Disposal: information about legal disposal of public records — Archives NZ

Preservation

Cloud systems used to store and manage public records must be able to actively preserve information and records until they are legally disposed of.

Information and records must be maintained, readable and accessible for as long as they are either:

• required by the organisation
• transferred as public archives.

The cloud system must be able to perform verifiable or auditable checks, or both. These checks detect changes or loss in or across copies — for example: checksum recalculation, fixity checking and identifying missing files. They also support independent integrity checking.

Records must not be changed or altered once they are no longer needed for business use. It’s at this point that legal disposal should be implemented, such as destroy, transfer or other disposal actions.

Best practice guidance on digital storage and preservation — Archives NZ

Metadata

Information and records created, stored, and managed in a public cloud environment must be able to link with their relevant metadata. This provides context and ensures their reliability as evidence.

Search, audit and reporting functions

Information and records hosted in the cloud should be easily discoverable for information requests. This is because the Official Information Act 1982 and the Privacy Act 2020 apply regardless of the location of information and records.

Te Tiriti o Waitangi

Government organisations have general obligations for considering Māori interests in public cloud.

Māori interests in public cloud

Agencies may also have specific requirements under Letters of Commitment or other agreements.

Taonga Tuku Iho (information and knowledge) — Archives NZ

More information

Digital information management

Governance of the information

Check how much control you will have over the information. Review the terms of service and compliance with NZ security requirements.

Terms of service

Public cloud services are a way of outsourcing. Make sure the contract’s terms clearly define ownership of the information and the control you have over it.

Public cloud services as outsourcing

Cloud computing is a way to outsource parts of traditional systems of information technology. Which parts are outsourced depends on the service model you’re using.

Service models for public cloud

Governance controls for public cloud services

For public cloud services, it’s not always possible to fully negotiate all terms in your contract with a service provider.

Help with negotiating contracts for public cloud services

This lack of control is a risk to governance. The main way government organisations can assert control in governance is by carefully reviewing the service provider’s:

• terms in the contract — also called ‘terms of service’
• service level agreement
• key performance indicators
• other metrics that specify the service performance.

Review the contract

Review those areas of the contract to make sure the public cloud service can meet your organisation’s need to protect the information’s:

• confidentiality — including the privacy of all personally identifiable information that will be used in the public cloud service
• integrity
• availability.

Ownership of the information

Government organisations must keep ownership of their information and know how the service provider will use this data when delivering the service.

Use of customer data is usually limited to consumer rather than enterprise contracts. Regardless, government organisations need to know if the service provider will use information for any purpose other than delivering the service.

Review the contract

Make sure the contract’s terms of service:

• clearly define the ownership of data
• state how the information will be used in delivering the service
• say whether or not the service provider will use the data for any purpose other than the delivery of the service.

Service provider outsourcing some of its services

It’s common for service providers to rely on components from other service providers. When assessing the risks of using your information in a public cloud service, identify any dependencies that the service provider has on third-party services.

Knowing who is involved in the service provider’s supply chain will give you a clearer understanding of the risks involved in using information with their public cloud service.

Compliance with NZ security requirements

See if the public cloud service meets NZ security requirements for protecting the information of the NZ government and New Zealanders.

Government responsibilities for information

When using a public cloud service, government organisations must responsibly and respectfully use the information of the NZ government and New Zealanders.

This means government organisations must be sure that security controls are in place to protect, within your organisation’s risk tolerance, the information’s:

• confidentiality
• integrity
• availability.

Using available certifications

Since government organisations often cannot negotiate the terms of a contract with a service provider, they likely cannot:

• specify security controls to protect their data
• directly verify that a service provider has proper controls in place to protect the information.

Even if it’s possible to directly verify a service provider’s controls, it may not be practical to do this if the public cloud service is hosted in a data centre outside New Zealand.

As a result, government organisations must often rely on the service provider setting up third-party audits of its security practices and controls. There are different certifications to show this has been done and they all have different criteria.

Understand the limits of each certification

Government organisations need to sort out which certifications are useful and whether or not they increase their confidence in the service provider’s ability to protect their information.

Even internationally recognised standards and frameworks have limits. You’ll need to check these to see if certifications to these standards and frameworks provide assurance that the provider of a public cloud service meets your organisation’s security requirements.

Openness to sharing audit information

Some service providers are willing to give current and potential customers full audit reports under a non-disclosure and confidentiality agreement.

Others only provide the certificate to show they have passed the audit.

The more transparent the service provider is, the easier it’s for government organisations to assess if the provider has proper security practices and controls in place to meet NZ security requirements.

Cloud Security Alliance (CSA) certifications

There are 3 different levels of assurance that service providers can achieve using the CSA’s Security, Trust, Assurance and Risk (STAR) registry.

CSA STAR certifications are another option for government organisations looking to gather information about a public cloud service’s security.

Level 1 — CSA STAR self-assessment reports

Service providers submit either a completed:

• Consensus Assessments Initiative Questionnaire, or
• Cloud Controls Matrix.

Level 1 STAR: Self-Assessment — CSA

Use Level 1 reports for insight, not assurance

These reports can give insight into the service provider’s security controls and practices. However, the CSA does not guarantee the accuracy of any entries. For submissions, the CSA only:

• verifies their authenticity
• does a basic check of their accuracy.

Level 1 CSA STAR registry

Being listed on the CSA’s Level 1 STAR registry means the service provider has done some level of diligence with a registration body. However, it does not give any assurance that they have proper security practices or controls in place.

Level 1 STAR registry — CSA

Level 2 — CSA STAR certification and attestation

Service providers go through auditing by a third party — one of the CSA’s approved certification bodies. The audits provide either:

• certification, or
• attestation.

Level 2 STAR: Third-Party Audit — CSA

Certification

CSA STAR certification is based on ISO/IEC 27001 and the service provider’s security controls listed in their Cloud Controls Matrix.

ISO/IEC 27001:2013 — International Organization for Standardization

The CSA assesses the service provider’s information security management system. If they have proper security controls in place, the CSA certifies the provider’s security processes.

Attestation

CSA STAR attestation is based on System and Organization Controls (SOC) 2+ and the criteria defined in their Cloud Controls Matrix.

SOC 2+ is part of the Statement on Standards for Attestation Engagements (SSAE) 18.

SOC 2+ for CSA STAR Attestation — SSAE 18

The CSA regularly assesses the service providers to see if their specified controls are in place and fit their description of the service.

Level 2 CSA STAR registry

See which service providers have Level 2 CSA STAR certification or attestation.

Level 2 STAR registry — CSA

Level 3 — CSA STAR continuous auditing certification

Level 3 STAR is not yet available. It’ll offer real-time transparency about the effectiveness of the service provider’s security management practices and controls.

Service providers at Level 3 STAR would work with the CSA using the:

• Cloud Controls Matrix
• Cloud Trust Protocol.

The Evolution of STAR: Introducing Continuous Auditing — CSA

More information — CloudTrust Protocol

• CloudTrust Protocol Information Overview — CSA
• CloudTrust Protocol Data Model and API — CSA

CloudCode — Cloud Computing Code of Practice

Government organisations should only use CloudCode documents for additional information because CloudCode does not have the needed security practices or controls in place.

CloudCode is designed to help New Zealand-based service providers to be transparent about the security of their services.

Cloud Computing Code of Practice — Information Technology Professionals NZ

Any gaps or further certification needed?

Government organisations need to understand the scope and any limitations of certifications that have come from:

• a third party
• another government organisation.

Government organisations might need to perform more assurance steps before using the public cloud service.

Physical security of information

See if physical security controls are in place to protect your information.

What physical security protects against

Physical security controls are needed to make sure that information is protected from unauthorised access by any malicious service-provider:

• personnel
• third parties.

Information security and physical controls

Information security depends on how well physical controls work to protect the service provider’s:

• offices
• data centres
• physical assets.

NZ requirements for physical security

Physical security controls must be in place to adequately protect the information of the NZ government and New Zealanders.

Physical security — PSR

Depending on your information’s classification, see which security controls you need in place.

Physical security — NZISM

When to use third-party audit reports

It’s not always possible or practical to directly assess the physical controls of a service provider. To see if the provider is adequately protecting its customers’ data, you should review recent third-party audit reports that include assessments of their physical security controls.

Example — ISO/IEC 27001 certification — International Organization for Standardization

Example — ISAE 3402 SOC 2 Type II — External Reporting Board

You should not use a public cloud service if:

• third-party audit reports from credible sources are not available
• the provider does not let you review the reports.

Incident response and management

Find out what you can see and control in security incidents — get the right level of assurance from the service provider.

Factors affecting visibility and control of security incidents

What you can see and control in security incidents is different depending on the:

• service models you’re using for public cloud
• type of cloud service you’re using — public cloud or another type.

Incidents occur — find your level of assurance

Even the most carefully planned, used and managed preventative controls can fail to stop a risk from happening. This is why it’s important to get the right level of assurance for your information. It shows that the service provider is capable of effectively and efficiently responding to an information security incident.

Review the service provider’s contract

It’s rare for government organisations to be able to negotiate contracts directly with providers of public cloud services.

When to negotiate direct contracts for public cloud services

Review the contract — either the:

• terms of service, or
• service level agreement.

See what, if any, support the service provider gives to their customers during an information security incident.

See or develop your incident response and management

Government organisations need to have their own processes and plans for incident response and management. They define how the government organisation will handle its responsibilities during an information security incident.

Topics to cover in plans and processes

For your organisation’s incident and response management, make sure your plans and processes cover, for example:

• roles
• responsibilities
• contacts
• incident definitions
• notification criteria
• escalation channels
• evidence collection and preservation
• post-incident activities.

More information

Information security incidents — NZISM