Licensed by Enterprise Singapore to YOU CHENG HWEE/MR, MAXIMUS CONSULTING PTE LTD

Singapore Standards eShop Order No: 6800066547/Downloaded:2021-05-12

Single user licence only, copying and networking prohibited

TR 82 : 2020
(ICS 35.020; 35.040; 35.240.01)

TECHNICAL REFERENCE

Guidelines for Cloud Native security

Licensed by Enterprise Singapore to YOU CHENG HWEE/MR, MAXIMUS CONSULTING PTE LTD
Singapore Standards eShop Order No: 6800066547/Downloaded:2021-05-12
Single user licence only, copying and networking prohibited

TR 82 : 2020
(ICS 35.020; 35.040; 35.240.01)

TECHNICAL REFERENCE
Guidelines for Cloud Native security

Published by Enterprise Singapore

All rights reserved. Unless otherwise specified, no part of this Technical Reference may
be reproduced or utilised in any form or by any means, electronic or mechanical, including
photocopying and microfilming, without permission in writing from Enterprise Singapore.
Request for permission can be sent to: standards@enterprisesg.gov.sg.

© Enterprise Singapore 2020

ISBN 978-981-49-2536-5
Licensed by Enterprise Singapore to YOU CHENG HWEE/MR, MAXIMUS CONSULTING PTE LTD
Singapore Standards eShop Order No: 6800066547/Downloaded:2021-05-12
Single user licence only, copying and networking prohibited

TR 82 : 2020

The content of this Technical Reference was approved on 27 November 2020 by the Information
Technology Standards Committee (ITSC) under the purview of the Singapore Standards Council.

First published, 2021

ITSC consists of the following members:

Name Representation

Chairman : Mr Chak Kong Soon Individual Capacity

Deputy
Chairman : Mr Harish Pillay Individual Capacity
Advisor : Mr Yap Chee Yuen Individual Capacity
Secretary : Mr Tao Yao Sing Infocomm Media Development Authority of
Singapore
Members : Assoc Prof Benjamin Gan Singapore Management University
Mr Hong Tse Min Infocomm Media Development Authority of
Singapore
Assoc Prof Huang Zhiyong National University of Singapore
Prof Li Xiaoli Institute for Infocomm Research
Mr Sam Liew Singapore Computer Society
Ms Lim Bee Kwan Government Technology Agency
Mr Lim Soon Chia Cyber Security Agency
Mr Kelvin Ng Nanyang Polytechnic
Mr Ong Hian Leong Individual Capacity
Mr Andy Sim SGTech

ITSC set up the Technical Committee on Cloud Computing Standards to oversee the preparation of this
standard. The Technical Committee consists of the following members:

Name Representation

Chairman : Mr Robert Chew Individual Capacity

Secretary : Mr Steven Tan Infocomm Media Development Authority of
Singapore
Members : Dr Anton Ravindran Singapore Computer Society
Mr Chan Kin Chong Individual Capacity
Dr Calvin Chan Meng Lai Singapore University of Social Sciences
Mr Chew Weiqiang Pactera Singapore Pte Ltd
Mr Hammad Rajjoub Individual Capacity
Dr Kang Meng Chow SGTech
Dr Ryan Ko Individual Capacity
Mr Kwa Kim Chiong Information Technology Management
Association
Mr James Loo Information Technology Management
Association

2
COPYRIGHT
Licensed by Enterprise Singapore to YOU CHENG HWEE/MR, MAXIMUS CONSULTING PTE LTD
Singapore Standards eShop Order No: 6800066547/Downloaded:2021-05-12
Single user licence only, copying and networking prohibited

TR 82 : 2020

Members : Mr Kelvin Ng Nanyang Polytechnic

Ms Ng Lay Ngan Institute of Systems Science
Mr Harish Pillay Individual Capacity
Mr Raju Chellam SGTech
Dr Suria P Asai Institute of Systems Science
Mr Tao Yao Sing Infocomm Media Development Authority of
Singapore
Mr Wong Onn Chee Resolvo Systems
Mr Martin Yates Singapore Computer Society

The Technical Committee set up the Working Group on Multi-Tiered Cloud Security to prepare this
standard. The Working Group consists of the following experts who contribute in their individual
capacity:

Name

Convenor : Dr Kang Meng Chow

Deputy
Convenor : Mr Lim Soon Chia
Members : Dr Anton Ravindran
Mr Mandar Bale
Dr Ken Baylor
Mr Chai Chin Loon
Mr Chan Meng Fai
Mr Dave Cheng
Mr Chetan Sansare
Mr Chong Jian Yi
Mr Patrick Choong Wee Meng
Ms Dhana Lakshmi
Mr Gajun Ganendran
Mr Hong Jian Hui
Mr Lucas Kauffman
Mr Richard Koh
Prof Lam Kwok Yan
Dr Lee Hing Yan
Ms Lim May Ann
Mr Loh Chee Keong
Mr Manoj Wadhwa
Mr Mok Boon Poh
Mr Chris Ng Khee Soon
Mr Raju Chellam
Mr Sanjeev Gupta
Mr Andrew Seit
Mr Sim Bak Chor
Mr Suresh Agarwal

3
COPYRIGHT
Licensed by Enterprise Singapore to YOU CHENG HWEE/MR, MAXIMUS CONSULTING PTE LTD
Singapore Standards eShop Order No: 6800066547/Downloaded:2021-05-12
Single user licence only, copying and networking prohibited

TR 82 : 2020

Members : Mr Tao Yao Sing

Ms Irene Wang
Mr Wong Onn Chee
Mr Xiang Bin
Mr Zhuang Haojie

The organisations in which the experts of the Working Group are involved are:

AliCloud
Amazon Web Services
Asia Cloud Computing Association
Association of Information Security Professionals
BSI Group Singapore Pte. Ltd.
Certification Partner Global
Cloud Security Alliance APAC
Cyber Security Agency
Ernst & Young CertifyPoint B.V.
Google Cloud
Government Technology Agency
IBM Softlayer Cloud
Infocomm Media Development Authority of Singapore
Microsoft Cloud Services
Salesforce.com
SCS Cloud Chapter
SGTech, Cloud and Data Chapter
Singapore Chinese Chamber of Commerce and Industry
SOCOTEC Certification Singapore
TÜV SÜD PSB Pte Ltd

4
COPYRIGHT
Licensed by Enterprise Singapore to YOU CHENG HWEE/MR, MAXIMUS CONSULTING PTE LTD
Singapore Standards eShop Order No: 6800066547/Downloaded:2021-05-12
Single user licence only, copying and networking prohibited

TR 82 : 2020

Contents
Page

Foreword 7

1 Scope 8
2 Normative references 8
3 Terms and definitions 8
4 Abbreviated terms 9
5 Introduction to Cloud Native 10
6 Information security management 18
7 Human resources 18
8 Risk management 19
9 Third party 19
10 Legal and compliance 19
11 Incident management 19
12 Data governance 19
13 Audit logging and monitoring 20
14 Secure configuration 21
15 Security testing and monitoring 22
16 System acquisitions and development 23
17 Encryption 23
18 Physical and environmental 24
19 Operations 24
20 Change management 25
21 Business continuity planning (BCP) and disaster recovery (DR) 25
22 Cloud services administration 25
23 Cloud user access 25
24 Tenancy and customer isolation 26

Tables
1 Characteristics and benefits 11
2 Challenges and concerns 12
3 Threats landscape 13

Figures
1 Relationships between characteristics of Cloud Native architecture 10
2 DevOps pipeline related concepts 12
3 Simplified component view of Containers 16

5
COPYRIGHT
Licensed by Enterprise Singapore to YOU CHENG HWEE/MR, MAXIMUS CONSULTING PTE LTD
Singapore Standards eShop Order No: 6800066547/Downloaded:2021-05-12
Single user licence only, copying and networking prohibited

TR 82 : 2020

Page

4 Simplified component view of Microservices deployment 16

5 Simplified component view of DevOps pipeline 17
6 Shared responsibility model 18

Bibliography 28

6
COPYRIGHT
Licensed by Enterprise Singapore to YOU CHENG HWEE/MR, MAXIMUS CONSULTING PTE LTD
Singapore Standards eShop Order No: 6800066547/Downloaded:2021-05-12
Single user licence only, copying and networking prohibited

TR 82 : 2020

Foreword

This Technical Reference (TR) was prepared by the Working Group on Multi-Tiered Cloud Security
Working Group set up by the Technical Committee on Cloud Computing Standards under the purview
of ITSC.

Cloud Computing shifts away from conventional hosting and delivery of services, to utility-based
consumption in both the enterprise and personal space. In the midst of building Cloud Native
applications, traditional IT security models are no longer adequate.

In operating cloud user virtual environments, shared responsibility model emerged as Cloud Service
Providers (CSPs) focus on protecting the underlying global infrastructure that supports the virtual cloud
environments that cloud users build and configure to safeguard their applications. In offering Cloud
Native services, there is a need to lay out a set of security best practices to guide CSPs to mitigate
security risks and vulnerabilities that may be present in Cloud Native architectures.

This TR provides guidance on Cloud Native security for relevant controls specified in SS 584, to mitigate
vulnerabilities that are applicable for CSP.

This TR is a provisional standard made available for application over a period of three years. The aim
is to use the experience gained to update the TR so that it can be adopted as a Singapore
Standard. Users of the TR are invited to provide feedback on its technical content, clarity and ease of
use. Feedback can be submitted using the form provided in the TR. At the end of the three years, the
TR will be reviewed, taking into account any feedback or other considerations, to further its development
into a Singapore Standard if found suitable.

In preparing this TR, reference was made to SS 584 : 2020, “Specification for multi-tiered cloud
computing security”.

Attention is drawn to the possibility that some of the elements of this TR may be the subject of patent
rights. Enterprise Singapore shall not be held responsible for identifying any or all of such patent rights.

NOTE

1. Singapore Standards (SSs) and Technical References (TRs) are reviewed periodically to keep abreast of technical
changes, technological developments and industry practices. The changes are documented through the issue of
either amendments or revisions. Where SSs are deemed to be stable, i.e. no foreseeable changes in them, they will be
classified as “Mature Standards”. Mature Standards will not be subject to further review, unless there are requests to review
such standards.

2. An SS or TR is voluntary in nature except when it is made mandatory by a regulatory authority. It can also be cited in
contracts making its application a business necessity. Users are advised to assess and determine whether the SS or TR is
suitable for their intended use or purpose. If required, they should refer to the relevant professionals or experts for advice on
the use of the document. Enterprise Singapore and the Singapore Standards Council shall not be liable for any damages
whether directly or indirectly suffered by anyone or any organisation as a result of the use of any SS or TR. Although care
has been taken to draft this standard, users are also advised to ensure that they apply the information after due diligence.

3. Compliance with a SS or TR does not exempt users from any legal obligations.

7
COPYRIGHT
Licensed by Enterprise Singapore to YOU CHENG HWEE/MR, MAXIMUS CONSULTING PTE LTD
Singapore Standards eShop Order No: 6800066547/Downloaded:2021-05-12
Single user licence only, copying and networking prohibited

TR 82 : 2020

Guidelines for Cloud Native security

1 Scope
This Technical Reference (TR) provides additional guidance for relevant controls specified in SS 584 :
2020, to mitigate vulnerabilities specific to Cloud Native architecture that are applicable for the Cloud
Service Provider (CSP). This TR should be used together with SS 584, as it excludes the guidance for
common implementation contained in SS 584.

This TR defines three common characteristics of Cloud Native architecture, as follows:

1. Use of Container technologies;

2. Use of Microservices-based technologies; and
3. Use of DevOps pipeline.

Currently, the use of Container technologies and Microservices-based technologies is growing amongst
CSPs. It will be the primary focus of this TR.

Container and Microservices-based technologies are provided as software services to help users run,
scale and secure containerised applications. The CSP should incorporate security best practices as
part of their software development lifecycle process.

The recommendations in this TR are relevant for the CSP’s implementation of Cloud Native
technologies and service offerings.

