Securing The Private Cloud

So much to write about, so little time. 

I guess I'm going to have to think carefully about the topics I write about going forward -- I could easily spend every day doing nothing but blog posts on interesting topics.  Sure, that'd be fun, but my day job would seriously suffer.

A few interesting announcements last week that we can correlate:

• VMware's vSphere announcement -- all about the private cloud
• The Jericho Forum issued their best practices around secure cloud computing
• VMware and RSA made an interesting announcement as part of last week's RSA Conference

Put it all together?

It's all about securing the private cloud ...

To Start With

If you've been following this blog for a while, the private cloud discussion is nothing new.  Well, with VMware's big announcement, a whole lotta more people are joining the discussion.

To oversimplify, a private cloud is a fully virtualized environment (desktop and server) that brings many cloud-like attributes to the data center.  Because virtual machines are inherently portable, there's the option of federating workloads not only on enterprise-owned infrastructure, but with compatible service providers as well.

If you had to boil the whole discussion into three words, it'd be "efficiency, control and choice".

The word "private" signifies the control and migration path that enterprise IT needs.  And a key aspect of "control" for any ITprofessional is security.

Security And Private Cloud Evolution

I think this whole security sub-discussion is going to be absolutely essential to just how fast private clouds evolve, especially the variants that include external service provider infrastructure.

People can wield security concerns as an excellent reason as to "why not".  How many progressive IT ideas are shot down or deferred because of "security concerns", whether real or imagined?

In this specific case, though, security concerns might be the excellent reason to make the change sooner than later.

Put differently, many of us are starting take the perspective that the private cloud model has the potential of providing far better security than is available today, doing so at less cost and effort, and provide superior auditability as well.

Those are some pretty audacious statements -- so let me make an effort to substantiate at least some of them.

The Magic Of Virtualization

In a fully virtualized world, everything runs in a virtual container.  Server applications run in a virtual container.  Databases run in a virtual container.  Desktops run in a virtual container.  Even infrastructure runs in a virtual container.

Now, change the phrase "runs in a virtual container" to "runs behind a consistent external layer of security", and you can see the beginnings of this architectural argument.

Paul Maritz expressed this elegantly at EMC' Strategic Forum from this slide.

Referring to the "policies" layer, he said that building cloud architectures using virtualization provided a clear, consistent and powerful "insertion point" for injecting all manner of policies about how virtual machines interact with the outside world, or each other.

Now, that's a powerful idea when you fully contemplate it.

Grasping for an analogy, I immediately thought of "packet inspection" from the network world.  Every packet gets inspected, every time.  There's one way of doing things, and no back doors!

Put differently, nobody gets in (or out) of a virtual machine without that communication and interaction being inspected, verified and audited.  That's true for applications, desktops, databases .. even infrastructure.

In a fully virtualized, private cloud world -- everything sits in a standardized container -- period.  There's one way of doing things, and no back doors!  No place to hide trojans and malware -- every file and memory access can be inspected.  No covert communication paths.

And, of course, the policy (security policy in this case) would follow the virtual machine where ever it went -- clouds, especially private ones built on virtualization -- are dynamic and fluid.  The security policy (and its enforcement) would have to follow the container wherever it went.

Now, Over To The Jericho Forum

The Jericho Forum had popularized this notion of de-perimeterized security -- that the old notion of security being associated with a physical location (e.g. inside the firewall) is a non-started going forwar.

They've taken this idea and extended it to the emerging cloud discussion.

Not to oversimplify again, but they speak in terms of a "cloud cube" that encourages organizations to assess four separate axes when thinking about cloud security.

They're decent criteria -- but they interact with private cloud concepts in a very interesting way.

The first criteria is easiest to understand -- internal vs. external physical location.

Interestingly enough, I encountered many people who insisted that you couldn't call something "cloud" unless it was physically outside the enterprise.  With all due respect, that's a non-starter.  For example, if a big energy company wants to stand up a big, dynamic pool of virtual servers and run it as an internal cloud, I'm not going to argue with them.

