"Risk management" is just a fancy term for the cost-benefit tradeoff associated with any security decision. It's what we do when we react to fear, or try to make ourselves feel secure. It's the fight-or-flight reflex that evolved in primitive fish and remains in all vertebrates. It's instinctual, intuitive and fundamental to life, and one of the brain's primary functions.

Some have hypothesized that humans have a "risk thermostat" that tries to maintain some optimal risk level. It explains why we drive our motorcycles faster when we wear a helmet, or are more likely to take up smoking during wartime. It's our natural risk management in action.

The problem is our brains are intuitively suited to the sorts of risk management decisions endemic to living in small family groups in the East African highlands in 100,000 BC, and not to living in the New York City of 2008. We make

systematic risk management mistakes -- miscalculating the probability of rare events, reacting more to stories than data, responding to the feeling of security rather than reality, and making decisions based on irrelevant context. And that risk cockpit of ours? It's not nearly as finely tuned as we might like it to be.

Like a rabbit that responds to an oncoming car with its default predator avoidance behavior -- dart left, dart right, dart left, and at the last moment jump -- instead of just getting out of the way, our Stone Age intuition doesn't serve us well in a modern technological society. So when we in the security industry use the term "risk management," we don't want you to do it by trusting your gut. We want you to do risk management consciously and intelligently, to analyze the tradeoff and make the best decision.

This means balancing the costs and benefits of any security decision -- buying and installing a new technology, implementing a new procedure or forgoing a common precaution. It means allocating a security budget to mitigate different risks by different amounts. It means buying insurance to transfer some risks to others. It's what businesses do, all the time, about everything. IT security has its own risk management decisions, based on the threats and the technologies.

There's never just one risk, of course, and bad risk management decisions often carry an underlying tradeoff. Terrorism policy in the U.S. is based more on politics than actual security risk, but the politicians who make these decisions are concerned about the risks of not being re-elected.

Many corporate security decisions are made to mitigate the risk of lawsuits rather than address the risk of any actual security breach. And individuals make risk management decisions that consider not only the risks to the corporation, but the risks to their departments' budgets, and to their careers.

You can't completely remove emotion from risk management decisions, but the best way to keep risk management focused on the data is to formalize the methodology. That's what companies that manage risk for a living -- insurance companies, financial trading firms and arbitrageurs -- try to do. They try to replace intuition with models, and hunches with mathematics.

The problem in the security world is we often lack the data to do risk management well. Technological risks are complicated and subtle. We don't know how well our network security will keep the bad guys out, and we don't know the cost to the company if we don't keep them out. And the risks change all the time, making the calculations even harder. But this doesn't mean we shouldn't try.

You can't avoid risk management; it's fundamental to business just as to life. The question is whether you're going to try to use data or whether you're going to just react based on emotions, hunches and anecdotes.

This essay appeared as the first half of a point-counterpoint with Marcus Ranum in Information Security magazine.

We've probably all heard that you can't secure what you can't see and that statement is even more profound when it comes to virtual environments.  This is because it is extremely challenging to see what is going on at a micro vs. macro level within a virtual environments network.  The virtualization vendors such as VMWare and Citrix have provided embedded tools into their management consoles that show a macro level of visibility but its not enough to identify security events in the environment.  Take a look at the attached picture.  It simply shows VMWare's ability to monitor virtual network performance statistics from a bits per second perspective.

<-Click To Enlarge

With only this level of detail how can one determine which network applications are causing spikes.  Is it FTP traffic that is occuring at a high volume at an unuseal time of day?  If that were occuring, could that be indicative of either a breach or some sort of problem? What if FTP isn't even an authorized service in the virtual environment but there is a high volume of it?  Did someone install a rouge FTP service so they could steal information from the server at will?

