Interoperability and
Portability
Aradhna Chetal, Balaji
Ramamoorthy, Jim Peterson,
Joe Wallace, Michele Drgon &
Tushar Bhavsar
Cloud Security Alliance
Group 4
8/22/2011
This section addresses portability and interoperability as it
relates to moving data and applications securely to and from
the cloud.
Table of Contents
Overview ………………………………………………….................................... Pages 2
What is Interoperability? ..................................................................................... Pages 3-8
What is Portability? .............................................................................................. Pages 9-12
Why Do Interoperability and Portability Matter? …………………………… Page 13-14
What do Interoperability and Portability Mean for Different Cloud Models? Pages 15-18
What are the Benefits of Interoperability and Portability? ……………......... Page 19
Example Use Cases ...…………………………………………………………... Pages 20-22
What are the Risks Involved with Interoperability and Portability? …......... Pages 23-28
Emerging Standards and Technology………………………………………… Page 29-31
Sources ………………………………………………………………………….. Page 32
Page 1
Overview
Is cloud computing really so different? It uses the same underlying elements that make up most
computing environments. Hardware, software, networks, and applications all interact to provide critical
business functions. The cloud environment uses these elements, what makes it unique? This section
addresses this question as it relates to portability and interoperability when moving data and applications
securely to and from the cloud. The advent of cloud computing offers unprecedented scalability to an
organization’s IT processing and administrative capability unlike those available in “traditional” in-house
infrastructures. This brings with it the potential for less impact on IT resources and reduced capital costs.
Almost instantaneously, additional capacity can be added, moved, or removed in response to dynamically
changing processing needs. A new application support system can be spun up to meet increased demand
in a matter of hours rather than weeks. Should demand fall back, the additional capacity can be shutdown
just as quickly with no “left-over” hardware now sitting idled. Gaining the benefits of this more elastic
environment requires appropriate planning to avoid being “locked” into a cloud solution that may not
measure up to the goals for moving to the cloud in the first place.
Why portability and interoperability are important to cloud computing strategies can be
understood by referencing Cloud Taxonomies (reference back to Domain 1 material) which illustrates
various components from which a cloud environment may be composed. Combining components into a
solution introduces boundaries between different components. Boundaries here can be defined as any
distinct division across which data or applications move or operate. Different types of boundaries may
exist between the various components of a cloud system, such as operational boundaries or trust
boundaries, etc… Some examples include those such as may exist between physical locations such as
internal .vs. external, across operating systems, across different platform or service providers, between
applications or application components, and between separate or distinct data stores.
Data and application processing routinely crosses these boundaries during the course of routine
business processing, or as data and applications migrate to new providers or platforms. Ensuring
operational integrity across these boundaries as processing needs move into the cloud is a critical
consideration which can be addressed through portability and interoperability. To avoid business
disruption, organizations moving to the cloud both must be addressed as part of risk management and
security assurance considerations when planning a cloud program.
Page 2
What is Interoperability?
The concept of interoperability as it applies to cloud computing is at its simplest, the requirement for
the components of a processing system to work together to achieve their intended result. Components
should be replaceable by new or different components from different providers and continue to work.
Components that make up a system consist of the hardware and software elements required to build and
operate it. Typical components required of a cloud system include:







Hardware
Operating systems
Virtualization
Networks
Storage
Software (Application frameworks, middleware, libraries, applications)
Data Security.
It should be apparent to most readers that these components compose almost any IT system. You
might ask how these components and therefore how interoperability concerns differ from “any” IT system
where all of the components would logically be expected to work together as well. If cloud computing
uses all of these same components, how is the cloud different?
The difference as it relates to interoperability within the cloud can be introduced by referencing the
architectural framework for cloud computing. This framework describes cloud computing as the
separation of application and information resources from the infrastructure and mechanisms used to
deliver them (reference Domain 1 What is Cloud Computing).
Essentially, in cloud computing, the underlying components of a system that provide for the
infrastructure and delivery of an application function may be abstracted. Other applications that interact
with the application function will receive the same processing capabilities as if the application were
provided through traditional integration models which have greater dependency on where and how a
process operates in order for them to work.
Abstracting an application within cloud computing continues to provide the same capabilities, but
receiving those capabilities has no dependency on the infrastructure components needed for the cloud
application to operate. It can be running on any type of hardware or OS, be written in any language and it
may reside anywhere. The application function provides a service accessible over the internet and that
interacts with other application modules that themselves may reside and operate from anywhere.
Abstracting what an application does, from where and how it does it introduces unique issues for
maintaining interoperability between applications as they move to the cloud.
Interoperability impacts often arise within cloud computing when changing business needs drive the
need for changing a service provider. While a system may be functioning to specifications with one cloud
provider, will it continue to do so with a new provider? Lack of interoperability can lead to being locked
to one cloud service provider. Inevitable business decisions will result in changes over time that may lead
to a change in providers. Reasons for this change include:



An unacceptable increase in cost at contract renewal time
A provider ceases business operations.
A provider suddenly closes one or more services being used, without acceptable migration plans.
Page 3


Unacceptable decrease in service quality, such as a failure to meet key performance requirements
or achieve service level agreements (SLAs).
A business dispute between cloud customer and provider.
The degree to which interoperability can be achieved or maintained when considering a cloud project
often will depend on the degree to which a cloud provider uses open, or published, architectures and
protocols. Refer for a moment to the Jericho Cloud Cube which defines a means for differentiating
between cloud models. An important dimension in this cube defines a measure for interoperability based
on the degree of ownership of the technology behind a cloud solution.
The Cloud Cube defines an axis that identifies two degrees for interoperability as “proprietary” and
“open”. Cloud providers that offer services that are based on technology that is not publicly documented,
or that may require specific technology licensing requirements with that provider fall on the side of the
axis considered as “proprietary”. Alternatively, cloud providers that offer services that utilize open or
published technologies, or that reply on recognized standards fall on the “open” side of the axis.
The degree to which a provider offers a service based on technology that is published or standardized,
typically will increase the interoperability across cloud systems. The reason for this is other vendors
providing similar services can build their offering s from the same published specification which results
in interoperable technologies from many vendors. Either option may provide the best fit for a given need,
however, consideration for the use of open and published technologies offers a greater opportunity for
interoperability and reduces the chance of being unavoidably locked into a single providers offering.
For example, a company may seek to reduce costs to maintain the components required to run an inhouse order entry subsystem. Some components of the order system may remain in-house, while others
may be moved to an external cloud provider. Reasons for such a move may be to take advantage of cost
savings opportunities or new features offered by the provider. Expectations for interoperability
expectations would be that the subsystem continues to operate to specification within the larger customer
fulfillment system? This change should not cause the larger order processing and fulfillment operation to
stop working beyond a manageable time period required to complete the switch, or to provide any level of
service less than before the switch to the cloud.
Similarly, changing from one hosted storage provider to another that may offer compelling storage
and transfer cost savings should not result in the moved data being unavailable for periods unacceptably
longer than would be expected for an in-house storage migration of similarly sized data sets and the
continued accessibility. Also continued use of that data by the users and systems that require it should
remain similarly unaffected after the move.
Almost any change related to a cloud migration can be expected to have some operational impact on
the affected systems. Moving data sets and applications will typically result in the business function
being unavailable during the planned period of the move. If appropriate considerations for
interoperability are made the impact of a service change can be both manageable and cost effective,
avoiding unanticipated costs and unacceptable delays.
Page 4
When appropriate interoperability between components is attained, companies can effectively deploy
cloud solutions from a single cloud provider or from many providers as best meets their needs. Since
cloud applications may be composed of separate elements running from potentially many separate sites,
cloud computing introduces another unique issue which intersects with interoperability requirements.
The issue is how to ensure all the geographically diverse components work together. Interoperability
must be retained for all components of a system and this consideration must extend to cover the
possibility that services and workloads may shift. Through interoperability, all components will require
appropriate orchestration in order continue to operate correctly and securely regardless of where they are
hosted or on what platform.
Interoperability considerations and recommendations for cloud systems include:

Hardware – hardware will inevitably vary from provider to provider leaving an unavoidable
interoperability gaps if direct hardware access is required.
Recommendations:
o
o

Whenever possible, use virtualization to remove any hardware level concerns.
If hardware must be addressed, important security considerations are to make sure that
the same or better physical and administrative security controls exist when moving from
one provider to another.
Virtualization – While virtualization can remove concerns about physical hardware, distinct
differences exist between common hypervisors such as ZEN, VMware and others.
Recommendations:
o

Consider using open virtualization formats such as OVF to ensure interoperability.
Frameworks – Different platform providers offer different cloud application frameworks and
differences do exist between them that affect interoperability
Recommendations:.
o
o
o
o
Investigate the API’s to determine where differences lie and plan for any changes
necessary that may be required to application processing when moving to a new provider.
Use open and published API’s to ensure the broadest support for interoperability between
components and to facilitate migrating applications and data should changing a service
provider become necessary.
Avoid service providers that supply services using unpublished “proprietary” API’s.
Applications in the cloud interoperate over the internet and outages can be anticipated to
occur. Determine how failure in one component will impact others and avoid stateful
dependencies that may risk system a data integrity when a remote component fails.
Page 5

Storage – Storage requirements will vary for different types of data. Structured data will most
often require a database system, or require application specific formats. Unstructured data will
typically follow any of a number of common application formats used by Word Processors,
Spreadsheets and Presentation Managers.
Recommendations:
o
o
o
o
o

Store unstructured data in an established portable format such as the interoperable ZIP
format for both reduced storage and transfer requirements.
Understand the size of data sets hosted at a cloud provider. Use interoperable data
compression for data moved to and from the cloud to reduce the volume of data being
moved and to reduce the time required time to move. Typically there is a cost to move
each byte of data into and then, when needed, out of the cloud as well as costs while
stored.
Aggregate files into ZIP archives to reduce complexities of moving sets of multiple files.
Ensure the storage format selected interoperates regardless of the underlying platform.
Data may need to be accessible from mobile, to desktop, to mainframe.
Check for compatible database systems and assess conversion requirements if needed.
Security – Data and applications in the cloud reside on systems you don’t own and likely have
only limited control over. A number of important items to consider for interoperable security
include:
Recommendations:
o
Make sure authentication controls for system and user account access credentials are
compatible to ensure continued and consistent system access integrity and security.
 This includes maintaining the same authentication factor level (i.e. single .vs.
dual).
 Assess whether user or process authentication requires a change in credentials
 If Smart card or other removable key storage is utilized, make sure support is
provided, or use roaming credentials.
o
The most important way to protect sensitive data moved to the cloud is through
encryption
 Encrypting data before it is placed into the cloud will ensure that it cannot be
accessed inappropriately within cloud environments.
 Avoid losing control of encrypted data by holding the keys and avoid trusting
them to a 3rd party, even if that 3rd party is your service provider. If only you hold
the keys, only you can access your data;
 Use only interoperable encryption such as that available through published
specifications such as ZIP or OpenPGP that directly and persistently protect data
and files regardless of the platform, storage systems, or location where it resides.
Page 6
o
Not all information used within a cloud system may qualify as confidential or fall under
regulations requiring protection. Assess and classify data placed into the cloud. Avoid
the additional work of encryption and key management if the nature of the data does not
warrant it. Encrypted assets should be protected using encryption that is based on
established standards such as AES and providers should comply with any geographic
regulatory mandates such as the U.S. Federal Information Processing Standard (FIPS)
140-2 or national boundary restrictions. Moving to the cloud does not remove
compliance requirements;
 Never rely on an encryption algorithm that has not undergone industry scrutiny.
 Make sure security services of your provider adhere to the same regulatory
mandates to which you and your data must conform.
o
Avoid unnecessary and potentially costly steps of re-encrypting and re-keying
confidential data that may be required if data moves between disparate cloud
environments.
 Use only interoperable encryption to protect files such as is available using ZIP
or OpenPGP.
o
When keys must be available within the cloud, investigate how and where keys are stored
to ensure access to existing encrypted data is retained
 Understand which staff of your service provider may have access to encryption
keys and under what rules of engagement do they require it.
 Understand your responsibilities and liabilities should a compromise occur due to
unanticipated “gaps” in protection methods offered by your service provider.
 If password encryption is used, determine if a stronger means such as a
public/private key may be required to avoid difficulties of sharing a password for
collaborative data.
 If “keys” are provided by your service provider, make sure you understand what
these keys protect. Do they directly encrypt your data, or do they protect only
other keys.
o
Applications utilizing Service-oriented Architectures remain in a state of “evolving”
security. Look for gaps that may exist when introducing services. Compensate by
ensuring data is protected through portable encryption formats. Require application to
support reading and writing necessary application data when it is unencrypted and also
when it may be protected using portable data encryption formats.
o
API security keys used for calls to services requiring authentication should interoperate
and appropriate maintenance and protections of keys must exist on new platforms
Page 7
o
o
Data integrity measures should be incorporated to ensure data remains unaltered while in
the cloud.
 Use watermarks where appropriate to identify ownership
 Increase the use of digital signing of files and documents to validate data
integrity and identity
 Incorporate time-stamps on digital signatures to fix content and integrity marks
in time.
 Where native document formats do not support digital signing, protect
documents in interoperable formats that do. Examples are ZIP and OpenPGP.
Both of these formats provide digital signing for any type of document or file.
Log file information should be handled with the same level of security as all other data
moving to the cloud. Log files contain important information for system investigation
and analysis and often contain highly sensitive information that must be protected.
 Investigate how log files are created and managed within the cloud environment
where processing occurs.
 Determine how log analysis tools interoperate with existing log management to
ensure the routine log management continues without disruption or determine
what new tools are required to support logging requirements for a cloud service.
 Make sure sufficient timeliness is provided by log reporting facilities to ensure
alerting and response continuity is maintained and ensure SLA’s for cloud
providers’ address this.
 Make sure log retention requirements can meet regulations.
 When completing a move to the cloud that includes migration of log information,
make sure copies of log files are properly deleted from the original system to
avoid leaving this now duplicated information behind.
 Log files in-house are generally not well protected today, and expectations for
more robust solutions being available yet from cloud offerings should not be set
too high.
 Encryption of log file data must occur. Choose an encryption method that is
interoperable across platforms. It is recommended to use secure ZIP
compression on all log files to protect them and to store them efficiently. Log
files typically have a high compression factor, often as high as 90%.
 Apply the same diligence to the encryption keys used for log files as you do for