2 Normative references
There are no normative references in this standard.

3 Terms and definitions

For the purposes of this TR, the following terms and definitions apply.

3.1 Artefact repository

A software for storing and managing articles from a build. The articles from the repository will subsequently
be used in runtime environments or as inputs to other builds.

3.2 Base images

The container images used as a foundation to build more specialised container images.

3.3 CI/CD orchestrator

A software to automate the control and coordination of continuous integration and continuous
delivery/deployment processes.

3.4 Cloud Native

The development and operation of applications as Microservices, built upon container technologies and
integrated continuously using the DevOps pipeline.

8
COPYRIGHT
Licensed by Enterprise Singapore to YOU CHENG HWEE/MR, MAXIMUS CONSULTING PTE LTD
Singapore Standards eShop Order No: 6800066547/Downloaded:2021-05-12
Single user licence only, copying and networking prohibited

TR 82 : 2020

3.5 Code repository

A software for storing and managing source codes, build instructions and documentation created by
developers.

3.6 Container

A technology to standardise packaging of software, with its dependencies (excluding OS), for rapid
deployment to multiple computing environments.

3.7 Container orchestrator

A software to automate the deployment, monitoring and management of containers.

3.8 Continuous delivery

A software development practice that extends continuous integration to automate the delivery of
integrated software to a staging environment.

3.9 Continuous deployment

A software development practice that extends continuous delivery to automate the deployment of
approved software to production environment.

3.10 Continuous integration (CI)

A software development practice that automates the testing and integration of changes to codes.

3.11 Service registry

A software to register, discover and manage information and status of services.

4 Abbreviated terms
API Application Programming Interface
BCP Business Continuity Planning
CD Continuous Delivery/Deployment
CI Continuous Integration
CLI Command Line Interface
CSC Cloud Service Customer
CSP Cloud Service Provider
DR Disaster Recovery
IDE Integrated Development Environment
IP Internet Protocol
MFA Multi Factor Authentication
MiTM Man-in-The-Middle
OS Operating System
VPC Virtual Private Cloud

9
COPYRIGHT
Licensed by Enterprise Singapore to YOU CHENG HWEE/MR, MAXIMUS CONSULTING PTE LTD
Singapore Standards eShop Order No: 6800066547/Downloaded:2021-05-12
Single user licence only, copying and networking prohibited

TR 82 : 2020

5 Introduction to Cloud Native

5.1 Overview

Clause 5 aims to establish a common understanding of the Cloud Native fundamentals and an overview
of its concepts, characteristics, benefits, challenges and concerns.

5.2 Characteristics and benefits

Figure 1 illustrates the relationships between the cloud infrastructure, containers, Microservices and
DevOps pipeline in the context of Cloud Native architecture, where:

1. Containers are the foundational building blocks of Cloud Native architecture. They
standardise the packaging of application software and their environments so that
application can be deployed easily and remain portable across different cloud
infrastructure.

2. Microservices are small software components designed to perform well defined and
standalone tasks. A Cloud Native application can be composed of one or more
Microservices. Microservices runs within different containers.

3. DevOps pipeline consists of processes and automation tools used for the
development, testing, deployment and operation of Cloud Native applications and the
underlying infrastructure.

Figure 1 depicts containers running on top of ‘plain vanilla’ cloud infrastructure, while Microservices
running within containers and DevOps pipeline to manage the development and operations lifecycle.

Figure 1 – Relationships between characteristics of Cloud Native architecture

10
COPYRIGHT
Licensed by Enterprise Singapore to YOU CHENG HWEE/MR, MAXIMUS CONSULTING PTE LTD
Singapore Standards eShop Order No: 6800066547/Downloaded:2021-05-12
Single user licence only, copying and networking prohibited

TR 82 : 2020

Table 1 provides a summary of the characteristics and benefits of Cloud Native architecture.

Table 1 – Characteristics and benefits

Characteristics Benefits

Containers  A virtualisation technology  Consume less system resource

 Lightweight and are more scalable
 Simplify packaging and  Packages are self-contained and
deployment of software easy to deploy
application  Increased portability across
 Reliable and portable across different infrastructure
environments
Microservices  A software architectural style  Small code size is easy to
 Componentised services, maintain and get right
organised around business  Microservices organised around
capabilities business capabilities are more
 Loosely coupled reusable
 Independently deployable  Technology agnostic
 Evolutionary design
DevOps  Consists of processes and  Deliver products and value at a
pipeline automation tools for the full faster pace
Software Development Lifecycle  Improved collaboration between
 A set of software development development and operations
practices that combines software teams
development and IT operations  Automation can ensure that
systems are updated and patched
quickly

5.3 DevOps pipeline concepts

This clause provides related concepts and their relationships, necessary for the understanding of the
DevOps pipeline.

Figure 2 depicts the DevOps lifecycle and related concepts.

The DevOps lifecycle covers all stages of development and operational stages of a software. The
development stages are defined as plan, code, build and test. The operational stages are defined as
release, deploy, operate and monitor.

Figure 2 highlights that selective transitions between development and operational stages can be highly
automated. Agile development is realised when the transition from code to build stage is automated.
Continuous integration (CI) encompasses agile development and is realised when transition from build
to test stage is also automated. Continuous delivery encompasses continuous integration and is
realised when transition from test to release stage is also automated. Continuous deployment
encompasses continuous integration and is realised when transition from release to deploy stage is
also automated. In addition, continuous monitoring (via alerts, insights that help teams mitigate issues
and improve the product) and configuration management (to track, state and avoid drift) are equally
important concepts, particularly when it comes to developing Cloud Native applications.

The DevOps pipeline encompasses a CI/CD pipeline and may further automate the transition from
deploy and operate stage and the transition from operate and monitor stage. To reflect the iterative
nature of the DevOps pipeline, the stages are also depicted into a cycle.

11
COPYRIGHT
Licensed by Enterprise Singapore to YOU CHENG HWEE/MR, MAXIMUS CONSULTING PTE LTD
Singapore Standards eShop Order No: 6800066547/Downloaded:2021-05-12
Single user licence only, copying and networking prohibited

