Clearing The Cloud 3: Some Security What-ifs

In the first in his series of "Clearing the Cloud" columns, security expert Ariel Silverstone explored the dangers of jumping too soon into cloud computing. In the second article, he defined relevant risks that we must consider when implementing cloud computing and promised to show us some solutions. In this article, he continues his vision on how to manage and secure cloud-computing solutions.

In the sections that follow I will put forward some ideas on how to resolve issues defined in my two previous articles. I will also attempt to show some of the security-related benefits we can garner from the use of cloud computing, especially those that we could not, or could not easily, do before.

The approach

Part I -- A Cloud OS:

In the early days of such companies as NetApp and EMC, one of the largest challenges faced by hosting providers was how to allocate, measure and control, bit/strip/block assignment to a specific user, and how to protect such elements from unauthorized access/modification, erasure and disclosure.

Such concern led, ultimately, to elaborate control systems, and to the concept of the Filers. Today, every large enterprise uses those tools and concept, usually seamlessly, and provides online and near-line service to its users and customers.

Let's do the following:

-- Create a bucket numbering and identification system where

1. Such identification is created on the fly

2. Such identification has a lifespan that terminates when the utility of such bucket terminates

3. Such identification is inherited to a backup medium (tapes or other identically copied buckets)

4. Such identification is done with consideration as to the ownership (process, user, organization, etc) of data in that bucket

5. Such identification is based on a federated model, where different physical locations, and even Cloud service providers, can understand, accept, and act upon each other's schemes

6. Optionally, such identification is tied to a digital certificate scheme

-- Implement a tethering scheme, a-la DRM, but much more user friendly, to monitor, pull, identify and allow/disallow access to such buckets

-- Implement an in-bucket modular encryption ability

-- Apply a monitoring, auditing, measuring and reporting mechanism

-- And finally allow relationships and some property inheritance between buckets.

Part II -- A Reference Model

Needing a presentation model is not something I can discuss here -- cloud computing is too early a concept to divine whether one will be needed. So let's start with the others:

1. Physical: For the first time in the history of computing, we could care less about the physical side of operations in this model. The physical (or rather the meta-physical in the case of Cloud Computing), is simply not relevant. Neither CISCO UCS nor VMWare, neither 3Tera's excellent product nor the IEEE's 802.11 definitions actually require, define, or mandate any particular Physical element to Cloud Computing. We should celebrate -- one step closer to Cloud Nirvana.

2. Data Link: Here is one of the most interesting opportunities of the cloud computing concept. We simply can use the data link layer as an effective interface to start, stop, throttle and perhaps even use bucket control. In some applications I can see, data link assumes a great part of what the session and the presentation layers do today.

3. Network: Cloud Computing is a beautiful, nay, poetic, case for the usage of routing. If we do it correctly, imagine how nice it would be to load-balance or storage-balance buckets between remote sites. We are now free of the tyranny of space.

4. Session: Depending on our implementation of a cloud OS and of the utility we gain from the routing and data link layers, Session, too, could be rendered effectively obsolete.

5. Presentation: As I stated above, I cannot rule out the need for a presentation layer in a Cloud. I can see some possibilities for such a layer, but those I see are not core to the need of the cloud.

Part III -- Nifty Things

Ok, so we have a cloud. What can we do with it? The following sections are some ideas I am thinking of. If I get response from this article showing interest in these, I will elaborate a lot more on these in a separate tome.

Logging (or how to out-Google Google)

What if we are the cloud service provider and what if we have logs, for example, about intrusion attempts, against a piece of the infrastructure and what if we have the ability to collect such logs, which to us represent potentially a great many customers, and whatif we have the smarts to correlate such logs for time, source, destination and other criteria?

So far, nothing new, right?

And what if, because of the volume of any specific type of logs, and our correlation, we are able to predict future events probabilityor even the time of day of predicted occurrence?

Where Social Media and Clouds Meet

What if we could enable a PKI-like social trust between not only users, but resources as well? What if we could say: User ASilverstone has secure access to his bits wherever they are in the world, whoever hosts them, at whenever times he needs to? Just how powerful would be secure, ubiquitous information access at any point?

In other words, do we need to know where the data is as long we can access, handle, process, control and remove it?

We Don't Need No Stinking OS!

If end users, (desktops) have access to a BOOTP/DHCP/Terminal Server-like secure access and an ever expanding (or contracting) storage and processing element, do they need a desktop OS?

What if all our desktops were unlimited? What if we paid for what we used instead of an over-bloated OS that includes kitchen sinks that most of us will never use?

Now your turn: What do you think?

Disclaimer: No squirrels were hurt in the process of writing this column, but one got a headache.

This story, "Clearing The Cloud 3: Some Security What-ifs" was originally published by CSO.

Copyright © 2010 IDG Communications, Inc.

7 inconvenient truths about the hybrid work trend
Shop Tech Products at Amazon