Can you get to a more secure computing platform than this? Microsoft would like you to. Really, they would. In the Anniversary Update to windows 10 (aka build 1607) they added more capabilities for you to use, and you should be looking at them.
Ultimately, the goal of any malware attack is to obtain administrative and/or system access. Anti-virus/malware protections depend upon detecting known signatures to prevent this, but are always vulnerable to attacks using code with different signatures or on systems not yet updated with the latest list. Intrusion protection systems attempt to prevent access to get the malware payload to the system, or detect suspicious activity after an infection has occurred.
A more complete solution is necessary, and with the Windows 10 Anniversary Update (and soon Server 2016), Microsoft is adding some interesting changes that might help us to get more secure. Keep in mind that nothing is foolproof, you will still need to monitor, but hopefully you can prevent enough and encourage outside parties to look elsewhere. In this article I’ll provide an overview of what is new, why it is important, and then finally who should care.
BitLocker / Disk EncryptionWhole disk encryption is about protecting the data at rest. BitLocker and 3rd party equivalents prevent modification of the disk when the computer is not running. We normally consider this in the context of having the data be stolen, but it also prevents modifications when the OS is not running. This isn’t anything that is new in Windows 10, but if you are thinking about the security of the OS you should start with disk encryption everywhere.
Virtualization Based SecurityAlthough portions of what this article discusses may be implemented on machines that do not have the hardware requirements to run a hypervisor, having hypervisor capable hardware, including IO-MMU, SLAT, and TPM, present and enabled is key to properly securing the operating system of the future. Microsoft generically refers to this as “Virtualization Based Security”.
Although in theory other hypervisors could enable features integrated with the Microsoft OS, it isn’t clear if Microsoft has made the necessary information public at this point for them to do so. So all of our experience with these features right now is with using the built-in Hyper-V capabilities. We don’t need the full blown hypervisor that can run Virtual Machines, just the portions that support trusted execution and secure memory partitioning. In the “features” portion of the control panel, you would enable this by selecting the Hyper-V Hypervisor without Hyper-V Services.
Selecting the Hyper-V Services in addition to the Hypervisor would enable the running of virtual machines, but this is not necessary for the features of this article. It is also not necessary that this operating system be running directly on hardware. With nested hypervisor support (such as in the upcoming Server 2016) this OS may be a VM already as long as you enable the second level hypervisor in the VM itself as shown.
Figure 1.
In addition to enabling the hypervisor, you also will also want to configure the features of Virtualization Based Security using a local or group policy object, shown below.There are several parts to virtualization based security which may be independently leveraged as appropriate.
Figure 2. Device Guard and Secure Boot
Assuming that you already encrypt the disk at rest, a more complete and secure solution must start with coverage of the system boot before you can even have a hypervisor or an OS. Newer 64-bit hardware supports UEFI, and UEFI is needed for you to enable Secure Boot as part of this protection. When enabled, which is something you do in the UEFI BIOS setup, Secure Boot records information on all of the EFI modules and stores them in a secure, password protected, way in the BIOS. So once you have the known good BIOS on the system, it will only boot using this version unless someone with physical access and the BIOS password changes it out.
The OS image being booted is also protected by Secure Boot. This means an attacker can't boot to an alternate OS to make the changes and then boot you back to Windows unless they have physical access and the UEFI password. After booting, Windows 10 detects if Secure Boot is enabled, which then enables additional protections to be implemented from within the OS. You can check the BIOS mode and if Secure Boot is enabled by using the built in msinfo32 command as shown in the image below:
Figure 3.
I should mention that there are still some gaps in firmware coverage not handled by UEFI/Secure Boot. This would include firmware such as device bios software (such as on a hard disk controller) that potentially could still be at risk. Most likely an attacker would need physical access to get at these, but hopefully these potential threats will also be addressed someday.
Device Guard and Code IntegrityOnce the system is booted, we also want to protect the kernel, drivers, and user mode code and scripts. Microsoft has been slowly advancing the movement towards all drivers being properly signed, and to get a secure system all your drivers must comply. But more than just being signed, Code Integrity enablement allows for a far more complete solution than we have had in the past, covering all kernel and user mode executables.
About 13 years ago I built a Windows XP lockdown system for a vendor which used a hash based whitelist/blacklist on Windows XP systems to prevent unrecognized executables from running by detecting and terminating them in a windows service running in the background. This was a really good idea, but one too far ahead of its time. Later, in Windows 7, Microsoft introduced AppLocker which was a much better implementation than mine since it was implemented inside the kernel of the OS and therefore better protected itself and was able to intercept at an earlier stage of the execution.
AppLocker allows both whitelisting and blacklisting of the user mode executable components (support for listing scripts was added later). Whitelisting allows a company to specify exactly which components may run and prevents all others not in the list. Signatures would be matched against a known list of good components. Anything that doesn’t match is simply prevented from loading into memory to be used. The signature checking may use any level of a digital signature, or if unsigned a file hash could be generated. While a file hash is not 100% perfect, the hash generation uses some of the same protections used within digital signatures. This make the effort to reverse engineer the hash an exhaustive trial and error experience; hard enough to discourage all but the most persistent from attempting it.
When released, AppLocker did not get much use by customers because most companies were not ready to start to worry about protecting their systems to this extent. Even if interested, many were so bogged down on getting all of their applications to work on Windows 7 that they didn’t have time to add to the workload with the additional effort of signature generation. And even then, it was likely that they were not ready to upgrade the Active Directory domains to the required functional level. Some did implement AppLocker, however, almost all ended up using blacklisting instead of whitelisting. While effect