This blog post will be the first (of many) in a series relating to Microsoft WDAC and how to understand, implement and manage it.
In the current cyber security landscape where ransomware and malware attacks are becoming more regular it is becoming increasingly challenging to protect devices and data. Anti-virus is critical in protecting endpoints, however new malicious threats are being created on a daily basis and an anti-virus solution may not fully protect against them especially in the in the immediate period after they are used in cyber-attacks. A defense-in-depth strategy is required where multiple layers of protection are used and this is where an application control solution working alongside anti-virus can be very effective at preventing ransomware and malware attacks.
What is application control?
Application control is a security solution that controls what software is allowed to be executed on an endpoint, and preventing software that isn’t authorised – which critically could be a piece of new malware that isn’t yet prevented by traditional anti-virus. Application control solutions could also be used to prevent users from installing or using unapproved software that you don’t want to run on your endpoints. This could be applications that aren’t business related, or applications that people want to use could present a data security risk.
Application control is a very effective solution which is why it has been identified as the first mitigation strategy in the Australian Signals Directorate (ASD) Essential 8 Maturity Model (that topic could be an entire blog series all to itself). The Essential 8 provides actionable guidance for organisations of all sizes to put in place preventative strategies and mitigations to prevent cyber-attacks outright or lessen their impact. The implementation of the maturity model, particularly in government is becoming increasingly common.
What is WDAC?
Windows Defender Application Control (WDAC) is Microsoft’s application control solution that is part of the Defender suite and is built into Windows 10 & 11 as well as Windows Server version 2016, 2019 & 2022.
There is no additional licensing required as it is included with Windows 10 & 11 (Pro, Enterprise and Education editions) as well as since Windows Server 2016. Be aware that not all WDAC features are available on all versions of Windows (especially with Windows Server) but this is well documented in Microsoft’s WDAC feature availability article.
How does WDAC work?
WDAC is implemented by building and deploying one or more WDAC policies to your endpoints. WDAC policies contain rules that indicate what protections should be enforced, such as requiring WHQL compliant drivers, in addition to defining what software is allowed or should be blocked.
There are several deployment options including using Intune or deploying via custom scripts.
WDAC policy rules
WDAC policies have numerous configuration options, protection settings and file rules that can be configured. Covering it all would go well beyond the scope of an intro blog post like this (and I intend to have separate articles on many of the different options available).
The list below is a high-level summary of the methods for allowing (or blocking) software, and keep in mind not all rule types are supported in all versions of Windows (refer to Microsoft’s WDAC feature availability article for full details).
- Managed installer – allows trusted software distribution systems, such as Intune or SCCM, to install software and WDAC will allow it to run.
- Intelligent Security Graph (ISG) – leverages Microsoft vast machine learning and security intelligence to classify applications as having a known good, bad or no reputation. WDAC can leverage this cloud solution for software that isn’t explicitly defined in your WDAC policy, and based on the Microsoft intelligence allow it to be executed or blocked. Government departments be aware that if you’re going for Essential 8 compliance, ISG isn’t considered an appropriate whitelisting method and generally can’t be used. Also be aware that the ISG may allow non-malicious software to run in your environment that you would want to prevent for valid reasons – for example you may not users to be able to use software such as Dropbox or Spotify.
- Publisher rules – file publisher rules leverage the certificates on digitally signed software to allow them to execute, for example this could be used to trust software from Google, Adobe and many other publishers that digitally sign their software.
- File paths – software installed in specific file paths, such as C:\Program Files, can be considered trusted (use this rule type with care).
- File hashes – if other rules aren’t suitable you can allow or block software by using the file hashes of its binaries. The downside of this approach is it can have a substantial ongoing overhead particularly for applications that are updated regularly.
- File properties – trusts software based on the metadata on the binaries such as the name of the application or its publisher. This method should generally be avoided as unlike other methods its trivial to spoof and isn’t considered suitable by the Essential 8 maturity model.
Deploy using audit mode first
WDAC policies should always be deployed initially in audit mode where software running on the device ins monitored and logs are generated indicating what software would be impacted by your current policy if it were implemented in enforcement mode. This logging can be used to continually refine your policy, and is available either directly in the device Windows event logs, or if configured by using advanced hunting queries in Defender 365 or Microsoft Sentinel.
Organisational impact considerations
Application control solutions like WDAC can significantly improve an organisations security posture however great care must be taken when embarking on the implementation journey. If an implementation is rushed or policies that are misconfigured or incomplete are deployed, it could be very disruptive to users in preventing them from being able to complete business critical tasks and result in your support teams being overwhelmed with support calls.
The potential impacts on the wider organisation are numerous, however these are some of the key considerations:
- Are support teams prepared and upskilled to support the potential impacts of an application control solution and identify whether application issues are related to WDAC or not.
- What will the impacts be on your software packaging team? Additional testing will likely be required when rolling out new or updated software to ensure they are not impacted by any WDAC policies.
- If administrators regularly install software manually for end users, these processes may be impacted and may require an alternative approach as WDAC policies are enforced for all users on a device – administrators aren’t exempt.
- Are there processes in place to “vet” software and determine if it should be allowed within your organisation, and how will requests be handled when a user’s favourite application doesn’t work anymore.
- Testing your rollout and rollback processes are critical! If there is impact from a deployment and an immediate rollback is required, knowing what the rollback steps are and that they work is critical to minimising the impact.
What’s next?
Jump in to create and deploy your first audit policy (on a test device of course), which will be the topic of the next post in this series using the Microsoft WDAC Wizard.
WDAC Series posts
Below are the links to the posts in this series.