Making WDACConfig easier for beginners

[agpt8]

Hey there!

WDACConfig is a powerful module and caters to large number of use cases for IT admins. Though as a beginner, I find it a little confusing and intimidating to use. Don't get me wrong! The documentation you have provided is extensive and any experienced person who works with Intune or on server side or manages IT infra at their workplace would find it much easier to use.

Rationale behind this post:

When I did a fresh install of Win 11 Beta a few months ago, Smart App Control was running in evaluation. I never changed it, even when I deployed the Hardening Module on my PC. Smart app control never caused any issue for me and it turned itself off sometime in these months. I think it goes with this talk when David Weston mentions that it will turn off automatically if it detects that the user runs certain types of programs. (https://youtu.be/8T6ClX-y2AE?si=Ohdl2q3KKCfnKZiz&t=1999)

I am planning a reinstall of the OS but this time with Smart App Control on. Since it can block certain types of scripts, apps, dlls, executables etc, I want to know how can I use WDACConfig to put them in allowlist and continue working.

To give you some details on my work, I am a Data Scientist by profession. I work with a lot of python scripts, some of which are taken from the internet, some that I wrote, code from places like textbooks, courses etc. Relating to this are a lot of tools like Github Desktop Beta, Visual Studio Code Insiders (and stable), JetBrains IDEs, Azul Zulu JDK, git, a lot of command line tools and utilities, some related and some unrelated to my job, all downloaded majorly from winget or directly from the website if not available on winget. I can provide you a list if you want privately.

Some queries about the documentation

The documentation is extensive but I have some queries.

Going into the intro post , the 5th point talks about Smart App Control: "It uses a special kind of WDAC policy that provides more protection than a lightly managed workstation but less protection than a fully managed workstation."

Since the machine in question is my personal machine, I guess the next stop would be to the lightly managed workstations. Here, it talks about creating a base policy and supplemental policy for apps(referring to regular Win32 programs as well as Microsoft Store installed apps; Basically, any software that you can run.).

Queries here

• Now I am assuming that these supplemental policies are the ones that can be used to put things in the allowlist for any apps/utilities that I want to run on my machine?
• If yes, are these to be used when Smart App Control (SAC) blocks something and I want to allow it to run? Since SAC works at higher level than lightly managed workstations but lower than fully managed ones...
• If yes to above two points, do I have to create a baseline policy first? Doesnt SAC already creates it?
• Where do I keep the .cer and other policy files when creating the base and supplemental policies? I mean what are the best practices here to store these files? Can I move them if I want?
• How do I back these up safely and migrate it on a new machine and redeploy them later easily?
• When creating supplemental policies, which rule level I should work with? This section throws some light on it but there are a lot of rule levels like Leaf Certificates, Pcs Certificates...? I am confused.
• Signed vs unsigned policy? The docs say signed is the most secure and without the certificates, I wouldnt be able to change the policy. Creating a signed policy is given here, but this doc is catered to the server environment. But we also create a signed base policy in the lightly managed workstation doc?!?

These are some of my current queries about WDACConfig. These may have been answered in the docs already but as I said, the docs contain a lot of technical jargon that a beginner (like me) might not understand. I believe the docs can be simplified a bit.

On a side note, this section can be updated. I believe, the limit has now been removed or I guess updated from 32.

Thank you for reading. Let me know if any input is required from my side.

[HotCakeX]

This is great post! I will provide answers and update the articles as soon as possible.
Currently my priority is completing this PR and its objectives #221
Should be done in a day or two.

[HotCakeX]

Time to unpack this and sorry for the late reply :)

You're right about Smart App Control, it turns itself off when it detects that turning itself on would block lots of the files you use frequently. The talk you mentioned is a great source of info about it!

However, we cannot change the Smart App Control's workflow other than turning it off/on. We cannot allow list a file that it blocks. The reason for this is that there are 2 types of WDAC policies, Signed and Unsigned.

