Per the article above "Now he’s one of the first victims of such an attack. "It’s funny," he said. "I got owned."*

Yeah, real funny.

/Hoff

* There’s lots of thrashing going on as to the veracity of HD’s quote rearding being owned. Regardless of the theatrics involved, it’s interesting food for thought when the result of exploit research might be turned against the researcher…

I wanted to make you aware of a "new" excellent budding resource for VMware infrastructure, VMware’s VI:Ops – Virtual Infrastructure Operations. Steve Chambers of VMware pointed me over to the site which is growing in both content and contributors.

VI:Ops currently includes the following sections:

Strategies and solutions using virtualization

Building
and managing virtual infrastructure with open, industry standards

One of my responsibilities as security cruise ship entertainment director is to distill the most complex things down into bite-sized digestible nuggets of chewy informative goodness whilst ensuring a good time is had by all.

It is in this spirit that I offer this gem regarding the release of PoC/Exploit code by supposed "whitehats" immediately after the disclosure of a nasty vulnerability. This post is random, of course, and is in no way a reference to any current event.

This quip was brought to you via Twitter which managed to stay up and functional long enough for me to tweet it:

POC code for near-zero day ‘sploits is like SPAM advertising penis-extending drugs…the only dick it’s helping is the one writing it…

Multifunction network devices that have the ability to "route" traffic and combine security capabilities are the ‘next big thing’

If a company offers a multifunction network device that has the ability to "route" traffic and combine security capabilities but have the misfortune of using Linux as the operating system, they will "…forever be pigeon-holed as SMB solutions, not ready for enterprise
prime time."

The Wall Street Journal issued "… the year’s most important article on networking" in an article titled "New Routers Catch the Eyes of IT Departments" which validates the heretofore undiscovered trend of convergence and commoditization!

"Real" network security players such as Cisco, Juniper and Redback are building solutions to this incredible new trend and because of the badge on the box, will be considered ready for "…enterprise prime time."

The WSJ article talks about the Cisco ASR1000 router as the penultimate representation of this new breed of converged "network security" device.

Strangely, Stiennon seems to have missed the fact that the operating system (IOS-XE) that the ASR1000 is based on is, um, Linux. You know, that operating system that dictates that this poor product will "…forever be pigeon-holed as SMB solutions, not ready for enterprise
prime time."

Oh, crap! Somebody better tell Cisco!

So despite the fact that Cisco ASR1000 is positioned as an edge device as are these crazy solutions called UTM devices, it seems we’re all missing something because somehow a converged edge device now counts as being able to provide a "secure network fabric?"

In closing, allow me to highlight the cherry on top of Stiennon’s security sundae:

Have you ever noticed how industry "experts" tend to get stuck in
a rut and continue to see everything through the same lens despite
major shifts in markets and technology?

For the second time in some months, Amazon’s S3 (Simple Storage Service,) one of the most "invisibly visible" examples of the intersection of Web2.0 and cloud computing, has suffered some noticeable availability hiccups.

Many well-known companies such as Twitter rely upon content hosted via Amazon’s S3 which is billed as offering the following capabilities:

Amazon S3 provides a simple web services interface
that can be used to store and retrieve any amount of data, at any time,
from anywhere on the web. It gives any developer access to the same
highly scalable, reliable, fast, inexpensive data storage
infrastructure that Amazon uses to run its own global network of web
sites. The service aims to maximize benefits of scale and to pass those
benefits on to developers.

It’s not realistic to think that infrastructure as complex as this won’t suffer service disruption, but one has to wonder what companies who rely on the purported resiliency of the "cloud" from a single provider do in cases where like it’s namesake, the skies open up and the service takes a dump?

I’ll go one further. If today you happen to use S3 for content hosting and wanted like-for-like functionality and service resiliency with a secondary provider, would your app. stack allow you to pull it off without downtime?

I was having an interesting discussion the other evening at BeanSec with Jeanna Matthews from Clarkson University. Jeanna is one of the authors of what I think is the best book available on Xen virtualization, Running Xen.

In between rounds of libations, the topic of Hypervisor-neutral, VM portability/interoperability between the virtualization players (see right) came up. If I remember correctly, we were discussing the announcement from Citrix regarding Project Kensho:

On the surface, this sounded like a really interesting and exciting development regarding interoperability between virtualization platforms and the VMs that run on them. Digging deeper, however, it’s not really about virtualization at all; it’s about the delivery of applications and services — almost in spite of the virtualization layer — which is something I hinted about at the end of this post.

I am of the opinion that virtualization is simply
a means to an end, a rationalized and cost-driven stepping-stone along the path of
designing, provisioning, orchestrating, deploying, and governing a more agile, real time
infrastructure to ensure secure, resilient, cost-effective and dynamic delivery of service.

You might call the evolution of virtualization and what it’s becoming cloud computing. You might call it utility computing. You might call it XaaS. What many call it today is confusing, complex, proprietary and a pain in the ass to manage.

Thus, per the press release regarding Project Kensho, the notion of packaging applications/operating environments up as tasty little hypervisor-neutral nuggets in the form of standardized
virtual appliances that can run anywhere on any platform is absolutely appealing and in the long term, quite necessary.*

However, in the short term, I am left wondering if this is a problem being "solved" for ISV’s and virtualization platform providers or for customers? Is there a business need today for this sort of solution and is the technology available to enable it?

Given the fact that my day job and paycheck currently depends upon crafting security strategies, architecture and solutions for real time infrastructure, I’m certainly motivated to discuss this. Mortgage payment notwithstanding, here’s a doozy of a setup:

Given where we are today with the heterogeneous complexity and nightmarish management realities of our virtualized and non-virtualized infrastructure, does this really solve relevant customer problems today or simply provide maneuvering space for virtualization platform providers who see their differentiation via the hypervisor evaporating?

While the OVF framework was initially supported by a menagerie of top-shelf players in the virtualization space, it should come as no surprise that this really represents the first round in a cage match fight to the death for who wins the application/service delivery management battle.

You can see this so clearly in the acquisition strategies of VMware, Citrix and Microsoft.

Check out the remainder of the press release. The first half had a happy threesome of Citrix, Microsoft and VMware taking a long walk on the beach. The second half seems to suggest that someone isn’t coming upstairs for a nightcap:

Added Value for Microsoft Hyper-V

Project Kensho will also enable customers to leverage the
interoperability benefits and compatibility between long-time partners
Citrix and Microsoft to extend the Microsoft platform. For example,
XenServer is enhanced with CIM-based management APIs to allow any
DMTF-compliant management tool to manage XenServer, including Microsoft
System Center Virtual Machine Manager. And because the tools are based
on a standards framework, customers are ensured a rich ecosystem of
options for virtualization. In addition, because of the open-standard
format and special licensing features in OVF, customers can seamlessly
move their current virtualized workloads to either XenServer or
Hyper-V, enabling them to distribute virtual workloads to the platform
of choice while simultaneously ensuring compliance with the underlying
licensing requirements for each virtual appliance.

Project Kensho will support the vision of the Citrix Delivery Center™
product family, helping customers transform static datacenters into
dynamic “delivery centers” for the best performance, security, cost
savings and business agility. The tools developed through Project
Kensho will be easily integrated into Citrix Workflow Studio™ based
orchestrations, for example, to provide an automated, environment for
managing the import and export of applications from any major
virtualization platform.

Did you catch the subtlety there? (Can you smell the sarcasm?)

I’ve got some really interesting examples of how this is currently shaking out in very large enterprises. I intend to share them with you, but first I have a question:

What relevance do hypervisor-neutral virtual appliance/machine deployments have in your three year virtualization roadmaps? Are they a must-have or nice-to-have? Do you see deploying multiple hypervisors and needing to run these virtual appliances across any and all platforms regardless of VMM?

Of course it’s a loaded question. Would you expect anything else?

/Hoff

* There are some really interesting trade-offs to be made when deploying virtual appliances. This is the topic of my talk at Blackhat this year titled "The Four Horsemen of the Virtualization Apocalypse"

Edward’s primary problem with the benchmark can be summarized well by this paragraph:

While the Benchmark was the first of its kind, it is nothing more than the Linux benchmark with some small changes for VMware ESX. Following these steps will increase security but it is by no means a panacea. Do not let it give you a false sense of security.

I think Edward set his expectations a little high prior to review, as I’m pretty sure the word panacea wasn’t used in the syllabus 😉

I don’t disagree with Edward that the flavor of the benchmark is very much a generic set of guidelines focused primarily on securing the underlying Linux-based service console and basic configuration for overall "system" hardening, but we need to realize a couple of things to keep the benchmark in perspective:

The benchmark was the first of its kind. It’s almost 10 months old! The second version is underway right now as a matter of fact.

In between when the benchmark was released and now, we’ve seen the emergence of the embedded version of VMware and much needs to change to address that.

The benchmark was designed to be generic and give virtual system administrators a baseline on basic security hardening, not serve as the end-all, be-all for some mythical security end-state.

The challenge for those of us who contributed (as I did) was that we had to keep the document vendor/tool agnostic which makes it difficult to frame solutions.

Lots of things have changed.

Keep in mind that this is a "level 1" benchmark whose settings/actions are as follows:

Can be understood and performed by system administrators with any level of security knowledge and experience;

Are unlikely to cause an interruption of service to the operating system or the applications that run on it; and

Can be automatically monitored either by CIS Scoring Tools or by CIS Certified tools available from security software vendors.

This isn’t about being defensive regarding the benchmark as I’ll agree that we could have done much, much more in terms of providing more meatier substance as it relates to how to better secure the ecosystem of mechanicals that a virtualized environment touches.

However, the scope of a document that effectively addresses the security concerns across this immense landscape would be a huge undertaking.

One of the other difficulties in creating a guideline like this is the fact that those responsible for securing virtualized environments are not security professionals. As I’ve spoken about previously, the operational realities of who is managing and securing our virtualized infrastructure is cause for concern.

Thus, when creating a guide like this, it’s best to start with the underlying basics and then branch out from there; involve the network and security teams as required. As Edward himself wrote in this piece, "Good virtual security requires better IT teamwork," to properly secure your virtualized infrastructure, it’s going to take cooperation and expertise from many camps.

BeanSec! is an informal meetup of information security
professionals, researchers and academics in the Greater Boston area
that meets the third Wednesday of each month.

I say again, BeanSec! is hosted the third Wednesday of every month. Add it to your calendar.

Come get your grub on. Lots of good people show up. Really.

Unlike other meetings, you will not be expected to pay dues, “join
up”, present a zero-day exploit, or defend your dissertation to attend.

Middlesex Lounge: 315 Mass Ave, Cambridge 02139. We are moving locations due to better seating and the fact that the Enormous Room (our prior location) no longer serves food. ;(

Don’t worry about being "late" because most people just show up when they can. 6:30 is a good time to aim for. We’ll try and save you a seat. There is a plenty of parking around or take the T.

In case you’re wondering, we’re getting about 30 people on average per BeanSec! Weld, 0Day and I have been at this for just almost 2 years and without actually *doing* anything, it’s turned out swell.

The food selection is basically high-end finger-food appetizers and the drinks are really good; an attentive staff and eclectic clientèle make the joint fun for people watching. I’ll generally annoy you into participating somehow, even if it’s just fetching napkins. 😉