Security in a virtual world

Virtualization of the data center is provoking fundamental questions about the proper place for network security services. Will they simply disappear into the One True Cloud, dutifully following applications as they vMotion about the computing ether? Will they remain as a set of modular appliances physically separate from the server computing blob? Should everything be virtualized because it can be?

Based on experience with large enterprises, we recommend that the network security infrastructure remain physically separate from the virtualized server/app blob. This separation allows you to maintain strong "trust boundaries" and high performance/low latency, without the loss of flexibility and adaptability of virtualized application infrastructures.

Large data centers have primarily safeguarded their servers with a well-protected perimeter and minimal internal protections. As zonal protection schemes were introduced to mitigate the unfettered spread of worms and intrusions, the natural boundaries became the divisions between the classic three tiers of Web infrastructures: Web, application and data layers.

More recently enterprises have further segmented these trust zones by service, business unit and other political criteria, yet this infrastructure does not lend itself to change. As three-tier architectures become vastly more flexible due to virtualization projects, the security infrastructure must develop its own flexibilty so it is never the bottleneck. Furthermore, it must also maintain the real-time guarantees of high throughput, high connection per second rates and low latency.

The good news is that this is precisely what forward-thinking architects and operations teams are designing and building right now. Best of all, some of these teams are discovering that, for once, security and performance optimization appear to benefit from the same strategy. Here's how.

There are two core principles in new security architecture designs. The first principle is to virtualize within the three layers, not across them, which forces inter-zone traffic to pass through physically separate security equipment.

The second principle is to use equipment that consolidates multiple security services that can be invoked in any combination depending on the type of boundary crossing, while maintaining performance, latency and connection rates. You can refer to this separate layer of security resources as the "second cloud."

The concept of virtualizing within layers (such as Web, application and database layers) vs. across layers can be depicted as follows. For example, Web servers and application servers are considered to pose risks of different levels.

Click to see: Figure 1

In Figure 1, VMs of different risk levels are on the same servers and boundary transitions between zones happen entirely inside one or more servers. In Figure 2, all Web VMs run on one physical set of servers while the application VMs run on a separate set. Boundary transitions in this model happen outside of each group of servers.