These types of questions can't really be answered without a micro level of detail into the packets flowing in, out and within the virtual environment.  Now, what I am highlighting is not security in the traditional sense of prevention but using visibility as a means to first identify, then pin point the source of an issue so that it can properly be mitigated.  Having constant visibility can also ensure that other security products in the environment are performing as expected.  What if a Montego HyperSwitch with firewalling enabled is configured with many policies but someone forgot to create an FTP block policy.  One could think they are protected from rouge FTP services transmiting data out of the network, but without constant visibility monitoring, can you be certain?

Some vendors, namely Reflex Security will get you to believe that their IPS / IDS solution that is inline and running in the virtual environment is the right and only approach.  Or they will tell you to hang a virtual IDS off a span port in the virtual environment and you will at least have visibility into the attacks that are taking place.  Well, sure... You now have attack visibility but at the performance cost of your virtual environment.  Signature matching technologies are great, I'm a huge believer; however they don't scale very well in shared computing environments such as virtual ones.  IDS systems also don't typically track protocol and network service (FTP, HTTP, etc.) utilizations; which is another important part of visibility.

So, what do we do to gain visibility without the performance headache?  Well, for starters its probably best to put your IDS/IPS solutions in the physical environment where performance will be less of a concern.  In fact, you can span a virtual switch's traffic out to a physical NIC as easy as you can to a virtual one.  So why do it virtual and have to pay a 60% CPU utilization tax?  Another solution is to IDS inspect only the things you care about.  Why IDS inspect SSL traffic if you know your solution can't unencrypt SSL.  Its just a waste of compute cycles isnt it?  Policy based switching helps you with directing only the things you care about to an IDS (attack visualization product).  Montego's HyperSwitch also can help you with the traffic redirection of only the things you care about.

Another method of visibility which I tend to be a fan of is one of packet analysis (aka NetFlow).  NetFlow was invented by Cisco some time ago and has gained popularity in the physical world and definately has a use in the virtual world.  NetFlow is lightweight.  Let me say that again, its light weight!  It only sends a summation of packet detail to an analytical engine which can do some number crunching, packet comparison, etc. etc. to make some sense out of whats going on.  Lancope, an Atlanta based visibility company that provides Network Visibility, Security Visibility and User Visibility has this tool on their website that is a Netflow Bandwidth calculator.  You'll see from playing with this ( http://www.lancope.com/netflowcalculator.aspx ) calculator that it doesn't consume a lot of network bandwidth to transmit these network accounting records.  It also doesn't cause a lot of CPU overhead to send these records to an analytical engine sitting somewhere in the network.

Lancope's analytical engines have the ability to do the following for you within your virtual environment:

...and probably a slew of other things I'm not aware of.  A screen shot of their product is bellow:

<- Click to enlarge

You'll notice from the screenshot that you are able to visualize who is talking to who, how much traffic they have sent and received and something called a concern index (not seen on this screenshot).

Now, a concern index is a number that increases as Lancopes analytical engines monitor suspicious activity on a session.  A high counter can be indicative of a security problem.  Its another way of identifying (visualizing) compromised hosts (virtual machines) without having to do signature matching like a heavy weight IPS engine.  Example:  Lets say you have a VM that has a BOT on it and is "owned".  The Lancope product is monitoring this long life session.  Let's say that session is established for several hours or maybe even days or months.  Lets also say that the conversation appears to be mostly unidirectional from a public ip address not belonging to your enterprise.  Lancope would increase a the concern index on this since this server hasn't typically had this type of behavior.  Once the concern index reached a certain level it could then fire off an email, send you a text message or something saying:  Warning, Warning, Danger, Danger Will Robinson!!! You're virtual server may be infected with a BOT, please investigate immediately!!!

This example is VISIBILITY which helps you with SECURITY.  There are a number of other things you can do with NetFlow and Lancope products that have less to do with security and more to do with operational efficiencies.  Things like, helping you answer questions of:  How do I know what network applications are taking up the most bandwidth?  When should I move those applications over to a server with more horsepower?  When did these VM's vmotion over here and was there a traffic condition / CPU condition that caused that to occur?  I could go on and on but thats a topic for another blog entry.

So, my suggestion is to take a look at what NetFlow has to offer.  Montego Networks supports NetFlow transmission and Lancope supports NetFlow analytics and with both you can regain what was lost visibility.

I hope this was helpful to you all!

-John Peterson

We've probably all heard that you can't secure what you can't see and that statement is even more profound when it comes to virtual environments.  This is because it is extremely challenging to see what is going on at a micro vs. macro level within a virtual environments network.  The virtualization vendors such as VMWare and Citrix have provided embedded tools into their management consoles that show a macro level of visibility but its not enough to identify security events in the environment.  Take a look at the attached picture.  It simply shows VMWare's ability to monitor virtual network performance statistics from a bits per second perspective.

<-Click To Enlarge

With only this level of detail how can one determine which network applications are causing spikes.  Is it FTP traffic that is occuring at a high volume at an unuseal time of day?  If that were occuring, could that be indicative of either a breach or some sort of problem? What if FTP isn't even an authorized service in the virtual environment but there is a high volume of it?  Did someone install a rouge FTP service so they could steal information from the server at will?

These types of questions can't really be answered without a micro level of detail into the packets flowing in, out and within the virtual environment.  Now, what I am highlighting is not security in the traditional sense of prevention but using visibility as a means to first identify, then pin point the source of an issue so that it can properly be mitigated.  Having constant visibility can also ensure that other security products in the environment are performing as expected.  What if a Montego HyperSwitch with firewalling enabled is configured with many policies but someone forgot to create an FTP block policy.  One could think they are protected from rouge FTP services transmiting data out of the network, but without constant visibility monitoring, can you be certain?

Some vendors, namely Reflex Security will get you to believe that their IPS / IDS solution that is inline and running in the virtual environment is the right and only approach.  Or they will tell you to hang a virtual IDS off a span port in the virtual environment and you will at least have visibility into the attacks that are taking place.  Well, sure... You now have attack visibility but at the performance cost of your virtual environment.  Signature matching technologies are great, I'm a huge believer; however they don't scale very well in shared computing environments such as virtual ones.  IDS systems also don't typically track protocol and network service (FTP, HTTP, etc.) utilizations; which is another important part of visibility.

So, what do we do to gain visibility without the performance headache?  Well, for starters its probably best to put your IDS/IPS solutions in the physical environment where performance will be less of a concern.  In fact, you can span a virtual switch's traffic out to a physical NIC as easy as you can to a virtual one.  So why do it virtual and have to pay a 60% CPU utilization tax?  Another solution is to IDS inspect only the things you care about.  Why IDS inspect SSL traffic if you know your solution can't unencrypt SSL.  Its just a waste of compute cycles isnt it?  Policy based switching helps you with directing only the things you care about to an IDS (attack visualization product).  Montego's HyperSwitch also can help you with the traffic redirection of only the things you care about.

Another method of visibility which I tend to be a fan of is one of packet analysis (aka NetFlow).  NetFlow was invented by Cisco some time ago and has gained popularity in the physical world and definately has a use in the virtual world.  NetFlow is lightweight.  Let me say that again, its light weight!  It only sends a summation of packet detail to an analytical engine which can do some number crunching, packet comparison, etc. etc. to make some sense out of whats going on.  Lancope, an Atlanta based visibility company that provides Network Visibility, Security Visibility and User Visibility has this tool on their website that is a Netflow Bandwidth calculator.  You'll see from playing with this ( http://www.lancope.com/netflowcalculator.aspx ) calculator that it doesn't consume a lot of network bandwidth to transmit these network accounting records.  It also doesn't cause a lot of CPU overhead to send these records to an analytical engine sitting somewhere in the network.

Lancope's analytical engines have the ability to do the following for you within your virtual environment:

...and probably a slew of other things I'm not aware of.  A screen shot of their product is bellow:

<- Click to enlarge

You'll notice from the screenshot that you are able to visualize who is talking to who, how much traffic they have sent and received and something called a concern index (not seen on this screenshot).

Now, a concern index is a number that increases as Lancopes analytical engines monitor suspicious activity on a session.  A high counter can be indicative of a security problem.  Its another way of identifying (visualizing) compromised hosts (virtual machines) without having to do signature matching like a heavy weight IPS engine.  Example:  Lets say you have a VM that has a BOT on it and is "owned".  The Lancope product is monitoring this long life session.  Let's say that session is established for several hours or maybe even days or months.  Lets also say that the conversation appears to be mostly unidirectional from a public ip address not belonging to your enterprise.  Lancope would increase a the concern index on this since this server hasn't typically had this type of behavior.  Once the concern index reached a certain level it could then fire off an email, send you a text message or something saying:  Warning, Warning, Danger, Danger Will Robinson!!! You're virtual server may be infected with a BOT, please investigate immediately!!!

This example is VISIBILITY which helps you with SECURITY.  There are a number of other things you can do with NetFlow and Lancope products that have less to do with security and more to do with operational efficiencies.  Things like, helping you answer questions of:  How do I know what network applications are taking up the most bandwidth?  When should I move those applications over to a server with more horsepower?  When did these VM's vmotion over here and was there a traffic condition / CPU condition that caused that to occur?  I could go on and on but thats a topic for another blog entry.

So, my suggestion is to take a look at what NetFlow has to offer.  Montego Networks supports NetFlow transmission and Lancope supports NetFlow analytics and with both you can regain what was lost visibility.

I hope this was helpful to you all!

-John Peterson

This week has been an interesting week in the virtual security blog world!  Simon Crosby of Citrix/XenSource stated in his podcast that he felt the virtualization vendors like VMWare and Citrix didn't have the competence to address the security challenges of virtualization and Chris Hoff blogged about it saying that the statement is a cop-out and that they should do more in securing their platforms. Alan Shimel also blogged on the topic and agreed with Hoff and I blogged about it agreeing with both Simon and Hoff. 

To restate my position on it I think that Simon is correct in that virtualization vendors like VMWare and Citrix do not have the expertise today to address all of the security challenges.  I also agree with Hoff that they should address more of the security challenges.  So this leads me to my own opinion that some of the virtualization vendors will acquire security technologies to differentiate  themselves from others and acquire the expertise.  Many say that the virtualization market will become commoditized and  that security can help protect its value. 

Think about it.  Would you rather buy a Virtual Environment or a Secure Virtual Environment?!

So.. Onto the topic of this blog!  Is Virtual Security Technology A Prime Target For Acquisition?

I'd love your opinion so please comment!!

What triggered my blog on this topic was this rumor I heard today.  Some buzz started today that one of the virtual security startups just agreed behind closed doors to be acquired by one of the big guys.  But, who could it be?  Reflex Security, Catbird, Blue Lane, Altor Networks, VMSight, Embotics, etc.

I have an idea of who it could be but don't want to spread rumors that could be false.  The other question is whether or not there is an atmosphere of acquisition frenzy brewing in the virtualization market. 

Please comment on your thoughts - Just click the comments link bellow.

This week has been an interesting week in the virtual security blog world!  Simon Crosby of Citrix/XenSource stated in his podcast that he felt the virtualization vendors like VMWare and Citrix didn't have the competence to address the security challenges of virtualization and Chris Hoff blogged about it saying that the statement is a cop-out and that they should do more in securing their platforms. Alan Shimel also blogged on the topic and agreed with Hoff and I blogged about it agreeing with both Simon and Hoff. 

To restate my position on it; I think that Simon is correct in that virtualization vendors like VMWare and Citrix do not have the expertise today to address all of the security challenges.  I also agree with Hoff that they should address more of the security challenges.  So this leads me to my own opinion that some of the virtualization vendors will acquire security technologies to differentiate  themselves from others and acquire the expertise.  Many say that the virtualization market will become commoditized and  that security can help protect its value. 

