Assuring the Security of

Cloud Services A framework for evaluating the trustworthiness, resilience and adaptability of

modern business applications that use cloud services and mobile devices

Handbook

James Kavanagh,

National Security Advisor, Microsoft Australia

Disclaimer:

This document has been prepared by Microsoft to provide an overarching framework for compliance and risk

assessment in relation to cloud computing.

This document is provided on an “as is” basis and to the maximum extent permitted by law Microsoft disclaims

all conditions, warranties and guarantees, express or implied, including but not limited to any warranty or

guarantee that the use of the framework set out in this document will not infringe any rights or any warranty

or guarantee of merchantability or fitness for a particular purpose. Before using the framework set out in this

document, you should evaluate its suitability for your organisation. In particular, if you choose to act upon the

output of the framework, then you do so at your own risk.

Apart from any use permitted under the Copyright Act 1968, and the rights explicitly granted below, all rights

are reserved.

Licence: This document is licensed under a Creative Commons Attribution Non-

Commercial 4.0 licence. You are free to copy, distribute and transmit the work

as long as you attribute the authors. You may not use this work for commercial

purposes.

To view a copy of this licence, visit http://creativecommons.org/licenses/by-nc/3.0/au/legalcode.

Contents Executive Summary ................................................................................................................................. 2

Assuring Modern Business Applications ................................................................................................. 4

Modern Apps ...................................................................................................................................... 4

The Problem of Assurance .................................................................................................................. 6

Introducing the SAFE Methodology ........................................................................................................ 8

Evolving security assurance ................................................................................................................ 8

Dimensions of Assurance .................................................................................................................... 8

The Five-Step Process ......................................................................................................................... 9

Step 1 – Understand Strategic Intent ................................................................................................... 18

Strategic Intent & Benefits Case ....................................................................................................... 18

Alternative Options ........................................................................................................................... 19

Context .............................................................................................................................................. 19

Assurance Objectives ........................................................................................................................ 20

Worked Example ............................................................................................................................... 24

Step 2 – Define Requirements .............................................................................................................. 27

Sources of Security Assurance Requirements .................................................................................. 27

Compliance Requirements ................................................................................................................ 28

Security Architecture and Policy Requirements ............................................................................... 33

Worked Example ............................................................................................................................... 35

Step 3 – Verify Claims ........................................................................................................................... 40

Assurance Boundaries ....................................................................................................................... 40

Types of Assurance Claims ................................................................................................................ 41

Worked Example ............................................................................................................................... 47

Step 4 – Assess Risk ............................................................................................................................... 56

Domain Based Risk Assessment ........................................................................................................ 56

Risk Event Catalogue ......................................................................................................................... 59

Threat Modelling ............................................................................................................................... 83

Worked Example ............................................................................................................................. 113

Step 5 – Decide & Plan ........................................................................................................................ 115

Overall Assurance Evaluation ......................................................................................................... 115

Ongoing Governance ...................................................................................................................... 116

Worked Example ............................................................................................................................. 118

1

Figure 1: The five step SAFE methodology for security assurance, progressing from an

organisation’s understanding of strategic intent to definition and verification of requirements,

assessment of risk and preparation of a final executive recommendation

2

Executive Summary

The Challenge The benefits of modern applications and

technology built with cloud services and

mobile devices are well understood:

improved productivity, increased

effectiveness and greater focus on achieving

business outcomes. Governments,

enterprises, small business and consumers are

rapidly adopting these modern applications.

But any enterprise that seriously progresses

towards adopting cloud must diligently

consider issues of compliance and risk. They

need to confirm that they will continue to be

able to satisfy compliance requirements that

may come from external regulators,

legislation, supply contracts and other

sources. They also need to ensure that they

will not face unacceptable risks, even if their

data is held and processed by another

organisation, possibly one based in another

jurisdiction.

A great deal of complexity arises as a result of

the diversity of cloud service providers that

exist in the market. This diversity can be

highly beneficial, enabling an organisation to

find the right combination of services to fit

their needs. But each service will integrate

differently, apply security differently, have

different expectations of privacy and commit

to different contractual terms.

The challenge therefore is to perform due

diligence assessment of compliance and risks,

but in a way that enables direct comparison of

alternative providers. And to do this

assessment quickly and consistently, so that

the business can maintain a focus on

delivering outcomes.

The Big Issues It seems every organisation is thinking about

cloud. They’re considering their future

technology choices and the role that cloud

services and modern applications will play.

This consideration brings into sharp relief a

number of central issues.

Firstly, how will cloud services integrate with

the existing technology, structure, processes

and culture within the organisation?

Important questions here relate to the

capacity of the workforce to adapt and

leverage new technologies and applications,

the process and organisational changes

necessary to realise full benefits and the

technical challenges of identity and access

management, information protection and

monitoring over a hybrid of cloud and on

premise systems.

Secondly, can the organisation satisfy it’s

compliance obligations if it processes or

stores data in the cloud? Concerns about

privacy are well placed with a great deal of

divergence in both the privacy expectations

and practices of cloud service providers. But

compliance considerations in areas like

records management, lawful discovery,

information security and procurement

processes also commonly need to be

assessed.

Finally, will the organisation be exposed to

unacceptable risks in adopting a cloud

service? Although, focus tends to initially turn

to abstract threats based on the most current

threats in the media, there are real and

important risks to consider of a strategic,

operational, technical and compliance nature.

A holistic assessment of risk also needs to

reflect the real risks organisations face in

operating legacy, on premise infrastructure.

In many circumstances, risks in the cloud are

outweighed by risks organisations face by

maintaining business-as-usual approaches.

3

Introducing SAFE The Security Assurance Framework for

Evaluation (SAFE) is a structured, lightweight

methodology for comparative assessment of

compliance and risk in relation to modern

cloud based applications. It is service and

technology agnostic. So it can be used to

compare alternative options that may

comprise such delivery models as on-premise

non-cloud based implementation, private

cloud, hosted cloud, public cloud or any other

combination. It can also be used to compare

multiple alternative cloud provider solutions

on a consistent basis.

It is not designed around any particular sector

or industry. Different tiers of government,

financial services and other sectors all have

unique compliance requirements. So the

SAFE framework is adaptable to any sector,

describing how to elicit and verify compliance

in a formal way. Rather than adopt any one

sector’s compliance or control framework, it

provides a generalised mechanism that an

organisation can apply to their specific

context.

It provides extensive guidance on how to

perform a risk assessment using two

approaches. Firstly, a domain based risk

assessment approach details about fifty

relevant risk events and guides the

organisation to assess both their tolerance

and exposure to those risk events. Secondly,

for more specific risks that require deeper

consideration, the framework provides

formalised threat models that support

definitive risk assessments.

SAFE is designed to be comprehensive but

lightweight, covering conventional assurance

considerations such as confidentiality,

integrity and availability but goes further to

address aspects of privacy, transparency and

adaptability. However, it is designed to be

lightweight, so that the assessment can be

performed rapidly without the need for highly

specialised skills.

Not every organisation will need to perform a

comprehensive compliance assessment or

analyse risks to a deep level. Essentially, SAFE

is a framework for asking questions and

interpreting answers. Its goal is to enable

rapid evaluation and decision making.

It is important to note that SAFE is not a

business case or TCO framework. It focuses

only on aspects of assurance, such as security,

compliance and risk.

Five Steps The SAFE framework consists of five distinct

stages. Firstly, the organisation develops a

clear statement of strategic intent, benefits

and options along with a description of their

assurance objectives. This stage is vital as it

sets the overall context and scope for

everything that follows.

The second stage is about laying out internal

and external requirements. External

requirements may come from legislation,

regulator guidance, codes of conduct, supplier

agreements, and so on. Internal

requirements come from security policies,

existing infrastructure and strategies.

Stage three is about verifying that the cloud

service or application can actually satisfy

these requirements. A combination of service

provider documentation, contract terms and

independent verification can inform this

verification process.

There will always be some unknowns, so the

fourth stage is about performing a holistic risk

assessment across domains of

trustworthiness, resilience and adaptability

considering impacts of a strategic,

operational, compliance or technical nature.

The final step is to combine all of the previous

inputs to provide a recommendation on the

organisation should proceed.

4

Assuring Modern Business Applications

Modern Apps Modern business applications are different.

They combine services delivered from cloud

providers with rich interactive experiences

on devices. They are frequently integrated

with social network services and take

advantage of big data approaches to analyse

and present information. Data within modern

applications is rarely static – it moves from

device to cloud to device, seamlessly crossing

system and geographic boundaries. End users

choose and adapt their own experiences,

combining data from multiple applications,

linking applications to their social network,

consuming content and exploring new

applications at will. Multiple forms of

communication merge on devices as users

seamlessly switch between cloud services that

offer voice, video, short messaging and email.

These modern apps offer the possibility for

employees to be more productive, for

students to learn anywhere, for citizens to

interact with government at any time.

This is a remarkable change from the more

contained, controlled business applications of

the past. The dominant paradigm of the last

ten years of business information systems has

been a focus on enabling silos of functionality,

albeit through web-enabled interfaces. The

paradigm of modern applications is all about

composing multiple discrete services

presented to users through highly adaptable

and engaging experiences on a variety of

devices. Every type of business application,

from email to medical records, from general

ledger to marketing, from transport schedules

to police dispatch, are all moving to this new

model.

The trend to modern applications has arisen

from both the evolving maturity of cloud

services and the increased sophistication of

devices. This is combined with the insistent

expectations of users who now demand

technology that fulfils their needs rather than

adapt their own working style to historic

technological limitations. Cloud services,

social networks, big data analytics and mobile

devices are integrated and mass-customised

to satisfy unique functional needs through

experiences that are tailored for and by users.

Dramatic cost efficiencies are realised through

use of large-scale cloud services and the

productivity benefits of anywhere, anytime

access. More rapid innovation emerges due

to the relative ease of combining multiple

services into useful application experiences.

And new data sources and data analytics

capabilities along with integration to social

networks provide richer insight and more

valuable engagement with customers.

Although this pattern may have begun on

mobile smartphones and small single purpose

utilities and games, it is extending to all forms

of devices and all types of applications. Even

applications that conventionally are

considered more as enabling infrastructure,

like email and storage have modernised into

combined cloud services and on-device

applications.

Figure 2: Modern apps are composed of discrete

cloud services, tailored to unique user needs and

experienced on a variety of mobile devices

5

But new challenges arise with the transition

to modern applications.

Cloud services can be provided at a local or

global scale so data may reside in multiple

geographic locations under different

compliance and regulatory regimes, the

problem often referred to as data sovereignty.

Some cloud services operate with rigorous,

proven security practices while others may

not be so diligent, exposing business and

customer data to the risk of loss. A user’s

work may be disrupted if one of the cloud

services their application relies upon becomes

unavailable. This danger is compounded as

multiple cloud services are combined in a

supply chain or integrated by the application.

Cloud service providers may not apply the

same respect to privacy and appropriate use

of private data as the customer expects,

especially if provision of the cloud service is

subsidised through an advertising or other

‘free’ business model.

Modern devices such as smartphones and

tablets are lit up by interactive experiences

within applications and data sourced from

cloud services. Commonly, modern devices

store cached communications and business

data, so loss of a device can potentially result

in the loss of sensitive data. A device in the

wrong hands or one that is inadequately

protected provides a gateway into the

organisation’s data and business services.

Yet, the demand for smart devices has led to

their proliferation in many forms from the

workplace to the home. These modern

devices blur the distinction between work and

personal use, often holding both corporate

and personal data.

Social network services can be useful both for

individuals as tools of communication and for

organisations as enablers of greater

engagement and connection. Big data

analytical approaches can enable a deeper

level of insight and understanding from vast

stores of data. But social networking and big

data can also be invasive to privacy.

So modern business applications are

composed of widely different cloud services

provided by different parties, from different

locations, under different terms-of-service

and they are experienced by end users on a

variety of different device platforms.

The diversity of choices and challenges is vast.

6

The Problem of Assurance The difficult challenge then for any

organisation adopting modern business

applications is how to validate the security,

privacy, resilience, adaptability and overall

adequacy of the total solution. Organisations

need to have confidence that their data is

protected from unauthorised access and that

their data is only used in a manner that is

consistent with the privacy expectations of

their clients. They need to know that

operational disruptions in cloud or network

service providers will not adversely affect

their own business operations. They need to

be sure that in using these modern

applications, they are still able to comply with

all appropriate regulations pertinent to their

business. More than just technical measures,

they need contractual protections to ensure

service providers say what they do and do

what they say.

And in our dynamic environment of new

opportunities and economic concerns, they

need confidence that their choice today does

not restrict choices they might need to make

tomorrow.

Conventionally, this is a problem within the

domain of information assurance.

Information assurance deals with the

technical and procedural measures designed

to ensure the confidentiality, control,

integrity, authenticity, availability and utility

of information systems. Information

assurance is an established discipline, with

well-defined skills, formal frameworks,

expectations and management

understanding.

But there is a problem applying established

information assurance approaches to modern

applications. Formalised assurance criteria,

standards, compliance requirements, controls

and audit processes have accreted into

sectoral and country-specific tomes. In

exquisite detail, these rigid rule books have

become the ‘bible’ for protection and

management of information. Government

and industry compliance regimes can turn

information assurance into a straitjacket for

the business, rather than an enabler of secure

innovation.

Conventional information assurance

approaches are poorly suited to the reality of

modern business applications. They generally

fail when dealing with modern applications

because of inherent assumptions that no

longer hold, such as:

Uniformity of Control. They generally

assume that all elements of the system

can be controlled to a common level with

similar technical and procedural controls.

But with cloud services provided by

multiple different providers, achieving this

level of control is practically impossible.

Static Data. They assume that data is

relatively static, contained behind

protective perimeters and only interacted

with in very specific ways. But modern

business applications move data in large

quantities between services and devices.

Users interact with data in much more

free-form ways appropriate to their style

of work. Sharing is the default, not

restriction. Data is always in motion.

Predictability. They assume that all

components of the business application

can be predicted in advance. This fails to

recognise the dynamic nature of modern

applications which evolve and adapt to

specific use cases either functionally

improved or enhanced through

integration with new cloud services or

even other apps.

Sovereignty. They frequently fail to

incorporate concerns that only really

surface as a result of the global nature of

cloud services and the new capabilities of

devices. These include for instance issues

of data sovereignty, privacy, data

aggregation and so on.

7

Point-in-time. Most information

assurance approaches are focused on a

point-in-time process such as an audit and

accreditation every few years. There is

typically little capacity to deal with

ongoing continuous improvement,

adaptation and response to changing

circumstances.

These failing assumptions need to be tackled.

But organisations currently operate within an

existing context where established

information assurance practices and

compliance regimes exist. The opportunity is

to evolve these practices to incorporate the

new circumstances of cloud services, social

networking, big data and devices. This is

especially necessary as organisations look to

map out alternative options for how their

communications infrastructure and business

applications will be best delivered into the

future.

There is a need for a security assurance

framework that is relevant to new models of

service & device based business applications,

while reflecting the broad range of security,

privacy and compliance considerations. And

for that assurance framework to be useful for

the rapid evaluation and planning of

organisational strategic choices.

Addressing this need is the principal focus of

the Security Assurance Framework for

Evaluation (SAFE).

8

Introducing the SAFE Methodology

Evolving security assurance Information security assurance commonly

begins from one of two perspectives – risk or

compliance.

A compliance perspective begins by collecting

all of the specific policy and regulatory

requirements, the internal standards and

information security checklists. Then the

organisation works through a series of

checklists, identifying discrepancies in

practice.

A risk perspective begins with enumerating

the assets of an organisation. Vulnerabilities

that may expose these assets to loss are

identified and a list of possible adverse events

along with their impact and probability are

assessed to develop an overall picture of risk

exposure. Then security control and risk

mitigation measures are applied and the final

overall level of risk is assessed.

In reality, most organisations ultimately find

some middle ground between a focus on

compliance and risk. Businesses are often

weighted towards risk management

approaches, while governments typically

favour compliance.

There are a variety of formalised processes to

achieve such assurance including the ISO

27000 series of standards and ISO 31000. The

SAFE methodology builds on these standards

to define a process that any organisation can

use to assure themselves of the security of

the end-to-end modern business application.

Dimensions of Assurance Within the SAFE methodology, security is

treated as a very broad concept

encompassing dimensions of trustworthiness,

resilience and adaptability. This is much

broader than a conventional perspective

limited to confidentiality, availability and

integrity.

Trustworthiness incorporates mechanisms

that ensure confidentiality and integrity of

information but also extends to performance

quality and dependability. A cloud service

that may be highly secure in a conventional

sense but that does exhibit an appropriate

level of transparency, consistent with the

customer’s expectations, would have a limited

assurance of trustworthiness. Similarly a

device or app that is secure against attack but

leaks private information such as user

behaviour and location may have a limited

assurance of trustworthiness.

Figure 3: Dimensions of assurance when using

cloud services

9

Resilience deals with the assurance of

availability and survivability. For a cloud

service, this would incorporate mechanisms

for business continuity, disaster recovery,

automated backup and failover. It also

includes characteristics of services and

devices under exceptional conditions, like

unexpectedly high load.

Finally, adaptability is a key attribute of cloud

solutions but this attribute is perhaps the

least likely to be incorporated into a

conventional assurance model. This is all

about how the organisation can adapt and

reconfigure the business application based on

changing needs and circumstances.

Adaptability may be necessary to cope

with new compliance obligations, a

crisis situation or even to rapidly take

advantage of an emerging opportunity.

Data portability, ease of substitution of

services and choice in suppliers are all

enablers of greater adaptability.

The SAFE methodology supports a

comparative evaluation of an end-to-

end solution in terms of these three

dimensions of assurance.

The Five-Step Process SAFE is designed to guide an

organisation’s evaluation of alternative

options for their implementation of

modern business applications,

principally from the perspective of

security assurance.

It follows a five step process that

progresses from understanding the

intent and context, through

requirement and compliance analysis to

assessing risk and finally planning for

deployment.

Throughout the process, the methodology

incorporates an evaluation of multiple options

but is not prescriptive about which

alternatives they may be. For example, it

could be used to compare email services

provided by a range of different cloud service

providers, to compare an on premise versus a

cloud provider solution or even to compare a

business application implemented with

alternative architectural choices.

The assurance dimensions of trustworthiness,

resilience and adaptability also carry through

the evaluation methodology. Ultimately the

goal is to develop adequate assurance that

the chosen approach delivers on the strategic

intent, appropriate to the organisation’s

internal and external context with an

acceptable level of risk in the dimensions of

trustworthiness, resilience and adaptability.

Figure 4: The 5 Step Process of the Security

Assurance Framework for Evaluation

10

1. Understand Strategic Intent The first stage in any evaluation is to establish

a very clear articulation of the strategic vision

and intended benefits along with a solid

understanding of the organisations internal

and external context.

The strategic intent is important because

security assurance inevitably involves trade-

offs. A particular risk might be demand

treatment with mitigations that adversely

affect functionality or even limit the

achievement of objectives. Typically, the

strategic benefits of modern applications

include faster time to market, ability to enter

into new markets, providing more valuable

services to customers, becoming more

responsive to demand, achieving greater

insight for decision making or achieving

greater efficiencies. There is no one-size-fits-

all. A policing organisation may see the key

strategic intent of a new intelligence

application as enabling rapid response to

emerging incidents and greater insight for

commanding officers. An educational

organisation may view a cloud storage service

combined with a learning app as a strategic

way to streamline and support individualised

student learning.

Security assurance needs to take account of

this strategic intent when assessing required

security functions and appropriately treating

risk. There are often multiple ways to achieve

the desired strategic intent and often the

purpose of evaluation is to help make a choice

between the range of options. Each option

however requires extensive work to assess, so

it is necessary to develop a short-list of viable

alternatives to take through the assurance

methodology.

It is important to reflect that a true assurance

assessment will generally consider both

aspects of maintaining status quo as a

baseline as well as moving to an alternative.

For example, some organisations assess cloud

services and hesitate due to a perceived risk

around data sovereignty. But they already

face risks, sometimes of even greater

proportion, in their existing on-premise

infrastructure, such as legacy system

maintenance and gaps in security practice.

Finally, it’s important to map out the internal

and external context of the organisation,

including how it perceives security risk

management. Context considerations vary

widely between organisations and have

significant bearing on the security assurance

process.

Figure 5: An illustration of some areas of internal

and external context

11

2. Define Requirements

Understanding the organisation context

leads to enumeration of the specific

regulatory and compliance obligations of the

organisation. Most government organisations

need to comply with national or state level

information assurance requirements such as

the Federal Information Security Management

Act (FISMA) requirements in the US or the

Protective Security Policy Framework in

Australia. They may also have specific

legislative requirements depending on their

function, such as legislation relating to health

information privacy, payment card data

protection or national security information.

Specific compliance obligations can really only

be determined by the organisation itself but

the following broad categories generally need

to be considered:

Security & Information Assurance. Public

sector organisations in particular

frequently need to comply with

government mandated security

requirements. These might take the form

of certification, accreditation or formal

evaluation processes. Private sector

organisations can have similar obligations,

such as for example security of credit card

data as specified by the Payment Card

Industry Data Security Standard (PCIDSS)

Privacy. Most organisations face

compliance obligations with regard to

respecting the privacy of customer data.

A distinction is commonly made between

personal information and sensitive

personal information, where the latter

might include credit reporting or medical

data for example. Some organisations

may face additional requirements around

employee privacy. Both cloud services

and devices need to enable these

obligations to be met by the organisation,

either through contractual measures or

capabilities of the service or device.

Records and Audit. Regulated enterprises

and government organisations generally

have specific obligations for formalised

record keeping and audit. In government,

this may extend to enabling freedom of

information requests by citizens or may

relate to the ability of the organisation to

present data to law enforcement on

request.

National Security Information. Central

government, security, intelligence and law

enforcement agencies within government

along with some private sector

organisations in the critical infrastructure

sector may hold national security

classified information. Commonly, the

handling of this information is subject to

special requirements and regulations.

Once the organisation identifies the broadly

relevant regulations, it’s necessary to

enumerate a list of specific compliance

requirements that can be validated and

identify the appropriate mechanism for

compliance verification. For example,

complying with a federal government

information assurance requirement might

require the agency to undertake an

accreditation process for the end-to-end

solution, or it might require only procuring

from an approved panel of evaluated

suppliers, or it may simply be a process of

ensuring contractual protections are in place.

Requirements come from both external and

internal sources. So the final part of this stage

in the evaluation is to identify the key specific

security functional requirements of the

organisation. These are requirements for

integrating the end-to-end solution with

existing infrastructure, aligning appropriately

with the organisations existing information

security management system, or the

capabilities needed to effectively deploy,

manage and monitor the solution. Note that

these requirements are not the business

requirements of the specific solution being

considered, but the security requirements

that would apply broadly to any cloud service

or modern application. For example, this

12

would include acceptable mechanisms of

authentication and access control, required

support for encryption of data across the

network, mechanisms for identity integration,

necessary interfaces for audit and event

reporting and so on.

For the purposes of security assurance and

evaluation, only the key functional

requirements need to be identified as the

more detailed requirements emerge during

planning and implementation phases. The

best way to arrive at these functional

requirements is by attempting to answer

questions like those indicated below.

The aim of mapping these security functional

requirements is to ensure that the overall

solution can integrate well with the

organisation’s existing and future

architecture.

Figure 6: Typical questions to elicit functional security requirements for a

modern app or cloud service

13

3. Verify Claims Each cloud service provider, app developer

and device manufacturer makes claims about

the security of their product or service, and

there are existing mechanisms to validate

those claims. These include:

Evaluation within international or national

information assurance schemes such as

Common Criteria or the US Federal

Information Processing Standards (FIPS).

Certification & Accreditation which

generally requires third party auditing and

validation that the information security

practices conform to a particular

standard, such as ISO 27001.

Audit, either external, internal or

conducted by the end-user organisation

can validate specific claims that may not

be already covered by standards-based

third party accreditation processes.

For cloud services, the most relevant schemes

include ISO 27001 certification, Statement on

Standards for Attestation Engagements No. 16

(SSAE16) audit reports, Payment Card Industry

Data Security Standards (PCI DSS) and the US

FedRamp scheme for the Federal Information

Security Management Act (FISMA)

For devices, formal evaluations are generally

more important. The most widely recognised

evaluations are based on testing for

conformance with Common Criteria

Protection Profiles. However, country-specific

schemes such as the US FIPS and Australian

Evaluated Products List are also important for

specific types of products that contain

cryptographic functions, including

smartphones and tablets.

Other less formal schemes such as the Cloud

Security Alliance (CSA) Registry and the Open

Data Center Alliance (ODCA) Usage Models

can provide a common baseline for the

definition of cloud security capabilities. It’s

important to understand these schemes may

not incorporate validation of claims by a third

party though.

So, the goal of this stage in the evaluation

process is to verify that the solution being

assessed can satisfy both internal and external

requirements. And to ensure that the

assurance claims made by the service provider

or vendor are valid and applicable.

To do this, we first need to consider the

concept of assurance boundaries within an

end-to-end solution. An assurance boundary

demarcates the span of control over security

that any one party has within a solution.

To understand these boundaries, consider an

email application running on a mobile device

connected to a cloud service.

In this example, one assurance boundary can

be drawn around the cloud email service - the

cloud provider controls the security and

operations of the service but has no control

over other parts of the solution. The device

manufacturer controls the security functions

and integrity of the device, so this is another

assurance boundary. A third party may

provide the email application on the device

itself and so this is a third assurance

boundary. Finally, there is a network between

Figure 7: An Example of assurance boundaries

14

the cloud service and the email application.

The provider of this network may vary and will

typically involve multiple parties, but it may

be considered as a single assurance boundary,

albeit one with little assurance.

Typically, each assurance boundary delineates

a set of assurance claims. So a cloud service

provider may claim ISO27001 certification,

FedRAMP Authority to Operate or some other

accreditation. A device provider may claim

their product has been evaluated to FIPS140-

2, to Common Criteria or some other claim.

Every solution will have different assurance

boundaries, delineated by the extent of an

organisations ability to make security

assurance claims. For example, a solution

comprising sensors on devices, a cloud service

and an application on a proprietary device

that is delivered and supported by a single

organisation might comprise of only a single

assurance boundary. Other solutions

comprised, for example, of a cloud service for

storage and a cloud service for email might

have two different assurance boundaries,

even if offered by a single cloud provider if

they cannot make equivalent security claims

over the two services.

Clearly understanding the assurance

boundaries of a solution is essential to

scoping, but it isn’t always necessary to fully

evaluate components within each boundary.

For example, if the strategic intent is to

choose between alternative cloud storage and

backup providers accessible from existing end

user devices, the choice of device may be

irrelevant to the evaluation. So in that case,

there’s no need to verify security claims of the

devices themselves.

Most of the work in this stage comprises of

mapping compliance and functional

requirements to the claims within each

assurance boundary in order to determine

that requirements are adequately addressed.

This mapping process of requirements to

assurance claims is illustrated below.

This mapping of requirements to assurance

claims may be necessary at different levels

depending on the context. For example, one

organisation may have a baseline requirement

of ISO 27001 certification on their suppliers. If

the supplier being evaluated has valid

ISO27001 certification in place, then there’s a

one-to-one mapping of requirement to

assertion. Other organisations may have very

detailed requirements that don’t map easily

to a single assurance claim, and so mapping

must be carried out at the individual level of

specific requirements and controls.

Inevitably, gaps exist between requirements

and assurance claims. When that happens,

further investigation may be required or a risk

assessment on the consequence may be

needed.

Figure 8: Mapping security requirements to

assurance claims

15

4. Assess Risk Modern applications that externalise IT

resources to the cloud can introduce

substantial business change. So even after

specifying and assessing fit to requirements,

holistic risk assessment is required. Although

an organisation may already be facing

significant risk with their on-premise systems,

the adoption of cloud services typically drives

a new awareness of risk and compliance.

The domains of holistic risk assessment

involved are broad, traversing aspects of

strategic, operational, compliance and

technical risk. It can be an onerous, and very

complex task to individually identify threats

and assess their risk to the organisation. So

instead, for the purposes of evaluating

alternative choices, the SAFE methodology

first employs a domain-based comparative

risk assessment.

Effectively this involves a qualitative

assessment of the organisations tolerance and

exposure to a set of risk events. The risk

events are drawn from frameworks such as

the Cloud Security Alliance, the ENISA Security

Risk Assessment model and the ASD Cloud

Considerations. The framework provides a set

of starting questions for each risk event that

assist an organisation in assessing their risk

tolerance and perceived risk exposure.

Tolerance to risk is a statement of how

prepared they are to accept a certain level of

risk. Tolerance to risk is assumed to be

equivalent for a particular risk event across

the variety of options being evaluated. Risk

exposure is conceptually the product of risk

impact and probability, reflected as the effect

of the risk on ability of the organisation to

achieve business objectives. Risk exposure

will vary for each option being considered.

Figure 9: Examples of risk events across each of the assurance domains

and risk impact types

16

As an example, an organisation may be

comparing risk for the option of upgrading an

on-premise email infrastructure versus

migrating to a cloud service provider for

email. Based on their past experience, they

may assess project delivery risk exposure for

the on-premise option as moderate based on

their experience of prior project overruns or

failures. They may assess risk exposure as low

for the cloud-delivered option considering it is

a pre-existing, proven service. For this

particular risk event, the organisation may

have a moderate tolerance for risk based on

their past experience. That is, they could live

with the circumstance where the project

failed to deliver positive benefits but did not

cause damage or loss.

This example is illustrative, but when

conducted across the four key domains of risk

(strategic, operational, compliance and

technical), the approach can provide a useful

high-level comparison of options. It is

consistent with the approach described in ISO

31000 that is often more generally applied

within organisations for enterprise risk

management. It can also help identify specific

areas that require more in-depth risk analysis.

A deeper level of risk analysis in specific areas

may also be justified, looking at particular

threats, events and controls. Formal

approaches to perform this type of analysis

include the creation of threat trees. Threat

trees describe the combination of events that

would need to occur for a specific threat to be

realised. As an example, the following threat

tree in Figure 10 shows a simplistic set of

scenarios for how data contained in a cloud

service could be stolen.

In this example, the primary threat being

considered is for readable customer data to

fall into the hands of a third party. For this to

happen, the threat tree indicates that the

data must be readable, which could happen if

the data is not encrypted, if encryption keys

are known or if the encryption is too weak.

The data must also of course be in the hands

of the third party, which may occur due to an

accidental data spillage, a deliberate hack or a

lawful data access request. The threat tree

can be developed to an arbitrary depth.

The effectiveness of mitigating controls to

prevent each threat is then assessed to

further understand the risk and/or identify

control gaps. Typically threat tree approaches

are much more comprehensive than domain

based comparative evaluation, but these

approaches also require more investment of

time and effort. So generally, they are only

developed for high impact, complex risk

events.

The final step in risk assessment is to make

decisions on appropriate risk acceptance or

treatment options. Some risks will be

deemed acceptable as they are within the risk

Figure 10: Example of a simple threat tree

17

tolerance of the organisation, others may

require the organisation to consider

additional steps to either reduce, avoid or

transfer the risk. Risk reduction measures

may include additional security controls,

further testing or evaluation, contractual

terms, etc. An example of a risk avoidance

measure might include limiting the extent of

functionality enabled or limiting permitted

data in the service to be of a lower sensitivity.

Risk transfer might involve insurance or other

third party arrangements.

Ultimately the aim is to determine if, after

applying optional risk treatments, the overall

risk profile for one or more of the options

being considered is within the overall

organisation risk tolerance.

5. Decide and Plan The final stage is to make a decision about the

best course of action for the organisation by

combining the outcomes of compliance,

functional and risk assessments with the

original strategic intent in mind. This leads to

an overall assurance measure in terms of each

of the three dimensions of assurance:

trustworthiness, resilience and adaptability.

Assurance is not just a point in time activity

though and some planning also has to go into

how decisions made during the assurance

process get incorporated into the engineering

design, how security will be monitored and

how access privileges and other customer

responsibilities for security are enacted.

18

Step 1 – Understand Strategic Intent

Strategic Intent & Benefits Case Any organisation evaluating their options to

implement modern business applications and

technology infrastructure will have some set

of problems or opportunities in mind. For

example, a university may be leveraging cloud

technology to deliver new online learning

opportunities to a broader market, a

government agency might see mobile devices

as essential to modernising service delivery or

an enterprise may see cloud infrastructure as

a mechanism to reduce costs and gain

flexibility. Whatever the scenario, the

business will have an expectation of specific

capabilities being delivered that drive

efficiency, effectiveness and performance

benefits. It’s vital to articulate this strategic

intent and agree on the expected benefits up-

front before undertaking a security assurance

evaluation. This is because decisions about

risk, security controls and levels of compliance

need to be made during the assessment

process in the context of how they relate to

the strategic intent and realisation of benefits.

The strategic intent needs to be clear and

succinct. Consider an organisation in a highly

competitive market that is exploring a cloud

platform to offer dynamic and differentiated

customer services while improving the ability

of their workforce to be productive from

anywhere. Their strategic intent might be:

“To establish a cost-effective technology

platform for marketing and service that

enables us to offer new, dynamic, customer-

centric services while allowing employees to

be highly productive anywhere”

The strategic intent connects with all

subsequent considerations during the

assurance process. Continuing the example,

this organisation may have a higher tolerance

to risk and much lower capacity to absorb cost

overrun. They would favour a service that

assures a high degree of adaptability with the

flexibility to enter new markets, while being

unlikely to accept additional security controls

that limit productivity or efficiency.

A simple model helps to communicate

benefits in different areas of the business.

One way is to classify benefits in a table as

either efficiency, effectiveness or

performance benefits so that the overall

benefits case can be easily understood and

related to by all stakeholders. This is not

intended to be the overall business case, just

a summary to provide context to the

assurance process. Some illustrative benefits

that might be anticipated from a modern

cloud service and device application are

included in the table below.

Business Area Efficiency Benefit Effectiveness Benefit Performance Benefit

Customer Service Reduced time on administrative tasks

Improved service scheduling

Mobile access to customer information

More rapid time-to-market with new services

Customer satisfaction improvement

Increased revenue through profitable new services

Information Technology Infrastructure cost reduction

Ability to scale up and down on demand

More rapid deployment of capabilities

Improved mobile security

Greater agility to align and support the business

Human Resources ICT Staff re-directed to higher value work

Better planning for human resource needs

Increased staff morale by enabling work-at-home

Figure 11: An example of a simple benefits table

19

Alternative Options There are often a number of alternative

architectures or suppliers that can be

deployed to achieve the specific strategic

intent. Each of these options may have very

different assurance characteristics but the aim

is generally to identify the option that best

matches the business needs in a compliant

way with the lowest risk profile.

But organisations also have existing

technology infrastructure so a fair evaluation

often also requires an assessment of the

existing environment. This is because modern

cloud services, mobile devices or applications

may create new risks related to data

sovereignty or third party access, but they

may also reduce existing risks such as legacy

infrastructure dependence and sub-optimal

processes.

Context Understanding the organisation’s context is

crucial to specifying security requirements

and all aspects of risk management. Context

includes considerations of the organisation

objectives, ongoing programs, culture and

attitude towards risk, external regulations,

internal constraints and existing security

practices or perceived vulnerabilities.

External Context Firstly, the external context is considered,

meaning the external environment and

factors outside the organisation that can

affect how the organisation operates or may

operate in the future. These can include

geopolitical, regulatory, social, economic,

market, competition and other factors. As

such a broad realm, it can become an

exhaustive task to catalogue external factors,

but the following questions can be used to

narrow focus around those considerations

that directly impact security assurance.

Context Area Question

Geopolitical Are there political issues in our region that could affect our decisions?

Regulatory Does legislation exist that we need to factor in, including for example, privacy, records and security obligations?

Are there regulator obligations that we need to consider, including for example prudential regulatory requirements?

Are there specific security assurance requirements or policies on our organisation, such as for example federal information security policy?

Are there laws, regulations or requirements in other countries that we operate in that we need to consider?

What legislative or regulatory changes are foreshadowed?

Social Are there community expectations or concerns that we need to factor in, for example privacy and data mining?

Economic What are the prevailing and forecast economic conditions for the organisation?

Market & Competition

What market does the organisation operate within and what are the market dynamics that need to be factored in, such as for example market regulation, consolidation or fragmentation?

What position does the organisation have in the market – leader, follower, niche player?

What activities are our key competitors doing that need to be considered?

External Stakeholders

Who are the key external stakeholders?

Are there views, positions or considerations of these external stakeholders that need to be factored into our decisions?

Figure 12: External Context Questions

20

Internal Context Developing the internal context is about

understanding the organisation’s internal

environment and factors relevant to security

and risk. These factors may include strategic

objectives, structure, key programs, business

functions, risk management practices and

technology infrastructure. Again, the analysis

should be limited to those considerations

relevant to the assurance evaluation.

Context Area Question

Objectives What are the key objectives of the organisation?

What are the key plans, programs and business functions that deliver these organisational objectives?

Are there any internal audits, reports or performance assessments relevant to security assurance?

Structure Which business units will be affected by the solution under consideration?

What resource limitations exist?

How flexible is the organisation to structural change and resource reassignment?

How is the organisation workforce geographically distributed?

Culture Is the workforce culture receptive or resistant to technology innovation?

What is the workforce awareness of risk and security process?

Are there organisation morale or industrial relation issues that may impact on the assurance evaluation?

What is the organisation’s adoption of work-at-home and work-remote practices?

Technology What technology platforms are deployed within the organisation?

How modern is the technology experience of users within the organisation?

Which cloud and mobile device technologies are already used, if any?

Risk Management

What is the organisations current approach around security risk management?

How are risk tolerance decisions made, and by whom?

Figure 13: Internal Context Questions

Assurance Objectives The final step in this first stage is to agree the

assurance objectives for the evaluation.

These can be thought of as the overarching

decision criteria and are expressed as desired

characteristics in the dimensions of

trustworthiness, resilience and adaptability.

Trustworthiness is the foundation of security

assurance, encompassing the ability of the

solution to maintain confidentiality and

integrity. But in the context of a modern

business application, it also incorporates

considerations of privacy, transparency,

predictability and quality. In each of these

areas, the organisation needs to agree desired

characteristics.

For example, think about confidentiality.

Most organisations have some form of

information classification scheme to indicate

sensitivity. If their most sensitively classified

information is to be shared within the solution

being evaluated, then they will certainly

require a high level of assurance around

confidentiality. That assurance expectation

will lead both to security functional

requirements and deep scrutiny about claims

that information can be kept confidential. On

the other hand, if only low classification

materials are being shared, then perhaps a

much lower level of assurance is required and

higher level of risk may be tolerated. It is for

the business organisation to reflect on their

context and strategic intent, then set their

assurance objectives in each area.

Similarly, this approach can be applied to the

dimensions of resilience and adaptability. The

following pages provide a template and

guidance for setting these objectives. It may

be tempting to set the highest bar in each

area, but this is counter-productive as higher

levels of assurance inevitability lead to

additional cost. The aim to keep in mind is to

figure out what the organisation needs as

opposed to what may be merely desirable.

21

Importance

Confidentiality Only public information is being shared so minimal requirement for confidentiality

Internal and sensitive information shared so a reasonable assurance of confidentiality is required.

Moderate tolerance to the risk of an information breach

Highly sensitive or even national security classified information is shared so strict confidentiality is required and very low tolerance

to risks of information breach

Integrity Information stored in the service is not the primary record. Modifications or partial loss would have limited impact

Business decisions are made based on the integrity of

information within the services, but there is a moderate

tolerance for risk of integrity issues in the data.

Information stored is the primary source of record with strict

records preservation regulation. Extensive controls on auditing

and prevention of integrity loss required.

Transparency Limited need-to-know how the service delivers on commitments. Minimal consideration of contract adherence and high risk tolerance for non-compliance

Can take a sensible risk-managed approach but need to know if there are any practices

of the service provider that might be counter to compliance

requirements or expectations

Need explicit and comprehensive visibility of

service provider operations and security practices, most likely

due to regulatory or contractual requirements

Privacy No personally-identifiable data will be stored in the service or on a device

Personal information is stored in the service with policy or

regulations governing how that personal data is collected, used

and managed.

Sensitive personal data (eg. health / financial), is stored with specific compliance regulations

for the management of this sensitive data. Sharing with 3rd

parties is explicitly prohibited

Predictability It has limited consequence for the business if the service changes frequently, adding and removing functionality or discontinuing services even with limited notification

Sensible changes that add beneficial functionality create

few problems, but major changes without notification or

discontinuation of services would have significant impact.

Even minor changes can cause significant disruption to working

practices, so advance notification and release control is

needed for all changes to the service.

Exploitability There would be minimal consequence if vulnerabilities in the device or service were exploited, so limited need for secure development and testing practices

Exploitation of vulnerabilities is undesirable and could impact

the business, so there’s an expectation of sound security

development lifecycle practices

Exploitation of a vulnerability in the service or device could have severe consequences, so formal

evaluation and proven security development lifecycle practices

should be demonstrated

Figure 14: Trustworthiness Assurance Objectives

Trustworthiness

22

Importance

Preparedness Ad-hoc, untested or only partially documented and tested operational continuity processes

Documented processes and procedures for response to

incidents with infrequent or only partial testing of those

procedures

The service provider is highly prepared with documented,

regularly tested, proven procedures to deal with failures

Responsiveness The service provider will respond but place restoration of the service at the lowest priority relative to other customers or services

The service provider will aim to apply resources and restore the service promptly within service

level agreements but other customers or issues may take

priority

The service provider will immediately apply maximum

effective resource to respond to a failure and restore service,

generally with penalties for failure to do so.

Survivability The service fails if even a small part of the overall service is disrupted. Limited or no internal redundancy.

Failover or load-balancing ensure the service survives one-

off failures, but may be susceptible to multiple internal failures or failures in external

services depended upon

The service will survive even a significant amount of disruption

or attack, possibly using multiple internal failovers and alternative

suppliers of external services dependent upon.

Durability It is not significant if the service or device degrades with usage, demonstrating declining performance or functionality over an extended period

Expectation that the service or device does not appreciably

degrade with use over moderate periods of time, but for example,

devices would be replaced in normal asset refresh cycles.

Very limited tolerance for performance degradation over

time. Devices should be especially durable for extreme

environments, extended use and shocks.

Availability Service disruption has limited consequence as users can use alternatives or wait for the service to return. Availability at approximately 98% level is acceptable

The business can cope reasonably with infrequent

disruptions of short duration but has an overall availability expectation above 99.5%

Business tolerance to disruption is very low, with the expectation

that disruption events are extremely rare. Overall service availability needed to be in the

range of 99.95%+.

Load Tolerance Under exceptional load circumstances, it is acceptable for the service performance to significantly degrade to the point of being unusable for periods.

Under exceptional load, the service performance will

degrade but should still be usable

The service must continue to operate with minimal

performance consequences in the case of exceptional load.

Figure 15: Resilience Assurance Objectives

Resilience

23

Importance

Portability Information stored and generated within the service is locked to the service and cannot be exported or used in any other service

Data can be exported from the service but it may be a complex

task to modify its format for import into another service

Tools exist for easy data export in a standardised format that can

then be imported and utilised in another service

Configurability Security settings have minimal configurability, effectively just one-size-fits-all

Generally the range of configuration options are narrow but sufficient for some degree of

customisation to needs.

Extensive configuration options exist enabling the security

settings for access control, information protection and

management to be configured to specific needs.

Flexibility Once the security configuration is set, it is difficult or impossible to make significant changes apart from say, adding/removing users

The security configuration can be modified to suit changing

business needs although it may require manual work

The security configuration is highly flexible and can be reconfigured on demand,

possibly even dynamically in response to changing events

such as attack or high load.

Interoperability The service utilises proprietary or closed interfaces so there is little capability to interoperate with other external services

Some essential interfaces are open and standards based,

especially for authentication and authorisation enabling secure

integration with external services

The service exposes a variety of standard, open interfaces that

enable easy integration with external services.

Substitutability No elements of the service can be substituted

Some basic parts of the service may be substituted, such as for example storage but it is not a normal process that is easily

facilitated

Key elements of the service can be substituted such as

authentication, storage, etc. to satisfy changing business or

assurance needs in a streamlined process.

Extensibility The security configuration cannot be extended beyond the base capabilities within the service

Some extension of the security configuration can be set up, including for example adding

multi-factor authentication, open standards based authorisation or

other key security controls

Substantial extension of the service security can include

capabilities like advanced encryption, custom

authentication and authorisation, and custom monitoring

Figure 16: Adaptability Assurance Objectives

Adaptability

Wo

rked

Exa

mp

le

24

Worked Example

Strategic Intent The New South Wales Government Department of Human Services (a fictitious department for this

example) is investigating options for modernisation of their technology platform for electronic

communications and collaboration. This is in order to improve teamwork, cross-organisation

information sharing and improved ability to serve clients while mobile in the community.

This will include a migration off their legacy email platform currently operated within the

organisation along with the deployment of mobile computing devices that would allow secure,

remote access to communications and client data.

Benefits Case Business Area Efficiency Benefit Effectiveness Benefit Performance Benefit

Client Service Reduced time on administrative tasks involved in communications, information dispatch, etc

Improved service scheduling and coordination

Mobile access to client information enabling more direct service delivery in the community

Improved communications, team work ability and ease of sharing best practices

Improved client satisfaction

Improved coverage of disadvantaged groups through remote and community presence

Information Technology Infrastructure cost reduction across hardware, software and maintenance

Ability to scale up and down on demand

More rapid deployment of new capabilities

Improved security

Redeployed IT resources that can better align to the business needs

Human Resources Ability to redirect human resources to client facing roles

Better planning for human resource needs

Greater flexibility in human resource deployment

Increased staff morale by enabling work-at-home and more direct engagement with the community

Alternative Options There are three principal options being considered:

1. Migrate to an on-premise modern platform for collaboration and communication, owned

and operated by the Department and deploy modern mobile devices for access. It is

anticipated this will be at higher cost, but possibly more specifically configured to the needs

of the Department.

2. Migrate to a dedicated cloud provider service hosted in an Australian data centre and also

deploy modern devices. This is expected to be lower cost than on-premise deployment

3. Migrate to a public cloud service hosted offshore accessed through deployed modern

devices. This is expected to be the lowest cost option, but there is concern as to whether it

introduces data sovereignty and other risks

Wo

rked

Exa

mp

le

25

External Context Context Area Question

Geopolitical No significant geopolitical considerations

Regulatory Existing relevant New South Wales legislation including:

o Privacy and Personal Information Protection Act 1998 (PPIPA): for the handling of personal information by government agencies and contracted service providers

o Health Records and Information Privacy Act 2002 (HRIPA): relevant to information processed by the Department that may relate to healthcare information

o State Records Act 1995 (standards for retention and access to government records). A General Authority (GA35) permits transfer outside of NSW provided an appropriate risk assessment has been made and the Department can maintain compliance with the State Records Act.

o Government Information (Public Access) Act 2009 (GIPAA): Provision that makes government information accessible, except where disclosure would be detrimental

Security assurance requirements exist in the form of the NSW Digital Information Security Policy which requires any cloud service provider to implement management processes for security governance, information security, personnel security and physical security certified to ISO 27001.

The Department operates an Information Security Management System (ISMS) consistent with the NSW Digital Information Security Policy (M2012-15) containing specific policies, standards and procedures of the Department that are broadly aligned to ISO 27001.

Social There is significant sensitivity required to the privacy expectations of clients, as significant amounts of sensitive, personal and financial information is processed by the Department.

Economic The Department is continuing to face budgetary pressures as the demands for client services stretch capacity and ongoing government efficiency dividends need to be delivered annually at 2%+ pa.

Market & Competition

No significant market / competition considerations

External Stakeholders

Key external stakeholders include government, non-government community organisations, contracted community service providers and client groups

Internal Context Context Area Question

Objectives The Department is undergoing a major transformation program to improve service delivery designed around the needs and circumstances of clients. This is driven by the need to do more with less and address inadequacies uncovered in recent government audits.

Structure The solution proposed will affect the entire organisation for communications and collaboration, but will particularly affect the front-line service staff. These staff are already under pressure of heavy workloads and low retention, so disruption to their work needs to be minimised.

The workforce is currently distributed across New South Wales but based primarily in offices. This project will enable staff to be spend a much larger portion of their time away from the office.

Culture The workforce is generally ambivalent to technology if sufficient training has been provided. The introduction of more remote and even work-from-home practices will require significant additional change management. Awareness of security and risk practices are limited, but staff generally follow procedures effectively, particularly in relation to client privacy.

Technology The current technology platform generally in use across the Department for collaboration and communications is out-of-date. End user computing is 90%+ based on office desktop computing.

Client service staff use smartphones for telephone calls and many are familiar with modern consumer apps through their personal use. By policy, the organisation does not currently employ any cloud technology. Some users deliberately or inadvertently breach that policy to use consumer cloud storage and file sharing solutions

Risk Management

The organisation has a generally conservative approach to security risk management, adopting more of a compliance driven approach than one focused on risk-managed adoption of innovation. Ultimately, risk management decisions are made by the Department executive team.

Wo

rked

Exa

mp

le

26

Assurance Objectives

Objective Importance

Trustworthiness Minimal Extreme

A high level of confidentiality and integrity protections are required, although there are no national security or highly damaging information being exchanged. Privacy is a particularly sensitive concern for clients and stakeholders, because some of the data is sensitive personal information. Because of the government nature of services provided, a reasonable level of transparency in how the service provider operates is necessary. The business can tolerate changes in the service as long as there is a reasonable level of predictability that can be factored into plans.

Confidentiality

Integrity

Privacy

Transparency

Predictability

Exploitability

Resilience Minimal Extreme

It is expected that the new communications and collaboration service will have a higher level of resilience than the present on-premise environment which operates at about 99% availability. Although a necessary service for smooth operations of the business, it does not have any life-threatening or huge business impact implications if the service is unexpectedly offline for short periods. Load on the service is generally quite consistent during the working day and even during busy periods does not vary significantly.

Preparedness

Responsiveness

Survivability

Durability

Disruption Tolerance

Load Tolerance

Adaptability Minimal Extreme

As an enterprise scale organisation, the Department has a reasonable level of sophistication in the security configuration required. Because of the ongoing transformation program, it is likely that the security configuration will need to be very flexible to accommodate changing business requirements. However, the business is unlikely to require a high degree of portability of data or ability to substitute or extend security-implementing parts of the service.

Portability

Configurability

Flexibility

Interoperability

Substitutability

Extensibility

27

Step 2 – Define Requirements

Sources of Security Assurance

Requirements Every modern application will have a wide

range of specific functional or technical

requirements that need to be met, but for our

purposes in a security evaluation, our focus is

only on a narrow set of requirements that

relate specifically to two areas: compliance

requirements and security functional

requirements.

Compliance requirements generally arise from

external legislation, regulations, policies,

standards and contracts. Some examples

would include privacy legislation, government

security assurance standards, payment card

industry rules and outsourcing contract terms.

Often but not always, external compliance

requirements are given effect by internal

policies which define more specifically how an

external compliance requirement is to be

enforced by the organisation.

In the case of a cloud service, most of the

compliance requirements need to be satisfied

by the service consumer organisation itself,

contracting appropriately with the service

provider. The reality is that compliance

requirements can’t simply be transferred

without accountability to the service provider.

For example, consider some of the typical

requirements for privacy compliance. The

service consumer organisation needs to

ensure that they are compliant with all of the

provisions for collection, storage, use,

correction, destruction, etc. They may

formally contract the service provider under

terms that ensure the information is stored

securely, but the compliance obligation rests

with the service consumer, not the cloud

service provider (or perhaps as well as the

cloud service provider).

Security functional requirements relate to

specifications that should be met by the

solution in areas like identity & access control,

management & monitoring and information

protection. They arise from the fact that

organisation already have existing

infrastructure that need to be integrated with.

For example, if the organisation has already

deployed multi-factor authentication tokens

to all users, it’s sensible that the cloud service,

device or app being evaluated should be able

to support those tokens. Likewise, if the

organisation already uses a set of tools for

managing their IT systems, it may be

necessary for the cloud service or device to

actually work with those tools. Requirements

may translate into security controls, but the

intent here is not to develop an exhaustive list

of required controls, but rather to identify

needs specific to the organisation.

Figure 17: Sources of external and internal assurance requirements

28

Compliance Requirements A consideration of compliance requirements

is necessary to avoid breaches of any law,

regulatory, statutory or policy obligation.

These requirements will often be specific to

the jurisdiction, sector and operations of the

organisation. Although compliance

obligations around information management

generally exist regardless of the use of cloud,

the questions of data location and control

that arise in cloud computing often bring an

awareness of compliance obligations to the

fore. Advice on specific legal requirements

should always be sought from the

organisation’s legal advisers, or qualified legal

practitioners. The following sections outline

some of the considerations an organisation

should include but does not constitute legal

advice.

Identifying and documenting compliance

requirements can become onerous, so this

evaluation methodology proposes a

streamlined approach to identify the most

relevant compliance requirements, rather

than an exhaustive list. The starting point

should be to understand the organisations

current practices around compliance and then

expand to survey other potential compliance

obligations relevant to the solution under

evaluation.

For each potential compliance requirement,

there are a few key questions to ask:

1. What are the source and specifics of the

compliance requirement? This is in

contrast to it’s interpretation in policy or

current practice. To understand the basis

of this question, consider the case of

privacy and data location considerations.

Many organisations initially think that

some legislation or regulation exists that

prevents private data from being located

offshore. Deeper investigation of the

actual compliance requirement often

reveals that the legal obligation does not

prohibit data location offshore, but current

practice or policy within the organisation is

to keep data onshore. Current practice or

policy is within the scope of control of the

organisation and so it can be adapted. It is

also necessary to understand if the

requirement is mandatory, recommended

or best practice.

2. How does the organisation currently

satisfy the compliance requirement? It is

often an incorrect assumption that current

practices are fully compliant, and

organisations may find that migration to

modern applications can actually improve

compliance and security. Understanding

how requirements are currently satisfied

can guide the organisation in defining

appropriate requirements for the modern

application or identify gaps in current

practice. This also helps to define how

compliance should be verified.

3. Who is the appropriate authority for

compliance? Typically an organisation,

board or individual is accountable for

compliance to a specific requirement. For

example, the CEO or CFO may be

accountable for corporate governance

obligations, the Chief Security Officer may

be accountable for information assurance

requirements, or an external party like a

government security agency may be

accountable. Sometimes the accountable

party has the flexibility to choose not to be

compliant on certain requirements, as long

as they understand and accept the risk –

but still remain accountable for the

outcome.

4. How is the compliance requirement

verified? A privacy requirement, as an

example, may state that an organisation

only uses private data for the purposes for

which it was collected. This may translate

into a requirement that a cloud service

provider must contractually commit not to

use customer supplied data for any other

purpose than delivering the service.

Verification may be to confirm this is

included in the contract.

29

Privacy Compliance requirements related to privacy

may result from federal and state legislation,

industry regulations, codes of practice,

government policies and other sources.

Although this may lead to a great deal of

variety in the specifics, there are some

general principles that often surface. These

typically include restrictions on the

appropriate collection and use of private data,

the need to notify individuals about privacy

policy and seek their consent and the need to

effectively secure and maintain the integrity

of private data.

There may also be some controls on the

transmission of private data outside the

original jurisdiction. In these cases,

compliance requirements may require either

the explicit consent of subjects for their data

to be sent offshore, or a contract between the

organisation and the service provider that

ensures the privacy protections are

maintained by the service provider. The

compliance obligation generally rests with the

organisation that collected the data and does

not typically transfer to the service provider,

except as a set of contract terms they should

adhere to.

The following table highlights some of the

privacy related compliance requirements that

might exist and be relevant to a modern

application. Working through these questions

will help determine the compliance

requirements around privacy that need to be

factored in.

Question

Sources What acts of legislation, rules, regulations, policies or codes or practice exist that relate to how the organisation deals with private information?

Is there a Privacy Commissioner, ombudsman or other independent party that oversees compliance to privacy requirements?

Do the privacy compliance requirements make a distinction between private and sensitive data?

Current Practice

How does the organisation currently ensure their compliance with privacy requirements?

How will current privacy practices be impacted by deployment of the solution being evaluated?

Authority Who is currently accountable in the organisation for privacy compliance?

Specifics Will any personally-identifiable information be collected, processed or stored within the application?

Is employee information, collected, processed or stored?

Is any of the private information regarded as sensitive, private information, such as health records or financial data?

What principles and requirements govern the collection and use of private data?

What requirements exist around notice and consent?

Are there restrictions on the transfer of data out of the jurisdiction and if so, what are they?

What restrictions must be enforced on any service provider processing data?

What restrictions must be enforced on the device used to collect data, such as location and user details?

Are there any particular standards that need to be complied with, either for privacy impact assessment or privacy practices?

Verification How is compliance with privacy requirements demonstrated or verified?

Is there an external mechanism for auditing, certifying or attesting to privacy compliance obligations?

Figure 18: Privacy Compliance Questions

30

Records Many government and private sector

organisations have specific requirements to

maintain effective record-keeping systems.

Generally these requirements call for

important records to be protected from loss,

destruction or falsification.

Records generally should be categorised with

details of retention periods, formats, location

and media. Consideration needs to be given

to possible deterioration or loss and formal

procedures for handling, processing and

disposal need to be defined.

In government, record keeping requirements

are formally codified with additional

requirements often relating to freedom-of-

information requests, national security

classification and archiving.

In the context of modern applications, these

record keeping compliance requirements can

lead to concerns around:

how the integrity of information is

maintained within a cloud service through

mechanisms like backup and recovery

how information is classified, marked or

identified to ensure it can be located in the

future

how the service or data will be accessible

in the future for the duration of the

required retention period

how the integrity of the record keeping

system can be verified through audit or

other measures

how these audit mechanisms are

protected to ensure they cannot be

tampered with

how information held in particular formats

can be accessible in the future

how records be provided in the event of

legal discovery or law enforcement request

This table highlights some of the key

questions around records compliance that

should be worked through.

Question

Sources What acts of legislation, rules, regulations, policies or codes or practice exist that relate to how the organisation deals with records?

Is the organisation subject to freedom-of-information, archive disclosure or other government regulations?

Current Practice

How does the organisation currently ensure their compliance with record keeping requirements?

How will current record keeping practices be impacted by deployment of the solution being evaluated?

Authority Who is currently accountable in the organisation for record keeping compliance?

Specifics Are there formal information classification and marking schemes that the organisation complies with?

What requirements exist for the storage and retention of records?

Is the information that will be processed in the solution considered to be a formal organisation record?

Are there any restrictions on record formats or media?

How should disposal of data be handled?

What audit mechanisms need to be in place to ensure that records are not tampered with?

Is there a need for the organisation to deal with freedom-of-information requests or legal discovery on the information in the solution being considered?

Verification How is compliance with record keeping requirements demonstrated or verified?

Is there a mechanism for external auditing, certifying or attesting to record-keeping compliance obligations?

Figure 19: Records Compliance Questions

31

Information Assurance Many organisations have specific information

security assurance obligations that derive

either from government security policies,

sector-specific regulator policies or as a result

of the nature of their business operations.

Government agencies will typically have

centrally defined requirements such as the

Protective Security Policy Framework(PSPF) in

Australia or the Federal Information Security

Management Act in the US (FISMA). These

typically entail a range of security controls

that should be applied by an agency, a

mechanism to accredit a system’s security and

a management framework for accountability

and governance. Generally, the information

classification dictates how the extent to which

these controls are mandatory.

Private sector organisations that act as

suppliers to government might also need to

factor in government compliance obligations

into their thinking. Private sector

organisations that process credit cards, health

care information or other sensitive activities

may also have externally imposed information

assurance requirements, such as the Payment

Card Industry Data Security Standards

(PCIDSS).

In high security environments, particularly

those operated by national security

organisations of government and their

suppliers, explicit formal evaluation

procedures may apply. For example, software

or a device may need to undergo a formal

Common Criteria evaluation against a

specified Protection Profile in order for it to

be considered acceptable for use. Certain

devices, applications and cloud services may

not be permitted for use if these security

evaluations are not complete and current.

More commonly though, information security

assurance requirements derive from best

practices defined in standards like ISO 27001

and ISO 27002

Question

Sources What acts of legislation, rules, regulations, policies or codes or practice exist that relate to how the organisation secures information?

Current Practice

How does the organisation currently ensure their compliance with information assurance requirements?

How will current information assurance practices be impacted by deployment of the solution being evaluated?

Authority Who is currently accountable in the organisation for information security compliance?

Specifics What classification of data will be stored or processed within the solution being evaluated, and does this have a bearing on the level or extent of information assurance compliance obligations?

Do the information assurance requirements align to any existing international standard or best practice, such as ISO standards?

Are there formal processes for accreditation or certification that need to be adhered to?

To what extent are the requirements mandatory or optional?

What compliance requirements exist around physical security that need to be factored in?

What are the compliance requirements around personnel security, such as employee screening and clearance?

What are the compliance requirements around information security?

Are there specific requirements around how information security management is governed?

Do the information assurance requirements specifically make distinctions around outsourcing or offshoring of data?

Verification How is compliance with information assurance requirements demonstrated or verified?

Is there a mechanism for external auditing, certifying or attesting to these compliance obligations?

Figure 20: Information Assurance

Compliance Questions

32

Other Compliance Requirements These are just some examples of the types of

compliance requirements that exist. Only the

customer organisation can determine the

specific range of compliance obligations they

hold. Some other types of compliance

requirement might include:

Intellectual Property

Most countries have legal requirements

around copyright and other intellectual

property infringement. It’s important for an

organisation to understand precisely who

retains intellectual property ownership over

data stored in a cloud service and the possible

derivative uses of that data.

Procurement Processes

Many government agencies have specific

procurement practices such as standard terms

and conditions, panel contracts of approved

suppliers, authorisation limits and gateway

reviews. These processes may introduce

specific compliance requirements that need

to be factored into the assurance process.

Appropriate Use

Most organisations have compliance

requirements around the appropriate use of

information and communications technology.

In particular, services may be restricted from

being used for distribution of pornography,

sharing of child abuse images, publication of

terrorist material, etc. Similarly, organisation

may need to ensure their information and

communications technology is not used to

perpetrate fraud or other crimes, such as

sending out spam or malware.

Lawful encryption

There may be compliance restrictions on the

use of very high grade cryptographic

materials. Although these restrictions have

lessened and usually only affect national-

security related organisations, an organisation

may need to consider if these apply.

33

Security Architecture and Policy

Requirements Every organisation has existing technology

infrastructure and practices or intended

strategic directions that need to be

considered when evaluating the security

capabilities of a modern application. For

example, if an organisation has invested in

deploying a particular identity management

solution, it would be desirable for the cloud

and device solution being evaluated to be

able to integrate with this identity solution.

Note that these requirements are not the

business requirements of the specific solution

being considered, but are the security

requirements that would apply broadly to any

modern application to enable it to integrate

with the organisation. For example, this

would include acceptable mechanisms of

authentication and access control, required

support for encryption of data across the

network, mechanisms for identity integration,

necessary interfaces for audit and event

reporting and so on.

The three key areas of security architecture

and policy that need to be considered in the

evaluation are:

Identity & Access: How the organisation

registers new users, authenticates,

authorises and oversees access of users to

information

Management & Monitoring: How

infrastructure and applications within the

organisation are currently managed and

monitored

Information Protection: Specific

technologies or approaches used by the

organisation to protect information

The easiest way to identify these security

functional requirements is to work through

questions such as in the table below.

Identity & Access

Question

Authentication What forms of authentication are acceptable for the solution (eg. Passwords, certificates, one-time-passwords, hardware tokens, etc)?

Does the organisation currently use multi-factor authentication?

Does the device need to be authenticated as well as the user?

Will sensitive users such as administrators require higher assurance authentication?

Is single-sign-on a requirement for the solution through identity federation?

Are there specific technologies or standards required by the organisation for authentication, such as SAML, OAUTH, x.509, etc.?

Access Control

How does the organisation currently perform access control to applications?

What factors are incorporated in making an access decision, such as user identity, device identity, location, etc?

Is there a mechanism for centralised authorisation employed or intended to be used by the organisation?

Are there specific technologies or standards used by the organisation for access control, such as SAML, XACML, etc?

Provisioning & Lifecycle Management

How is the lifecycle management of identities within the organisation currently performed?

Is there a centralised technology or management system used by the organisation for identity lifecycle management?

Audit & Logging

How much data needs to be logged and audited within the solution? (for example, every login / every action / every attempted action, etc)

Are there existing technologies used by the organisation for logging or auditing?

Do the access logs need to be correlated with other sources of logs, for example physical access events with online access events?

Figure 21: Identity & Access Requirements

34

Management & Monitoring

Question

Configuration Management

What tools or systems does the organisation currently use for asset and configuration management?

How are configuration change processes currently implemented within the organisation?

Are there systems or applications within the organisation for which their configuration needs to be strictly controlled – for example, critical infrastructure components?

Security Management & Monitoring

What tools or systems does the organisation currently use for security incident and event management?

What existing incident response processes will need to integrate with the solution?

Will the organisation need to correlate events across cloud, on-premise and devices?

Service Management & Monitoring

Are there tools or systems that the organisation uses as standard for service management and monitoring?

How does the organisation currently track service availability and performance?

If an existing service became unavailable within the organisation, how would the organisation become aware and what processes would trigger?

Figure 22: Management & Monitoring

Requirements

Information Protection

Question

Encryption What requirements does the organisation have as standard for encryption of data-at-rest on devices or in the cloud?

What requirements does the organisation have for encryption of data-in-transit?

Are there specific encryption protocols, algorithms or key sizes required?

What key management practices are required?

Do the encryption keys need to remain controlled by the organisation? If so, does the organisation have appropriate key management and distribution infrastructure?

Threat Management

How does the organisation currently implement threat management (such as anti-malware, anti-spam, intrusion detection and prevention systems, etc)?

Will the organisation require traffic between clients and web services to traverse a controlled gateway?

If so, what restrictions are imposed at that gateway (ie. protocols, ports, white/black lists, etc)?

How does the organisation perform vulnerability scanning and address vulnerabilities discovered?

Data Loss Prevention

What are the organisations current practices around backup and recovery that are relevant to the solution?

Does the organisation currently implement or require data labelling or classification? If so, is this automatic or selected by the user?

Do security controls need to enforce policy such as data flow restriction, encryption or auditing based on labelling or classification?

How would the organisation currently deal with a data spillage event?

Does the organisation have any specific requirements for media sanitisation or destruction?

Figure 23: Information Protection

Requirements

Wo

rked

Exa

mp

le

35

Worked Example

External Requirements (Compliance)The following table of compliance requirements has been developed based on a review of key

documents:

1. NSW Cloud Services Policy & Guidelines, August 2013 (CSP&G)

2. NSW Digital Information Security Policy, November 2012 (DISP)

Unless otherwise noted, the authority for all compliance requirements is the Department’s Risk &

Audit Committee.

Source & Authority

Specifics Current Practice Verification

State Records Act 1998 and General Authority (GA35)

State Records are prohibited from leaving the state except under circumstances authorised by GA35, namely:

The Department must assess and address the risks involved in taking and sending records out of the State for storage or processing by a cloud service provider

The cloud service providers’ facilities conform to requirements in standards issued by the State Records Authority

Contractual arrangements and controls are in place for safe custody and preservation of records

Ownership of records remains with the Public Office

The arrangement should be monitored for conformance to standards.

The Department currently only processes and stores data within NSW on Department premises that conform to State Records standards

Internal audit

Possible external audit by State Records Authority

Privacy and Personal Information Protection Act 1998

Health Records and Information Privacy Act 2002

Agencies must take reasonable steps to ensure that no unauthorised access, use, modification or disclosure of personal information occurs.

The Department must ensure provisions for the following are in place:

The cloud provider must hold and process customer data consistent with the instructions of the Agency, and may not use the data for its own purposes.

Data security and safeguards against misuse, loss, unauthorised access or alteration must be in place

The Department and the data subject must be able to have ongoing access to the data. Access for the data subject will typically be via the Department.

Although the Department does not currently use cloud services, it does have processes in place to manage compliance with privacy requirements when dealing with third party contracted suppliers and service providers.

In these instances, the Department manages private information and third parties are prohibited from using or disclosing that information for any other purpose than contracted with the Department.

Full ownership of data remains with the Department.

All requests for access by a data subject to their private information are handled by the Department, not by the contracted supplier.

No formal verification requirements exist

Wo

rked

Exa

mp

le

36

Source & Authority

Specifics Current Practice Verification

Ownership of data must remain with the Public office on termination of the service

Data must be retained unless authorised to be disposed

Government Information Public Access Act 2009

Members of the public have an enforceable right to access government information. The specific relevant requirement is:

The Department must ensure that records and data created, stored and managed on the cloud remains accessible and retrievable. The cloud service provider does not respond directly to a request for information under this Act.

The Department has a formal process for responding to any freedom of information requests.

No formal verification requirements exist

NSW Digital Information Security Policy Memo

All NSW Government Departments must satisfy a set of information security management requirements:

Departments must have in place an Information Security Management System (ISMS) based on the application of ISO 31000 for risk management and ISO 27001 for information security management.

Agencies must comply with a specific minimal subset of controls across the domains of ISO 27001

All shared service providers within government must attain and maintain third party accreditation to ISO 27001

Each agency must attest annually to the adequacy of their information security

The Department is currently in the process of implementing improvements to the governance and practice of information security.

The minimal set of mandated controls are implemented but the Department has not obtained certification to ISO 27001.

Annual attestation for the Agency

Certification to ISO 27001 by third party independent accreditor

Procure IT Procurement Guidelines and Standards Terms

It is mandatory that all procurement processes, terms and conditions of contracting are consistent with the NSW Government Procure IT. This includes:

Processes for tendering, probity, evaluation and ordering of products and services that must be performed

Standard contract terms covering issues such as liability, indemnity, intellectual property, etc. that should be included in supply contracts

The Department currently leverages the ProcureIT framework. Where circumstances deviate, the Department can alter standard contract terms within appropriate authorisations.

Possible procurement review or audit

Wo

rked

Exa

mp

le

37

Internal Requirements (Security Architecture & Policy)The following table describes the internal security requirements of the Department as they relate to

each of the key areas of identity & access, management & monitoring and information protection.

The Authority for all requirements is the Department’s Chief Information Officer.

Identity & Access:

Source & Authority

Specifics Current Practice Verification

Internal Access Control Standards

Authentication:

For general users, username and password credentials are acceptable within the Department network

Two factor authentication using a smartcard or other factor is preferable for remote access to information

Two factor authentication is required for all administrator access to the service

The Department has a strategy to progress towards single-sign-on for all corporate applications. Cloud services will need to integrate by performing federated authentication

The Department favours the use of SAML 2.0

The Department currently only uses domain credentials or username/password combinations for authentication to applications.

Administrators must authenticate with a smartcard to work remotely, but internally can just use domain credentials.

Having single sign-on is desirable future state for the Department

None

Internal Access Control Standards

Access Control:

Access to applications must be authorised by an administrator based on a determination of business need

For the applications being assessed in this evaluation, all should be accessible remotely

Access to each corporate application is currently managed one by one by the corporate applications team.

The only application that is available remotely at present is email through a web access portal.

None

Internal Access Control Standards

Provisioning & Lifecycle Management:

Once a user is created in the corporate directory, they should automatically get access to the base level of applications, including email, collaboration and communications.

The Department should be able to manage groups of users with similar access rights, granting those groups access to applications as a group.

If an employee leaves the organisation, their account should be suspended internally which should then immediately revoke acess to cloud services.

Currently, each new user is provisioned within the Departments Human Resources system and we have a process for then requesting a system user to be configured in our corporate directory. Periodically, users who have left the organisation are removed from the directory.

None

Internal Security Audit Standards

Audit & Logging:

The Department requires every user login event to be logged and auditable.

The Department currently logs all login events and each application used within the Department has capabilities for application specific logging.

None

Wo

rked

Exa

mp

le

38

Source & Authority

Specifics Current Practice Verification

This at a minimum should include date/time and application accessed.

The Department requires all data deletion and modification actions to be logged and audited

It should be possible to selectively configure auditing for all read access

All logs should be accessible to the Department

Management & Monitoring:

Source & Authority

Specifics Current Practice Verification

Systems Management Standards

Configuration Management:

.The Department should be able to administer the configuration of the application and have advance notice of changes to the cloud service configuration that might affect users.

The Department has a configuration management process but no formal toolset that needs to be integrated with

None

Incident Response Standard

Security Management & Monitoring:

The Department should be able to configure and view reports of system access, malware detections or other security event.

The Department should be alerted to suspicious activity or attacks against Department applications

Currently, access to all external resources is monitored through a gateway. All malware incidents are reported though a security management application

None

Systems Management Standards

Service Management & Monitoring:

The Department must be able to access management reports on service availability and performance, tracked against committed service level agreements

Nominated system administrators in the Department should be alerted if any services become unavailable.

Service reporting information should be integrated with the Department’s existing service management toolset

The Department has in place a systems management tool for help desk, case management, alerting and executive reporting.

None

Wo

rked

Exa

mp

le

39

Information Protection:

Source & Authority

Specifics Current Practice Verification

Network Security Standard

Encryption:

Data should be encrypted at rest within the cloud service

It is desirable for there to be a dedicated network connection or encrypted virtual private network between users inside the corporate network and the cloud service

Users accessing the service from outside the corporate network should always have their communication encrypted using at least SSL3.0

It should be possible to selectively encrypt documents or communications based on the sensitivity or classification of the data within them.

The Department currently has limited use for encryption, except in the case of S/MIME for encryption of secure emails for one part of the organisation.

None

Incident Response Standard

Threat Management:

The Department requires all communications to be scanned for malware and spam prevention should be performed by the service provider

The service provider should be able to demonstrate intrusion detection and prevention capabilities within the cloud service.

Currently, the department has an antimalware solution installed on premise for email communications and using an external service for spam.

Intrusion detection is primarily performed at the network gateway where the Department has installed network firewalls and intrusion detection systems

None

Systems Management Standards

Data Loss Prevention:

The Department should be able to block or hold communications being sent to or from the cloud service. .

It should be possible to assign a classification to documents or other records using metadata

Currently the Department has little capability to detect or block flows of information out of the Department.

None

40

Step 3 – Verify Claims

Assurance Boundaries The intent behind defining assurance

boundaries is to break the solution down into

components about which a specific set of

security assurance claims can be made.

Usually, these are set by the limits of a party’s

span of control. For example, consider a

cloud service provider that operates

infrastructure-as-a-service to offer virtual

machines. The cloud service provider can

make claims about the security of the physical

data centre, the backup and recovery

mechanisms, security monitoring, the

virtualisation fabric, and so on. They may

conduct audits and obtain certifications like

ISO27001. But they are unable to make any

valid security claims about the applications

running within the virtual machines, about the

network connecting the virtual machines to

an end user or about the security of the end

user’s device.

A typical modern application that leverages

cloud services, devices, big data and social

networks may be composed of a number of

assurance boundaries. A realistic example is

illustrated below for a solution that provides

online learning and video conferencing. There

are at least eight assurance boundaries in this

solution:

1. Enterprise on premise infrastructure

including the devices and other systems

2. Enterprise cloud identity & collaboration

service which provides the services for

communication and sharing of information

3. Cloud application which provides the

learning application operated by a

different cloud service provider

4. Cloud application infrastructure which may

be operated by a third party cloud provider

5. Consumer identity service such as a

Facebook, Microsoft or Google identity

6. Consumer communications service such as

Skype enabling the consumer to perform

voice and video-conferencing

7. Consumer apps & devices in the home

through which they interact

8. App store which facilitates the discovery

and deployment of apps to the end user

Figure 24: Example of a complex solution with multiple assurance boundaries

41

Not all assurance boundaries need to be

assessed with the same level of rigour and

some can indeed be safely disregarded. In our

example scenario, most of the assurance

focus would be on assurance boundaries 2, 3

and 4 which compose the enterprise cloud

services for identity, collaboration and the

online learning application. It may however

be worth investigating the effectiveness of the

privacy practices within the consumer

communications service to ensure that the

consumer’s privacy is not adversely affected

(assurance boundary 5), or assess the integrity

of the consumer identity service (boundary 4)

or even the integrity of the app store

(boundary 7).

The intent is not to conduct an exhaustive

assurance process over every aspect of the

solution, but to map out the different spans of

control that exist over the security of different

parts of the solution. In the example solution,

every assurance boundary has a different

owner and only the owner can make

meaningful assurance claims. In this case,

the vendor of the online learning application

(ie. the owner of assurance boundary 3) can

make claims about the security of the

application but they also rely on the validity of

claims made by the cloud virtualisation

service on which the application runs (ie. the

owner of assurance boundary 4). However,

the service provider for the collaboration

service also operates the identity service and

can therefore make meaningful claims about

the security of both services together.

So the question then is what types of claims

can an assurance boundary owner make and

how do they relate to the functional security

requirements and compliance requirements

of the organisation.

Types of Assurance Claims Cloud service providers, application vendors

and device manufacturers seek to assure

prospective customers of the security of their

services using a variety of certifications, audits

and attestations. Examples include ISO 27001

certification, SSAE16 audit reports,

government certifications like FISMA and UK-

IL2 and compliance with privacy terms like

HIPAA, Safe Harbour, EU Model Contracts and

Data Protection Agreements or industry

assurance mechanisms such as those of the

Cloud Security Alliance and Open Data Centre

Alliance. Devices, applications and equipment

used within cloud services may also be

evaluated in formal schemes such as Common

Criteria or FIPS140.

Documentation provided by cloud service

providers in the form of technical

descriptions, security control frameworks,

contractual service descriptions, policy and

procedures documents can also be valuable.

Even though it may not be validated by a third

party, most service providers are careful to

only claim functions, capabilities and

processes that they do indeed perform.

Each of the forms of assurance claim have

varying intent, scope, applicability and

ultimately merit in verifying the security

assurance of a service, application or device.

There are some key considerations to keep in

mind when assessing the merits of any

particular claim:

Scope: The scope of an assurance claim may

be limited to certain facilities, locations,

functions, business units or other criteria. The

scope may not match the elements of the

solution within the assurance boundary.

Type: Some assurance claims relate only to

the management of security, others relate to

the actual observed practices. Some have

only a financial or operational focus (for

example SSAE 16 SOC1). Others are more

