Consider the Dimensions of Cloud Deployment to Achieve Secure Collaboration
Posted by Doug Walters on 8th April 2014
In an attempt to simplify the picture to aid business-leaders' understanding, consultants often present a two-dimensional picture of cloud topologies (Private -> Public; IaaS -> SaaS.) It's my opinion that by doing so, they do their clients a disservice - failing to grasp that there are FOUR dimensions to the cloud-scape only causes confused conversations and leads to inappropriate decisions.

There are several “cloud formations” - or forms of cloud computing. Each offers different characteristics, varying degrees of flexibility, different collaborative opportunities, and different risks. Thus a key challenge when considering cloud computing as an option is to determine how to choose the cloud formation best suited to our various types of business operations.

The objective is to enable secure collaboration in the appropriate cloud formations best suited to the business needs.

The aim of this paper is to:

• Explain that not everything is best implemented in clouds; it may be best to operate some business functions using a traditional non-cloud approach
• Explain the different cloud formations
• Describe key characteristics, benefits and risks of each cloud formation
• Provide a framework for exploring in more detail the nature of different cloud formations and the issues that need answering to make them safe and secure places to work in.
Why should We care?
Cloud computing suppliers claim they are responding to customer demands for assurances on the security of the services they provide. While this may well be true, it is critical that the right cloud formations is selected to ensure security, safe collaboration with their selected parties as business needs evolve, and compliance with applicable regulatory requirements - including on the use and location of data.

The cloud model can deliver significant benefits, but only if we know where in the different formations of cloud we need to be in order to achieve the right flexibility for our business needs. For example, if a cloud vendor were to cease providing a service, how effortlessly could we move to another provider or use our cloud-based capability to provide us with seamless disaster recovery and business continuity?

Data Protection - Data classification is necessary to ensure that the correct rules are applied when protecting it:
• It’s sensitivity - must it only exist at specific trust levels? If so, which?
• What regulatory/compliance restrictions apply – e.g. Must it stay within UK / EU boundary?
We can only meet this requirement if we have a standards for:
• A data classification model that is sufficiently easy for all originators of data to use – for example the G8 Traffic Light Protocol.
• An associated standard for managing trust levels
• Standardised metadata that signals to “cloud security” what security needs be applied to each item of data. With an understanding on what security we need to apply to our data, we are in a position to decide:

Cloud Formations – The Cloud Cube Model
The Jericho Forum (on whose work much of this paper is based) has identified 4 criteria to differentiate cloud formations from each other and the manner of their provision.

The Cloud Cube Model summarises these 4 dimensions, which are explained in turn in the rest of this paper.

“The Cloud Cube Model”

Dimension: Internal (I) / External (E)
This is the dimension that defines the physical location of the data: where does the cloud form we want to use exist - inside or outside the organisation’s boundaries.
• If it is within the organisation’s own physical boundary then it is Internal.
• If it is not within the organisation’s physical boundary then it is External.

For example, virtualised hard disks in a Service-Provider data centre would be internal, while Amazon SC3 would be external at some location “off-site”.

Dimension: Proprietary (P) / Open (O)
This is the dimension that defines the state of ownership of the cloud technology, services, interfaces, etc. It indicates the degree of interoperability, as well as enabling “data/application transportability” between business’ systems and other cloud forms, and the ability to withdraw the organisation’s data from a cloud form or to move it to another without constraint. It also indicates any constraints on being able to share applications. Proprietary means that the organisation providing the service is keeping the means of provision under their ownership.

As a result, it may not be able to move from a proprietary cloud to another cloud supplier without significant effort or investment.

Often the more innovative technology advances occur in the proprietary domain. As such the proprietor may choose to enforce restrictions through patents and by keeping the technology involved a trade secret. Clouds that are Open are using technology that is not proprietary, meaning that there are likely to be more suppliers, and you are not as constrained in being able to share your data and collaborate with selected parties using the same open technology. Open services tend to be those that are widespread and consumerised, and most likely a published open standard, for example email (SMTP).

It is arguable that the clouds that most effectively enhance collaboration between multiple organisations are Open.

Dimension: Perimeterised (Per) / De-perimeterised (D-p) Architectures

The third dimension represents the “architectural mindset” – is the business operating inside its traditional IT perimeter or outside it? De-perimeterisation has always related to the gradual failure / removal / shrinking / collapse of the traditional silo-based IT perimeter.

