Document 10 FINAL.pdf

ICT Shared Capabilities
Infrastructure as a
Service (IaaS)
Security Risk Assessment
Report
under the Official Information Act 1982
Issued by
Digital Public Service Branch
Released

under the Official Information Act 1982
Released

IN-CONFIDENCE
Glossary of Terms
Availability
Ensuring that authorised users have timely and reliable access to
information.
API
A set of functions and procedures allowing the creation of
applications that access the features or data of an operating
system, application, or other service.
B2B
Business-to-business (B2B), also called B-to-B, is a form of
transaction between businesses
Confidentiality
Ensuring that only authorised users can access information.
Consequence
The outcome of an event. The outcome can be positive or negative.
However, in the context of information security it is usually
negative.
Control
A risk treatment implemented to reduce the likelihood and/or
impact of a risk.
Gross Risk
The risk without any risk treatment applied.
ICT
Information and Communications Technologies
Impact
See Consequence.
Information Security
Ensures that information is protected against unauthorised access
or disclosure users (confidentiality), unauthorised or improper
modification (integrity) and can be accessed when required
(availability).
Integrity
Ensuring the accuracy and completeness of information and
information processing methods.
ISPS Panel
The Information Security Professional Services panel are a group of
industry experts contracted through the Marketplace agreement to
provide government agencies with ICT services and advice on a
range of information security and privacy practices.
Likelihood
See Probability.
NIST
The National Institute of Standards and Technology (NIST) is a
physical sciences laboratory and a non-regulatory agency of the
United States Department of Commerce. Its mission is to promote
innovation and industrial competitiveness.
under the Official Information Act 1982
Probability
The chance of an event occurring.
POC
A proof of concept (POC) is a demonstration to verify that certain
concepts or theories have the potential for real-world application.
Recovery Point Objective
The earliest point time that is acceptable to recover data from. The
(RPO)
RPO effectively specifies the amount of data loss that is acceptable
to the business.
Recovery Time Objective
The amount of time allowed for the recovery of an information
Released
(RTO)
system or service after a disaster event has occurred. The RTO
effectively specifies the amount of time that is acceptable to the
business to be without the system.
Residual Risk
The risk remaining after the risk treatment has been applied.
IaaS Security Risk Assessment Report
IN-CONFIDENCE
Page 4 of 56

IN-CONFIDENCE
Risk
The effect of uncertainty on the business objectives. The effect can
be positive or negative. However, in the context of information
security it is usually negative.
Risk Appetite
The amount of risk that the organisation is willing to accept in
pursuit of its objectives.
Risk Owner
A person or entity with the accountability and authority to manage
a risk. Usually, the business owner of the information system or
service.
Stakeholder
A person or organisation that can affect, be affected by, or
perceive themselves to be affected by a risk eventuating.
Threat
A potential cause of a risk.
Vulnerability
A weakness in an information system or service that can be
exploited by a threat.

under the Official Information Act 1982
Released
IaaS Security Risk Assessment Report
IN-CONFIDENCE
Page 5 of 56

IN-CONFIDENCE

Contents
Document Control
2
Document Information
2
Revision History
2
Document Approval
3
Glossary of Terms
4
Executive Summary
7
Introduction
7
Key IaaS Risks
7
Gross Risks
10
Key Recommendations
11
Residual Risks
13
Business Context
14
Key IaaS Threats
16
Stakeholders
20
Information Classification
20
Business Processes Supported
21
Business Impact
21
Security Requirements
21
Users
22
Legislation, Policy, and Guidelines
22
Information Protection Priorities
23
Detailed Risks
24
Controls Catalogue
41
Appendix A – Project Overview
52
Appendix B – Risk Assessment Guidelines
54
Rating Risk
54
Likelihood (Probability) Assessment
54
Impact (Consequences) Assessment
54

under the Official Information Act 1982
Released
IaaS Security Risk Assessment Report
IN-CONFIDENCE
Page 6 of 56