technical in nature such as FISMA

certification.

42

Authority: Service providers can be self-

audited or engage an external audit.

Generally, a reputable external auditor

provides a higher level of assurance. Other

claims require very specific certifying

authorities such as the US Federal

Government in the case of FISMA/FedRamp,

the UK Government in the case of UK-IL2, etc.

Applicability: Some assurance claims are

more appropriate to cloud services while

others relate to applications or devices. For

example, Common Criteria and FIPS 140 are

not relevant to cloud services as a whole but

be very relevant to devices and applications

used within a cloud infrastructure.

Validity: Some certifications are only valid for

a defined period of time and need to be re-

audited on a periodic basis. Others are only

valid for a particular configuration in

perpetuity but are no longer deemed valid if

the configuration changes.

The following is a high level guide to some of

the more common security claims.

Technical Documentation Service providers, device manufacturers and

application vendors commonly publish

technical information on their security

capabilities and practices. This may include

whitepapers, control frameworks and

implementation guides that provide

comprehensive security details. Most

reputable service providers take a substantial

amount of care to ensure that their

documentation is accurate.

As a starting point, this technical

documentation is probably the most useful

resource. The downside of technical

documentation is that it is unverified by an

external party so important security assurance

claims need to be verified by other means.

Cloud Security Alliance STAR Registry The Cloud Security Alliance (CSA) was formed

in 2008 as a not-for-profit organisation with a

mission to promote the use of best practices

for providing security assurance of cloud

computing services. It is comprised of quite a

broad coalition of industry practitioners,

corporations, associations and other key

stakeholders. As one of their first steps, the

alliance created the CSA Security, Trust &

Assurance Registry (STAR). This is a publicly

accessible registry that documents the

security controls provided by various cloud

computing offerings, thereby helping users

assess the security of cloud providers they

currently use or are considering contracting

with. Within the STAR registry, cloud service

providers publish details on how they

implement each of the controls within the

CSA Cloud Controls Matrix which is a

generalised security control framework for

cloud services.

There can be very significant variability in the

depth of information provided by different

vendors with some service providers simply

indicating compliance to controls, while

others provide extensive documentation on

how many controls are implemented.

The major drawback of the CSA Registry is

that all information is self-reported and non-

verified. To address this, the CSA has recently

introduced three new levels of reporting,

called CSA STAR Certification, CSA STAR

Attestation and CSA STAR Continuous.

Although few service providers have yet

adopted these additional levels, it is likely that

CSA STAR Certification in particular will gain

traction. This certification involves third party

audit against both the CSA Cloud Controls

Matrix and ISO 27001.

Further information on the Cloud Security

Alliance STAR is available at:

https://cloudsecurityalliance.org/star/

43

ISO 27001 Certification to ISO 27001 is perhaps the most

common assurance claim of cloud service

providers. Published in 2005, ISO 27001

formally describes an information security

management system with mandated

requirements across 11 different domains:

Security policy: the executive direction and

oversight around security

Organisation of information security: how

information security decisions are made

Asset management: inventory and

classification of information assets

Human resources security: employee

screening, training and exit

Physical and environmental security:

protection of the computer facilities

Communications and operations

management: technical controls around

exchange of information in networks

Access control: restriction of access rights to

networks, systems, applications and data

Information systems acquisition,

development and maintenance: how security

is built into the end-to-end lifecycle of

systems

Information security incident management:

preparing for and responding to information

security incidents

Business continuity management: ensuring

resilience of systems to disruption and

disasters

Compliance: satisfying local security policies,

standards, laws and regulations

A cloud service provider or other organisation

that has adopted ISO/IEC 27001 can be

formally audited and certified by an external

party as compliant to the standard. Upon

completion of the audit, the Cloud Service

Provider can provide a certificate of

compliance. The certificate will identify the

scope of certification which commonly

includes specific locations and services in

scope for the certification but generally

provides little additional detail. The Service

Provider should also be able to provide a

more detailed ISO 27001 Audit Report which

includes a summary of audit findings in each

of the 11 domains of the standard. This audit

report can be useful in determining if the

cloud service provider controls align to the

customer security controls.

Although the standard predates the

emergence of cloud computing and mobility,

the principles and requirements are

structured in a manner by which they are still

very appropriate. A revision of the standard

to ISO27001:2013 has recently been finalised

with changes that reflect an increasing focus

on risk management, security leadership and

executive focus on security outcomes. Some

controls have been updated to reflect modern

threats and security approaches. It will

however take a period of time for cloud

service providers and others to transition to

this revised standard.

44

SSAE 16 (SAS 70) – SOC & ISAE 3402 Statement on Standards for Attestation

Engagements no. 16 (SSAE 16) is a recent

standard put forth by the Auditing Standards

Board (ASB) of the American Institute of

Certified Public Accountants (AICPA). For

reporting periods ending on or after June 15,

2011, SSAE 16 became the new standard for

reporting on controls at service organizations,

essentially replacing Statement on Auditing

Standards no. 70, commonly known as SAS 70.

ISAE 3402 is a standard for reporting to which

SSAE16 complies. So to simplify – the

important assurance claim for a Customer to

focus on is SSAE 16, but there a few key points

to understand about how it works.

Firstly, SSAE16 provides for audit statements,

not certifications. So a service provider

cannot be ‘compliant’ to SSAE16 but rather

can provide an attestation to SSAE16.

Secondly, there are three different forms of

report under SSAE16. SOC 1 reports focus on

the internal control over financial reporting.

SOC 2 reports are more specifically designed

for reporting on the technical and procedural

controls of technology related entities,

including cloud service providers. Lastly,

similar to SOC 2 is SOC 3, which utilises a

defined list of Trust Services Principles to

report on cloud service provider practices in

five key areas:

Security: The system is protected, both

logically and physically, against

unauthorised access.

Availability: The system is available for

operation and use as agreed to.

Processing Integrity: System processing is

complete, accurate, timely, and

authorised.

Confidentiality: Information that is

designated “confidential” is protected as

committed or agreed.

Privacy: Personal information is collected,

used, retained, and disclosed in

conformity with the commitments in the

entity’s privacy notice and with the

privacy principles put forth by the

American Institute of Certified Public

Accountants (AICPA) and the Canadian

Institute of Chartered Accountants (CICA).

Thirdly, there are two ‘types’ of report: Type I

and Type II. Type I reports describe the

system and state that certain controls and

management practices are in place. Type II

reports build on this to indicate that these

controls and practices were consistently

applied and operating effectively over a

defined period of time.

Finally, the SSAE 16 standard requires a

written “assertion” by management. This

written assertion is essentially an assertion

made by the service organisation that must be

provided to the service auditor (i.e., the

auditing firm that is conducting the SSAE 16

engagement) representing and asserting to a

number of essential clauses, such as:

The description fairly presents the service

organisation's "system”

That the control objectives were suitably

designed (SSAE 16 Type I) and operating

effectively (SSAE 16 Type II) during the

dates and/or periods, as asserted to.

The criteria used for making these

assertions (which are additional

statements with supporting matter

regarding risk factors relating to control

objectives and underlying controls) were in

place (Type I) and were consistently

applied (Type II).

Customers assessing the security claims of a

particular service should request the SSAE16

SOC 2 or 3 Type II attestation if it is available.

This will be one of the most useful documents

in verifying the security claims of the service

provider. Similar to ISO 27001 certifications,

it is important to check that the attestation

scope is relevant to the systems within the

assurance boundary being considered.

45

FISMA / FedRAMP Authority to

Operate Based on experience with FISMA and the

lengthy time it takes for each agency to

evaluate and authorise operation of cloud

services for its own usage, the U.S. General

Services Administration launched an effort to

standardise security assessments of cloud

products and services across the government.

This program, called Federal Risk and

Authorisation Management Program

(FedRAMP), provides a government-wide

certification process to reduce costs and

duplication when multiple agencies attempt

to certify products and services for security

compliance.

In the past, each agency would typically take

applications and services through their own

FISMA accreditation process. FedRAMP

allows cloud services to be accredited once

and have that accreditation leveraged by all

federal agencies using what is called a

Provisional Authority to Operate (P-ATO).

The FedRAMP control set includes the NIST

800-53 R3 defined baseline for low and

moderate impact systems and a set of

controls that are FedRAMP requirements

above the baseline. These requirements have

parallels in the requirements of other

countries like the UK and Australia.

Federal government agencies in the US are

required to ensure that cloud service

providers they contract with have authority to

operate under FedRAMP. Further information

on FedRAMP and the list of cloud service

providers that have authority to operate can

be found at:

http://www.gsa.gov/portal/category/102371

US-EU Safe Harbour, Data

Processing Agreements and EU

Model Contracts There are a number of different but related

claims that a service provider may make in

relation to privacy.

The European Union/United States Safe

Harbor framework provides a means to help

U.S. organizations meet data transfer

requirements as needed by the European

Commission’s Directive on Data Protection.

Organisations self-certify that they implement

a comprehensive system of privacy

protections, permitting the transfer of private

information between EU and US data centres.

Moving beyond the Safe Harbour self-

certification mechanisms, in 2010, the

European Union released the EU Model

Contract Clauses (EUMC). These Model

Clauses help customers certify compliance

with the European Commission's Data

Protection Directive in order to allow them to

transfer data outside of the European

Economic Area. They include additional

security and notice requirements that a

service is willing to contractually commit to in

order to support customers. When included in

service agreements with data processors, the

Model Clauses assure customers that

appropriate steps have been taken to help

safeguard personal data, even if data is stored

in a cloud-based service centre located

outside the European Economic Area.

Some service providers will commit to data-

processing agreements (DPAs) for all

customers regardless of whether the

customer is located in the EU. This is because

broadly the EU data protection directives are

generally regarded as the high bar in privacy

protection globally. A customer organisation

that has particular sensitivity to privacy in

their assurance objectives should request the

service provider’s capability to contract to a

Data Processing Agreement and verify the

contract terms within that agreement.

46

Common Criteria & the Federal

Information Processing Standard Organisations that are familiar with

conventional approaches to security

assurance such as Common Criteria or FIPS

often look for a similar or equivalent

evaluation approach to cloud computing.

Existing government assurance requirements

may state a preference or need for

technologies used by government agencies to

be evaluated.

These models however have challenges in

being applied to cloud services and there is

currently no mechanism by which any cloud

service could be evaluated consistent with

Common Criteria. Technologies, devices or

applications used within cloud data centres or

network and computing equipment used to

access cloud services could however be

evaluated according to Common Criteria or

FIPS140.

Wo

rked

Exa

mp

le

47

Worked Example

External Requirements (Compliance)Building upon the external requirements defined in stage 2, the Department has undertaken a

review of technical documentation provided by cloud service providers, certification and

accreditation reports and contract terms. To assess option 3 (on-premise solution), the Department

assessed current practices in assessing our ability to meet compliance requirements.

The following table summarises the findings across the three alternative options.

Legend:

Fully conforms to requirement

Conforms with some additional contractual,

process or technical changes

Partial conformance to requirement

Non-conformant to requirements

Requirement 1: On Premise 2: Local Hosted Cloud 3: Public Cloud

State Records are prohibited from leaving the state except under circumstances authorised by GA35, namely:

The Department must assess and address the risks involved in taking and sending records out of the State for storage or processing by a cloud service provider

Records are not leaving the state, so

risk assessment is not required

By reference to the risk assessment

section of this assurance evaluation, this requirement can be fully addressed

Stage 4 of this assurance process

(risk assessment) addresses this requirement

The cloud service providers’ facilities conform to requirements in standards issued by the State Records Authority

Current facilities on Department premises

conform to the standards requirements.

Technical description of local hosted cloud

provider facilities reviewed and found to be conformant to standards

Documentation review of physical security

measures provides sufficient assurance that physical facilities are conformant to requirements.

Contractual arrangements and controls are in place for safe custody and preservation of records

No contractual arrangement

necessary as records will be kept by the Department and preserved in an equivalent manner to current record keeping processes

Review of the standard contract

includes specific terms for the preservation of records

Review of the standard contract

includes specific terms for the preservation of records. Customer data held in the cloud can be destroyed 90-120 days after termination of the service, so the agency would have only that long to repatriate all data.

Ownership of records remains with the Public Office

No issue, as no data is leaving the

Department

Contract terms state that ownership rights

on all data remain with the customer.

For the public cloud provider being

evaluated, a standard contract term states that the Customer retains all right and ownership of the data.

The arrangement should be monitored for

Current monitoring practices are only

All data within the local hosted cloud can

Monitoring conformance to

Wo

rked

Exa

mp

le

48

Requirement 1: On Premise 2: Local Hosted Cloud 3: Public Cloud

conformance to standards.

partially effective without complete visibility of information and records locations and classifications.

be effectively monitored with ease of access for physical inspection

standards will be achieved through annual certification to ISO 27001, but physical inspection or 1st party audit is not permitted

With regard to compliance of the Privacy of Personal Information Protection Act, the Department must ensure provisions for the following are in place:

The cloud provider must hold and process customer data consistent with the instructions of the Agency, and may not use the data for its own purposes.

No issue, as no data is leaving the

Department

Contract terms state that ownership rights

on all data remain with the customer.

Cloud service provider will sign a Data

Processing Agreement that explicitly states they will not use data for their own purposes

Data security and safeguards against misuse, loss, unauthorised access or alteration must be in place

The Department has work to do to improve

the current state of information security, particularly in relation to data loss prevention and authorisation of access

According to technical documentation

provided, the hosting provider does implement a comprehensive range of data security controls

Review of the technical

documentation, ISO 27001 audit report and SSAE16 SOC 2 attestations, the agency is confident the cloud service provider has an extensive range of data security controls in place.

The Department and the data subject must be able to have ongoing access to the data. Access for the data subject will typically be via the Department

No issue, as no data is leaving the

Department

The Department will be able to access

data within the service as required.

The Department will be able to access

data within the service as required.

Ownership of data must remain with the Public office on termination of the service

No issue, as no data is leaving the

Department

Contract terms state that ownership rights

on all data remain with the customer.

For the public cloud provider being

evaluated, a standard contract term states that the Customer retains all right and ownership of the data.

Data must be retained unless authorised to be disposed

No contractual arrangement

necessary as records will be kept by the Department and preserved in an equivalent manner to current record keeping processes

Review of the standard contract

includes specific terms for the preservation of records.

Review of the standard contract

indicates data will be retained unless authorised to be disposed, but can be destroyed 90-120 days after termination of the service if termination is by either party.

Members of the public have an enforceable right to access government information. The specific relevant requirement is:

Wo

rked

Exa

mp

le

49

Requirement 1: On Premise 2: Local Hosted Cloud 3: Public Cloud

The Department must ensure that records and data created, stored and managed on the cloud remains accessible and retrievable. The cloud service provider does not respond directly to a request for information under this Act.

No issue, as no data is leaving the

Department

During the period of the contract, the

Agency has full access to data in order to respond to requests for information

During the period of the contract, the

Agency has full access to data in order to respond to requests for information

All NSW Government Departments must satisfy a set of information security management requirements:

Departments must have in place an Information Security Management System (ISMS) based on the application of ISO 31000 for risk management and ISO 27001 for information security management

The Department’s ISMS is not currently

based on ISO 27001 and there are a number of domains where the Department would have to invest to conform to this requirement.

According to technical documentation

provided, the ISMS of the cloud hosting provider is derived from ISO27001 and they use ISO31000 for security risk management

According to information security

policy and ISO27001 audit report provided, the ISMS of the cloud provider is derived from ISO27001 and they use ISO31000 for security risk management

Agencies must comply with a specific minimal subset of controls across the domains of ISO 27001

Currently the Department

implements a range of security controls consistent with the minimum baseline but some changes in identity & access management would be required to satisfy all requirements

According to technical documentation

provided, the hosting provider does implement the mandatory controls

The agency has verified through

review of the ISO27001 audit report that the cloud provider implements the mandatory controls.

All shared service providers within government must attain and maintain third party accreditation to ISO 27001

This is not presently an issue as the

service would not be considered a shared service

The hosted service data centre is certified

to ISO 27001, but the application for collaboration and communications is not.

The cloud service provider maintains a

contractual commitment to maintaining ISO27001 accreditation annually on the application and the data centre.

Each agency must attest annually to the adequacy of their information security

Currently the Department attests

based on information available without any formal audit or certification regime, but improvement in the security program is required to address gaps.

A review of the ISMS used by the hosted

service provider is adequate, but doesn’t have formal attestation according to SSAE16 or a similar standard.

The cloud service provider maintains a

contractual commitment to maintaining ISO27001 accreditation annually on the application and the data centre. In addition, we have reviewed the SSAE 16 SOC 2 reports of the cloud service provider which are a strong basis for attestation

It is mandatory that all procurement processes, terms and conditions of

Wo

rked

Exa

mp

le

50

Requirement 1: On Premise 2: Local Hosted Cloud 3: Public Cloud

contracting are consistent with the NSW Government Procure IT. This includes:

Processes for tendering, probity, evaluation and ordering of products and services that must be performed

No issue, tendering for services to

implement the solution on premise can be conducted

The local hosted cloud provider is

familiar with our tendering processes.

Normal procurement processes for

tendering and evaluation present problems as the public provider is unlikely to respond to a market tender at fixed price, fixed spec.

Standard contract terms covering issues such as liability, indemnity, intellectual property, etc. that should be included in supply contracts

No issue with tendering for services

to implement the solution on premise can be conducted

Although the standard ProcureIT contract

terms need to be amended for a cloud service, the local cloud provider has worked with other government agencies locally on acceptable contracts.

Standard procurement contract terms and

conditions are not yet available in government and contract terms from the Cloud Provider are significantly different from ProcureIT

Internal Requirements (Security Policy and Architecture)The Department has reviewed the technical documentation provided by the alternative cloud

service providers. Workshops have also helped to assess the capability of each option to satisfy the

Departments’ needs.

The following table summarises the findings across the three alternative options.

Legend:

Fully conforms to requirement

Conforms with some additional contractual,

process or technical changes

Partial conformance to requirement

Non-conformant to requirements

Identity & Access

Requirement 1: On Premise 2: Local Hosted Cloud 3: Public Cloud

Authentication

For general users, username and password credentials are acceptable within the Department network.

Current practice of using username and

password credentials can be extended to the new solution

Username and password

authentication supported

Username and password

authentication supported

Two factor authentication using a smartcard or other factor is preferable for remote access to information

The Department’s implementation of

two-factor auth is only for system administrators. An additional project would need

Based on technical document review,

two-factor authentication is possible to implement but it is an additional service.

Two factor authentication is

supported by the cloud service natively or it can be integrated with an on premise two factor authentication provider.

Wo

rked

Exa

mp

le

51

Requirement 1: On Premise 2: Local Hosted Cloud 3: Public Cloud

to roll this capability out at substanial cost.

Two factor authentication is required for all administrator access to the service

Currently, this would require further

implementation work for the Department

Two factor authentication for

customer administrators is standard practice

Two factor authentication is

standard practice

The Department has a strategy to progress towards single-sign-on for all corporate applications. Cloud services will need to integrate by performing federated authentication

Although this strategy exists, it is currently

only at the planning stage

Standard practice of this hosting provider

The application includes an identity

governance capability

The Department favours the use of SAML 2.0

Currently none of the applications supported

by the Department use SAML 2.0, but an implementation of the new solution would involve SAML.

Based on technical document review,

applications with the hosted cloud either leverage SAML 2.0 already

SAML 2.0 is supported widely with

web-based applications on the public cloud

Access Control

Access to applications must be authorised by an administrator based on a determination of business need

Current in-house processes will

continue to apply

The Department will be able to control

provisioning of new users and granting access

The Department will be able to control

provisioning of new users and granting access

For the applications being assessed in this evaluation, all should be accessible remotely

There is currently minimal remote

access to applications from within the Department.

Applications will be accessible through a

browser or mobile device

Applications will be accessible through a

browser or mobile device

Provisioning & Lifecycle Management:

Once a user is created in the corporate directory, they should automatically get access to the base level of applications, including email, collaboration and communications.

The Department currently has no

mechanism to perform this automated provisioning and it is not feasible to include this within the project scope

A mechanism for automatic provisioning

of users within the cloud service with identity federation can be implemented within the scope

A mechanism for automatic provisioning

of users within the cloud service with identity federation can be implemented within the scope

The Department should be able to manage groups of users with similar access rights, granting those groups access to applications as a group

Currently access is granted on a

combination of groups and individual accounts

The Department will be able to control

access based on group membership

The Department will be able to control

access based on group membership

If an employee leaves the organisation, their account should be suspended

The Department does not currently have this

capability and it’s not feasible

Automatic de-provisioning of users

within the cloud service with

Automatic de-provisioning of users

within the cloud service with

Wo

rked

Exa

mp

le

52

Requirement 1: On Premise 2: Local Hosted Cloud 3: Public Cloud

internally which should then immediately revoke access to cloud services.

to implement this sophistication of de-provisioning in the project scope.

identity federation can be implemented within the project scope

identity federation can be implemented within the project scope

Audit & Logging:

The Department requires every user login event to be logged and auditable. This at a minimum should include date/time and application accessed.

Standard capability The Department can have full access to

logs and work with the hosting provider to adapt logging

All login events are audited and available

for review

The Department requires all data deletion and modification actions to be logged and audited

Standard capability The Department can have full access to

logs and work with the hosting provider to adapt logging

Deletion and modification logs are

available but from a technical workshop, it is clear the logging capabilities are reduced

It should be possible to selectively configure auditing for all read access

The Department can reconfigure auditing

as required

The Department can have full access to

logs and work with the hosting provider to adapt logging

A standard set of logs are available.

Adapting those or additing additional log triggers is limited

All logs should be accessible to the Department

All logs are held on premise and so

always available to the Department

All application logs should be available

but network logs are unlikely to be provided in the event of an investigation

Only the standard set of logs would be

accessible to the Department.

Management & Monitoring

Requirement 1: On Premise 2: Local Hosted Cloud 3: Public Cloud

Configuration Management:

The Department should be able to administer the configuration of the application and have advance notice of changes to the cloud service configuration that might affect users.

The Department can fully control the timing

of changes to the service

The Department would have advance

notice of changes but limited influence over their timing.

The Department generally may have

some advance notice of changes to the system functionality, but no ability to control the timing of those changes

Security Management & Monitoring:

The Department should be able to configure and view reports of system

The Department does not have a fully

cohesive security incident

The cloud provider reports on system

The cloud provider will report on system

access and malware

Wo

rked

Exa

mp

le

53

Requirement 1: On Premise 2: Local Hosted Cloud 3: Public Cloud

access, malware detections or other security event.

and event management system.

access and malware detections

detections, but from a review of the technical specification and contract terms, it is understood the malicious attacks blocked by the cloud provider will not be reported.

The Department should be alerted to suspicious activity or attacks against Department applications

The Department does not have an

extensive detection mechanism

The Department generally will not be

notified of any suspicious activity or attacks unless they are successful.

The Department generally will not be

notified of any suspicious activity or attacks unless they are successful.

Service Management & Monitoring:

The Department must be able to access management reports on service availability and performance, tracked against committed service level agreements

The Department currently can monitor

and report on system availability

The hosted cloud service provider

provides online access to service availability and performance information

The Department has reviewed the service

availability and performance reports that are available

Nominated system administrators in the Department should be alerted if any services become unavailable.

Currently, the Department is able to

set up alerts for emergency situations

Administrator alerts can be set up based

on configurable events

Administrator alerts can be set up based

on configurable events

Service reporting information should be integrated with the Department’s existing service management toolset

It is expected the on-premise solution

would be be integrated with the existing tools

It’s possible to have integrated

management systems but significant configuration is required

It’s possible to have integrated

management systems but significant configuration is required

Information Protection

Requirement 1: On Premise 2: Local Hosted Cloud 3: Public Cloud

Encryption

Data should be encrypted at rest if it is outside the corporate network

With an on-premise solution, the data is

being stored within the corporate network. However, the Department does not have a solution for the data being encrypted on remote or mobile devices

Email communications are

encrypted at rest, and all data in transit is encrpyted but other data may not be encrypted at rest

Email communications are

encrypted at rest, and all data in transit is encrpyted but other data may not be encrypted at rest

Wo

rked

Exa

mp

le

54

Requirement 1: On Premise 2: Local Hosted Cloud 3: Public Cloud

It is desirable for there to be a dedicated network connection or encrypted virtual private network between users inside the corporate network and the cloud service

The service would be inside the corporate

network

A dedicated virtual private network can be

configured with the local hosted cloud provider, or a dedicated network at additional cost

A virtual private network can be

configured with the cloud service provider

Users accessing the service from outside the corporate network should always have their communication encrypted using at least SSL3.0

SSL/TLS used for all connections

SSL/TLS used for all connections

SSL/TLS used for all connections

It should be possible to selectively encrypt documents or communications based on the sensitivity or classification of the data within them.

The Department can incoorporate

classification marking into the solution on-premise but it’s not feasible to incorporate policy-based encryption

The hosted cloud provider has a

solution for marking of documents/emails as well as policy based encryption as an additional (added cost) feature

The cloud provider has limited ability to

support classification markings but can apply encryption by policy out-of-the-box.

Threat Management

The Department requires all communications to be scanned for malware and spam prevention should be performed by the service provider

The Department can continue to use a

combination of in-house and external antimalware and spam prevention tools

The local hosting provider solution

includes anti-malware and anti-spam

The cloud service provider incorporates

antimalware / anti-spam into the cloud service

The service provider should be able to demonstrate intrusion detection and prevention capabilities within the cloud service.

The Department has limited in-house

intrusion detection and prevention capabilities

The hosted cloud provider has outlined

their capabilities in intrusion detection and prevention, but with limited detail available it is difficult to ascertain the depth of capability available.

The cloud service provider has outlined

their capabilities in intrusion detection and prevention, but with limited detail available

Data Loss Prevention

The Department should be able to block or hold communications being sent to or from the cloud service.

Data loss prevention is not considered

feasible in the current scope

The hosted cloud provider supports this

type of data loss prevention but it requires significant configuration

The cloud service provider incorporates

data loss prevention out-of-the-box

It should be possible to assign a classification to documents or other records using metadata

The proposed solution will have the capability

to assign metadata classifications

Metadata classifications can be

applied to data stored in the cloud service

Metadata classifications can be