all other data placed into the cloud.
 Encrypting log files will inhibit search functions. This is a tradeoff that should
be made as searching and security tend to work at odds with each other.
Searching typically requires indexing which leaves sensitive information
exposed.
Page 8
What is Portability?
The concept of portability as it applies to the cloud provides for application and data components
to continue to work the same way when moved from one cloud environment to another without having to
be changed. Portability is achieved by removing dependencies on the underlying environment. A
portable component can be moved easily and reused regardless of the provider, platform, operating
system, location, storage or other elements of the surrounding environment.
Portability of applications means that an application running on one cloud platform can be moved
to a new cloud platform and operate correctly without having to be re-designed, re-coded, or re-compiled.
If the new cloud platform is a different operating platform such as when an application moves from a
Windows host to a Linux host, the application will run without needing to be changed.
Application portability can be significantly enhanced by using higher level languages or JAVA to
provide for more interoperable application support through greater abstraction from the operating
platform. Lower level languages can be used, but abstraction should also be considered through serviceoriented architectures.
Portability of data means that databases, data files or other data elements used within application
or user processing can be moved to any new environment and used without requiring changes to the data
format or to the applications that use it. Applications processing data should be assessed to ensure
appropriate security remains while the data is in use. Leaving unencrypted data or encryption keys within
application memory buffers is not recommended.
Data persisting outside the processing boundaries of applications or databases should be protected
so it can be stored or moved anywhere without risk of exposure that may occur as data passes across
many of the “gaps” present today in many data security systems. Inherently, these systems are not able to
fully protect data since they operate as “point” solutions capable only of securing data within the
boundaries in which they operate. Examples of solutions commonly deployed which cannot fully secure
data through its useful life include secure channels, encrypted drives, or secure messaging.
Since data frequently moves through any number of paths, point methods of securing files
requires additional diligence to ensure that as data moves from one point to another that each point retains
the required level of security. To achieve this data often must undergo encryption as it reaches a new
point and then must be decrypted as it passes to the next point. Risks arise that any change to a point may
open data to exposure. This risk increases with cloud computing since each point may reside within
services of different providers.
For example, a sensitive data file may undergo encryption and decryption within an SSL/TLS
channel as it is being passed over a network from one process to another. As it leaves the encrypted
channel, it may be destined for storage with a storage service provider. As it arrives at the storage facility
it undergoes another encryption operation as it is written to storage.
Page 9
Rather than relying on point solutions for encrypting data choose an encryption method that
operates directly on the data independent of the applications or systems that may process, move or store
it. Portable data encryption should be used to encrypt sensitive files moving to the cloud. Either of two
published formats should be considered to persistently and portably protect data.
The OpenPGP format provides one method for encrypting individual files. The ZIP format
provides an important alternative that uses algorithms and encryption strengths of the same durability as
OpenPGP and adds additional archiving capabilities which makes it easier to work with multiple files
across different platforms. ZIP also includes industry leading portable data compression to reduce a files
size before encryption which provides additional benefits of reducing impacts to storage or transfer
bandwidth. Both formats are universally recognized and it is likely that a versatile cloud solution will
need to support encrypted data in both formats.
As example, information that may reside protected within a database facility, must protected
when that data is used outside the database system. Report queries, log files and other extracts should be
securely zipped to ensure information is not compromised.
Additional considerations for portable data encryption include the types of keys that can be used
and whether metadata can be encrypted. Passwords remain the most common method of keying.
Public/private key methods are available in either the X.509 or OpenPGP format. Metadata is
information about a file that is stored within the encrypted format. Important metadata to encrypt
includes file names and file sizes. Choose a portable format such as secure ZIP that includes protections
for important information ‘about” your data, not just the data itself.
Moving to the cloud can simplify many of the concerns of traditional systems, replacing
traditional costs such as infrastructure and power with a “pay as you use it” approach. Making this type
of move requires addressing appropriate portability issues to ensure essential business needs continue to
be met. Existing applications and data when moved from traditional processing models to the cloud will
encounter portability considerations unique to the cloud.
There are a number of issues standing in the path of moving to the cloud. Portability
considerations and recommendations that impact moving to the cloud include:
Management control – managing systems and applications becomes much more difficult with a
move to the cloud. Traditional tools operate effectively within the established enterprise boundary, but
they lack the ability to manage services as they move outside the perimeter. Adopt management tools that
can monitor internal as well as external applications regardless of location. Understand what
management control capabilities are provided by a selected service provider and be prepared to adopt a
set of new management tools to maintain hosted functions. This can result in supporting more than one
management tool to cover internal and external systems.
Service Level – Expectations for meeting service level agreements (SLA’S) will introduce both
distance and boundary transitions that can impact abilities to meet the SLA’s a company must meet for
their own customers. Applications that run across the internet from geographically dispersed locations
will not consistently perform to the level of traditional applications. Are the SLA’s from a cloud service
provider sufficient to meet SLA’s requirements for your customer? If you move to a new provider, can
Page
10
they achieve the same level of performance? Determine who has the burden of proof for a possible
violation.
Fault management – Services moved from traditional environments can be expected to lack
integration points with exiting management tools used to monitor, report, and remedy system faults.
Determine how events will be received to detect and avoid disruptions to service. Log files and messages
may contain sensitive material. Make sure event reporting does not become a point of compromise or a
cause for lack of compliance.
Different architectures – Systems in the cloud may reside on disparate platform architectures.
Moving to the cloud or changing to a new service provider within the cloud can be impacted by
architecture differences. Leading platforms such as Google App Engine, Force.com and Amazon all
provide some degree of support for moving applications. However, each is architected differently enough
so that moving from one to another is not easy. Appropriate portability assessments must be made to plan
for adjustments required to ensure both data and application portability are maintained.
Security integration –End to end security remains a requirement for cloud systems to ensure
compliance and data confidentiality are maintained. Cloud systems introduce unique portability concerns
for maintaining security, including:
o
o
o
o
o
Authentication and identity mechanisms for user or process access to systems now must
operate across all components of a cloud system. Single sign-on using authentication
against an enterprise Active Directory may pose a risk when outside components cannot
authenticate to an internal LDAP repository. Ensure authentication extends appropriately
to the divergent systems required for a cloud application.
Two factor systems should be assessed to determine they will recognized within cloud
systems where remote system elements are not directly accessible to removable card or
token key storage devices.
Access controls must extend from the internal environment to the cloud. Preventing
access to users within the corporate perimeter is an established practice today. Cloud
applications running on the internet now require access management to appropriately
restrict access for anyone using the internet.
Data encryption must be applied to data moving to the cloud. The systems one which
your data resides will not be owned by your organization, and they will most often be
managed and maintained by outside parties. To ensure there is no loss of control of
sensitive data or risk of falling out of compliance, encrypt data before it moves to the
cloud. Remove risks to portability by placing data into universally portable secure
formats that are published such as OpenPGP or ZIP.
Encryption keys should not be turned over to cloud providers.
Metadata is an aspect of digital information that is often and easily overlooked. This is generally
because metadata typically is not directly visible when working with files and documents because it is not
part of the main document or file content. Metadata is data about data. It has been used for years in the
IT industry. Familiar examples include file owner or time-stamp information. This “metadata” about a
Page
11
file records information useful for managing the file, but is not needed for most user needs for the file.
Users of a spreadsheet typically are most concerned with the rows, columns and charts within the
document and rarely consider the metadata that accompanies that spreadsheet wherever it goes.
Metadata becomes an important consideration in the cloud, simply because this metadata does
move with the document. Encryption functions that protect important financial information for a
spreadsheet may easily leave the metadata for the file unprotected. Further as the use of metadata evolves
from storing basic information to storing much more advanced information about files and the users of
those files, the risk of exposure through metadata leakage increases. Especially since metadata often is
unseen by design.
As the use of metadata expands, portability concerns arise over whether the metadata can be used,
and protected within cloud systems, and when moving from one cloud system to another. The use of
metadata increasingly relies on XML to provide for portability of this information. Because XML adds to
the storage requirements for each file, document formats that combine XML to preserve portable
metadata with ZIP compression provide for efficient and portable packaging methods for documents and
files.
Information retentions for metadata may fall under the same retention requirements driven by
requlation as must be applied to the data itself. When moving files and their metadata to new cloud
environments, make sure copies of file metadata is securely removed to prevent this information from
remaining behind and opening a possible opportunity for compromise.
Page
12
Why Do Interoperability and Portability Matter?
Reasons for moving to the cloud vary from business to business. Each business will make cloud
decisions based on differing needs and objectives. Decision making when selecting suitable cloud service
and deployment models requires analysis of which cloud model is the best fit for a defined need.
Organizations looking to host business processing in the cloud may choose the IaaS model to
extend their infrastructure needs for OS platform support, storage, email and messaging, or other
extensions of basic IT infrastructure. Companies needing application support may decide on the SaaS
model to access business application services for functions such as Customer Relationship Management
(CRM), business collaboration software, or Ecommerce. Those looking to expand or move custom
application processing to the cloud may look to the PaaS model for cloud development frameworks. A
single business may likely find they need to adopt each of these models over time as more and more of
their information processing support moves to the cloud.
A factor for successful cloud deployment is achieving processing compatibility for cloud systems
with that of the traditional systems they replace. The ability to move to the cloud requires that
applications now hosted internally can run in the cloud. Applications that worked on in-house
infrastructures must continue to work with the same capabilities and reliability as they move to the cloud.
Storage solutions hosted within internal NAS or SAN facilities must continue to support the same storage
and access needs regardless of which cloud storage provider is selected. Applications built on cloud
frameworks must meet the same business requirements and development efficiencies as in-house efforts.
Once established, each of these scenarios must also provide on-going compatibility should changing
business needs require changing any of the underlying cloud components on which a solution depends.
Portability and interoperability combine to provide compatibility of cloud solutions. They are
important considerations for cloud planning because together they ensure that cloud solutions continue to
operate (through interoperability) and do so unchanged (through portability). When portability and
interoperability between components is not addressed, unanticipated processing failures will be the likely
result with the associated costly disruption of business continuity.
Portability and interoperability must be considered whether the cloud migration is to public,
private, or hybrid cloud deployment solutions. They are important elements to consider for service model
selection regardless of whether a migration strategy is to Software as a Service (SaaS), Platform as a
Service (PaaS), or Infrastructure as a Service (IaaS). Failure to appropriately address portability and
interoperability in a cloud migration may result in failure to achieve the desired benefits of moving to the
cloud. Ignoring these aspects of cloud migration can result in costly problems or project delays due to
factors that should be avoided such as:


Application, vendor, or provider lock-in – choice of a particular cloud solution may mean
you cannot easily move in the future to another cloud offering from another vendor
Processing incompatibility and conflicts causing disruption of service – provider,
platform or application differences may expose incompatibilities that cause applications
to malfunction ifa new cloud platform is chosen
Page
13




Unexpected application re-engineering or business process change – moving to a new
cloud provider can introduce a need to rework how a process functions or require coding
changes to retain original behaviors
Costly data migration or data conversion - lack of interoperable and portable formats
may lead to unplanned data changes to move to a new provider
Retraining or retooling new application or management software
Loss of data or application security – different security policy or control, key
management or data protection between providers may open undiscovered security gaps
when moving to a new provider or platform.
Portability and interoperability are not considerations unique to cloud environments and their
related security aspects are not new concepts brought about by cloud computing. However, the open and
often shared processing environments that exist within the cloud bring a need for even greater precautions
than are required for traditional processing models. Multi-tenancy means data and applications reside
with data and applications of other companies and that access to confidential data (intended or
unintended) is possible through shared platforms, shared storage and shared networks.
Data moving outside the protected organization boundaries means encryption is mandatory and
traditional “parameterized” security measures are not sufficient in the cloud. To ensure portability and
interoperability of data in transit to, and stored within the cloud, make sure data is protected before
placing it in the cloud and make sure keys remain within the hands of authorized company staff.
Page
14
What do Interoperability and Portability Mean for Different Cloud Models?
As defined in the earlier section Interoperability means the ability for multiple cloud platforms to
work together or interoperate. The primary goal of interoperability is to make it easier to adopt cloud.
Compatibility is next natural step of how to achieve this interoperability. It is the ability of the
application and the data to work the same way irrespective of the service model (IaaS, PaaS, SaaS) or
deployment models (private, public, and hybrid) and location (internal or external to the enterprise)
Portability is where application components are able to be moved easily and reused regardless of
provider, platform, OS, infrastructure, location, storage, format of data, API etc. The pre-requisite for
interoperability is existence of abstraction between application, data, logic and system interfaces.
One of the key factors to cloud portability and interoperability is data portability. While the
systems interoperability becomes the primary concern of the cloud service provider, issues around data
interoperability and portability remains critical. The onus is on the cloud consumer to make sure that the
data is portable as the consumer owns the data. Data should be in a format that is sharable between the
cloud providers, since without ability to port data it will become impossible to switch cloud providers.
Organizations must approach the cloud with the understanding that they may have to change
providers in the future. Portability and interoperability must be considered up front as part of their cloud
planning strategy. It is advisable to do basic business continuity planning to help minimize the impact of
worst-case scenarios when various companies might find themselves with urgent needs to switch cloud
providers.
In this section we will look what portability and interoperability means to various cloud models
(both service and deployment models) and various factors that cloud customers should consider with
respect to portability and interoperability.
Before we look into various cloud models all cloud customers should acknowledge that



Substituting cloud providers is in virtually all cases a negative business transaction for at least one
party, which can cause an unexpected negative reaction from the legacy cloud provider. This must be
planned for in the contractual process as outlined in Domain 3, in your Business Continuity Program
as outlined in Domain 7, and as a part of your overall governance in Domain 2.
Understand the size of data sets hosted at a cloud provider. The sheer size of data may cause an
interruption of service during a transition, or a longer transition period than anticipated. Many
customers have found that using a courier to ship hard drives is faster than electronic transmission for
large data sets.
Document the security architecture and configuration of individual component security controls so
they can be used to support internal audits, as well as to facilitate migration to new providers.
Infrastructure as a Service (IaaS)
Page
15
As the responsibility of the cloud provider is to provide basic computing utilities such as storage,
computing power etc., a majority of application design tasks related to interoperability rests on the cloud
customer. The cloud provider should provide standardized hardware and computing resources that can
interact with various disparate systems with minimal efforts. The Cloud provider should strictly adhere to
industry standards to maintain interoperability. The provider should be able to support complex scenarios
such as cloud brokerage, cloud bursting, hybrid clouds, multi- cloud federation etc.
Recommendations













