Archive

Archive for the ‘Virtualization Security’ Category

VMware vCloud Director Security Hardening Guide Is Available

September 23rd, 2010 No comments
Image representing VMware as depicted in Crunc...
Image via CrunchBase

I’ll be adding a material review of this document here later, but I wanted to make sure folks know this resource exists.

It’s titled the “VMware vCloud Director Security Hardening Guide”

You can download it here (PDF)

The Table of Contents appears reasonably robust…content is TBD

/Hoff

Related articles by Zemanta
Enhanced by Zemanta
Categories: Cloud Computing, Cloud Security, Virtualization, Virtualization Security, VMware Tags: , , , ,

VMware’s (New) vShield: The (Almost) Bottom Line

September 1st, 2010 2 comments

After my initial post yesterday (How To Wield the New vShield (Edge, App & Endpoint) remarking on the general sessions I sat through on vShield, I thought I’d add some additional color given my hands-on experience in the labs today.

I will reserve more extensive technical analysis of vShield Edge and App (I didn’t get to play with endpoint as there is not a lab for that) once I spend some additional quality-time with the products as they emerge.

Because people always desire for me to pop out of the cake quickly, here you go:

You should walk away from this post understanding that I think the approach holds promise within the scope of what VMware is trying to deliver. I think it can and will offer customers choice and flexibility in their security architecture and I think it addresses some serious segmentation, security and compliance gaps. It is a dramatically impactful set of solutions that is disruptive to the security and networking ecosystem. It should drive some interesting change. The proof, as they say, will be in the vPudding.

Let me first say that from VMware’s perspective I think vShield “2.0” (which logically represents many technologies and adjusted roadmaps both old and new) is clearly an important and integral part of both vSphere and vCloud Director’s future implementation strategies. It’s clear that VMware took a good, hard look at their security solution strategy and made some important and strategically-differentiated investments in this regard.

All things told, I think it’s a very good strategy for them and ultimately their customers. However, there will be some very interesting side-effects from these new features.

vShield Edge is as disruptive to the networking space (it provides L3+ networking, VPN, DHCP and NAT capabilities at the vDC edge) as it is to the security arena. When coupled with vShield App (and ultimately endpoint) you can expect VMware’s aggressive activity in retooling their offers here to cause further hastened organic development, investment, and consolidation via M&A in the security space as other vendors seek to play and complement the reabsorption of critical security capabilities back into the platform itself.

Now all of the goodness that this renewed security strategy brings also has some warts. I’ll get into some of them as I gain more hands-on experience and get some questions answered, but here’s the Cliff Note version with THREE really important points:

  1. The vShield suite is the more refined/retooled/repaired approach toward what VMware promised in delivery three years ago when I wrote about it in 2007 (Opening VMM/HyperVisors to Third Parties via API’s – Goodness or the Apocalypse?) and later in 2008 (VMware’s VMsafe: The Good, the Bad, and the Bubbly…“) and from 2009, lest we forget The Cart Before the Virtual Horse: VMware’s vShield/Zones vs. VMsafe API’s…
    _
    Specifically, as the virtualization platform has matured, so has the Company’s realization that security is something they are going to have to take seriously and productize themselves as depending upon an ecosystem wasn’t working — mostly because doing so meant that the ecosystem had to uproot entire product roadmaps to deliver solutions and it was a game of “supply vs. demand chicken.”
    _
    However, much of this new capability isn’t fully baked yet, especially from the perspective of integration and usability and even feature set capabilities such as IPv6 support. Endpoint is basically the more streamlined application of APIs and libraries for anti-malware offloading so as to relieve a third party ISV from having to write fastpath drivers that sit in the kernel/VMM and disrupt their roadmaps. vShield App is the Zones solution polished to provide inter-VM firewalling capabilities.
    _
    Edge is really the new piece here and represents a new function to represent vDC perimeterized security capabilities.Many of these features are billed — quite openly — as relieving a customer from needing to use/deploy physical networking or security products. In fact, in some cases even virtual networking products such as the Cisco Nexus 1000v are not usable/supportable. This is and example of a reasonably closed, software-driven world of Cloud where the underlying infrastructure below the hypervisor doesn’t matter…until it does.
    _
  2. vShield Edge and App are, in the way they are currently configured and managed, very complex and unwieldy and the performance, resiliency and scale described in some of the sessions is yet unproven and in some cases represents serious architectural deficiencies at first blush. There are some nasty single points of failure in the engineering (as described) and it’s unclear how many reference architectures for large enterprise and service provider scale Cloud use have really been thought through given some of these issues.
    _
    As an example, only being able to instantiate a single (but required) vShield App virtual appliance per ESX host brings into focus serious scale, security architecture and resilience issues. Being able to deploy numerous Edge appliances brings into focus manageability and policy sprawl concerns.There are so many knobs and levers leveraged across the stack that it’s going to be very difficult in large environments to reconcile policy spread over the three (I only interacted with two) components and that says nothing about then integrating/interoperating with third party vSwitches, physical switches, virtual and physical security appliances. If you think it was challenging before, you ain’t seen nothin’ yet.
    _
  3. The current deployment methodology reignites the battle that started to rage when security teams lost visibility into the security and networking layers and the virtual administrators controlled the infrastructure from the pNIC up. This takes the gap-filler virtual security solutions from small third parties such as Altor which played nicely with vCenter but allowed the security teams to manage policy and blows that model up. Now, security enforcement is a commodity feature delivered via the virtualization platform but requires too complex a set of knowledge and expertise of the underlying virtualization platform to be rendered effective by role-driven security teams.

While I’ll cover items #1 and #2 in a follow-on post, here’s what VMware can do in the short term to remedy what I think is a huges issue going forward with item #3, usability and management.

Specifically, in the same way vCloud Director sits above vCenter and abstracts away much of the “unnecessary internals” to present a simplified service catalog of resources/services to a consumer, VMware needs to provide a dedicated security administrator’s “portal” or management plane which unites the creation, management and deployment of policy from a SECURITY perspective of the various disparate functions offered by vShield App, Edge and Endpoint. [ED: This looks as though this might be what vShield Manager will address. There were no labs covering this and no session I saw gave any details on this offering (UI or API)]

If you expect a security administrator to have the in-depth knowledge of how to administer the entire (complex) virtualization platform in order to manage security, this model will break and cause tremendous friction. A security administrator shouldn’t have access to vCenter directly or even the vCloud Director interfaces.

Since much of the capability for automation and configuration is made available via API, the notion of building a purposed security interface to do so shouldn’t be that big of a deal. Some people might say that VMware should focus on building API capabilities and allow the ecosystem to fill the void with solutions that take advantage of the interfaces. The problem is that this strategy has not produced solutions that have enjoyed traction today and it’s quite clear that VMware is interested in controlling their own destiny in terms of Edge and App while allowing the rest of the world to play with Endpoint.

I’m sure I’m missing things and that given the exposure I’ve had (without any in-depth briefings) there may be material issues associated with where the products are given their early status, but I think it important to get these thoughts out of my head so I can chart their accuracy and it gives me a good reference point to direct the product managers to when they want to scalp me for heresy.

There’s an enormous amount of detail that I want to/can get into. The last time I did that it ended up in a 150 slide presentation I delivered at Black Hat…

Allow me to reiterate what I said in the beginning:

You should walk away from this post understanding that I think the approach holds promised within the scope of what VMware is trying to deliver. I think it can and will offer customers choice and flexibility in their security architecture and I think it addresses some serious segmentation, security and compliance gaps. It is a dramatically impactful set of solutions that is disruptive to the security and networking ecosystem. It should drive some interesting change. The proof, as they say, will be in the vPudding.

…and we all love vPudding.

/Hoff

Related articles by Zemanta
Enhanced by Zemanta
Categories: Cloud Computing, Cloud Security, Virtualization, Virtualization Security, VMware Tags: , , , , , , , , ,

How To Wield the New vShield (Edge, App & Endpoint)

August 30th, 2010 4 comments
Image representing VMware as depicted in Crunc...
Image via CrunchBase

Today at VMworld I spent my day in and out of sessions focused on the security of virtualized and cloud environments.

Many of these security sessions hinged on the release of VMware‘s new and improved suite of vShield product offerings which can be simply summarized by a deceptively simple set of descriptions:

  • vShield Edge – Think perimeter firewalling for the virtual datacenter (L3 and above)
  • vShield App – Think internal segmentation and zoning (L2)
  • vShield Endpoint – Anti-malware service offload

The promised capabilities of these solutions offer quite a well-rounded set of capabilities from a network and security perspective but there are many interesting things to consider as one looks at the melding of the VMsafe API, vShield Zones and the nepotistic relationship enjoyed between the vCloud (nee’ VMware vCloud Director) and vSphere platforms.

There are a series of capabilities emerging which seek to solve many of the constraints associated with multi-tenancy and scale challenges of heavily virtualized enterprise and service provider virtual data center environments.  However, many of the issues associated with those I raised in the Four Horsemen of the Virtualization Security Apocalypse still stand (performance, resilience/scale, management and cost) — especially since many of these features are delivered in the form of a virtual appliance.

Many of the issues I raise above (and asked again today in session) don’t have satisfactory answers which just shows you how immature we still are in our solution portfolios.

I’ll be diving deeper into each of the components as the week proceeds (and more details around vCloud Director are made available,) but one thing is certain — there’s a very interesting amplification of the existing tug-of-war  between the security capabilities/functionality provided by the virtualization/cloud platform providers and the network/security ecosystem trying to find relevance and alignment with them.

There is going to be a wringing out of the last few smaller virtualization/Cloud security players who have not yet been consolidated via M&A or attrition (Altor Networks, Catbird, HyTrust, Reflex, etc) as the three technologies above either further highlight an identified gap or demonstrate irrelevance in the face of capabilities “built-in” (even if you have to pay for them) by VMware themselves.

Further, the uneasy tension between  the classical physical networking vendors and the virtualization/cloud platform providers is going to come to a boil, especially as it comes to configuration management, compliance, and reporting as the differentiators between simple integration at the API level of control and data plane capabilities and things like virtual firewalling (and AV, and overlay VPNs and policy zoning) begins to commoditize.

As I’ve mentioned before, it’s not where the network *is* in a virtualized environment, it’s where it *isn’t* — the definition of where the network starts and stops is getting more and more abstracted.   This in turn drives the same conversation as it relates to security.  How we’re going to define, provision, orchestrate, and govern these virtual data centers concerns me greatly as there are so many touchpoints.

Hopefully this starts to get a little more clear as more and more of the infrastructure (virtual and physical) become manageable via API such that ultimately you won’t care WHAT tool is used to manage networking/security or even HOW other than the fact that policy can be defined consistently and implemented/instantiated via API across all levels transparently, regardless of what’s powering the moving parts.

This goes back to the discussions (video) I had with Simon Crosby on who should own security in virtualized environments and why (blog).

Now all this near term confusion and mess isn’t necessarily a bad thing because it’s going to force further investment, innovation and focus on problem solving that’s simply been stalled in the absence of both technology readiness, customer appetite and compliance alignment.

More later this week. [Ed: You can find the follow-on to this post here “VMware’s (New) vShield: The (Almost) Bottom Line]

/Hoff

Related articles by Zemanta

Categories: Cloud Computing, Cloud Security, Compliance, Virtualization, Virtualization Security, VMware Tags: , , , , , , , , , ,

Video Of My Cloudifornication Presentation [Microsoft BlueHat v9]

August 16th, 2010 2 comments

In advance of publishing a more consolidated compilation of various recordings of my presentations, I thought I’d post this one.

This is from Microsoft’s BlueHat v9 and is from my “Cloudifornication: Indiscriminate Information Intercourse Involving Internet Infrastructure” presentation.

The direct link is here in case you have scripting disabled.

The follow-on to this is my latest presentation – “Cloudinomicon: Idempotent Infrastructure, Building Survivable Systems, and Bringing Sexy Back To Information Centricity.”

Related articles by Zemanta

Enhanced by Zemanta
Categories: Cloud Computing, Cloud Security, Cloud Security Alliance, CloudAudit, Compliance, Conferences, Microsoft, Security Conferences, Virtualization, Virtualization Security Tags: , , , , , , , , , , , ,

The Security Hamster Sine Wave Of Pain: Public Cloud & The Return To Host-Based Protection…

July 7th, 2010 7 comments
Snort Intrusion Detection System Logo
Image via Wikipedia

This is a revisitation of a blog I wrote last year: Incomplete Thought: Cloud Security IS Host-Based…At The Moment

I use my ‘Security Hamster Sine Wave of Pain” to illustrate the cyclical nature of security investment and deployment models over time and how disruptive innovation and technology impacts the flip-flop across the horizon of choice.

To wit: most mass-market Public Cloud providers such as Amazon Web Services rely on highly-abstracted and limited exposure of networking capabilities.  This means that most traditional network-based security solutions are impractical or non-deployable in these environments.

Network-based virtual appliances which expect generally to be deployed in-line with the assets they protect are at a disadvantage given their topological dependency.

So what we see are security solution providers simply re-marketing their network-based solutions as host-based solutions instead…or confusing things with Barney announcements.

Take a press release today from SourceFire:

Snort and Sourcefire Vulnerability Research Team(TM) (VRT) rules are now available through the Amazon Elastic Compute Cloud (Amazon EC2) in the form of an Amazon Machine Image (AMI), enabling customers to proactively monitor network activity for malicious behavior and provide automated responses.

Leveraging Snort installed on the AMI, customers of Amazon Web Services can further secure their most critical cloud-based applications with Sourcefire’s leading protection. Snort and Sourcefire(R) VRT rules are also listed in the Amazon Web Services Solution Partner Directory, so that users can easily ensure that their AMI includes the latest updates.

As far as I can tell, this means you can install a ‘virtual appliance’ of Snort/Sourcefire as a standalone AMI, but there’s no real description on how one might actually implement it in an environment that isn’t topologically-friendly to this sort of network-based implementation constraint.*

Since you can’t easily “steer traffic” through an IPS in the model of AWS, can’t leverage promiscuous mode or taps, what does this packaging implementation actually mean?  Also, if  one has a few hundred AMI’s which contain applications spread out across multiple availability zones/regions, how does a solution like this scale (from both a performance or management perspective?)

I’ve spoken/written about this many times:

Where Are the Network Virtual Appliances? Hobbled By the Virtual Network, That’s Where… and

Dear Public Cloud Providers: Please Make Your Networking Capabilities Suck Less. Kthxbye

Ultimately, expect that Public Cloud will force the return to host-based HIDS/HIPS deployments — the return to agent-based security models.  This poses just as many operational challenges as those I allude to above.  We *must* have better ways of tying together network and host-based security solutions in these Public Cloud environments that make sense from an operational, cost, and security perspective.

/Hoff

Related articles by Zemanta

* I “spoke” with Marty Roesch on the Twitter and he filled in the gaps associated with how this version of Snort works – there’s a host-based packet capture element with a “network” redirect to a stand-alone AMI:

@Beaker AWS->Snort implementation is IDS-only at the moment, uses software packet tap off customer app instance, not topology-dependent

and…

they install our soft-tap on their AMI and send the traffic to our AMI for inspection/detection/reporting.

It will be interesting to see how performance nets out using this redirect model.

Enhanced by Zemanta
Categories: Cloud Computing, Cloud Security, Data-Centric Security, Firewalls, Information Centricity, Information Security, Information Survivability, Intrusion Detection, Intrusion Prevention, Virtualization, Virtualization Security Tags: , , , , , , , , , ,

The Classical DMZ Design Pattern: How To Kill Security In the Cloud

July 7th, 2010 6 comments

Every day I get asked to discuss how Cloud Computing impacts security architecture and what enterprise security teams should do when considering “Cloud.”

These discussions generally lend themselves to a bifurcated set of perspectives depending upon whether we’re discussing Public or Private Cloud Computing.

This is unfortunate.

From a security perspective, focusing the discussion primarily on the deployment model instead of thinking holistically about the “how, why, where, and who” of Cloud, often means that we’re tethered to outdated methodologies because it’s where our comfort zones are.

When we’re discussing Public Cloud, the security teams are starting to understand that the choice of compensating controls and how they deploy and manage them require operational, economic and architectural changes.  They are also coming to terms with the changes to application architectures as it relates to distributed computing and SOA-like implementation.  It’s uncomfortable and it’s a slow-slog forward (for lots of good reasons,) but good questions are asked when considering the security, privacy and compliance impacts of Public Cloud and what can/should be done about them and how things need to change.

When discussing Private Cloud, however, even when a “clean slate design” is proposed, the same teams tend to try to fall back to what they know and preserve the classical n-tier application architecture separated by physical or virtual compensating controls — the classical split-subnet DMZ or perimeterized model of “inside” vs “outside.” They can do this given the direct operational control exposed by highly-virtualized infrastructure.  Sometimes they’re also forced into this given compliance and audit requirements. The issue here is that this discussion centers around molding cloud into the shape of the existing enterprise models and design patterns.

This is an issue; trying to simultaneously secure these diametrically-opposed architectural implementations yields cost inefficiencies, security disparity, policy violations, introduces operational risk and generally means that  the ball doesn’t get moved forward in protecting the things that matter most.

Public Cloud Computing is a good thing for the security machine; it forces us to (again) come face-to-face with the ugliness of the problems of securing the things that matter most — our information. Private Cloud Computing — when improperly viewed from the perspective of simply preserving the status quo — can often cause stagnation and introduce roadblocks.  We’ve got to move beyond this.

Public Cloud speaks to the needs (and delivers on) agility, flexibility, mobility and efficiency. These are things that traditional enterprise security are often not well aligned with.  Trying to fit “Cloud” into neat and tidy DMZ “boxes” doesn’t work.  Cloud requires revisiting our choices for security. We should take advantage of it, not try and squash it.

/Hoff

Related articles by Zemanta
Enhanced by Zemanta
Categories: Application Security, Cloud Computing, Cloud Security, Cloud Security Alliance, CloudAudit, Compliance, De-Perimeterization, Risk Assessment, Risk Management, Security Strategy, Virtualization, Virtualization Security Tags: , , , , ,

All For One, One For All? On Standardizing Virtual Appliance Operating Systems

June 11th, 2010 6 comments
SuSE logo
Image via Wikipedia

Hot on the tail of the announcement that VMware and Novell are entering into a deeper “strategic partnership” in order to deliver and support SUSE Linux Enterprise Server (SLES) for VMware vSphere environments, was an interesting blog post from Stu (@vinternals) titled “Enter the Appliance.”

Now, before we get to Stu’s post, let’s look at the language from the press release (the emphasis is mine):

VMware and Novell today announced an expansion to their strategic partnership with an original equipment manufacturer (OEM) agreement through which VMware will distribute and support the SUSE® Linux Enterprise Server operating system. Under the agreement, VMware also intends to standardize its virtual appliance-based product offerings on SUSE Linux Enterprise Server.

…

Customers who want to deploy SUSE Linux Enterprise Server for VMware® in VMware vSphere™ virtual machines will be entitled to receive a subscription to SUSE Linux Enterprise Server that includes patches and updates as part of their newly purchased qualifying VMware vSphere license and Support and Subscription. Under this agreement, VMware and its extensive network of solution provider partners will also be able to offer customers the option to purchase technical support for SUSE Linux Enterprise Server delivered directly by VMware for a seamless support experience. This expanded relationship between VMware and Novell benefits customers by reducing the cost and complexity of deploying and maintaining an enterprise operating system with VMware solutions.

As a result of this expanded collaboration, both companies intend to provide customers the ability to port their SUSE Linux-based workloads across clouds.  Such portability will deliver choice and flexibility for VMware vSphere customers and is a significant step forward in delivering the benefits of seamless cloud computing.

Several VMware products are already distributed and deployed as virtual appliances. A virtual appliance is a pre-configured virtual machine that packages an operating system and application into a self-contained unit that is easy to deploy, manage and maintain. Standardizing virtual appliance-based VMware products on SUSE Linux Enterprise Server for VMware® will further simplify the deployment and ongoing management of these solutions, shortening the path to ROI.

What I read here is that VMware virtual appliances — those VMware products packaged as virtual appliances distributed by VMware — will utilized SLES as the underlying operating system of choice. I don’t see language or the inference that other virtual appliance ISVs will be required to do so

To that point, Stu’s blog post said:

VMware will be adopting SUSE Linux Enterprise Server, SLES, as the single platform for their virtual appliances.

I’ve ranted in the past about the problem with virtual appliances. Everything from the lack of a standard Linux platform even within a single vendor (let alone amongst multiple vendors), to the additional overhead such a model of software distribution would place upon software vendors, to the security needs of the Enterprise around patch response times etc. And today, every single one of those arguments has been nullified in one fell swoop. Hallelujah, someone was listening after all!

So far, so good. Seems pretty much in-line with what VMware said.

Here’s the interesting assertion Stu makes that inspired my commentary:

If you’re a software vendor looking to adopt the virtual appliance model to distribute your wares then I have some advice for you – if you’re not using SLES for the base of your appliance, start doing so. Now. This partnership will mean doors that were previously closed to virtual appliances will now be opened, but not to any old virtual appliance – it will need to be built on an Enterprise grade distro. And SLES is most certainly that.

Chris Wolf, Stu and I had a bit of banter on Twitter regarding this announcement wherein I suggested there’s a blurring of the lines and a conflation of messaging as well as a very unique perspective that’s not being discussed.

Specifically, I don’t see where it was implied that ISV’s would be forced to adopt SLES as their OS of choice for virtual appliances.  I’m not suggesting it’s not compelling to do so for the support and distribution reasons stated above, but I suggest that the notion that “…doors that were previously closed to virtual appliances” from the perspective of support and uniformity of disto will also have and equal and opposite effect caused by a longer development lifecycle for many vendors.

Especially networking and security ISVs looking to move their products into a virtual appliance offering.

I summed up many of the issues associated with virtual security and networking appliances in my Four Horsemen of the Virtualization Security Apocalypse presentation, and given how the definition and capabilities of “the network” are (d)evolving (depending upon how you view abstraction) you might also find Where Are the Network Virtual Appliances? Hobbled By the Virtual Network, That’s Where… an interesting read:

What does this mean?  It means that ultimately to ensure their own survival, virtualization and cloud providers will depend less upon virtual appliances and add more of the basic connectivity AND security capabilities into the VMMs themselves as its the only way to guarantee performance, scalability, resilience and satisfy the security requirements of customers. There will be new generations of protocols, APIs and control planes that will emerge to provide for this capability, but this will drive the same old integration battles we’re supposed to be absolved from with virtualization and Cloud.

Tell me that’s not what’s happening *right* now.

Unlike most user-facing or service-delivery applications that are not topology sensitive (that is, they simply expect to be able to speak to “the network” without knowing anything about it,) network and security ISVs do very interesting things with drivers and kernel-space code in order to deal with topology, where they sit in the stack, and how they improve performance and stability that are extremely dependent upon direct access to hardware or at the very least, customer drivers or extended/hacked kernels.

One of the reasons you see a slow trickle of network and security virtual appliances is because of these bespoke OS builds and what virtualization has done to how these services are delivered, scaled and deal with resilience.  We’ve already seen the challenge of ISVs having to re-write code to fit the VMsafe fast/slow-path driver model.

You can imagine the consternation involved if what Stu alluded to is actually required — that you must build your virtual appliances on a specific OS.  It’s going to slow down innovation and delivery of solutions if the ISV does not (for any number of valid reasons) use SLES.  This is also one of the downsides of a JEOS approach.

Stu’s warnings about compliance to SLES development notwithstanding, this puts ISVs in a delicate position — one they’ve faced before but is now exacerbated by virtualization and Cloud.  Security vendors generally minimize and harden OS stacks to fit their “application” and then tune the environment accordingly.  We’re already introducing new monocultures and uniformity in attack surfaces with hypervisors.  Are we going to do the same with the operating systems that power the virtual appliances/virtual machines that run atop them — especially those designed to protect these very systems?

Diversity is a good thing — at least when it comes to your networking and security infrastructure.  While I happen to work for a networking vendor, we all recognize that uniformity brings huge benefits as well as the potential for nasty concerns.  If you want an example, check out how a simple software error affected tens of millions of users of WordPress (WordPress and the dark side of multitenancy.) While we’re talking about a different layer in the stack, the issue is the same.

I totally grok the standardization argument for the cost control, support and manageability reasons Stu stated but I am also fearful of the extreme levels of lock-in and monoculture this approach can take.

/Hoff

Related articles by Zemanta
Enhanced by Zemanta
Categories: Cloud Computing, Cloud Security, Virtualization, Virtualization Security, VMware Tags: , , , , , , , , ,

The Hypervisor Platform Shuffle: Pushing The Networking & Security Envelope

May 14th, 2010 1 comment

Last night we saw coverage by Carl Brooks Jo Maitland (sorry, Jo) of an announcement from RackSpace that they were transitioning their IaaS Cloud offerings based on the FOSS Xen platform and moving to the commercially-supported Citrix XenServer instead:

Jaws dropped during the keynote sessions [at Citrix Synergy] when Lew Moorman, chief strategy officer and president of cloud services at Rackspace said his company was moving off Xen and over to XenServer, for better support. Rackspace is the second largest cloud provider after Amazon Web Services. AWS still runs on Xen.

People really shouldn’t be that surprised. What we’re playing witness to is the evolution of the next phase of provider platform selection in Cloud environments.

Many IaaS providers (read: the early-point market leaders) are re-evaluating their choices of primary virtualization platforms and some are actually adding support for multiple offerings in order to cast the widest net and meet specific requirements of their more evolved and demanding customers.  Take Terremark, known for their VMware vCloud-based service, who is reportedly now offering services based on Citrix:

Hosting provider Terremark announced a cloud-based compliance service using Citrix technology. “Now we can provide our cloud computing customers even greater levels of compliance at a lower cost,” said Marvin Wheeler, chief strategy officer at Terremark, in a statement.

Demand for services will drive hypervisor-specific platform choices on the part of provider with networking and security really driving many of those opportunities. IaaS Providers who offer bare-metal boot infrastructure that allows flexibility of multiple operating environments (read: hypervisors) will start to make in-roads.  This isn’t a mass-market provider’s game, but it’s also not a niche if you consider the enterprise as a target market.

Specifically, the constraints associated with networking and security (via the hypervisor) limit the very flexibility and agility associated with what IaaS/PaaS clouds are designed to provide. What many developers, security and enterprise architects want is the ability to replicate more flexible enterprise virtualized networking (such as multiple interfaces/IP’s) and security capabilities (such as APIs) in Public Cloud environments.

Support of specific virtualization platforms can enable these capabilities whether they are open or proprietary (think Open vSwitch versus Cisco Nexus 1000v, for instance.)  In fact, Citrix just announced a partnership with McAfee to address integrated security between the ecosystem and native hypervisor capabilities. See Simon Crosby’s announcement here titled “Taming the Four Horsemen of the Virtualization Security Apocalypse” (it’s got a nice title, too 😉

To that point, are some comments I made on Twitter that describe these points at a high level:

I wrote about this in my post titled “Where Are the Network Virtual Appliances? Hobbled By the Virtual Network, That’s Where…” and what it means technically in my “Four Horsemen of the Virtualization Security Apocalypse” presentation.  Funny how these things come back around into the spotlight.

I think we’ll see other major Cloud providers reconsider their platform architecture from the networking and security perspectives in the near term.

/Hoff

Related articles by Zemanta
Reblog this post [with Zemanta]
Categories: Cloud Computing, Cloud Security, Virtualization, Virtualization Security Tags: , , , , , ,

You Can’t Secure The Cloud…

April 30th, 2010 3 comments

That’s right. You can’t secure “The Cloud” and the real shocker is that you don’t need to.

You can and should, however, secure your assets and the elements within your control that are delivered by cloud services and cloud service providers, assuming of course there are interfaces to do so made available by the delivery/deployment model and you’ve appropriately assessed them against your requirements and appetite for risk.

That doesn’t mean it’s easy, cheap or agile, and lest we forget, just because you can “secure” your assets does not mean you’ll achieve “compliance” with those mandates against which you might be measured.

Even if you’re talking about making investments primarily in solutions via software thanks to the abstraction of cloud (and/or virtualization) as well adjusting processes and procedures due to operational impact, you can generally effect compensating controls (preventative and/or detective) that give you security on-par with what you might deploy today in a non-Cloud based offering.

Yes, it’s true. It’s absolutely possible to engineer solutions across most cloud services today that meet or exceed the security provided within the walled gardens of your enterprise today.

The realities of that statement come crashing down, however, when people confuse possibility with the capability to execute whilst not disrupting the business and not requiring wholesale re-architecture of applications, security, privacy, operations, compliance, economics, organization, culture and governance.

Not all of that is bad.  In fact, most of it is long overdue.

I think what is surprising is how many people (or at least vendors) simply suggest or expect that the “platform” or service providers to do all of this for them across the entire portfolio of services in an enterprise.  In my estimation that will never happen, at least not if one expects anything more than commodity-based capabilities at a cheap price while simultaneously being “secure.”

Vendors conflate the various value propositions of cloud (agility, low cost, scalability, security) and suggest you can achieve all four simultaneously and in equal proportions.  This is the fallacy of Cloud Computing.  There are trade-offs to be found with every model and Cloud is no different.

If we’ve learned anything from enterprise modernization over the last twenty years, it’s that nothing comes for free — and that even when it appears to, there’s always a tax to pay on the back-end of the delivery cycle.  Cloud computing is a series of compromises; it’s all about gracefully losing control over certain elements of the operational constructs of the computing experience. That’s not a bad thing, but it’s a painful process for many.

I really enjoy the forcing function of Cloud Computing; it makes us re-evaluate and sharpen our focus on providing service — at least it’s supposed to.  I look forward to using Cloud Computing as a lever to continue to help motivate industry, providers and consumers to begin to fix the material defects that plague IT and move the ball forward.

This means not worrying about securing the cloud, but rather understanding what you should do to secure your assets regardless of where they call home.

/Hoff

Related articles by Zemanta

Reblog this post [with Zemanta]
Categories: Cloud Computing, Cloud Security, Cloud Security Alliance, CloudAudit, Virtualization, Virtualization Security Tags: , , , , , , , ,

The Four Horsemen Of the Virtualization (and Cloud) Security Apocalypse…

April 25th, 2010 No comments

I just stumbled upon this YouTube video (link here, embedded below) interview I did right after my talk at Blackhat 2008 titled “The 4 Horsemen of the Virtualization Security Apocalypse (PDF)” [There’s a better narrative to the PDF that explains the 4 Horsemen here.]

I found it interesting because while it was rather “new” and interesting back then, if you ‘s/virtualization/cloud‘ especially from the perspective of heavily virtualized or cloud computing environments, it’s even more relevant today!  Virtualization and the abstraction it brings to network architecture, design and security makes for interesting challenges.  Not much has changed in two years, sadly.

We need better networking, security and governance capabilities! 😉

Same as it ever was.

/Hoff

Related articles by Zemanta
Reblog this post [with Zemanta]
Categories: Cloud Computing, Cloud Security, Information Security, Information Survivability, Infrastructure 2.0, Networking, Security Innovation & Imagination, Virtualization, Virtualization Security Tags: , , , , , , ,