Our Head of Emerging Technologies, Kenny Lowe, attended Microsoft’s Ignite Conference in Atlanta. While there, Kenny spoke at breakout sessions about Shielded VMs. In this blog, Kenny explains what Shielded VMs are.

So having noted in my previous post that I was asked to speak about my experience in operationalising a Guarded Fabric which hosts Shielded VMs, the question which you, dear reader, may have, is “what the blazes is a Shielded VM and why should I care?”

Well it’s a good question, so well done for asking it. Before I dive into what a Shielded VM is and what it aims to achieve though, first I want to take a little detour through human psychology.

We humans are inherently built for pattern-matching and auto-association – there’s a wonderful book called ‘Thinking, Fast and Slow‘ which dives deep into this trait and which I heartily recommend reading. Wherever our brains can, they look for the familiar, correlate, and file as neatly as they can – in many cases we have no conscious control over this.

If you read the word ‘Library’, you have no choice but to automatically understand it and process it. You simply cannot make your brain incapable of instantly recognising, reading, and understanding the word. This is a wonderful evolutionary trait which lets us make decisions in split seconds and understand relatively new concepts which relate to existing knowledge with ease. This is a very base definition of ‘Thinking Fast’.

If I ask you to solve 1463 * 432 in your head, then unless you are a mathematical savant you will need to engage a series of conscious processes and steps to work through the multiplication to find the answer. This is a very crude way of explaining ‘Thinking Slow’.

Thinking Fast and Thinking Slow are not complementary processes which work in harmony, they compete and conflict, and can cause significant angst and annoyance, or even danger. Everyone who drives knows well the feeling of getting in their car, setting off to work, arriving at work and wondering how the hell they got there as there’s no memory of the drive. The fast thinking portion of the brain has taken over and is almost automatically driving a route it knows well while other parts of the brain engage elsewhere to focus on other thoughts. If the route was ever unchanging and always the same every day this would be an extremely valuable trait, however other drivers are unpredictable and conditions change, so we’ve also all experienced being jolted into alertness as another driver swerves in front, or roadworks get in the way.

All of the above is contextually relevant, because without fail every time I start to explain Shielded VMs to someone, they immediately drop into a fast thinking modality, relate it to basic encryption, nod and file it away in their mind as just that. They could not be further from the truth. So before I explain what assurances VM Shielding provides, first empty your mind of preconceptions about existing security technologies, and believe me when I say that this capability is completely unique to Hyper-V 2016 today.

Shielded VMs as a concept came about because of a growing attack vector which Microsoft Research identified around four years ago. This attack vector covers many different methods of infiltrating and exfiltrating data from virtualised environments, but the one commonality across them all was the leveraging of fabric-level admin credentials to conduct malicious activities.

Today, a virtualisation admin is the god-emperor of all that he or she has purview over – there is no effective way to protect the data and secrets contained within a virtual machine from the fabric on which it runs. Whether it’s taking a copy of a VHDX/VMDK on USB and attacking it or booting it off-site, consoling on to a VM, capturing live migration or state traffic, attaching debuggers to VM processes, or a plethora of other routes, the contents of virtual machines today are inherently open to the admin credentials of the fabric on which they run.

I say admin credentials, because more than a few people I’ve spoken to about this have taken significant umbrage at the implication that they may be in some way untrustworthy or capable of malicious activity. ‘IT is an position of trust, we’re given these services to manage and it’s our duty to protect them.’ is a common line of rebuttal, and I agree wholeheartedly.

There’s no avoiding the fact though that today the majority of data breaches which occur are caused by insider attacks, be it due to malware, compromised credentials, coercion, or, yes, malicious administrators. This isn’t a slur against sysadmins, it’s a recognition of three routes to insider attack which can occur even to the nicest sysadmin, and that in all large-scale industries it’s inevitable that bad actors and disgruntled employees will at some time exist.

What Shielded VMs aim to do is completely fill in this hole in the security model that we currently have patched together with process, audit, and trust, and completely remove it as a valid attack vector. It does this through a series of very clever technologies which come together to form a cryptographically trusted platform on which we can run Shielded VMs, in a model we call a Guarded Fabric.

I’m not going to go into any great detail here about the methods in which this is achieved, for that I strongly recommend watching this Dive into Shielded VMs with Windows Server 2016 Hyper-V session from Ignite 2016. All I want to achieve here is an understanding of what the feature seeks to and manages to achieve.

• VM Disks are encrypted at the VM level using strong cyphers and the most secure method of key release we have today, TPM.
• VMs are only allowed to boot/migrate on cryptographically provably healthy hosts. i.e. hosts which have not been compromised.
• PowerShell Direct does not work to a Shielded VM.
• Console connections to a Shielded VM will not work.
• RemoteFX is disabled.
• Specific WMI calls are disabled (screenshot, thumbnail, keyboard, mouse)
• Guest File copy IC is disallowed.
• IMC registry hive injection is disallowed.
• Some virtual devices like debug devices, synthetic keyboard, synthetic mouse, serial device are removed.
• Shielded VMs run inside a protected process which will not allow debuggers to be attached.
• A whitelisted Code Integrity Policy is enforced on hosts to ensure that only known trusted binaries can run on them.
• All live migration traffic is encrypted.
• All VM states are encrypted.
• VM access is available to owners only, via certificate signed RDP or key-trusted SSH.
• For all the encryption items above, the VM owner owns and maintains the encryption keys, not the fabric admin.

For a hosting service provider like ourselves, this allows us to guarantee to tenants that their VM secrets are completely hidden and protected from us the fabric admins. For tenants, they can run workloads which have stringent compliance and regulatory requirements in a multi-tenanted environment. Enterprise admins can enforce strong separation between Hyper-V administrators and sensitive workloads. I would argue that this is a huge benefit to enterprise sysadmins, who can use VM Shielding to indemnify themselves in the event of data breach, as the data remains completely encrypted and secure.

The absolute most important point here is that all of the above trust is rooted in hardware through TPMv2 based attestation. In a fully operationalised and working Guarded Fabric there isn’t a locked down subset of admins who can still compromise the security model, the trust is rooted in cryptography, and in the hardware.

Hopefully the benefits here are now obvious, and why we as a hosting provider are so excited about the capabilities that VM Shielding allows us to bring to our customers.

Hopefully it’s also obvious that VM Shielding represents a leap step forward in virtualisation security that goes way beyond anything else available in the market today.

Want to learn more about Shielded VMs? Watch our video.