Software restriction policies srp

AppLocker permits customization of error messages to direct users to a Web page for help. All SRP rules are in a single rule collection. AppLocker can control the following file types: Executables Dlls Scripts Windows Installers Packaged apps and installers AppLocker maintains a separate rule collection for each of the five file types.

SRP supports an extensible list of file types that are considered executable. Administrators can add extensions for files that should be considered executable. AppLocker currently supports the following file extensions: Executables. Beginning with Windows 7 and Windows Server R2, you can only select the file to hash, not provide the hash value. AppLocker computes the hash value itself. With SRP, you can specify the permissions with which an app can run.

So, you can configure a rule such that Notepad always runs with restricted permissions and never with administrative privileges. SRP on Windows Vista and earlier supported multiple security levels. On Windows 7, that list was restricted to just two levels: Disallowed and Unrestricted Basic User translates to Disallowed.

Software restriction policies are enforced by the operating system and by applications such as scripting applications that comply with software restriction policies. Set the scope of the software restriction policies specify whether policies affect all users or a subset of users on clients. Prevent executable files from running on the local computer, organizational unit OU , site, or domain.

This would be appropriate in cases when you are not using software restriction policies to address potential issues with malicious users. The following features are required to create and maintain software restriction policies on the local computer:.

If your design calls for domain deployment of these policies, in addition to the above list, the following features are required:. Skip to main content. This browser is no longer supported. However, before you begin to formulate an application whitelisting policy, it is very important to understand precisely the sets of applications that your users need to use. Blocking without preparation can easily lead to chaos as line-of-business applications stop functioning, and this will have a terrible knock-on effect for your user experience.

You should never implement application whitelisting without proper planning and testing! You can deploy SRPs and AppLocker policies without AD, but it would involve configuring local policies on each machine and therefore has a very big overhead. For the purposes of this article, we will assume that deployment is being done via AD although the policy settings would be the same if done locally.

For the auditing aspect, you can either use the audit features provided by SRPs or AppLocker, or you can use a third-party monitoring tool. However, in an ideal world a central monitoring tool would be best, in order to give you full visibility of what is being run.

For posterity, SRP produces log files, AppLocker produces event log entries, and a third-party monitoring tool should provide proper reports. The techniques described here allow you to whitelist certain key system areas like the Program Files folder without needing to formulate an exhaustive list of executables that lie within them, so the process can be slightly less intimidating than it first may seem.

However, it is vitally important that you capture all required executables, as some of them run from places you might not expect such as Teams, Chrome, DropBox, Slack, etc. An example of a non-standard application launch being blocked.

The main drawback is that WDAC cannot currently apply policies for different users or groups on shared computers. As a best practice, you should enforce WDAC at the most restrictive level possible for your organization, and then you can use AppLocker or SRP to further fine-tune the restrictions. It already has some features that work above the capabilities of AppLocker and SRP, such as restricting kernel-mode drivers and preventing administrators from being able to turn off the protection.

Software Restriction Policies are not as granular as AppLocker rules, in that they cannot be applied to specific groups of users so, for instance, allowing UserA to run an application, whereas UserB cannot, is not possible with SRPs. Software Restriction Policies can be run in either a blacklist or a whitelist configuration. Right-click the node and choose New Software Restriction Policies.

Security Levels and Additional Rules we know about and will come to in a moment. Firstly, though, right-click on Enforcement and choose Properties , and you will see this dialog.

If you start applying application controls to DLL files, you may find problems as you will need to list all libraries used by a program. I would only turn on DLL-level checking in high-security environments where you have total control over every file in use. The second option, Apply to all users or all users except local administrators , is up to you to decide. If you are in an environment where administrators routinely log on to and perform troubleshooting on client devices, then make them exempt from the SRP rules.

However, if you are in an environment where all troubleshooting is done remotely via a privileged-access station which, ideally, it should be , then you can apply the restrictions to administrators as well.

Alternatively, you can whitelist all of the administrator tools as well, but bear in mind that because SRPs are not flexible by user this will allow ordinary users to run these tools also. Choose the option that makes the most sense for your environment. The final option is whether to enforce certificate rules. If, in the Additional Rules section, you are using certificate-based checking, then you will need to enforce them here.

The caveat about performance refers to the need to check a certificate revocation list CRL every time a program is run. It also means that the CRL usually held online needs to be accessible from the client, so environments with internet access blocked may struggle if this option is enforced.

Choose the option that matches your requirements. Notice that. All of the others in the list can be removed, or added to. There are a couple of notes worth calling out.

Firstly, that. I normally remove. The final option is for management of Trusted Publishers. It also, optionally, allows you to enforce a CRL on the trusted certificates. Again, choose the options which are relevant to how you wish to manage the environment. You will get a warning — just click on Yes. This now means that everything will be blocked, subject to a the options configured under your global rules, and b any Additional Rules configured with a security level of Unrestricted.

In a whitelist situation, you configure Additional Rules with a Security Level of Unrestricted to allow executables to run. However, these paths predate the arrival of x64 computing and often will mean anything in the x86 Program Files folder will be blocked.

I delete the default Path Rules and replace them with those shown below This ensures that files in the system areas can execute without needing to provide an exhaustive list prior to deployment. Population of the Additional Rules section is where your understanding of execution areas will become paramount.

For instance, in our image we use App-V applications. These applications do not execute from Program Files or the SystemRoot areas — they have their own cached location. If we try to launch one, we see the standard SRP block screen below. If you then check in the Event Viewer under Application log and look for an event ID , it will tell you the path of the executable which was prevented from running. So we need to add a new Additional Rule that allows this path.

One thing worth noting with SRPs, though, is that often the user has to log out and back in before the updated policy will take effect. So now only executables residing in our specified paths can be run. For instance, I can run regedit. Simply allowing Paths is the most basic way to allow executables to run. However, this can potentially be subverted by an attacker creating files within the allowed Paths, even with the same name as expected executables, if you have restricted by exact name.