TR 82 : 2020

Figure 2 – DevOps pipeline related concepts

5.4 Challenges and concerns

Although the adoption of Cloud Native architecture brings many benefits, both the CSPs and CSCs
should also be mindful of its associated challenges and concerns. The guidance on mitigating the
common concerns and potential threats of Cloud Native architecture is provided from Clause 6 onwards.

Table 2 gives a summary of the associated challenges and concerns of Cloud Native architecture.

Table 2 – Challenges and concerns

Common challenges Common Concerns

Containers  Container images, libraries,  Vulnerabilities are pervasive and

runtime and host OS may have may not be mitigated in time
vulnerabilities  Malicious activities are not
 Typical security tools may not detected
provide visibility into containers  Leakage of keys and credentials
and not integrated with container
tools
 Difficult to manage keys and
credentials for codes and image
verifications
Microservices  Managing an application that is  Unable to monitor an application
composed of many Microservices during a breach or to log for
 Distributed data flows between forensic purposes
many Microservices  Data may be compromised in
 Dependencies between transit
Microservices not well understood

12
COPYRIGHT
Licensed by Enterprise Singapore to YOU CHENG HWEE/MR, MAXIMUS CONSULTING PTE LTD
Singapore Standards eShop Order No: 6800066547/Downloaded:2021-05-12
Single user licence only, copying and networking prohibited

TR 82 : 2020

DevOps  CI/CD components and tools are  Untrustworthy components may

pipeline sourced from multiple third-party or be introduced
open-sourced  Improper access rights
 More people need access to  Misconfigurations may happen
development and operation
 Rapid changes and deployment

Table 3 gives a summary of the potential threats to Cloud Native architecture.

Table 3 – Threats landscape

Threat Container Microservices DevOps pipeline

category

Spoofing  Compromised third-  MiTM attack, e.g.  MiTM attack, e.g.

party container messaging between control flows
components and tools Microservices between managers
 Unverified container  Compromised third-  Compromised third-
registries and images party Microservices party CI/CD
 Compromised components and components and
software updates and tools tools
patches  Unverified  Unverified CI/CD
 Unverified container application registries registries/repositories
runtime and images and images
 Unverified container  Compromised  Compromised
cluster and nodes software updates software updates
and patches and patches
 Unverified
Microservices
instances
Tampering  Tampering of  Tampering of  Tampering of
container images Microservice images configuration scripts
 Tampering of  Tampering of inputs  Tampering of build
container runtime to API tools
 Tampering of host OS  Tampering of
 Tampering of automation scripts
communication  Tampering of update
and patches
 Tampering of log
data
Repudiation  Unsigned container  Unsigned  Lack of versioning of
images Microservice images configurations of the
 Unsigned host OS CI/CD tools
 Unauthenticated
user actions
 Unauthenticated
operator actions

13
COPYRIGHT
Licensed by Enterprise Singapore to YOU CHENG HWEE/MR, MAXIMUS CONSULTING PTE LTD
Singapore Standards eShop Order No: 6800066547/Downloaded:2021-05-12
Single user licence only, copying and networking prohibited

TR 82 : 2020

Threat Container Microservices DevOps pipeline

category
Information  Exposed container  Exposed source  Exposed
Disclosure volume codes configuration scripts
 Exposed container  Exposed keys and  Exposed automation
images credentials scripts
 Exposed container  Exposed sensitive  Exposed keys and
configurations data credentials
 Exposed keys and  Exposed  Exposed sensitive
credentials Microservices data, including test,
 Exposed metadata log and backup data
communication  Exposed  Exposed
between containers communication communication
 Exposed between across CI/CD
communication Microservices pipeline
between container  Compromised
and host monitoring tools
 Compromised
container lifecycle
Denial of  Exposed ports  Dependency  Abuse of deployment
Service  Abuse of container between tools
resource Microservices
 Abuse of cloud  Abuse of API calls
infrastructure
Elevation of  Unauthorised access  Unauthorised  Unauthorised access
privilege to container images access to software to IDE
and registries libraries and  Unauthorised access
 Unauthorised use of registries to build tools
container tools  Unauthorised  Unauthorised access
 Unauthorised access access to to deployment tools
to container volume Microservices  Unauthorised access
 Unauthorised  Unauthorised to CI/CD orchestrator
configurations Microservices  Unauthorised access
 Unauthorised access running in privilege to test tools
between container mode  Unauthorised access
instances to admin console
 Unauthorised  Unauthorised access
installation of software to data and logs
packages  Unauthorised
configurations
 Unauthorised
installation of
software
 Unauthorised import
and export of data

14
COPYRIGHT
Licensed by Enterprise Singapore to YOU CHENG HWEE/MR, MAXIMUS CONSULTING PTE LTD
Singapore Standards eShop Order No: 6800066547/Downloaded:2021-05-12
Single user licence only, copying and networking prohibited

TR 82 : 2020

5.5 Component views

This clause provides three simplified component views of Cloud Native architecture.

Figure 3 provides a component view on the use of containers. The components shown are not
exhaustive.

Each container is defined by its base image, binaries / libraries and application Microservices. For
applications that are Microservices-based, Figure 4 provides further elaboration. Multiple containers are
executed by a container runtime that is hosted on a common operating system and sharing resources.
While the underlying infrastructure can be a physical hardware or virtual machines instance, as defined
in cloud infrastructure.

This setup can be further organised into nodes and nodes into clusters to provide scalability.

The Container Orchestrator is responsible for the automation of deployment, monitoring and
management of containers. While container registry stores validated and approved container images
for instantiating the containers by the Container Orchestrator. This TR does not cover guidance for the
Container Orchestrator as it is not exposed to the CSCs.

Figure 4 provides a component view on the use of Microservices. The components shown are not
exhaustive.

In Microservices-based technologies, services are self-contained, lightweight and highly scalable. A

typical application is composed of many Microservices and fronted by an application gateway to support
multiple types of user interfaces. Microservices have defined business capabilities (for example, access
to data store, remote services, legacy systems, etc) and are shared across applications.

