If you have end users (and who doesn’t?) you should be worried about what they might try to run or install on their computer. Some people just don’t pay attention, clicking on any box that may appear.
Others simply think they can do whatever they want on their work machine.
But, for the most part, people simply don’t understand that an innocent appearing pop up may actually be something that they don’t want.
Antivirus software can help, but we all know it’s far from foolproof. Another great idea is to make sure your users are not local administrators. Unfortunately, that doesn’t stop them from installing all programs, just those that go into protected areas like the Program Files folder. Anything that installs under a profile, like most browsers (and most crypto infections) can install with only user-level access. So what’s an admin to do? Whitelist!
Whitelisting is a process where you select a list of programs and allow only those programs to run. If a user tries to run (or install) anything not on the list, it will fail with an error similar to this:
There are many third party programs out there that can implement whitelisting, but Windows Server already has this ability built in. If you are using Pro versions of Windows on your Desktops you can use Software Restriction Policies (SRP). If you are using Enterprise versions you can use the more full-featured Applocker, but most small businesses will find SRP is more than enough.
Software Restriction Policies are configured via Group Policy, and work just like any other GPO. You can configure it as a User or a Computer GPO and then apply it however you like. You can even set up SRP via Local Policy on machines that are not on a domain.
SRP offers several ways to add programs to the whitelist.
- By path. This is the broadest method, allowing you to add entire folders. This is the method used to add the default items, like the Windows folder. This should only be done with paths that you trust and that cannot be written to by your Users. If your user has write access, the path isn’t safe because the User could put anything in there.
- Programs by filename. This allows you to specify a particular location (like c:\MyProgram) and only allow a certain filename to run from it. This is a little more restrictive than allowing an entire folder, but if the User can write to this location there is the chance that they might delete the real program and replace it with something of their own. For less tech-savvy users, though, this isn’t very likely to happen.
- Network Zones. This allows programs if they come from a trusted site, like your local Intranet. While this option exists, it seems unlikely that any SMBs would ever use it.
- Hash rules. With this option, SRP will create a hash of the file you want to allow and then it will be allowed to run no matter what folder it happens to be in. This is considerably more secure than a path rule because only this exact file will be allowed. If you ever need to update the file, you’ll need a new rule to create a new hash.
- Certificate rules. These are probably the most secure type, because they are based on a certificate from the manufacturer. Because of this, they require more work from the PC and can slow down processing. Each time you run a program with a Certificate Rule applied it has to check in with the Server to see if the Certificate is valid and if it’s expired or not. When the certificate does expire, you’ll need to create a new rule.
While it sounds somewhat intimidating, getting SRP up and running really isn’t that bad. I’ve created a snip on the basic setup here:
And the NSA has a handy (somewhat outdated) PDF here:
As long as you remember to test your settings on a small group before deploying to the entire network, you’ll find SRP to be fairly painless. Whether you decide to use SRP, Applocker, or another option, with whitelisting your network will be safer than ever before.