Signed policies are tamper proof, they cannot be modified without having access to the certificate (certificate's private keys to be precise). Smart App Control gets deployed as a Signed policy on the system, Microsoft is the only entity that owns the certificate for it. This means that we cannot modify the policy to allow list a file.

So to put it simply, when Smart App Control is turned on, it defines a security baseline that we can only tighten from that point on. We cannot loosen it. The way we tighten it is by adding more WDAC policies to the system (Signed or Unsigned).

You will probably find out that some of the files you use or download get blocked by Smart App Control, most likely because they were unsigned. Python itself is not an enlightened script host so WDAC can't directly control things it runs. Installing Python would mean you automatically trust all of the scripts it runs, but some Python packages contain executables that are not signed and would be blocked by Smart App Control.

About the questions regarding lightly managed WDAC policy

1. Yes, supplemental policies for expanding the allowed list of files. WDAC policies are allow list in nature, meaning if a file or certificate is not mentioned in the policy, it is automatically blocked. We rarely need to define Deny rules in a WDAC policy because of this fact.

2. As mentioned above, we cannot allow list a file that is blocked by Smart App Control.

3. Same as 2. Smart App Control creates base and supplemental policies on the system automatically and manages them based on the cloud intelligence. Both Smart App Control and Lightly managed WDAC policy scenario use ISG for automated safe file authorization and allow listing but Smart App Control uses some policy rule options that are only available to it and it has a big difference: Let's say you want to install a program, when using the ISG rule normally in a WDAC policy like in the lightly managed scenario, if the file's installer is deemed safe by the ISG, it will allow the installer and all of the subsequent files it installs. Smart App Control, on the other hand, will allow the installer if it's safe but will block the subsequent files it installs if they are not safe. It has the ability to check and block individual files in a chain of installations or when the app is running. It has special notification toasts for this purpose, saying that a file was blocked by Smart App Control that belongs to an App but the app might still continue to work properly, and most of the time it does, unless the blocked file is crucial for the app to work. So that explains why Smart App Control is more secure than a lightly managed WDAC policy.

4. There are 2 main types of certificate extensions when it comes to signing WDAC policies. .cer and .pfx files. You can store the former anywhere you like, but the latter should be stored in a secure location because it contains the private key of the certificate. The certificate is used to sign the WDAC policy, and the private key is used to verify the signature. PFX files can be password protected, stored in VBS on the system. The ideal way to store them would be to use a hardware security module (HSM), but they are expensive. HSMs are what people use when they buy an EV (Extended Validation) code signing certificate from a globally trusted certificate authority, they mandate the use of an HSM to store the private key. However, you can store the private key relatively safely following these steps. Keeping the private key on another offline and secure computer would also be a good idea, you will sign the policies on it and then transfer them to the target system. The WDACConfig module supports this scenario.

5. To backup up the PFX files, you need to export it from the certificate store of your computer where it's saved and set a SHA-2 256 long password for it. To import it on a system, please follow these steps.

6. Which level to work with depends on how specific you want to define a file to be allowed. You can use wildcard file path and it will allow all of the files in a folder to run, which is insecure. You can use Hash level which is the most secure but also not practical to maintain. So what I suggest is WHQLFilePublisher for the main level and FilePublisher, Hash for the Fallback levels. The combination of these levels ensure that if a file is a driver, it will be properly and securely defined in the policy without requiring policy change later on when it is updated. This will also allow any signed file that is not a driver. Any unsigned file is allowed by its hash values. This is a very maintainable and secure policy.

7. This doc is only for those that want to use Windows Server's Active Directory Certification Service to create a code signing certificate for WDAC signing, it is not required to use with the WDACConfig module. The secure and automated way to make certificates for WDAC signing is through this cmdlet. Signed policies can be used on any device and not just servers.

I'll definitely overhaul all of the documents to make them clearer and update them to remove the 32 limit of the WDAC policies!

I hope this helps, let me know if you have any more questions, i'll be happy to answer ^^

[agpt8]

Thank you so much! This clears up a lot of things for me!
I guess I have to leave SAC in evaluation mode and let it decide if my workstation is a good candidate or not.

I dont have any more queries, so I'll close this out for now. I will let you know if anything comes up.

[testmmo]

I agree with this sentiment. I attempted another go with WDAC module and couldn't keep in enabled as too many things stop working and don't want sit in powershell making policies for different programs and updates. Hoepfully microsoft makes some way where smart app can whitelist even if its a few hoops or a gui for apps signature if ephemeral. i.e. i already uploaded an exe to virustotal and trust it well from the source I should be able to approve it knowing there still is potential for compromise.

I wanted to use the lightly managed WDAC but tools like WSL are blocked by it. I hope one day ms makes it usable without needing an entire module to figure out the complexities. The lockdown is very useful just the process to override it is too cumbersome. The download defense policy is great though.

I think the biggest opportunity to get more adoption is if there was a gui for the WDAC that allowed people to select their apps to work with the signed policy. A guided process to do it where generates keys encrypts with ms hello etc.

[HotCakeX]

I understand that and a proper GUI is planned for the WDACConfig module, it will have everything you're asking for and then some! There is however WDAC Wizard for now: https://webapp-wdac-wizard.azurewebsites.net