IN-CONFIDENCE
Executive Summary
Introduction
This report presents the generic findings of an Information Security Risk Assessment1 for the
suppliers of Infrastructure-as-a-Service (IaaS) services and the consumption of these services by New
Zealand government agencies. It also includes the IaaS services that are listed under the
Infrastructure as a Services catalogue2 on Marketplace.
The  Risk Assessment followed the Government Chief Information Officer’s (GCIO)  Risk Assessment
process, which is based on the AS/NZS ISO 31000:2018 and ISO/IEC 27005:2022 risk management
standards.
As this is a high-level  Risk Assessment report, the risks identified, and ratings assessed may be
different and unique in the context of participating agencies. Therefore, agencies reading this report
should review the risks using their own risk management framework. This will ensure that the risks
identified are specific to the agency’s adoption of the IaaS service, are within their business context,
and risk appetite.
This  Risk Assessment incorporates the risks identified in the DIA generic cloud services Risk
Assessment report3 which identifies common risks associated with the consumption of cloud
services. It is recommended that both reports are consumed together.
The details of the Risk Assessment scope can be found in Appendix A. Where PA is used in this
report, it refers to Participating Agency.
9(2)(k)
under the Official Information Act 1982
Released

1 This Risk Assessment report is a refresh & replacement of previous ICT Shared Capabilities IaaS Security Risk Assessment
v1.0 2023_031 and combines the risks from previous version.
2 https://marketplace.govt.nz/about-the-marketplace/whats-open-on-marketplace/
3 GCIO Cloud Services Risk Assessment Report dated March 2017, version 1.1
4 DIA Cloud Services Risk Assessment Report dated March 2017, version 1.1
IaaS Security Risk Assessment Report
IN-CONFIDENCE
Page 7 of 56

IN-CONFIDENCE
9(2)(k)
under the Official Information Act 1982
Released
IaaS Security Risk Assessment Report
IN-CONFIDENCE
Page 8 of 56

IN-CONFIDENCE
9(2)(k)
under the Official Information Act 1982
Released
IaaS Security Risk Assessment Report
IN-CONFIDENCE
Page 9 of 56

IN-CONFIDENCE
Gross Risks
Table 1 illustrates the rating of each risk without any controls in place. The table below includes the
gross risk positions of both IaaS specific and generic cloud risks.
Table 1 – Gross Risk Ratings
9(2)(k)
under the Official Information Act 1982

Released
IaaS Security Risk Assessment Report
IN-CONFIDENCE
Page 10 of 56

IN-CONFIDENCE
Key Recommendations
The  Risk Assessment included key controls that if implemented, helps to address the identified risks.
9(2)(k)
manage the identified gross risks rated
9(2)(k)
the following key recommendations should be undertaken:
a)  Strong Encryption and Secure Key Management
The use of strong encryption to protect data at rest and in transit is a key control to address
confidentiality and integrity risks within the cloud.
Suppliers and PAs should ensure that all requirements for protecting data at rest and in transit
are well defined, configured and implemented. This includes the secure management of
cryptographic keys used to encrypt agency data.
b)  Change, Configuration, and Vulnerability Management
Change, configuration and vulnerability management procedures should be defined and
followed by the supplier, to ensure that the risks associated with misconfigurations and
vulnerabilities that affect IaaS are mitigated. Ensuring that security design reviews are included
in the change management process will minimise the likelihood of vulnerabilities being
introduced, such as vulnerabilities that could lead to data belonging to different tenants not
being adequately segregated.
A robust vulnerability management process to maintain the status of all components of the
underlying infrastructure such as servers, hypervisors, and network devices, should be
developed and followed. This includes regular vulnerability assessments, implementing and
maintaining specific security features, as well as timely software and firmware patching and
updating. The requirements for change and vulnerability management should be included in the
contracts or service level agreements with the supplier.
c)  Contracts and Service Level Agreements
Contracts and service level agreements with the supplier defines the agency’s requirements for
the service. They should include elements such as terms of service, associated service levels, key
performance indicators and metrics demonstrating service performance.
Agencies must ensure that the supplier is aware of agency information security requirements by
formalising contract provisions or service level agreements. In addition, monitoring of
performance should be performed on a regular basis to ensure that expectations are met. This
under the Official Information Act 1982
includes any third parties that may be contracted by the supplier to provide part of an IaaS
service.
d)  Risk Management, Supply Chain Assurance and Due Diligence
Before the consumption of any IaaS services, agencies should be informed and aware of the
implicating risks associated with using the service. This can be done by performing a
comprehensive  Risk Assessment to identify the risks and controls associated with the service. All
identified risks should be understood and formally accepted with an appropriate risk
Released
management plan. The controls identified should be validated or assurance obtained from the
Supplier, to ensure that they are operating as designed.
The amount of due diligence should also extend out to any third parties supporting an IaaS
supplier. While it may not be possible to audit the third-party supplier directly, agencies may be
able to rely on independent third-party audit reports where appropriate.
IaaS Security Risk Assessment Report
IN-CONFIDENCE
Page 11 of 56

IN-CONFIDENCE
e)  Security Incident Response and Resilience
The ability to respond to a security incident if one was to occur is just as important as the
preventative measures, as well as recovering data and infrastructure. Agencies should define
and implement steps and procedures to follow in the event a security incident occurs to
minimise the impact of the incident. This will also help agencies to learn from these incidents to
better prepare themselves if something similar were to happen again.
The robust implementation of backup and restore processes, including documentation, enables
agencies to maintain business as usual in the event of a security incident. These include regularly
updating and maintaining each procedure, plan, and backups needed to resume services in a
timely manner.
f)  Secure Facilities, Access Management and Staff Awareness
Supplier and PA staff that require access to the IaaS components should only be provided with
permissions that they are authorised to use. A robust process that defines user access
management ensures that permissions are appropriately and timely updated, preventing the risk
of unauthorised access and internal threats.
Effective physical controls should be implemented at the Supplier’s facilities and physical assets
to ensure that information is physically protected from unauthorised access by both malicious
supplier personnel and third parties.
Supplier and PA users should be made aware of their requirements towards protecting the
confidentiality of their credentials, including programmatic API keys. Regular staff awareness
and training programs should be developed and made available to users. Topics may include
users’ information security responsibilities within an organisation and good security practices for
storing user credentials.
g)  Logging and Auditing
The presence of in-depth logging and regular auditing of the relevant IaaS components can
enable the suppliers and PA to detect or investigate security incidents associated with the
services, should they occur. Accurate logs provide investigation teams with a precise timeline of
events, enabling a faster response.
h)  Cloud Security Access Brokerage and Data Leak protection
Human errors are a key security threat to organisations. PA staff uploading classified information
under the Official Information Act 1982
or uploading infected files could cause a significant impact to the security of the information. It is
highly recommended for PA to implement the controls like CASB and DLP to reduce this risk to
an acceptable level.
Released
IaaS Security Risk Assessment Report
IN-CONFIDENCE
Page 12 of 56

IN-CONFIDENCE
Residual Risks
The tables below illustrates the expected residual rating of each of the risks if all the recommended controls are implemented and appropriately configured and managed, with respectively only the IaaS supplier controls, and all controls including
Participating Agency controls.

9(2)(k)
under the Official Information Act 1982
Released
IaaS Security Risk Assessment Report
IN-CONFIDENCE
Page 13 of 56

under the Official Information Act 1982
Released

IN-CONFIDENCE
9(2)(k)
under the Official Information Act 1982
Released
IaaS Security Risk Assessment Report
IN-CONFIDENCE
Page 17 of 56

IN-CONFIDENCE
9(2)(k)
under the Official Information Act 1982
Released
IaaS Security Risk Assessment Report
IN-CONFIDENCE
Page 18 of 56

IN-CONFIDENCE
9(2)(k)
under the Official Information Act 1982
Released
IaaS Security Risk Assessment Report
IN-CONFIDENCE
Page 19 of 56

IN-CONFIDENCE
9(2)(k)
Stakeholders
The key stakeholders for generic IaaS services:
•  PA;
under the Official Information Act 1982
•  IaaS Supplier; and
•  Third parties contracted by agencies.
Information Classification
Based on the New Zealand Government Security Classification System6, the information that will be
stored, processed or transmitted by the IaaS service has been classified Classification Removed and below. The
compromise of information classified as Classification Removed can:
Released
•  Adversely affect diplomatic relations;
•  Hinder the operational effectiveness or security of New Zealand or friendly forces; and

6 https://protectivesecurity.govt.nz/classification-system/how-to-classify/
IaaS Security Risk Assessment Report
IN-CONFIDENCE
Page 20 of 56

