Is there any way to tell Windows (XP and above) not to execute files (*.exe files), which are present in drives/folders other than certain folders, that I mention? In short I want executables from only a 'whitelist' to be executed.

I think this is better than asking users not to run any executables from whatever garbage CDs they bring from home.


you want Software Restriction Policies. This underutilized feature of modern Windows allows the administrator to allow or restrict executables from running based on the path or even based on a cryptographic signature. By the way, you want more than just EXE's. Software Restriction Policies has a list of 30 or 40 additional types of files that you need to restrict, such as CMD and SCR, Screen savers. In addition, you can block DLL's.

I would rate its effectiveness as substantially better than anti-virus.Also, it's difficult to educate users about social engineering attacks that modern malware uses, such as getting a user to click on ListenToThisMusic.mp3.exe.

  • You hit the nail. :) The venture was succesfull. – mohan Jun 23 '09 at 16:51

I'd be careful with this. You won't be able to 100% lock everything down and you will make the machines nearly impossible for users to use. You should look at educating your users and putting process, policy and education in place. You need to find the right BALANCE between restricting actions and end user productivity.

I see a LOT of wasted $$$ in companies where they make users lives absolute hell just to make things a little bit easier for the support guys.

  • 1
    I'm not sure why people downvoted Bruce here. He raises a good point. Unless you have a very clearly defined and small list of apps you want people to use, tight SRPs can be a total pain in the hoop. – Rob Moir Jun 14 '09 at 11:35
  • It's a bit of a cop-out answer, and will only work with users who genuinely make mistakes. If you're dealing with the type of user who is always going to be bad you need firmer control. A HR-backed policy can only deal with the incident after it has happened, and you may well have significant havoc to clean up by then. It's more about achieving the correct balance than about being draconian. – Maximus Minimus Jun 14 '09 at 11:43
  • Good point. Like many things, it’s important to make sure the IT policies agree with what the company wants. For example, if we had a bank, we might have computers in the lobby for customers, tellers, developers, and a CEO that wants to play Doom. Lobby computers would be locked down with SRP and probably Steady State. Tellers can’t install software; they’re not admin; and SRP enforces no software other than what's installed for them. The developers are admin on their own machines and SRP is likewise less restrictive. And the CIO takes care of the CEO’s machine. – Knox Jun 14 '09 at 15:37
  • Actually you can lock it down 100%, it just makes the machine far less utilitarian. I use to use SRP all the time to create data entry machines. – Jim B Jun 15 '09 at 3:32
  • I'm not using this on the users' personal(company's cubicle) systems. Only in the labs where people share the systems and we exectly know which software they'll use. This distinction is made as these systems contain sensitive data while the personal systems are normally used for their other work including mail checking, porn (;-)) etc. My irritation is that some users cuoldn't control themselves in little time they spend in lab. Ergo we go SRP way. :) – mohan Jun 23 '09 at 16:57

You can whitelist using software restriction policies in GPOs but I'm not sure how effective it is. I'd bet a small donut on it working with most non-malicious users in most places but I wouldn't bet my career on it working anywhere and I wouldn't count on it in places where I expected it to come under attack (e.g. educational environment).

You can certainly block code from running from certain devices and areas of the disk with a combination of ACLs and Software Restrictions and that is a useful security tool, but I'd make it a small part of a security policy, not the cornerstone of one.


You could use Cisco Security Agent with a rule that (after a "watch only" period for training) blocks any executable that hasn't run before.

You can allow executables from certain directories if you want.


Its much easier to Blacklist than it is to Whitelist. Most likely you have an idea of what you don't want the users to run. The way Windows handles this is through Software Restriction Policies in your GPO. Software Restriction Policies can be used for allowing software to run as well as denying it. There are four different methods available to use and they are: Hash rules, Certificate rules, Path rules, and Internet zone rules.

Hash Rules rules uses a MD5 or SHA-1 hash of a file in its match. This can be a uphill battle. Trying to block something like pwdump using just a hash rule is going to result in LOTS of entries, for each different version of pwdump. And when a new version comes out you need to add that as well.

Path Rules are based on the location of the file on the file system. So you could restrict "\program files\aol\aim.exe" for example, but if the user chooses to install it into "\myapps\aol\aim.exe" it would be allowed. You can use wildcards to cover more directories. It is also possible to use the registry path if the software has a registry entry but you don't know where it will be installed.

Certificate rules are useful for software that includes a certificate. Which means mostly commercial software. You could build up a list of Certs that are allowed to run on your systems and deny everything else.

Internet Zone Rules only apply to Windows Installer Packages. I've never used this so I can't comment on it much.

A proper GPO will use several of these rules to cover everything. Restricting software requires you to really think of what you want to prevent to get it right. Even then, its probably still not right. Technet has some good articles on using Software Restriction Policies, and I'm sure there are other good docs off Microsoft's site found through your favorite search engine.

Good Luck!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy