Windows security has always borne the brunt of security attacks because of the large number of Windows platforms—hence a large attack surface—and because the attack surface within Windows was essentially the entire system. This has been changing over time, however, with significant changes to 64-bit Windows 10 making it a desirable system for users, network administrators, and embedded developers alike.
At this point, Windows 10 has an incredible number of security services that address pre- and post-breach areas (Fig. 1). It starts with device protection and secure boot through conditional access for breach detection. Some features target the user interface, such as Windows Hello login support that provides consistent support for fingerprint and facial recognition. These will be of interest to some embedded developers with applications that deal with authenticated users, while the remaining features will be of interest to all developers.
The reason for the plethora of security services is to reduce the attack surface while delivering a more manageable security interface. It starts with secure boot support that is essentially standard with most UEFI bootable systems these days. Windows has worked with the Trusted Platform Module (TPM) in the past, but this feature was less common on motherboards, whereas the UEFI support is now ubiquitous.
Secure boot checks the operating system boot kernel before it is used. This prevents booting a system that has been compromised, possibly by physically installing new boot code, although it is more common to have this occur due to a virus that has succeeded in breaching the system.
A new component of Windows 10 is the Virtual Secure Mode (VSM) virtualization-based security (VBS) that employs Microsoft’s Hyper-V hypervisor (Fig. 2). Hypervisors have been used to isolate services, but this is relatively new to Windows. It specifically targets applications like Edge, the new web browser, as well as services that browser runs like Adobe Flash.
The reason why VSM makes such a difference is that it changes the runtime environment for applications like Edge. They used to have unrestricted use of the system, allowing modification of system files. This is no longer the case. It is the same type of containerize approach used with Android and other operating systems, which limits the system functionality available to an application to as small a subset as possible, thereby reducing the attack surface and limiting the areas where protection needs to be applied. This also reduces the overhead related to protection.
VBS is used to run a number of services called trustlets. These include the Local Security Authority (LSA); Code Integrity control functions in the form of Kernel Mode Code Integrity (KMCI); and the Hypervisor Code Integrity (HVCI) that provides the hypervisor code integrity control.
Embedded developers will appreciate Device Guard that includes VBS and secure boot. There is also an application whitelisting service that prevents malicious code from running on Windows, as opposed to letting any application run on a system. The Configurable Code Integrity (CCI) trust model requires that code is signed and trusted before it can run. This approach had been used with device drivers and moved to application control. Credential Guard runs an isolated LSA under VSM to manage user and storage credentials on the system.
Device encryption support has been available for a while, providing at-rest protection. BitLocker technology encrypts data preventing access if a storage device is removed and accessed using another system.
Overall, Windows 10 security support has taken a major leap forward over previous versions of Windows, making it an interesting target for embedded developers. It starts with a base of Windows 10 IoT Core.
