Fearing the cloud: why the life sciences shouldn't fret

Why the Life Sciences Shouldn’t Fret
Michael Osburn
Director, Risk &Compliance Advisory Services
Cornerstone OnDemand
Nyla Reed
Founding Partner
The Educe Group

Cloud Computing Defined
 Cloud computing is Internet-based computing, where
computing resources (servers, services, applications, data
storage, buildings and/or staff) are provided to users on
demand as a product offered by a company.
Fearing the Cloud: Why the Life Sciences Shouldn’t Fret | July 29, 2015 2

►It typically involves
over-the-Internet
provision of
dynamically
scalable and often
virtualized
computing
resources
 Virtualization allows
the same computing
hardware to be
shared by multiple
clients or customers
3Fearing the Cloud: Why the Life Sciences Shouldn’t Fret | July 29, 2015

►Fees are typically based on the total amount of
computing resources used
 Think about how we access, use and pay for electricity
from the power grid. The cloud model is similar. You
use what you need, pay for it accordingly, and it is
always available

The NIST Cloud Model
► The cloud model can be thought
of as being composed of five
essential characteristics, three
service models and, four
deployment models.
► A model for enabling
convenient, on-demand network
access to a shared pool of
configurable computing
resources (e.g., networks,
servers, storage, applications,
and services) that can be rapidly
provisioned and released with
minimal management effort or
service provider interaction.
5
Public Private Hybrid Community
BroadNetwork
Access
RapidElasticity MeasuredService
On-Demand
Self-Service
ResourcePooling
Essential
Characteristics
Deployment
Models
SoftwareasaService
(SasS)
PlatformasaService
(PasS)
Infrastructureasa
Service(IasS)
Service
Methods
Source: NIST: National Institute of Standards and Technology
Fearing the Cloud: Why the Life Sciences Shouldn’t Fret | July 29, 2015

Essential Characteristics of Cloud
MULTI-TENANCY
6
 Not called out by NIST, but
considered another
essential characteristic of
Cloud.
 Multi-tenancy in its
simplest form implies use
of same resources or
application by multiple
consumers that may
belong to same
organization or different
organization.
 The impact of multi-
tenancy is visibility of
residual data or trace of
operations by other user or
tenant.
Source: http://www.cloudsecurityalliance.org/guidance/csaguide.v3.0.pdf

Cloud Deployment Models
7
Public
Cloud
Private
Cloud
Hybrid
Cloud
Community
Cloud
Systems and services are delivered and managed within
an organization in a shared services model.
Organization has greater/complete control over data
and systems.
The cloud infrastructure is a composition of two or more clouds
(private, community, or public) that remain unique entities
bound together by standardized or proprietary technology
enabling data and application portability.
The cloud infrastructure is shared by several organizations
and supporting communities that share concerns (i.e.,
mission, security requirements, or policy)
The cloud infrastructure available to the general public or a
large industry group and owned by an organization selling
cloud services

Cloud Service Models
THE SPI SERVICE MODELS

Cloud Service Models - SPI
9
Public
Cloud
. Capability to use the provider’s applications running
on cloud infrastructure. The applications are
accessible from various client devices through a thin
client interface such as a web browser (e.g., web-
based e-mail).
Capability to deploy onto the cloud infrastructure customer-
created or acquired applications created using
programming languages and tools supported by the
provider.
Capability to provision processing, storage, networks and
other fundamental computing resources, offering the
customer the ability to deploy and run arbitrary software,
which can include operating systems and applications.
IaaS puts these IT operations into the hands of a third
party.

Cloud Computing
CLOUD SERVICE MODELS – FACTORS TO CONSIDER
10
Source: ISACA Cloud Computing: Business Benefits With Security, Governance and Assurance Perspectives [October 2009]

Cloud Computing
CLOUD DEPLOYMENT MODELS – FACTORS TO CONSIDER

Is Cloud for Us ?
 Here’s a quick method for evaluating your
tolerance for moving an asset to various cloud
computing models.
 Work through the following steps:
 Identify the asset for cloud deployment
 Evaluate the asset
 Map the asset to potential cloud deployment models
 Evaluate potential cloud service models and
providers
 Map out the potential data flow
 Conclude
 Documented within CSA’s publication: “Security
guidance for critical areas of focus in Cloud
Computing v3.0”
ARE WE WILLING TO ACCEPT THE RISK ?

Is Cloud for Us ?
 How sensitive is the asset ?
 How important an application / function / process is ?
 Ask the following questions for each asset:
 1. How would we be harmed if the asset became widely
public and widely distributed?
 2. How would we be harmed if an employee of our cloud
provider accessed the asset?
 3. How would we be harmed if the process or function were
manipulated by an outsider?
 4. How would we be harmed if the process or function
failed to provide expected results?
 5. How would we be harmed if the information/data were
unexpectedly changed?
 6. How would we be harmed if the asset were unavailable
for a period of time ?
EVALUATE THE ASSET

Is Cloud for Us ?
 Essentially we are assessing confidentiality, integrity,
and availability requirements for the asset; and how
the risk changes if all or part of the asset is handled
in the cloud
EVALUATE THE ASSET

Is Cloud for Us ?
 Which deployment models we are comfortable with?
 Can we accept the risks implicit to the various deployment models:
private, public, community, or hybrid; and hosting scenarios: internal,
external, or combined ?
 For the asset, determine if you are willing to accept the following
options:
 1. Public.
 2. Private, internal/on-premises.
 3. Private, external (including dedicated or shared infrastructure).
 4. Community; taking into account the hosting location, potential
service provider, and identification of other community members.
 5. Hybrid. To effectively evaluate a potential hybrid deployment, you
must have in mind at least a rough architecture of where
components, functions, and data will reside
MAP THE ASSET TO CLOUD DEPLOYMENT MODELS

Is Cloud for Us ?
 In this step focus on the degree of control you’ll have at each SPI tier
to implement any required risk management.
 If you are evaluating a specific offering, at this point you might switch to
a fuller risk assessment
 Your focus will be on the degree of control you have to implement risk
mitigations in the different SPI tiers.
 We’ll cover the evaluation of providers later.
EVALUATE POTENTIAL CLOUD SERVICE MODELS AND
PROVIDERS

Is Cloud for Us ?
 If you are evaluating a specific deployment
option, map out the data flow between
your organization, the cloud service, and
any customers/other nodes.
 It’s absolutely essential to understand
whether, and how, data can move in and
out of the cloud.
 If you have yet to decide on a particular
offering, you’ll want to sketch out the
rough data flow for any options on your
acceptable list. This is to insure that as
you make final decisions, you’ll be able to
identify risk exposure points..
MAP OUT THE POTENTIAL DATA FLOW

Evaluating Cloud Service Providers
 Choose a CSP that best serves business needs whilst minimizing potential risk
 Consider size – smaller CSP vs established larger CSPs, Larger CSPs:
 Will have references, comparable use cases etc
 Will be more experienced with running cloud infrastructures, adapting to change and generally faster in
responding to an incident or threat, thus being able to maintain stability more efficiently.
 But a larger CSP will likely be stricter toward its offerings, which will greatly reduce the possibility of fine-
tuning services not fully compatible with the enterprise needs
WHEN EVALUATING A CLOUD SERVICE PROVIDER (CSP)
18
Source: Controls and Assurance in the Cloud: Using COBIT® 5

 Vendor expertise
 The enterprise needs expert knowledge or a broader perspective and experience with similar enterprises to effectively
and efficiently handle certain activities.
 Vendor capacity
 The enterprise does not have the resources to handle the work related to a specific product or service. The vendor can
supply the resources to support the entire operation or to supplement in-house resources.
 Vendor assuming risk
 The enterprise outsources activities to leverage a vendor’s experience with operational risk and corresponding risk
mitigation services. However, the accountability for the adequate performance of those activities can never be
delegated and stays with the enterprise.
 Vendor leveraging scale
 Vendors can offer services at a lower cost because working for multiple customers allows vendors to leverage scale.
FACTORS THAN CAN INFLUENCE SELECTION OF A CSP

 Vendor location (storage and processing centers) is of key importance for legal
reasons. Laws are applicable locally, which can result in a multitude of different law
systems applicable to data or business processes stored in the cloud.
 We need to consider:
 Local Law of the Enterprise
 Local law of the CSP
 Local law where data is stored
 Local law where data is processed
.
LEGAL IMPLICATIONS

 An effective Vendor Management Process with clear goals and objectives can help to ensure:
 Vendor selection and management strategy is consistent with enterprise goals.
 Effective cooperation and governance models are in place.
 Service, quality, cost and business goals are clear.
 All parties perform as agreed.
 Vendor risk is assessed and properly addressed.
 Vendor relationships are working effectively, as measured according to service objectives.
 Many key stakeholders will be involved:
 IT and business process owners solely,
 Legal to help define requirements and writing contracts.
 Compliance and audit should be consulted when reviewing service agreements and vendor compliance
assessments.
 Risk management and business continuity should analyze vendor-related risk, etc.
:
VENDOR MANAGEMENT PROCESS

 A formal information gathering process should be followed and key questions answered