Certainly, if a virtual container (containing application and information) is going outside the firewall, there's going to be a lot more scrutiny around security.  However, I'd argue that the exact same effort is required to secure a virtual container -- regardless of whether it's going outside the firewall or not.

Put differently, the act of making a virtual container secure is (or should be!) indifferent to physical location.

The second criteria is "proprietary vs. open" -- their words, not mine.  Now, many of us will look at these choices of words and wonder what they could have meant. 

I believe what they probably meant to do was to draw a distinction with more public cloud models (Google's comes to mind) where it's not clear who really owns the data, vs. more traditional models where it's very clear who owns what information, how it's protected against unauthorized access, etc.

Now, those of us who work in enterprise IT environments realize that we just can't have corporate data floating around out there; it's presumed that in a private cloud model that IT has tight control of information -- period.

The third criteria is perimeterized vs. de-perimeterized (e.g. the overall security architecture).

Perimeterized security is basically firewall thinking -- if something is located *here* it's seen as protected, if it's located *there* it isn't.  For those of you who have to use something like VPN outside the firewall, you'd be familiar with the concept. 

Now, it doesn't take too much thought to realize that any architecture built on perimeter security thinking (at least in the physical world) is going to have major challenges going forward.

However, one of the more interesting aspects of securing the private cloud is that each virtual entitity can be seen as having its own "perimeter" in a manner of speaking.  That's true for user desktops, application, infrastructure services, etc.  Ideally, this perimeter follows the container where ever it goes.

I wonder if we'd call this "perimeterized" or "de-perimeterized"?

And, finally, the fourth criteria is insourced vs. outsourced provisioning models.  An environment where you'd call your service provider to spin up some new stuff is seen one way; an environment where IT is in charge of spinning up new services (using presumably external resources) is seen differently.

Frankly, I don't really see what that has to do with a security discussion -- hard to argue that one approach is inherently any less or more secure than the other one -- but the distinction largely disappears in a private cloud model: the IT organization provisions their own services, using a mix of internal and external infrastructure.

In closing, the Jericho Forum is attempting to put just a bit of rationality around how IT organizations should think about evaluating external cloud services from a security perspective.

We could debate as to whether they picked the right criteria, or the best ones, etc. -- but any attempt at clarity is certainly appreciated these days.

I will point out, though, that when considering private clouds -- all of this is largely irrelevant any more.  Everything lives in a virtual container which has its own perimeter, and that's true whether the container is running inside the firewall, outside the firewall, or both.

And, Finally, On To VMware and RSA

As mentioned before, VMware and RSA announced collaboration activities as part of the RSA Conference.

I was hoping for more beef in this announcement (because both companies are working on some pretty cool stuff together), but I guess people weren't comfortable in sharing the specifics publicly at this time.

Sure, there's the usual API integration stuff -- that much you'd expect -- but the industry needs a complete model for securing virtual machines: including authentication, authorization and auditing.  Not every entity is a user; applications have to be 3A'd as well when they access other applications.

And -- finally -- that protection mechanism has to work pretty much the same where ever the virtual machine might be running -- a corporate desktop, or your kid's PC.

The Discussion Is Just Starting

Some people will inevitably wave the security flag and point to any form of extensive virtualization, or using external services providers in a private cloud model and say "that's not secure".

A few of us, though, firmly believe that not only will this sort of approach be secure, it'll be much more secure (and efficient) than anything we're doing today in the physical world.

Time will tell ...

Comments

[Christofer Hoff]

Just a tickler, Chuck...

I left the Cloud Security Alliance (CSA) launch to make my panel discussion with Gunnar and Rich at the Jericho Forum event during RSA.

One of the points I made there in discussing their Cube Model as well as when I was discussing virt/cloud on the panel debate I had with Simon Crosby and Steve Herrod was specifically right to this point where you said:

>> "However, one of the more interesting aspects of
>> securing the private cloud is that each virtual entitity
>> can be seen as having its own "perimeter" in a manner of
>> speaking. That's true for user desktops, application,
>> infrastructure services, etc. Ideally, this perimeter
>> follows the container where ever it goes.

>> I wonder if we'd call this "perimeterized" or
>> "de-perimeterized"?"

My answer is neither. It's "RE-perimeterized."

It's my contention/assertion that the perimeter is NOT disappearing. In fact, it's multiplying, BUT the diameter is collapsing.

That goes right to your point. The perimeter is -- given the VM as the new atomic unit of the emerging NG datacenter -- the VM boundary described by and enforced with policy.

So, it's RE-Perimeterization. We've always done it this way as we follow the Hamster Sine Wave of Pain (see my Frogs preso for that little gem...)

/Hoff

[John F.]

Hi Chuck,

Timely subject, tantalizing hints, but where's the beef? Don't leave me hanging. Even if you just point me to one of your minions' blogs describing the minutia, that would be great.

Impatiently awaiting your response

John F.

[Chuck Hollis]

Always great to hear from you, /Hoff !

"Re-perimeterization" -- ok, I get the logic of the word, but somehow it doesn't capture the significance of the concept, at least to my feeble brain.

We're coming from a world of a few, massive monolithic perimeters (e.g. firewalls) and evolving to a world of many thousands of entities, each with their own perimeter, each with an implied "firewall" as it journeys around the infrastructure.

What we need here is a new word or phrase -- "atomic perimeter"? "entity perimeter"?

I dunno. It's late, and I can't think.

-- Chuck

[Chuck Hollis]

Hi John F.

Given that you're not a trusted customer or partner, I guess you get to find out when everybody else finds out!

I know you understand ...

-- chuck

[Christofer Hoff]

Right, but we're not getting RID of perimeters, just redefining what establishes them.

Instead of using the firewall as the Maginot line demarcation between "inside" and "outside" as the perimeter, you're simply saying it's the policy that matters.

I believe that when you said:

>> We're coming from a world of a few, massive monolithic
>> perimeters (e.g. firewalls) and evolving to a world of
>> many thousands of entities, each with their own
>> perimeter, each with an implied "firewall" as it
>> journeys around the infrastructure.

...you inadvertently agreed with me, even if you didn't know it ;)

So again, it's not about getting rid of the perimeter (de-perimeterization) but rather redefining what describes it (re-perimeterization.)

That's what I meant when I said they were expanding, but the diameter (of the controls/policies) were collapsing...

Make more sense?

[Christofer Hoff]

Right, but we're not getting RID of perimeters, just redefining what establishes them.

Instead of using the firewall as the Maginot line demarcation between "inside" and "outside" as the perimeter, you're simply saying it's the policy that matters.

I believe that when you said:

>> We're coming from a world of a few, massive monolithic
>> perimeters (e.g. firewalls) and evolving to a world of
>> many thousands of entities, each with their own
>> perimeter, each with an implied "firewall" as it
>> journeys around the infrastructure.

...you inadvertently agreed with me, even if you didn't know it ;)

So again, it's not about getting rid of the perimeter (de-perimeterization) but rather redefining what describes it (re-perimeterization.)

That's what I meant when I said they were expanding, but the diameter (of the controls/policies) were collapsing...

Make more sense?

[Andrew Yeomans]

The dimensions in the Jericho Forum cube model are architectural. That's why the fourth dimension of Outsourced / Insourced is treated separately.

My simple definitions of the other axes are:-

Internal / External:- can you get hold of the physical media? The distinction reduces as virtualisation increases, but it's needed as it affects the risk / confidentiality / legal issues / data destruction.

Perimeterised / De-perimeterised:- is the data mingled with that of your collaborators, or is it all yours? (The Cloud Security Alliance have a similar concept of "multi-tenanted".) Phrasing it that way tends to be more productive than debating where the perimeter is.

Open / Proprietary:- Can you easily move your data, applications, interfaces to an alternate provider? Which may be an internal cloud. Or are you locked in to a single vendor? Of course, while cloud computing is still young, there may be problems in finding a second supplier, even if the formats and protocols are defined and "open".

Hope that helps!

[Chuck Hollis]

Yes, that's better -- thanks!

-- Chuck