applied to data stored in the cloud service

55

Figure 25: Examples of risk events in each domain

56

Step 4 – Assess Risk

Domain Based Risk Assessment

In earlier stages of the assurance assessment,

the organisation develops a clear

understanding of the business goals, context

and assurance objectives. Then the

methodology goes on to determine specific

security and compliance features and verify

the cloud service provider’s security claims.

But modern applications that involve cloud

services, mobile devices, social networks and

big data externalise significant aspects of the

solution. Parts of the solution can be

operated in-house, other parts are run by

contracted service providers and other parties

in the supply chain of each service can play a

role.

This externalisation can bring risks that are

strategic, operational, compliance or technical

in nature. Strategic risks can impact the

organisation’s ability to fulfil it’s long term

goals or even lead to the demise of the

organisation. Operational risks can disrupt or

strain the functioning of the organisation

making it less effective or less efficient.

Compliance risks expose the organisation to

potential consequences from failing to satisfy

legal or regulatory requirements. Finally,

technical risks limit the technology choices of

the organisation or prevent it from achieving

best value from technology implementations.

The ‘domain based’ aspect of this risk

assessment is important. In order to

streamline the risk assessment, an approach is

taken to identify only the most important risks

in each of the assurance areas of

trustworthiness, resilience and adaptability.

For each of these three areas, risk events that

have strategic, operational, technical or

compliance impacts are catalogued and

assessed. This handbook details

approximately 50 of the most commonly

assessed risks but the organisation may

choose to add additional risks or determine

that some are not relevant to their situation.

The set of risk events encompass many of the

risks outlined in guides like the Cloud Security

Alliance Top Risks, ENISA Cloud Computing

Risk Assessment, Australian Signals

Directorate Cloud Computing Considerations

and other documents. They are spread across

each of the domain and impact areas as

shown in the diagram to the left.

Figure 26: Spread of risk events

across each domain

57

Leveraging ISO 31000

The risk assessment approach proposed in

this step is a process consistent with ISO

31000 to:

Understand the context: Revisit the

internal and external context developed

at step 1 in this framework

Identify risks: Involve a variety of

perspectives and stakeholders to

catalogue the relevant risks

Analyse risks: Assess the organisations

tolerance for a specific risk and determine

it’s likely probability and impact

Treat risks: Determine if there are risks

that require specific treatment and

consider possible mitigations

Provide an overall risk assessment:

Summarise the risk of each solution

option considered

This consistency with ISO 31000 enables

better integration with the organisation’s

broader risk management framework and

practices. It also brings along the consistent

terminology of risk tolerance, likelihood,

impact and exposure.

Risk Likelihood

Likelihood is simply the probability of a risk

event occurring on a scale from rare to almost

certain. Although every organisation can

develop their own rating scheme, a

reasonable guideline is provided below.

Risk Impact

Impact is the outcome or consequence of a

specific risk event on a scale from minimal to

catastrophic. Again, each organisation may

define their own rating scheme, but a useful

guideline is provided below.

Risk Exposure

Risk Exposure, sometimes referred to as the

risk rating, is simply the product of risk

likelihood and impact. In this framework, it is

rated on an extended scale from very low

exposure to extreme risk exposure. For

example using the diagram below, an

organisation that assessed a risk event as

having an unlikely probability, but major

impact would be rate their risk exposure as

significant.

Likelihood Illustrative Criteria

Almost Certain

‘Happens often’ or

‘Could occur within days or weeks’

Likely ‘Could easily happen’ or

‘Could occur in weeks or months’

Possible ‘Could happen, maybe has before’

‘Could occur in a year or so’

Unlikely ‘Never yet happened but might’

‘Could occur in 10 years or so’

Rare ‘Maybe in extreme circumstances’, or

‘A 100 year event’

Impact Illustrative Criteria

Catastrophic ‘Extremely negative coverage’ or

‘Unable to satisfy critical objectives’

Major ‘Persistent negative coverage’ or

‘Unable to achieve a core objective’

Moderate ‘Negative coverage for a few days’

‘Significant inefficiencies and loss’

Minor ‘Minor, transient negative coverage’

‘Inefficiencies somewhat recoverable’

Minimal ‘Isolated, brief coverage’, or

‘Slight inefficiencies’

Figure 27: Ranking scheme for risk likelihood and impact

58

Risk Tolerance

Risk tolerance is the concept of what level of

risk is the organisation is willing to accept to a

specific risk event. It is graded on an

equivalent scale to risk exposure.

In simplistic terms, if an organisation’s

exposure to a risk is greater than their

tolerance of that risk, then the risk needs to

be mitigated. If the risk is assessed to be

lower than the tolerance, then it is an

acceptable risk. In reality, the situation is not

so simple as the urgency with which a risk

must be addressed or it’s significance may be

a factor. For example, an extreme exposure

risk event for which the business has a low

tolerance may need to be immediately

addressed or it may even rule out any

possibility of a particular solution. Another

risk event for which the organisation has a

significant exposure but only a medium

tolerance may require less urgent attention or

scrutiny.

Comparing Options & Treating Risks

The focus on externalisation that comes with

assessing risk of cloud services can also draw

attention to existing risks that the

organisation is facing with current on premise

systems. Alternative service delivery models

may bring new risks while reducing others, so

the risk assessment needs to not only cover

the options involving cloud services, but also

have comparison to on premise or other

options. Apart from developing the

comparative risk assessment, a key objective

here is to identify risk events for which the

risk exposure is greater than the risk

tolerance. In these cases, the organisation

may investigate possibilities to accept, avoid,

reduce or transfer the risk.

Risk reduction strategies may include

implementing additional security mitigations,

including for example, encryption, access

controls, third-party monitoring or requesting

additional contract terms. Risk avoidance

decisions might include avoiding the transfer

of highly sensitive data to the service. Risk

transfer may include taking on insurance.

Ultimately, reasonable risk treatment

strategies should be incorporated into the

final analysis.

Figure 28: Risk Tolerance

Figure 29: Risk Tolerance and Treatment

59

Risk Event Catalogue

Strategic Risk Events

Risk Event Type Domain

S-Co-01: Cloud service data breach: A data breach of the cloud service provider results in sufficient data loss to cause strategic impact to the customer organisation

Strategic Confidentiality (Trustworthiness)

Risk Description:

If a major data loss occurs either broadly within the Cloud Service Provider, or specifically the Customer application/data hosted in the cloud service, then strategic impacts could include loss of stakeholder confidence, loss of market confidence, brand reputation damage, competitive disadvantage or financial loss.

Risk Tolerance Questions: Risk Exposure Questions:

How critical is the service and data to the strategic value of the business?

What strategic impact would a major breach of data stored in the service have on the organisation?

What if the breach became publicly disclosed?

What are the organisations current strategic risk considerations around data breach of existing systems?

What specific assurances can the Cloud Service Provider provide in terms of information security, such as certifications, practices, etc?

What is the scale and level of expertise available to the cloud service provider?

What would the consequences of a breach be for the Cloud Service Provider?

What evidence is there that they heavily invest in securing their systems?

What is their track record in preventing or dealing with any security breaches they might have had in the past?

What compensation would the Cloud Service Provider be liable for in the event of a data breach?

How does the Cloud Service Provider limit their liability?

Risk Event Type Domain

S-Tr-01: Cloud service bankruptcy: The service provider becomes financially non-viable or even bankrupt leading to degradation or termination of the service

Strategic Transparency (Trustworthiness)

Risk Description:

The service provider becomes financially non-viable or even bankrupt leading to degradation or termination of the service

Risk Tolerance Questions: Risk Exposure Questions:

How critical is the application or service to the operation of the organisation?

What is the current financial viability of the service provider and the depth of their financial resources?

Are their services profitable?

What is their credit rating and financial track record?

Do they have a proven track-record of investing and developing their services?

How large is their operation and what impact would a failure of their finances have on the market?

What is their track record of acquisition or mergers?

Are there any escrow mechanisms in the contract that deal with failure of the service provider?

60

Risk Event Type Domain

S-Tr-02: Inappropriate use of customer data The cloud service provider claims to protect privacy but uses customer data inappropriately or in ways that are inconsistent with the expectations of the Customer organisation

Strategic Transparency (Trustworthiness)

Risk Description:

Cloud services providers operate platforms on which data and works are created by Customer organisations, but contract terms of use may specify joint or service provider ownership of data and developments. If the Customer data is high value, this could create a strategic risk for the Customer organisation (Ref: ENISA R24, ASD CC 20i)

Risk Tolerance Questions: Risk Exposure Questions:

Will the service contain high value intellectual property?

Will the services developed by the Customer in the cloud be of high commercial value?

What are the organisation's current practices and expectations around intellectual property development, protection and commercialisation?

Does this intellectual property belong to the Customer organisation or are third parties involved?

What will the cloud service provider contractually commit to in terms of intellectual property ownership over data and developments?

Do all ownership rights remain with the Customer or are some transferred to the Service Provider?

What is the perceived value of those rights in the future?

Are there any relevant third party intellectual property claims?

On termination of the service, will all intellectual property stored within the service be destroyed?

Risk Event Type Domain

S-Pd-01: Termination by Service Provider Termination of service by the Service Provider due to acquisition or market circumstances

Strategic Predictability (Trustworthiness)

Risk Description:

Market failure, competitive pressures, funding challenges, acquisition, strategic portfolio changes or other factors may lead to service provider terminating a service or making significant changes so that it no longer satisfies the needs of the customer. (Ref: ENISA R5, R6)

Risk Tolerance Questions: Risk Exposure Questions:

How critical are the services to the organisation?

How quickly could the organisation adapt or find an alternative service if the service was terminated?

What is the scale and reputation of the service provider?

How established is the market for the service?

Are there competing standards or approaches that may not coexist well in the future?

Is the service expanding and being invested in?

What is the service providers track record around terminating services?

61

Risk Event Type Domain

S-Av-01: Extended period of service disruption The service fails and is unable to be restored to operation in a reasonable time causing strategic damage such as significant lost revenue, lost customers and brand damage

Strategic Availability (Resilience)

Risk Description:

If the service fails or is disrupted for a significant duration, the organisation may face strategic, long-term impacts that are likely to exceed caps on liability or other damages from the service provider.

Risk Tolerance Questions: Risk Exposure Questions:

How critical is the service to the continued operation of the business?

What impact would it have for the organisation if the service became unable for a prolonged period?

What are the business continuity and disaster recovery practices of the service provider?

What visibility can the Customer organisation have into these processes?

Will the Customer organisation maintain a separate backup or archive either on premise or within another Cloud Service Provider?

What options might be possible to return to operation with another service provider or on premise infrastructure if the cloud service provider could not return to operation?

Risk Event Type Domain

S-Fl-01: Service inflexibility to adapt to new needs Security or other requirements of the Customer organisation change, but the Cloud Service is inflexible to accommodate these changes

Strategic Flexibility (Adaptability)

Risk Description:

Changing external factors (such as new threats or opportunities) or internal factors (such as expansion, new ways of working, structure, etc) may emerge requiring the Service to be adapted. Some applications can be highly configurable initially, but inflexible to adapt. Such inflexibility may result in restrictions on the business or inability to effectively respond to changing circumstances

Risk Tolerance Questions: Risk Exposure Questions:

How dynamic is the organisation?

Does it typically need to respond rapidly to changing external or internal circumstances?

How will changes or reconfiguration of the cloud service be handled?

What is the cloud service provider’s track record around innovating and developing the service to deal with changing external factors, such as threats, authentication & access control options, etc?

Do changes or reconfiguration typically require downtime?

62

Risk Event Type Domain

S-Po-01: Non-portability of data on termination The service is terminated by either party, but the Customer is unable to extract the data in a way that can be ported to another service

Strategic Portability (Adaptability)

Risk Description:

The customer organisation decides to migrate to a different cloud application or service but is unable to readily extract the data in a format that is usable within the new service. Effectively they are locked-in to using the chosen application or service, not contractually but because the data itself is not portable. (Ref: ENISA R1, ASD CC 19m)

Risk Tolerance Questions: Risk Exposure Questions:

How likely is it that the organisation will switch to a different service?

If it occurred, how rapidly will that switch need to take place?

Are there multiple service providers in the market offering equivalent services?

Are there application interfaces and tools available for export and import of data?

Does the data export need to be performed by the service provider, the customer or a third party?

To what extent are open standards used for data structures?

Risk Event Type Domain

S-Cf-01: Unable to initially configure to fit The application or service cannot be configured initially to satisfy the business requirements of the Customer organisation

Strategic Configurability (Adaptability)

Risk Description:

Because cloud services work on the basis of configuring a common service, rather than customising to specific needs of a Customer, issues may emerge where either the service cannot be configured to requirement or the expense of configuring to requirement is too great.

Risk Tolerance Questions: Risk Exposure Questions:

How complex are the organisations requirements?

How well understood are they?

How adaptable is the organisation in changing business processes rather than the technology systems?

How configurable is the cloud service assessed to be?

Are there similar customers with equivalent scale, complexity, market and location already using the cloud service?

What is the Cloud Service Provider's track record of implementation?

63

Operational Risk Events

Risk Event Type Domain

O-Ex-01: Damage due to co-tenant activities Service disruption or loss of reputation due to co-tenant activities

Operational Exploitability (Trustworthiness)

Risk Description:

Resource sharing in the cloud service can mean that the activities of another tenant may affect the reputation of the customer organisation, for example due to spamming, fraud or serving of malicious content. Actions to mitigate or stop the malicious tenant activity may impact on the customer organisation.

Risk Tolerance Questions: Risk Exposure Questions:

How critical are the services to continuity of business operations?

What impact would it have if the organisation IP address range was shunned?

What is the scale and reputation of the service provider?

What are the policies and practices of the service provider for dealing with malicious tenants?

How does the service provider mitigate fraud or malicious hijacking of cloud services?

What activities are allowed / disallowed by the service provider – for example: do they allow vulnerability scanning or bulk emailing from their cloud service?

Are there any technical or operational mechanisms in place to prevent the activities of one tenant from impacting the reputation or service of another?

Risk Event Type Domain

O-Co-01: Malicious insider steals data Malicious insider within the cloud provider abusing high privilege access to customer data

Operational Confidentiality (Trustworthiness)

Risk Description:

Failure in internal cloud provider practices, ineffective screening, fraudulent intent or other motivation causing an internal administrator or other insider within the service provider to access and steal customer data. (Ref: ENISA R10, ASD 22b)

Risk Tolerance Questions: Risk Exposure Questions:

How sensitive is the data stored within the application?

Is there any sensitive or high value intellectual property stored within the service?

What would the impact be of a theft of customer data and disclosure publicly or to a competitor?

What practices does the cloud provider implement around employee screening and background checks?

How are these processes maintained during employment?

Are service provider employees security cleared, for example through a government security vetting program?

Do administrators have standing privileges to access customer data, or do those privileges need to be requested, authorised and then removed when no longer required?

What technical controls are in place to mitigate the risk of the abuse of high privilege roles?

Do third party suppliers have access to customer data or occupy high privilege roles?

What controls are in place to monitor third party supplier activities around use of higher privileges?

Are all activities of administrators logged, monitored and periodically audited?

64

Risk Event Type Domain

O-Av-01: Network disruption: The network between the cloud service provider and the Customer organisation endpoint is disrupted

Operational Availability (Resilience)

Risk Description:

With most cloud services relying on the internet for connectivity to customer endpoints, a broad or localised failure in network connectivity can temporarily disrupt the operations of the organisation. (Ref: ENISA R25)

Risk Tolerance Questions: Risk Exposure Questions:

How critical is the service to the continued operation of the business?

What would the impact be of a 1 hour disruption to operations? What about 1 day?

Is the service designed to be tolerant of temporary network failures, using mechanisms like caching, alternative network routes, client side processing, etc?

Does all network traffic need to pass through a common network gateway or are there multiple alternative network routes possible?

Are there multiple network routes between the data centre and the location where the customer is operating?

Can a user with the Customer organisation access the service even if the corporate network connectivity is offline, possibly using a public internet connection?

What service-level-agreements exist relating to the network interconnection between the cloud data center and the Customer organisation?

Risk Event Type Domain

O-Lt-01: Required capacity unavailable Service provider is unable to provide additional capacity on demand to meet customer need

Operational Load Tolerance (Resilience)

Risk Description:

Resource constraints in network, storage, processing or other areas may reduce the ability of the cloud service provider to provide the capacity requested by the customer. (Ref: ENISA R8, ASD CC 19l)

Risk Tolerance Questions: Risk Exposure Questions:

How variable is the resource load for the application being considered?

Is consumption of resources expected to peak far beyond normal levels under any particular circumstances?

In those circumstances, what would be the impact of disruption or performance degradation?

What is the scale of operations of the service provider?

Is the option being assessed involve on-premise or private cloud infrastructure where new hardware or resources would need to be acquired and commissioned?

Does the option utilise public cloud which typically has a much greater capacity to be provisioned on demand?

How long would it take to double the resource provisions of the service? How long to expand by a factor of 10?

Does the service provider have a track record of supporting applications at the scale required by the customer organisation?

65

Risk Event Type Domain

O-Lt-02: Network congestion: The network between the cloud service provider and the Customer organisation endpoint is congested or exhibits highly variable quality of service

Operational Load Tolerance (Resilience)

Risk Description:

With most cloud services relying on the internet for connectivity to customer endpoints, network congestion or poor quality of service can significantly impact productivity or end user experience within the Customer organisation. (Ref: ENISA R26)

Risk Tolerance Questions: Risk Exposure Questions:

How critical is the service to the continued operation of the business?

What impact would variable performance have on end user productivity?

Is the service designed to be tolerant of temporary network congestion, using mechanisms like caching, client side processing, etc?

What is the typical latency, congestion and packet loss characteristics of the network link between the Customer and data center locations?

Are there bottlenecks in the network topology that could cause congestion, such as a Customer Organisation-owned network gateway?

Are these gateways adequately specified for the transition of processing to an external cloud service?

What service-level-agreements exist relating to the network interconnection between the cloud data center and the Customer organisation?

Risk Event Type Domain

O-Tr-01: Confused security responsibilities Lack of clarity in security operational responsibilities leads to confusion and gaps in process that may ultimately lead to data loss.

Operational Transparency (Trustworthiness)

Risk Description:

Cloud service providers take on some, but not all of the security responsibilities for the application and the demarcation of responsibilities differs between across different service providers and types of cloud services. This can lead to gaps in process and accountability that may result in security events. (Ref: ENISA R20)

Risk Tolerance Questions: Risk Exposure Questions:

To what extent are the organisations current security practices consistent and standardised across the organisation?

How does the organisation currently deal with suppliers who may have different security practices and policies?

How well understood are the relative security responsibilities of the customer and the cloud service provider?

Are these responsibilities clearly documented and agreed?

How would a mismatch in expectations be resolved?

How experienced is the customer organisation in establishing outsourcing or external service provider arrangements?

66

Risk Event Type Domain

O-Ex-02: Unauthorised physical access: Access by an external attacker to premises, data or systems

Operational Exploitability (Trustworthiness)

Risk Description:

Unauthorised physical access by an attacker to machines, data or networking of the cloud provider could compromise Customer data leading to data loss, data integrity issues or disruption (Ref: ENISA R33, ASD CC 22d)

Risk Tolerance Questions: Risk Exposure Questions:

Tolerance questions: How sensitive is the data stored within the service?

What physical security controls exist within cloud service provider data centres, such as fencing, isolation, monitoring, guards, access controls, etc?

What certifications/attestations does the cloud service provider have relating to physical security?

What physical protections exist on the network infrastructure between data centres?

What physical cabling standards are enforced to help prevent accidental or deliberate incorrect cabelling?

Are third party facilities used by the cloud service provider, and if so, do the same level of physical protections apply to those?

How is data and equipment physically secured when outside of the data centre, for example during large data uploads / transfers or decommissioning of equipment?

What restrictions does the Cloud Service Provider place on third party visitation or external auditing?

Risk Event Type Domain

O-Co-02: Lawful confiscation of equipment Due to the shared resource nature of cloud services, if a lawful subpoena on another tenant leads to physical confiscation of hardware, then data of the customer organisation might also be disclosed

Operational Confidentiality (Trustworthiness)

Risk Description:

This is the scenario whereby if multiple tenants are on shared hardware and law enforcement require that hardware for evidentiary purposes in an investigation of one tenant, then the data of uninvolved tenants might also be confiscated and potentially be disclosed. (Ref: ENISA R21)

Risk Tolerance Questions: Risk Exposure Questions:

How sensitive is the information being stored in the cloud service?

What is the cloud service provider’s formal process for dealing with lawful requests?

Will they minimise the data or assets provided to law enforcement in a manner that excludes data of unrelated third parties?

Is the cloud service a public cloud (lower risk in this circumstance) or a private cloud (higher risk in this circumstance)?

Can dedicated resources be assigned to the customer?

In what jurisdictions are the resources located, and within those jurisdictions, how normalised are practices around lawful requests?

67

Risk Event Type Domain

O-In-01: Damage to logs Loss or compromise of operational or security logs

Operational Integrity (Trustworthiness)

Risk Description:

In the event of a security investigation or a legal request for information, complete logs are essential. If there is any tampering, if they are incomplete or if the cover an insufficient period of time, then the investigation could be hindered.

Risk Tolerance Questions: Risk Exposure Questions:

What is the sensitivity/classification of the data stored in the service?

How does the Cloud Service Provider implement backup and recovery?

What technical and process controls are put in place by the Cloud Service Provider to prevent compromise of the backup system or loss of backup media?

What is the retention schedule for backup media and how are they wiped at their end of life?

Risk Event Type Domain

O-Co-03: Accidental loss or theft of backups Backup media being lost

Operational Confidentiality (Trustworthiness)

Risk Description:

Because backups may contain all the data of the application, a compromised backup system or loss of backup media could lead to a large loss of Customer data

Risk Tolerance Questions: Risk Exposure Questions:

What is the sensitivity/classification of the data stored in the service?

How does the Cloud Service Provider implement backup and recovery?

What technical and process controls are put in place by the Cloud Service Provider to prevent compromise of the backup system or loss of backup media?

What is the retention schedule for backup media and how are they wiped at their end of life?

68

Risk Event Type Domain

O-Re-01: Disruption due to natural disaster A natural disaster such as an earthquake, fire, flood or extreme weather event disrupts the operations of the service

Operational Responsiveness (Resilience)

Risk Description:

If the cloud service provider or on-premise infrastructure is not able to rapidly respond to a natural disaster event and restore normal operations, then the Customer organisation may suffer downtime. (Ref: ENISA R35)

Risk Tolerance Questions: Risk Exposure Questions:

How sensitive is the data stored within the service?

What are the organisations current expectations and practices around disaster recovery and business continuity?

What is the likelihood of extreme weather events, earthquakes, fire, flood and other natural disasters in the region where the cloud service provider data centers are located?

What technical measures are in place to deal with disaster events, such as backup, geo-replication of data, redundant resources, alternative network routes, etc?

What is the scale and sophistication of the cloud service providers approach to business continuity and disaster recovery?

What is the cloud service provider's track record in handling disaster and outage events?

What assurance can the cloud service provider give that disaster recovery practices are effective?

Has the disaster recovery process been tested?

Risk Event Type Domain

O-Av-02: Downtime during business hours The cloud service is unavailable during periods of business operation

Operational Availability (Resilience)

Risk Description:

Lack of availability of the cloud service during business operations times may have a significant impact if prolonged or frequent. With regard to scheduled outages if required, the Customer organisation typically has less control over timing but may at least be notified in advance. (Ref: ASD 19f, 19g, 19h).

Risk Tolerance Questions: Risk Exposure Questions:

Tolerance questions: How critical is the service to the continued operation of the business?

What would the impact be of a 1 hour disruption to operations? What about 1 day?

What is the service level agreement guarantee provided by the cloud service provider?

What high availability measures are implemented by the Cloud Service Provider, such as clustering, replication, redundancy, etc?

How will the Customer organisation be compensated by the Service Provider if the service is unavailable beyond the SLA guaranteed time?

What limitations exist on the level of compensation provided by the service provider?

How is availability reported to the Customer?

What is the track record over the past year on service availability?

If there are scheduled outage time windows, how do they relate to the business day where the Customer is located?

69

Risk Event Type Domain

O-Lt-03: Variable performance under load The cloud service exhibits varying performance during periods of business operation due to resource contention within the cloud service

Operational Load Tolerance (Resilience)

Risk Description:

Lack of availability of the cloud service during business operations times may have a significant impact if prolonged or frequent. With regard to scheduled outages if required, the Customer organisation typically has less control over timing but may at least be notified in advance. (Ref: ASD 19f)

Risk Tolerance Questions: Risk Exposure Questions:

Tolerance questions: How critical is the service to the continued operation of the business?

What would the impact be of a 1 hour disruption to operations? What about 1 day?

What is the service level agreement guarantee provided by the cloud service provider?

What high availability measures are implemented by the Cloud Service Provider, such as clustering, replication, redundancy, etc?

How will the Customer organisation be compensated by the Service Provider if the service is unavailable beyond the SLA guaranteed time?

What limitations exist on the level of compensation provided by the service provider?

How is availability reported to the Customer?

What is the track record over the past year on service availability?

If there are scheduled outage time windows, how do they relate to the business day where the Customer is located?

Risk Event Type Domain

O-Cf-01: Lack of skilled resources Skilled resources are not available to configure or maintain the solution appropriate to the needs of the organisation

Operational Configurability (Adaptability)

Risk Description:

As with all information technology projects, the availability of skilled resources may present a risk. Although cloud services make it possible to draw on a wider pool of resources or offload work to a cloud service provider, skilled resource challenges may still exist.

Risk Tolerance Questions: Risk Exposure Questions:

How does the organisation currently deal with skills challenges?

Does the organisation have the budget and resources for skills development or recruitment?

Are skills from configuring and supporting existing applications transferrable to the new solution?

How prevalent are skills in the market for the technologies within the solution?

Does the cloud service provider have training, certification or skills readiness program?

Does the cloud service provider have consulting or engineering support staff locally?

70

Compliance Risk Events

Risk Event Type Domain

C-Co-01: Lawful warrant compelling disclosure Lawful warrant or subpoena process directed to the cloud service provider compelling the disclosure of customer data

Compliance Confidentiality (Trustworthiness)

Risk Description:

This is the scenario where a law enforcement or intelligence agency in the same jurisdiction as the Customer organisation, in the jurisdiction of the Cloud Service Provider data centre, or any other jurisdiction that applies extra-territorial powers makes a request of the Cloud Service Provider specifically for Customer data to be disclosed. As the cloud service provider would need to operate within the law of that jurisdiction, if it is a legally valid production order, Customer data could be disclosed. (Ref: ASD CC 20d)

Risk Tolerance Questions: Risk Exposure Questions:

What is the sensitivity / classification of the data being processed in the service?

What would the impact be of disclosing that data to a foreign law enforcement or intelligence service?

In what jurisdiction are the cloud service providers data centres? Where else could data flow?

How well regarded are the privacy protections and law enforcement/intelligence oversight processes in those jurisdictions?

What is the cloud service provider’s process for dealing with lawful requests for data?

What is their track record in complying with lawful requests for customer data?

Will the cloud service provider seek to direct requests to the Customer organisation if possible, rather than directly disclose information?

Can the customer restrict the allowable data location to specific jurisdictions?

Will the Customer organisation be notified if the jurisdictions in which data processing occurs changes?

Risk Event Type Domain

C-Co-02: Leakage of sensitive data into cloud Leakage of more sensitive data into the cloud service than it is designed/assured to contain

Compliance Confidentiality (Trustworthiness)

Risk Description:

This could be the scenario where although the cloud service is chosen and considered adequate to contain low or moderate business impact classified data, through user error, ineffective customer controls or usage creep, high business impact data is placed on the cloud. The most immediate impact may be that the organisation is unable to satisfy it's compliance obligations. (Ref: ASD CC 19i)

Risk Tolerance Questions: Risk Exposure Questions:

What is the sensitivity / classification of the data to be processed or stored in the service?

How does the organisation currently treat different classifications of data?

Are there different security assurance or compliance requirements depending on the classification of data?

How will the organisation segment or control data to ensure only appropriately classified data is processed in the cloud service?

Does the cloud service provider or the Customer organisation implement any technical controls for data classification or handling or data loss prevention?

In the event of a data spill (ie. higher classification data going to the cloud than is permitted), how would the customer detect the spill and what process would exist with the Cloud Service Provider to recover from and remove the spilled data?

71

Risk Event Type Domain

C-Tr-01: 3rd party supplier compliance issues Inadequate practices of a third party supplier to the service provider lead to customer organisation non-compliance

Compliance Transparency (Trustworthiness)

Risk Description:

The service provider engages a third party who doesn't adhere to equivalent policies or practices as the service provider, resulting in a significant compliance issue for the customer organisation. (Ref: ENISA R2, R7)

Risk Tolerance Questions: Risk Exposure Questions:

How highly regulated is the customer organisation?

Are there specific compliance areas relevant that are especially sensitive to third party or supply chain considerations, such as privacy?

How consistently are baseline practices currently monitored across suppliers?

Does the service provider engage third parties?

For what purposes are subcontractors engaged?

Does data transfer occur to subcontractors?

What level of data access would they have?

How assured are you that subcontracting agreements reflect terms in the customer contract?

Do you know who the subcontractors are and where they're located?

Will the service provider notify you of changing subcontractor arrangements?

Risk Event Type Domain

C-Tr-02: Failure to maintain adequate controls The service provider fails to maintain the security controls necessary for the customer organisation to satisfy required compliance obligations

Compliance Transparency (Trustworthiness)

Risk Description:

The customer adopts the cloud service with an understanding of certain controls in place that enable it to meet it's compliance obligations. However, the service provider either doesn't implement these controls or fails to maintain them adequately, leading to the customer becoming non-compliant. (Ref: ENISA R2, ASD CC 20c)

Risk Tolerance Questions: Risk Exposure Questions:

How highly regulated is the customer organisation?

Are there specific compliance areas relevant that are especially sensitive to third party or supply chain considerations, such as privacy?

Are there periodic or ad-hoc external audits of the customer security practices?

Does the service provider hold current SSAE16 SOC 2 reports that have been reviewed by the customer organisation?

Are there any relevant exceptions or limitations in those audit reports?

Is the scope of the audit reports appropriate for the solution being considered?

What are the service provider’s commitments around periodic audit and reporting?

What other certifications / audits does the service provider hold (eg. PCI DSS, ISO27001, etc)?

To what extent are the security controls described by the service provider explicitly articulated in formal service descriptions and contracts?

Will the customer be notified if a periodic external audit of the service provider identifies exceptions?

Does the customer have the ability to perform an audit / inspection?

72

Risk Event Type Domain

C-Pr-01: Insider accesses private data Malicious insider within the cloud provider abusing high privilege access to privacy-related customer data

Compliance Privacy (Trustworthiness)

Risk Description:

Specifically in relation to privacy-related data, such as personally-identifiable-information, financial information, credit history, health and social welfare information, a malicious insider could access and steal this data resulting a significant compliance issue for the customer organisation (ENISA R10, ASD CC 22b)

Risk Tolerance Questions: Risk Exposure Questions:

Is privacy-related customer data stored within the application?

Is this privacy-related data highly sensitive, such as financial details, health and social security data, etc?

What would the impact be of a theft of privacy related customer data and disclosure?

Is there a regulatory obligation for mandatory disclosure of privacy-related data loss?

What practices does the cloud provider implement around employee screening and background checks?

How are these processes maintained during employment?

What privacy training does the service provider organisation deliver internally?

Under what circumstances would a cloud provider administrator or other role be able to read privacy-related customer data?

Do any staff in the service provider have standing privileges to access privacy-related customer data, or do those privileges need to be requested, authorised and then removed when no longer required?

What technical controls are in place to mitigate the risk of the abuse of high privilege roles, specifically to access privacy-related data?

How are the privacy controls and expectations enforced across third party suppliers to the cloud service provider?

Is access to privacy-related customer data within the service provider organisation logged, monitored and periodically audited?

Risk Event Type Domain

C-Pd-01: Change in cloud provider practices: The service provider changes business practices or service functionality in a manner that no longer enables the organisation to meet compliance obligations

Compliance Predictability (Trustworthiness)

Risk Description:

Cloud services rapidly evolve but if the service provider makes significant changes, like for example changing their privacy policy to permit secondary use of data or terminating certain protections, then the organisation may no longer be able to satisfy compliance obligations.

Risk Tolerance Questions: Risk Exposure Questions:

Is the organisation operating in a highly regulated sector or have extensive regulatory requirements?

How dynamic is the organisation and capable of moving to a different service if necessary?

What is the service provider's track record in being predictable about the types of services being offered?

Have they significantly changed privacy or security policies in unpredictable ways?

What commitments can they provide contractually around maintaining certifications and minimum security & privacy protections?

73

Risk Event Type Domain

C-Pr-02: Inadequate privacy legal protections Cloud service provider may operate in a jurisdiction that provides inconsistent legal protections for privacy

Compliance Privacy (Trustworthiness)

Risk Description:

Cloud services operate on a global scale and in each jurisdiction must comply with local laws. The risk is that legal privacy protections or law enforcement powers are inconsistent with the customer organisation's jurisdiction to such an extent that the customer cannot be sure they are at all times satisfy their privacy protection obligations. (Ref: ENISA R22, ASD CC 19d)

Risk Tolerance Questions: Risk Exposure Questions:

Is private information or sensitive private information to be stored within the service? What are the organisation’s current compliance obligations in respect to privacy?

In what jurisdiction are the cloud service provider’s data centres? Where else could data flow?

How well regarded are the privacy protections and law enforcement/intelligence oversight processes in those jurisdictions?

What is the cloud service provider’s process for dealing with lawful requests for data?

What is their track record in complying with lawful requests for customer data?

What is contractually specified for data location in the service provider agreement?

Can the customer restrict the allowable data location to specific jurisdictions?

Will the Customer organisation be notified if the jurisdictions in which data processing occurs changes?

Risk Event Type Domain

C-In-01: Unable to respond to legal discovery Cloud service provider is unable to provide information required by the Customer Organisation to respond to a subpoena or warrant

Compliance Integrity (Trustworthiness)

Risk Description:

This is the scenario where a customer has to provide information in a legal matter or investigation, but due to limitations in the application, the Cloud Service Provider is unable to provide the required information in a timely manner.

Risk Tolerance Questions: Risk Exposure Questions:

What circumstances may lead to the customer needing to respond to a warrant or other legal request?

Is there information stored in the application that is considered likely to be subject to such a request?

What information can be provided by the Cloud Service Provider in the event of a legal request?

Does the service support legal hold, discovery or retention?

Will the Customer Organisation implement archiving on premise or with another cloud service provider?

74

Risk Event Type Domain

C-Pr-03: Cloud practices inadequate for privacy The cloud service provider claims to protect privacy but uses customer data inappropriately or in ways that are inconsistent with the expectations of the Customer organisation

Compliance Privacy (Trustworthiness)

Risk Description:

Cloud service providers potentially have access to large amounts of customer data that could be used in data mining, ad targeting, marketing or other purposes. The Customer organisation may not know this is occurring but if the private data of their clients is mined in this way, they may face a significant privacy compliance problem.

Risk Tolerance Questions: Risk Exposure Questions:

Will the service contain privacy related data, especially sensitive private data?

What obligations exist for the organisation to protect the privacy of their clients when engaging a third party for data processing?

What will the cloud service provider contractually commit in terms of use and explicit non-use of customer provided data (ie. commitment not to use Customer data for data mining, ad targeting, etc)?

Will the cloud provider commit to standard data-processing terms, such as the EU Model Contracts?

What formal certifications or assurances can the cloud service provider assert?

What is the reputation and scale of the cloud service provider?

Is private data encrypted or otherwise protected within the cloud service?

Risk Event Type Domain

C-Pp-01: Insufficient disaster preparedness Service provider business continuity preparedness is insufficient to satisfy regulatory requirements

Compliance Preparedness (Resilience)

Risk Description:

It is a common requirement of regulators or government that organisations have adequate preparedness for continued operations in the event of a disruption. If the cloud service provider can't demonstrate the continued adequacy of their preparedness, then the customer may face a compliance issue.

Risk Tolerance Questions: Risk Exposure Questions:

How critical is the service to the continued operation of the business?

What impact would it have for the organisation if a single user's data could not be restored when needed? What about for all data?

What are the business continuity and disaster recovery practices of the cloud service provider?

What visibility can the Customer organisation have into these processes?

Are they fully documented and are staff fully trained?

How frequently are these processes tested?

What audit reports are available from the service provider to demonstrate their preparedness?

How frequently will these audits be repeated?

75

Risk Event Type Domain

C-Fl-01: Unable to meet new compliance needs New compliance requirements emerge that cannot be satisfied by the functionality within the cloud service

Compliance Flexibility (Adaptability)

Risk Description:

New legislation, regulations, codes of conduct, supplier agreements and policies may emerge in the future that create new compliance requirements for the organisation. Alternatively, the Customer organisation may expand into new markets that impose compliance obligations. If the cloud service provider or the cloud service itself is unable to adapt to satisfy these new requirements, then the Customer may face a compliance problem or be limited from entering markets.

Risk Tolerance Questions: Risk Exposure Questions:

How sensitive is the data stored within the service?

What are the organisations current expectations and practices around disaster recovery and business continuity?

What is the likelihood of extreme weather events, earthquakes, fire, flood and other natural disasters in the region where the cloud service provider data centers are located?

What technical measures are in place to deal with disaster events, such as backup, geo-replication of data, redundant resources, alternative network routes, etc?

What is the scale and sophistication of the cloud service providers approach to business continuity and disaster recovery?

What is the cloud service provider's track record in handling disaster and outage events?

What assurance can the cloud service provider give that disaster recovery practices are effective?

Has the disaster recovery process been tested?

Risk Event Type Domain

C-Po-01: Contractual restriction on portability The customer is contractually limited from terminating the service and withdrawing their data or configuration for use in another service.

Compliance Portability (Adaptability)

Risk Description:

The customer decides to migrate to a different cloud application or service, but a contractual or legal restriction exists that prevents the extraction of data necessary to move to the new service. (Ref: ENISA R1, ASD CC 19l, 19m)

Risk Tolerance Questions: Risk Exposure Questions:

How likely is it that the organisation will switch to a different service?

If likely, how rapidly will that switch need to take place?

Are there terms in the contract that enable the service provider to assert ownership in any way over customer data?

Are there specific contract terms or termination provisions that would prevent the extraction of data?

76

Technical Risk Events

Risk Event Type Domain

T-Ex-01: Isolation failure between tenants Isolation failure enabling one tenant in the cloud service to exploit resources of another tenant

Technical Exploitability (Trustworthiness)

Risk Description:

Cloud services have multiple isolation mechanisms to separate storage, networking, memory and other resources of each tenant from one another. A failure in any of these isolation mechanisms may enable an attack leading to data loss or disruption. (Ref: ENISA R9, R19, ASD CC 21a)

Risk Tolerance Questions: Risk Exposure Questions:

How sensitive is the data stored within the application?

What would the impact be of a disruption to the service?

What is the track record of the cloud provider in implementing effective security practices?

Can they provide assurance around their secure development lifecycle approach?

What technical controls are in place to isolate storage, networking and memory?

How would the service provider detect and respond to an exploitation event?

What is the service providers approach for mitigating possible vulnerabilities in hypervisors?

How consistent and effective are the configuration, patch management and other infrastructure management capabilities of the service provider?

Are parts of the solution dedicated hardware or shared?

Are there any restrictions on which kinds of tenants can operate services within the cloud - for example a government community cloud?

Risk Event Type Domain

T-Co-02: Data visible on reallocated resources: Ineffective wiping of data resulting in possible data recovery by another tenant in the cloud service

Technical Confidentiality (Trustworthiness)

Risk Description:

If resources are scaled back, the customer terminates the service or for any other reason, resources are returned to a pool of available resources, there is a risk that data could still be held on the drive and visible to a subsequent tenant. This could lead to loss of customer data if a malicious third party attempted to recover inadequately wiped data. (Ref: ENISA R14, ASD CC20f, 21d)

Risk Tolerance Questions: Risk Exposure Questions:

How sensitive is the application/data to the organisation?

Does the cloud provider implement standard data wiping practices (such as NIST 800-88) to ensure that resources returned to a pool are appropriately wiped?

Is data encrypted-at-rest on drives?

77

Risk Event Type Domain

T-Co-01: Interception in-transit to customer Interception of data in-transit between customer endpoint and service provider

Technical Confidentiality (Trustworthiness)

Risk Description:

If data protection controls between the customer endpoint and the interface at the service provider are compromised, then data could be intercepted by a malicious third party.

Risk Tolerance Questions: Risk Exposure Questions:

How sensitive is the application/data to the organisation?

Are significant amounts of sensitive data transmitted between the customer endpoint and the service provider?

What encryption or other data protection measures are used to protect data in transit to/from the service provider? Specifically, is SSL/TLS or Virtual Private Networking used?

If on premise-servers are replicating or exchanging significant amounts of data with cloud servers, how is the data protected in transit?

Is information encrypted at the application or data level in addition to encryption at the transport level?

Are any counter-interception mechanisms used such as Perfect-Forward-Secrecy?

Is the cloud service provider able to provide assurance around how the service is protected against spoofing, replay, man-in-the-middle, sniffing and other attacks?

If large volumes of data are transferred out-of-band (such as mailing of hard drives for big data uploads), how are these transfers secured?

Can additional protections be implemented selectively for highly sensitive data, such as digital rights management?

What encryption protocols, algorithms and key lengths are used and are these consistent with requirements for information assurance compliance?

78

Risk Event Type Domain

T-Co-03: Interception between data centres Interception of customer data in-transit between service provider data centres

Technical Confidentiality (Trustworthiness)

Risk Description:

Replication and transmission of customer data between cloud service provider data centres is commonly performed to ensure high availability and disaster recovery. If data protection controls between one data centre and another are compromised, then data could be intercepted by a malicious third party. (Ref: ENISA R12,R13, ASD CC 20d)

Risk Tolerance Questions: Risk Exposure Questions:

How sensitive is the application/data to the organisation?

What encryption or other data protection measures are used to protect data in transit between service provider data centres?

Are these protections applied at the application level or on all network traffic?

Do the network connections cross international boundaries?

Can the customer specify that data transfer is restricted to certain regions or data centres?

Is data encrypted and unreadable even to the cloud service provider?

If the data is encrypted in transit between data centres, what are the key management practices of the cloud service provider?

What encryption protocols, algorithms and key lengths are used and are these consistent with requirements for information assurance compliance?

Risk Event Type Domain

T-Co-04: Interception due to loss of encryption Loss of encryption keys or weak encryption practices leading to interception or theft of data:

Technical Confidentiality (Trustworthiness)

Risk Description:

Encryption controls are only effective if keys are securely protected but a failure in key management practices could lead to loss of keys or weakening of encryption mechanisms (Ref: ENISA R17, ASD CC 22a)

Risk Tolerance Questions: Risk Exposure Questions:

How sensitive is the application/data to the organisation?

Are significant amounts of sensitive data transmitted between the customer endpoint and the service provider?

What are the key management practices of the cloud service provider?

If keys are retained by the customer to enable encryption/decryption on premise, how are these keys secured?

Are protocols like Perfect-Forward-Secrecy implemented to protect intercepted data even if keys are lost in the future?

What protocols, algorithms and key sizes are used for encryption at-rest and in-transit?

Which protocols are not permitted within the cloud service provider (eg, MD-5 for hashing)?

Are there circumstances by which a cloud provider would need to provide keys to law enforcement or other third parties?

79

Risk Event Type Domain

T-In-01: Backup failure The cloud service fails to create adequate backups or backed-up data cannot be restored when required

Technical Integrity (Trustworthiness)

Risk Description:

Backup data may be required to recover from a user error, system failure, security incident or legal investigation. If this data is not recoverable or only partially recoverable when needed, it may result in a data integrity problem for the Customer organisation. (Ref: ASD 19b,19c, 19j, 19k)

Risk Tolerance Questions: Risk Exposure Questions:

How critical is the service to the continued operation of the business?

What impact would it have for the organisation if a single user's data could not be restored when needed? What about for all data?

What are the backup and recovery practices of the cloud service provider?

What visibility can the Customer organisation have into these backup and recovery processes?

For how long are backups retained?

What would the process be for requesting the recovery of data from backups, in particular would it be performed by the Cloud Service Provider or customer administrators?

How long would it be expected to take?

How frequently and comprehensively are these backup and recovery processes tested?

Will the Customer organisation maintain a separate backup or archive either on-premise or within another Cloud Service Provider?

Risk Event Type Domain

T-Ex-02: Exploitation of customer gateway The communications gateway between the cloud service provider and the Customer organisation is exploited

Technical Exploitability (Trustworthiness)

Risk Description:

A cloud service solution may implement a gateway architecture, whereby there is some form of network protection and monitoring infrastructure at either the cloud provider boundary or the Customer organisation boundary. Compromise of either end of the gateway may lead to potential interception, traffic manipulation, disruption or creation of vulnerabilities that enable further exploitation. (Ref: ASD CC 19j, 19k)

Risk Tolerance Questions: Risk Exposure Questions:

Does the solution architecture incorporate a gateway implementation?

If the Customer organisation currently uses a gateway, how effective are the organisation's current mechanisms to protect the gateway itself from compromise?

Are there any specific certifications or compliance obligations existing for the organisation around the security of the gateway?

What technical controls are applied by the Cloud Service Provider in the gateway?

Specifically, do these controls include firewalls, content filters, antimalware scanners, intrusion detection, etc?

Are the gateway technologies accredited against relevant government or other security requirements?

Is it possible to establish a secure virtual private network with the Cloud Services Provider?

If so, how is that VPN secured, configured and monitored?

80

Risk Event Type Domain

T-Ex-03: Isolation failure on cloud fabric Isolation failure enabling one tenant in the cloud service to exploit resources of the cloud fabric

Technical Exploitability (Trustworthiness)

Risk Description:

Cloud services need to have isolation mechanisms in place to prevent a tenant developed application from breaking out of their sandboxed virtual environment to affect the infrastructure of the cloud service provider. A failure of this isolation mechanism that was sufficient to enable an attacker to gain access and modify the cloud fabric could lead to significant data loss or disruption. (Ref: ASD CC 21a)

Risk Tolerance Questions: Risk Exposure Questions:

How sensitive is the data stored within the application?

What would the impact be of a disruption to the service?

What is the track record of the cloud provider in implementing effective security practices?

Can they provide assurance around their secure development lifecycle approach?

What technical controls are in place to prevent virtualisation sandbox escape or mitigate other possible vulnerabilities in hypervisors?

How would the service provider detect and respond to an exploitation event on the service fabric?

How does the hypervisor solution protect resources of the host operating system from resources of the guest?

How consistent and effective are the configuration, patch management and other infrastructure management capabilities of the service provider?

Are there any restrictions on which kinds of tenants can operate services within the cloud - for example a government community cloud?

Risk Event Type Domain

T-Ex-04: Exploitation of cloud operations Exploitation of Cloud Service Provider administrative infrastructure leading to an attacker gaining access to Customer data

Technical Exploitability (Trustworthiness)

Risk Description:

Every cloud service provider operates an administrative infrastructure for monitoring, configuration management, helpdesk support, etc. An external attacker successfully compromising this administrative infrastructure could enable a compromise of Customer data (Ref: ASD CC 19g)

Risk Tolerance Questions: Risk Exposure Questions:

What is the sensitivity/classification of the data stored in the service?

What technical and process controls are put in place by the Cloud Service Provider to prevent exploitation of administrative infrastructure?

Specifically, are controls such as host configuration hardening, administrative privilege lock down, application whitelisting, patching, antimalware and other host protection controls apply?

What processes does the Cloud Service Provider have in place for detection and containment of any compromise on an administrative system?

Do administrators have standing privileges for access to cloud infrastructure and customer data?

81

Risk Event Type Domain

T-Ex-05: Customer infrastructure exploited Customer data held within the cloud application is lost due to exploitation of the Customer Organisation infrastructure

Technical Exploitability (Trustworthiness)

Risk Description:

A compromise of the infrastructure or user endpoints within the Customer Organisation due to inadequate security practices within the Customer Organisation could lead to loss of user or administrator credentials, and consequent disruption or loss of Customer data.

Risk Tolerance Questions: Risk Exposure Questions:

What is the sensitivity / classification of the data stored in the cloud service?

How assured is the Customer organisation currently of the adequacy of it's own security practices.

How will the endpoints and infrastructure within the Customer organisation that access the cloud service be protected?

How would a compromise of these systems be detected and contained?

What will the process be for management of privileged accounts within the Customer organisation?

Risk Event Type Domain

T-Su-01: Cascading failure in cloud An easily exploitable vulnerability within a component of the cloud service is discovered that can cause failure that replicates across the entire cloud service causing disruption or loss

Technical Survivability (Resilience)

Risk Description:

Cloud infrastructure at global scale is homogenously configured with the same operating systems, patch levels and applications. Hypothetically, a failure resulting from a discovered vulnerability could more easily cascade across a homogeneous system.

Risk Tolerance Questions: Risk Exposure Questions:

How critical is the service to the continued operation of the business?

What impact would it have for the organisation if the service became unable for a prolonged period?

What are the business continuity and disaster recovery practices of the service provider?

What visibility can the Customer organisation have into these processes?

What denial-of-service protections does the service provider implement?

How would the cloud service provider approach containing the spread of an attack across a set of homogeneous, internet-facing systems?

82

Risk Event Type Domain

T-Ip-01: Failed integration of security systems Existing or future security management and monitoring tools used by the Customer are incompatible with Cloud Service Provider systems

Technical Interoperability (Adaptability)

Risk Description:

Typically enterprise customers will need to maintain some level of visibility into the configuration and operations of the Cloud Service to integrate with an enterprise wide security incident and event management system, to correlate logs, maintain asset inventories, etc. The risk is that the Cloud Service Provider either doesn't expose sufficient data or exposes it in a way that can't be readily integrated into the enterprise's broader management toolset (Ref: ASD CC 19g)

Risk Tolerance Questions: Risk Exposure Questions:

What does the Customer organisation currently do in terms of security incident and event management?

Is there a standard toolset adopted by the Customer organisation for systems/security management and monitoring?

What impact would it have if those tools could not be integrated with the cloud service?

What security, management and monitoring data does the Cloud Service Provider expose for integration with Customer management systems?

Are there specific toolsets required?

Is the data provided in a non-proprietary manner that could be integrated with a variety of different management toolsets?

Are there third-party cloud service providers that can provide management & monitoring?

83

Threat Modelling

The risk assessment described so far is based

on an approach that looks across the widest

practical range of risk domains and possible

impacts. It’s intent is focused on breadth of

coverage, rather than depth.

However, some risk events may require a

more extensive examination that looks

deeper into the possible conditions that may

realise a risk and one that more fully

examines the security mitigations in place to

reduce the event’s probability or impact. This

may particularly be the case for risk events

with a potential major or catastrophic impact

to the organisation. For these high impact

risks, the organisation needs to be very

confident that their assessment of probability

is correct.

Additionally, for some risks to be realised

there may need to be multiple failures in

controls. For example, the risk of interception

of data transmitted between two cloud data

centres may require (a) failure of physical

controls on communication networks, (b)

failure of encryption methods on the same

communication networks. Determining the

probability of such multiple event scenarios

can be complex but necessary to inform an

assessment of that specific risk. This is where

threat modelling, and in particular the

concept of a threat tree can be very valuable.

A threat tree (sometimes referred to as an

attack tree) is a conceptual hierarchy showing

how an asset can be attacked, or more

formally how a risk event can be realised.

First described by Edward Amoroso and then

popularised by Bruce Schneier, threat trees

have gained wide adoption in areas where the

interrelationships between complex risk

events need to be assessed.

A threat tree has a single root node that

represents a risk event, and then multiple

child nodes that represent conditions or

events that must be satisfied for the root risk

event to be realised. Each child node can in

turn have multiple child nodes. The

relationship between a node and it’s child

nodes can be expressed logically as AND or

OR. That is, a node’s conditions can be

satisfied if a number of child nodes are true

(AND) or if one of it’s conditions are true (OR).

This is best represented by the simplified

example below. In this diagram the root risk

event is for readable customer data to be

compromised. For this to occur, firstly the

data would need to be compromised but it

