Virtualizing Security Will NOT Save You Money; It Will Cost You More
In my post titled "The Four Horsemen Of the Virtualization Apocalypse" I brought to light what I think are some nasty performance, resilience, configuration and capacity planning issues in regards to operationalizing virtualized security within the context of security solutions as virtual appliances/VM’s in hosts.
This point was really intended to be discussed outside of the context of virtualizing security in physical switches, and I’ll get to that point and what it means in relation to this topic in a later post.
I wanted to reiterate the point I made when describing the fourth horseman, Famine, summarized by what I called "Spinning VM straw into budgetary gold:"
By this point you probably recognize that you’re going to be deploying the same old security software/agents to each VM and then adding at least one VA to each physical host, and probably more. Also, you’re likely not going to do away with the hardware-based versions of these appliances on the physical networks.
That also means you’re going to be adding additional monitoring points on the network and who is going to do that? The network team? The security team? The, gulp, virtual server admin team?
What does this mean? With all this consolidation, you’re going to end up spending MORE on security in a virtualized world instead of less.
This is a really important issue because over the last few weeks, I’ve seen more and more discussions surrounding virtualization TCO and ROI calculations, but most simply do not take these points into consideration.
We talk about virtualization providing cooling, power and administrative cost-avoidance and savings. We hear about operational efficiencies, improved service levels and agility, increased resource utilization and reduced carbon footprint.
That’s great, but with all this virtualized and converged functionality now "simplified" into a tab or two in the management console of your favorite virtualization platform provider, the complexity and operational issues related to security have just faded into the background and been thought of as having been absorbed or abstracted away.
I suppose that might point to why many simply think that security ought to be nothing more than a drop-down menu and checkbox because in most virtualization platforms, it is!
When thinking about this, I rationalized the experience and data points against my concern related to security’s impact on performance, scale, and resiliency to arrive at what I think explains this behavior:
Most of the virtualization implementations today, regardless of whether they are client, server, production/QA or otherwise, are still internally-facing and internally-located. There are not, based upon my briefings and research, a lot of externally-facing "classically DMZ’d" virtualized production instances.
This means that given the majority lack of segmentation of internal networks (from both a networking and security perspective,) the amount of network security controls in place are few.
Following that logic, one can then assume that short of the existing host-based controls which are put in place with every non-virtualized server install, most people continue this operational practice in their virtualized infrastructure; what they did yesterday is what they do today.
Couple that with the lack of compelling security technologies available for deployment in the virtual hosts, most people have yet to start to implement multiple security virtual appliances on the same host.
Why would people worry about this now? It’s not really a problem…now.
When we start to see folks ramp up virtual host-based security solutions to protect against intra-vm threats and vulnerabilities (whether internally or externally-facing) as well as to prevent jail-breaking and leapfrog attacks against the underlying hypervisors, we’ll start to see these problems bubble to the surface.
What are your thoughts? Are you thinking about these issues as you plan your virtualization roll-outs?
/Hoff
>Are you thinking about these issues as you plan your virtualization roll-outs?
Yes. And I'm not sleeping, goddammit.
It would be nice to think that when the technology zealots try and force there next new bright shinny thing into the enterprise they may perhaps may just have thought about the security risks – I wish!!. Currently I am trying to refine a set of security requirements for the virtualisation which will try and look at the technology as a capability rather than just a bolt on to an already secure(-ish) server. However trying to get buy from the engeering team to even recognise the the risk is the tad challenging to put it midly. But I will overcome š If you or anybody else has already looked at the security issues and translated them into a set of security requirements to get the risk into the manageable zone it would be great to see them – save me some work
Interesting Bits – May 9th, 2008
I guess, your comments are very fair however are more in the granular details – with the right set of policy and deployment standards, the cost can be zeroed right from the initial days of deployment and you need to strike a balance between the risk vs. the benefit – benefit as in agile environment, risk as in exposure to security threats.
For example one of the policy could be:
No sharing of virtualized zones between business applications. Say, ERP and HR applications.
With this, you reduce the security exposures and leverage existing set of controls (assuming existing controls are strong). However, here is where you strike a balance between risk vs. benefit. You lose a bit of agility of virtualization however it is well worth it.
Another policy could be:
All changes to the virtualized zones/clusters align with the existing change processes with appropriate approvals including access changes. Again, assuming there is a strong change process and security related changes are well addressed.
This would help increase awareness and reduce the 'knee jerk' reaction to make changes to virtualized zones.
Another policy could be:
Migration to production (regardless of OS, Database, Applications, interfaces, Network connectivity, storage changes) complies with Security checklist – this checklist ensures securing the base operating system (hardening), physical and logical access to console, admin access to each zones and so on for each associated layers.
Another policy could be:
Logs of changes are maintained in the system (global zone and virutal zone) and is audited periodically.
This is to ensure that potential exposures are detected and addressed.
Hope this helps
…so the issue with the "no sharing zones" from a cost perspective is that depending upon the number of zones, you may have to increase the number of physical hosts to accommodate them versus mixing VM's. That hardware and software costs is NOT zero, especially with virtualization, OS, security, and management tool licenses!
Secondly, while I don't argue that crafting policies are the right thing to do, studies clearly show that people are NOT following the same configuration/security standards in virtualized environments as they do in the physical world.
Thirdly, due to the fact that the separation of duties is now blurred (if not evaporated,) existing change management processes (checks/balances, etc.) are compromised as the virtual server admin is also the security guy is also the network guy…
We could go on, but I'm not really arguing about POLICY here. I am arguing about the constituent control deployments in host and network licenses (and the residual operational impact from an FTE perspective) that will INCREASE in a virtualized environment.
Perhaps a tool/calculator is in order…
/Hoff
I agree with you – if somebody could come up with a TCO calculator on "about the constituent control deployments in host and network licenses (and the residual operational impact from an FTE perspective) and Hardware & software license costs" as pointed by you, that would be awesome.
I would appreciate if you could post the link to those studies. I am intrigued.
I disagree that Virtual admin guy is now the security admin as well as network admin unless I haven't understood the virtualized computing clearly (I am referring to Fijitsu, IBM blades housing ESX or Sun Virtualization tech).
The virtualization technology world is separated by logical layer namely storage and Network and in my understanding, the traditional storge and network admins are still the key players when it comes to maintaining the frame uptime by providing storage and networking needs.
However, I do agree with your SOD comment on zone admins and the console admin – it has to be separated as a policy with 2 separate team/individuals and is not impossible. Is there something our Unix Admins are not telling me? Is my understanding wrong here?