For those of you who missed it, my editor and I have decided to close the Norwegian IT website ITproX. As part of this, two of my podcasts on virtualization-based security are re-published here.
I have been fortunate to join Derek Granito, Product Manager in the Enterprise Security department, with a primary focus on virtualization-based security (VBS), especially around memory integrity. Read the interview or follow along with the video interview for extra spice!
Hi Derek, can you tell us a little bit about yourself and what you do?
My team and I are responsible for building new features and capabilities around these security features so that we make them available to other Windows teams and hardware vendors.
What does memory integrity do?
It’s a relatively complex interplay where we use the hypervisor to create our own dedicated environment for the operating system’s kernel to operate. In this way, we prevent malicious code from writing to the Windows kernel and manipulating sites it should not make changes to.
Before memory integrity is activated, the operating system checks for applications, especially drivers, that will not work with memory-integrity. Often these are drivers that have not checked the support for the correct parameters, but sometimes it happens that the drivers are coded poorly and try to write to areas of memory it should not. This is often one of the reasons why blue screens occur, when drivers do not follow the rules of the game and Windows shuts down to protect the integrity of the kernel.
Does VBS impose any special requirements on the hardware it will be run on?
On the whole, no. If your computer supports Hyper-V, it will also support Memory Integrity. It’s also Platform independent, so you can enable this functionality on both Windows 10 and Windows Server, which is worth keeping in mind for administrators.
However, and this is somewhat essential, some improvements have been made in recent years. This applies to both the hypervisor as well as hardware improvements. This means that more and more devices coming out of the factory now have these features enabled from the start.
So the features have seized a little too many resources on the performance of previous hardware components?
That’s part of the reason, but it’s also the aspect of new security features imposing new compliance requirements on both the hardware as well as the overall ecosystem of the machine being delivered. Some of these are application requirements, so that we do not destroy the applications that run on the Windows computers of the users (Editor’s note: for example, virtual printers and virtual hardware).
Devices like Surface Book 3 and Surface Pro 7+ come with these security features at the factory, is there a significant risk difference if activated a year into the life of the device?
While it’s best to have memory integrity and other VBS features enabled at the factory, turning on this feature is a huge win – even if a device has been in production for a long time. If you combine memory integrity with firmware protection, you are secured from some of the most devious forms of attack we face.
Virtualization-based security is a concept that is becoming increasingly ingrained, but where does the idea come from? Do we have any stories from the early days of technology?
Much of the technology comes from the challenge we had associated with malicious attacks that gave elevated privileges after abusing the rights of the kernel. In practice, this means that malicious code had administrator or system privileges as a result of running in the context of the kernel of the operating system, and we wanted to break this.
One of the best ways to strengthen the Windows kernel was to create a new level of privilege that bypassed the core of the operating system, which is the most privileged zone of the hardware — that is, it is not the core of the operating system that holds the highest privilege to the platform, but the dedicated area of memory in a dedicated virtual machine.
Those of us on the outside of Microsoft find that virtualization-based security works in multiple levels and multiple layers. One of them is the “Credential guard” that protects the user’s identity and password on the machine, is there any point in protecting the kernel of the operating system if they get hold of the identity?
That’s a great question, and it’s included as a solution to a complex problem. So VBS is a concept with several elements, which Credential Guard consists of, among others.
Take a version of Windows where this feature isn’t enabled, and your user identity, or credentials if you will, will be stored in a specific place in Windows. With Credential Guard enabled, we store this information in a secured section of the machine’s memory so that it is more challenging for an attack to retrieve the information that resides there, but you are right. If an attacker manages to gain access to your identity, they may also be able to authorize access in the system that you are not aware of.
For those who don’t have this enabled, is there an easy way to turn this into the ecosystem?
For each machine, you can enter “core isolation” and turn on the switch found here. The operating system will then look for applications and drivers that are not supported in kernel isolation and prompt you to take action here before it can be activated.
What’s the next big, cool, thing in VBS that you can share with us?
So I don’t know if you’ve heard of the concept of “Secure core”? It is a set of functions in the VBS concept where everything is activated. One of these is something that we haven’t talked much about yet, but is Firmware protection. If you go to the security settings and look for it, it will depend on your hardware whether you see it or not. This is one of the major new safety features that has come recently and which will provide a significant safety improvement for the unit fleet.
Memory integrity relies heavily on something called “Secure boot” and the entire security chain that occurs during machine startup. When it comes to Firmware protection, what this feature does, conceptually, is that also the firmware has not been tampered with since the last time the computer was running, or out of context by the Operating System.
Isn’t this something that comes from Xbox?
Well, that’s exactly right, and the security concept comes from our game console. What made this somewhat easier was that we owned the entire ecosystem. Both the hardware, the operating system, and all applications allowed to run on the Xbox platform. Windows is a very different story with a decades-old software library.
Is there an easy way to get an overview of which of these security features are enabled?
There are a couple of places, but the easiest of them is to type “msinfo32” in the Windows search window where you can look for the “Virtualization-based security features available” attribute. This will show how many of the virtualization-based security features are enabled.
Any last minute word before we round up?
Yes! If you notice applications or drivers that are not supported in memory integrity – let us know in the feedback app! We get regular reports of which applications and drivers are not working, and we do our utmost to facilitate a smoother implementation, or we work with hardware vendors to update the drivers to be supported.