Rational Survivability

The premise of my Commode Computing presentation was to reinforce that we desperately require automation in all aspects of “security” and should work toward leveraging APIs in stacks and products to enable not only control but also audit and compliance across physical and virtualized solutions.

There are numerous efforts underway that underscore both this need and the industry’s response to such.  Platform providers (virtualization and cloud) are leading this charge given that much of their stacks rely upon automation to function and the ecosystem of third party solutions which provide value are following suit, also.

Most of the work exists around ensuring that the latest virtualized versions of products/solutions are API-enabled while the CLI/GUI-focused configuration of older products rely in many cases still on legacy management consoles or intermediary automation and orchestration “middlemen” to automate.

Here’s a great example of how one might utilize (Perl) scripting and RESTful APIs against VMware’s vShield Edge solution to provision, orchestrate and even audit firewall policies using their API. It’s a fantastic write-up from Richard Park of SourceFire (h/t to Davi Ottenheimer for the pointer):

Working with VMware vShield REST API in perl:

Here is an overview of how to use perl code to work with VMware’s vShield API.

vShield App and Edge are two security products offered by VMware. vShield Edge has a broad range of functionality such as firewall, VPN, load balancing, NAT, and DHCP. vShield App is a NIC-level firewall for virtual machines.

We’ll focus today on how to use the API to programatically make firewall rule changes. Here are some of the things you can do with the API:

• List the current firewall ruleset
• Add new rules
• Get a list of past firewall revisions
• Revert back to a previous ruleset revision

Awesome post, Richard.  Very useful. Thanks!

/Hoff

Related articles

• Can IPS Appliances Remain Useful in a Virtual-machine World? (pcworld.com)
• Clouds, WAFs, Messaging Buses and API Security… (rationalsurvivability.com)
• AWS’ New Networking Capabilities – Sucking Less 😉 (rationalsurvivability.com)
• Sourcefire Enables Application Control Within Virtual Environments (it-sideways.com)
• Using The Cloud To Manage The Cloud (informationweek.com)
• Virtualizing Your Appliance Is Not Cloud Security (securecloudreview.com)
• OpenFlow & SDN – Looking forward to SDNS: Software Defined Network Security (rationalsurvivability.com)

Cover via Amazon

I don’t think I’m verbalizing something very well…so I decided to write it down. I still don’t think I’m managing to stick my point, but perhaps clarity will come by discussion.

Simon Wardley has written about market dynamics and behaviors associated with the emergence and ultimate commoditization of things many, many times, but I’m not sure that I’ve found satisfaction in being able to accurately describe the dysfunctional co-dependency between consumer, leading vendor and ecosystem supporters to my liking.

Here’s an example…

There’s an uneasy tension that seems to often become nothing more than wink-and-nod-subtext in discussions relating to the various stacks offered by leading cloud and virtualization vendors.  Even those efforts with the “open” or “open source” descriptor bolted on for good measure.

It occurs to me that this can be attributed to many things; the business and licensing model of the solution provider, the ultimate “consumer” the offering targets, the area(s) of differentiation around technology, the maturity of the ecosystem, and the amount of self-integration versus vendor support required to successfully operationalize and maintain the solution.

More directly, the tension I refer to is the desire (or at least oft-verbalized complaints) on the behalf of “consumers” of cloud and virtualization stacks to not be “locked in” to a single vendor balanced against the odd juxtaposition — but not entirely unreasonable requirement — of simultaneously not being subject to the “integrator’s dilemma,” and having to support it all themselves.

Stir in the ecosystem of ISVs and solutions providers who orbit around these stacks, adding value where they have the “permission” to do so before either the stack provider obviates their existence by baking those features in directly, or simply makes it increasingly more difficult to roadmap given engineering dependencies they can’t control or count on.

I alluded to some of this in my blog titled Cloud Computing, Open* and the Integrator’s Dilemma wherein I mused:

I am just as worried about the fate of OpenStack and its enterprise versus service provider audience and how it’s being perceived as they watch the mad scramble by tech companies to add value and get a seat at the table.

Each of these well-intentioned projects are curated by public cloud operators and technology vendors and are indirectly positioned for the benefit of enterprises, but not really meant for their consumption — at least not if they don’t end up putting enterprises right back where they were trying to escape from in the first place with cloud computing: the integrator’s dilemma.

If you look at the underlying premise of OpenStack — it’s modularity, flexibility and open design — what you get is the ability to craft a solution finely tuned to an operating environment of your design. Integrate solutions into the stack as you see fit.  Contribute code.  Develop an ecosystem. Integrate, manage, maintain…

This is as much a problem as it is a solution for an enterprise.  This is why, in many cases, enterprises choose to use a single vendor with a single neck to choke in order to avoid having to act as an integrator in the first place or simply look to outsource to one or more public cloud providers and avoid this in the first place.

Chances are, most are realistically caught up somewhere in the nether-regions in between the two.

This all sounds so eerily familiar…

Related articles

• Cloud Computing, Open* and the Integrator’s Dilemma(rationalsurvivability.com)
• Citrix Leverages OpenStack With Project Olympus Cloud Platform (ostatic.com)
• RackSpace’s OpenStack Targets Cloud Lock-in (pcworld.com)
• More Signs of the Multiple-OS, Virtualized Future Are Appearing (ostatic.com)
• On balancing economic power in the FLOSS ecosystem (markshuttleworth.com)
• Citrix Commercializes OpenStack & Takes on VMware (gigaom.com)
• Impact of OpenStack Project Goes Beyond the Cloud Industry Leaders (readwriteweb.com)
• Incomplete Thought: The Curious Case Of the Carnival Cloud (rationalsurvivability.com)

Image via Wikipedia

In my Commode Computing talk, I highlighted the need for security automation through the enablement of APIs.  APIs are centric in architectural requirements for the provisioning, orchestration and (ultimately) security of cloud environments.

So there’s a “dark side” with the emergence of APIs as the prominent method by which one now interacts with stacks — and it’s highlighted in VMware’s vCloud Director Hardening Guide wherein beyond the normal de rigueur deployment of stateful packet filtering firewalls, the deployment of a Web Application Firewall is recommended.

Why?  According to VMware’s hardening guide:

In summary, a WAF is an extremely valuable security solution because Web applications are too sophisticated for an IDS or IPS to protect. The simple fact that each Web application is unique makes it too complex for a static pattern-matching solution. A WAF is a unique security component because it has the capability to understand what characters are allowed within the context of the many pieces and parts of a Web page.

I don’t disagree that web applications/web services are complex. I further don’t disagree that protecting the web services and messaging buses that make up the majority of the exposed interfaces in vCloud Director don’t require sophisticated protection.

This, however, brings up an interesting skill-set challenge.

How many infrastructure security folks do you know that are experts in protecting, monitoring and managing MBeans, JMS/JMX messaging and APIs?  More specifically, how many shops do you know that have WAFs deployed (in-line, actively protecting applications not passively monitoring) that did not in some way blow up every app they sit in front of as well as add potentially significant performance degradation due to SSL/TLS termination?

Whether you’re deploying vCloud or some other cloud stack (I just happen to be reading these docs at the moment,) the scope of exposed API interfaces ought to have you re-evaluating your teams’ skillsets when it comes to how you’re going to deal with the spotlight that’s now shining directly on the infrastructure stacks (hardware and software) their private and public clouds.

Many of us have had to get schooled on web services security with the emergence of SOA/Web Services application deployments.  But that was at the application layer.  Now it’s exposed at the “code as infrastructure” layer.

Think about it.

/Hoff

[Update 6/7/11 – Here are two really timely and interesting blog posts on the topic of RESTful APIs:

• George Reese’s The Good, the Bad, and the Ugly of REST APIs and
• Mark O’Neill’s The REST Doggy Door

Mark’s post has some links to some videos on secure API deployment]

Related articles

• I love WAFs and so should you. (jarrodloidl.blogspot.com)
• AWS’ New Networking Capabilities – Sucking Less 😉 (rationalsurvivability.com)
• Should We Be Limiting Developers API Usage? (programmableweb.com)
• Glass House Syndrome and the Security Industry (ashimmy.com)
• Securing VMware (imperva.com)
• Barracuda Networks Breached (acunetix.com)

Image via Wikipedia

As a follow-on example to my blog titled The Curious Case of the MBO Cloud, in which I detailed the mad rush of companies to deploy something — anything — that looks like a “cloud” to achieve an artificial benchmark of cloudiness, I present you the oft-experienced “Carnival Cloud.”

What’s a Carnival Cloud?

Have you been to Disneyland?  Perhaps a Six Flags theme park?  Perhaps even Coney Island?  If so,  you’ve likely marveled at the engineering and physics associated with some of the rides.  Seeing a train of interconnected people haulers hurtling around a steel (or wooden) substructure of vomit-inducing gravity abuse is a marvelous thing.

I saw a documentary on the construction of some of these modern wonders.  Amazing.  Well modeled, precision engineered, expertly designed and a remarkably good track record of safety.  Yes, sometimes bad things happen, but rarely do you see a rollercoaster at a theme park decommissioned due to inherent design flaws.

I do however sometimes reflect on these rides and the notion that one willingly slaps down some money, straps in, gets rocketed around at 60+ mph pulling G’s rivaling that of some fighter aircraft and realize there’s really no Plan B should something go ass over tea kettles.

One simply has to trust in the quality of design, the skills of the engineering, the on-going maintenance efforts and the 16 year old who pushes the go-button after your crotch-squashing safety bar is slammed into one’s lap and morphs your unmentionables.

…keep your hands inside the ride at all times…

We trust that we’ll come out the other side and give no pause to the fact that the hopes for such are granted by the fact that these rides are often heavily automated, computer controlled and are instrumented to detect failure or flaw.

Now, have you been to a local fair or carnival?

Contrast your experience at Six Flags — often with the same level of risk — with a local carnival ride that’s unloaded from the back of a 1972 Chevy Stepsider, bolted together (and repeatedly unbolted) with some handtools and the sticky residue of lubricating oil and cotton candy.

I don’t know about you, but putting my life in the hands of carnie who does double duty as the bearded lady doesn’t inspire confidence, especially when the Tilt-o-whirl has the potential to demonstrate the unfortunate ramifications of cascading failure domains in physics that run well beyond the fact the some of these operators can’t count past the 4 missing fingers they have on their right hand.

This isn’t saying that carnivals aren’t fun.  This isn’t implying that toothliness ain’t close to Godliness (especially when the afterlife is one missing bolt away.) This isn’t saying you shouldn’t go, thereby missing the nacho cheese-dipped pretzel logs and colon-clogging funnel cakes.

Nay, the point is to simply suggest that there’s a lot to be said for solid infrastructure — regardless of where it’s sourced — that’s performant, safe, operated and maintained in a ruthlessly diligent manner, instrumented well and is subject to constant rigor and inspection.

Relating that to cloud, your experience — depending upon your appetite for risk (and nacho cheese) — will dictate whether your E-ticket ride ends well or as a footnote on MSNBC.

Mmmm. Ableskivers and giant stuffed armadillos.  Anyone got change for a $20?

/Hoff

Related articles

• NY and PA Injury Lawyer: Dangers Lurk at Fairs, Carnivals and Amusement Parks (zifflaw.com)
• 3 rescued from carnival ride (faircarnivals.com)
• Cloud Computing, Open* and the Integrator’s Dilemma (rationalsurvivability.com)

The best summary I could come up with:

Image via Wikipedia

In case you weren’t aware, NIST has a WIKI for collaboration on Cloud Computing.  You can find it here.

They also have a draft of their v1.0 Cloud Computing Reference Architecture, which builds upon the prior definitional work we’ve seen before and has pretty graphics.  You can find that, here (dated 3/30/2011)

/Hoff

Related articles

• NIST Issues Cloud Security Guidelines (informationweek.com)
• NIST formalizes cloud computing definition, issues security and privacy guidance – CSO (sectorprivate.wordpress.com)

Image via Wikipedia

With my focus on cloud security, I’m always fascinated when derivative business models arise that take the issues associated with “mainstream” cloud adoption and really bring issues of security, compliance and privacy into even sharper focus.

To wit, Enomaly recently launched SpotCloud – a Cloud Capacity Clearinghouse & Marketplace in which cloud providers can sell idle compute capacity and consumers may purchase said capacity based upon “…location, cost and quality.”

Got a VM-based workload?  Want to run it cheaply for a short period of time?

…Have any security/compliance/privacy requirements?

To me, “quality” means something different that simply availability…it means service levels, security, privacy, transparency and visibility.

Whilst one can select the geographic location where your VM will run, as part of offering an “opaque inventory,” the identity of the cloud provider is not disclosed.  This begs the question of how the suppliers are vetted and assessed for security, compliance and privacy.  According to the SpotCloud FAQ, the answer is only a vague “We fully vet all market participants.”

There are two very interesting question/answer pairings on the SpotCloud FAQ that relate to security and service availability:

How do I secure my SpotCloud VM?

User access to VM should be disabled for increased security. The VM package is typically configured to automatically boot, self configure itself and phone home without the need for direct OS access. VM examples available.

Are there any SLA’s, support or guarantees?

No, to keep the costs as low as possible the service is offered without any SLA, direct support or guarantees. We may offer support in the future. Although we do have a phone and are more than happy to talk to you…

:: shudder ::

For now, I would assume that this means that if your workloads are at all mission critical, sensitive, subject to compliance requirements or traffic in any sort of sensitive data, this sort of exchange option may not be for you. I don’t have data on the use cases for the workloads being run using SpotCloud, but perhaps we’ll see Enomaly make this information more available as time goes on.

I would further assume that the criteria for provider selection might be expanded to include certification, compliance and security capabilities — all the more reason for these providers to consider something like CloudAudit which would enable them to provide supporting materials related to their assertions. (*wink*)

To be clear, from a marketplace perspective, I think this is a really nifty idea — sort of the cloud-based SETI-for-cost version of the Mechanical Turk.  It takes the notion of “utility” and really makes one think of the options.  I remember thinking the same thing when Zimory launched their marketplace in 2009.

I think ultimately this further amplifies the message that we need to build survivable systems, write secure code and continue to place an emphasis on the security of information deployed using cloud services. Duh-ja vu.

This sort of use case also begs the interesting set of questions as to what these monolithic apps are intended to provide — surely they transit in some sort of information — information that comes from somewhere?  The oft-touted massively scaleable compute “front-end” overlay of public cloud often times means that the scale-out architectures leveraged to deliver service connect back to something else…

You likely see where this is going…

At any rate, I think these marketplace offerings will, for the foreseeable future, serve a specific type of consumer trafficking in specific types of information/service — it’s yet another vertical service offering that cloud can satisfy.

What do you think?

/Hoff

Related articles

• Spotcloud launches cloud computing clearinghouse (zdnet.com)
• Are There Tax Breaks in The Cloud? (datacenterknowledge.com)
• SpotCloud Launches Today: What Kind Of An Impact Will It Have? (cloudave.com)
• ComputeNext: Google For Compute Resources (cloudave.com)
• ScaleUp Enables A Federated Cloud Ecosystem (diversity.net.nz)
• Dark Clouds: Can you trust the Cloud? Panel on Feb 4th at Cloud Communications Summit in Miami (voipsa.org)

There are lots of reasons one might use to illustrate why operationalizing security — both from the human and technology perspectives — doesn’t scale.

I’ve painted numerous pictures highlighting the cyclical nature of technology transitions, the supply/demand curve related to threats, vulnerabilities, technology and compensating controls and even relevant anecdotes involving the intersection of Moore’s and Metcalfe’s laws.  This really was a central theme in my Cloudinomicon presentation; “idempotent infrastructure, building survivable systems and bringing sexy back to information centricity.”

Here are some other examples of things I’ve written about in this realm.

Batting around how public “commodity” cloud solutions forces us to re-evaluate how, where, why and who “does” security was an interesting journey.  Ultimately, it comes down to architecture and poking at the sanctity of models hinged on an operational premise that may or may not be as relevant as it used to be.

However, I think the most poignant and yet potentially obvious answer to the “why doesn’t security scale?” question is the fact that security products, by design, don’t scale because they have not been created to allow for automation across almost every aspect of their architecture.

Automation and the interfaces (read: APIs) by which security products ought to be provisioned, orchestrated, and deployed are simply lacking in most security products.

Yes, there exist security products that are distributed but they are still managed, provisioned and deployed manually — generally using a management hub-spoke model that doesn’t lend itself to automated “anything” that does not otherwise rely upon bubble-gum and bailing wire scripting…

Sure, we’ve had things like SNMP as a “standard interface” for “management” for a long while 😉  We’ve had common ways of describing threats and vulnerabilities.  Recently we’ve seen the emergence of XML-based APIs emerge as a function of the latest generation of (mostly virtualized) firewall technologies, but most products still rely upon stand-alone GUIs, CLIs, element managers and a meat cloud of operators to push the go button (or reconfigure.)

Really annoying.

Alongside the lack of standard API-based management planes, control planes are largely proprietary and the output for correlated event-driven telemetry at all layers of the stack is equally lacking.  Of course the applications and security layers that run atop infrastructure are still largely discrete thus making the problem more difficult.

The good news is that virtualization in the enterprise and the emergence of the cultural and operational models predicated upon automation are starting to influence product roadmaps in ways that will positively affect the problem space described above but we’ve got a long haul as we make this transition.

Security vendors are starting to realize that they must retool many of their technology roadmaps to deal with the impact of dynamism and automation.  Some, not all, are discovering painfully the fact that simply creating a virtualized version of a physical appliance doesn’t make it a virtual security solution (or cloud security solution) in the same way that moving an application directly to cloud doesn’t necessarily make it a “cloud application.”

In the same way that one must often re-write or specifically design applications “designed” for cloud, we have to do the same for security.  Arguably there are things that can and should be preserved; the examples of the basic underpinnings such as firewalls that at their core don’t need to change but their “packaging” does.

I’m privy to lots of the underlying mechanics of these activities — from open source to highly-proprietary — and I’m heartened by the fact that we’re beginning to make progress.  We shouldn’t have to make a distinction between crafting and deploying security policies in physical or virtual environments.  We shouldn’t be held hostage by the separation of application logic from the underlying platforms.

In the long term, I’m optimistic we won’t have to.

/Hoff

Related articles

• Don’t Conflate Virtual with Dynamic (devcentral.f5.com)
• Seeing Through The Clouds: Understanding the Options and Issues (thesecuritysamurai.com)
• The Fallacies of Distributed Computing Reborn: The Cloud Era (newrelic.com)
• Gazing into the Crystal Ball: GigaOm on APIs in 2011 (programmableweb.com)
• NSA To Assume Security Is Compromised (securosis.com)
• Seeing Through The Clouds: Understanding the Options and Issues (thesecuritysamurai.com)

• The Fallacies of Distributed Computing Reborn: The Cloud Era (newrelic.com)
• Gazing into the Crystal Ball: GigaOm on APIs in 2011 (programmableweb.com)
• NSA To Assume Security Is Compromised (securosis.com)

* Update:  A few hours after writing this last night, AWS announced they had achieved Level 1 PCI DSS Compliance.* If you pay attention to how the announcement is worded, you’ll find a reasonable treatment of what PCI compliance means to an IaaS cloud provider – it’s actually the first time I’ve seen this honestly described:

Merchants and other service providers can now run their applications on AWS PCI-compliant technology infrastructure to store, process and transmit credit card information in the cloud. Customers can use AWS cloud infrastructure, which has been validated at the highest level (Level 1) of PCI compliance, to build their cardholder environment and achieve PCI certification for their applications.

Note how they phrased this, then read my original post below.

However, pay no attention to the fact that they chose to make this announcement on Pearl Harbor Day 😉

—

Here’s the thing…

A cloud provider can achieve compliance (such as PCI — yes v2.0 even) such that the in-scope elements of that provider which are audited and assessed can ultimately contribute to the compliance of a customer operating atop that environment.  We’ve seen a number of providers assert compliance across many fronts, but they marketed their way into a yellow card by over-reaching…

It should be clear already, but for a service to be considered compliant, it clearly means that the customer’s in-scope elements running atop a cloud provider must also undergo and achieve compliance.

That means compliance is elementally additive the same way “security” is when someone else has direct operational control over elements in the stack you don’t.

In the case of an IaaS cloud provider who may achieve compliance from the “concrete to the hypervisor,” (let’s use PCI again,) the customer in turn must have the contents of the virtual machine (OS, Applications, operations, controls, etc.) independently assessed and meet PCI compliance in order that the entire stack of in-scope elements can be described as compliant.

Thus security — and more specifically compliance — in IaaS (and PaaS) is a shared responsibility.

I’ve spent many a blog battling marketing dragons from cloud providers that assert or imply that by only using said provider’s network which has undergone and passed one or more audits against a compliance framework, that any of its customers magically inherit certification by default. I trust this is recognized as completely false.

As compliance frameworks catch up to the unique use-cases that multi-tenancy and technologies such as virtualization bring, we’ll see more “compliant cloud” offerings spring up, easing customer pain related to the underlying moving parts.  This is, for example, what FedRAMP is aiming to provide with “pre-approved” cloud offerings.  We’ve got visibility and transparency issues to solve , as well as temporal issues such as the frequency and period of compliance audits, but there’s progress.

We’re going to see more and more of this as infrastructure- and platform-as-a-service vendors look to mutually accelerate compliance to achieve that which software-as-a-service can more organically deliver as a function of stack control.

/Hoff

* Note: It’s still a little unclear to me how some of the PCI requirements are met in an environment like an IaaS Cloud provider where “applications” that we typically think of that traffic in PCI in-scope data don’t exist (but the infrastructure does,) but I would assume that AWS leverages other certifications such as SAS and ISO as a cumulative to petition the QSA for consideration during certification.  I’ll ask this question of AWS and see what I get back.

Related articles

• Navigating PCI DSS (2.0) – Related to Virtualization/Cloud, May the Schwartz Be With You! (rationalsurvivability.com)
• Seeing Through The Clouds: Understanding the Options and Issues (thesecuritysamurai.com)
• I’ll Say It Again: Security Is NOT the Biggest Barrier To Cloud… (rationalsurvivability.com)
• PCI 2.0 Allows For Compliant Clouds, Make Sure Your Service Providers Are PCI Compliant (securecloudreview.com)
• What’s The Problem With Cloud Security? There’s Too Much Of It… (rationalsurvivability.com)
• FedRAMP. My First Impression? We’re Gonna Need A Bigger Boat… (rationalsurvivability.com)
• Mixed Mode and PCI DSS 2.0 (brandenwilliams.com)
• The Future Of Audit & Compliance Is…Facebook? (rationalsurvivability.com)
• Incomplete Thought: Compliance – The Autotune Of The Security Industry (rationalsurvivability.com)

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

• HyTrust Cloud Control Unveiled to Enable Accelerated Cloud Adoption (eon.businesswire.com)
• Catbird and HyTrust Team to Provide End-to-End Protection and Compliance for Virtual Infrastructure (eon.businesswire.com)
• The Classical DMZ Design Pattern: How To Kill Security In the Cloud (rationalsurvivability.com)
• The Security Hamster Sine Wave Of Pain: Public Cloud & The Return To Host-Based Protection… (rationalsurvivability.com)
• CLOUDINOMICON: Idempotent Infrastructure, Survivable Systems & Bringing Sexy Back to Information Centricity (rationalsurvivability.com)
• The Hypervisor Platform Shuffle: Pushing The Networking & Security Envelope (rationalsurvivability.com)
• Altor V4 – security in virtualized environments and the cloud (zdnet.com)