If you are not familiar with Windows Defender Application Control (WDAC), let me fill you in. Not to be confused with Windows Defender Application Guard, a containerization solution for Microsoft Edge that uses Hyper-V to isolate browser sessions, WDAC is one part of Windows Device Guard. Just to add to the confusion, Microsoft uses Windows Device Guard to refer to the use of WDAC and hypervisor-protected code integrity (HVCI) together.
For more information on Windows Defender Application Guard, see Revisiting Application Guard in the Windows 10 April 2018 Update on Petri.
Windows Device Guard was introduced in Windows 10 as a new, robust application control solution designed to be more flexible than AppLocker. But Microsoft promoted Device Guard along with HVCI and many IT administrators wrongly assumed that the application control part of Device Guard couldn’t be used without HVCI, which has some hardware requirements that many older devices don’t meet.
Last year, Microsoft announced that the two technologies that makeup Device Guard had been separated into Windows Defender Application Control, which deals with application whitelisting, and Windows Defender Exploit Guard would handle protecting WDAC using HVCI if required. By separating Device Guard into two distinct technologies, Microsoft hopes that IT administrators will understand that HVCI isn’t required to use WDAC.
Application control first appeared in Windows XP as Software Restriction Policies (SRP), but it was not widely adopted because it was difficult to implement. AppLocker in Windows 7 was designed to solve that problem. But AppLocker isn’t without its shortcomings. Not least of which is that its implementation isn’t very robust. For example, users with administrative privileges can disable AppLocker.
Windows Defender Application Control uses Code Integrity (CI) policies that are implemented by the Windows kernel right from early in the boot sequence before most other OS code starts running. CI policies also extend to kernel mode code, such as drivers and Windows components, unlike AppLocker that can only be used to whitelist user mode code. Administrators can be prevented from tampering with WDAC by digitally signing CI policies. To change a policy, a user would need administrator privilege and access to the organization’s digital signing process.
Additionally, the entire process can be further protected using virtualization-based security (VBS) if your devices meet the necessary hardware requirements. This is enabled using Windows Defender Exploit Guard. Sometimes this is also referred to in Microsoft’s documentation as HVCI. To further muddy the waters, the feature is labeled Memory integrity under Device Security in the Windows Defender Security Center.
If you want to enable HVCI using Group Policy or MDM, you need to look for the Turn on Virtualization Based Security setting under Computer Configuration > Administrative Templates > System > Device Guard. For more information on enabling HVCI, see Microsoft’s website here. You can find out if your devices support HVCI by downloading the Device Guard and Credential Guard Readiness Tool from Microsoft.
Windows Defender Application Control is a robust application whitelisting technology that when implemented can significantly reduce the risk of being infected by Advanced Persistent Threats (APTs) and zero-day malware. But as it stands, the lack of a centralized GUI management tool is likely to limit uptake. The PowerShell configuration tools also involve a steep learning curve and require a substantial investment in testing. Some drivers might not be compatible with HVCI. Microsoft has more information on this issue here. Organizations interested in deploying WDAC might look to enabling it first on servers where the software portfolio is relatively static.