There are plenty of options to prevent unknown and unwanted code from running on Windows systems; you simply upload reputable antivirus and antispyware software and it's almost a plug-and-play solution. No more worries.
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
@33746 But what if there are specific Windows executables you are aware of that you want to allow or prevent from running in Windows? You may not want certain users or groups to be able to run things like built-in or third-party Windows diagnostic tools (net.exe and Process Explorer come to mind), hacking and cracking programs, and even internal client/server apps. The list is endless but there's almost always a business need in organizations to create executable whitelist or blacklist controls.
A seemingly simple solution is to tell your users not to run unsupported or banned software. After all, it's probably documented in your organization's acceptable usage policy. But anyone with a week's worth of experience supporting a Windows environment knows what happens in reality. By and large, users won't care if a policy is in place telling them what they cannot do. That doesn't mean you can't do anything about it.
For starters, you can change NTFS permissions to remove the Read & Execute permission from specific files. However, I think this is too complex and too unreliable. Instead, look into creating Windows Software Restriction Policies. You can do this at the domain level via Group Policy Objects (GPOs) in Active Directory or on a per computer basis by creating individual policies using gpedit (Start/Run/gpedit.msc) as shown in the following figure.
Figure 1 - Creating executable restrictions using Group Policy
As you can see, there are options to create rules based on software certificates, file hashes, Internet zones and path locations. As a quick example, I created a hash rule with the security level set to disallowed that prevents the tsgrinder program from running on the local machine. (See Figure 2.)
Figure 2 - Creating a hash rule prevents the tsgrinder password cracking tool from running.
After you create the rule and the program is executed, the error window shown in Figure 3 validates that the policy works.
Figure 3 - Software restriction policy prevents a specific executable from running.
This is a basic -- yet very powerful -- set of blacklist controls locking down specific executables in Windows. You can also deny everything from running and then set up whitelists of trusted paths or specific Windows executables that are configured with an unrestricted security level.
If GPOs or local policies aren't your idea of fun, there are third-party applications that provide similar (but more in-depth) blacklisting and whitelisting capabilities for executables in Windows. Specific commercial products include Horizon Datasys Inc.'s Exe Lockdown, Faronics Corp.'s Anti-Executable, and Fortres Grand Corp.'s Fortres 101, one that I had lots of experience with in hostile K-12 educational environments. All three are deployable via the network and the latter two have pretty impressive enterprise management features. The pricing for these solutions is reasonable given the control you can attain -- especially when you compare them to the user free-for-all downside of your workstations. If your budget's limited, check out the freeware tool called Trust-No-Exe for similar features.
Windows security, like other facets of information security, is all about control. Reasonable IT safety controls on what users can and cannot do are a great step toward minimizing a good portion of vulnerabilities on your network and the associated business risks your users are no doubt creating.
About the author: Kevin Beaver is an independent information security consultant, speaker and expert witness with Atlanta-based Principle Logic LLC. He has more than 19 years of experience in IT and specializes in performing information security assessments involving compliance and IT governance. Kevin has authored/co-authored six books on information security including Hacking For Dummies and Hacking Wireless Networks For Dummies (Wiley) as well as The Practical Guide to HIPAA Privacy and Security Compliance (Auerbach). He also created the Security On Wheels series of audiobooks. Kevin can be reached at firstname.lastname@example.org.