across the following topics. These should include topics such as:
RFI / INFORMATION GATHERING QUESTIONNAIRE
22
Source: SIG (Standardized Information Gathering Questionnaire) v7.0 / The Santa Fe Group / http://www.sharedassessments.org

 Cloud specific questions..
 What service model (SaaS, PaaS, IaaS) ? What deployment model (Private, Public..) ?
 Where is the Cloud infrastructure hosted ?
 Is there a Cloud Audit Program to address client audit and assessment requirements ?
 Is there a formal Development Methodology in operation ?
 Is there a formal process to ensure clients are notified prior to changes being made which
may impact their service ?
 Is there a scheduled maintenance window ?
RFI / INFORMATION GATHERING QUESTIONNAIRE
23
Source: SIG (Standardized Information Gathering Questionnaire) v7.0 / The Santa Fe Group / http://www.sharedassessments.org

 Increasingly common for CSPs to elect to undergo an audit/review/assessment from an
independent auditor/assessor and share the report/certification.
 Most commonly used reports are:
 SSAE 16 (SOC 1, SOC 2, SOC 3)
 ISAE 3402 (SOC 1)
 ISO/IEC 27001
 AICPA / CICA Trust Services (SOC 2 and SOC 3) reports
INDEPENDENT ASSURANCE OF CSP
24

What does this mean to you?
DEPLOYMENT CHANGES
25
Area of Responsibility Behind the Firewall Cloud
Infrastructure and
Architecture
Hardware and Software installation - Integrations
- SSO
- Extensions (web services)
Application Level
Changes
- Full access to enable/disable
functionality and change system settings
- Customizations
- Some system settings changed by vendor
only
- Configuration only
Reporting - Ability to access database directly - Reporting and Analytics
- Export functionality
Performance - Performance monitoring
- Bandwidth limitations
- Opportunities to optimize for
growth/peak periods
- Leverage CDNs
Release Management - Upgrades
- Client-based scheduling of changes
- Release cycle determined by vendor
- Client determines enable/disable settings
Say goodbye to… The new normal…

IMPLEMENTATION APPROACH
26
Area of Responsibility Behind the Firewall Cloud
Validation Strategy Created by client Leverage vendor documentation
Requirements --- ---
Business Process Definition --- ---
Configuration Performed by client Responsibility split: client/vendor
Testing Performed by client Leverage vendor, customer base
Help Desk Client establishes SLAs SLAs need to be aligned with vendor
Governance Vendor may participate in some meetings Greater partnership with vendor
Technical – Content Client manages content servers Choice of content location
Technical - Infrastructure Installations affect project plan Infrastructure readily available
Say goodbye to… The new normal…

RELEASE MANAGEMENT
27
 Identify internal resources to manage
periodic release process
 Review vendor release notes and
determine what functionality changes will
affect you
 Create testing plan to regression test
existing processes
 Leverage existing vendor resources
 Testing environment
 Customer community
 Pre-release webinars

Contractual Provisions
 Overview of important contractual provisions that an enterprise should consider when contracting with a CSP.
 These include:
 1. Scope of Services
 2. Core Obligations of Parties
 3. End of Contract
 4. Custody and Ownership
 5. Security, Privacy and Access
 6. Fees and Payment Terms and Modalities
 7. Performance
 8. Term and Termination Possibilities
 9. Liabilities
 10.Dispute Resolution and Applicable Law
 11.Business Continuity, Data Disposal and Exit Strategy
WHEN CONTRACTING WITH A CLOUD SERVICE PROVIDER (CSP)
28

References
 Key Organisations:
 NIST – National Institute of Standards and Technology (www.nist.gov)
 CSA – Cloud Security Alliance (www.cloudsecurityalliance.org)
 ISACA – www.isaca.org
 Shared Assessments Program – (https://sharedassessments.org)
 Key document references:
 The NIST Definition of Cloud Computing (NIST Special Publication 800-145, Feb 2011)
 Cloud Computing: Business Benefits With Security, Governance and Assurance Perspectives (ISACA
Emerging technologies white paper, Oct 2009)
 Controls and Assurance in the Cloud: Using COBIT® 5 (ISACA, 2014)
 Cloud Governance: Questions Boards of Directors Need to Ask (ISACA, 2013)
 Guiding Principles for Cloud Computing Adoption and Use (ISACA Cloud Computing Vision Series White
Paper, February 2012)
 Security Guidance for Critical Areas of Focus in Cloud Computing v3.0 (CSA, 2011)
[http://www.cloudsecurityalliance.org/guidance/csaguide.v3.0.pdf]
 Standardized Information Gathering Questionnaire (SIG) (https://sharedassessments.org/)

Fearing the cloud: why the life sciences shouldn't fret

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (20)

Semelhante a Fearing the cloud: why the life sciences shouldn't fret

Semelhante a Fearing the cloud: why the life sciences shouldn't fret (20)

Mais de Cornerstone OnDemand

Mais de Cornerstone OnDemand (20)

Último

Último (6)

Fearing the cloud: why the life sciences shouldn't fret