Businesses and hosters will want to offer their own clouds he said, and Microsoft will have tools for them, but Azure isn’t their answer. Instead, he said, Windows Server, System Center, and Virtual Machine Manager will get a lot better at operating in a cloud-based environment, while still offering customers lots more choice.”We will be taking our Virtual Machine Manager product and evolve it over time to much more straightforwardly allow customers to build their own private cloud,” Muglia said.”

I do like the idea of them embracing private clouds with VMM, a logical step when competing against VMware and vCloud, but then I pause. Will Azure ever compete against vCloud? vCloud is designed to allow enterprise customers to build a services-based application bundle in-house (ie running in a private cloud) and then push that entire application service bundle up to a service provider also running VMware and supporting vCloud (ie the public cloud). Build at home, push to the cloud. Makes sense. When people think private cloud, they think vCloud.But Azure is different than vCloud: it’s a service and development cloud, closer to Google Apps than vCloud. If Azure proper won’t support private clouds (and I’m making a huge leap of assumptions on definitions here, but I’m going with that data I have), either because MS has chosen not to or because private dev clouds don’t make much sense (yet), here’s my question: Will an enterprise looking at a branded Microsoft cloud solution have to choose between a private cloud vs. Azure? If the goal is to build everything in-house, then a private cloud on VMM makes sense. If the goal is to develop a MS service-based application for and running in the cloud, then Azure makes sense.But these are two distinctly different use cases, a binary decision based on what type of cloud I’m looking for. In other words if I write an app for Azure, do I need a private cloud running on VMM at all? Customers will choose to re-write their application for Azure and possibly choose to run their MS apps completely hosted in Azure – on one of the Azure services listed here – or they’ll build a private cloud in-house and run everything locally.I guess my hold up here is getting my brain around the Azure model when compared to vCloud. With vCloud, I get the idea of building my application in-house in a virtualized environment and then shipping that application – lock, stock, and barrel – off to my vCloud provider for remote hosting in the cloud. But Azure is different: if I start building an app from scratch to run on Azure I’m going to build it on Azure, in the cloud already. I won’t need to build it in-house first and ship it anywhere; it’s already there.Maybe I’m comparing apples to oranges here and I shouldn’t even be thinking about private clouds, yet there is a lot of talk about private clouds from Microsoft – even from Bob Muglia – so I have to somehow equate the two. They’re comparing and contrasting Azure with private clouds, creating a message that they’re the same type of cloud, yet one is for home and one is remote.Maybe the model will be to build some apps on Azure and run some apps in-house on my VMM private cloud, and then use the new interoperability between 2008 and Azure to let the apps running on Azure become extensions of my private cloud. Maybe my Sharepoint web tier is run in-house but my Sharepoint search and data tiers are run in Azure to keep storage and processing off my network and out of my private cloud.Does Microsoft have it right in keeping Azure and private clouds completely separate for enterprise customers because they are in fact two different beasts, yet saying they’ll work together? Or is Microsoft comparing the two because it’s not yet sure how customers will use and embrace Azure?

Technorati Tags: microsoft,azure,cloud,cloud computing,private cloud,vmm,virtual machine manager,virtualization

The latency monster rears its ugly head when apps are spread across data centers, either in a split architecture or with bursting, where the user is first directed to your local data center and then a decision is made to move that request (and possibly that entire user session) to the cloud portion of the app. Solutions exist today to help optimize the applications and the network to provide a better user experience, but there’s a new(er) trend that’s not getting much attention to help combat geographic latency: regional cloud providers.Regional cloud providers are exactly as the name suggests: providers that offer cloud services close to your physical data center. Think of these providers as “buy local” clouds. Today these providers offer local cloud hosting services that compete with the larger players, such as Amazon and RackSpace, with local knowledge and local support.

But what about a hybrid model, the Cloud Franchise: local owners and operators that offer local cloud services but also offer branch versions of the larger cloud options. Some of this model exists in the platform levels today, in fact there is a thriving marketplace for start-ups who are offering AWS-based solutions, pre-packaged and ready to go. But those solutions, once deployed, still run in AWS data centers (although AWS doesn’t publish this information, their US data centers are rumored to be located on the East Coast). If I have latency concerns about bouncing my users from one part of my app in my private Missoula data center to another part of my app located in Baltimore, then a pre-packaged AWS solution won’t really help me with that. I want all parts of my app to be as local as possible, especially when I need to burst into or direct users to the cloud.

