Decouple an App From the OS Before You Move to the Cloud

Virtual Application Appliances

Subscribe to Virtual Application Appliances: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get Virtual Application Appliances: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

VAA Authors: Destiny Bertucci, Ray Parker, William Schmarzo, Pat Romanski, Gilad Parann-Nissany

Related Topics: Virtualization Magazine, Security Journal, Virtual Application Appliances


Virtual Security Without Gaps

Understanding the issues and options of next-generation security solutions is a great first step

Virtualization Magazine on Ulitzer

Implementing security is not a perfect science. It doesn't matter if you're talking about security for airports, bank vaults or computers; there will always be a struggle between the ultra-secure, practically unusable solution and the barely secure, user-friendly solution. Given unlimited resources (time, $$, etc.) and a great deal of leeway to infringe on peoples rights or business practices, you could create a security solution with little to no "gap." In reality though, we end up trying to balance security and usability and do the best we can to fill as many gaps as possible.

When trying to protect virtual machines (VMs) you have to think of the same elements. For the most part, it's safe to say nobody wants to have their servers wide open waiting to be exploited by a new piece of malware or malicious hacker. However, they also don't want to break functionality, reduce manageability or negatively impact performance. There are some basic types of classifications we can make about organizations and virtual security "gaps."

1. Type 1 (Non-Adopter). Some organizations have taken no extra precautions in their virtual environments and simply justify it as "We don't do anything special for internal servers, why should we do it for virtual internal servers?" Or perhaps say "We have a firewall in front of the VMware servers." For those who don't have sensitive systems virtualized, then perhaps this is a fine stance but, those who have virtualized important systems should consider the fact those VMs are communicating on a virtual network and communication between them isn't protected. If one VM gets compromised, it could compromise all of the other VMs before a single packet hits the traditional physical network. Ignoring a basic practice of layered security (security internally and on perimeters) comes with great risk.

2. Type 2 (Using VLANs and/or Host-Based Firewalls). Those who are funneling traffic out of the virtual network via VLANs and then doing some filtering between VLANs have at least taken a step to protect their resources. The problem is VLANs require a physical device to do the security; they become difficult to manage, can lead to issues with VMotion and worst of all end up creating "groups" of systems that can still be compromised (one system in a VLAN can compromise all others in that VLAN). Host-based firewalls eliminate that fundamental "group" issue with VLANs but they don't reduce complexity and unfortunately they mix security context with the very element they are trying to protect. Step one in many pieces of malware is to deactivate local OS firewalls!

3. Type 3 (Using First Generation Virtual Security Products). Organizations that have recognized the need to layer security in a dynamic and flexible manner have purchased a solution that is integrated with the virtual management infrastructure (i.e., VMware VirtualCenter/vCenter) so new machines are seen as they are created and some type of security policy (firewall, IDs, etc.) is implemented within the virtual network.

This first-generation architecture relies on bridging internal vSwitches with a security VM. The issue here is that bridge mode firewalls can't give true individual VM protection when traffic doesn't traverse the security VM. Any non-VMsafe solution won't be able to implement full protection for every single VM. Altor has a bridge mode solution for older versions of VMware (it's the only solution possible prior to vSphere 4.0). If you're forced into using an older version of VMware, you can still use Altor to protect your VMs but you will need to understand that VMs in the protected segment will be able to freely use non-TCP protocols to communicate with one another.

4. Type 4 (Using Next Generation Virtual Security Products based on Advanced Hypervisor Integration). vSphere 4.0 from VMware brings many new features and one of the most important is the release of VMsafe.

Clearly not everyone is going to be able to adopt the next-generation security solutions, but understanding the issues and options is a great first step.

More Stories By Kevin Piper

Kevin Piper is currently the Director of Technical Operations at Altor Networks where he helps customers deploy solutions to protect their virtualized environments. Prior to joining Altor Networks, he spent 8 years at Check Point Software Technologies. In his last role at Check Point, Piper was the Manager of the Partner Solutions Engineering team and was responsible for building and testing some of the industries most advanced security solutions. Previously, he worked as a Technology Consultant in the Compaq Professional Services Division where he spent many years building secure networks for a variety of companies

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.