Creating Custom Rules

If you find yourself permitting the same software twice, then you can go in and create custom rules on your own. When creating a custom rule, it is important to create the rule as restrictively as possible without making it burdensome.  

The hash is a one-way encoding of the file, calculated by ThreatLocker using its own hashing algorithm. It is the most secure way of permitting a file. By default, ThreatLocker will always use the hash when it creates Policies and Application Definitions during an automatic learning session.    

When you are creating a custom policy, generally you are dealing with a file that is changing hash, therefore the hash should not be used as one of the parameters. ThreatLocker recommends combining the following parameters when creating a custom rule:

• Certificate - A digital certificate is issued by a certificate authority (CA). It serves as a way of saying that the signing company stands behind the file. This is the certificate of the file, not the process using the file.

• Path - The path is where the file is located. Multiple wildcards can be used in the path. For example in c:\users\*\appdata\myapp\* the first wildcard replaces the username and the second wildcard says that anything in c:\users\*\appdata\myapp folder is permitted. You can also use Regular Expressions here if you'd like to be more complex.

• Process - The process is what process or Application is trying to use the file. For example, the file in the photo above was being called by the process pictured below, C:\program files\oracle\virtualbox\virtualboxvm.exe. If needed, the process path can also contain wildcards. When creating a custom rule for a file that has no process, instead of leaving it blank, use "[]" to specify that this value must remain empty. 

• Created By - The created by parameter is used by temporary files that were just created. If there is a process that creates a new file, using this parameter will help ensure that the file wasn't created by something other than what you want to permit. Created by only works on ThreatLocker Version 6.2 and above. Created by works great for update files that are temporarily created just to update an application. The created by process can also contain wildcards if needed.

In the example below, you’ll see that the ‘.ps1’ file was called by ‘powershell.exe’ and created by ‘agentpackagesystemtools.exe’  

1. Permitting by hash is always the most secure method.  
2. After that, permitting by certificate and at least one other parameter is the next most secure method. You can permit by certificate and path, certificate and process, or certificate and created by. If you can use certificate and two other parameters, that would be even more secure. ThreatLocker also recommends using wildcards to account for any changing variables (e.g. usernames or version numbers). 
3. After combining certificate and one other parameter, the next best way is to permit by certificate alone, but only from a very trusted vendor that is selective in the files they sign. The best practice is to only allow by certificate if it is a company that you really trust. Even ransomware can be signed these days. Consider if permitting by certificate alone would be casting too wide a net for a secure environment.  
4. If you are dealing with a file that is not signed, you can choose to combine the other parameters: path, process, or created by process. If you can combine all 3, that is the most secure way here. But always use at least 2. You should always avoid permitting by a single parameter.  

For more information, please see our ThreatLocker University Course, Permitting Software.

If you are having trouble figuring out the most secure way to permit a file, contact the Cyber Heroes. Within a minute you will have a live response. They can assist you in making a secure rule, and they will walk you through it step by step.