Joerg Fritsch

A member of the Gartner Blog Network

Joerg Fritsch
Research Director
1 year at Gartner
15 years IT Industry

Joerg Fritsch is a Research Director in the Gartner for Technical Professionals Security and Risk Management Strategies team. His specialties include information security, data center and cloud security, big data (analytics), cloud computing, PaaS, distributed systems, messaging and event-driven systems, and very fast networks and servers. Read Full Bio

Coverage Areas:

About commingling Virtual Machines

by Joerg Fritsch  |  February 3, 2014  |  4 Comments

An inquiry that pops up every now and then is whether a computing node with a hyper-visor installed should be considered good enough to segregate virtual machines with different security levels such as the front end (web server) tier and the database tier, –that could well be an ERP, of an eCommerce platform. You get the idea. While for example firewalls have historically been conceived with the notion to be a security technology suitable to withstand attacks and protect the physical perimeter, hyper-visors were conceived to run virtual machines. Data center consolidation, server consolidation and public clouds eventually lead to the question in how far a single computing node can be leveraged to an extend that it segregates & runs VMs with different sensitivity. Well, there are three answers to this question.

The savings are not what you think they are. The first answer is a non-answer. No matter how secure it is or not, I am frequently wondering what savings an enterprise that does not sell cloud computing services expected from this. The virtualization ration of [computing nodes : virtual machines] is in any environment only so much. Let’s do an exercise. Assuming you have a virtualization ratio of 1:7, 60 blue VMs and 30 green VMs. In this case you would end up with 13 computing nodes where eight would run 56 blue VMs and four would run 28 green VMs. One computing node would eventually end up running a mix of four blue VMs and two green VMs giving you and overall saving of one physical node. You can change the numbers as much as you want, for example increase the virtualization ration, but it won’t cause a huge change to the overall result. You can then argue with error conditions and moving VMs around a bit dynamically etc.. But I say: it won’t change much.

commingling_2

The second answer is that most hypervisors are common criteria evaluated and EAL4+ certified concerning for example their resource control and process isolation. If this is new to you, Common Criteria Evaluations and EAL certifications are the certification path that leading firewall vendors go through. Otherwise they would not be able to sell to the governmental market where a valid EAL4 certification is a pre-requirement for most of the use cases. In short: To date most hypervisors have EAL/Security Certifications that market leading firewalls also have. Some of them even never reached the stringent requirements of EAL4+. There is then some fine print as to what was exactly the security target of evaluation, but this should not distract. hypervisors are certified to be pretty secure animals. Of course I know about Red Pill and Cross-VM side channel or CPU cache attacks. But these are not happening every day and I believe that in your private cloud or on-premise virtualization you probably don’t have to worry.

And what then? What if you bought into all of those, if I have made you a believer into EAL certifications and you want to go ahead and put this into practice to save two physical nodes? Well, your data must come from somewhere, isn’t it? Your VMs are probably connected to some sort of SAN where you need to follow up with some serious SAN zoning, otherwise your SAN would defy the idea of a collapsed (or condensed) virtualized environment. And, how about your network? VLAN separation? SR-IOV? If you truly want to collapse your network across different levels of sensitivity, you will need to think of more than only the hypervisor. Maybe the hypervisor is even the least of your worries.

4 Comments »

Category: perimeter server security virtualization     Tags:

4 responses so far ↓

  • 1 About commingling Virtual Machines | All that Cuteness   February 3, 2014 at 2:29 pm

    [...] By Joerg Fritsch [...]

  • 2 nicolae   February 5, 2014 at 8:11 pm

    Imho this blog post does not contain any useful information whatsoever. Saying that an attack “does not happen every day” is…amateur at best.

  • 3 Joerg Fritsch   February 6, 2014 at 3:19 pm

    @nicolae

    Blogs do reflect the unfiltered and unedited opinion of the analyst that can at times be a little edgy.

    I think these attacks are all academic. To date none of them that I’ve seen is a realistic setting.

  • 4 SteveB   February 15, 2014 at 1:59 pm

    @joerg,

    As a security researcher in a previous life, involved in (pre-Common Criteria Orange Book security at B2 and higher), and having been more recently involved in consumer electronics where attacks were continuous and sometimes successful, this post and your reply to a comment made me a bit nervous.

    With modern attack tools, every known attack is eventually included in a kit or product, making script-kiddie or malware-as-a-service users capable of seemingly esoteric attacks. Examples like Target come to mind.

    Security is a weak-link phenomenon. If any service running inside your data center gets *any* input from outside your security perimeter, you should assume that in the worst case the VM running it can be compromised. (Never mind internal attacks that might come about when your employees bring their laptop back to work from, say, Sochi. Ever notice that if you install virtualization software for Mac, and install the “helper” tidbits they supply for Windows inside the VM, that the OS running in the VM has full access to your Mac file system? And that Windows is the most-common OS installed in that VM, and the target of beaucoup malware attacks? Still feel safe?)

    You only need to read CERT notices for a while to see the name of something you recognize from your own network. You then have to ask yourself where the attack can be escalated from that failure — to the VM? to the network or VLAN? to the hypervisor? to the POS terminals the service connects to?

    Your final paragraph is right — there are likely to be more-vulnerable places in your network than the hypervisor, but it’s a game of probability. If a good hypervisor attack (maybe a zero-day, maybe not, but stay patched just in case) becomes known, COUNT ON IT being in an attack kit or malware product — those guys are good. Do your best to keep it out of your physical network (keep in mind that VLAN tags are often set on network traffic by non-virtualized OSs and hypervisors), and make sure that you are watching for “unusual” behavior. Use suspenders, and a belt, and duct tape to put together your internal barriers — the more barriers you put up, the less likely it is that a scripted attack will succeed. The Common Criteria are about raising the cost of attack, not setting the probability of success to zero.

    It’s dangerous to assume that because you haven’t personally seen an attack in a “realistic setting” that it doesn’t exist. The Careto attack recently noticed by Kaspersky has been out there for 7 years. Think about it… 7 years, without being detected. Huh. And now, anyone reading the Kaspersky report knows how they did it.