There are a growing number of virtual aware security technologies that promise to help you keep data moving between virtual machines safe. This video is intended to help you to evaluate the technologies and how best to integrate them into your existing network topology for a complete view of activity, vulnerabilities and remediation options. Key areas of emphasis include:
- How virtualization technology is affecting security, and virtualization vendors' responses
- Considerations for virtual firewalls and network segmentation
- Tactics for using IDS/IPS with virtualization
- Strengths and weaknesses of virtual vulnerability management
About the author:
Dave Shackleford is director of risk and compliance and acting director of security assessments at Sword and Shield Enterprise Security Inc., and is a certified SANS instructor. He was formerly CSO at Configuresoft Inc. and CTO at the Center for Internet Security, and has worked as a security architect, analyst, and manager for several Fortune 500 companies. In addition to these roles, he has consulted with hundreds of organizations for regulatory compliance, as well as security and network architecture and engineering.
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 email@example.com.
Integrating virtual-aware security technologies
Dave Shackleford: Hi, I'm Dave Shackleford and I'm going to be talking today about
integrating virtualization-aware security technology into your
infrastructure. Without further ado, let's get started.
So, let's just set the backdrop today and take a look at what technologies
we've been used to accommodating within our infrastructure as it is.
There's a huge variety of these. Obviously, everybody has their own idea of
what everyone needs, as far as security technology is concerned. But,
generally, when I talk to people out in the world, and they talk about
security technology, most folks have firewalls.
It's generally understood that's the best practice today. You're going to
have some sort of firewall technology. The same thing goes, usually, for
intrusion detection and prevention technologies. So, some sort of intrusion
detection, whether it’s behavioral in nature, whether it's more signature
based, something that's watching what's happening on the network, and
actually giving you some alerting capabilities.
Usually, there's some degree of gateway level anti-malware. If not at the
gateway, typically around e-mail technology. Usually, everyone has anti-
malware technology, at least at the host level. These are all falling into
that best practice category.
Finally, another category that really depends on the organization is
vulnerability management and so we do tend to find more organizations today, at
least running some type of vulnerability scanners on a regular basis,
trying to find those vulnerabilities and do something about them,
obviously, before attackers do. So, this is really the general level of
categorization we kind of call best practices.
For the host side, again, anti-malware is very common. Host-based firewalls
or host-based intrusion detection or prevention are very common
technologies. Depending on the organization and how it's implemented, some
type of configuration, or patch management. Again, these are the most
common technologies, both on the network side and on the host side, that we
tend to see. So, that is the backdrop of the overall security
Let's move on to our next slide and really ask the question, "How does
virtualization affect those technologies?" So, it’s not enough to just have
them in place and hope that they're probably going to work as we expect
them to with the integration of a totally different paradigm for
operational technology today, which is virtualization.
We're taking an entirely different stack, we're adding a hypervisor layer
in, we're accommodating multiple systems, obviously, virtualizing them on
top of one platform and things don't necessarily work exactly as they used
to in our traditional, physical environment. So we do have to take a look
and really ask ourselves, "Hey, how are we going to adapt? How are we going
to change or, at least, integrate technologies that have a better capacity
for understanding the differences and nuances that go along with
virtualization?" So, that's the question we are asking.
Sometimes, if we just try to use our, say, traditional intrusion detection
system, it can't see all the traffic that's within those virtual
environments. Our firewalls, obviously, are intended to be controlling
access on our physical networks. So, it may not be the case where we find
our virtual systems are actually integrated into those kinds of security
paradigms like they used to. Host-based products, really the same kind of
thing so more of the network is what I was talking about a moment ago.
At the host level, now you're taking a system, and instead of being an actual
physical system, obviously, it's being abstracted down into a number of
files. Virtualization takes a virtual disk file and a virtual configuration
file, and a virtual snapshot file of the state of that system, as an example,
in it's memory and uses that, with the concept of this hypervisor, to
abstract the hardware so multiple systems can all operate simultaneously on
top of one physical platform.
Well, that certainly changes the way that technology, particularly security
technology, interprets things like signatures for anti-malware, as an
example, or the types of traffic or configuration parameters that are going
to be affecting and really in place on top of these systems. So, we really need to take a look
at what we've had in place traditionally and start taking a look at some of
the technologies out there and how they're adapting to virtualization.
Let's go ahead and do that.
A lot of virtualization vendors out there. Not just the virtualization
platform vendors themselves, but also the security vendors and how they're
starting to integrate.
Starting off with the virtualization platform vendors, there's, obviously,
a lot of them depending on the type of virtualization that you're doing.
But we'll focus here more on the traditional virtualization or server
virtualization that most people are really starting off these projects with.
Obviously, when you get down to nuts and bolts, you tend to find there's
only a handful of them that most people are integrating. Microsoft is a big
one. They have their Hyper-V platform. Citrix is another. They've certainly
had a variety of Xen technologies that are used for virtualization today.
The biggest player out there, which most people know, is VMware.
The question, of course, is, "How responsive and proactive are these
vendors actually working with the security community and with the security
vendor community to ensure that they are integrating their technologies
into these platforms?" The two that seem to have a lead here would be
VMware and Citrix. And, certainly, VMware is ahead of the curve. They've
created their VMsafe program, specifically, to offer APIs to the security
vendor community for really seamless integration into their hypervisor
platforms. There's been mixed success, and that's not what we're going to
focus on today.
Citrix has kind of followed along and they've got their Citrix Ready
certification with even online labs that people can do their testing in
but they're not quite as mature or robust a program as VMware really has
had in place for quite some time. These are the leading edge things we've
seen so far, as far as effort is concerned, to integrate with security
technology but there are a lot of vendors that are taking advantage of this.
What we are going to focus on are all those traditional categories that we
just discussed in security, so firewalls, things like intrusion detection
and then how that's actually playing in to the virtualization environments.
So, let's get going.
Solutions, planning; the things you need to think about before you go
integrating into your environment. You need to make sure that, hey, maybe,
what you do have already, could work, depending on what it is, and how it's
been implemented. So, what I always tell people when they're starting to go
down this road and really considering virtualization technologies or
specific technologies that are focused around security, I say, "Well, what
do you have?"
The first thing to take a look at is maybe the firewalls that you've
already got. Just to give an example, you may have CheckPoint firewalls and
CheckPoint has made some big strides in trying to integrate into
virtualization environments. So you may already have some things in place
that you didn't realize might accommodate that virtualization
infrastructure. More so than anything else, you may be looking at identical
products, but that are available for the virtualization environment or that
are ready to integrate into those virtualization environments.
Most of the time, when you go through your product evaluations, a lot of
the things you are going to be looking at are going to be identical. If
you're looking at firewalls, you're going to be looking at port density
perhaps, although this is a little less applicable in virtual environments,
you'll be looking at the speeds and capabilities as far as efficiency are
concerned, obviously, feature sets, in terms of the types of filtering you
can do. When it comes to virtualization, maybe there are a few differences,
but by and large, you'll probably be looking at a similar checklist in
terms of functionality and really what you're hoping to get out of the product,
regardless of how it's implemented. There are some additional points though
and that's really what I am going to focus on.
Let's start off with virtual firewalls. I have, kind of, eluded to that.
The reason for that is because it's led that market space. Most
organizations have been aware of the fact that, "Hey, we could get a
virtual firewall, if we wanted to. For, maybe, a year and a half two years
now, it's been a while." This is not a new market segment. It's still
evolving. It's one that, most people are starting to come to grips with and
ask themselves whether it's a need they really have, but if you've got a
traditionally physical firewall infrastructure in place, there's a very
good chance, if you're rapidly virtualizing or a lot of your infrastructure
is being virtualized right now, that you've got some gaps in terms of how
that physical firewall is going to work for you.
The reason for this is you're taking networks and collapsing them. Instead
of having very simple to identify network segments, VLANS that are
identified through specific physical ports across your switches, routers,
firewalls and all that, now, in one physical system, you may have an entire
infrastructure. You've got multiple different segments, you've got multiple
virtual switches and you're going to have to be able to segment that
appropriately. Particularly, if you have compliance needs and other types
of regulatory concerns that actually mandate that.
A couple things to consider. First of all, just architecturally, do
traditional screen subnet approaches still work? You have to ask yourself
this. Depending on how you're put together, in terms of your architecture
today, it may or may not be something you can easily make a shift to. If
you've got a simple environment, and what I mean by that is that you've got
some very clearly identified, say, DMZ zones where one of them has a very
particular function, another has a very different specific function, but
they're easily identified and you don't have too many of them, this is
probably an easy shift for you. You can probably look at your virtual
environments and kind of compare apples to apples.
In some cases, however, the complexity and interconnections between your
different zones may be such that just easily taking what you have set up
physically and trying to port it over to a virtual side is not going to be
that simple. The other thing you have to ask yourself is simply just the physical
versus virtual question. Do I really need to have as much port density as I
Let's say for example, your physical firewalls today have 16 ports. Do I
need the same number of ports when I look at a virtual system? Could I
architect it perhaps differently? When I am looking at the system that actually has
all of my virtualization infrastructure, let's say you're using something
from Dell or HP just as your platform, you're limited in the number of
actual physical neck slots that you have and most of those you are probably going to
want to allocate to your virtual machine production environment. If you
have to start carving some of those off and allocating them to your
firewall, that may be a real serious choice you have to make from a
Another thing that you really have to consider is whether or not your auditors
will count a virtual firewall as a legitimate means of segmenting your
network. A lot of auditors out there, that I've spoken with and I've seen
actually engaging in compliance audits don't understand exactly how virtual
firewalls work. They're not real keen to say, "Hey, okay, that counts as
the same kind of thing." So, make sure you understand that, particularly,
if you are looking at a virtual firewall for this specific purpose.
Then the last couple questions you are going to want to ask around virtual
firewalls and segmentation is, "Well, do our existing firewalls support
virtualization?" Much like the CheckPoint example I gave a moment ago. You
also need to think about who's managing this.
So, a big question, and one that I get a lot of blank stares when I ask people,
is I go in the environment and I say, "Well, you've got a virtualization
team or, perhaps, your systems administration team has taken over
virtualization, but within that virtual infrastructure you've got distinct
network components." It's fairly rare to find your, say, Windows
administration team managing switches or managing firewalls but that's exactly
what a lot of organizations inadvertently find that's going once they put
something like a virtual firewall in because everything virtualization is
handled by this one team. You should really strongly consider the separation of
duties that you should have in place with different virtual components,
particularly if you're adding in something like a virtual firewall. So
something to make sure that you can do if you are going down that road.
What I have got here on this slide is something taken from VMware and I've
credited them, but it's a fairly simple slide to understand that shows a
little bit of a hybrid approach between a physical and a virtual
infrastructure in this regard. VMware has got some great literature out
there that explains how to think about segmenting the virtual versus
physical and heading down the road of more virtual, obviously. I am
certainly not endorsing them in any way. They just happened to have this
available and it made the point pretty well.
So what you see here is the use of traditional, physical systems, things
like firewalls in place and still being leveraged just as they were before
you really started virtualizing. However, these are being used in conjunction with
some additional virtualization technology. And so this is an approach that
a lot of enterprises are taking today, which is to use both for a while. As
they are heading down the road of more and more virtualization, perhaps
they start thinking about phasing out some of their physical infrastructure
and using more virtual. Today, typically what I find in mature
organizations that have been doing virtualization for a while is that they are
using both. That's really what is reflected here. There is both in place
and there's a happy medium that can exist for some time.
To give an example of some of the vendors in the space, and this is
definitely not a comprehensive list, so please understand that, I just
chose some that are fairly well known and have been out there for a while.
Obviously, VMware has their own product. They've had this for some time and
it's grown to be a little bit more mature in its latest phase, it's called
vShield Zones. You can get a number of different types of zones that you
can implement and you can do very simple kind of perimeter zoning much like
you would with a traditional perimeter-based firewall. You can also do more
application inspection types of firewalls with their vShield app. So
they've got kind of this range of things that you can put in place, but you
can actually get the base level of vShield Zones free within the product
itself. So, they do give you some degree of virtual firewalling.
Many have found though that just this base level was not quite enough
comparatively with what they're used to from a more robust firewall
infrastructure. There are a number of vendors that have much more robust
products in this space. Altor Networks is one, they were recently acquired
by Juniper, which makes sense given that they are an infrastructure player
and they're certainly starting to expand into the virtualization environment. Altor
is well known for, specifically, virtual firewall. They don't try to be all
things to all people. They make a very full featured, simple to use and
implement virtual firewall technology that's capable of being managed
through a central console. Much like, again, you would an enterprise
environment with traditional firewalls.
Catbird is another company that makes a lot of virtual security products.
They've got what they call their vSecurity or TrustZones virtual firewall.
Very similar to what Altor had, obviously, a little different feature set
and interface, and so forth. Reflex Systems has a product called vTrust and it
allows you to do segmentation between different zones. Again, kind of the
The last one on this list is a little bit different. I added it here simply
because more people are familiar with it and I am actually seeing rapid adoption of
this in larger enterprises. It's Cisco's Virtual Switch. One of the
complaints early on with virtual technology was, "Hey, I just can't get as
much functionality out of these basic, rudimentary virtual switches as I
would with my traditional switch technology where I have a lot of granular
control over the access controls I apply at the port level, the different
types of virtual LANs or VLANs that are assigned, and so forth."
Well, you can do all of those things now with the Nexus 1000V Switch from
Cisco. From a security perspective, the reason I have included this here is
because many organizations are relying on things like SPAN or mere ports on
their switches today to actually span traffic out and send them off to an
intrusion detection system or something along those lines. Well, you
couldn't do that easily or readily with the pre-existing set of virtual
switches in most technology. Cisco's virtual switch entrance into this
market gives you all those same capabilities, but, again, within the
virtual environment. So that's a very good thing for a lot of security
Moving on. Another common thing that we see is virtual intrusion detection
and prevention. Early on when virtualization really started to grow, this
was one of the most common questions I fielded is, "I can't see all the
traffic inside my virtual environment." One of the questions I would then
pose back to the people asking me this was, "Do you really need to? Do you
really need to see all that traffic?" because most of the time in our
environments today, we are not monitoring every bit of traffic between all
the systems in every subnet. You may not need to do that within the virtual
environment either. There are a number of cases where you do though,
particularly where you have a certain subnet that has, say, payment card
data or is subject to certain compliance regulations.
So, including virtual intrusion detection and prevention certainly is something
you want to be able to do and, again, it's a case where maybe your existing
technology that’s primarily a physical system that's sitting in a rack
somewhere doesn't have the capacity to easily integrate into those
environments. So, the first question you'll ask is, "Well, can I monitor what I
need to monitor today? Could I possibly send some of my virtual environment
traffic out to my existing IDS or IPS and is that going to work for me?" If
it does, as I always say, use what you've got. Try to leverage your
existing technology to the best that you can. However, you may need to
monitor more in depth than that gives you the ability to do. If you really
find yourself struggling with your existing technology, you will probably
want to look into a virtual-ware IDS or IPS. There's definitely technology
that can help you there.
A number of vendors, and, again, the caveat that this is not an exhaustive
list, I am just giving representative examples. Sourcefire, very well
known, obviously, because their founder, Marty Roesch, created Snort, which
is the best known open source IDS out there, but they've got a whole range
of commercial products and their 3D system and they're absolutely at the
top of the game as far as integrating into virtual technology. They really
wanted to make sure that they were capable of doing that. They've got virtual 3D
sensors; they can tie back to an existing 3D infrastructure where you've
got monitoring and all the other things that go along with a true IDS or
TippingPoint, probably one of the best known names in intrusion prevention,
now a part of HP. They absolutely have virtual tipping point sensors that
you can include, so you can integrate right into, say, a VMware environment
just as you would with a traditional physical system. IBM ISS, they have a
virtual appliance. Their prevention line of IDS and IPS systems can be
Reflex Systems, again, has a very unique solution called their
Virtualization Management Center. It doesn't really do it credit by
including it, just on this slide, because it's much, much more than an IDS
or IPS, but it started off as an IDS/IPS and grew into a much more robust
security solution. But it has that functionality and can be integrated very
easily into VMware environments.
There's plenty of other solutions out there. If you are not really looking
to incorporate another vendor product, there are plenty of readily
available, open source capabilities that you can get. You can find a
virtualized Snort system or you could create your own. You could actually
create a virtual machine, run Snort on it, and then, obviously, set it up
in promiscuous mode and do all those fun things, but you'll ask the same
questions you typically would as setting up traditional IDS or IPS.
The cost is a major factor. These are going to cost you. Probably not as
much as a physical system would, obviously, but you're still going to
spend quite a bit of money just investing in the technology and then the
operation and management of that, ongoing.
Ease of installation is a factor. Some of these are ready to go. You can
actually just kind of, drop them down in as a virtual appliance into an existing
environment. Some of them actually take a lot more installation, so it is
much more software-based and the integration with those hypervisors may not
be as smooth as some of the others. So, you want to make sure you are
considering that when you take a look at some of these vendors.
Obviously, everything else comes down to the traditional IDS/IPS questions, which are
what's the quality of their signatures? What kind of behavioral analysis
can they do? What kind of alerting and reporting can they give me? False
positive reduction. How can they integrate into change control and
integration depth, and so forth? All the same kinds of things you would be
asking, regardless of whether it was physical or virtual, but there are a
number of solutions out there.
Vulnerability management is another big category for security. So,
obviously, we want to make sure that any of our virtual machines are as
safe as any of the physical systems. The thing I always remind people is,
"Hey, a virtual machine is still a machine." If you virtualize a Windows
OS, it has all the same problems that Windows OS may have, meaning you've
got to keep up with patches, you've got to keep up with configuration
details just as you would on a traditional physical system.
One of the problems that occurs often within virtualized environments is
something called virtual sprawl, which means I can create a virtual machine
in seconds. It takes a lot more effort to install an OS and get it ready on
a physical system, which means that people who have virtual environments
tend to proliferate virtual machines and sometimes it can get out of hand.
You may have virtual machines hanging around all over the place that
nobody's really paying that much attention to and that's a problem because those
patch cycles could get out of whack, you could ultimately have
configuration problems because nobody was actually tuning or adjusting
those systems if they were in test environments, the list goes on and on.
Thus, the need for vulnerability management, particularly for our virtual
Most of our existing tools can accommodate this fairly well. If you are
running, say, Nessus Scanner, just as an example, you could incorporate
virtual machines that were live and online without too much of a hiccup. You
might want to make sure you knew where those systems were because you don't
want to throttle them by scanning them. There are different performance
needs, but if you've got existing scanning technology, pretty good chance
that it will probably be able to, at least, give you a rudimentary idea of
the state of vulnerabilities on those virtual machines. So keep that in
Sometimes, I've seen some cases where they don't detect hypervisor platforms very
well. For instance, if you are running an ESX platform or ESXi from VMware, well
your virtual vulnerability management tools may not actually be able to
figure out what that is and so it will come back with some response and say,
"Hey, I think this is a Linux system or I think this is some other system."
Again, it just depends on the vendor and what solution you're using. You,
again, may want to consider things like performance effects.
Keep in mind; in a virtualized environment you have maybe a hundred virtual
machines all sharing physical resources. So, they're sharing RAM, they're
sharing disk space potentially, they're sharing CPU. So, if you start
running these kinds of scanning tools, and throttling them perhaps, you
could actually have an effect on the entire environment, not just those
machines. So, again, just something you want to be sure you're planning for
and accommodating in your discussions around vulnerability management. So,
lots of different deployment options.
Some of the scanners actually can be deployed as virtual appliances. They
can be put right inside the virtual environment so they are right up close,
right next to the virtual machines, giving you a much more granular look
down in there, whereas, others may be physical appliances just as you would
have today or even software that just, gets installed. It really just
depends on what you are looking for. There's a very wide variety.
Here is an example of some of the vendors in the space and most of these names
are probably familiar to many of you. Tenable, probably the leader in
vulnerability management just having been around so long and so many people
know about Nessus, they absolutely have a virtual appliance for Nessus. You
can implement this pretty easily into the virtualization environment very
Rapid7, which is a newcomer in the space, they've been around for a few
years now, but they're doing a lot of very interesting things, particularly
with their integration of the Metasploit project. Well, they have their
NeXposeVM virtual capabilities. So they're absolutely there as well.
They're actually integrating very well into a lot of people's environments.
So, this is another one that you might want to take a look at.
Qualys has support for scanning virtual systems, as does eEye Retina. They
don't necessarily have standalone virtual appliances, but they absolutely
come out and say, "Hey, we support the scanning of virtual systems if you
already have our appliances or already have our tools in place." For many
of you that may be just fine. You don't want to have to go invest in new
technology just to accommodate VMs.
Things you'll want to consider, cost, certainly is one. Trying to rip and
replace whatever you have just to get virtualization capabilities may not
be a good idea. Integration options, if you want to integrate it down into
the environment because you need to get down closer to those VMs, you'll
want to look at a vendor that can accommodate that. That's again a big factor
when you are taking a look at these.
Configuration, scalability, performance, again, all the things that you
would look at traditionally around a vulnerability management solution
doesn't really change when you get down into the virtual environment. You
just want to make sure that it's going to meet your needs, whatever those
Anti-malware is a big one. Most people have been running anti-malware
solutions for a long time. Again, as I referenced back at the beginning,
kind of at the gateway we usually see this around, say, e-mail. We want to
make sure we are not getting e-mail viruses and things, but definitely at
the host. Almost all of us run some type of anti-malware solution on our
laptops, on desktops, on our servers. Well, when you get into a virtual
environment, there are some very interesting changes that occur.
First and foremost, because when you start scanning your entire system with
traditional anti-malware technologies, it has a huge significant
performance hit and most of us are well aware of this because we've been
complaining about it for years. It just is what it is. However, that
changes when you're inside a virtual environment because if you start
scanning that environment and cause that performance spike, again, remember
what I just said, you've got shared infrastructure, which means that a
hundred virtual machines are sharing memory and sharing CPU. If one of them
just happens to kick of an anti-virus scan and starts trying to suck up CPU
or memory just to actually accommodate that scan, you could actually steal
resources from other virtual machines causing slow down in the environment
or even, potentially, a denial of service or triggering VM migrations and
things you definitely don't want.
You have to plan very carefully around anti-malware solutions, particularly
when you put them at the host level. So, if you are integrating this into a
virtual machine, I've got a bunch of Windows virtual machines and I want to
make sure they're running anti-virus or whatever anti-malware technology,
make sure you are looking at the vendor you have, and that they have the
accommodation for virtual environments. It's very important. Just about all
of them do today. It's pretty rare to find an anti-malware solution that
doesn't accommodate virtualization, but you'll just want to double check
because it really could have a significant impact on your environment.
When you get down into the host level, and what I mean by the host is the
hypervisor platform itself. So, if you are running Microsoft as Hyper-V,
you are running VMware ESX, or ESXi, Citrix XenServer, whatever the case,
there's a very different level of support there for anti-malware. In fact,
there's many in the community that don't feel that anti-malware is even
needed on the host itself. Again, I'm not going to recommend that because I
think you want to make sure you are covered and that will depend on your
risk tolerance and your own environment. But for those of you who do feel
that you need, for instance, anti-malware on ESX, make sure that you go
check with the vendor that you're looking at and that they do have full
support for it because it's a very, very different technology altogether.
So, you want to make sure you've got the specific stuff that will work
within that environment.
Giving a little example of architecture here, and this is a simple example,
but just kind of illustrates what you might be thinking of. You are going
to have to ask the question, "Do I really want to have it on all my hosts
or do I potentially want to have it on maybe just a gateway, virtual
machine?" So, if you think about a virtualization environment, again, we've
got one physical platform and that acts as somewhat of a gateway to the
rest of the virtual machines that are sitting on it. Well, potentially, you could
implement something like, a virtual anti-malware gateway where all of the
traffic coming through is somewhat filtered before it even talks to the VMs
at all. Something you'll want to consider when you're really considering
all those resource constraints and whether you want to put it on all of
your different VMs itself.
The other questions you'll have to ask, "Well, where do I put my management
server? Is it going to sit within the virtual environment or am I going to
send all the traffic back out from the virtual anti-malware gateway to some
traditional console? What about access controls for the traffic in and out?
Do I have to make a lot of virtual firewall changes just to accommodate the
virtual anti-malware technologies?" Even though anti-malware is something we
almost take for granted today, it's kind of a simplistic thing that we have
gotten very accustomed to, it's one of the more complex decisions inside a
virtual environment. Make sure you're really thinking this through when you
are looking at different options. Definitely some vendors out there.
The names that you see on this slide should be familiar to just about
everyone because they are probably the bigger leaders in the space. Trend
Micro, McAfee, Symantec all have anti-malware solutions that will work
within a virtual environment. Again, you can get different virtual
appliances that will work just fine down within those environments. You can
actually get an agent that sits on the virtual machines and works fine
within the virtual environments. There is a whole range of these. I won't
go through all of them. You can go check out the vendors for yourself, but
it should come as no surprise to you that they've adapted their technology
to work within these environments.
As another interesting aide, VMware does have an anti-malware, not quite a
solution, but essentially a partner focused option with their vShield line
that sets up a separate virtual machine within the environment and then
integrates with, say, Trend Micro or one of the other anti-malware vendors.
And that virtual machine acts as all of the anti-malware processing. It
does all of it. Essentially what it does is offloads that resource
constraint from each of the VMs that are your normal production VMs to this
one specific VM that does nothing but look at anti-malware options. So,
something else to consider, again, if you want to take a look at VMware's
options, they'll integrate with some of the partners out there, but it just
goes to show you that this is an evolving space and one that is taking a
different look at the way we've traditionally done some of this.
Improving anti-malware with virtualization, maybe not so much. This is not
something that most people consider, but it is something that you should
ask yourself, "Could I have a better option for doing my anti-malware
operations just by doing it in a virtual fashion? Maybe I could." If I want a
malware analysis or reverse engineering, virtual solutions are great
because you can revert them back to a known, clean state after doing the
You can have; again, these localized anti-virus proxies where everything is
passing in and out. You could actually take your offline virtual machines
and scan them in an offline state to have maybe a more efficient type of
operation than throttling them while they are online. So there are a lot of
new considerations. It really just goes to show you this is an evolving
space all together.
The last category is more operational in nature. Again, just getting into
the guts of things; configuration, inventory, patch management, a lot of
the things we take for granted in most of our operational environments
today, but there's a lot of options out there for you. There's way to many
to cover in this discussion.
Inventory management, as I said, is critical because you don't want to end
up having virtual sprawl. Keeping up with where those virtual machines are
and what virtual machines you've got is paramount because, otherwise, you
could find yourself in a situation where you have unsafe or vulnerable
systems all over the place.
Configuration management can get a lot more complex because, obviously,
virtual machines on VMware versus Citrix versus Microsoft, all totally
different. You want to make sure all the different parameters are being
considered in how they are getting locked down. Depending on the solution
you've chosen to implement, there's a good chance that some sort of
template technology already exists. If you are using VMware as an example,
you can use host profiles to give a snapshot of the underlying hypervisor
host and then clone that or replicate it. You can do the same things for
the virtual machines by using templates. This could actually help you in
configuration management, to having much more strict regimen of keeping
things up to date and patching, and so forth.
Most of the patch management solutions out there are doing a good job of
keeping up with virtualized environments. Again, if you are already using
one of the well known patch management vendors, then there's a good chance
that they've already gotten to the point where they support virtualization,
but, again, make sure that you are checking into that.
Additional vendors and products, this is just to kind of follow up. There are
a lot of new things happening in this space. I'm kind of just giving
examples here, but what we've talked about is the more traditional types of
security technology. But there's a lot more going on inside the virtual
environment, especially, when you talk about cloud computing, and people
that are developing internal cloud environments, or shared services
environments, you've got to ask yourself, "Well, hey, is it okay to have
sensitive data on a virtual machine that's sitting right next to a virtual
machine without the sensitive data? How do I really protect myself from that? How
do I assign policies to a virtual machine as it moves around within the
environment and keep it with that virtual machine?"
So lots of new and different questions we have to ask in terms of the
different types of threats we are facing a lot of questions. There are new
technologies out there that are starting to emerge. I've given two examples
of fairly innovative companies that are doing some interesting and
different things. I already talked about Reflex Systems and their
Virtualization Management Center.
HITRUST is another company that has, what they call, their HITRUST
appliance. What these do is give you much more holistic policy management
and overall threat detection, and so forth, within the entire virtual
infrastructure versus just one piece of it. Something to take a look at if
you're really virtualizing rapidly.
To wrap up, something to keep in mind, make sure, first and foremost,
you're looking at your existing vendors and seeing what they can do for
you. If you find that they are not able to actually keep up with what
you're doing in terms of virtualization, you may need to look at some other
options, but the good news is there are plenty of options out there.
Thanks very much for joining me. I'm, again, Dave Shackleford, and we'll
see you next time.