Understand how virtual machine images can be captured and ported to new cloud providers, who
may use different virtualization technologies. Ex: Distributed Management Task Force (DMTF)
Open Virtualization format (OVF).
Identify and eliminate (or at least document) any provider-specific extensions to the virtual
machine environment.
Understand what practices are in place to make sure appropriate de-provisioning of VM images
occurs after an application is ported from the cloud provider.
Understand the practices used for decommissioning of disks and storage devices.
Understand hardware/platform based dependencies that need to be identified before migration of
the application/data.
Ask for access to system logs, traces, and access and billing records from the legacy cloud
provider.
Identify options to resume or extend service with the legacy cloud provider in part or in whole if
new service proves to be inferior.
Determine if there are any management-level functions, interfaces, or APIs being used that are
incompatible with or unimplemented by the new provider.
Understand costs a involved for moving data to and from a cloud provider
Determine what means are supported for moving data as efficiently to the cloud as possible
through using standard capabilities such as data compression
Understand what security is provided and who maintains access to encryption keys
Encrypt data before placing it in the cloud and retain control of all encryption keys to avoid risks
from multi-tenancy or careless or disgruntled staff of the cloud provider
Encrypt using standard encryption formats for ensured portability using OpenPGP or ZIP
Platform as a Service (PaaS)
The cloud provider is responsible to provide a platform on which the consumers can build their
systems. They provide with a runtime environment and an integrated application stack. It allows
developers to quickly develop and deploy custom applications on the offered platforms without the need
to build the infrastructure. The cloud provider provides the entire infrastructure and its maintenance to its
consumers.
Page
16
Recommendations









When possible, use platform components with a standard syntax, open APIs, and open standards.
Ex: Open Cloud Computing Interface (OCCI)
Understand what tools are available for secure data transfer, backup, and restore.
Understand and document application components and modules specific to the PaaS provider,
and develop application architecture with layers of abstraction to minimize direct access to
proprietary modules.
Understand how base services like monitoring, logging, and auditing would transfer over to a new
vendor.
Understand what protections are provided for data placed into the cloud and data generated and
maintained in the cloud
Protect data using standard encryption formats of OpenPGP or ZIP and retain control of all
encryption keys
Understand control functions provided by the legacy cloud provider and how they would translate
to the new provider.
When migrating to a new platform, understand the impacts on performance and availability of the
application, and how these impacts will be measured.
Understand how testing will be completed prior to and after migration, to verify that the services
or applications are operating correctly. Ensure that both provider and user responsibilities for
testing are well known and documented.
Software as a Service (SaaS)
The cloud provider provides application capabilities over the cloud and the client just manages
his/her operations and the information flowing in and out of the system. The client needs a browser and
majority of the administrative at all the levels rests with the provider.
Recommendations








Perform regular data extractions and backups to a format that is usable without the SaaS provider.
Understand whether metadata can be preserved and migrated.
If possible use data escrow services.
Understand that any custom tools being implemented will have to be redeveloped, or the new
vendor must provide those tools.
Assure consistency of control effectiveness across old and new providers.
Assure the possibility of migration of backups and other copies of logs, access records, and any
other pertinent information which may be required for legal and compliance reasons.
Understand management, monitoring, and reporting interfaces and their integration between
environments.
Is there a provision for the new vendor to test and evaluate the applications before migration?
Page
17
Private Cloud
Private cloud is when consumers run private cloud within their enterprise or use private cloud
offering from the cloud providers.
Recommendations


Ensure interoperability exists between common hypervisors such as KVM, VMware, Xen.
Ensure standard API’s are used for management functions such as users and their privilege
management, VM image management, Virtual Machine management, Virtual Netw ork
management, Service management, Storage management, Infrastructure management,
Information Management etc
Public Cloud
Interoperability in public cloud means exposing most common cloud interfaces. They may be
vendor specific or open specifications and interfaces such as OCCI, libcloud etc
Recommendations

Ensure that the cloud providers expose common and/or open interfaces to access all cloud
functions in their service offering.
Hybrid Cloud
In this scenario the consumer’s local private infrastructure should have the capability to work
with external cloud providers. A common scenario is “cloud bursting”. For an enterprise to meet peak
demands to better serve its customers, the enterprise could share load with external cloud providers
Recommendations


Ensure that the cloud providers expose common and/or open interfaces to access all cloud
functions in their service offering.
Ability to federate with different cloud providers to enable higher levels of scalability.
Page
18
What are the Benefits of Portability and Interoperability?





Infrastructure Abstraction – Application developers and administrators no longer need to worry
about the hardware the application is running on. Hypervisors gives the abstraction from
underlying hardware thus removing the compatibility concerns.
Abstraction between application, data, logic and system interfaces – This level of abstraction
provides agile application development process, portability, modularity and lose coupling.
Enterprises no longer need to worry that application and data need to reside on the same location.
Cloud Adaptability and Customization – Provides ability for the enterprises to adopt cloud and
also the ability to customize the cloud environments to fit their needs.
Vendor lock-in – Portability and Interoperability standards provide consumers the ability to
switch cloud providers without a lock-in to a particular provider.
Openness – Transparency is one of the key requirements of cloud computing. Provides the
confidence to the consumers with their business continuity planning in the event they want to
switch providers.
Page
19
Example Use Cases
The follow scenarios are based on a person we will call Tim. Tim is it manager of sales management
tool and history for his corporation. The use case explore the concepts of moving this sales management
tool from in house to the cloud then to anther cloud vendor and back to in house. The sales management
tool is for tracking sales opportunities and the process they go through. It consists of web interface and a
database containing transactions and history.
Tim is facing many decisions that affect his budget both or people and hardware.


Move from In-house to Cloud :
o Tim is working on an old sales management tool that was built in house and requires
multiple engineers and soon will require a hardware upgrade. This expense is taking a
large portion of his IT budget. He has found two cloud vendors that could help reduce
his cost.
 PaaS – The first vendor cloud vender has configured hardware and software
platform to run his internal applications as well as the historical data. Concerns
creating new ID’s for each user and setting up permissions. Management of
these ID is separate from the management of Corporate ID
management. Procedures and process will need to be put in place to update both
Identity Management systems. There is a possibility of some type of federation
that can offer some type cross coordination of the Identities but this to will need
to be wrapped in procedures and process. Example: if someone leaves the
company then Tim will need to remove the ID from both systems. The downside
of this solution is Tim will still need to keep his engineers working on the
system.
 SaaS - The second vendor offers turnkey Sales Management Tool. Tim may not
need as many engineers on the project and have a predictable cost for
service. The downside with many of the off the shelf solutions is you must tailor
your business process to the software, including Identity Management. Security
concerns are many of the same concerns as IaaS solution, two places to manage
ID and permission. Process and procedures to ensure proper maintenance, with
the added burden of maintaining historical data (because SaaS solutions rarely
have the same database structure as the historical data) which could not be
moved to the SaaS vendor.
Move from One Cloud provider to Another Cloud provider:
o Tim uses a turnkey sales management tool hosted by a cloud provider. The tool does not
quite match his sales process so Tim is changing vendors to a sales management tool that
more closely aligns to his company’s sales process.
 SaaS – The new vendor is competitors with the old vendor and therefore
interoperability would not be high on their list of priorities. On the other hand if
the vendors were built on standards as recommended above the work to move
data would be much easier. The Identify management becomes an issue.
Translating identities and permission from one vendor to another would be work
most likely done by Tim. Cloud brokers (addressed later) may provide the
expertise to accomplish this movement
 PaaS & IaaS – The issue with both the platform and infrastructure cloud venders
is they are mostly like build on different technologies. For example on platform
vendor may be Windows based and another is Lunix based. The Infrastructure
Page
20





vendors that just provide cpu and storage and allow the customer to pick a
platform would likely facilitate the movement of virtual machines from vendor to
vendor.
Move parts of applications from In-house to the cloud:
o Part of Tim’s sales management application provides information about a customer for
the sales person prior to visits. The portion of the application needs to be accessible from
anywhere. Moving this portion of his application to the cloud allows access to the
information and allows him to test moving to the cloud.
 Identity management and data transfer from on-premises to cloud application
Move part In-house and part on another cloud.
o Tim cannot find the perfect sales management tool the fits new sales processes. Tim
decides to develop part of the application in house and leave that data in the cloud.
 PaaS – Data warehousing services provide this type of benefit. The applications
can be developed in the cloud or in house. The
Move part to Cloud 1 and the rest to Cloud 2:
o Tim has decided to have Application to application provider and database to database
provider
Move from the Cloud(s) to In-house partially or fully.
o Tim’s company has just been acquired. The new company has its own in house sales
management tool. Tim’s sales management tool is in the cloud and needs to be moved to
the in house tool.
 IaaS & PaaS – having your cloud base application based on a platform and an
infrastructure provides the option of moving the application in house by
recreating the infrastructure or platform in house and then moving the
application. With moving to an established in house application many of the
same considerations and moving to the cloud occur. The data migration and
transformation is critical. Identity mapping and data access also critical.
 SaaS – When moving from the cloud application to an in house application is
about changing of business processes. Consider leaving the cloud applications for
a period of time while the history and information is still needed.
Other use case considerations



When you use cloud provider#1 and in turn cloud provider#1 is using other cloud providers like
#2 and #3. Now your data is spread across all #1, #2 and #3 cloud providers and you don't have
direct relationship with #2 and #3. What are the issues faced when you try to migrate out of this.
o Data migration from on vendor to another means pulling data to in house. Translating the
data to a new format or schema. Then moving it to its new destination.
o Identity management and permission on the data also need to be translated. The
Cloud Broker or aggregator.
o When you use services from this cloud aggregator each of those services could be offered
from different cloud providers and the consumer is totally agnostic about it. What are the
issues faced when you try to move to another cloud aggregator.
 Cloud Brokers hold the promise of solving many of the migration issue. The
idea is that a cloud broke understands many cloud vendors and can facilitate the
migration of data and identity to another cloud vendor.
 Cloud brokers may specialize in data migration, application migrations or
identity migration.
Cloud Identity and Access Management
Page
21
o
o
The key too many of these scenarios is Identity Management when moving from in house
application to a cloud vender or from cloud vendor to another cloud vendor. “Identity
Management as a Service” providers are just beginning to become available.
When using “Identity Management as a Service” providers should provide
 Strong passwords and polices that can be managed by the customer. These
standards should exceed internal standards.
 Ability to leverage this management within the firewall as well.