That’s where the cloud franchise model comes into play: regional cloud providers can offer pre-packaged AWS services as well as be a branded AWS hoster, hosting those deployed services in a local data center rather than in Baltimore. The customer is still using AWS and has access to 100% of the AWS products and features, but the end result – the hosted application — is running on an AWS platform in Missoula instead of Baltimore, run by the local provider.

AWS is just one type of architecture: Azure is another place where the cloud franchise architecture could come into play. If I write my .Net app to span between both my local data center and an Azure cloud, I want to make sure that I have the shortest path in place between my data center and where my app is actually running in the Azure cloud. Mainstreet is going to perform so much better if it only has two hops between my local DC and Azure, both in Missoula, than if it has to bounce over multiple providers to cross the country to one centralized data center in Dallas.

At the end of the day the goal is to reduce latency between my data center and my public cloud. The more I can control in my user’s experience the more likely I am to deploy into the cloud, especially for latency-sensitive apps such as VDI. One way to control access to the my cloud apps is to control location: buy local from a regional cloud provider who is also a cloud franchisee. Use the services and products of a trusted brand (AWS, Azure, etc) with local hosting, management, and support, and keep the apps local.

It works for fast food, why not the cloud?

Technorati Tags: cloud,regional cloud,regional cloud providers,intercloud,context,data center,cloud computing,aws,azure,cloud franchise,application delivery,network,latency,vdi

I’ve been traveling a fair amount lately, speaking on the impact virtualization has on your applications, and talking to customers about their current virtualization issues. As you know I typically talk about the virtual platforms: hypervisors, resource management, virtual networking, and how all of that trickles up the stack to your applications. In other words: What happens to my web app when I move my web farm from physical servers to virtual servers?

More and more my conversations have been moving from concepts around introducing virtualization into the data center and towards how to efficiently use virtualization in the data center. The difference here is subtle in verbiage but huge in impact: customers are saying and showing that they understand, trust, and are standardizing on virtualization technologies and now they’re attacking deployment of these technologies. We’ve moved beyond the whiteboard phase and now we’re into the data center. For those keen on the 4Ds, we’re past Define and Design and now somewhere in the midst of Develop and Deploy. This may seem like old news to people who live and breath virtualization every day, but to customers who are not early adopters or bleeding technology implementers, this movement is a huge step for the virtual data center.

The key litmus test I’ve used for this evaluation is how frequently I talk about architecture. Last year I spent all my time talking about virtualization technologies, the challenges they introduce into the physical data center, and how to start planning to adequately manage those challenges and migrating to a truly dynamic virtual data center. I talked plumbing. Today I’m talking much more about how to architect virtualization technologies in the data center; how to use these tools as building blocks for service delivery (the real reason we use data centers in the first place). And those architecture conversations have likewise changed scope, moving from talk about how to add virtualization to the data center to talk about how to build the data center around the dynamic nature of virtualization. Oh yes, I’m talking dynamic infrastructure (or Infrastructure 2.0 as it’s been called for a while) conversations with IT architects. Awesome.

And while it may be an obvious and slight change in perception from those of us who are looking at virtualization 2-3 years down the road, we can’t forget about what a drastic leap it is for data center architects who are building applications and systems that have to be reliable. Services that are re-sold; applications that provide a business presence; 5 9’s SLAs that are dependent on virtual platforms.

Paradigm shifts are often subtle because we’re looking from inside. When viewed from the outside, though, the dynamic data center is finally coming to fruition, and the implementers – the customers — are the leading the way. We’ve built the rollercoaster; now let’s try out that exhilarating first drop.

• Networking and Application Delivery: To me recent movement from Citrix in this space is the paramount camel’s straw/tipping point for why Microsoft should finally take the leap. Citrix’s application delivery product line, NetScaler, has been a good appliance-based product for Citrix. Not a market leader, but they’ve held their own against F5 and Cisco. They manage application delivery well enough. With the announcement last week of NetScaler VPX, their virtual appliance version of MPX, NetScaler has made the leap into software-based application delivery, ala Zeus. This is huge for the acquisition discussion. First of all it could bring networking and application delivery into Microsoft’s world, something they’ve avoided with Hyper-V to date. Customers use virtualization for applications and they need to deliver those applications outside their data center. Couple VPX with the new software switch Citrix announced to compete against Cisco’s Nexus 1000v and you have the critical missing pieces for application deliver via Hyper-V (as well as another angle for Microsoft to compete against Citrix). And then add in the Citrix desktop and access-related apps for the non-MS platforms, like the iPhone, and Microsoft makes a huge push owning the application delivery stack from the VDC to the client, any client.
• VDI: Citrix has done an amazing job on virtualization geared towards the client. Going back to Metaframe and Presentation Server and then today with the work they’re doing with Xen on client virtualization, Citrix has always been focused on the client. Ironically, even though Microsoft is the de facto enterprise desktop client (in a sense), it hasn’t addressed the client virtualization markets too well. App-V is a step forward, but MED-V (with desktop virtualization code based on Virtual PC rather than Hyper-V) is a step back. VMware is making a huge push in this market with VMware View; if any player is going to win the VDC space completely they have to include a VDI solution, one that works locally and remotely, in their portfolio. Citrix could help Microsoft make that push by combining their respective solutions for hypervisor and application virtualization technologies. Many of the enterprise desktops and apps are Microsoft; the underlying technology running those desktops and apps in the data center and over the network are Citrix.
• Cloud Platforms/Providers: Xen owns a good bit of real estate in cloud and service provider data centers. Although Microsoft has good presence with customers running Windows operating systems, it doesn’t have the same exposure for Hyper-V as a platform that VMware and Xen have. I think MS is looking to change this with Azure but it will still be limited to the MS-only solution (for the short term anyway). Acquiring Citrix would give Microsoft that cloud provider mindshare by name alone. They could then take that business and technology model that Xen has built and create a best of breed service provider platform between Xen and Hyper-V for customers that want to run non-Windows apps on Xen and .Net-based apps on Hyper-V. This could drastically help Microsoft’s Oslo application lifecycle plan moving forward with cloud providers while not alienating non-.Net apps.
• Application Virtualization: As you know, I’m a huge fan of a true application virtualization model, something that I believe App-V will ultimately be able to deliver. However it will most likely be focused on .Net and Microsoft apps only and is still a few years away from full delivery and even more from adoption. In the mean time we have this bridging technology between VDI, client virtualization, and streaming apps. VMware is getting there with tools like View and ThinApp, but Citrix is staying in lockstep. Microsoft could use a Citrix acquisition to springboard App-V into a multi-focused application delivery platform, taking what’s good today with streaming apps and client virtualization and continue to work on true application virtualization for all apps.
• Customer/Device Support: And as a roll-up benefit of the above categories, we have application delivery to devices. I don’t want to place too much emphasis on supporting remote access via the iPhone, but when you look at Microsoft’s historic relationships with Apple and Linux (as a whole), of which Citrix has obvious ties into both now, that’s an appealing way for Microsoft to jump right into those groups. That doesn’t mean they’ll keep the momentum alive, but at least it would give them more opportunity than they have today. The overlap between VDI, XenApp, secure remote access, and the iPhone is an extremely appealing proposition for mobile users; a turn-key solution for Microsoft to cover a huge gap in their overall cloud and virtualization offerings.

And let’s be honest: Microsoft has had some challenges with their virtualization solutions and their overall direction. Client virtualization based on Virtual PC and no enterprise VDI solution? Hyper-V management hiccups through SCVMM/SCOM and delaying live migration for so long? Azure wanting to change the way applications run and are written on-premise? These raise questions in my mind, a lot of “Why?” questions. Citrix, on the other hand, is heading squarely in the right directly for virtualization solutions.  Citrix continues to plow ahead against VMware at a good pace, whereas Hyper-V isn’t quite at that same pace. The virtual switch announcement from Synergy last week is an excellent example; we haven’t seen any movement or advancements on virtual switching or networking for Hyper-V at all. Sophisticated virtual networking and switching management is an absolute critical component for virtual and cloud-based platforms, IMO. Moving internal roles and tasks to VMs running on the platforms is something we’ve seen for a while with VMware, even going so far as to running the full version of ESX 4.0 in a VM on top of ESXi 4.0. Citrix is doing the same with their Dazzle product. In other words both VMware and Citrix are finding optimized ways to use their own technology for their own benefit. We’re not seeing this today from Hyper-V. Again, there’s nothing to say that Microsoft acquiring Citrix would change that, but at least it might help grease the skids a bit towards internal product unification. Citrix knows how to do it well.To be clear, I am not being critical of Microsoft technologies or business practices (as any long-time readers of my blog will undoubtedly know). I am suggesting that when compared on a chart, Citrix is closer today to where the market and VMware are going for virtual platforms, and if the goal is to compete with VMware for both enterprise and cloud virtual platforms then Microsoft could benefit in leaps and bounds by acquiring Citrix for both Xen and their networking products. Microsoft would get virtual platform, application, and networking tools that they don’t have today.I’ll leave you with one final thought on how compelling a Microsoft/Citrix acquisition could be: Imagine a year from now if Azure launched out of beta running on both Xen and Hyper-V. This would be the best of both worlds: Microsoft could continue to push it’s current developer-based approach to Azure, SaaS, and application cloud computing, focusing on .Net and helping to push users to re-write their current and new apps. They could also support non-.Net customers by allowing them to run their services on Xen in Microsoft’s cloud. Customers wouldn’t have to choose based on their app needs. That would be the ultimate competitor to both Google and Amazon for cloud mindshare, bridging the two cloud models together and backed by the Microsoft brand.  Awesome. Will we ever see it? I hope so for market and customer needs.“Wish You Were Here” Image © 1975 EMI, Storm Thorgerson

Ahhh, finally back at the home office after two weeks of conferences: VMware Partner Expo in Orlando and RSA in San Francisco (with a pinch of SAP Virtualization Week thrown in the middle for flavor). It was a tiring trip but an excellent one for getting out in the field and talking to folks about virtualization and, as much as they would let me, security. I’ll have write-ups of each of the shows over the next week beginning with RSA today.

So RSA, we’ve known each other for years and sometimes you impress and sometimes you disappoint. I’d have to lean towards the latter this year; you really didn’t feel new and exciting. I was hoping that there would be a much larger virtualizaiton (and yes, cloud) security push this year than I saw, but the majority of what I witnessed in public (admittedly this was limited to the expo floor and partner-esque conversations due to a great list of analysts meetings that kept me from the general sessions) was the same ol’ same ol’: AV, IAM, UTM, network security, application security, FOBs on your iPhone, etc.

Now don’t get me wrong: obviously these are extremely important tools and technologies, but I guess I was expecting RSA to hold form and be more than the standard security show. If this year is any judge RSA will be returning to it’s pure security roots moving forward. Much like a storage show focuses solely on drives, data, and transport, RSA may be headed back to the days when us security geeks went to dig way down into the security internals. If that’s true, we had a few great years where RSA opened its arms to everyone. There was a time when it really felt that security was leading rather than following, and I just didn’t get that feeling with the show itself this year. The show felt like a necessary evil.

In contrast, the 1:1 meetings I had throughout the week were exactly as I’d hoped: Where’s security going? How can we use these security tools to create integrated solutions for the data center? What are the threats with cloud computing? How come virtual platform providers still haven’t moved beyond securing VMs and their flat virtual networks? Why is it still so easy to create VM trojans? Those were the amazing conversations I had outside RSA; talking with people who are passionate about security. But those interesting and productive conversations felt like we were whispering behind the gym in high school, as if we’d sneaked out of Physics 101 class to build our own rocket. And that alone, that feeling of making progress while the rest of the world remained stagnant, was worth the trip alone.

I know there were some great sessions on virtual and cloud security with Hoff, McKeay, and others that I didn’t witness first hand. I look forward to hearing/reading about those once RSA is officially done. And I can’t write a post about RSA without mentioning the excellent time I had at the RSA Security Bloggers Meetup 2009, another example of moving miles ahead outside of the organized show in just a few hours. Sure the drinks were flowing, but I still took copious mental notes and left excited with a smile on my face.

Anyway I’m already looking forward to next year, hoping that 365 days from today I’ll be writing about how far we’ve come in the past year on topics like virtual platform security. Until then I’ll just need to make sure I stay busy for the cause.

*In case you’re curious, that direct quote was made by someone working the show behind the scenes, someone extremely familiar with RSA. Awesome.

This topic was spawned by a comment to an earlier post on the cloud. Here’s the comment:

In the Virtual Data center deployments/cloud, do you see a chance of IP address clash with the subscribers? Subscribers would want to have freedom to select the IP addresses. In such cases, how the network setup will be?

Ravi, the commenter, brings up a great point. The cloud is shared computing space so that’s got to include the network, and unlike computing resources and other parts of the network, such as MAC addresses, which are always unique until exhausted, IP addresses are such a small, finite pool of unique identifiers they have to overlapp at some point. We’ve seen this for years with companies that acquire other companies and attempt to combine and merge two different networks that share overlapping private IP addresses. And on a much smaller scale with home router users that end up using default IP addresses, typically either 192.168.0/24 or 192.168.1/24; basically any of them if they don’t change the default Linksys/Netgear/D-Link setting.

Like home users, the concern with share IP addresses in the cloud isn’t with public IP addresses; those are governed and for the most part rigid. The problem is inside the cloud, where IPv4 cloud providers are limited to one of three banks of private, non-routable IP addresses: 10/8, 172.16/12, and 192.168/16. On their own, this range encompasses almost 18 million IPv4 addresses, which will be plenty for most cloud providers. However there are two issues for pause, even with a pool of 18 million IPs to choose from:

1. Extremely large cloud providers, such as AWS. It’s not unrealistic to imagine that Amazon could support at some point more than 18 million unique workloads at once (in this case workloads meaning applications tethered to a unique IP address). Even as they were to get close to that number, management of re-usable IP addresses would be a challenge. They would have to know by the second which workload was using which IP address, when that workload relenqueshes that IP address, re-assigning the IP, and then the technical challenge of ARP management with such high-volume IP turnover.
2. Cloud providers that accept pre-configured workloads, say from internal private clouds. Company A may have a series of applications, bundled together in something like VMware’s vApp, that all use IP addresses in 192.168.22/24. Company B may have an vApp bundle with an overlapping range, such as 192.168.20/22. Given a large enough customer pool using vApp in an external cloud provider, there will be customers that use overlapping IP addresses on the same cloud network, and these customer IP ranges most likely won’t fall on easily defined subnet borders.

So what’s the solution (ruling out IPv6 since Ravi is probably asking about IPv4)? Thankfully there are a number of tools available that will virtualize networks above layer 2, virtualizing the IP space in the same way that VLANs virtualize frames. To address this issue, a cloud provider can use some network management device that will virtualize layer 3 before or at the same time customer traffic in the cloud is translated (via NAT) from a public IP address to a private IP address. As a request for a service in the cloud comes into the cloud edge, the network or application management tool will recognize the request for a specific customer and move that request over to the segmented layer 3 network isolated for that specific customer. Very much in the same way we tag frames and ports with VLAN data, a segmented layer 3 network can be created with “tagged” IP addresses that are destined for different parts of the network.

Ravi hit a core requirement for the cloud: in a true multi-tenant environment, overlapping IP addresses must be supported and cloud customers must be able to select any IP address they’d like, either during service creation or as part of a pre-configured virtual application bundle. Customers need to be able to say “This application must use this IP address” and not have to worry about the cloud provider returning a “Sorry, IP address already in use” error. So to answer his question, yes, I absolutely see a need for overlapping IP addresses inside the cloud, but as long as the cloud is built to support that architecture, overlapping IP addresses shouldn’t be a problem for cloud customers.

@thevirtualdc I hate to tell you this, but your last blog isn’t about securing “the Cloud” at all. You are interchanging cloud & virt…

You are correct that I am presumptively interchanging the cloud with virtualization within the cloud. The primary point of this series of cloud security posts is to break out all the areas that securing the cloud entails, taking a huge topic that many people are discussing and breaking it down into small bits. A very large bite of those small bits, in my opinion, is the platforms that run each individual cloud. It’s been my experience that the majority (definitely not all) of cloud providers right now, and the customers that are seeking out these cloud providers, are using some form of virtual platforms. This is an assumption I’ve discussed here before. I’m definitely not saying virtualization=the cloud, but rather that most cloud implementations rely somewhat on virtual platforms. Virtual platforms introduce a layer of transparency in cloud providers; a customer who choose a provider that’s running virtual platforms will most likely know what that platform choice and what version it’s running. To that extent, the security of those platforms is paramount to the security of the cloud itself.

@thevirtualdc …not that they aren’t related, but by lumping everything into the IaaS bucket (which is what you are essentially doing)…

I’m not necessarily lumping all cloud providers into the IaaS bucket. Non-IaaS providers, such as AWS, Azure, and Terremark, are cloud providers that build their solutions on top of virtual platforms. These are the types of cloud providers that fall into my assumptive clause above. I’m not so concerned in this post with what those providers are doing with virtual platforms or how they’re marketing their service, but rather the fact that they are running shared virtual platforms and relying on shared data plane management from companies that are outside their control. No matter how they’re implementing these technologies, the customers are trusting the providers and the providers are trusting the platforms (along with a ton of other pieces in the cloud puzzle that I’ll delve into later as part of this continuing series) to keep things secure. Basically I’m talking here about any cloud provider that’s implementing a solution on top of stadard virtual platforms.

@thevirtualdc I totally buy everything you wrote, except you decided to call it Cloud instead of Virt which will add 2 the confusion.

I completely agree with you on this one. Goodness knows I get all up in arms about terminology and definitions when it comes to technology, but the choice to lump a discussion about virtual platform and shared data security under the Cloud nameplate was intentional. I want people who are looking at the cloud, who are looking at security concerns in the cloud, to start thinking about security risks of what’s actually running most of the cloud. For example, a major cloud provider recently discussed their solution for cloud security was to deploy individually managed distributed firewalls for their customers. That’s good, but has nothing to do with the security concerns of the virtual platforms that are running those distributed firewalls. That’s the reason I want to associate virtual platform security with cloud security. Sure, there are providers and customers that won’t need to worry about this, but I believe the majority of both will. I don’t want people to think that the cloud is magical and mystical. It’s not; most of it is running some of the same software that we’re running in the enterprise, software that’s highly prone to security breaches.

Hoff concluded with this comment, which I’m unable to find in his Twitter stream but is available via Google cache:

 @thevirtualdc What about folks who use Xen derivatives…like the 800lb gorilla of Cloud, Amazon?

You are correct; I omitted Xen from my “take responsibility” list in that post. Xen introduces a different element that’s slightly harder to control: the OEM’ing and open-source nature of their solution(s). There’s no question that a provider like Amazon who’s depending on Xen as their platform foundation should be concerned about the security of that platform, however, Xen has the ability to be modified (to varying degrees). With respect to security, this makes it much more difficult for Citrix to be ultimately responsible for a secure running environment. The ESX hypervisor is always the same. The Xen hypervisor may be different across every implementation. That introduces risks to the data plane that are much harder to control. Still as critical but it’s harder to lump Citrix in the same bucket as Microsoft and VMware in this scenario for that reason. Regardless, you are correct in that I should have addressed this in my last post.

As always the feedback from Hoff is much appreciated and enjoyed. Even if I’m way off the planet on this (and most of what I wax about here) at least it contributes to the discussion and makes us think about these things. Security risks associated with virtual platforms and not controlling the data plane won’t directly impact all cloud providers or all cloud customers. But it will impact a good number of them, and the fact that we’re not looking to these technology creators (ie the platform vendors) to lead the way and create safe computing environments for shared data…well, that keeps me awake at night.

Like it or not, we’re going to have to address and solve security of physical computing resources in the cloud sooner rather than later. And by sooner I mean now. First thing. Put down your VM security appliance and step away from your network and packets. This morning. Stop what you’re doing because I’m about ruin the image and the plan that you’re used to*. We need to figure out how to secure VM computing traffic over shared resources like CPU, RAM, and bus – the data plane implemented by virtual platforms and thus the backbone of the dynamic cloud. We’re going to deal with near-limitless attack vectors across all parts of the cloud but if we don’t secure the running environment first then we’ll be asking for someone to find an open door and take our virtual CPUs, our virtual networks, our virtual I/O.

Tools like VMware’s vShield Zones are good starts but they don’t go deep enough (at least from what about Zones today; I’ll know more after the Partner Exchange in April), managing policies and trust levels in the zones down to the bit level, not just the packet level. Exploits against the physical and virtual data planes will make network and application attacks looks like child’s play because the data plane owns the transport and storage of the targets of those attack. It’s going straight to the source. It will allow attacks from inside the cloud out through all those oh-so-useful networking and framework tools that have built up the cloud. It’s a like a microwave: attack the molecules from the inside.

Saying we’re going to do it is one thing, actually doing it is something different. Many moons ago I wrote a three-part piece about the hypervisor/platform vendors taking responsibility for their own virtual space. Their virtual CPUs, their virtual switches, their virtual IPC between host and guests; these items can all easily be secured by the vendors. But what about securing data in the hardware and the step that moves data from virtual software to the hardware? That, too, is mostly the platform vendors, but not all. With virtualization now happening in the CPU, securing that shared data in transit will require the platform vendors to work with the hardware manufacturers to address the problem and establish trust. How can the CPU trust bits from the hypervisor are safe and vise versa?

So how are the manufacturers and vendors going to do that? Easy: the platform vendors will need to create dedicated virtualization security teams that include working with hardware vendors, and start talking about this today. Get the word out that this is a critical issue and concern. Sound familiar? See, it’s all coming together to form an easily manageable plan of attack and execution for securing the cloud from the inside-out. But we have to start somewhere, and I prefer to start with the most difficult task first, the core issue and technologies at the center of the cloud, and then move out from that.

You’re reading this Microsoft and VMware, right? I thought so, just wanted to make sure.

*Yes, I did just borrow and paraphrase the opening line from The Humpty Dance, thank you very much.

As I’ve talked about a good bit recently, security in the cloud is something we’re all currently thinking about and about to face head-on. But the phrase “securing the cloud” is a misnomer; we can no more easily secure the generic cloud than we can secure the entire generic internet. The cloud is made up of many, many pieces that start at a core center (the computing platform resources) and move out to the edge (the network). But that’s only one cloud; The Cloud (as we say) is actually made up of limitless smaller clouds where data is processed locally and then pushed out to another cloud for more processing.

With this in mind, let’s stop thinking about the insurmountable task of securing The Cloud and instead start looking at securing various parts of these micro-clouds. If we can secure the smaller parts then it will be easy to piece these together as we need (a jigsaw coming together if you will) to build out a complete cloud solution. So here’s the list: What smaller parts of the cloud should we start securing today?

• Secure the platforms: Microsoft, VMware, Citrix, hypervisors, virtual switching, segmentation of VM roles
• Secure the frameworks: Those wrappers around the platforms that control provisioning and resource management, tools that manage the data in and out of the cloud to the platforms
• Secure the network: Standard network security can be apply here but it needs to be managed in parallel with the other cloud delivery security solutions
• Secure the applications: The data receivers from the frameworks. Standard application security can apply here but should have the same requirements as securing the network (ie in context) and be paired with platform security
• Secure the endpoints: Doesn’t matter if an endpoint is a traditional client technology or another cloud (remember the good ol’ days of extranets? Yeah, let’s start calling them extraclouds!), anything responsible for seeding data into or receiving data out of the cloud needs to be secured and trusted
• Secure the edge: Just like the endpoints the edge needs to be secured to validate and protect data as it’s coming in and out; the Cloud Sentry
• Secure the Cloud<->Cloud connections: This is really an amalgam of edge and client security, but unlike the model today where we secure each independently, the Cloud<->Cloud security controls need to validate all data and connections in context to make sure that the data that’s supposed to be in the cloud is correct (it may be secure data before this point but now we need to look at it in context of these two clouds talking to each other)

This nice thing about breaking these items out in a list is that no single group has to tackle everything. The cloud providers are in the unique place where they can become the Secure Cloud Project Managers, but even then they’re relying on other groups to fulfill their end of the bargain by supplying secure solutions from each of their areas of expertise. Divide and conquer!

There’s no way that securing the giant cloud can be successful if we try to do it all at once and with only one solution. We need multiple solutions working together, and to get to those solutions we need to enter the first two phases of tackling a project: Define and Design.

Now that I’ve done the work of Defining the smaller, bite-sized categories for you, let’s go ahead and start securing each of those categories. Ready? ’cause this is going to take years…

But all the talk still isn’t enough. I know, I’m never happy. The talk needs to lead to action, and that action should be led by the big three platform vendors: Microsoft, VMware, and Citrix. Regardless of how they’re addressing the cloud in public with marketing and solutions right now, these three platforms provide the backbone (figuratively, not as in networking) for both service provider and enterprise cloud computing. There are limitless other components to the cloud I’ve talked about before, but all of those components have some reliance on solutions from one of these three vendors. Sure, you can argue that the cloud can happen without any Microsoft, VMware, or Citrix technology, but that argument would be so short it wouldn’t be worth the coffee that was ordered for the argument. So keeping in tone with most of my recent posts, this is a call to arms for the big three: Why don’t you each have very public virtual security teams canvasing the globe to gather data and offer solutions?

Here’s what I’d like to see from Microsoft, VMware, and Citrix:

1. A massive evangelical thought leadership virtual security push. I’m talking a carpet bomb attack where all you do it talk, talk, talk about the risks associated with security of virtualiztion and in the cloud. It doesn’t have to be accompanied by solutions at this stage, just spread the word and solicit feedback. I want to see deep technical security tracks at VMworld and MS TechEd. I’ll save a suggested list of topics for another post (’cause I got ‘em). At this point in the plan topics should cover all three types of virtual security.
2. Cloud security teams: It’s not enough to offer cloud services like Azure and AWS, you need to offer cloud security services as well. It (I’m generalizing here with the ‘it’ part) should be a click button when I provision a new system or service. There should be a toll-free number that I can call right now and ask Amazon what they use to secure storage calls over HTTP, or call MS and ask how they guarantee my sensitive traffic can’t leak across VLANs. I don’t want to search for it, I don’t want to submit a ticket, I want this information right in front of me and at my fingertips. And I want the people answering those calls to be security experts.
3. Behind-the-scenes security swat teams. As I’ve discussed before, virtual pentesters looking for ways to exploit hypervisors, to escape the guest, working with Intel and AMD on security risks of moving logic to the CPU, to MitM bus traffic as it moves from one CPU to another. I’m not picky on whether they publicly disclose this information (that’s not true, I would prefer they do but understand why they wouldn’t want to yet) so long as their doing the research today.
4. And finally, a single funnel-up management of all these teams. I want the hypervisor security team to work side-by-side with the cloud platform deployment teams. It does no good if these teams aren’t a single entity with weekly triage meetings. The evangelist who’s talking to an ISP in Japan needs to know the person back at HQ who’s responsible for securing traffic into the cloud data center. And no using the term ‘virtual teams’ here for the obvious reasons, and for the not-as-obvious reason that these need to be real teams that do nothing but cross-technology security research.

Not only will this plan help propel security of virtualization and the cloud, it will also do wonders for customers who are looking at the cloud for mission-critical apps. If I know how to deploy a secure vApp in my internal cloud, know how to secure the channel to move that vApp to my external cloud provider, and know that they are monitoring the security of my application data on the wire and on the bus, then I’m much more likely to move forward with a complete cloud model. Security geeks and business units unite! I want this group to explain to the world the security risks of VDI and how those compare/contrast to security risks of client virtualization.

I’ve heard from so many people in the field (partners, customers, friends) that virtual security isn’t a concern today, and that’s good news. But will you be ready when it is a concern, and who will you turn to for help getting ready? Hopefully you’ll be able to rely on your platform and cloud providers, so start asking them  your questions now.