assessing compliance & risk for cloud computing deployments · pdf fileassessing...

1Assessing compliance & risk for cloud computing deployments

Assessing compliance & risk for cloud computing deployments

Microsoft

A practical field book built on ISO 31000 for compliance assessment and risk-based decision-making in cloud computing.


Contents

03

0506

0707

0810

111216

1823

2528

3031343536

36 3739

4446

484950

Using this field book

IntroductionWhy use a risk approach for cloud selection?What is risk management?About ISO 31000

The five-step processExample: The ‘Human Services Agency’

Step 1: Establish the context What is the context?How HSA did it

Step 2: Define requirements How HSA did it

Step 3: Verify claims How HSA did it

Step 4: Analyse and treat risks Measuring riskCompleting the assessment Inputs sources for your assessment Agreeing on your organisation’s risk toleranceComparing options and treating risksHow HSA did itModel domain risks – a work list

Step 5: Review and decide How HSA did it

RecommendationHelpful linksDisclaimer


We have provided a short overview of risk management as an introduction to the topic and then laid out the five simple steps you will need to follow to evaluate and then decide between multiple cloud options.

To help you we have structured this field book as a set of five steps paired with a matching worked example snippet from our complete worked example.

This field book is for IT and non-IT individuals. No special training is needed and any competent business practitioner should be able to follow the process and achieve a decision.


Steps 1–5Step-by-step risk evaluationWe explain each step in the process with supporting guidance that explains what the process does, why it is needed and how you can apply it to your own analysis.

Worked exampleThe hypothetical case we use Each step ends with a separate call-out illustrating how the step was undertaken in our fully documented worked example – The ‘Human Services Agency’.


Introduction


Introduction

Why use a risk approach for cloud selection?

A huge diversity of cloud service providers exist today. This can be highly beneficial, enabling an organisation flexibility in securing the right combination of services to fit their needs. But each service will integrate differently, apply security differently, and operate under different terms of trade and privacy models.

Cloud computing can lift an organisation’s performance and lower costs, but it can also change the risk exposure of an organisation. They need to know which options are safe.

Their challenge is to perform reasonable due diligence in a way that enables direct comparison of alternative providers. And to do this assessment quickly and consistently, so that organisations can maintain their focus on delivering outcomes.

Risk is the chance of something happening that will affect an organisation’s objectives. Or, as it is described in the global ISO 31000 standard, risk is ‘the effect of uncertainty on objectives’.

This field book shows you how to perform an assessment of compliance and risk across various alternative cloud strategies. You can use it to build a preliminary business case for your organisation based on cost, value and risk.

We focus primarily on the risk dimension because many organisations understand the cost benefit analysis of cloud but struggle to perform formal risk analysis appropriate to cloud.

Cloud computing services can simultaneously introduce risks and mitigate or avoid risks your organisation already has, ranged across strategic, operational, compliance or technical areas. We have designed this field book to help you objectively identify, assess and treat risks so you can decide between alternative options and build a business case for your most appropriate needs.

We do not intend this field book and its accompanying tools to replace a comprehensive enterprise risk management practice. Rather, it supports decision making. For further details, please refer to the Risk Management best practice guidance in ISO 31000.

Figure 1. Cost–value–risk decision-making model

Cost what you

pay

Value what you receive

Risk the effect of uncertainty

on your objectives


Figure 2. Overview of ISO 31000 enterprise risk standard

Principles

Process

Lifecycle management

What is risk management?

Risk is the chance of something happening that will affect an organisation’s objectives.When an organisation considers cloud computing as an option for delivering services, existing risks may change and new ones may be introduced. This means that these potential changes in risk position need to be identified, and if necessary treated to an acceptable level.

ISO 31000 provides a widely accepted, standards-based approach that can be readily applied to decision making. It uses a straightforward set of steps to identify, analyse, evaluate and treat risks. Risk is determined by combining two drivers: ‘impact’ should the event occur and ‘likelihood’ that it will occur at all.

This field book adds two steps for identifying and addressing any compliance requirements ahead of a formal risk assessment process. Compliance with external regulations is usually not negotiable, so assurance of a particular option’s ability to conform is a vital gating decision.

About ISO 31000

The ISO 31000 Overall Enterprise Risk Management Standard has three main parts: principles, a risk lifecycle framework and a process for dealing with risk.

This field book develops the third part only, because it deals specifically with deciding between competing options.

This field book develops the ISO 31000 guidance further by drawing from the extensive methodology described in the Microsoft Security Assurance Framework for Evaluation Handbook and within this paper.

We illustrate each step with a simplified example from the corresponding step in the case study. The Handbook and full study is provided in detail at www.microsoft.com/government/cloudassessment

Introduction


The five-step process


3

Verify Claims

4

Analyse Risks

5

Review & DecideThe final step is to combine all of the previous inputs to provide an executive recommendation on whether the organisation should proceed.

Stage three is about verifying that the cloud service can satisfy requirements by reviewing a combination of documentation, contracts and independent verifications.

There will always be some unknowns, so the fourth stage is about performing a holistic risk assessment considering impacts of a strategic, operational, compliance or technical risk event.

1

Establish Context

2

Define RequirementsThe second stage is about defining internal and external requirements. External requirements are often compliance obligations from legislation, regulators, etc. Internal requirements come from security policies or existing practices.

Firstly, the organisation develops a clear understanding of direction, benefits and options, along with a shared view of the political, organisational, social and technological context in which the organisation operates.

We use the following five steps to address compliance requirements and evaluate risk for a cloud-services candidate.

The five-step process


Introducing the worked example we use: The ‘Human Services Agency’

This field book provides illustrative examples at the end of each step of how one hypothetical agency – the Human Services Agency – performed each step.

HSA’s planning process has confirmed that there is a growing trend for citizen services to be delivered in the community or by not-for-profit organisations rather than the government directly – with the agency providing a direction, support and governance role. This would challenge the agency’s existing systems, which were built for a more static, vertically integrated role. HSA also needs to improve teamwork and cross-organisation information sharing, and be able to serve clients while mobile in the community.

Improved messaging and collaboration tools have been identified as technology prerequisites, but the agency’s current capability is outdated, inflexible and cannot deal with mobile scenarios. Investigation suggests a cloud-based solution should be considered but the comparative risks are unknown because no staff members have used cloud services.


Step 1

Establishing context

1 32 4 5


1 32 4 5

Once this is clear, it becomes much easier to identify options and assess the compliance requirements and risks that accompany them. At a minimum, you should confirm the overarching business benefit central to the project, what capabilities are needed to realise it, and what kinds of technology enablement this will translate into.

The following table indicates some of the questions your organisation might consider to elicit the business benefit central to the project, what capabilities are needed to realise those benefits, and what technologies can underpin these capabilities.

What is the context?

When framing your decision making around cost–value–risk dimensions outlined in Figure 1, the first thing that must be agreed is the business value you want to gain and why you want it.


Determining your options

Why are you doing this?

1 32 4 5

There are often multiple ways to achieve the desired strategic outcome, and the purpose of assessment is to help make a choice between these options.

The following questions can help to develop a short-list of viable alternatives.

Figure 3. Establish the context

What are the major business benefits you are trying to secure and how do they align with your overall strategy?

What are the new business level capabilities sought to support these benefits and how are these capabilities integrated?

What are the technology tools important to delivering these business capabilities?

Business benefits

Business capabilities

Technologies

What are the specific functional requirements at technology level and are these able to be stack ranked in order of importance?

How is this currently operated, delivered and accessed by the organisation and where are any gaps?

What are the broad alternatives and their delivery and consumption models – i.e. ‘self-hosted’, private, public or hybrid cloud? These will form the targets for your analysis.

Required functionality

Current state

Delivery models

Figure 4. Determining your options


1 32 4 5

A clear understanding the organisation’s internal and external 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 includes 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. 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. It can become an exhaustive task to catalogue all factors, but the following questions can be used to isolate those considerations that directly impact a cloud strategy.

With a better understanding of the range of options, you can define the context in which this proposed project would exist.


Are there community expectations or concerns about areas such as duty of care or information use?

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

Are there any organisational data classifications to be adhered to?

Figure 5.

Figure 6.

1 32 4 5

Your context

Your context

Are there views, positions or considerations of any external stakeholders that need consideration?

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

Are there regulatory obligations, such as prudential regulatory requirements, for the finance industry?

What resource limitations exist?

Are you bound by any specific security assurance requirements or policies?

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

What legislative or regulatory changes are foreshadowed?

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

Must you comply with any cross-border laws or regulations or requirements?

What technology platforms are deployed within the organisation?

External

Internal


1 32 4 5

How HSA did it

Case Study: Example business benefits sought at HSA

Client service

Business area

• Reduced time on administrative tasks

• Improved service coordination

• Infrastructure cost reduction

Efficiency benefit

• Mobile access to client information

• Improved communications

Effectiveness benefit

• Improved client satisfaction

• Improved coverage of disadvantaged groups

Performance benefit

The following three options were considered viable to explore:

1. Migrate to an on-premises modern platform for collaboration and communication, owned and operated by the Agency, 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 Agency.

2. Migrate to a dedicated cloud provider service hosted in a local data centre and also deploy modern devices. This is expected to be lower cost than on-premises deployment.

3. Migrate to a public cloud service hosted offshore, accessed through deployed modern devices. This is expected to be the least costly option, but there is concern as to whether it introduces data sovereignty and other risks.

Case Study: Options at HSA

The following is a snapshot taken from the separate worked example available at www.microsoft.com/government/cloudassessment


How HSA did it continued

Case Study: Internal context at HSA

1 32 4 5

Case Study: External context at HSA

Major restructure is ongoing, with significant numbers of staff being redeployed or retrained as part of the transformation program.

Extensive regulatory requirements for the handling of private information including the Privacy Act along with government requirements for records management and security.

Current technology platform is out of date, primarily consisting of desktop computing. Very few mobile or remote working capabilities exist.

Community and stakeholder expectation of greater engagement between the Agency and community groups, including stronger presence in the community.

Generally, working practices are designed for handling sensitive, private information.

Political commitment to increase the number of personnel available for in-the-community and in-the-home support.


Step 2

Define requirements

2 31 4 5


2 31 4 5

This step is all about understanding constraints imposed by external compliance obligations or internal policy or technical requirements. Many private sector and government organisations need to comply with government or sector-specific information security, privacy, records and data protection requirements.

They may also have specific legislative requirements, with examples including health information privacy, payment card data protection or even national security information.

You can only really determine your specific compliance obligations yourself, but the following broad categories generally need to be considered.


PrivacyMost organisations have privacy of customer data compliance obligations. These may embrace not only general personal information but also sensitive information such as credit reporting or medical data. Some organisations may face additional requirements around employee privacy. These obligations need to be addressed either through contractual measures or capabilities of the service or device.

Records and auditRegulated enterprises and government organisations generally have specific obligations for formalised record keeping and audit. These can also include freedom of information and law enforcement information requirements.

Security assurancePublic 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. Payment Card Industry Data Security Standard (PCIDSS) is one example of possible private sector compliance requirement.

The source the origin of the compliance requirement

The authority who’s responsible for the compliance within your organisation

Specific requirements what practice is explicitly required

Your current practices how your organisation currently does or does not comply

Verification requirements how compliance with these requirements needs to be demonstrated

For each external compliance requirement, it is important to capture some key information, including:

2 31 4 5


Your organisation may also have internal requirements. For example, it is likely that the end-to-end solution will require integration with existing infrastructure and therefore need to align with the organisation’s existing information security management, deployment, management and monitoring capabilities.

Mapping these internal security functional requirements will ensure risk is addressed appropriately for current and future architectures.

Figure 7.

2 31 4 5

Privacy

Records and audit

Security assurance

What legislation, regulations or codes of conduct exist for the protection of private data?

What legislation, regulations or codes of conduct exist for the maintenance of records and audit materials?

What standards or formal assurance mechanisms exist for the security of information?

What restrictions exist on the appropriate collection and use of private data, to notify individuals about privacy and seek their consent?

Are there specific requirements for information backup, recovery, handling, retention, deletion or destruction?

Are particular forms of independent verification, such as ISO 27001 certification or SSAE16 attestation reports, recognised?

Are there specific restrictions on the transfer of data out of the country?

Are there specific requirements for production of records on request?

Is any information being processed of a highly sensitive classification, and therefore in need of special protection?

Typical external (compliance) obligations


How will users need to authenticate their identity to the service?

How does the organisation manage changes and release of new capabilities to users?

What standards and practices exist for protection of information through classifications, policy and encryption?

How is access controlled across systems and data in the organisation?

How does the organisation currently maintain oversight and visibility of security events?

How does the organisation implement threat detection and management?

Is there an established process for managing the lifecycle of identity?

How does the organisation monitor and manage availability of services?

Does the organisation enforce data loss prevention policies and tools?

How does access need to be audited and logged?

Identity and access

Management and monitoring

Information protection

Typical internal obligations

Figure 8.

2 31 4 5


How HSA did it

Case Study: External (compliance) requirements at HSA


Area Specifics

Privacy

Records and audit

• 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 and unauthorised access must be in place

• Ownership of data must remain with the public office on termination of the service.

• The Agency 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

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

2 31 4 5


Area Specifics

Identity and access

Management and monitoring

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

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

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

• 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 Agency requires every user login event to be logged and auditable.

• The Agency 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 Agency should be able to configure and view reports of system access, malware detections or other security events

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

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

Case Study: Internal requirements at HSA


2 31 4 5


Step 3

Verify claims

321 4 5


321 4 5

Each cloud service provider, application developer and device manufacturer makes claims about the security of their product or service, and mechanisms exist to validate those claims. These include:

Formal evaluationwithin international or national information assurance schemes such as Common Criteria or the US Federal Information Processing Standards (FIPS). These are generally only appropriate for devices and packaged software and currently have limited relevance to cloud solutions.

Third-party certification and accreditation which generally requires audit and validation that the information security practices conform to a particular standard, such as ISO 27001, or are demonstrated to be effective with regard to a set of principles, such as SSAE16 SOC 2 Trust Principles. Other less formal schemes such as the Cloud Security Alliance (CSA) Registry can provide a common baseline for the definition of cloud security capabilities, but these schemes may not incorporate third-party validation.

Contract reviews can be very effective, particularly in relation to service level agreements, service descriptions and security contracts. One particular example is a data processing agreement which builds on a set of standard contractual clauses developed in the European Union for private data protection.

Technical documentation reviews Cloud service providers need to take due care their documentation provides an accurate representation. Although not a formal attestation, technical documentation can often be more up to date and easily understood than audit or contract terminology.

In this step, we evaluate whether the proposed cloud solution(s) can meet the internal functional and external compliance requirements identified in Step 2.


We now need to validate the requirements identified in Step 2 to verify whether the proposed cloud solution can meet those obligations, using one of the these forms of assurance claim.

For example, complying with a particular government information assurance requirement might involve the organisation completing an accreditation process across the end-to-end solution. It may also mean procuring the service from an approved panel of evaluated suppliers, or it might simply be a process of ensuring certain contractual protections are in place.

This mapping exercise is shown in Figure 9.

Figure 9. Mapping compliance to verification

Your compliance requirements

How you will verify them

Requirement

Claim

Privacy complianceSecurity compliance

ISO 27001

Contract term

Data processing agreement

?

GapSSAE16

321 4 5


321 4 5

How HSA did it

Summary verification of each solution alternative Case Study: Verifying external (compliance) requirements


Privacy

Records

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

The department must assess and address the risks involved in taking and sending records out of the state

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

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 ISO 27001 audit report

and SSAE16 SOC 2 attestations, demonstrate the cloud service provider has an extensive range of data security controls in place

Compliance Requirement

Option 1: On premises

Option 2: Local hosted cloud

Option 3: Public cloud


Legend

Fully conforms to requirement

Conforms with some additional contractual, process or technical changes

Partial conformance to requirement

Does not conform to requirement

Case Study: Internal requirements at HSA


321 4 5

Records

Security Assurance

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

Review of the standard contract

includes specific terms for the preservation of records

Standard contract includes specific

terms for the preservation of records for up to 120 days

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

The Agency inconsistently

implements a range of security controls


documentation provided, the cloud host does implement the mandatory controls

Verified through review of the ISO

27001 audit

The Agency must have in place an Information Security Management System (ISMS) based on the application of ISO 31000 and ISO 27001

The department’s ISMS is not

currently based on ISO 27001 or certified in any way


documentation provided, the ISMS of the cloud host is derived from ISO 27001 and ISO 31000

The ISMS of the cloud host

is derived from ISO 27001 and they use ISO 31000 for security risk management

Compliance Requirement

Option 1: On premises

Option 2: Local hosted cloud

Option 3: Public cloud


Step 4

Do risk assessment

421 3 5

421 3 5

Now you have established a clear view of the context and assessed how compliance requirements can be addressed, the next step is to analyse the comparative risks of each of your solution options.

To be useful, the risk analysis needs to address risks across the organisation as a whole and a common way to do this is by using what is known as a ‘domain-based’ approach.

This approach attempts to identify the risks associated with the proposed solution as they manifest in each of a number of domains in your organisation. These include risks that can be strategic, operational, compliance or technical in nature.

Strategic risks are those that can impact the organisation’s ability to fulfil its 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.

Technical risks limit the technology choices of the organisation or prevent it from achieving best value from technology implementations.

To help streamline the risk assessment we suggest identifying only the most important risks in areas of trustworthiness, resilience and adaptability.

Approximately 50 of the most commonly assessed risks are catalogued in the accompanying spreadsheet template, but the organisation may choose to add or remove risks based on its unique situation. They are spread across each of the domain and impact areas as shown in Figure 10.


Measuring risk

Strategic

Operational

Compliance

Technical

Resilience

Major disruption

Unpredictable downtime

Inadequate disaster preparedness

Cascading failure

Trustworthiness

Large data breach

Confused responsibilities

Inappropriate business practices

Loss of encryption keys

Adaptability

Inflexible to strategic business needs

Downtime for configuration changes

Unable to comply with new regulations

Incompatible tools

Figure 10. Example risk events

This first step is to define how you will measure risk. The most common way to do this involves using a graduated scale of ‘likelihood’ that an event will occur and a separate scale of ‘impact’ that would be suffered, and then multiplying these together to arrive at a resultant ‘exposure’.

This reflects the overall projected effect of the particular risk on the ability of the organisation to achieve business objectives. Figure 11 describes one example of a sliding scale for likelihood, impact and the resultant exposure.

421 3 5


Catastrophic

Major

Moderate

Minor

Minimal

Impact

S

M

L

VL

VL

Rare

Unlikely

Possible

Likley

Alm

ost certain

H

S

M

L

VL

VH

H

S

M

L

E

VH

H

S

M

E

E

VH

H

S

Extreme

Very high

High

Significant

Medium

Low

Very low

Probability

421 3 5

Figure 11. Impact, likelihood and exposure scales

Impact Likelihood

Catastrophic Almost certain

Major Likely

Moderate Possible

Minor Unlikely

Minimal Rare

· ‘Extremely negative coverage’, or· ‘Unable to satisfy critical objectives’

· ‘Happens often’, or· ‘Could occur within days or weeks’

· ‘Persistent negative coverage’, or· ‘Unable to achieve a core objective’

· ‘Could easily happen’, or· ‘Could occur in weeks or months’

· ‘Negative coverage for a few days’, or · ‘Significant inefficiencies and loss’

· ‘Could happen, maybe has before’, or · ‘Could occur in a year or so’

· ‘Minor, transient negative coverage’, or · ‘Inefficiencies somewhat recoverable’

· ‘Never yet happened but might’, or· ‘Could occur in 10 years or so’

· ‘Isolated, brief coverage’, or· ‘Slight inefficiencies’

· ‘Maybe in extreme circumstances’, or · ‘A 100 year event’

Illustrative criteria Illustrative criteria


This approach is then applied to each identified risk area across all the relevant domains in your organisation and the output is seen in Figure 12.

You are now ready to work through each of the domains and complete the risk assessments within them. To help, we have provided a separate set of templates in Excel, complete with automated menus and formulas for calculating risk exposures and formatting colours accordingly in a summary sheet.

This can be downloaded from www.microsoft.com/government/cloudassessment. The following pages in this paper provide an abbreviated version.

However, we’d recommend you don’t limit yourself to this template. Some risks are very specific to certain industries, cultures and geographies.

Figure 12. An example risk rating for one risk event

Completing the assessment

421 3 5

On-premises email Cloud email

ToleranceDomain Risk Impact ImpactProbability Probability

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

Possible Moderate Moderate

Significant Low

Rare

Exposure

ConfidentialityStrategic

Exposure


Input sources for your assessment

Rating risk is inherently subjective, although a structured process such as this helps provide discipline. If you employ a good range of relevant input sources this will greatly improve the quality of your assessment. The following are some basic suggestions:

Quantitative information Use relevant quantitative information such as logs, monitoring, reports, audit and previous incidents to rate the risk, and report as a comment alongside the risk rating

Qualitative information Use qualitative information, mostly derived from the cumulative experience of the stakeholders to rate the risk

Validate internally Conduct internal validation across different business and technical groups

Validate externally Use external sources such as analysts, industry groups and even other organisations’ experience and expertise to help you.

421 3 5


Your options for addressing risk

Ultimately, reasonable risk treatment strategies should be incorporated into the final analysis, along with any additional costs or restrictions associated with them.

Figure 13. Your options for addressing risk

421 3 5

Agreeing on your organisation’s risk tolerance

For these results to be useful, you also need to establish your risk tolerance – the risk your organisation is willing to accept for 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 for that risk, then the risk needs to be mitigated. If the risk is assessed to be lower than the tolerance, then it is acceptable.

Identifying risk events for which the risk exposure is greater than the risk tolerance is an important part of this assessment. In these cases, the organisation may investigate possibilities to treat these risks. Four options are available to manage risk: accept, reduce, transfer or avoid the risk.

Comparing options and treating risks

Determine whether the organisation can tolerate the risk introduced by the cloud solution. Must compare enterprise risk tolerance to solution risk profile

Follow mitigation strategies and Enterprise Risk Management (ERM) practices to reduce the probability and impact of risks. Plan for failures such as the recent Amazon outage

Cloud insurance is an emerging field that enables risk transfer to a third-party. Alternatively, warranties and SLAs can be used to transfer the risk to the cloud provider

Choose not to adopt the cloud solution and avoid the risks introduced by initial cloud solution

Accept

Reduce

Transfer

Avoid


421 3 5

How HSA did it

Figure 14 represents just a few of the many potential risks you may consider across each domain, and is drawn from our fully worked example available separately online.


Strategic risk events

Risk Event

1: On premises 2: Local hosted cloud 3: Public cloud

4

3

2

Impact

S

S

L

Exposure Exposure Exposure

M

M

L

M

L

L

M

M

S

Tolerance

2

3

2

Likelihood Likelihood Likelihood

1

2

2

1

1

3

Cloud service data breach

Extended period of service disruption

Non-portability of data on termination

Operational risk events

Risk Event

2

2

3

Impact

M

S

S


L

VL

M

L

VL

L

H

M

M

Tolerance

3

4

3


2

2

2

2

2

1

Network congestion

Unauthorised physical access

Lack of skilled resources


Figure 14. Potential risk events (strategic, operational, compliance and technical)


421 3 5

Figure 14. Potential risk events (strategic, operational, compliance and technical)

Technical risk events

Risk Event

2

2

1

Impact

VL

VL

VL


L

VL

VL

VL

VL

L

S

H

H

Tolerance

1

1

1


2

1

2

1

1

3

Isolation failure between tenants

Cascading failure in cloud

Failed integration of security systems


Compliance risk events

Risk Event

2

2

2

Impact

M

VL

M


L

M

M

VL

L

M

H

M

S

Tolerance

3

1

3


2

3

3

1

2

3C-Co-02: Leakage of sensitive data into cloud

C-Pp-01: Insufficient disaster preparedness

C-Po-01: Contractual restriction on portability




421 3 5

Model domain risks – a work list

We provide the following list of the most common risks that organisations are likely to consider, grouped by domain. Use these as a manual checklist as you move through your own risk analysis.


421 3 5


Option 1 Option 2


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

Exposure

TrustworthinessStrategic

Exposure

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

Exposure


Exposure

Service inflexibility: Security or other requirements of the customer organisation change, but the cloud service is inflexible to accommodate these changes

Exposure

AdaptabilityStrategic

Exposure

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

Exposure


Exposure

Non-portability of data: 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

Exposure


Exposure

Termination by service provider: Termination of service by the service provider due to acquisition or market circumstances

Exposure


Exposure

Inability to initially configure to fit: The application or service cannot be configured initially to satisfy the business requirements of the customer organisation

Exposure


Exposure

Extended period of service disruption: The service fails and is unable to be restored to operation in a reasonable time, causing significant lost revenue, lost customers or brand damage

Exposure


Exposure


421 3 5


Option 1 Option 2


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

Exposure


Exposure

Unauthorised physical access: Access by an external attacker to premises, data or systems

Exposure


Exposure

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

Exposure


Exposure

Downtime during business hours: The cloud service is unavailable during periods of business operation

Exposure


Exposure

Malicious insider steals data: Malicious insider within the cloud provider abusing high privilege access to customer data

Exposure


Exposure

Network congestion: The network between the cloud service provider and the customer organisation endpoint is congested or exhibits highly variable quality of service

Exposure


Exposure

Damage to logs: Loss or compromise of operational or security logs

Exposure


Exposure

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

Exposure


Exposure

Lawful confiscation of equipment: If a lawful subpoena on another tenant leads to physical confiscation of hardware, then data of the customer organisation might also be disclosed

Exposure


Exposure

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

Exposure


Exposure

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

Exposure


Exposure

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

Exposure


Exposure

Accidental loss or theft of backups: Backup media being lost

Exposure


Exposure

Network disruption: The network between the cloud service provider and the customer organisation endpoint is disrupted

Exposure


Exposure


421 3 5


Option 1 Option 2


Lawful warrant compelling disclosure: Lawful warrant or subpoena process directed to the cloud service provider, compelling the disclosure of customer data

Exposure


Exposure

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

Exposure


Exposure

Change in cloud provider practices: Cloud service provider may operate in a jurisdiction that provides inconsistent legal protections for privacy

Exposure


Exposure

Third-party supplier compliance issues: Inadequate practices of a third-party supplier to the service provider lead to customer organisation non-compliance

Exposure


Exposure

Insufficient disaster preparedness: Service provider business continuity preparedness is insufficient to satisfy regulatory requirements

Exposure


Exposure

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

Exposure


Exposure

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

Exposure


Exposure

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

Exposure


Exposure

Unable to respond to legal discovery: Cloud service provider is unable to provide information required by the customer to respond to a subpoena or warrant

Exposure


Exposure

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

Exposure


Exposure

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

Exposure


Exposure


421 3 5


Option 1 Option 2


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

Exposure


Exposure

Exploitation of customer gateway: The communications gateway between the cloud service provider and the customer organisation is exploited

Exposure


Exposure

Interception in transit to customer: Interception of data in transit between customer endpoint and service provider

Exposure


Exposure

Failed integration in security systems: Existing or future security management and monitoring tools used by the customer are incompatible with cloud service provider systems

Exposure


Exposure

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

Exposure


Exposure

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

Exposure


Exposure

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

Exposure


Exposure

Exploitation of cloud operations: Exploitation of cloud Service provider administrative infrastructure leading to an attacker gaining access to customer data

Exposure


Exposure

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

Exposure


Exposure

Interception between data centres: Interception of customer data in transit between service provider data centres

Exposure


Exposure

Customer infrastructure exploited: Customer data held within the cloud application is lost due to exploitation of the Customer organisation infrastructure

Exposure


Exposure

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

Exposure


Exposure


Step 5

Decide and plan

521 43


521 43

The final step is to combine all inputs and the outcomes of compliance and risk assessments to develop an executive recommendation for the business.

This recommendation should reflect the strategic direction, benefits and context mapped out at the beginning of the process and support a non-technical executive decision to be made between multiple alternative options. The risk colour coding acts as a useful ‘dashboard’ indication in this regard.

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 and access, information protection, and management and monitoring. It aims to answer the question:

Which of the alternatives best delivers the capabilities our organisation requires, mindful of our needs and context?

The second part is a compliance assessment covering privacy, records, information security and other externally imposed compliance requirements. This section addresses the important 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 five risk events are also described, possibly along with guidance for their treatment.


521 43

Using traffic lights to present risk analysis in an accessible way helps you to communicate findings with broader business stakeholders.

How HSA did it


Compliance area

Records

Information security

Privacy

Freedom of information

Procurement



Risk Event


Impact Exposure Exposure ExposureTolerance Likelihood Likelihood Likelihood

4

3

3

S

H

S

M

M

M

M

M

L

M

M

M

2

4

3

1

2

2

1

2

1

Cloud service data breach

Extended period of service disruption

Unable to initially configure to fit


521 43



Risk Event Impact Exposure Exposure ExposureTolerance Likelihood Likelihood Likelihood


2

3

3

3

S

M

S

S

VL

S

M

M

VL

H

M

L

M

M

M

M

4

2

3

3

2

3

2

2

2

4

2

1O-Ex-02: Unauthorised physical access

O-Tr-01: Confused security responsibilities

O-Av-02: Downtime during business hours

O-Cf-01: Lack of skilled resources







4 H S MM 3 2 1C-Tr-02: Failure to maintain adequate controls

4

3

4

4

S

S

H

S

M

M

H

S

M

M

H

S

M

M

M

M

2

3

3

2

1

2

3

2

1

2

3

2

T-Co-04: Interception due to loss of encryption

T-Ex-05: Customer infrastructure exploited

T-Ex-02: Exploitation of customer gateway

T-Ex-04: Exploitation of cloud operations


Recommendation

Our findings are that Option 2 (local hosted cloud) or Option 3 (public cloud) can both adequately satisfy internal requirements, compliance requirements and risk assessments. Either option is viable for the department to proceed with, so selection may require a consideration of cost and delivery.

Implementing the solution on-premises (Option 1) while satisfying most 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.


Helpful Links

The Office 365 Trust Centre http://office.microsoft.com/en-us/business/office-365-trust-center-cloud

Microsoft Azure Trust Centre http://azure.microsoft.com/en-us/support/trust-center/

Microsoft Dynamics CRM Trust Centre www.microsoft.com/en-in/dynamics/crm-trust-center.aspx


This document has been prepared by Microsoft to provide a risk-management framework to allow organisations to conduct a risk-based assessment of a move to the cloud.

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 of 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.

© Microsoft

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 3.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

Disclaimer

assessing compliance & risk for cloud computing deployments · pdf fileassessing...

Documents