Managing Application Definitions
Application Definitions are sets of files hashes, certificates or other rules that define what files are required for an Application to run. There are two types of Application Definitions.
Built-In Application Definitions
Built-In Applications are created by ThreatLocker. These definitions contain all of the files required to run an Application. For example, Slack (Built-In) contains all of the hashes that are required to run the Slack Desktop Application.
When using Built-In Definitions, ThreatLocker automatically updates the Definitions as vendors release new builds. In most cases, ThreatLocker's Built-In Application Definitions are made up of a list of hashes that are required to run an application. In some cases, where it is not possible to use the hash (e.g. if the hash is unique per computer), ThreatLocker will use the most restrictive ruleset possible to build a definition.
Organization Specific definitions can contain various rulesets. These definitions can be built automatically using Installation Mode or automatic profiling during Learning Mode, or manually by the administrator.
There are four parameters that can be used when creating Application Definitions. When adding rules, all parameters that have values must match. For example, if you have a rule that says the path is "c:\program files\microsoft office\*" and the certificate field contains "o=Microsoft Corporation", both of those parameters must match in order for the Application to match.
This is the exact path of the file. Examples could be "c:\program files\gimp 2\lib\python2.7\site-packages\setuptools\gui.exe" or "c:\program files\gimp 2\*". You can also use Regular Expressions to do more specific pattern matching. When using Regular Expressions, you should prefix the path with regex: (e.g. regex:c:\\programfiles\\.....*\\*).
If the file is signed by a vendor, you can add the vendor's certificate information into a ruleset. You can either add by the certificate subject, or a unique SHA of the certificate. When adding the certificate subject, ThreatLocker is going to do verification with a root CA to verify the cert is a trusted certificate. If you are adding self-signed certificates, you should only add the SHA. Adding the SHA is normally the preferred option unless the vendor is using a different private key each time they release a build.
Adding by hash is the preferred method. If the file changes in any way, the hash will change and no longer be trusted. The disadvantage of permitting by hash is if the vendor updates the file, it will no longer be permitted.
ThreatLocker uses a unique hashing mechanism that is extremely fast and effective. For small files, less than 1MB, you can add the MD5 hash, for files over 1MB ThreatLocker uses a process sampling various sections of the file to give you a very fast and secure hashing mechanism. When adding hashes, we recommend you copy the Hash from the Unified Audit or use Installation Mode to automatically add the hashes during an installation.
This is the process that calls the file. For example, you may add a rule that says if payroll.exe calls c:\payrollsoftware\*.dll that it is considered a match for the Application. Like the path rule, you can also use definitions.
In most circumstances, adding the hash is the best method. Using the "hash only" also provides the fastest method of processing on the endpoint.