Removal of “NCSU-Banned Software” policy

For some time now there has been a really great security feature that was introduced with Windows Server 2003 and Windows XP. This feature was designed primarily to help administrators keep unwanted programs (like malware) off of their systems. It’s called “Software Restriction Policies (SRPs)”. These policies allow OU Admins to create a list of specific applications that they want to deny endusers from installing. In general, however, SRPs have gone unused primarily because of the time it took to create and maintain the restriction polices.

Case in point…

The “NCSU-Banned Software” GPO was created in 2005 and applied throughout the domain. We created this policy because I felt that there were certain applications I didn’t want installed on a computer on the WolfTech domain — specifically, P2P / filesharing applications. At the time, they were extremely popular and a huge security hole — often leading to our machines being compromised. Examples include Limewire, Kazaa, eMule, and others. And it was effective in reducing the installations, especially when combined with departmental IT policies.

The list of software within the policy was maintained until early 2007. At that time, we lost the system administrator who had been actively updating it. It has not been updated since. As the way SRPs work depends on the administrator creating new hashes for *every* new release of the applications, the list has become irrelevant — our users aren’t trying to install 5yr old versions of P2P software; they’re installing the current versions.

So, in an effort to keep our central policies limited (and cleaned up), we’re preparing to unlink/retire the policy a month from now. I’ll be posting the date to Sysnews on Monday. Sure, we could do it now, but we like to play it safe. In the meantime, we’ve created the following “software” group.

<DEPT>-EX-NCSU-Remove Banned Software-1.0

Any computers you place in this will ignore this policy. Those interested in testing ahead of time now have that option.

We do not plan to replace this policy with a new one with current software. Partially because of the effort it would require, partially because the domain is no longer controlled solely by myself and its up to each unit to decide what applications, if any, they wish to deny to their users. We will be providing the NCSU Security Committee with the option to create a new central policy for any campus wide security threats they identify, but I expect its usage will be very limited and would address very specific issues.

For those of you interested in creating your own lists of denied software, here’s some details on maintaining your own Software Restriction GPO: