Managing cloud services risk throughout a supplier lifecycle relationship

Managing cloud services risk throughout

a supplier lifecycle relationship

By Mark Becker, Senior security consultant, BT and

Bryan Fite, Security portfolio manager, BT

Introduction

Cloud services have proliferated. New, virtual services and repositioned hosted services deliver the agility and pay-for-use objectives cloud proponents expect. Project teams and organizational units have found the cloud to be a highly responsive option to immediate needs.

While the cloud as a service delivery model has made substantive advances in the past two years, companion risk and governance models have not matured at a similar rate. Risk Management and Information Security teams should be concerned. Who has the responsibility to provide a sustainable management and governance infrastructure that minimizes business risk? Who will assure that compliance, privacy and long-term service continuity controls are adequate? Who will guarantee that the level of trust extended to a service provider is warranted?

In an ideal world, the tactics used to engage a Cloud Services Provider (CSP) would be commensurate with the level of risk to which the enterprise is exposed. The tactics to establish whether the CSP is worthy of trust, the scope of technical control to mitigate threats, and the quality management governance model would be dictated by a simple to use and easily-understood risk management framework.

Managing cloud services risk throughout a supplier lifecycle relationship 3

Today, the focus is on the service outcome

BT provides network consulting services for which the cloud is often a delivery option. We have noticed that many cloud programs are directed at a specific problem that can be solved by a widget or service provided by a CSP. The good news is that if the widget fits, the result is generally of high quality. The bad news is, far too often there is very little: 1) Oversight of the CSP relationship,

2) Data protection, 3) Operational and business continuity assurance, and / or 4) Integrated change management.

While not as egregious as buying a “Rolex” watch from a New York street vendor, there are similarities: the watch does tell the time, for a while anyway, the credentials of the supplier are assumed adequate, and the purchase comes with no warranty. Urgency, responsiveness and the short-term nature of the vendor relationship are the justification for risk management shortcuts.

Reality check – CSP selection is risky business

The more sensitive the data and / or the more critical

the process, the more important supplier selection tactics and trust management become to the success of the relationship and the value it provides. A successful relationship will be grounded in a shared understanding of accountabilities and expectations. The choice will not be solely whether someone else can provide a service within desired cost and time parameters. Rather, the choice will confirm that they will do it with the same care you provide when doing it yourself as well. As the relationship develops from prospect to partner, risk mitigation must change from assessment to in-life control. The focal point must change from ‘me’ to ‘we’.

Figure 1 looks at the various stages of a provider

relationship lifecycle. At each point, a share of the activity should include risk management activities.

• Define use case must declare the relative risk associated with data sensitivity and process criticality - the service is to support.

• Qualify CSP must build trust based on a verification that the service provider provides adequate security controls for the use case, the business benefits, and the cost of entry.

• Define service should summarize the human and security controls aligned with use case risk, document the technical and process integration with the CSP, and provide the quality control framework to manage the in-life operation.

• Contract for service must include the terms under which the use case and service are managed to contain risk including SLAs, roles/responsibilities, and terms that could be invoked upon service failure such as information disclosure and service interruption.

• Manage in-life service includes the required level of joint management and control.

• Terminate service is the unavoidable but mutually agreed end of the relationship.

Figure 1: Cloud Services Relationship Lifecycle

CSP Relationship

Lifecycle

Define use case

Quality CSP

Define service Contact for service

Manage in-life service Terminate

Fill a need, not buy a service

The crux of the relationship is the use case for which a service is to be provided. A use case describes the business operation, process and data flow, technical services, support requirements, and its risk management requirements in terms of data sensitivity and process criticality. The use case is the risk filter for the

development of the relationship. The greater the risk, the more judicious the CSP selection, the more complete the service description, the more protective the contract, and the more rigorous in-life management becomes. Figures 2 offers instances of triggered / materialized risk in the context of sensitivity and criticality. Data and process examples by risk level (low, medium, high) are found in Figure 3.

Each enterprise should standardize how data and processes are to be categorized with respect to risk. The standard should be grounded on the impact on the enterprise rather than the impact on a team or project. At one extreme, it is tempting to claim that ‘my data’ does not require protection, or that ‘my process’ is the most important work the business does. It would benefit all organizational units and project teams if the Risk Management group defined the risk levels associated with data categories and process criticality to assure alignment with corporate confidentiality and business continuity objectives.

Figure 2: Triggered Risks

Figure 3: Data and Process Examples

CSP qualification is an exercise in trust management

CSP qualification is the starting point for building trust.

Clearly, mission-critical transaction processing or the ‘secret sauce’ that is your marketplace differentiation requires a different level of trust and assurance than does a conferencing service. The greater the processing dependence on the CSP and / or the privacy of the data the CSP retains, the greater the potential risk and the more substantial the level of required due diligence. Ultimately, a qualified CSP infers that you trust the supplier will provide a level of protection and quality of service no worse than you demand of yourself given the data sensitivity and process criticality.

The scope of due diligence should include:

• Data privacy, access control and leakage prevention.

• Perimeter controls including access link, intrusion prevention.

• Desktop controls to preclude malicious code introduction.

• Isolation from other clients to assure processing performance and data confidentiality.

• Hypervisor standards and virtual image protection.

• Log collection, management and analysis.

• Physical and environmental controls.

• System development practices.

Data Sensitivity H

M

L

Privacy regulation violation Lost strategic advantage Fines for OID leakage Eroded competitiveness Brand damage

Regulatory compliance fines Adverse impact on image / reputation Process Criticality L M H Reproduction cost Recovery cost Lost revenue / sales Eroded customer confidence Recovery from mission critical outage

Lost market share

Data Sensitivity H

M

L

External personally identifiable data Strategic planning content Stock-price-affecting content Audit findings

Need to know (business plans, password, system logs, legal) Customer data / transactions Employee information Publically available content Unrestricted internal (intranet, briefings, policies)

Use case / Process Criticality L M H Training Storage Conferencing Public sites

Web presence for commerce Virtual data center Hosted security

Hosted processes (call center, BPOS) Disaster recovery

Managing cloud services risk throughout a supplier lifecycle relationship 5

Service design clarifies the operational control baseline

• Security requirements and controls that in combination harden the environment.

• Operational quality controls such as monitoring.

• ITSM integration for service catalogues,

technology introduction, change management and incident management.

• Human resource requirements and controls such as selection/vetting, duty separation, social engineering prevention and personal responsibility programs, and training.

• In-life management practices.

• Service activation and termination processes.

The service must be designed and implemented in a manner that can be sustained. The focal point is a service design that is as complete as the use case demands. When the data sensitivity and/or process criticality require, the service design should have agreed descriptions of all of the services and controls required to assure quality and mitigate threats.

With a depth appropriate for the use case risk, the service design should address:

• Technical integration for seamless and secure communications.

• Process integration including declared handoffs between entities.

Contracting sets the relationship tone

Just as fences make good neighbours, contracts make

good partners. While the service design describes how the integrated operations are to behave, the contract confirms responsibility should operational stability be lost. As the level of risk increases, so do the scope and the specificity of the contract.

The contract may include:

• SLAs and associated reporting for each service.

• Quality/audit/legal/regulatory expectations for data confidentiality/privacy, regulatory reporting, audit, and system compliance with regulatory requirements.

• Specific terms and potentially monetary recovery for contract failures such as recurring SLAs, confidentiality/non-disclosure, reputational loss, Intellectual Property, and limitation of liability/indemnity.

• Applicability of terms to federated CSPs.

• Delineation of client and CSP roles/responsibilities such as service changes and steady state

monitoring/administration.

• Joint management/governance requirements.

• Escrow agreement for critical software.

Once the service becomes operational, it is tempting to fall back to a business-as-usual mindset. However, data sensitivity and/or process criticality may demand a high degree of on-going vigilance to sustain long-term quality. High and even moderate risk use cases demand that in-life governance controls be compatible and shared.

The greater the risk and/or longer the term of the relationship, the more proactive managerial oversight must become, including: • Policy alignment.

• Joint governance and oversight teams that meet regularly.

• Integrated emergency response and forensic services.

• Joint quality programs underpinned with robust

dashboard/reporting, rigorous risk-based self-assessment process, and coordinated improvement program.

• Joint audit/remediation controls based upon shared control points and their metrics aligned with SLAs.

• Joint DR/BCP and capacity management.

In-life management keeps the

focus on quality (and ensures

accountability)

Managing cloud services risk throughout a supplier lifecycle relationship 7

Future, scaled CSP relationships

If we are to manage our CSP relationships more effectively, we need an assessment framework that responds to use case risk. The framework will guide a ‘relationship management plan’ defined by the CSP Relationship Lifecycle. Figure 4 is such a framework. The data sensitivity and process criticality define a cell in the model which is the starting point for the analysis of the level of trust, control and governance the relationship demands.

Figure 4: Risk-based CSP relationship requirements

Application of this framework is a two-step process: 1. Define the cell represented by the data sensitivity and

process criticality of the use case.

2. Include all calls within the ‘shadow’ of the use case cell. The shadow of a use case covers all cells to the right and below the use case cell. See Figure 5 for some examples.

The framework has advantages for both project teams and Risk Management.

• Multiple suppliers can be introduced to the

organization based upon need, provider capabilities and consistent enterprise requirements.

Figure 5: Framework applicability given use case

• The development of each CSP relationship will assess and manage risk to an appropriate level based upon the data and process characteristics of the use case.

• Relationships will emerge in the context of a lifecycle, not a specific and immediate project need.

• The effort to create a relationship will be scaled to the impact on the enterprise.

• Organizational units and project teams will be freed to quickly engage niche CSPs whenever the data and process represent low risk to the enterprise.

Monetary recovery for contact failure Integrated security Due diligence for data privacy / leak Contract extends to federated CSPs

ITSM integration VM / hypervisor

Due diligence for security / risk / regulatory

Due diligence for HR / admin access Due diligence for federated CSPs

Comprehensive service design Joint governance / change control Due diligence for ops / DR / BCP / physical / IDP tools

Joint DP /DCP Joint CSIP Joint audit In-house backup copy Internal governance CSP restoration process Contractual SLA / terms

Due diligence for SDLC Joint restoration process CSP quality reporting Data Sensitivity High Medium Low Process Criticality High Medium Low

High High High High

High Medium Low Process Criticality Data Sensitivity High Medium Low Process Criticality Data Sensitivity High Medium Low Process Criticality Data Sensitivity Medium Low Medium Low Medium Low High Medium Low Process Criticality Data Sensitivity Medium Low Use Case Shadow Use

Extending the framework to common cloud services

The range of cloud services is on the rise. It would be

especially useful if service categorization can be linked to risk. Two categorizations may be helpful:

Delivery model – type of service available on a pay-for-use basis:

• Infrastructure as a Service (IaaS): Computing power, storage, and networking infrastructure.

• Platform as a Service (PaaS): Runtime environment for client-provided compiled application code.

• Software as a Service (SaaS): Entire application available on demand.

Deployment model – Will other clients share the same service? Namely:

• Public cloud: clients are intermingled.

• Virtual private cloud: client-specific resources are provided within a public cloud.

• Hybrid cloud: on-premise private cloud selectively interacts with publicly available cloud services.

Each combination of delivery model and service-sharing fits a typical risk profile. Figure 6 organizes cloud services based upon risk exposure. For a given use case and its risk level, a generic service structure emerges.

Figure 6: Common CSP services aligned with risk

Based upon Figure 6:

• The degree to which services are shared shifts from public services to client-specific and ultimately client-controlled infrastructures as risk increases.

• Low-risk use case scenarios focus on speed and agility (that is public clouds) while higher risk scenarios focus on privacy and control.

• The role of SaaS decreases in high-risk use cases, retaining more of the critical capabilities in house.

Figure 6 is intended to be a guideline. Enterprises that intend to leverage many cloud services would be well-served to develop a similar model. In the process, the relative completeness of the risk assessment at each stage in the CSP relationship lifecycle can be clarified.

Virtual private cloud (IaaS, PaaS, SaaS) Virtual private cloud (IaaS, Paas) Hybrid cloud (IaaS, Paas) Public cloud (IaaS, Paas, SaaS) Virtual private cloud (IaaS, Paas, SaaS) Virtual private cloud (IaaS, Paas) Public cloud (IaaS, Paas, SaaS) Public cloud (IaaS, Paas, SaaS) Virtual private cloud (IaaS, Paas, SaaS) Data Sensitivity High Medium Low Process Criticality High Medium Low

Managing cloud services risk throughout a supplier lifecycle relationship 9

Conclusion

Cloud services are here to stay. How quickly they should be adopted is a risk management issue. The intensity of the risk assessment varies with the data sensitivity and/or process criticality of the use case being supported with a cloud service. The CSP relationship lifecycle infers a management plan to adopt CSP services. Risk mitigation activities should be scaled to balance business objectives and cloud service benefits. It would be in the best interest of cloud-friendly enterprises to put a framework in place such that project teams and organizational units understand what they must do to capitalize on available cloud services and manage risk at the same time. Ideally, the framework would embed tactics that would address the level of trust, control and governance the risk scenario demands.

Offices worldwide

The telecommunications services described in this publication are subject to availability and may be modified from time to time. Services and equipment are provided subject to British Telecommunications plc’s respective standard conditions of contract. Nothing in this publication forms any part of any contract. © British Telecommunications plc 2013