IN-CONFIDENCE
•  Adversely affect the internal stability or economic wellbeing of New Zealand or friendly
countries.
Business Processes Supported
Each PA will be using the IaaS service to support different types of business processes. Therefore, it
is important for each agency to understand what business processes will be supported and define
the security requirements for the service. This will ensure that agencies understand the security
requirements that the service needs to meet.
Business Impact
Each PA will be using the IaaS service to transmit, store or process different types of information, in
addition to providing access to different information systems and services. Therefore, it is important
for each agency to identify and document the types of information that will be transmitted, stored,
or processed in the Supplier cloud infrastructure. This will ensure that agencies understand the
business impact if the confidentiality, integrity, and availability of the information was compromised.
Security Requirements
The Confidentiality, Integrity, and Availability requirements for the consumption of the IaaS service
have been defined as:
Confidentiality
The confidentiality of the information transmitted, stored, or processed by the IaaS service is
assumed as critical for PAs. This is driven by the classification of information that will be
transmitted, stored, or processed by the service. The information processed in the cloud must
be protected from unauthorised access and disclosure.
If the confidentiality of Classification Removedinformation was compromised, the following impacts are
expected:
•  Disclosure of Classification Removedinformation to unauthorised personnel;
•  Loss of key stakeholder confidence in the IaaS service;
•  Reputation damage for the affected PA; and
•  Further investigation where required by law.
Integrity  under the Official Information Act 1982
The integrity of the information transmitted, stored, or processed by the IaaS service is assumed
as critical for PAs. It is assumed that PAs will be using the service to store and process
information that business processes rely on for decision-making. Inaccurate or corrupted
information can cause PAs to lose their data source of truth and affect business outcomes.
If the integrity of Classification Removedinformation was compromised, the following impacts are
expected:
Released
•  Modification of Classification Removedinformation by unauthorised personnel leading to inaccurate or
corrupted data;
•  Loss of key stakeholder confidence in the IaaS service;
•  Reputation damage for the affected PA; and
•  Further investigation where required by law.
IaaS Security Risk Assessment Report
IN-CONFIDENCE
Page 21 of 56

under the Official Information Act 1982
Released

IN-CONFIDENCE
9(2)(k)
9(2)(k)
IaaS-R06
Information Disclosure, Modification or Loss
due to Compromised User Credentials
9(2)(k)
under the Official Information Act 1982
Released
IaaS-R07
Information Disclosure, Modification or Loss
due to Insecure Supplier Programmatic Access
Credentials
IaaS Security Risk Assessment Report
IN-CONFIDENCE
Page 26 of 56

under the Official Information Act 1982
Released

IN-CONFIDENCE
9(2)(k)
9(2)(k)
IaaS-R16
Information Disclosure, Modification or Loss
due to Supply Chain Compromise
9(2)(k)
GC-R01
Information Disclosure, Modification or Loss
due to Poorly Defined Service Agreements
9(2)(k)
under the Official Information Act 1982
Released
IaaS Security Risk Assessment Report
IN-CONFIDENCE
Page 31 of 56

IN-CONFIDENCE
9(2)(k)
9(2)(k)
GC-R02
Information Disclosure or Loss due to Legal
Jurisdictional Rules
9(2)(k)
GC-R03
Information Disclosure, Modification or Loss
due to Data Distribution
9(2)(k)
under the Official Information Act 1982
GC-R04
Information Disclosure, Modification or Loss
due to Data Lock In
9(2)(k)
Released
IaaS Security Risk Assessment Report
IN-CONFIDENCE
Page 32 of 56

under the Official Information Act 1982
Released

IN-CONFIDENCE
9(2)(k)
9(2)(k)
GC-R07
Information Disclosure, Modification or Loss
due to Inappropriate Use of Cloud Service
9(2)(k)
GC-R08
Information Disclosure, Modification or Loss
due to Incomplete Segregation of Suppliers
Tenant Data
9(2)(k)
under the Official Information Act 1982
GC-R09
Information Disclosure, Modification or Loss
due to Virtualisation Technology
Released
Vulnerabilities
9(2)(k)
IaaS Security Risk Assessment Report
IN-CONFIDENCE
Page 34 of 56

IN-CONFIDENCE
9(2)(k)
9(2)(k)
GC-R10
Information Disclosure, Modification or Loss
due to Insecure Facilities
9(2)(k)
under the Official Information Act 1982
Released
GC-R11
Information Disclosure due to Incomplete
Data Deletion
9(2)(k)
IaaS Security Risk Assessment Report
IN-CONFIDENCE
Page 35 of 56

under the Official Information Act 1982
Released

IN-CONFIDENCE
9(2)(k)
9(2)(k)
GC-R14
Cloud Service Degradation or Outage due to
Inadequate Network and Server Capacity
Management
9(2)(k)
GC-R15
Information Disclosure, Modification or Loss
due to Social Engineering Attacks
9(2)(k)
under the Official Information Act 1982
Released
GC-R16
Information Disclosure due to Incomplete
Segregation of Suppliers Management
Networks
9(2)(k)
IaaS Security Risk Assessment Report
IN-CONFIDENCE
Page 37 of 56

