When you start with your application allow listing project (WDAC), the idea is to switch from blocking known-bad software to only allowing known-good applications.
This is a bit of a paradigm shift in how we look at software in a company.
Traditionally we rely on Anti-virus/Anti-Malware tools to keep us safe from bad actors but those tools are largely geared to being reactive and try to identify known bad.
This changes when doing allow listing. We now start defining the applications that are needed to run in our company and only allow those applications to run. As a result, everything else will be blocked (thus including malware, ransomware, ...). We switch to only allowing known-good.
In a typical WDAC project, there are roughly 3 ways to make an application trusted:
Relying on the Managed Installer
Modifying the WDAC Policy
Using Security Catalogs
This blogpost is specifically geared towards Security Catalogs as they are often overlooked as a way to make applications trusted.
So what are security catalogs exactly?
Security catalogs have been around for ages, well at least decades. And we have all been using them as they are what is used to make drivers trusted on a Windows Operating system since Windows XP. If you download driver packs from any vendor's website, they will include a '.cat' file . Those '.cat' files are security catalogs.
A digitally-signed catalog file (.cat) can be used as a digital signature for an arbitrary collection of files. A catalog file contains a collection of cryptographic hashes, or thumbprints. Each thumbprint corresponds to a file that is included in the collection.
A default windows operation system will already have a ton of security catalogs on it's system, just go take a look at your "C:\Windows\System32\CatRoot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}" folder and see for yourself.
So, to summarize, a security catalog identifies a collection of files via a hash. Nothing more, nothing less. By trusting the certificate used to sign a security catalog, you specify that you trust the files that are listed in this catalog. The fact that a hash is used makes this method extremely tamper-resistant. Any modification that is made to a file will result in a different hash-value.
Security catalogs vs modifying your policy
The policy-equivalent of a security catalog would be a set of hash-rules. If you create a hash-rule for each file that makes up your application, or you have a security catalog that combines that same set of files, the end-result will be identical. Both scenario's will make your application trusted and both scenario's are extremely tamper-resistant.
Here are some advantages of using catalogs :
Repeatable Process
Inventory
Management
Repeatable Process
The way you create a security catalog is always the same. On a device that has a WDAC audit policy enabled, start PackageInspector.exe from a command prompt.
Copy over your installation binaries and install the application.
This can be as simple as running your setup.exe and following the wizard through the end.
Once the installation has finished, run the application to capture any additional files that might get downloaded at runtime.
Finally, stop packageinspector.exe with the parameter to create the catalog and you are done. These few steps should allow you to create a security catalog for nearly any application. (See video below for a quick demo)
Inventory
We suggest applying a naming convention to your security catalog, eg, start all custom catalogs with "C_<name of app_app version>.cat" . This enables you to deploy a simple script using your preferred management tool and query the "C:\Windows\System32\CatRoot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}" folder for any file that matches your naming convention. This is a quick and easy way to identify , on the end-users device itself, what applications should be trusted based on catalogs.
Doing the same for hash-rules in a WDAC policy is a lot more complicated from the client side. The policy files are binary files and as a result non-readable. This means that you have to come up with a different way of validating that the version specific policy you deployed is indeed the policy that is active on that client device. Policy filenames are equally renamed to the policyID, which again makes knowing what you have on a device somewhat more challenging. This introduces a requirement to keep a list somewhere with which PolicyID relates to which application and which version
Management
At some point you might want to remove trust for a specific application (or application version). In the security catalog scenario, this is as easy as removing the security catalog from the end-users system.
Removing a specific application or app version from your policy is a bit more work. As we identified in the previous section, there is no clear way of identifying what files belong to what application. This will probably result in your policy not being cleaned up.
The above examples should highlight that working with catalogs has some clear advantages over modifying a policy to make applications trusted.
Making security catalogs trusted
Now that we know what a security catalog is and why we want to use it, we have to talk about trusting a security catalog. It's not because you have a security catalog on your windows system, that by default every file defined in this catalog is automatically trusted. For this to work, we need to actually trust our catalog itself, or, technically more accurate trust the certificate used to digitally sign the catalog.
So, Step 1 is to trust the certificate that is used to sign your security catalog. When you download driver packs, those driver security catalogs are signed with a specific Microsoft certificate and windows trusts that certificate. As such, your drivers are trustworthy.
If however, we are leveraging security catalogs for defining trust in applications, those catalogs are not signed by anything. So we have so sign them ourselves with a certificate that is trusted in your WDAC policy.
Once you have a signed catalog with a trusted certificate, you can copy this catalog to "C:\Windows\System32\CatRoot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}" and you're done. From that moment on, any file defined in your catalog is trusted by WDAC, so your application is allowed to run. It's that easy :)
We have created a short video showing the process on how to create a security catalog. View it here.
It should be clear that we are big fans of security catalogs. They enable scenarios that are more challenging to address by using a policy.
It's one of the reasons we created the App Control project, to automate the creation of security catalogs for any application that is available in your management tool. Once your apps have been processed, you can logon to our portal and download any individual security catalog, or download them all.
You subsequently, sign them with your code-signing certificate and distribute the catalogs to your end-users workstations using your favorite method.
Comentarios