Event-driven communication between Microservices is an industry best practice to achieve loose-

coupling and high performance. Either messaging or service mesh may be used. Communications
between Microservices and non-Microservices may require additional protocol mediation.

Troubleshooting can be difficult because of the distributed nature of Microservices. One best practice
requires Microservices to log state changes centrally as events to provide traceability and visibility of
operations across chains of Microservices.

Furthermore, the Service Registry and discovery mechanisms are required to support the dynamic
lifecycle of Microservices. Microservice instances record their availability at the Service Registry and its
clients use the service discovery mechanism to locate it for invocation.

With respect to the container view, Microservices are hosted within individual containers. In addition,
other Microservices view components, such as application gateway, Service Registry, etc, may also be
hosted in containers.

15
COPYRIGHT
Licensed by Enterprise Singapore to YOU CHENG HWEE/MR, MAXIMUS CONSULTING PTE LTD
Singapore Standards eShop Order No: 6800066547/Downloaded:2021-05-12
Single user licence only, copying and networking prohibited

TR 82 : 2020

Figure 3 – Simplified component view of Containers

Figure 4 – Simplified component view of Microservices deployment

16
COPYRIGHT
Licensed by Enterprise Singapore to YOU CHENG HWEE/MR, MAXIMUS CONSULTING PTE LTD
Singapore Standards eShop Order No: 6800066547/Downloaded:2021-05-12
Single user licence only, copying and networking prohibited

TR 82 : 2020

Figure 5 provides a plausible component view on the use of the DevOps pipeline by the CSP. The
components shown are logically and not exhaustive.

Increasingly, CSPs develop and operate their Cloud Native environments (test, staging and production)
using automated CI/CD pipelines. The DevOps pipeline has its associated set of tools and control/data
flows that require additional security considerations. Test, staging and production environments may be
further broken down through the container and Microservices views, as elaborated by Figure 3 and
Figure 4.

At the development phase, CSP developers manage multiple versions of source codes, configuration
files, build scripts and test scripts through the code repository. The CI/CD Orchestrator receives a
notification when new versions are available and starts the build process. After a successful build, the
build tools deposit the executables/binaries/scripts into the artefact repository. Next, the CI/CD
Orchestrator invokes the container builder to package the executables/binaries/scripts into self-
contained images. Similarly, the container builder only deposits viable container images into the
container registry.

Next, the CI/CD Orchestrator instructs the Container Orchestrator to deploy the container images into
the test environment for unit testing and subsequently into the staging environment for system
integration testing. After testing, test results are deposited into the artefact repository. CSP
administrators have access to the CI/CD Orchestrator and Container Orchestrator and can manually
promote the tested codes into the production environment.

At the operational phase, the operators monitor and manage the production environment, its services
and applications through the system management software. The system management software gains
visibility to the operating status of containers through the Container Orchestrator.

Figure 5 – Simplified component view of DevOps pipeline

17
COPYRIGHT
Licensed by Enterprise Singapore to YOU CHENG HWEE/MR, MAXIMUS CONSULTING PTE LTD
Singapore Standards eShop Order No: 6800066547/Downloaded:2021-05-12
Single user licence only, copying and networking prohibited

TR 82 : 2020

5.6 Shared responsibility model

Security is a shared responsibility between the CSPs and CSCs.

Figure 6 depicts a shared responsibility model for Cloud Native architecture with examples of possible
CSP offerings.

The CSPs and CSCs are both responsible for the components offered (cloud infrastructure, container
technologies, Microservices and DevOps tools). The CSCs are always responsible for defining
appropriate access and protection for their application data and user interfaces.

Figure 6 – Shared responsibility model

6 Information security management

The implementation guidance associated with “Information security management” controls in SS 584
should apply.

7 Human resources

7.1 General

Clause 7 and the associated implementation guidance and other information specified in SS 584 should
apply. The following clauses are additional to the “Human resources” controls in SS 584 with specific
implementation guidance for Cloud Native architecture.

7.2 Level 1

The CSP should ensure that the workforce is trained in cyber security considerations and controls
specific to Cloud Native technologies and tools in use.

18
COPYRIGHT
Licensed by Enterprise Singapore to YOU CHENG HWEE/MR, MAXIMUS CONSULTING PTE LTD
Singapore Standards eShop Order No: 6800066547/Downloaded:2021-05-12
Single user licence only, copying and networking prohibited

TR 82 : 2020

The cloud service auditor should validate the existence of Cloud Native technology related topics in the
employee's training syllabus and check the training records (or equivalent) to verify attendance.

7.3 Level 2

There is no additional implementation guidance for Cloud Native architecture specific to this level.

7.4 Level 3

There is no additional implementation guidance for Cloud Native architecture specific to this level.

8 Risk management
The implementation guidance associated with “Risk management” controls in SS 584 should apply.

9 Third party
The implementation guidance associated with “Third party” controls in SS 584 should apply.

10 Legal and compliance

The implementation guidance associated with “Legal and compliance” controls in SS 584 should apply.

11 Incident management
The implementation guidance associated with “Incident management” controls in SS 584 should apply.

12 Data governance

12.1 General

Clause 12 and the associated implementation guidance and other information specified in SS 584
should apply. The following clauses are additional to the “Data governance” controls in SS 584 with
specific implementation guidance for Cloud Native architecture.

12.2 Level 1

The CSP should ensure that container images offered to CSCs are version-controlled and managed in
repositories.

The cloud service auditor should check that a process is in place to ensure that the container images
offered to the CSCs are labelled with version number(s) and that the container images are properly
maintained in repositories.

12.3 Level 2

The implementation guidance for the CSP are those in Level 1 and in addition should ensure that data
access is restricted to authorised Microservices.

19
COPYRIGHT
Licensed by Enterprise Singapore to YOU CHENG HWEE/MR, MAXIMUS CONSULTING PTE LTD
Singapore Standards eShop Order No: 6800066547/Downloaded:2021-05-12
Single user licence only, copying and networking prohibited

TR 82 : 2020

