With high-profile security breaches making headlines all too frequently these days, the security features available in Windows 10 are perhaps one of the most compelling reasons for organizations to adopt the latest Microsoft OS. In fact, our recent Windows 10 survey – which you may have participated in – revealed that new security features shared top place with end-of-Windows 7 support as the most important reason for the adoption of Windows 10.
So, what are these features, what do they do to improve security and most importantly, how do you access them?
Secure Boot
Secure Boot, which was actually introduced in Windows 8, is the first line of defense in what is referred to as a chain of trust established with other security features. It prevents malware loading during the OS boot process. This specific type of malware is referred to as a bootkit and is particularly tricky as it is loaded before the operating system, which means it can modify behaviour, including obscuring itself, when the OS loads.
Bootkits have been compromising the traditional Master Boot Record for decades. As with the Nemesis example linked above, simply switching to UEFI with a GUID Partition Table (GPT) disk configuration may thwart some of these. However, malware can be developed to compromise the modern UEFI boot loaders. The extensible nature of UEFI means that bootkits can be developed in C, actually making it easier for malicious developers who previously had to use the low-level assembly language to wreak their havoc.
Secure Boot, which is enabled in the UEFI firmware and supported by the OS, will only load boot files if they are signed by a trusted source. The list of trusted source signatures is programmed into the Secure Boot database in the firmware by the hardware manufacturer and can only be updated by the manufacturer using their digital signing key (manufacturers are required to include Microsoft’s signing key so Microsoft can update the database to support new operating systems and drivers). With Secure Boot enabled, any compromised or unauthorized boot files will not be loaded and the Operating System will not boot – at which point various attempts at recovery are made (depending on exactly which part of the boot process is unauthorized) but the malware is rendered ineffective.
Device Guard
So, Secure Boot ensures the firmware and boot loader is trusted and we can now load the OS. Device Guard, which is new for Windows 10, forms the next link in the chain. It is a set of features that includes Code Integrity for Kernel Mode and User Mode execution and virtualization-based security to protect its own configuration. Device Guard only allows trusted code to execute as the OS kernel, device drivers, services and finally user applications are loaded.
This is a fundamental change to the way that organizations have typically tackled malware. The traditional approach with anti-malware software is to trust anything unless it is known to be bad (typically identified by the anti-malware signatures that need to be updated often daily to identify and protect against new threats). Device Guard starts with the ‘trust nothing’ approach – using configurable code integrity it prevents any code from executing unless it has been specifically identified as trusted. It is conceptually similar to the idea of whitelisting, but applies to the core of the operating system right through to the applications.
So if the starting point is ‘trust nothing’, how do you ever run anything? Code signing is the key here. Most vendors of legitimate, enterprise software sign their code these days. You use Device Guard policies (typically managed through Active Directory Group Policy or System Center Configuration Manager) to define the signatures that are trusted in your organization, then any software applications that are signed by that vendor signature can be executed. If you want to get more granular, you can trust specific applications based on hash-values of the individual application files. If you need to trust code that is not signed (perhaps in-house developed applications), as an alternative to rebuilding these applications with trusted signatures, you can create catalog files that contain file hashes for the application binaries. The catalog file is then signed using a trusted signing certificate that is either already trusted through the Device Guard policy, or is subsequently added to the policy.
But with all this being so configurable, surely malware can simply add its own signature to the Device Guard policy on a computer, enabling it to execute? This is where the Virtualization-based security comes in. Configurable Code Integrity is ‘locked’ once the policy is initially loaded (from a trusted source such as Active Directory) and isolated from the operating system through virtualization, so should any malware manage to execute on the machine it will not have access to modify the policy at all.
Credential Guard
Modern malware is often designed to get information out of your environment while remaining undetected, rather than to become obvious through destruction or ‘ransom’ of your data – it’s this kind of security breach that so often makes the headlines when customer or citizen data gets into the wrong hands. In order to achieve this, the malware needs to be installed (it’s remarkably easy to trick a user into clicking a link in what looks like a trustworthy email). It then needs to get access to other resources (e.g. databases or systems that run the databases) on the network. If the user that was duped into installing the malware has admin rights on their PC, the malware now also has admin rights.
In previous versions of Windows, malware that has admin rights on a single PC could then get access to information (in the form of hashed credentials) of other network users (including service accounts) that were logged on to that machine at the time. These hashed credentials could then be used to gain access to other systems on the network spreading the malware until the target data source is found, the data extracted and sent to the attacker. This technique of using hashed credentials to gain access to secured resources is known as pass-the-hash and is explained quite well in this Microsoft Security Intelligence Report.
Restricting admin rights of your users is the first and probably most effective line of defense in this particular scenario. If malware does get installed with admin rights, Device Guard will prevent it from executing unless it has somehow been signed with a signature you trust. In the unlikely event of that ever happening – or for devices that are not running Device Guard – Windows 10 can prevent access to these hashed credentials through Credential Guard.
Credential Guard uses virtualization-based security to isolate and protect the hashed credentials that traditionally were stored in the system memory, rendering them inaccessible to anything other than the Windows Local Security Authority (LSA).
Realizing the potential
These security features in Windows 10 have the potential to make your environment the most secure it has ever been. But these features have specific requirements that you need to understand if you are to realize that potential. To start with, Device Guard and Credential Guard are only available with Windows 10 Enterprise Edition – specifically, the 64-bit version is required to run Hyper-V required for the virtualization-based security components. Secure Boot, however, is available on all editions of Windows 10.
More importantly, the approach you choose for migrating your existing devices to Windows 10 now could prevent you from realizing this potential in the future. In many cases, almost certainly if you are running Windows 7 currently, an in-place upgrade to Windows 10 will prevent you taking advantage of these features on those upgraded devices.
This is because Secure Boot requires Unified Extensible Firmware Interface (UEFI) with a GUID Partition Table (GPT) disk configuration. While devices have been manufactured with UEFI for several years, unless they were supplied with Windows 8/8.1 installed it is very likely that they will be running in a BIOS emulation mode with a Master Boot Record (MBR) disk configuration. Enabling Secure Boot would therefore require disabling BIOS emulation in the firmware and re-partitioning and formatting the disk – a wipe-and-load approach to Windows 10 migration.
We will be continuing to explore these features in more detail through a series of blogs over the next few weeks, with the aim of showing you how to approach your Windows 10 migration to ensure you get the most out of its security features.