under the Official Information Act 1982
Released

9(2)(k)
IN-CONFIDENCE
9(2)(k)
GC-R22
Information Disclosure, Modification or Loss
due to Insecure Data Migration
9(2)(k)
under the Official Information Act 1982
Released
IaaS Security Risk Assessment Report
IN-CONFIDENCE
Page 40 of 56

under the Official Information Act 1982
Released

IN CONFIDENCE
Table 13 – Controls to Risk Mapping
9(2)(k)
under the Official Information Act 1982
Released
IaaS Security Risk Assessment Report
IN CONFIDENCE
Page 50 of 56

9(2)(k)
under the Official Information Act 1982
Released
IaaS Security Risk Assessment Report
IN CONFIDENCE
Page 51 of 56

IN CONFIDENCE
Appendix A – Project Overview
Scope
The Digital Public Service branch (DPS) as the Government Chief Digital Officer (GCDO) function for
the Department of Internal Affairs (DIA) has produced this Security Risk Assessment report.
The objective was to create a generic Risk Assessment to be used by the suppliers of IaaS services
and use of IaaS by Consuming Agencies when completing the security certification of these services.
The assessment can then be used to frame and provide a basis for future Risk Assessments and
control audits of IaaS.
This IaaS Risk Assessment focused on identifying common risks for IaaS service suppliers and
agencies consuming the IaaS services through ICT Shared Capabilities such as Infrastructure as a
Service (IaaS) or Marketplace.
Infrastructure as a Service (IaaS) is a managed and hosted computing solution for government
agencies containing 4 core services: data centre services, utility compute services, storage and back-
up services. In April 2023, the AoG agreement for Infrastructure as a Service (IaaS) stopped being
required for government organisations. For more information please visit Infrastructure as a Service
| NZ Digital government.
Marketplace is an All-of-Government (AoG) initiative that enables New Zealand and international
businesses offer their products and services directly to New Zealand government agencies.
Marketplace links business with government, making the procurement process easier for all. For
more details, please visit https://marketplace.govt.nz
Marketplace has a list of IaaS products and suppliers that are categorised in Tier 1, Tier 2 and Tier 3.
The Tier 3 a is lower entry bar for small products and suppliers where, Tier 1 is for enterprise grade
products and suppliers that require the highest assurance.
Minimum tier requirement for the scope of this Risk Assessment varies between Tiers 3, 2 and 1
depending on:
•  Risk profile of the service;
•  Use / delivery of cloud-based tools to deliver these services;
•  Reliance on Agency controls, particularly for people and process controls; and
•  Claims made by the Supplier in the service description.
Tier 3: Baseline Index — Suppliers respond to security questions which can include the Cloud Risk
Assessment Tool (GCIO105). Assessment is based on self-assertions and not independent reviews.
IaaS go through a Confidence and Risk Index (CRI) rating by McAfee MVision.
under the Official Information Act 1982
Tier 2: Design and Control Analysis — Suppliers have to provide independent security assurance
information that Consuming Agencies will be able to review. This can include ISO27001 or SOC2 Type
2 audit reports, and penetration testing reports. This information will be reviewed and confirmed
appropriate by the GCDO before Tier-2 endorsement.
Tier 1: Design and Control Effectiveness— To obtain this rating, suppliers have to provide additional
information and receive Certification from the GCDO. Certification is based on  Risk Assessment and
demonstration of controls effectiveness can be supported from an organisation having ISO 27001 or
SOC2 Certification or going through an certification audit by an independent auditor from the
Information Secur
Released  ity Professional Services (ISPS) panel.
Approach
The  Risk Assessment followed the GCDO risk framework based on the AS/NZS ISO 31000:2018 and
ISO/IEC 27005:2022 risk management standards. The assessment was conducted as a series of
workshops and document reviews, including:
IaaS Security Risk Assessment Report
IN CONFIDENCE
Page 52 of 56

IN CONFIDENCE
•  Consumption of documentation provided by DIA;
•  Identification of risks and controls associated with the use of generic cloud services;
•  Development of a  Risk Assessment report in draft; and
•  Issuance of a final  Risk Assessment report.
Documents Referenced
The following documentation was referenced and used to inform the  Risk Assessment:
•  Guidance – risk discovery tool for public cloud (link as consulted on the 07/09/2023)

under the Official Information Act 1982
Released
IaaS Security Risk Assessment Report
IN CONFIDENCE
Page 53 of 56

under the Official Information Act 1982
Released