Think about it.  Would you rather buy a Virtual Environment or a Secure Virtual Environment?!

So.. Onto the topic of this blog!  Is Virtual Security Technology A Prime Target For Acquisition?

I'd love your opinion so please comment!!

What triggered my blog on this topic was this rumor I heard today.  Some buzz started today that one of the virtual security startups just agreed behind closed doors to be acquired by one of the big guys.  But, who could it be?  Reflex Security, Catbird, Blue Lane, Altor Networks, VMSight, Embotics, etc.

I have an idea of who it could be but don't want to spread rumors that could be false.  The other question is whether or not there is an atmosphere of acquisition frenzy brewing in the virtualization market. 

Please comment on your thoughts - Just click the comments link bellow.

It looks like virtual security is getting some attention this week as seen on the front page of Network World.  There are multiple articles in this issue that talk about the security challenges in the virtual environment.  I suggest everyone interested in the topic take a read.

After reading the articles, I did want to put out a short blog today to bring clarity to some of the vendor hype and mis-information that has been floating around lately.  I've heard many people say that Reflex, Blue Lane and Catbird provide security between virtual machines.  This isn't true.  What these vendors do is provide "monitoring" between virtual machines as stated on page 48 of Network World's article on virtual security.  What monitoring gives you in the case of Reflex is IDS (detection) and while useful it does not provide what many THINK it does.  Many think it provides prevention. 

<-- Click to enlarge

The way they provide monitoring is by taking a port on the virtual switch and enabling "promiscuous mode" and hanging a virtual security appliance off of that port.  Its in a sense like setting up a span port on a physical switch and mirroring all traffic out that span port.

This is definitely helpful from a visibility perspective  but does not give  you  VM to VM isolation or VM to VM intrusion prevention.  Take a look at the attached graphic from Reflex.  They displayed this graphic today on a webinar about PCI compliance.  You'll notice the VM's on the right can all talk to each other and the VM's on the left can all talk to each other.

<--Click to Enlarge

Now from the picture you can see that it does provide prevention from the GROUP of VM's on the left if they try to talk to the GROUP of VM's on the right.  I've yet to see anyone deploy their VM's like this however it does make sense to put your VM's in trust Zones. 

I am of the opinion however to put every server on their own trust zones and set up policy between those zones.

-JP

It looks like virtual security is getting some attention this week as seen on the front page of Network World.  There are multiple articles in this issue that talk about the security challenges in the virtual environment.  I suggest everyone interested in the topic take a read.

After reading the articles, I did want to put out a short blog today to bring clarity to some of the vendor hype and mis-information that has been floating around lately.  I've heard many people say that Reflex, Blue Lane and Catbird provide security between virtual machines.  This isn't true.  What these vendors do is provide "monitoring" between virtual machines as stated on page 48 of Network World's article on virtual security.  What monitoring gives you in the case of Reflex is IDS (detection) and while useful it does not provide what many THINK it does.  Many think it provides prevention. 

<-- Click to enlarge

The way they provide monitoring is by taking a port on the virtual switch and enabling "promiscuous mode" and hanging a virtual security appliance off of that port.  Its in a sense like setting up a span port on a physical switch and mirroring all traffic out that span port.

This is definitely helpful from a visibility perspective  but does not give  you  VM to VM isolation or VM to VM intrusion prevention.  Take a look at the attached graphic from Reflex.  They displayed this graphic today on a webinar about PCI compliance.  You'll notice the VM's on the right can all talk to each other and the VM's on the left can all talk to each other.

<--Click to Enlarge

Now from the picture you can see that it does provide prevention from the GROUP of VM's on the left if they try to talk to the GROUP of VM's on the right.  I've yet to see anyone deploy their VM's like this however it does make sense to put your VM's in trust Zones. 

