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.
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 ...