Perimeterised implies continuing to operate within the traditional IT perimeter, often signalled by “network firewalls”. This approach inhibits collaboration. In effect, when operating in the perimeterised areas, we may simply extend the organisation’s perimeter into the external cloud computing domain using a VPN and operating the virtual server in it's own IP domain, making use of it's own directory services to control access. Then, when the computing task is completed we organisation’s perimeter is withdrawn back to its original traditional position. This type of system perimeter is a traditional, though virtual, perimeter.

The de-perimeterised areas in the Cloud Cube Model use both internal and external domains but the collaboration or sharing of data should not be seen as internal or external – rather it is controlled by and limited to the parties that the using organisations select. For example, one organisation will not feel uncomfortable about allowing data into the internal COA-compliant domain of a collaborating organisation; they will be confident that the data will be appropriately protected.

This means: It is possible to operate in any of the four cloud formations so far described (I/P,I/O,E/P,E/O) with either of two architectural mindsets - Perimeterised or De-perimeterised.

The top-right E/O/D-p cloud formation is likely to be the “sweet spot” where optimum flexibility and collaboration can be achieved.

A Proprietary cloud provider will likely want to keep you in the left side of the cube, achieved by either continuous innovation that adds value, or by limiting the means of migrating from the proprietary domain. The ability to move from that top-left cloud form to the “sweet-spot” top-right cloud form will require a rare interface because facilitating you making this move is going to be rarely in the cloud supplier’s best business interests.

While the underlying intent remains the same, an added distinction in describing De-perimeterised cloud usage arises in that the detailed description changes based on the level of abstraction at which you choose to operate.

At the heart of all cloud forms is the concept of abstraction. Cloud models separate one layer of business from another, e.g. process from software, platform from infrastructure, etc. We show an example model here with four levels of abstraction; we can expect other models identifying different layers and abstraction levels to emerge to suit different business needs. Most cloud computing activities today are occurring at the lower layers of the stack, so today we have more maturity at the lower level.

Dimension: Insourced / Outsourced
A 4th dimension has 2 states in each of the 8 cloud forms: Per(IP,IO,EP,EO) and D-p(IP,IO,EP,EO), that responds to the question “Who do we want running our Clouds?”:
• Outsourced: the service is provided by a 3rd party
• Insourced: the service is provided by our own staff under our control

This is primarily a policy issue (i.e. a business decision, not a technical or architectural decision) which must be embodied in a contract with the cloud provider. In the Cloud Cube Model diagram this 4th dimension is shown by 2 colours; any of the 8 cloud forms can take either colour.

Note: Few organisations that are traditionally bandwidth, software or hardware providers will be able to easily make the move to becoming Cloud Service providers. It takes a new mindset - a new culture - to be a Cloud Service Provider, just as it takes a new mindset to be a Cloud Service User. We can expect early growing pains caused by both of these transitions. This leaves a market for traditional service providers to help organisations to make this cloud transition.
Given the ease with which a user within the organisation can procure cloud services – just by tendering a valid credit card - it is absolutely essential that the organisation develops the agility to set up legally binding collaboration agreements quickly, and to close them equally rapidly as soon as they are no longer needed. Will it be possible in the future to design a cloud data encapsulation approach that means if the cloud provider accepts the data capsule then they automatically accept the terms that the data came with – for example “do not process outside the data owner’s national boundary”?

Note: When closing down an agreement with a provider, care should be taken to ensure that the data is appropriately deleted from the cloud service provider’s infrastructure (including backups), otherwise a data leak risk will remain. “Data Repatriation” is a key new capability.

Background / rationale
Key questions we need to ask Cloud Computing suppliers so as to be confident that they are securely collaboratively enabled and compliant with applicable regulations:
• Where in our cloud cube model is my cloud supplier operating when providing each of their services?
• How will my cloud supplier assure that when using their services I am operating in a cloud form that has and will maintain the features I expect?
• How can I ensure that my data and the cloud services will continue to be available, in the event of the provider’s bankruptcy or change in business direction?

It’s important for the business:
• To understand how and why using any cloud form will return the value-add we want to achieve
• To set out their Cloud Computing requirements clearly, and know what to expect as a result, so they can achieve the great benefits that cloud computing can offer. Entering into any cloud form without establishing the actual business objectives – especially what collaborative flexibility and security they want - may well result in significant problems.
• Moving data, both sensitive and confidential, into the cloud also has legal and compliance issues. These too should be fully understood by all parties before the decision to move to a cloud service is made. It may be that while the cost associated with the cloud service is significantly lower, the business risk is too high.

blog comments powered by Disqus

Sign up for extra content

Register here to access premium content - the only information we require is your user name and a valid email address

Follow me

Latest private posts

Latest public posts

—1st July 2014
—18th April 2014
—9th April 2014