I am of the opinion however to put every server on their own trust zones and set up policy between those zones.

-JP

In the physical world we have all grown to understand that there are many types of security solutions that are needed to secure your environment.  We purchase products like Switches with ACL's, Firewalls, Intrusion Prevention Devices, Patch Management Appliances, Network Access Control appliances and many times we for go "best of breed" and go for the "all in one" approach and deploy UTM devices.

So what has changed for the virtual environment?  Nothing really.  Those same types of choices and things need to be looked at and considered.

But!  The Vendor community would lead you to believe that you don't need various types of security products in your virtual environment.  They would also lead you to believe that you only need their solution.  In fact, they all compete against each other to some extent. 

I'm sure if you were to ask Reflex who their competitors were, they would tell you Blue Lane and Catbird, or if you were to ask Catbird who their competitors were, they would say Blue Lane and Reflex.  I know this because I use to site these companies as competitors myself while serving as the Chief Product Officer at Reflex Security.

As a vendor we spend so much time trying to show our value that we loose sight of the real value of security solutions working together to provide a comprehensive and secure solution vs. a single point solution.

Think about this for a moment.  None of the following vendors really compete with each other, in fact they can complement each other:

Blue Lane - Provides Inline Patch Management
Reflex Security - Provides Intrusion Prevention
Montego Networks - Provides Secure Switching (Firewalling + Switching)

Still Secure - Provides IPS
Catbird - Provides IPS

Now, you can say Reflex, Catbird and Still Secure compete but the rest are very different.

The real question is how do you deploy a Firewall, Patch Management and Intrusion Prevention products in your virtual environment.  Well, one way is to deploy them in "series" and each product will require a dedicated virtual switch.  Take a look at the picture bellow and you will see how messy the design looks:

<-- Click to Enlarge

Each time a packet has to enter and leave a vSwitch you will experience some performance degradation; however this is a requirement by VMWare if you want to install "guest-based" security appliances. 

This  security product to vswitch, to security product, to vswitch is very much like an A/D (analog to digital) conversion that takes place on  digital networks.  Each time you make an A/D conversion you introduce  noise and noise introduces signal loss, which introduces poor performance or sound quality.

Not to mention its just really messy looking!

So, how does one deploy the security products one needs in the virtual environment without causing a performance challenge and how do we get the vendors to stop competing and start joining forces to deliver solutions that work together?

Well, one way of doing this is to put some intelligence in the switching architecture so that it can play "traffic cop" and send traffic to the needed security applications.  This type of design would be security in parallel vs. in series.  Take a look at the bellow graphic and it will be more clear:

<-- Click to Enlarge

You'll also note from this picture that the Security Switch in the center is already able to see VM to VM communication and by it playing traffic cop as well as switch and firewall it can also extend its VM to VM capabilities to security products that do not have that ability.

In the previous picture, products were deploed in series and there was no VM to VM Patch Management, or VM to VM Intrusion Prevention or VM to VM Network Access Control.  What you were able to get was VM to Physical Patch Management, Intrusion Prevention, etc.

With a product such as a Virtual Security Switch you get VM to VM everything hooked up to the Security Switch. 

What a concept!  Companies partnering to provide a comprehensive security solution.  No competing, each company focuses on their core competencies and works together to give customers what they really need.

Think about it, does McAfee compete with NetScreen?  Did Checkpoint compete against Tipping Point back in the early days?  No, we had Firewalls, Anti-Virus, Intrusion Prevention products all co-existing and many of these vendors partnered with Extreme and Foundry since they were the connectivity point of the network.

I think the virtual network is no different, so vendors, please stop confusing the market and telling customers they only need IPS, or only need Firewall, or only need Patch Management.  What customers need is choice and the ability to have the products they choose co-exist without causing major performance and management challenges.

-JP