The implementation guidance for the cloud service auditor are those in Level 1 and in addition the cloud
service auditor should check that appropriate data access controls (e.g. role-based access control) are
in place to allow only authorised Microservices to access data.

12.4 Level 3

The implementation guidance for the CSP are those in Level 2 and in addition should ensure that
container images undergo an appropriate integrity check (e.g. digital signatures) before storage and
before being offered to the CSCs.

The implementation guidance for cloud service auditor are those in Level 2 and in addition the cloud
service auditor should check that there is a process in place to perform integrity check(s) on the
container images before storage and before being offered to the CSCs.

13 Audit logging and monitoring

13.1 General

Clause 13 and the associated implementation guidance and other information specified in SS 584
should apply. The following clauses are in addition to the “Audit logging and monitoring” controls in
SS 584 with specific implementation guidance for Cloud Native architecture.

13.2 Level 1

The CSP should:

a) Ensure that logging capability is provided for API calls and container runtime; and

b) Ensure that monitoring service executes with least privileges outside containerised
applications.

The cloud service auditor should:

a) Check that logging capability is enabled and verify that logs by API calls and container runtime
are tracked; and

b) Check that a process is in place to ensure that the monitoring function and access rights are
executed with least privileges outside containerised applications.

13.3 Level 2

The implementation guidance for the CSP are those in Level 1 and in addition the CSP should ensure
that the security of container operations is visible and capable of being monitored.

The implementation guidance for cloud service auditor are those in Level 1 and in addition the cloud
service auditor should check that a monitoring process is in place to provide visibility into the security
of container operations.

13.4 Level 3

There is no additional implementation guidance for Cloud Native architecture specific to this level.

20
COPYRIGHT
Licensed by Enterprise Singapore to YOU CHENG HWEE/MR, MAXIMUS CONSULTING PTE LTD
Singapore Standards eShop Order No: 6800066547/Downloaded:2021-05-12
Single user licence only, copying and networking prohibited

TR 82 : 2020

14 Secure configuration

14.1 General

Clause 14 and the associated implementation guidance and other information specified in SS 584
should apply. The following clauses are in addition to the “Secure configuration” controls in SS 584 with
specific implementation guidance for Cloud Native architecture.

14.2 Level 1

The CSP should:

a) Ensure that Microservices and containers are securely configured, with the provision of access
control(s).

b) Ensure that Microservices and containers are executed with least privileged access rights and
with specific configurations to meet its intended objectives.

The cloud service auditor should:

a) Check that there are preventive mechanisms (such as access control) in place for the secure
configuration of Microservices and containers.

b) Check that Microservices and containers have least privileged access rights and with specific
configurations to meet its intended objectives.

14.3 Level 2

The implementation guidance for the CSP are those in Level 1 and in addition the CSP should provide:

a) Container images that are properly hardened against known/published vulnerabilities;

b) Container images that are provisioned with pre-determined components and libraries that are
used by authorised Microservices; and

c) Microservices which are executed using reviewed container images only.

The implementation guidance for cloud service auditor are those in Level 2 and in addition the cloud
service auditor should:

a) Verify that container images are hardened in accordance with CSP internal or against
known/published vulnerabilities;

b) Check that a process is in place to pre-determine that the provisioned components and libraries
are used by the authorised Microservices; and

c) Check that a process is in place to review the container images that are executed by the
authorised Microservices.

14.4 Level 3

There is no additional implementation guidance for Cloud Native architecture specific to this level.

21
COPYRIGHT
Licensed by Enterprise Singapore to YOU CHENG HWEE/MR, MAXIMUS CONSULTING PTE LTD
Singapore Standards eShop Order No: 6800066547/Downloaded:2021-05-12
Single user licence only, copying and networking prohibited

TR 82 : 2020

15 Security testing and monitoring

15.1 General

Clause 15 and the associated implementation guidance and other information specified in SS 584 apply.
The following clauses are in addition to the “Security testing and monitoring” controls in SS 584 with
specific implementation guidance for Cloud Native architecture.

15.2 Level 1

The CSP should:

a) Ensure that API calls are monitored for security violations; and

b) Ensure that vulnerability scanning and monitoring are employed for components provided by
the CSP.

The cloud service auditor should:

a) Verify the existence of monitoring capabilities on API calls for security violations; and

b) Check that vulnerability scanning and monitoring are employed for components provided by
the CSP.

15.3 Level 2

The implementation guidance for the CSP are those in Level 1 and in addition the CSP should:

a) Ensure that container images are scanned for vulnerabilities; and

b) Ensure that continuous identification of newly published vulnerabilities in the Cloud Native
system are established, to keep pace with any threat developments.

The implementation guidance for cloud service auditor are those in Level 1 and in addition the cloud
service auditor should:

a) Check on the processes of the vulnerability scanning of the container images and track the last
scanned date(s); and

b) Determine that processes are in place to identify and assess newly published vulnerabilities of
the Cloud Native system.

15.4 Level 3

The implementation guidance for the CSP are those in Level 2 and in addition the CSP should ensure
least-privileged access is enabled to avoid unauthorised modification(s) of the container runtime and
configurations.

The implementation guidance for cloud service auditor are those in Level 2 and in addition the cloud
service auditor should check that a process is in place to enable least-privileged access of container
runtime and configurations.

22
COPYRIGHT
Licensed by Enterprise Singapore to YOU CHENG HWEE/MR, MAXIMUS CONSULTING PTE LTD
Singapore Standards eShop Order No: 6800066547/Downloaded:2021-05-12
Single user licence only, copying and networking prohibited

TR 82 : 2020

16 System acquisitions and development

16.1 General

Clause 16 and the associated implementation guidance and other information specified in SS 584
should apply. The following clauses are in addition to the “System acquisitions and development”
controls in SS 584 with specific implementation guidance for Cloud Native architecture.

16.2 Level 1

There is no additional implementation guidance for Cloud Native architecture specific to this level.

16.3 Level 2

There is no additional implementation guidance for Cloud Native architecture specific to this level.

16.4 Level 3

The implementation guidance for the CSP are those in Level 2 and in addition the CSP should:

