Today we will talk about rule types, their characteristics and some best practices.
When we open Additional Rules section, we will see two predefined rules:
They doesn’t look as usual path rules, instead they refer to registry keys. If you open Regedit and check these keys you will see that registry key values contains corresponding folders paths: C:\Windows and C:\Program Files. This means that SRP can read file paths from registry keys and values. In the default state, SRP allows to run anything that is stored in system folders and anything from other folders (say, from user profile) is prevented. In most cases it is enough. However, certain business applications are not installed in the default program folders (C:\Program Files). for example, they can be installed in the system drive root, different drive or in the network folder. As the result, you may have to create additional rules.
SRP allows you to create 4 kind of rules (they are listed in the prioritized order):
Certificate rules have the highest precedence (or priority) and path rules have the lowest priority.
General rule for rule creation is:
If a user has write access to a folder with a business application and you create path rule for the file (or files), it is easy to change original files with inappropriate files. I had few cases, when users temporarily replaced original files with games or 3rd party tools. If a user can change original file, you must not use path rules at all. Also user profile can be infected, and malware (which runs with current user rights and cannot infect system files) can infect original files of the application and SRP will allow infected file execution. If you use certificate or hash rules for the application files, then they won’t work after modification (replacement or infection). In fact, if allowed application suddenly stops launching, then this is an indicator of the file modification (probably, infection).
Certificate rules can be used when a file is digitally signed. SRP recognizes only Authenticode signatures and do not support catalog signing (which is usually used only by Windows OS). How to determine whether the file is digitally signed? If you take file properties, you will see Digital Signatures tab:
You can check signature details and verify it’s signature status. If your business application issuer signs application files, then you can add single certificate rule and all files signed by specified publisher will run without question. When you create certificate rule, you can select either signing certificate or just select signed file. SRP will automatically retrieve signing certificate from signed file.
when you create certificate rule with Unrestricted security level, the signing certificate is added to Trusted Publishers container in the local system certificate store and is propagated to all users. If you create certificate rule with Disallowed security level it is added to Untrusted Certificates container in the local system certificate store and is propagated to all users.
Also, your company may use their own applications and scripts which are signed by a company’s signing certificate. It is reasonable to add this certificate to SRP, so all signed scripts will be run normally. If someone attempts to change the script, it will be prevented from run, because digital signature become broken.
The downside of certificate rules is that you can’t control application versions, which are allowed. For example, you have an application XYZ version 1.0. After a time you received an update (version 2.0) and you want to prevent v1.0 usage and allow only v2.0. Unfortunately, certificate rules cannot handle this situation, and you have to use other rule type.
If your business application is not digitally signed and is stored in the folder where users have write access, then you should consider to use hash rules. Also, you may consider to use hash rules when you want to control which application versions are allowed and which are not. When you create hash rule, SRP just calculates a MD5 (and SHA256 in Windows Vista and newer systems) hash over a file. Obviously, if you change the file, the hash will become different and you will unable to run the file.
The downside of hash rules is that you may have to create a lot of hash rules if application uses a lot of executable files. Also, you have to recreate hash rules after application update.
This is less used rule type and it applies only to MSI installers. This rule type can be used in conjunction with software installation via GPO. For example, you are deploying applications via GPO and you specify network share where installers are located. By specifying required zone (Local Intranet) you can allow software installation via GPO.
it is not necessary when you define software deployment policy under Computer Configuration section. This is because such applications are installed under local system account which is not affected by SRP.
In fact, I never used Network Zone rules and if you can share your experience, you are welcome in comments.
This rule type is used only when application is installed in non-standard place and regular users do not have write access to the application folder. Well-written applications normally do not require write access to the application folder and application settings are stored in registry and/or in user profile. Bad-written applications require write access to the folder and you have to use either certificate or hash rules.
With path rules you can use:
you MUST NOT use system environment variables! This is because it is possible to override variable value for a single process. In the next posts I’ll show this trick.
In certain cases, applications are deployed in the network share and it is mapped to users with specific letter. In such cases you can’t use mapped drives, instead, you must specify UNC path, i.e. \\server\share.
due to unknown reason, UNC paths doesn’t work in Applocker (prior to Windows Server 2012 R2). This means that if your application is installed in network, you have to create either hash or publisher rules.
There are few words about registry paths. Consider the following, you have the registry key: HKLM\Software\CompanyName\CustomApps (where leaf element is registry value, not a key) that points to C:\CustomApps folder. In order to use this path you can create the following path rule:
SRP allows you to continue the path by appending folder or folders after the base path. In this case you should consider the following:
Therefore, if you want to allow only certain application under base path, the path in the rule should be the following: %HKLM\Software\CompanyName\CustomApps%App. To allow only specific executable, you should write this: %HKLM\Software\CompanyName\CustomApps%App/Bin/start.exe.
As you can see, there is no definite solution to create rules in SRP. Each case should be tested individually. Today we discovered properties of each SRP rule type and their pros and cons. In the next post I’ll talk about rule processing order and how rule conflicts are resolved.
Post your comment: