Who should secure virtual IT environments?

Security blogger Chris Hoff and Citrix CTO Simon Crosby discuss whether security companies or virtualization vendors should be responsible for the security of virtual environments. The two security experts sat on a panel discussion with VMware's Stephen Herrod at the 2009 RSA Conference in which the future of virtualization technology was discussed. The experts agreed that the evolution of the technology could change drastically over the next 18 months. The interview was conducted by Information Security magazine's Michael S. Mimoso.

Part 1: Who whould be responsible for security of virtual environments?

Part 2: Crosby and Hoff talk about how the industry is challenged by vendor proprietary interests despite the desire by customers for highly automated environments.

Read the full text transcript from this video below. Please note the full transcript is for reference only and may include limited inaccuracies. To suggest a transcript correction, contact editor@searchsecurity.com.  

Who should secure virtual IT environments?

Mike Mimoso: Hi, I'm Mike Mimoso, editor of Information Security magazine, and
joining me today are Simon Crosby of Citrix and Chris Hoff. We're going to
be discussing virtualization and security. So, I want to start off with a
question to both of you about who should be responsible for the security of
virtualized environments. So, Chris, I want to talk to you first. You've
argued in the past that VM vendors should absorb that responsibility. How
would you suggest that an infrastructure vendor contribute to security,
especially when it's not their core competency?

Chris Hoff: The important part there is to a degree. My feeling is that, and my
belief is that, ultimately there is a responsibility on the part of any
platform provider, whether it be a virtualization platform for an
operating system provider, or somebody who provides a security appliance
network function, to do two things. Number one, obviously make their
platform as secure as it possibly can be. But given the investment that
people make in their security infrastructure, a lot of times the new
products that are rolled out, whether it's a virtualization platform or a
new security tool, often times expects kind of the green field of approach
forklift of everything they already have. So, the notion of being able to
imbed enough functionality that bolsters the underlying platform but then
also exposes certain functionality to make the integration of the ecosystem
also function is pretty important. So, you know, the percentage-wise is not
something I care to get into in detail. I just want to make the point that
there is a certain amount of functionality besides the platform itself, and
just securing that needs to be exposed in some form or function in a way
that is safe, and ensures that the ecosystem can also function.

Mike Mimoso: Simon, where do you see the virtualization vendors roll in security?

Simon Crosby: Well, it's pretty difficult to disagree with what Chris said. It is
a very balanced statement. I think the key issue, from a virtualization
platform perspective is that our view is that it should be minimal, as
minimalist as possible. And I think where Chris and I would agree is that
what you want is an architectural agreement on how security functions, then
apply. My biggest worry is that in a world which is dominated by a single
virtualization vendor, VMware being encumbent, they start to dictate an
architecture which actually breaks security, or limits the ability of the
ISVs to innovate around it or dictates new ways which aren't necessarily
secure, or whatever. I don't like that as an architecture. I'd like to see
broad agreement across the industry on how virtualization and virtualized
infrastructure generally, should provide interfaces so that security
functions can be implemented, so you can guarantee compliance, and all that
sort of stuff. And I worry very sincerely about what I'm seeing in the
industry, which is an increasing trend towards locking these things up.
Just by way of example, VMsafe was announced well over a year ago, and
everybody was on stage, it looked like a great thing. But the black hatters
hate it, and I haven't yet seen one product. And when I talked to those
vendors they all hate that thing, right? Everybody hates it. And so, what I
worry about is that the security industry is being wagged by the tail, or
maybe the virtualization guys are wagging this security dog by the tail,
and I worry about that because I don't think you end up with a more secure
system. And I worry that we are losing opportunities to enhance security as
a result. So, I think we can make security better, and I don't think we're
doing that.

Mike Mimoso: So, can we expect a response to VMsafe from Citrix?

Simon Crosby: The Xen community has its own interface there. In general, I'd say
the security industry isn't wild about VMsafe for several reasons. First
of all, it's not the core competency of the security vendors today to poke
around in memory blocks and find bad guys. That's not what they do. They
are used to being in-guest, understanding key interfaces and key
transition state, stateful transitions within a guest that allow them to
infer that a thing is going on. Just telling them to go and poke around in
the memory block and find the bad guy is not what they do today. It's a
complete rewrite for them. Okay. In general, they are in a tough place,
because with Windows 64-bit locking down the OS anyway, they're finding it
a tricky place for them, which is where the heck do they go? But there's a
nice opportunity, I believe, in whitelisting, and we can
provide them a home in terms of giving them key interfaces so they can
white list and see what's happening in the page table, and tons of cool
things can go on there. Yes, the Xen community has its own equivilent to VM
Safe. What worries me about VMsafe is that it's still proprietary. I still
can't see it. And as far as I'm aware, therefore, it is not subject to
scrutiny, and I just have to believe that it's safe. And that's not good
enough for me.

Chris Hoff: So, just a couple of counterpoints too. The definition of core
competency is pretty relevant here, too. When you look at virtualization
platforms, whosever, and the ubiquity of their delivery in today's
infrastructure, to me it's the equivalent, of, albeit slim, but an operating
system. And when we look at what is required in many cases with operating
systems we have today, in terms of developing a core competency in
security, you can hear from Microsoft that they are trying to position that
message for lots of interesting reasons, right, wrong, or indifferent. One
has to really be careful about defining the scope of security, especially
in relevance of what you mean by competency. So, if security by classical
definition is confidentiality, integrity, and availability, and you take
the CISSP test, availability and integrity are two very important
functions; confidentiality also. And the notion of limiting, in Simon's
description of security vendors is, I think, a little narrow in scope.
Because those that operate within the construct of the guest absolutely I
think is an accurate description of not operating the way in which
currently they are being asked to operate. But we have a whole other side
of the network and network appliance-based security vendors that VMsafe
and technologies like that do actually help quite a bit. So, that opens
then initiatives that, for example, aren't necessarily as developed or
robust currently in terms of adoption by folks that are willing to use
them. And VMsafe is kind of an interesting thing. I agree, like two years
ago it was announced on the floor and everyone was frothing at the mouth
and it seemed like a good thing. Here we are two years later, and it's
really taken this amount of time to kind of get it off the ground, but what
people didn't realize, and given my background in trying to integrate other
people's products into a platform, in one of my previous jobs, getting
people modify their roadmaps to align to yours, while that code base is
changing on both fronts--very difficult. So that has been an interesting
stumbling block, but what I've discovered also is that if you go back and
look, and I think this will be a bit of an equalizer, in terms of some of
these platforms, Microsoft also. VMware, and to the first question, VMware
made an acquisition through Blue Lane, who was the third party ISP.
And what they actually did was they stripped away a bunch of functionality
out of the Blue Lane product, and they've built and are demoing here today.
I'm using this to defend VMware; I'm just using it as an example to
actually agree with what you're saying. They realized that the ecosystem as
it stands is incredibly diverse, large vendors, small vendors. And trying
to get them to modify code is a very painful process, you're interrupting
the roadmap. So, to Simon's point, not seeing any products available, it's
because they have to disrupt their entire roadmap. So, what we're seeing
now is, with the acquisition of Blue Lane, there is a new model that allows
you to not have to write kernel-mode drivers and fast path drivers that
require you to retool your product, and they are working on now standardizing.
You can look at RSAs DLP tablet product of actually being able to some of
this interaction without modifying code on either end. So, they kind of
realized this. It's kind of backwards from what you would have expected.
You would have expected what Simon describes first, and then get to the API
with the openness and integration. But what it does is offers customers a
little bit of choice, now, that they didn't have before. Whether that's to
wait for a product that gives you memory block disk, actual CPU instruction
and execution capabilities with the VMsafe. Or potentially use what they
already have today, which is better news than the kind of proprietary lock-
in issues we're dealing with.

Simon: One of the things that's interesting about the security features
sprung up certainly around the virtualization area, they are all just
falling off a cliff, because things are changing in there very fast. I
don't think there's going to be a particular fault that the notion of a
plug-in virtual appliance, plugging into a promiscuous network switch in the
hypervisor, that's all going away. It's going away just because Moore's
law is increasing the number of VMs per server because IOV is introducing a
direct fast path for IO between the hardware and the guest. And so, there
isn't a good place for those folks to get a look in. So, again, I think
it's an imperfect understanding of virtualization, as in architecture,
immaturity of virtualization generally, we are pretty early in this whole
area. Therefore, an inability for a decent ecosystem to built up around,
even the interfaces that were there. And in general, just plugging people
into promiscuous places leaves a lot to be desired. And so, there's a nice
opportunity, I believe right now, to reexamine all of that. Again, what
worries me a little bit is that in the context specific of the virtual
switch and how security vendors plug in there the only trend I see is all
of the packets getting shipped off the server back into one vendor's
switch. And I think, speaking on behalf of every other switch and server
vendor in the industry, everybody is a little worried about that.

Chris: Saying all of this is very interesting, right? We kind of, as part
of the discussion, there are philosophical and quasi-religious views on the
question you ask. And they are architectural and technical, and are
balanced by the notion of proprietary and open. And those three things, I
mean, no matter whether we're talking about virtualization or pretty much
anything in IT, that balance is pretty hard to achieve, any way you look at
it. So, there is no difference to virtualization. It's funny, when we sat
down and discussed this, people are always interested to find out that
Simon and I actually probably agree on more things than we disagree. And
the notion of disagreement is sometimes an issue of nuance, depending on
which one of those corners of the triangle we are talking about. It may be
subtle, it maybe profound. But I think the balance is the issue here,
making sure there's choice.

Simon Crosby: Sure, and just so you understand, from a security perspective in the
Xen world we've been on this for as long as Xen has been around. And some
of the security challenges that are user-based experienced, are quite
different and quite profound. So, by way of example, Amazon EC2 built on
Xen. When you hand out a VM to some user, and then shortly thereafter hand
out the same memory blocks to another VM, somebody can go in and index
through the memory blocks you just gave them if they haven't zeroed them
before. So, all of those things which are not generally considered in a
normal commercial environment, where you have multiple diverse sets of
interest showing up on the same physical server from different
organizations, who can really be hostile in attacking each other. These
aren't even considered in the normal commercial deployment of
virtualization, but they're actually very important. The same occurs for
the virtual hard disk you hand out to somebody. The first thing I do when I
get my virtual hard disk is go and look at all the blocks on the disk and
see if I can find out what the guy before me did. Okay? And then some guys
have seen everything that you could ever plan on--everything that you could
ever imagine happening on a multi-tenant system. And Zen has seen all of
this. And I think we've learned an enormous amount. But I don't see any way
to bring that forward in a commercial context, given a roadmap that doesn't
allow these interfaces to be exposed, doesn't start talking about
standardized policies, and requirements there. I think that's a real
requirement. The other thing I worry about slightly is that in general,
given there is a lot of change happening in terms of how big servers are,
where security policy lives anyway, VMs introduced agility. Agility breaks
the stuff that is static, and security policy today is static, and we've
got to fix that. And VMsafe is interesting on single server, but it
doesn't solve that problem in any way from an agile infrastructure
perspective. I think there's a huge opportunity for the industry to gather
around, try and figure out how it is you would specify policy for an
application. It's not just a VM, a VM is just a sub-component of an app,
and how to make that agile in a multi-tenant world where applications can
show up and run any place at any time. That's a very important problem to
solve, and we're not doing anything there right now.

Chris Hoff: And I think the things that we are doing, especially if you look at
VM solutions with the extension of distributed virtual switching, for them
to be able to pull that off in a way which in an enterprise environment
makes sense, the Cisco-VMware partnership, assuming that you are willing
to invest in those two vendors, certainly yields some of these problems.
They are not standardized across multiple hypervisors or multiple
instances, and we'll see where that leads in terms of vCloud.

Simon Crosby: I think it's very compelling in the sense that to the extent you
trust both those vendors, there's nothing wrong with that. You've invested
in their technologies for both security and virtualization, that's fine. It
actually consolidates the management view of it and makes it simpler and
does solve a lot of custom problems there. But it doesn't solve the
industry problem.

Chris Hoff: That's a great point. The difference between the industry's set of
problems and then the end users' set of problems, they don't always align.
The notion of essentially being able to take long term trends and their
impact on what that means to roadmaps, technology, and ultimately how that
is delivered is often times at odds and quite different than what users in
the enterprise expect, from the perspective of what solutions are supposed
to deliver. They are not always aligned, right? We're always kind of
trailing at least the six months to a year in terms of what technology
gives us in the security side, because we're never really ahead of the
threat, despite their suggesting that we can be.


View All Videos

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.