would also need to be readable. If the data is

not encrypted, the root risk event could occur

if there was either an accidental data spillage,

deliberate compromise or lawful data

request. However, if the data were

encrypted, then not only must the data be

compromised, either the encryption keys

must become known to the attacker or the

encryption is found to be weakly

implemented.

Figure 30: An Example Threat Tree

84

Security controls or mitigations can be applied

at any level of the threat tree to reduce the

probability of a condition being satisfied. It is

indeed possible to map security controls

against each leaf of the threat tree in order to

assess their effectiveness in addressing the

root risk event. Following on from the

previous example, the diagram below maps

some illustrative process and technical

security controls to the threat tree.

Assessing the probability of any of these

conditions being satisfied (and therefore the

probability of the root risk event occurring)

then comes down to assessing the

effectiveness of each of these controls. This

approach can also be very effective in

understanding the benefit of adding a specific

mitigating control or having additional

controls applied by the cloud service

consumer. For example, the diagram shows

the inclusion of data loss prevention filters

which would be configured by the service

consumer rather than the cloud provider.

Every organisation will have different

perspectives on key risk events, the conditions

they see as precursors to the risk event and a

framework of technical and process controls.

As an aid, the handbook provides threat trees

and control mappings for three of the most

commonly assessed complex, high impact risk

events:

Readable customer data compromised

disclosed to a third party

Permanent customer data loss or damage

Disruption of service

It should be reiterated that because of the

depth of understanding required, this type of

threat modelling should be applied selectively

to high impact or complex risk events only.

85

Threat Tree 1: Overview

The first threat tree provides an overview of

the three key threats modelled and how they

are composed into sub-trees. A number of

threat trees are expanded in further diagrams,

so this only shows the root risk events and

their highest level children. Interconnections

between threat trees are not shown here but

they do exist and are described in the

subsequent more detailed models.

The diagram to one side and the following

tables describe each threat tree and aligned

controls.

86

87

88

Threat Tree 2: Customer Data is

Readable

The second threat tree in this hierarchy

focuses on the conditions by which data could

be in a readable, unencrypted state. There is

a common understanding that encryption is a

desirable control to protect data stored in a

cloud service. The assumption is that even if

data is lost or intercepted, it is meaningless

while in an encrypted state. However, for this

assumption to be valid, the encryption /

decryption keys must not become known, the

choice of cryptographic controls must be

adequate and cryptographic policies need to

be technically enforced appropriate to

different data classifications. These are the

conditions assessed in this threat tree.

The first condition for customer data to be

readable is simply that the data is not

encrypted in the first place. Encryption at rest

and/or in transit are commonly applied

controls. Local data encryption is a variant of

this practice, whereby data is encrypted on

premise before it is stored in the cloud and

decrypted again on premise prior to access by

a user. The challenge with local encryption is

that it makes it impossible for the cloud

service to perform any function more than

simply storage. Effective data classification

and an enforced policy on the use of

encryption for appropriate classifications of

data is also necessary.

Encryption keys could be lost if the cloud

provider infrastructure is compromised by an

external attacker (under circumstances

modelled in threat tree 4) and there is a

breakdown in key management practices.

This is because standard key management

practices isolate keys as highly sensitive

information including storage of the keys so

they cannot be exported by an attacker.

A similar circumstance could occur if

encryption keys are held by the customer but

the customer infrastructure is compromised.

It is common thinking that encryption is a very

effective control in cloud services, provided

the customer can retain control of the keys.

In reality, this depends on what threat the

customer is more concerned about and the

relative security capabilities of the cloud

service and the customer. If the most salient

threat is the possibility of a malicious act by

the cloud provider or one of it’s employees,

then the logic may be sound. However, if the

most significant threat is of a targeted attack

by a determined intruder, then considering

the relatively stronger security controls and

processes of cloud service providers in

comparison to their customers, this

assumption is likely to be untrue. It’s

probably far easier for an intruder to steal

keys from the customer organisation than to

steal them from the cloud service provider.

Finally, encryption may be rendered useless if

poor choices are made in the protocol,

algorithms and key lengths selected. For

most organisations, this becomes equivalent

to ensuring that modern systems are used

and kept up to date, but for more sensitive or

classified data, specific protocols, algorithms

and key lengths might be specified.

89

Identifier Event / Condition Aligned Controls

1.2 Customer data is readable

1.2.1 Data is not encrypted

Encryption at Rest: Encrypting data at rest can protect against loss of media or physical attack but it should be noted that the data is generally decrypted to be processed or transmitted by an application in the cloud, so encryption at rest is not effective against attacks on the application. Encryption in Transit: Encrypting data as it traverses a network between services and consuming devices or between data centres can be an effective control against interception. Local Data Encryption (Customer): Encrypting data before it enters the cloud service can be performed by a client application, encryption gateway or device. The benefit is that with all data encrypted in the cloud, the risk of data loss is reduced. However, this imposes severe restrictions on the utility of cloud applications: As they cannot access the data, the function of the cloud is limited to merely storage. Data Classification: Effective data classification, and then the enforcement of policy based on that classification is a fundamental control relevant to the use of the cloud. For example, a policy might enforce the rule that all data classified as Sensitive must be encrypted-at-rest in the cloud service. Generally, the classification needs to be applied by the Customer of the service, not the cloud service provider. Policy on Use of Cryptographic Controls: Based on data classifications, a policy on the use of cryptographic controls should describe how cryptography is used to protect data at different classifications.

1.2.2 Encryption keys become known

1.2.2.1 Encryption keys lost by cloud provider

1.2.2.1.1 (AND) Cloud provider infrastructure compromised

Step to Threat Tree 4: 1.1.3.1

1.2.2.1.2 (AND) Breakdown in key management enabling attacker access to keys

Key Management: Encryption controls are only as effective as their associated key management practices. A formal process needs to be in place covering the lifecycle of keys including key generation, replacement, revocation, access controls, storage and monitoring. Protected Key Storage: An important part of the overall key management practice is stored in a protected manner. The sensitivity of keys requires additional controls including isolation, access control and monitoring. Some scenarios also permit storage of keys in the cloud using a High Security Module, whereby keys are accessible to the application, but remain under the control of the customer.

1.2.2.2 Encryption keys lost by the customer

1.2.2.2.1 (AND) Customer infrastructure compromised

Step to Threat Tree 5: 1.1.3.2

1.2.2.2.2 (AND) Breakdown in key management enabling attacker access to keys

Key Management (Customer): As per the control described above, if the customer retains control of keys, then they must similarly apply a comprehensive key management practice.

90

Identifier Event / Condition Aligned Controls

Protected Key Storage (Customer): As per the control described in 1.2.2.1.2 above, but in this case the customer is maintaining the keys and therefore must take similar steps to ensure they are protected.

1.2.3 Data is weakly encrypted

Cryptographic Standards: Cryptographic protocols and algorithms differ in their ability to protect information and poor choice of algorithms, protocols, key lengths and other characteristics can render encryption controls to be of limited value. Therefore, it’s necessary to set specific baselines for each form of encryption and ensure they are applied.

91

92

Threat Tree 3: Accidental Data

Spillage & Law Enforcement Request

An accidental data spillage or release of

information to law enforcement as a result of

a warrant are two circumstances by which

customer data might be disclosed to a third

party. Limiting both of these circumstances

relies heavily upon having in place effective

procedural controls.

In the case of accidental spillage, the threat

model focuses on circumstance whereby data

might physically leave a secure area on media,

where an operator may accidently spill data

during the course of their work, where an

application itself may inadvertently spill data.

One other scenario for data spillage

considered is leakage if one tenant reuses a

resource previously used by another tenant,

such as a disk, and is able to see data of the

previous tenant. A range of process and

technical controls are described to address

these circumstances including the use of

dedicated systems, resource isolation, media

wiping, access management and encryption.

Disclosure due to a law enforcement request

is a very different scenario. In this

circumstance, the customer is the subject of a

warrant or other order that the cloud service

provider responds to. Clarity around

applicable legislation and formal business

processes to review, challenge and respond

are the most appropriate controls in this

regard.

93

Identifier Event / Condition Aligned Controls

1.1 Customer data disclosed to a third party

1.1.1 Accidental data spillage

1.1.1.1 Data on media leaving cloud provider secure area to uncontrolled site

Media Wiping: Wiping of media is necessary to eliminate all traces of data on a disk prior to it leaving a secure area. Wiping typically involves multiple successive overwrites of zero or random data on to the disk. Encryption at Rest: Encryption of data stored on media is an effective control against spillage of data.

1.1.1.2 Unintended spillage directly from cloud application

Secure Development Lifecycle Practices: Threat modelling and other secure design techniques can help ensure that threats to software applications are identified and mitigated. This can include gaps in input validation that are a common cause of application data spillage.

1.1.1.3 Data on media, memory or network shared resources spilling

Resource Isolation: Cloud service providers routinely share resources such as networking, memory and storage with tenants isolated from one another using virtualisation approaches. Media Wiping: Wiping of media before it is reallocated to another tenant. Wiping typically involves multiple successive overwrites of zero or random data on to the disk. Encryption at Rest: Encryption of data stored on shared media Dedicated Systems: Some cloud services can be provided in a dedicated manner so that tenants do not have to share the same physical memory or storage.

1.1.1.4 Accidental spillage by cloud support personnel during operations

Data Loss Prevention: Monitoring outbound communications or network traffic to identify data spillages or deliberate attempts to exfiltrate data can reduce the risk of spillage Privileged Access Management: Privileged accounts by their nature have the ability to perform administrative activities to delete, remove or modify data and change configurations to disrupt the service. It’s therefore essential to have formally enforced mechanisms to control the allocation and use of these privileges. The most effective approach is to have zero standing privileges, only permitting an administrator to be granted a privilege on request for a specific purpose and duration. Operations Policies & Restrictions: Cloud services have service management, administrative and support teams with access to the cloud infrastructure. Technical protections on the systems they use such as authentication, hardening, antimalware, etc and process controls such as training, clearance, etc can be effective in reducing the risk of an accidental or deliberate data spillage.

1.1.2 Data disclosed to law enforcement

1.1.2.1 (AND) Customer is the subject of an order, warrant or other request

Jurisdiction for Data: The location of data stored in the cloud may have bearing on the ability of law enforcement to request access. However, in practice, multi-lateral assistance treaties may render this to be of limited relevance.

94

Identifier Event / Condition Aligned Controls

Customer Business Practices (Customer): The most significant factor in considering whether an organisation is likely to be subject of a law enforcement request is the governance, appropriateness and legality of their own business practices.

1.1.2.2 (AND) Cloud service provider responds to the warrant by releasing customer data

Legal Review, Challenge and Response Practices: The cloud service provider should have formal processes to review any request from law enforcement, determine it’s validity, and if necessary provide the minimum data requested. It may also be appropriate for the cloud service provider to redirect the request to the Customer or challenge the request.

95

96

Threat Tree 4: Cloud Service

Provider Infrastructure

Compromised

This is a complex portion of the threat tree

examining the set of conditions that could

lead to data disclosure through a compromise

of the cloud service provider infrastructure.

There are four major sets of circumstances

that are considered.

Firstly, the actions of a malicious employee or

contractor who deliberately seeks out and

removes customer data. Mitigating controls

like employee screening, monitoring,

privileged access management and data loss

prevention approaches can be effective in this

circumstance.

Secondly, the threat tree breaks down some

of the circumstances that may permit a

network exploitation by a remote attacker,

including attacks from one tenant to another,

an attack on the cloud fabric itself, an attack

on the operator systems or an attack on the

Customer application running in the cloud. A

range of relevant controls related to isolation,

secure development practices, vulnerability

management and intrusion detection &

mitigation are listed.

Thirdly, the threat tree considers the

circumstances by which an attacker could gain

access by using valid credentials that are

either lost or stolen or perhaps attack the

authentication mechanism itself, for example

by brute force guessing of passwords. Control

emphasis here is on credential management

processes and technically stronger

authentication mechanisms like multi-factor

authentication.

Finally, physical attack is considered whereby

an attacker would need to breach physical

protections to access systems, locate

customer data and extract that data. Control

emphasis here is on a range of physical

protections for the data centre itself as well as

processes to securely dispose of or handle

data if it goes off-site.

97

Identifier Event / Condition Aligned Controls

1.1.3.1 Cloud service provider infrastructure compromised

1.1.3.1.1 Malicious employee or contractor within cloud provider extracts data

1.1.3.1.1.1 (AND)

Malicious employee or contractor has sufficient access rights

Privileged Access Management: Privileged accounts by their nature have the ability to perform administrative activities to delete, remove or modify data and change configurations to disrupt the service. It’s therefore essential to have formally enforced mechanisms to control the allocation and use of these privileges. The most effective approach is to have zero standing privileges, only permitting an administrator to be granted a privilege on request for a specific purpose and duration. Administrator Monitoring & Audit: The actions of administrators should be logged, monitored and periodically audited. Employment Screening: Background verification, employment history, skills and qualifications checking are all valid ways to attempt to identify employees with potential malicious intent. Segregation of Duties: Risks associated with a user-role conflict of interest, such as the same person being able to request a privilege and be able to authorise the granting of that privilege can be addressed through careful segregation of duties.

1.1.3.1.1.2 (AND)

Malicious employee or contractor has the ability to remove data

Data Loss Prevention: Monitoring outbound communications or network traffic to identify attempts to exfiltrate data. This can also be applied to removable media. Operations Policies & Restrictions: Cloud services have service management, administrative and support teams with access to the cloud infrastructure. Technical protections on the systems they use such as authentication, hardening, antimalware, and process controls such as procedures to formally request access rights to data can be effective.

1.1.3.1.2 Network exploitation by external attacker to gain access to data

1.1.3.1.2.1 Access gained via a web application attack

1.1.3.1.2.1.1 Successful attack on cloud application’s management interface or API

Secure Development Lifecycle Practices: Threat modelling and other secure design techniques can help ensure that threats to software applications are identified and mitigated. This can include vulnerabilities in the handling or validation of data by application interfaces (API’s)

1.1.3.1.2.1.2 Successful attack on cloud application

Secure Development Lifecycle Practices (Customer): If the application is developed by the consumer of the cloud service, as in an IaaS or PaaS based application, then the customer needs to take due care in the development of the application.

1.1.3.1.2.2 Attack on cloud infrastructure resulting in access privileges

1.1.3.1.2.2.1 Tenant-to-tenant attack resulting in access privileges for attacker

Tenant Isolation: All cloud services make extensive use of virtualisation approaches in order to share physical resources like memory, storage and processing power across multiple tenants.

98

Identifier Event / Condition Aligned Controls

Isolation of these tenants from one another is critical to preventing interference from one tenant to another. Network Segmentation: Segmenting traffic on networks can mitigate the risk of attack from a tenant on one network segment against a tenant on another segment. Typically in cloud infrastructures, this segmentation is achieved virtually rather than physically. Domain Isolation: Domain isolation, sometimes referred to as community cloud, is about restricting the tenants on the cloud infrastructure to be from a specific community, such as a government cloud. This approach typically has limited effectiveness and it depends heavily on processes to restrict entrants to the community cloud. Intrusion Detection & Breach Mitigation: Processes and tools to detect network and processing anomalies, investigate and correlate security events, contain incidents and continuously improve security approaches are essential. In this scenario, it is important that attempts to attack another tenant from within one tenant are detected and contained.

1.1.3.1.2.2.2 Attack on tenant resulting in access privileges for the attacker

1.1.3.1.2.2.2.1 Unpatched vulnerability in the tenant operating system

Virtual Machine Patch Management (Customer): If the solution is Infrastructure-as-a-Service (IaaS), then the cloud customer needs to ensure that patches are deployed and have a mechanism to do so. PaaS and SaaS patch management is performed by the cloud solution provider. Vulnerability Management (Customer): This is a process of proactively identifying vulnerabilities on a continuous basis, then assessing appropriate mitigations, such as patches.

1.1.3.1.2.2.2.2 Unpatched vulnerability in the tenant application

Secure Development Lifecycle Practices (Customer): Threat modelling and other secure design techniques can help ensure that threats to software applications are identified and mitigated. If the application is developed by the customer (as in IaaS or PaaS), then this control is implemented by the cloud customer. If the solution is a SaaS service, then the control should be implemented by the cloud service provider.

1.1.3.1.2.2.3 Attack on cloud fabric resulting in access privileges for the attacker

1.1.3.1.2.2.3.1 Unpatched vulnerability in the cloud fabric operating system

Cloud Fabric Patch Management: Monitoring the cloud underlying infrastructure and deploying appropriate patches Vulnerability Management: In relation to patches, vulnerability management comprise the processes for assessing and determining the need to deploy patches. Intrusion Detection & Breach Mitigation: Processes and tools to detect network and processing anomalies, investigate and correlate security events, contain incidents and continuously improve security approaches are essential. In this scenario, it is important that

99

Identifier Event / Condition Aligned Controls

attempts to attack another tenant from within one tenant are detected and contained.

1.1.3.1.2.2.3.2 Unpatched vulnerability in the cloud fabric management application

Secure Development Lifecycle Practices: Each cloud platform requires underlying infrastructure and software to manage virtual resources, commonly known as the cloud fabric. Threat modelling and other secure design techniques can help ensure that threats to the cloud fabric are identified and mitigated.

1.1.3.1.2.2.4 Attack on operator systems enabling privileged access to data

Privileged Access Management: Privileged accounts by their nature have the ability to perform administrative activities to delete, remove or modify data and change configurations to disrupt the service. It’s therefore essential to have formally enforced mechanisms to control the allocation and use of these privileges. Network Segmentation of Management Systems: Segmenting management traffic from normal traffic on the network can limit the potential for leakage of data via the management interfaces of systems. Operations Policies & Restrictions: Cloud services have service management, administrative and support teams with access to the cloud infrastructure. Technical protections on the systems they use such as authentication, hardening, antimalware, etc and process controls such as training, clearance, etc can be effective in reducing the risk of an accidental or deliberate data spillage. Intrusion Detection & Breach Mitigation: Processes and tools to detect network and processing anomalies, investigate and correlate security events, contain incidents and continuously improve security approaches are essential. In this scenario, it is important that attempts to attack operator systems and networks are detected and contained.

1.1.3.1.3 Use of valid credentials by external attacker to gain access to data

1.1.3.1.3.1 Valid cloud service provider administrator credentials lost or stolen

Multi-factor Authentication for Cloud Administrators: The use of multiple factors, such as username/password along with biometrics or a smartcard can be effective to reduce the risk of lost or stolen credentials. The most common factors used by cloud providers are biometrics for physical access and smartcards for system access. Credential Management: This comprises the process controls around issuance, revocation and protection of credentials.

1.1.3.1.3.2 Customer user or administrator credentials lost or stolen

Multi-factor Authentication for Customer Users (Customer): Customers of cloud services can also use multiple factors for authentication such as smart cards, tokens, etc. Credential Management (Customer): Processes need to be established to control the issuance, protection and revocation of credentials used by administrators and staff of the cloud customer.

1.1.3.1.3.3 Authentication mechanisms are vulnerable to attack

Authentication Policies: Authentication policies define the appropriate credentials required for access to different services. For example, low sensitivity assets may only require user name and password to access. Highly sensitive systems may require multiple factors for authentication. Also some authentication approaches are

100

Identifier Event / Condition Aligned Controls

more susceptible to attack such as for example, passwords with a small number of characters.

1.1.3.1.4 Physical attack by external attacker to gain access to data

1.1.3.1.4.1 (AND)

External attacker can gain physical proximity to access and remove data

Secure Perimeters: Physical perimeters protected with fences, doors, locks, barriers and guards are a foundational control for data centres to prevent damage or theft of equipment. Secure Areas: Typically data centres comprise of segmented areas, with different levels of sensitivity and access restriction. Physical Security Monitoring: Monitoring of physical security perimeters and internal areas with alarms, intruder detection systems and guards. Secure Disposal & Off-site Handling: If data or equipment is moved off site for backup, maintenance or other purposes, it is important to ensure that the data is protected. This may require additional measures such as encryption, wiping or policies that prevent off-site handling. Secure Equipment Management: The selection, commissioning and maintenance of equipment needs to performed in a manner that protects the security of data stored on that equipment

1.1.3.1.4.2 (AND)

External attacker can identify the specific physical location of data

Data Sharding: Data sharding is a process of distributing data across multiple locations in small portions rather than placing all data on a single drive.

101

102

Threat Tree 5: Customer or 3rd Party

Infrastructure Compromised

The extensive investment made by cloud

service providers in their security technologies

and practices makes them a hardened target

for any attacker. To a very real extent, it be

much wiser for an attacker to focus on a

potentially more vulnerable means of attack,

the customer infrastructure itself.

Compromising customer systems, apart from

gaining access to information still stored on

the customer on-premise systems, could

enable an attacker to steal credentials for

access to the cloud service, steal data

synchronised between the cloud service and

customer devices, or modify configuration on

customer infrastructure to disrupt access to

the service.

There are a wide range of mechanisms by

which an attacker could compromise

customer infrastructure from seemingly

simple approaches involving social

engineering to more sophisticated techniques

using custom malware. It may also involve

physical attack or perhaps the accidental or

malicious actions of an employee. It is

beyond the scope of this handbook to address

all these possibilities and relevant controls.

Instead, the threat tree focuses on how a

compromise of customer infrastructure could

be escalated to affect the customer services

or data contained within the cloud service.

There are two key scenarios considered here.

The first scenario is one in which data is

synchronised locally and accessible to the

attacker. The second highlights the risk that

an attacker who has stolen credentials on the

customer infrastructure could use those

credentials to access the cloud service.

It is important to note there are other

connections between this scenario of

customer infrastructure compromise and

other threat trees. For example, if an attacker

can gain access to customer held encryption

keys, then some of the encryption practices in

the cloud can be nullified.

Another area covered in this threat tree is

that of compromise of a third party or other

systems not under the control of either the

customer or the cloud service provider. This

could for example include the public or

private network between the customer and

the cloud provider or the network between

cloud service provider data centres. It may

also include third party services that integrate

with the solution, such as for example a third

party identity service provider or third party

suppliers that are embedded within the

supply chain, such as hardware equipment

manufacturers. Encryption, along with virtual

private or dedicated private networks are key

controls to consider to mitigate risk of these

scenarios.

103

Identifier Event / Condition Aligned Controls

1.1.3 Deliberate compromise leading to disclosure of customer data

1.1.3.1 Cloud service provider infrastructure compromised

Step to Threat Tree 4: 1.1.3.1

1.1.3.2 Customer infrastructure compromised

1.1.3.2.1 (AND) Customer infrastructure is compromised by an intruder

Customer Infrastructure Technical Controls (Customer): A range of customer technical controls covering governance of information security, security awareness, access control, data protection, physical security and so on are necessary to protect the customer infrastructure from compromise. Ideally, a comprehensive framework such as ISO 27001 is adopted. Customer Infrastructure Process Controls (Customer): To complement technical controls a range of management and procedural controls around personnel, physical and technical security are required on the customer side.

1.1.3.2.2 (AND) Intruder on customer infrastructure gains access to cloud data

1.1.3.2.2.1 Data is copied locally and accessible to the attacker

Data Loss Prevention: Monitoring outbound communications or network traffic to identify data spillages or deliberate attempts to exfiltrate data can reduce the risk of spillage.

1.1.3.2.2.2 Attacker gains credentials that enable access to cloud services

Multi-factor Authentication for Customer Users (Customer): The use of multiple factors, such as username/password along with biometrics or a smartcard can be effective to reduce the risk of lost or stolen credentials. An attacker might be able to get access to credentials like a username and password but if they also need a device like a phone or smartcard, then they are prevented from gaining access. Credential Management (Customer): This comprises the process controls around issuance, revocation and protection of credentials.

1.1.3.3 Compromise of 3rd Party systems outside cloud provider or customer control

1.1.3.3.1 Compromise of cloud service provider supply chain

Supply Chain Integrity Processes: Generally these are equipment and service acquisition controls to ensure that equipment or services required by the cloud service provider are evaluated as not introducing security risks.

1.1.3.3.2 Interception of communications between data centres

Encryption in Transit: Encrypting data as it traverses a network between services and consuming devices or between data centres can be an effective control against interception. Private Networks: The bandwidth of communications between data centres though may make encryption of all traffic cost-prohibitive. Private networks may be a reasonable alternative, although a preferable approach is to use both private networks and encryption. Interception Detection & Mitigation: Processes for monitoring, detecting and mitigating attempts to infiltrate or intercept communications between data centres.

104

Identifier Event / Condition Aligned Controls

Restrictions on Data Location (Customer): The customer may be able to choose in which locations data may be stored, such as restricting data to the local country or region. Although not directly a control that may impact the risk of interception, some may view different global regions as having a greater or lesser risk of interception.

1.1.3.3.3 Interception of communications between cloud customer and data centre

Encryption in Transit: Encryption of data between the cloud service provider and the customer is a foundational control necessary for any cloud service. Commonly this is implemented as SSL at the application layer Virtual Private Networks: A virtual private network can isolate and protect communication between the customer end point and the cloud service. Typically this is established through the use of IPSec, which is a standard for encryption and authentication between the end points at the network layer. Dedicated Network Connections: Some cloud services will be able to provide direct, dedicated network connections so that communications between the cloud service and the customer do not pass over the pubic internet.

105

106

Threat Tree 6: Permanent Loss of

Customer Data

The loss of customer data through deletion,

damage or destruction is a second risk event

that is commonly necessary to analyse.

Compliance requirements around record

integrity and maintenance as well as the

potential business impact of losing important

data generally drive the focus on this risk.

According to this threat tree, there are really

three conditions that need to simultaneously

exist for the risk event to occur.

Firstly, customer data has to be deleted,

damaged or destroyed. This could happen as

a result of an accidental deletion or damage

by the customer for which there isn’t a simple

‘undo’ process or feature. Alternatively, data

could be accidentally deleted or damaged by

cloud service personnel. The practice of

continuous replication of data across multiple

locations can mean that any deletion or

damage introduced can rapidly replicate to all

other locations where that data is stored. To

avoid this circumstance, change control and

privileged access management controls are

vital on both the cloud service provider and

customer side. Another alternative would be

the deliberate action of an attacker as

described in threat tree 4.

The second prerequisite would be for there to

be no readily recoverable backup on the

customer or 3rd party location. Some