In the physical world we have all grown to understand that there are many types of security solutions that are needed to secure your environment.  We purchase products like Switches with ACL's, Firewalls, Intrusion Prevention Devices, Patch Management Appliances, Network Access Control appliances and many times we for go "best of breed" and go for the "all in one" approach and deploy UTM devices.

So what has changed for the virtual environment?  Nothing really.  Those same types of choices and things need to be looked at and considered.

But!  The Vendor community would lead you to believe that you don't need various types of security products in your virtual environment.  They would also lead you to believe that you only need their solution.  In fact, they all compete against each other to some extent. 

I'm sure if you were to ask Reflex who their competitors were, they would tell you Blue Lane and Catbird, or if you were to ask Catbird who their competitors were, they would say Blue Lane and Reflex.  I know this because I use to site these companies as competitors myself while serving as the Chief Product Officer at Reflex Security.

As a vendor we spend so much time trying to show our value that we loose sight of the real value of security solutions working together to provide a comprehensive and secure solution vs. a single point solution.

Think about this for a moment.  None of the following vendors really compete with each other, in fact they can complement each other:

Blue Lane - Provides Inline Patch Management
Reflex Security - Provides Intrusion Prevention
Montego Networks - Provides Secure Switching (Firewalling + Switching)

Still Secure - Provides IPS
Catbird - Provides IPS

Now, you can say Reflex, Catbird and Still Secure compete but the rest are very different.

The real question is how do you deploy a Firewall, Patch Management and Intrusion Prevention products in your virtual environment.  Well, one way is to deploy them in "series" and each product will require a dedicated virtual switch.  Take a look at the picture bellow and you will see how messy the design looks:

<-- Click to Enlarge

Each time a packet has to enter and leave a vSwitch you will experience some performance degradation; however this is a requirement by VMWare if you want to install "guest-based" security appliances. 

This  security product to vswitch, to security product, to vswitch is very much like an A/D (analog to digital) conversion that takes place on  digital networks.  Each time you make an A/D conversion you introduce  noise and noise introduces signal loss, which introduces poor performance or sound quality.

Not to mention its just really messy looking!

So, how does one deploy the security products one needs in the virtual environment without causing a performance challenge and how do we get the vendors to stop competing and start joining forces to deliver solutions that work together?

Well, one way of doing this is to put some intelligence in the switching architecture so that it can play "traffic cop" and send traffic to the needed security applications.  This type of design would be security in parallel vs. in series.  Take a look at the bellow graphic and it will be more clear:

<-- Click to Enlarge

You'll also note from this picture that the Security Switch in the center is already able to see VM to VM communication and by it playing traffic cop as well as switch and firewall it can also extend its VM to VM capabilities to security products that do not have that ability.

In the previous picture, products were deploed in series and there was no VM to VM Patch Management, or VM to VM Intrusion Prevention or VM to VM Network Access Control.  What you were able to get was VM to Physical Patch Management, Intrusion Prevention, etc.

With a product such as a Virtual Security Switch you get VM to VM everything hooked up to the Security Switch. 

What a concept!  Companies partnering to provide a comprehensive security solution.  No competing, each company focuses on their core competencies and works together to give customers what they really need.

Think about it, does McAfee compete with NetScreen?  Did Checkpoint compete against Tipping Point back in the early days?  No, we had Firewalls, Anti-Virus, Intrusion Prevention products all co-existing and many of these vendors partnered with Extreme and Foundry since they were the connectivity point of the network.

I think the virtual network is no different, so vendors, please stop confusing the market and telling customers they only need IPS, or only need Firewall, or only need Patch Management.  What customers need is choice and the ability to have the products they choose co-exist without causing major performance and management challenges.

-JP

Coming from NetScreen a performance leader in Firewall, Fortinet a performance leader in UTM and Reflex Security a performance leader in IPS many can see how performance is burned into my brain.

So, as I start thinking about security in the virtual environment I think not only about security but the performance impact security applications will have on the virtual environment.

People virtualize because CPU/Memory resources have been UNDER utilized.  People have traditionally bought a server to host an application and those applications are not always in use.  Many times they sit idle while other servers are maxed out and could use the help of those idle CPU's on the server in the next rack.  So, by sharing CPU/Memory resources virtualization allows for better use of resources and helps applications take advantage of CPU cycles when needed.  Ok, we get that.... Thats virtualization.

Security applications ARE typically utilized.  If there CPU's are idle then something is wrong.  We want those CPU's working 24/7 because we want to make sure we are secure.  Would you hire a security guard that slept on the job?  No, you want him attentive, walking around, checking for open windows, etc. etc.

So, now we have a challenge!  If we put security, something that is heavily utilized into an environment  that is intended for servers that were once under utilized we can cause a problem around why people virtualize in the first place.  Catch 22 eh? 

We need security but we don't want to pay for it.  Isn't that always the issue!

Well, not exactly.  The key thing to think about is the type of security that you need in the environment and then you need to asses whether or not that level of security is important enough for your business drivers.  Some things need to be protected more than others.

But, at a high level, think about this.  Security needs to be as close as possible to the things you are trying to protect.  The President has his security detail right beside him at all times.  This can be related to HOST based security.  The President also has Secret Service guys on the roof of the white house and on the front lawn.  This could be called Edge and Perimeter security respectively. 

Now, in the virtual environment HOST based security is VERY expensive from a resource perspective.  Imagine having Symantec Personal Firewall/AV on each virtual machine and lets say you have 20 virtual machines in an environment.  If all of those host based security tools kick off a virus scan at the same time, don't you think the CPU cycles will spike?

Once they spike, the CPU resources are not available anymore for the server applications which is what drove you to virtualize in the first place.

If I do some sort of network based security in the virtual switch then I'm as close as possible to the things I'm trying to protect without being on the things I'm trying to protect.  You now have one virtual security switch serving 20 VM's vs. 20 Symantec security applications.

Ok, so that makes sense.. straight forward right.  Its easier to manage 1 thing than 20 and you now have a shared security point in the network vs. distributed.  Got it.....

BUT, its not as simple as that.  The other question one needs to ask themselves is what type of security application is good enough for the assets I'm trying to protect.  Is it Firewall?  is it IPS?  is it Anti-Virus, etc. etc. etc.

Once you pick one you now need to think about the performance ramifications they individually have.

Firewall for example is less expensive than IPS.  It simply looks at less data.  IPS engines done in User space are more expensive than IPS engines done in Kernel space.   

I personally believe that IPS done in its traditional fashion is to expensive for the virtual environment.  Take Reflex Security's VSA product which I use to Product Manage at Reflex.  Its very expensive and depending on how its configured can consume 70% of the resources in the virtual environment.  Traditionally IPS has dedicated CPU's.  In fact, I designed a 10 gig IPS system that required 48 CPU cores.  It was great for the physical world but when you virtualize you don't want to dedicate that many CPU cores for IPS, otherwise you turn it into an IPS not a Virtual Environment.  You need those cycles for server applications.  In fact, if you go back and look at some of the press releases around the Reflex VSA product you'll see that Reflex multi-threaded their Virtual IPS product so that it could use more CPU's to deliver better performance in the virtual environment.  This doesn't actually make a whole lot of sense now that I think about it.  But, it was great marketing at the time!

See:  http://www.reflexsecurity.com/news/052207_reflexships.php

Firewall technology because its typically looking at headers and such take up far less CPU cycles to deliver the same level of performance as IPS.  But, their is a trade off with that to.  You don't get a view into the content.  So, it really comes down to the price/performance/risk assessment that companies need to make.

Soon you'll see vendors look for smarter ways to deliver Firewall + Content Inspection levels of performance without having to consume  as many CPU cycles.  This will then allow for a healthy balance of security and server virtualization.

John Peterson