I sometimes find myself talking about a topic and getting blank stares. Then a year or two later, everyone is suddenly talking about it. One such topic is security virtualization. Until now, those two words were seldom seen together. You would have to live in a cave to have not heard about server virtualization, and storage virtualization also is discussed widely in storage areas. Network virtualization applies to virtual LANs (VLAN) and MPLS, so lots of people discuss that. But security was never brought into the virtualization discussion.

This is a shame, because security has a lot to gain from virtualization — and virtualization has a lot to lose if it has no security controls. So what do I mean by security virtualization? At the most basic level, it is security that has the physical layer abstracted. One easy example is the ability to take a single physical firewall and partition it into multiple virtual firewalls to serve different administrative domains or applications.

But the real challenge, and the reason security and virtualization are discussed a lot today, is that server virtualization is moving beyond the development environment and into production. In a production setting, many of the ideas that seemed great in development are running into objections by the security team and auditors. “So, you took the three-tier architecture with firewalls and collapsed it into a single server pool? How are you controlling between the virtual machines?" And thus, the on-demand, virtual-moving dream of dynamic servers smacks hard into the static, inflexible reality of security-by-physical architecture.

Which leads to the conundrum: Is security going to thwart your business agility and new computing paradigms? Or are you going to find a new, more dynamic way of doing security? Security virtualization is therefore more about making security infrastructure (hardware, software or both) flexible enough to co-exist and contribute to a virtualized data center environment. In a virtualized environment, some of the old concepts have to go: IP addresses do not identify servers because servers can be redeployed on-the-fly to a different subnet. So your “IP A.A.A.A can send packets to IP B.B.B.B" access control design is no longer relevant or helpful. What was at IP A.A.A.A has moved to a different subnet/data center/continent.