a) Ensure that container images are moved across Cloud Native environments (build, test,
staging, production, etc) with proper controls and authorisation;

b) Ensure that the application gateway supports authentication tokens, if applicable; and

c) Ensure that mechanisms are in place to encrypt all communications of authentication tokens.

The implementation guidance for cloud service auditor are those in Level 2 and in addition the cloud
service auditor should:

a) Check that mechanisms are in place to protect container images moving across Cloud Native
environments;

b) Check that the application gateway supports authentication tokens (e.g. OAuth 2.0 or SAML),
if applicable; and

c) Check that mechanisms are in place to encrypt all communications of authentication tokens.

17 Encryption

17.1 General

Clause 17 and the associated implementation guidance and other information specified in SS 584 apply.
The following clauses are in addition to the “Encryption” controls in SS 584 with specific implementation
guidance for Cloud Native architecture.

17.2 Level 1

The CSP should ensure that secrets and credentials are retrieved only at runtime, when needed.

The cloud service auditor should determine mechanisms are in place to ensure that secrets and
credentials are only retrieved at runtime.

17.3 Level 2

There is no additional implementation guidance for Cloud Native architecture specific to this level.
23
COPYRIGHT
Licensed by Enterprise Singapore to YOU CHENG HWEE/MR, MAXIMUS CONSULTING PTE LTD
Singapore Standards eShop Order No: 6800066547/Downloaded:2021-05-12
Single user licence only, copying and networking prohibited

TR 82 : 2020

17.4 Level 3

The implementation guidance for CSP are those in Level 2 and in addition the CSP should ensure that
mechanisms are in place to perform an appropriate integrity check (e.g. digitally signatures) on API
requests, to protect data in transit.

The implementation guidance for cloud service auditor are those in Level 2 and in addition the cloud
service auditor should check that appropriate integrity check process(es) are in place for API requests.

18 Physical and environmental

The implementation guidance associated with the “Physical and environmental” controls in SS 584
should apply.

19 Operations

19.1 General

Clause 19 and the associated implementation guidance and other information specified in SS 584 apply.
The following clauses are in addition to the “Operations” controls in SS 584 with specific implementation
guidance for Cloud Native architecture.

19.2 Level 1

There is no additional implementation guidance for Cloud Native architecture specific to this level.

19.3 Level 2

The implementation guidance for the CSP are those in Level 1 and in addition the CSP should:

a) Ensure that mechanisms are in place to monitor and alert on resource utilisation by
Microservices to defined thresholds; and

b) Ensure that mechanisms are in place to limit the number of authentication retries and to alert
on authentication failures by Microservices.

The implementation guidance for cloud service auditor are those in Level 1 and in addition the cloud
service auditor should:

a) Check that thresholds are defined for resource management and monitoring function(s) are in
place for Microservices; and

b) Check that mechanism(s) are in place to limit the number of authentication retries and to alert
on authentication failures by Microservices.

19.4 Level 3

The implementation guidance for the CSP are those in Level 2 and in addition the CSP should:

a) Ensure that mechanisms are in place for the CSCs to manage and monitor container volumes;
and
b) Ensure that mechanisms are in place to enable container application to perform rollback to a
known secure state.

24
COPYRIGHT
Licensed by Enterprise Singapore to YOU CHENG HWEE/MR, MAXIMUS CONSULTING PTE LTD
Singapore Standards eShop Order No: 6800066547/Downloaded:2021-05-12
Single user licence only, copying and networking prohibited

TR 82 : 2020

The implementation guidance for cloud service auditor are those in Level 2 and in addition the cloud
service auditor should:

a) Check that the monitoring function over container volumes is enabled; and

b) Check that a process is in place to allow a containerised application to transit to a secure state.

20 Change management

20.1 General

Clause 20 and the associated implementation guidance and other information specified in SS 584 apply.
The following clauses are in addition to the “Change management” controls in SS 584 with specific
implementation guidance for Cloud Native architecture.

20.2 Level 1

The CSP should ensure that CSP provided container images are reviewed before use by the CSCs.

The cloud service auditor should check that a review process is in place to validate the container images
prior to release.

20.3 Level 2

The implementation guidance for the CSP are those in Level 1 and in addition the CSP should ensure
that a CI/CD Orchestrator is employed to automate deployment and updates.

The implementation guidance for cloud service auditor are those in Level 1 and in addition the cloud
service auditor should check that a process is in place for a CI/CD Orchestrator to automate deployment
and updates.

20.4 Level 3

The implementation guidance for the CSP are those in Level 2 and in addition the CSP should ensure
that a mechanism is in place to identify misconfigurations of containers.

The implementation guidance for cloud service auditor are those in Level 2 and in addition the cloud
service auditor should determine that a mechanism is in place to detect misconfigurations of containers.

21 Business continuity planning (BCP) and disaster recovery (DR)

The implementation guidance associated with “Business continuity planning (BCP) and disaster
recovery (DR)” controls in SS 584 should apply.

22 Cloud services administration

The implementation guidance associated with “Cloud services administration” controls in SS 584 should
apply.

23 Cloud user access

The implementation guidance associated with “Cloud user access” controls in SS 584 should apply.

25
COPYRIGHT
Licensed by Enterprise Singapore to YOU CHENG HWEE/MR, MAXIMUS CONSULTING PTE LTD
Singapore Standards eShop Order No: 6800066547/Downloaded:2021-05-12
Single user licence only, copying and networking prohibited

TR 82 : 2020

24 Tenancy and customer isolation

24.1 General

Clause 24 and the associated implementation guidance and other information specified in SS 584 apply.
The following clauses are in addition to the “Tenancy and customer isolation” controls in SS 584 with
specific implementation guidance for Cloud Native architecture.

24.2 Level 1

The CSP should:

a) Ensure that communication among container management, container registry, container

runtime and containers are protected;

b) Ensure that remote write access to container registry, runtime and CI/CD orchestrator are
safeguarded with strong authentication and access controls;

c) Ensure that communication between Microservices and the Service Registry are protected;

d) Ensure that the Service Registry is safeguarded with strong authentication and access controls;