customer may deem risks to be so significant

as to require replication of data on their

premise or to a 3rd party location. If such a

backup exists, there may still be disruption

and complexity to recovering the backup but

at least data is not irrevocably lost.

The third condition is for no readily

recoverable backup to exist within the cloud

service. Generally, cloud service providers

undertake to have comprehensive backup and

recovery controls in place including data

replication between paired sites, but there

are some circumstances in which no backup in

the cloud could be recoverable.

Firstly, if there was a simultaneous disaster in

the two paired sites of a cloud service, then

both production and failover data could be

destroyed. Although the prospect may be

remote, this is one reason why both sites

should be geographically separated.

Alternatively a disaster in just one site

combined with a failure of disaster recovery

processes, perhaps because those processes

were untested, could also lead to the risk

event occurring.

A final scenario whereby no readily

recoverable backup exists in the cloud would

be where backup and recovery processes are

inadequately implemented or insufficiently

tested. Customers may believe that backups

are being taken but they may not be

operational.

107

Identifier Event / Condition Aligned Controls

2 Permanent loss of customer data

2.1 (AND) Customer data is deleted or destroyed

2.1.1 Accidental deletion by customer

Customer Change Control Processes (Customer): Formalised processes for the planning, authorisation, execution and verification of changes in a controlled manner

2.1.2 Accidental deletion by cloud service personnel

Cloud Provider Change Control Processes: Formalised processes for the planning, authorisation, execution and verification of changes in a controlled manner Privileged Access Management: Privileged accounts by their nature have the ability to perform administrative activities to delete, remove or modify data and change configurations to disrupt the service. It’s therefore essential to have formally enforced mechanisms to control the allocation and use of these privileges.

2.1.3 Deliberate deletion as a result of cloud infrastructure compromise

Step to Threat Tree 4: 1.1.3

2.2 (AND) No readily recoverable backup exists on customer or 3rd party site

Replication / Backup of Data Locally (Customer): The customer can put in place mechanisms to maintain a backup or archive of data held in the cloud. Replication / Backup of Data to 3rd Party (Customer): Data can be archived, journaled or backed up to a third party service in addition to the normally expected backups on the cloud service

2.3 No readily recoverable backup exists on the cloud

2.3.1 Unrecoverable disaster event in cloud provider infrastructure

2.3.1.1 Disaster in paired site of cloud infrastructure simultaneously

Geographic separation: Ensuring that data centre locations are geographically distant so that any localised disaster event does not affect both data centres in an availability pair.

2.3.1.2 (AND) Disaster in a single cloud infrastructure location

Fire Suppression & Containment: Physical equipment to detect the presence of fire, suppress that fire and contain it to one area of a data centre for a period of time. Power Management: Uninterruptible backup power supplies capable of maintaining operations during power disturbances. Heating & Cooling: Environmental controls over heating and cooling to ensure the data centre can be maintained at a reliable working temperature. Site Selection: Due diligence around the selecting the location of a data centre to limit exposure to environmental conditions like flood, fire, or other extreme weather events as well as geopolitical and legal stability.

2.3.1.3 (AND) Disaster recovery processes fail

System Redundancy and Failover: High availability measures including redundancy and the ability to failover systems

108

Identifier Event / Condition Aligned Controls

Tested Disaster Recovery Processes: A process of regular testing of disaster recovery processes to ensure that in the event of a real disaster, the processes work.

2.3.2 Cloud provider backup or recovery processes fail

Offline Backup: This is the process of taking a backup copy of customer data at scheduled intervals, then transferring that copy to a secure location. The volume of data involved and opportunity for errors in this process has led to the decline in practices for offline backup in favour of near-continuous data replication. Data Replication: Replication of data within a data centre and between paired data centres is generally more favoured than offline backup. Tested Backup and Recovery Processes: Ensuring that backup and recovery processes are tested and that both responsibilities and procedures are understood between the customer and the cloud service provider.

109

110

Threat Tree 7: Disruption of Cloud

Service

As organisations increasingly rely on their

applications and information technology

services, it is understandable to be concerned

that disruption of a cloud service could have

significant impact on the business operation.

This third risk event focuses then on the

conditions that could result in a cloud service

becoming unavailable.

Generally, cloud service providers will have an

established Service Level Agreement defining

the expected level of service availability. This

may be backed by financial or other

compensation mechanisms if the actual

availability levels are less than the SLA.

However, it is unlikely that this compensation

will adequately reflect the actual cost of

business disruption to a customer.

There are four main circumstances considered

in this threat tree. The first scenario is that of

the service becoming unavailable due to

exceptional network or processing load on the

service. This could result from a denial of

service attack, an inadequate amount of cloud

or network resources being provisioned or

congestion and disruption on the network.

Effectively dealing with these circumstances

requires an ability for the cloud service

provider to dynamically provision and deal

with exceptional load events. It also requires

customers to have adequate network

provisioning and planning.

A second scenario is for the service to be

unavailable due to planned downtime. Large

scale cloud providers generally plan and

execute updates and changes in a manner

that avoids significant amounts of planned

downtime. Planned downtime should be

reflected in the Service Level Agreement and

care should be taken to consider the timing of

any planned events. For example, a common

planned downtime window for a US based

service is late on a Sunday night, which may

equate to late Monday afternoon in

somewhere like Australia.

The third scenario for disruption to service is a

failure event either within the cloud service,

on customer infrastructure for connecting to

the cloud or a configuration error by either

the cloud provider or the customer. Dealing

with this scenario requires a combination of

high availability technical measures within the

cloud service as well as change control

processes on both sides.

A final scenario is for the service to become

unavailable if it is terminated by the cloud

service provider, either because they’ve

become financially non-viable or have simply

chosen to terminate the service as a business

decision. Apart from contractual

commitments, this requires due diligence in

assessing the track record and viability of the

cloud service provider.

111

Identifier Event / Condition Aligned Controls

3 Disruption of cloud service

3.1 Service unavailable or degraded due to network or processing load

3.1.1 Denial of service attack Content Distribution Network: A content distribution network can help mitigate the effects of a denial of service attack by having content distributed and cached at multiple locations. This spreads the impact of an attack and enables multiple alternate channels to a cloud resource. Denial-of-Service Throttling: Effective detection, and classification of traffic into ‘good’ and ‘bad’ combined with automated mechanisms to throttle bad traffic out.

3.1.2 Inadequate cloud infrastructure resources provisioned

Dynamic cloud resource provisioning: Mechanisms to scale up and scale out on demand either automatically based on identified resource needs or on customer demand. This dynamic resource provisioning is a foundational characteristic of public cloud. Service / Resource Planning (Customer): Customers of cloud services also need to plan for the resources they will need, then establish authorisation for the cloud service provider to scale to satisfy demand.

3.1.3 Inadequate network resources provisioned

Network provisioning and scale-up (Customer): Commonly, the performance bottleneck in cloud services is the network connection between the cloud service provider and the consumer. A network connection that can be adjusted in terms of bandwidth and quality on demand is usually required.

3.1.4 Network service congested or disrupted

Multiple network routes within cloud service: Use of multiple network paths within a cloud data centre and between data centres enables a greater level of resilience to network issues. Likewise connections between data centers man need to traverse multiple paths Multiple network routes for customer (Customer): Use of multiple network routes between the customer and the cloud service provider might include for example both a direct, dedicated connection and an encrypted connection over the public internet.

3.2 Service unavailable due to planned service downtime

Contracted service level agreement: A formal agreement around service levels including availability targets, scheduled downtime and compensation for failing to achieve SLA’s. High availability configuration (Customer): The cloud customer can often make choices that increase the availability of the overall solution. For example, having multiple virtual machines live operating in different availability zones. Generally cloud service providers will schedule changes so that they only occur in one availability zone at a time.

3.3 Service unavailable due to a failure event

3.3.1 Cloud service provider hardware or software failure

3.3.1.1 (AND) Hardware or software fails Clustering and Load Balancing: Distribution of processing across a number of systems can enable seamless recovery from failure.

112

Identifier Event / Condition Aligned Controls

Automated Fail Over: Clustering is often used for processing intensive systems, while failover is more commonly implemented for database and storage resources Replication of Data: Replicating data between systems to ensure a consistent replica exists on a number of systems simultaneously is essential to effective automated failover. Replication may exist within close proximity of a system or even between geographically distant data centres. High availability configuration (Customer): The cloud customer can often make choices that increase the availability of the overall solution. For example, having multiple virtual machines live operating in different availability zones. Generally cloud service providers will schedule changes so that they only occur in one availability zone at a time.

3.3.1.2 (AND) Clustering and failover measures fail

Testing of high availability processes: Frequent, periodic testing and refinement of high availability processes is essential.

3.3.2 Customer intermediary hardware or software failure

Redundancy & fail over: Sometimes cloud services rely on particular infrastructure operated by the customer, such as for authentication or networking. If these systems are not resilient, then a failure could prevent users from accessing the services. Testing of high availability processes: Frequent, periodic testing of high availability mechanisms on the customer side is necessary.

3.3.3 Configuration error Cloud service change control processes: Formalised processes for the planning, authorisation, execution and verification of changes in a controlled manner Customer change control processes (Customer): Formalised processes for the planning, authorisation, execution and verification of changes in a controlled manner

3.4 Service unavailable due to termination of service by the cloud provider

3.4.1 Service provider becomes bankrupt or otherwise ceases to operate

Financial due diligence: Examining the financial stability and liquidity of the cloud service provider

3.4.2 Service provider makes a business decision to terminate the service

Business Practices Due Diligence: Examining the track record of the cloud service provider in launching and terminating services.

Wo

rked

Exa

mp

le

113

Worked Example The following summary risk assessment describes the Department’s assessment of risk exposure for

each of the three alternative options. Risk events where the assessed exposure is higher than the

organisation’s assessed risk tolerance are particularly highlighted.

Strategic Risk Events 1: On Premise 2: Local Hosted Cloud

3: Public Cloud

Risk Event Tolerance Impact Likelihood Exposure Likelihood Exposure Likelihood Exposure

S-Co-01: Cloud service data breach M 4 2 S 1 M 1 M

S-Tr-01: Cloud service bankruptcy S 3 1 L 2 M 1 L

S-Tr-02: Inappropriate use of customer data M 4 1 M 1 M 1 M

S-Pd-01: Termination by service provider M 2 1 VL 2 L 2 L

S-Av-01: Extended period of service disruption M 3 3 S 2 M 1 L

S-Fl-01: Service inflexibility H 1 4 M 2 VL 3 L

S-Po-01: Non-portability of data on termination S 2 2 L 2 L 2 L

S-Cf-01: Unable to initially configure to fit M 3 4 H 2 M 2 M

Operational Risk Events 1: On Premise 2: Local Hosted Cloud

3: Public Cloud

Risk Event Tolerance Impact Likelihood Exposure Likelihood Exposure Likelihood Exposure

O-Ex-01: Damage due to co-tenant activities S 1 1 VL 2 VL 2 VL

O-Ex-02: Unauthorised physical access M 3 3 S 2 M 1 L

O-Co-01: Malicious insider steals data M 3 2 M 2 M 2 M

O-Co-02: Lawful confiscation of equipment S 1 1 VL 3 L 1 VL

O-Co-03: Accidental loss or theft of backups M 3 2 M 2 M 2 M

O-Tr-01: Confused security responsibilities M 3 2 M 3 S 4 H

O-In-01: Damage to logs S 2 2 L 1 VL 1 VL

O-Lt-01: Required capacity unavailable S 2 4 S 2 L 1 VL

O-Lt-02: Network congestion H 2 3 M 2 L 2 L

O-Lt-03: Variable performance under load H 2 4 S 3 M 2 L

O-Av-01: Network disruption S 3 3 S 3 S 3 S

O-Av-02: Downtime during business hours M 3 3 S 2 M 2 M

O-Re-01: Disruption due to natural disaster S 3 2 M 1 L 1 L

O-Cf-01: Lack of skilled resources M 2 4 S 2 VL 2 VL

Wo

rked

Exa

mp

le

114

Compliance Risk Events 1: On Premise 2: Local Hosted Cloud

3: Public Cloud

Risk Event Tolerance Impact Likelihood Exposure Likelihood Exposure Likelihood Exposure

C-Co-01: Lawful warrant compelling disclosure M 2 1 VL 1 VL 2 L

C-Co-02: Leakage of sensitive data into cloud S 2 3 M 3 M 3 M

C-Tr-01: 3rd party supplier compliance issues M 3 1 L 2 M 2 M

C-Tr-02: Failure to maintain adequate controls M 4 3 H 2 S 1 M

C-Pr-01: Insider accesses private data M 3 2 M 1 L 1 L

C-Pr-02: Inadequate privacy legal protections M 2 1 VL 1 VL 3 M

C-Pr-03: Cloud practices inadequate for privacy M 3 2 M 2 M 2 M

C-Pd-01: Change in cloud provider practices S 4 1 M 2 S 2 S

C-In-01: Unable to respond to legal discovery H 2 1 VL 2 L 3 M

C-Pp-01: Insufficient disaster preparedness H 2 3 M 2 L 1 VL

C-Fl-01: Unable to meet new compliance needs S 2 2 L 2 L 3 M

C-Po-01: Contractual restriction on portability M 2 1 VL 3 M 2 L

Technical Risk Events 1: On Premise 2: Local Hosted Cloud

3: Public Cloud

Risk Event Tolerance Impact Likelihood Exposure Likelihood Exposure Likelihood Exposure

T-Ex-01: Isolation failure between tenants S 2 1 VL 2 L 1 VL

T-Ex-02: Exploitation of customer gateway M 4 2 S 2 S 2 S

T-Ex-03: Isolation failure on cloud fabric S 2 1 VL 2 L 2 L

T-Ex-04: Exploitation of cloud operations M 3 3 S 2 M 2 M

T-Ex-05: Customer infrastructure exploited M 4 3 H 3 H 3 H

T-Co-01: Interception in transit to customer M 3 2 M 1 L 1 L

T-Co-02: Data visible on reallocated resources M 3 1 L 1 L 1 L

T-Co-03: Interception between data centres M 3 1 L 1 L 2 M

T-Co-04: Interception due to loss of encryption M 4 2 S 1 M 1 M

T-In-01: Backup failure S 2 3 M 1 VL 1 VL

T-Su-01: Cascading failure in cloud H 2 1 VL 1 VL 1 VL

T-Ip-01: Failed integration of security systems H 1 1 VL 2 VL 3 L

115

Step 5 – Decide & Plan

Overall Assurance Evaluation

The final step in the assurance evaluation is to

combine all inputs and the outcomes of

functional, compliance and risk assessments

to develop an executive recommendation for

the business. This recommendation should

reflect the strategic intent, context and

assurance objectives mapped out at the

beginning of the process. And it needs to

provide sufficient guidance for an executive

decision on which of the multiple alternative

options are preferable from a security

assurance perspective.

There are three principal components to the

final recommendation. The first component

comprises an assessment of how the cloud

service can integrate with the organisation,

addressing the internal requirements around

identity & access, information protection and

management & monitoring. It aims to answer

the question: Which of the alternatives best

aligns with our organisation’s security needs?

The second part is a compliance assessment

covering privacy, records, information security

and other externally imposed compliance

requirements. This part addresses the

question: Which of the options best enables

our organisation to satisfy compliance

obligations?

The third part presents a summary of the risk

assessment across the assurance domains of

trustworthiness, resilience and adaptability

considering impacts of a strategic,

operational, compliance and technical nature.

Along with the summary, the top 5 risk events

are also described, possibly along with

guidance for their treatment.

Finally, the executive recommendation

provides a subjective overall assessment of

each solution relative to the assurance

objectives.

A template for presenting this

recommendation is shown in the worked

example.

Figure 31: Assembling the outputs from each stage of the assurance process to provide an

overview and executive recommendation

116

Ongoing Governance

The focus of this handbook has been

undertaking an assurance evaluation and then

making a decision, but assurance is not just a

point-in-time process. During the design,

deployment and operational stages of

implementing a cloud solution, there are a

number of aspects of assurance and security

governance that need to be monitored.

Engineering Quality It’s important to ensure that the engineering

plan to migrate to the cloud solution

incorporates security throughout the design

and deployment. Decisions that may have

been made during the assurance evaluation to

incorporate specific mitigations or additional

controls will need to be factored into the

design. New information and technical

challenges may emerge during the

engineering process requiring security

assessment.

User Privileges and Credential

Management The cloud service provider will generally have

formalised controls around privileges and

credentials for operator personnel, but the

cloud customer also has to establish similar

controls. Who will have administrative access

to the cloud service, capable of configuring

the service or adding new users? How will

users be authenticated and how will their

credentials be distributed? How will their

access be revoked if they leave the

organisation? These are just some of the

questions that the cloud service customer

needs to address.

Information Classification The risk and compliance assessment is based

on an understanding of the sensitivity or

classification of the customer data. For

example, the assessment may have concluded

that for confidential data, the cloud service

provides adequate protection as default, but

the controls are not yet adequate for Secret

data.

Classification is typically the responsibility of

the customer though, so it’s necessary to have

processes to actually confirm that data being

processed in this example is restricted to only

confidential data or lower, and that it doesn’t

arbitrarily expand to be used for more

sensitive data classifications without

appropriate assessment.

Operational Assurance Cloud services are always changing as new

functionality and capabilities are released.

New threats and techniques emerge to be

used by attackers. Compliance requirements

change as government and regulators adapt

to the opportunities and risks of cloud.

The customer needs to be able to validate

that these features, threats or compliance

requirements don’t materially affect their

compliance and risk assurance posture. It

may be appropriate to implement additional

compensating controls or take advantage of

new features to offset a change in assessed

chance in risk or compliance.

Monitoring & Management Processes The organisation needs to assess if it has the

processes in place to monitor and manage

their consumption of cloud services. The

technical skills involved are very different to

managing on-premise infrastructure and the

mechanisms by which services are monitored

and managed require different skills.

From a security incident response

perspective, the process between a cloud

117

service provider and a customer will be very

different. If an attack is prevented by the

cloud service provider, then the customer

may not even be notified. If an attack is

successful, then the investigation performed

by the cloud provider may result in very little

information being available to the customer.

Forensic information may be unavailable or of

a very different nature to on-premise forensic

investigations.

Wo

rked

Exa

mp

le

118

Worked Example

Executive Background

The Department has undertaken an evaluation of the security of three alternative delivery options

for the Department’s collaboration & communications modernisation program. The three options

were: to implement the solution on-premise; to source the solution from a local cloud hosting

provider; to source the solution from a global cloud service provider. It is understood that each

option comes at significantly varying costs, but cost was out-of-scope for this evaluation.

The evaluation sought to assess the capability of each option to:

Integrate with our existing systems and Departments future information security needs;

Enable compliance with the Department’s regulatory and other external requirements;

Minimise the information security risk to the Department

Fit to Internal Requirements

An assessment covering the ability of each alternative option to satisfy the Department’s

requirements in the areas of identity & access, management & monitoring and information

protection is summarised below. All solution options provide an adequate capability to integrate

with the Department’s existing systems. Public cloud and local hosted cloud provide a lesser

amount of direct control and therefore less visibility into internal security events, but both cloud

options provide much better identity & access capabilities as well as better information protection

capabilities than the Department could realistically achieve with an on-premise solution.

Identity & Access 1: On Premise 2: Local Hosted Cloud 3: Public Cloud

Authentication

Access Control

Provisioning & Lifecycle Management

Audit & Logging

Management & Monitoring 1: On Premise 2: Local Hosted Cloud 3: Public Cloud

Configuration Management

Security Management & Monitoring

Service Management & Monitoring

Information Protection 1: On Premise 2: Local Hosted Cloud 3: Public Cloud

Encryption

Threat Management

Data Loss Prevention

Wo

rked

Exa

mp

le

119

Compliance Requirements

An assessment of compliance requirements covering in particular privacy, records, information

security and freedom-of-information was undertaken. This included a review of current compliance

practices, workshops with cloud service providers and a review of their draft contract terms.

Although a number of considerations were noted for consideration in contract negotiation and

detailed design, there were no areas of non-compliance identified. To emphasise in particular, this

assessment found the Department could implement the solution using an offshore public cloud

provider while in full compliance with our privacy and record-keeping regulatory requirements. The

practice of third party attestation of security in cloud service providers would help the Department

in meeting it’s information security compliance goals. The only area that may require attention is

around procurement practices as the conventional approach of tendering and fixed-price, fixed-

specification procurement will be problematic.

Compliance Area 1: On Premise 2: Local Hosted Cloud 3: Public Cloud

Records

Privacy

Information Security

Freedom-of-Information

Procurement

Risk Assessment

A risk assessment across strategic, operational, compliance and technical domains was performed

for each of the three alternative options. Risk events for which the exposure was determined to be

equivalent to or higher than the organisational tolerance are listed in the following table.

The key findings regarding risk can be summarised as:

The highest risk option is to undertake to develop the solution on premise. The

Department’s capacity to implement and monitor effective information security controls is

less than either the local hosted cloud or public cloud provider.

There is little appreciable risk differential between having the solution implemented on a

local hosted cloud versus a public cloud. The actual location of data only affects a small

number of risk events, such as interception between data centres and inadequacy of legal

privacy protections. Each of these risk events were assessed to be within the tolerance for

risk exposure.

A number of important risks were identified that highlight the need for rapid improvement

in the Department’s current practices regardless of the solution option chosen:

o Exploitation of customer gateway

o Exploitation of customer infrastructure

o Confused security responsibilities

Wo

rked

Exa

mp

le

120

Strategic Risk Events 1: On Premise 2: Local Hosted Cloud

3: Public Cloud

Risk Event Tolerance Impact Likelihood Exposure Likelihood Exposure Likelihood Exposure

S-Co-01: Cloud service data breach M 4 2 S 1 M 1 M

S-Av-01: Extended period of service disruption M 3 3 S 2 M 1 L

S-Cf-01: Unable to initially configure to fit M 3 4 H 2 M 2 M

Operational Risk Events 1: On Premise 2: Local Hosted Cloud

3: Public Cloud

Risk Event Tolerance Impact Likelihood Exposure Likelihood Exposure Likelihood Exposure

O-Ex-02: Unauthorised physical access M 3 3 S 2 M 1 L

O-Co-01: Malicious insider steals data M 3 2 M 2 M 2 M

O-Co-03: Accidental loss or theft of backups M 3 2 M 2 M 2 M

O-Tr-01: Confused security responsibilities M 3 2 M 3 S 4 H

O-Lt-01: Required capacity unavailable S 2 4 S 2 L 1 VL

O-Av-01: Network disruption S 3 3 S 3 S 3 S

O-Av-02: Downtime during business hours M 3 3 S 2 M 2 M

O-Cf-01: Lack of skilled resources M 2 4 S 2 VL 2 VL

Compliance Risk Events 1: On Premise 2: Local Hosted Cloud

3: Public Cloud

Risk Event Tolerance Impact Likelihood Exposure Likelihood Exposure Likelihood Exposure

C-Tr-01: 3rd party supplier compliance issues M 3 1 L 2 M 2 M

C-Tr-02: Failure to maintain adequate controls M 4 3 H 2 S 1 M

C-Pr-01: Insider accesses private data M 3 2 M 1 L 1 L

C-Pr-02: Inadequate privacy legal protections M 2 1 VL 1 VL 3 M

C-Pr-03: Cloud practices inadequate for privacy M 3 2 M 2 M 2 M

C-Pd-01: Change in cloud provider practices S 4 1 M 2 S 2 S

C-Po-01: Contractual restriction on portability M 2 1 VL 3 M 2 L

Technical Risk Events 1: On Premise 2: Local Hosted Cloud

3: Public Cloud

Risk Event Tolerance Impact Likelihood Exposure Likelihood Exposure Likelihood Exposure

T-Ex-02: Exploitation of customer gateway M 4 2 S 2 S 2 S

T-Ex-04: Exploitation of cloud operations M 3 3 S 2 M 2 M

T-Ex-05: Customer infrastructure exploited M 4 3 H 3 H 3 H

T-Co-01: Interception in transit to customer M 3 2 M 1 L 1 L

T-Co-03: Interception between data centres M 3 1 L 1 L 2 M

T-Co-04: Interception due to loss of encryption M 4 2 S 1 M 1 M

T-In-01: Backup failure S 2 3 M 1 VL 1 VL

Wo

rked

Exa

mp

le

121

Overall Assurance Assessment

An overall subjective assurance assessment was developed returning to the initial assurance

objectives laid out in the first stage of the evaluation. This assessment is subjective, combining all of

the inputs, discovery and findings throughout this evaluation process to provide a summary

assessment.

Objective Importance

Trustworthiness Minimal Extreme

Option 1 (on-premise) has been assessed as presenting a high risk of being unable to meet the confidentiality and exploitability assurance requirements. This is due to concerns about the ability of the Department to sufficiently secure internal systems against modern threats. However, the on-premise option offers greater transparency, privacy and predictability. Both of the cloud options are assessed to meet the assurance objectives.

Confidentiality

Integrity

Privacy

Transparency

Predictability

Exploitability

Resilience Minimal Extreme

The public cloud option achieves the highest rating in terms of resilience on all assurance criteria, closely followed by the local hosted cloud option. The on-premise deployment option achieves the lowest assurance rating in resilience. This is because the Department has significant gaps in business continuity practices and limitations in the amount of resilient infrastructure that can be implemented.

Preparedness

Responsiveness

Survivability

Durability

Availability

Load Tolerance

Adaptability Minimal Extreme

An on-premise implementation will provide the greatest level of adaptability because the Department can adapt the system in any way required. This adaptation will of course be at the cost of the Department. The public cloud solution can provide the next highest level of adaptability as the hosted cloud solution has less ability to be extended or substituted.

Portability

Configurability

Flexibility

Interoperability

Substitutability

Extensibility

Wo

rked

Exa

mp

le

122

Recommendation

The conclusion of this assurance evaluation is that Option 2 (Local Hosted Cloud) or Option 3 (Public

Cloud) can both adequately satisfy internal requirements, compliance requirements and risk

assessment. Either option is viable for the Department to proceed with, so selection may require a

consideration of cost and delivery.

The option of implementing the solution on-premise (Option 1) although fully satisfying compliance

requirements represented the least optimal fit to long term requirements and the highest overall

risk. The recommendation is not to proceed with Option 1.