Before you start
Objectives: Learn which methods we can use to restrict application usage on Windows installations, and what are their specifics.
Prerequisites: no prerequisites.
Key terms: rule, rules, windows, file, files, applocker, applications, default, software, certificate, srp
How to Restrict Software
In newer versions of Windows, like in Windows 7, we have two different technologies to limit applications that users can run. The first method to restrict software is by using the AppLocker. In the second method we can simply use Software Restriction Policies (SRP). SRP was introduced with Windows XP. In both ways we configure restriction rules by using Group Policy. We can restrict executables, scripts, Windows installers, and even Dynamic-Link Library (DLL) files.
Technically, AppLocker policies are similar to Software Restriction Policies, but have many advantages such as the ability to be applied to a specific user, or even groups of users. We also have the capability to apply settings to all future versions of the software. Software Restriction Policies or SRP can be used to restrict or allow certain applications to run based or rules, such as path or hash rules. When configuring software restriction in Windows environment, keep in mind that AppLocker rules will take precedence over SRP rules on clients running Windows 7 and up. This is common in environments with different versions of Windows operating system.
AppLocker Policies
AppLocker is a new method of restricting software that was introduced with Windows 7. AppLocker is often reffered to as Application Control Policies as well. AppLocker is not available in all editions of Windows. For example, when it comes to Windows 7, AppLocker is only available in Enterprise and Ultimate editions. As with SRP, we can use AppLocker to limit access to executables, scripts, Windows installers, and even DLL files. In order for AppLocker to function the “Application Identity” service must be active on our machine. By default, this service has to be manually started. This is great for testing purposes, because we can manually start the service and check if we have problems with the AppLocker rules that we have applied. If we have problems, we can simply restart our machine, double check the applied rules, and then start the mentioned service again. Once the rules are working properly we can change the startup of the mentioned service to “automatic”.
With AppLocker we have a default set of rules which are created automatically. Default rules are very important because once the AppLocker is enabled, only applications that have an allow rule will execute. By default, default rules will allow access to default Windows program files and directories. When we create new rules, they are applied to everyone group by default, but we can change this to specific user or group.
With AppLocker we have four rule types. The first type of rule is calledExecutable rule, which is applied to files with “.exe” and “.com” extensions. The default rules for the executable rule type allow everyone to execute all applications in the “Program files” and in the “Windows” folder. Also, administrators can execute applications anywhere on the computer. We should always enable those default rules so that Windows can execute important system files from the “Windows” and the “Program files” directories.
The second type of rule is called Windows Installer rule, which can be applied to MSI and MSP file extensions. With this type of rule we can allow or deny the installation of software on the computer. By default, this rule will allow everyone to install signed Windows installer files, and all MSI files in the[system drive]WindowsInstaller directory. Also, administrators can run any MSI or MSP file. Installation of software trough Group Policy is also enabled. Note that even if the Windows installer rule allows the installation, users still need proper administrative and NTFS permissions to perform those actions, as well.
The third type of rules are Script rules. With script rules we can control files with “.ps1”, “.bat”, “.CMD”, “.vbs”, and “.js” file extensions. By default, this rule will allow the execution of all scripts located in the “Program files”, and in “Windows” folder. Also, administrators can execute scripts in any location.
The last type of rules are DLL rules. With DLL rules we can control libraries with “.dll” and “.ocx” extensions. The DLL rule is not enabled by default. With this type of rule, we have to manually create a rule for each DLL that is used on our machine. For administrators this means a ton of work because applications can have many DLL files. On the other hand, this provides maximum security.
When we create some new rule, we also have to specify a condition for the rule. With AppLocker rules, we can have three conditions. Those conditions are publisher, path, and file hash. The publisher condition is based on certificates which are used to sign applications by publishers. We don’t have to actually obtain the certificate from the publisher since it can be extracted from the digital signature on the application file itself. Files which don’t have digital signature can’t be used with the publisher condition. With publisher condition we can also specify exactly what version of the application is allowed to execute.
The path condition is used to specify a folders, files or wild cards of files to implement restriction policy. If we specify a folder, restrictions apply to all programs within that folder. Path rules are easy to manage, but are less secure. The user can simply move a malicious application to another location or he can simply rename the program to some name which is allowed to run. To prevent users from copying applications to unwanted locations we have to make sure that we have proper NTFS permissions implemented in our environment.
The last condition is the hash condition, which enables us to identify a file by creating a digital fingerprint. Digital fingerprint is a file hash and it is based on the content of the file, not the file name. The problem with hash condition is that we have to re-create file hashes if the file gets updated.
We can use exceptions to allow specific applications to run, regardless of the rule set. We can also configure AppLocker in audit mode (soft-enforcement). In the audit mode, the restrictions are configured but they are only monitored, not actually applied. This allows us to see how AppLocker works before we actually enable it. We can see which applications will be restricted without actually restricting them. We can see those events in the AppLocker event log. Log will contain information about the rule, SID of the user or group, files or paths that were blocked or allowed, and the rule type or condition used.
Software Restriction Policies (SRP)
By using SRP we can utilize the same restriction policies like with AppLocker, but remember that with SRP we can also apply SRP to older versions of Windows like Windows XP, Windows Vista and it will also work on Windows 7. AppLocker can only be applied on Windows 7 and up. When using SRP, we have to configure all policies manually. We can configure restrictions based on rules.
The first rule that we can use is the Hash rule. With hash rule we create a digital fingerprint (a hash value) of file based on the content of the file. This means that regardless of the location or the file name, the hash value will be the same. The disadvantage of hash rules is that we need to manually create new hash values for every file and for every version of the file. This means that for every update of the file or program we will have to generate a new hash value.
Another rule that we can use is the Certificate rule. With certificate rule we use a publisher’s certificate to identify the application. If all applications use the same certificate (certificate of the same vendor), we can target multiple applications with a single certificate rule. To apply the certificate rule we must obtain the certificate of the application vendor. The main disadvantage of certificate rule is the performance. Each time the application is executed the certificate has to be validated. Another problem is that we can’t apply different restrictions for different applications from the same vendor.
Another rule that we can utilize is the Path rule. Path rules are easiest to manage since we only need to specify a file, folder or a registry key as the target of the restriction policy. For example, the path can be “C:Adobe”, or the file can be “reader.exe”, or specific registry value. The more specific rule takes precedence. The file name is more specific than folder name, and registry value is more specific than the file name. The main disadvantages of path rule is that the restricted files or folders have to remain in the same path. If we rename or copy the restricted file to other location, the application will run.
Another rule that we can use is the Network Zone rule. This rule applies only to Microsoft Installer Package (MSI) files downloaded using Internet Explorer. Zone rules only apply to MSI files, not other executable files. Zone rules are similar to the security zones in Internet Explorer. This allows us to run MSI files based on the Web site from which the file was downloaded.
We also have the Default rule, which is applied when no other rules match the specific application. Starting from Windows 7 we have a new default rule named “Basic user”, in addition to the other two default rules in SRP. The default rules are now “disallowed”, “basic user” and “unrestricted”. With the “disallowed” rule set, users are unable to run applications if the applications are not allowed by any rule in software restriction policy. This is the most strict rule so we should be careful when enabling it. The “basic user” rule enables users to run applications that do not require administrative rights. With “unrestricted” rule enables users to execute all applications unless there is a restricted rule for specific application.
In SRP the more explicit rule will override the more general rule. If two restriction rules are applied to the specific program, the more specific rule takes precedence. The most specific rule in SRP is the hash rule, then certificate rule, then path rule, then zone rule, and then the default rule.
When using SRP we can use software enforcement policies options. This means that we can apply restriction rules to all software or to all software except DLLs (actually, it is recommended to exclude DLLs in restriction policies because of great number of DDL files). Also, we can apply policies to all users or all users except members of the local administrators group. We can also ignore or enforce certificate rules when applying restrictions. We should ignore certificate rules if we’re not using them to preserve performance. We can also specify which file extensions should be restricted. We can add or remove as many extensions as we want, but we can’t remove standard executable extensions such as EXE, COM, etc.