Windows Defender Application Control (WDAC) is a technology that is built into Windows 10 that allows control of what applications execute on the device.
WDAC also allows you to control which drivers are allowed to run and is thus, a very powerful security measure that many should consider implementing. A typical WDAC blocking message is shown above.
Microsoft also has an older application white listing technology known as AppLocker. Here is the recommendation from Microsoft when choosing between the two technologies:
“Generally, it is recommended that customers, who are able to implement application control using WDAC rather than AppLocker, do so. WDAC is undergoing continual improvements, and will be getting added support from Microsoft management platforms. Although AppLocker will continue to receive security fixes, it will not undergo new feature improvements.”
You can deploy AppLocker and WDAC together if your wish, and thus the best practice recommendation from Microsoft is:
“As a best practice, you should enforce WDAC at the most restrictive level possible for your organization, and then you can use AppLocker to further fine-tune the restrictions.”
This is also a good side by side feature comparison here:
So, WDAC it is!
WDAC policies apply to the managed computer as a whole and affects all users of the device. WDAC rules can be defined based on:
– Attributes of the codesigning certificate(s) used to sign an app and its binaries
– Attributes of the app’s binaries that come from the signed metadata for the files, such as Original Filename and version, or the hash of the file
– The reputation of the app as determined by Microsoft’s
– Intelligent Security Graph
The identity of the process that initiated the installation of the app and its binaries (managed installer)
– The path from which the app or file is launched (beginning with Windows 10 version 1903)
– The process that launched the app or binary
WDAC policies are composed using XML. You can view a number of example policies on any Windows 10 device by navigating to:
and looking at the file I’ll be starting is process with:
and building from there.
Before we get too much further along I need to give you this warning. Application whitelisting is a lot of work to implement and maintain. The more variations (i.e. third party software) you have floating around the environment, the more challenging it is to implement. Also, remember that application whitelisting of ANY form is placing restrictions on user productivity. The things you do with tools like WDAC have the potential to severely restrict users ability to do their job. This can result in the ‘local villages’ pitching up to your door with burning effigies, sharp weapons, menacing looks and foul language if you are not careful. I’ll give you my best practices for reducing the pain and suffering but be prepared for this to be a journey rather than a set and forget update.
Before anything else, I would suggest that you should be conducting a software audit in your environment. You should know what applications are being run by users, however, I’ll guarantee that you won’t know them all. This should not preclude you from at least making an attempt to catalogue what you have. Doing so will save you a lot of pain in the long run.
Next, you’ll create start creating a default WDAC policy in audit mode to see what is actually happening and what issues may be faced. This policy will then be adjusted along the way to accommodate any required inclusions (typically third party software). Once that stage has been completed, the policy will then be flipped from audit to enforcement mode to actually start preventing unknown applications from running.
That’s the plan for these upcoming series of WDAC articles and I hope you’ll follow along and with the knowledge I share look to implement WDAC in your own environment.