Page
22
What are the Risks Involved with Interoperability and Portability?
The biggest challenge to adoption of Cloud is portability and interoperability even higher
than Security as per the recent research by IEEE. Most organizations feel they lose control of
their critical business data. There is no doubt that there are several risks involved with Portability
and Interoperability in Cloud environments. Some of which are enumerated below.
Some companies have databases which are huge and are sized to be Peta bytes of data in
the cloud. The process of moving huge databases into the cloud can be slow and painful and that
also means moving data from one provider to another, especially if there is a lack of appropriate
supporting tools
Several of the Public Cloud offerings are built on proprietary technologies and not open
standards. Cloud providers do not support Heterogeneous deployments.
The lack of integration between various Cloud networks makes it difficult to migrate
applications and data amongst them and also diminish the realization of Cost savings.
There is lack of any standards which Cloud Providers should abide by to help facilitate
migration of data and applications in and out of their environments.
Enterprise tools that enable management of security and availability in the cloud in the
same way as in a data center are not there today.
Any cloud migration decision is, needs to be made in the larger context of related
application portfolio and infrastructure components management
In order to take advantage of Cloud’s scalable infrastructure will require that the
development teams have concurrent programming, workload decomposition, and data
partitioning experience. The development team also should have experience debugging
distributed systems.
The applications may explicitly require file or block storage services and may have
specific performance requirements, retention policies, or compliance
Restrictions and there is a risk these requirements may not be completely met when
migrating from one Vendor to another and this may incur additional work for the development
teams to make them compliant in the new Cloud Provider’s environment.
The design of application and how the distributed components interact and messages or
data being exchanged at each transaction can be an issue when migrating from one vendor to
another as the infrastructure environment may be different.
Page
23
Online transaction processing (OLTP) systems can have stringent requirements regarding
distributed transactions and support for a two-phase commit protocol. Application semantics may
also require custom orchestration of transactions.
A Quantitative analysis of number of users (including concurrent users) who will be
accessing the application is another important factor to consider for capacity and migration
planning for the new Cloud environment.
Interactive applications are sensitive to network and processing latency for usability. Due
to distance between users and a remote service provider causing additional Latency, may require
teams to consider regional proximity. Ideally the selection of the new Cloud provider should be
done based on a guarantee of an acceptable response time range.
Licensing requirements: Some Cloud providers may not allow in house software licenses
to be migrated to their environment and may require new licenses being bought by them to be
deployed, hence causing additional expense. The precise licensing requirements for Third party
software’s which are required by Applications/services should be evaluated upfront and
negotiated with the Cloud Vendor.
For an application to function at optimum performance, data rates and number of
transactions, impact on data transfer rates can be an issue. .If the application requires a specific
transport or network protocol for certain functions, or to provide access to users, these should be
considered when planning migration or portability of applications to a particular vendor.
In case of SaaS applications, relevant data can become locked because it is difficult to
access and use. SaaS vendors design the information model for their convenience and may not
even publish their data models in the documentation for consumption by user organizations.
SaaS integration with existing systems and processes may be more difficult than with other
migration options because APIs may not be available, well-built, well-documented, or usable
Inadequate service-level can be a significant issue for certain applications which have
strict quality of service requirements. Some risks to service levels cannot even be quantified
prior to hosting applications in the cloud. Most public cloud providers typically do not offer a
range of service levels, and have a static approach to SLAs.
In order to maximize the ROI of funds already sunk into development of applications in
house and IT, organizations may want to leverage existing investments in development and
operations skills, tools, infrastructure, and deployed applications. Identifying the net value of
these investments can be challenging in some cases.
There are no standards for IAAS Virtual Machine formats that can be an issue for IAAS
migration by consumer organizations.
Page
24
There are no portability audits available upfront which can certify that a particular
application environment is portable and nor are the Cloud Providers audited/certified on the basis
of portability and interoperability.
Risk management of the Cloud providers from a legal, compliance and operational
perspectives is another issue when it comes to interoperability. If the customer applications have
strict compliance, privacy requirements, the new Cloud vendor should be evaluated and audited
for those requirements before a decision to migrate is made.
Recommendations
Organizations are showing overwhelming interest in cloud computing due to economic
reasons and efficient resource management. Most IT environments will require significant
changes and will be introducing new challenges of cross-functional and cross-supplier
integration. This will bring the long-term benefit of decoupling core and secondary functions so
that they can be more effectively distributed. As the potential market for cloud service providers
grows and new market competition is introduced, clients with highly portable applications and
services will be able to negotiate for improved cost savings, lower risk and maximum ROI with
better service level features and options.
Identifying and selecting an optimal application migration option cannot be made in
isolation. Any cloud migration decision, may it be an application or infrastructure migration
decision, it needs to be made in the larger context of related application portfolio and
infrastructure portfolio management. Precise migration goals and motivations must be identified
along with a detailed analysis of requirements and constraints looking at various aspects for
Quality of service. Several questions must be answered about the service/application, for
example:
Is the application used for a key business function?
What is the future roadmap for the application?
Where in the lifecycle of the application is it, just released or close to be retired?
What are the underlying technologies used architecture, Framework, infrastructure and
integrations?
Cloud migration decisions will impact the application platform decisions. Other decisions
could be:
Data Center sourcing
What are the application platform foundations?
Which Programming Languages are used for development and which developer skills are
available in house
Page
25
Presentation Technologies, Server Side frameworks
Application modernization requirements
Migration costs
How can the existing investment be leveraged?
Needs to build additional operational efficiencies?
Are the individual applications or services are self- contained with limited integration points that
are permitted and supported by a cloud model.
Can Applications and services use standard communication protocols and front-end access
methods are supported by the client and the cloud service provider?
The end-user profile for the intended applications or solutions is open and inclusive so that all
intended end-users will have continuous accessibility to the applications or solutions ported to
The Cloud
Security for the applications or services is reasonable and simplistic enough to be included in a
cloud service model
Client teams have pre-approved them for consideration and migration to Cloud
Cloud service provider has reviewed and approved the applications/ solutions and has established
that the needs fit into the service provider cloud landscape of supported offerings.
The application and services are supported by the “behind-the-scenes” platforms provided by the
cloud service provider
Other Policy, governance considerations could be:
The application and services SLAs are reasonable and supported by the cloud service provider
for long-term maintenance and support, If Application has any specific compliance, privacy
needs they are supported by the Cloud provider and it should be enforceable in the runtime and
by audits.
The cloud migration decision may be impacted by some of the following issues as well:
Because of pay as you go and self-service characteristics, application migration to cloud
providers can support a department’s autonomous operations. This principle impacts the
migration decision because some alternatives can be used more in certain cases than others,
without central IT support.
Page
26
Organizations favoring open solutions will have a greatly reduced choice of cloud
providers. Most alternatives present lock-in challenges related to the service offered. Closed
versus open can mean different things for virtualization, code and data perspectives.
The organization's sourcing principles may dictate the use of single vendors over best-ofbreed vendors and influence the decision when multiple migration options meet an application's
requirements. Some new cloud platform vendors may not have offerings corresponding to all
requirements and/ or alternatives.
Hence it is important to go thru a structured methodology and extensive analysis for
deciding to port applications to the Cloud. A Complete risk assessment exercise must be
conducted for the applications/services being migrated to a Cloud environment.
Inventory all the application components that need to be ported to the cloud. Premigration audit should be conducted and that should include evaluation and ranking of all the
applications or service components that will be migrated to the cloud (NOTE: this includes, sw
version, sw patch levels, sw vendor license agreements, number of users accessing the
application or service, any interfaces to third party organizations or services, currently supported
hardware platforms, front-end or end user access and connectivity options, bandwidth
requirements, availability requirements, service level agreements (SLAs RTO RPO minimums,
application or service business criticality level and confirmation of established business
continuity procedures).
Pre-Portability analysis of Governance should be conducted as all portability activities
will need to have clearly defined customer and service provider governance. The Governance
teams/auditors for supporting this activity for Cloud migration will need to be available to ensure
that all requirements are met as defined by the Pre-portability audit and requirements.
Pre-Portability audit for Security should be conducted in detail so all security requirements and
attributes for the application or service are outlined in a check list and confirmed with the service
provider for the availability and support for required security attributes. In some cases, a higher
level of service will be possible with certain cloud configurations.
Another important Pre-Portability activity is to plan fall Back Options or in the event that
a ‘no-go’ is decided, for any reason, during the move to the Cloud, a clearly defined fall-back
strategy and plan are available to the customer. Any and all in-house fall back processing will
be the responsibility of the customer. The Cloud service provider will work with the customer to
ensure that all the necessary data and content is available for fall-back plan initiation and
support.
In addition to extensive pre-portability planning and a good portability plan, maximum
ROI and low risk can be further protected with an audit process. An audit process can be a
monthly or yearly point-in-time check to ensure that the optimum features, functions and costsavings models of The Cloud solution are being applied to the ported application or services.
Page
27
After the pre-portability plan its important that the plan is orchestrated in the order of
steps to be conducted and an end to end plan that outlines the start-to-finish activities for initial
portability or migration to cloud. This plan should also include either a mock or dry-run
portability test. If the Cloud service provider does not support such a test then, the live
portability activity will need to take place with a “first attempt” activity that will then determine
the process for subsequent applications and user groups.
In order to minimize risk further a Portability Audit must be conducted. Risk can be
further lowered significantly using a continuous audit process. This audit process should include
complete review of key risk factors. These factors include any changes or updates that could
impact the on-going portability or interoperability of the application or service. As long as the
application or service remains ‘highly portable’, customers will have the option for negotiating
improved plans annually or at service renewal times. Hence reduces the risk of a situation where
only one possible cloud service provider is available. This will ensure maximum ROI and it will
significantly reduce the risk of having a non-distributed cloud service model for larger
customers. In such situation, clients with many applications and services will want the option of
distributing between different cloud service providers to maximize their ROI and mitigate their
Risk. Portability will be very crucial for such customers anyway.
In spite of all due diligence that goes into planning the migration to Cloud, there are still
risks and unexpected events that happen in real life as we all know, hence following a sound risk
management strategy i.e., accept, avoid, mitigate, and transfer before placing applications and IT
services in the cloud is a good way to go.
Risks which cannot be avoided, pre-determined, or quantified prior to hosting
applications in the cloud, no amount of up-front planning can mitigate these accepted or
“residual” risks. Unfortunately, many organizations do not have a plan to manage these risks.
Those organizations that do actively manage these risks do so by reapplying many of the same
risk management strategies (accept, mitigate, and transfer) toward creating a cloud exit strategy,
distributing services, and acquiring insurance to mitigate and transfer as much of the remaining
cloud risk as possible.
Having a Cloud Exit strategy Or strategy to exit from one Cloud environment to another
should be part of the process of deciding to migrate to cloud. It will be prudent to have a set of
event triggers and actions that can help the organization know when something is going awry,
what action to take, and the resources required to execute the exit strategy. Risk can also be
mitigated to some extent by using multiple sources that might be internally managed or managed
using a third party such as a cloud broker or federated clouds. The residual risks can be
transferred e.g losses which can’t be recovered if an outage has already taken place may cause
damage to the reputation of a business or lost data or a breach which has occurred, such risks can
be transferred using Risk insurances.. it may compensate for measurable business loss and
compensate for time required to rebuild data.
Page
28
Emerging Standards and Technologies
Cloud consumers have various methods to interact with cloud services in the form of API’s and
interfaces. At present there are important standards and technologies emerging for portability and
interoperability for the cloud. It will take long time for these standards to mature and be supported by the
majority of the providers. Until these standards are adhered cloud brokers will play an important role in
the overall cloud ecosystem. These cloud brokers will abstract the possibly incompatible capabilities and
interfaces and provide a proxy in advance of the arrival of common and open standards.
Following are few of the many efforts centered on the development of both open and proprietary
API’s that tries to address things such as management, security and interoperability for cloud.







Open Grid Forum’s (OGF) Open Cloud Computing Interface (OCCI). It is a protocol and API
originally initiated to create a remote management API for IaaS, allowing for development of
interoperable tools for deployment, autonomic scaling and monitoring. It has evolved into flexible
API with strong focus on integration, portability, interoperability and innovation and supports all
service models.
Open Data Protocol (OData) is a web protocol for querying and updating data that provides a way
to unlock the data from the applications. This is being used to expose and access information
from variety of sources such as relational databases, file systems, content management systems,
web sites etc
DMTF’s Open Virtualization Format (OVF) is a packaging standard designed to address the
portability and deployment of virtual appliances. A workload for amazon EC2 cannot be shifted
into Savvis or Terremark without first being reformatted. OVF addresses this problem by
providing an import format that allows a virtual machine to be recast into a form that can be
recognized by a hypervisor say VMware’s ESX Server. Cloud providers today don’t allow the
virtual machines to be exported in OVF format. It has to be exported and converted into OVF
format before importing into other provider.
IEEE the standards body has created 2 working groups P2301 and P2302. P2301 working group
will provide a portability roadmap for cloud vendors, service providers and their consumers. The
goal of this working group is a standard that will allow users to know that the services they buy
meets standardized definitions and measures. P2302 working group will define topology,
protocols, functionality and governance for cloud-to-cloud interoperability and federated
operations (hybrid cloud). The standard that results will provide an economy of scale that is
transparent to the users.
Unified Cloud Interface (UCI) Project is an attempt to create an open and standardized cloud
interface for the unification of various cloud API’s. Its goal is to provide a single programming
point of contact that can encompass entire infrastructure stack as well as emerging cloud centric
technologies. The Resource Description Framework (RDF) based language is used to describe a
semantic cloud data model (taxonomy and ontology).
Cloud Computing Interoperability Forum (CCIF) was formed to enable a global cloud computing
ecosystem where organizations can work seamlessly for wider adoption of cloud computing. The
key focus of this group is to create a common agreed upon framework or ontology that enables
the ability of two or more cloud platforms to exchange information in a unified manner. (seems to
be dormant)
CTP – Cloud Trust protocol was developed by CSC is licensed at no cost to CSA. It is being
integrated to CSA’s GRC Stack. CTP provides cloud consumers with right information to make
correct information risk management decisions. This allows cloud consumers to make informed
Page
29




decisions on what processes and data could be moved to cloud provider. CTP provides
transparency into cloud and cloud customers can inquire providers about configurations,
vulnerabilities, access, authorization, policy, accountability, anchoring and operating status
conditions. This gives cloud consumers insight into the security configurations and health of their
services deployed in the cloud. The success of this depends on service providers to adhere to this
protocol and the cloud consumers demand for it.
OpenStack – This was originally founded by Rackspace and NASA. It has grown into an open
source community with global collaboration of developers and cloud computing technologists to
provide open source cloud computing platform for public and private clouds. It delivers solutions
for all types of clouds with simple implementation, scalable and with lots of features geared
towards IaaS service model. It has 3 major interrelated projects
o Openstack compute – opensource software and standards for large scale deployments of
auto-provisioned virtual compute instances
o Openstack object storage – Opensource software and standards for redundant storage of
static objects
o Openstack image service – Provides discovery, registration and delivery services for
virtual disk images.
For enterprises to restrict access to the cloud services using their already existing IAM
infrastructure federation (WS-federation, SAML) is really the standard. Some of the service
providers started supporting OAUTH for accessing resources in the cloud.
Few other emerging standards that address user’s privacy concern with respect to accessing their
data include Mozilla’s BrowserID, Microsoft’s U-Prove (formerly cardspace), Kantara initiative’s
UMA (User Managed Access). UMA is built on OAUTH and gives a uniform way of managing
access to the resources across the web with a unified access engine. This also has the potential in
future to help small businesses manage their resources across different cloud providers to their
employees.
Homomorphic encryption – not yet within a standards track, homomorphic encryption may
provide a means to support encrypting data for use within the cloud without the requirement of
decrypting. With homomorphic encryption, operations on data may occur directly using
ciphertext without decrypting and achieve the same result as with the plaintext form of the same
data. A useful application for this will be to process encrypted database information that is stored
in the cloud and protected with encryption. As example, calculating a value from two encrypted
values results in an encrypted result that when decrypted has the same, correct value as would
result from the same calculation on the unencrypted values.
Areas that need more work


Currently if a cloud consumer wants to orchestrate or dynamically move a work load running on
Amazon EC2 to another provider like Terremark there is no easy way to move that work load
without first converting into OVF format first. Providers should support exporting the work load
in an open interoperable format like OVF
Currently each hypervisor exposes its own API for monitor the traffic crossing VM backplanes.
Standards need to emerge for these API’s that could be leveraged by cloud consumers for
Page
30
monitoring and reporting. This will allow cloud consumers not to retool their applications if they
move from one provider to another.
Page
31
Sources
http://msdn.microsoft.com/en-us/library/cc836393.aspx
http://blogs.msdn.com/b/eugeniop/archive/2010/01/12/adfs-wif-on-amazon-ec2.aspx
PROVIDING SINGLE SIGN-ON TO AMAZON EC2 APPLICATIONS FROM AN ONPREMISES WINDOWS DOMAIN
CONNECTING TO THE CLOUD
DAVID CHAPPELL
DECEMBER 2009
http://download.microsoft.com/download/6/C/2/6C2DBA25-C4D3-474B-8977E7D296FBFE71/EC2-Windows%20SSO%20v1%200--Chappell.pdf
http://www.zimbio.com/SC+Magazine/articles/6P3njtcIjmR/Federation+2+0+identity+ecosystem
http://www.datacenterknowledge.com/archives/2009/07/27/cloud-brokers-the-next-bigopportunity/
http://blogs.oracle.com/identity/entry/cloud_computing_identity_and_access
http://www.opengroup.org/jericho/cloud_cube_model_v1.0.pdf
http://www.burtongroup.com
http://www.pkware.com/appnote
http://www.apps.ietf.org/rfc/rfc4880.html
Page
32