10
Managing cloud services risk throughout a supplier lifecycle relationship By Mark Becker, Senior security consultant, BT and Bryan Fite, Security portfolio manager, BT

A BT Cloud whitepaper: Managing cloud services risk throughout a supplier lifecycle relationship

Embed Size (px)

Citation preview

Managing cloud services risk throughout a supplier lifecycle relationshipBy Mark Becker, Senior security consultant, BT and Bryan Fite, Security portfolio manager, BT

Managing cloud services risk throughout a supplier lifecycle relationship 2

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

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

• QualifyCSP 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.

• Defineservice 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.

• Contractforservice 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.

• Managein-lifeservice includes the required level of joint management and control.

• Terminateservice 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 service

Managing cloud services risk throughout a supplier lifecycle relationship 4

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.

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

Thescopeofduediligenceshouldinclude:

• 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 violationLost strategic advantageFines for OID leakage

Eroded competitivenessBrand damageRegulatory compliance fines

Adverse impact on image / reputation

Process Criticality

L

M

H

Reproduction cost

Recovery costLost revenue / salesEroded customer confidence

Recovery from mission criticaloutageLost market share

Data Sensitivity

H

M

L

External personally identifiable dataStrategic planning contentStock-price-affecting contentAudit findings

Need to know (business plans, password, system logs, legal)Customer data / transactionsEmployee information

Publically available contentUnrestricted internal (intranet, briefings, policies)

Use case / Process Criticality

L

M

H

TrainingStorageConferencingPublic sites

Web presence for commerceVirtual data centerHosted securityHosted processes (call center, BPOS)

Disaster recoveryCore ERP systems

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.

Withadepthappropriatefortheusecaserisk,theservicedesignshouldaddress:

• Technical integration for seamless and secure communications.

• Process integration including declared handoffs between entities.

Managing cloud services risk throughout a supplier lifecycle relationship 6

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.

Thecontractmayinclude:

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

Thegreatertheriskand/orlongerthetermoftherelationship,the moreproactivemanagerialoversightmustbecome,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

Applicationofthisframeworkisatwo-stepprocess:

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.

TheframeworkhasadvantagesforbothprojectteamsandRiskManagement.

• 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

DataSensitivity

Hig

hM

ediu

mLo

w

ProcessCriticality

HighMediumLow

Hig

h

Hig

h

Hig

h

Hig

h

HighMediumLow

ProcessCriticality

DataSensitivity

HighMediumLow

ProcessCriticality

DataSensitivity

HighMediumLow

ProcessCriticality

DataSensitivity

Med

ium

Low

Med

ium

Low

Med

ium

Low

HighMediumLow

ProcessCriticality

DataSensitivity

Med

ium

Low

UseCaseShadowUse

case + sameandlowerdataandsameorlowerprocessrisk

Managing cloud services risk throughout a supplier lifecycle relationship 8

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)

DataSensitivity

Hig

hM

ediu

mLo

w

ProcessCriticalityHighMediumLow

Managing cloud services risk throughout a supplier lifecycle relationship 9

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

Officesworldwide

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

© British Telecommunications plc 2013Registered office: 81 Newgate Street, London EC1A 7AJRegistered in England No: 1800000