Neil MacDonald

I still see people getting bogged down in rather meaningless arguments as to whether or not firewalls will be virtualized.

They will (and, in fact, are).

The bigger trend is the shift from proprietary hardware to software running on commodity hardware (in almost all cases, x86). That’s the big shift. Whether or not a given security control is packaged as a virtual machine is a matter of requirements (and to some extent preference).

Some information security curmudgeons prefer to see a separate box perform the security policy enforcement. They like the sense of “strong” separation of duties that comes with security controls being embedded in a separate physical appliance. The mistake here is equating physical separation with logical separation of duties or an outdated belief that “infrastructure can’t protect infrastructure”. Absolutely we must maintain separation of security policy formation, but it is a mistake to assume that the policy enforcement can’t take place within the infrastructure itself.

Indeed, a recent 2012 Gartner survey (full copy for clients here) showed that there is a preference for virtualized security controls over external security controls run outside the VM environment for virtualization/private cloud projects. Further, they indicated a preference for integration security controls (e.g. VMware’s vShield) within the platform – in other words, integrated into the infrastructure.

virtual appliances, installed as software on commodity hardware or in the cloud (as IaaS based virtual machines).

In a recent research note for clients titled “The Impact of Software Defined Data Centers on Information Security”, I outlined many of the drivers to software-based security controls in the context to the switch to software defined security:

A common misconception with the shift to software-defined security (SDSec) is that all security controls must move to software. There are cases where this makes sense, and cases where it does not. The security data plane (where packets and flows are inspected) can benefit from the processing power of hardware-based inspection. Like SDN, hardware has a role to play in SDSec, especially when high throughput is needed. However, there are cases where SDSec policy enforcement is useful, such as:

• To scale out (as opposed to hardware scale-up) and parallelize the enforcement of security controls.
• To potentially reduce the cost, as compared with the use of physical appliances
• To speed the provisioning of security controls by making their provisioning as easy as provisioning a new VM.
• To enable flexible placement of security controls. For example, as most data center appliances shift to standardized hardware, the security controls may be placed onto the infrastructure platforms — for example, embedded within a storage array or as a software blade in a router. Another example would be placement within the SDN controller.
• To provide visibility into blind spots, such as inter-VM communications, without requiring all traffic to be routed to physical appliances.

Virtual or physical? The answer is both!

The myth is that this is an either/or question … and add to this – on branch routers and in the cloud and on software based SDN controllers and on commodity hardware and in converged servers – all within a consistent management console and policy management framework. The future of information security is in software.

You choose what makes the most sense for your workloads, not the vendor. Favor vendors that get this and support your journey.

2 Comments »

Category: Cloud Cloud Security Next-generation Security Infrastructure Virtualization Virtualization Security     Tags: Adaptive Security Infrastucture, Best Practices, Defense-in-Depth, Next-generation Security Infrastructure, Software Defined Security, Virtual Appliances, Virtualization Security, VMware

Share

Tweet