Windows 10's security overhaul offers a lot but beware its complexities and limitations
With the arrival of Windows 10 in late July, businesses must once again pose many of the same questions that presented themselves at the time of the launch of Windows 8 in 2012, Windows 7 in 2009 and, for those with long enough memories, Windows XP in 2001.
What resources does the new operating system require to run well? Is it compatible with current software, including in-house applications? Windows 10 offers a range of brand new security features but are these compatible with every network?
Faced with implementation issues and migration costs, it's likely that many if not all businesses will see Windows 10 as a medium or longer-term ambition, sticking with what they have, typically Windows 7, for the time being.
An extra issue for some businesses is simply timing, barely a year after the end of life (EOL) demise of Windows XP, which a shocking number of organizations still seem to cling to, presumably because they are willing to take the security and cost pain of that in return for being able to run old applications. For these organizations, Windows now forks into an intimidating four different strands, each with its own sometimes overlapping security architectures.
The first issue is to what extent the new security features in Windows 10 Enterprise improve what is on offer in Windows 7 and 8. A number of new elements have been added, including an overhauled password and biometrics architecture (Microsoft Hello and Passport), a new browser called Edge, Enterprise Data Protection (EDP) to manage and encrypt data, and most significant of all for network admins, Device Guard.
Device Guard, a allow listing layer for controlling which applications run on a PC and which don't, turns out to be complex. Using it depends on being able to create a virtual machine (VM) using Hyper-V in a protected zone for these applications to run in and that in turn requires a UEFI secure boot BIOS and a Trusted Platform Module (necessary in case of kernel-level attacks) of the sort that will only exist on recent PCs.
This also limits Device Guard allow listing to signed apps although that can include new Universal Windows Platform (UWP) apps as well as Classic (i.e. Win32) Windows applications that have been signed using dedicated tools provided by Microsoft.
Other limitations include having to configure it using the same specialised PowerShell interface used with other Microsoft virtualization systems, and the need to reboot for each configuration change. Powerful it will undoubtedly be, but for admins it's very much a case of two steps forward and about the same number of steps back again.
Perhaps the biggest limitation could be its inflexibility whereby applications will have to be approved and signed, or not, 'on' or 'off'. This essentially forces enterprises to choose which applications will be allow listed, or not. New or unusual applications that aren't on the list won't run and yet some of these might turn out to be important. Control over those will depend on the same hierarchical software approval processes that have hindered innovative application use in many organizations.
Certain types of app - Java is one example but application macros might be another - can't be controlled using Device Guard. Even a perfectly-deployed Device Guard won't do everything.
Organizations running a mixture of new Windows 10 systems with older versions of Windows or non-compatible hardware will find themselves running more than one application control and allow listing (or block listing regime), a nuisance in practical terms.
In its current form, then, Device Guard seems to deliver a lot of power into the hands of admins but not much fine control, precisely the thing many organizations badly need. The inflexibility of the architecture could be useful in very tightly-locked down environments such as embedded and kiosk applications. Mainstream IT? For now, probably not. Device Guard is very much the start of integrated allow listing. A lot of work lies ahead.