e) Ensure that communication(s) between application clients and gateways are protected; and

f) Ensure that hosts of Microservices employ IP filtering (or equivalent).

The cloud service auditor should:

a) Verify that secure communication is employed among container management, the CI/CD
Orchestrator, container registry, container runtime and containers;

b) Verify that strong authentication and access control mechanisms are in place to protect remote
write access to container registry, runtime and the CI/CD Orchestrator;

c) Check that secure network communication protocol is in place between Microservices and the
Service Registry;

d) Verify that strong authentication and access control mechanisms are in place to protect the
Service Registry. For example, check the authentication method used;

e) Verify that secure network communication protocol is in place between application clients and
gateways; and

f) Verify that the hosts of Microservices employ IP filtering (or equivalent).

24.3 Level 2

The implementation guidance for the CSP are those in Level 1 and in addition the CSP should:

a) Ensure that communication between Microservices is protected against information disclosure

and alteration; and

b) Ensure that Microservices have restricted access to the necessary communication channels.

26
COPYRIGHT
Licensed by Enterprise Singapore to YOU CHENG HWEE/MR, MAXIMUS CONSULTING PTE LTD
Singapore Standards eShop Order No: 6800066547/Downloaded:2021-05-12
Single user licence only, copying and networking prohibited

TR 82 : 2020

The implementation guidance for cloud service auditor are those in Level 1 and in addition the cloud
service auditor should:

a) Check the authentication and encryption tools between Microservices; and

b) Verify that mechanisms are in place to restrict access of Microservices to certain

communication channels only.

24.4 Level 3

The implementation guidance for the CSP are those in Level 2 and in addition the CSP should:

a) Ensure that the CI/CD Orchestrator provides mechanisms to the CSCs to isolate deployment
to network segment; and

b) Ensure that mechanisms are in place for the CSCs to use dedicated hosts to run containerised
workloads only.

The implementation guidance for cloud service auditor are those in Level 2 and in addition the cloud
service auditor should:

a) Check that the CI/CD Orchestrator is configured to deploy containers only to specific network
segments; and

b) Verify that only dedicated hosts are used to run containerised workloads.

27
COPYRIGHT
Licensed by Enterprise Singapore to YOU CHENG HWEE/MR, MAXIMUS CONSULTING PTE LTD
Singapore Standards eShop Order No: 6800066547/Downloaded:2021-05-12
Single user licence only, copying and networking prohibited

TR 82 : 2020

Bibliography

Standards/Publications

[1] SS 584 : 2020 Specification for multi-tiered cloud computing security

[2] Agile Security : The intersection of security, development and operations, Cloud Security
Alliance

[3] Best practices for implementing a secure application container architecture, Cloud Security
Alliance

[4] Challenges in securing application containers and microservices, Cloud Security Alliance

[5] DoD Enterprise DevSecOps reference design

[6] DWP-ss011-security-standard-containerization

[7] DWP-ss028-security-standard-microservices-architecture

[8] NIST SP 800-180, NIST Definition of microservices, application containers and system virtual
machines

[9] NIST SP 800-190 Application container security guide

[10] NIST SP 800-204 Security strategies for 3 microservices-based application systems

[11] NISTIR 8176 Security assurance for linux application container deployments

28
COPYRIGHT
Licensed by Enterprise Singapore to YOU CHENG HWEE/MR, MAXIMUS CONSULTING PTE LTD
Singapore Standards eShop Order No: 6800066547/Downloaded:2021-05-12
Single user licence only, copying and networking prohibited

TR 82 : 2020

Feedback Form

To : Enterprise Singapore

E-mail : standards@enterprisesg.gov.sg

Guidelines for Cloud Native security

Specific: (Please use the format below)

S/No Clause no. in Comments (To be supported Proposed changes

the TR with reasons)

General:

Submitted by : Name (Spelt in full) :

Company :

Designation :

Postal address :

Tel no. :

E-mail :

29
COPYRIGHT
Licensed by Enterprise Singapore to YOU CHENG HWEE/MR, MAXIMUS CONSULTING PTE LTD
Singapore Standards eShop Order No: 6800066547/Downloaded:2021-05-12
Single user licence only, copying and networking prohibited

TR 82 : 2020

SINGAPORE STANDARDS COUNCIL

The Singapore Standards Council (SSC) facilitates the development, promotion and review of
Standards and Technical References in Singapore. This work is done through partnerships with the
industry, academia and government organisations, under the national standardisation programme
administered by Enterprise Singapore.

Visit www.enterprisesg.gov.sg/standards for more information.

ENTERPRISE SINGAPORE

Enterprise Singapore is the government agency championing enterprise development. We work with
committed companies to build capabilities, innovate and internationalise.

We also support the growth of Singapore as a hub for global trading and startups, and build trust in
Singapore’s products and services through quality and standards.

Visit www.enterprisesg.gov.sg for more information.

SINGAPORE STANDARDS AND TECHNICAL REFERENCES

Singapore Standards (SSs) and Technical References (TRs) are in the form of specifications for
materials, products, services and systems, codes of practice, requirements for interoperability, methods
of test, management systems, guidelines, nomenclatures, etc.

TRs are pre-SSs developed to address urgent industry demand and are issued for industry trials over
a period of time. Comments received during this trial period are considered when a TR is reviewed.
TRs can become SSs after the trial period, continue as TRs for further industry trials or be withdrawn.

To ensure adequate viewpoints are considered in the development and review of SSs and TRs,
committees and working groups set up by the Standards Council consist of representatives from various
key stakeholders which include industry associations, professional bodies, academia, government
agencies and companies. SSs are also put up for public comment before publication.

30
COPYRIGHT
Licensed by Enterprise Singapore to YOU CHENG HWEE/MR, MAXIMUS CONSULTING PTE LTD
Singapore Standards eShop Order No: 6800066547/Downloaded:2021-05-12
Single user licence only, copying and networking prohibited

The Singapore Standards Council facilitates the

development, promotion and review of standards for
enterprise growth under the national standardisation
programme overseen by Enterprise Singapore.

www.enterprisesg.gov.sg/standards