Desktop security can be very frustrating for IT professionals as we try to find the delicate balance between security and user experience. Most end users take things for granted and don’t realize the potential danger that lays in wait in advertising and other lovely pop-ups that warn of impending doom of their computer or hard drive that must be saved by this “free” software!
For those that wonder how this may apply to nonprofits, just remember that productivity is just as vital (if not more) in the nonprofit world as it is in the corporate world. Having lost time due to a virus outbreak is annoying, but lost or stolen data, downtime because your ISP has turned off your internet access due to SPAM emails being sent out, etc. is much more than just annoying. It can take a lot of time to rectify the virus problem, and that doesn’t include the network cleanup, ISP phone calls and calls to customers or donors letting them know their data was either lost or stolen.
Antivirus software such as Symantec, ESET NOD32, or my personal favorite, Vipre Enterprise, can only do so much with a persistent user who really wants to install that free software. There’s only one sure way to prevent that software from being installed – and that’s to prevent the user from installing it at all.
This is probably one thing that most IT staff (volunteer or paid) get soft on with their end users – local admin rights. Being a local administrator, for those that don’t know, gives you the “keys to the castle” to make all system/registry/file changes, which also allows any software you install to make those changes. Virus, spyware and other malicious software (well, all software, actually) will run within the security context of the logged in user. This means, to continue the key analogy, that any virus that attempts to run on your computer has access to everything door/room that you do. Microsoft notes this on many, if not all, of their security patches in a statement similar to this:
“An attacker who successfully exploited this vulnerability could gain the same user rights as the local user. Users whose accounts are configured to have fewer user rights on the system could be less impacted than users who operate with administrative user rights.”
For management, power users and even IT personnel, it’s fairly often that software needs to be installed, updated or system changes made for a variety of reasons, so local administrator access is really the default in most people’s network configuration. Step 1 – Join PC to Domain, Step 2 – Add user to local Administrators group. The alternative is to log off and then log back in with an administrative user to make any system changes. This is not only annoying, but it’s also inefficient. However, virus outbreaks, as I noted earlier, are much more costly.
In my network, I apply the following principles: 1) No local administrators unless a specific application requires it (there are some older applications that do require it).; 2) Use Restricted Groups in Group Policy to assign workstation administrator accounts (that are not domain administrators) to all PCs within the domain.; 3) Use Vipre Enterprise for antivirus and malware protection.
Restricted Groups are a very powerful tool in Group Policy to assign users to specific groups on a local machine, but they must be used carefully. Restricted Groups is a wipe/replace setting, which means that any user(s) you put in the local Administrator group will replace the existing users. So be sure to add the “Administrator” account in addition to any domain accounts you would like to add to the Administrators group. More information is available from Microsoft here (http://technet.microsoft.com/en-us/library/cc785631(WS.10).aspx).
For those that don’t have any special applications that require administrative permissions can feel free to quit reading now, as I know this is long-winded. But for those that want to implement these security measures but have some older applications that require local administrator access, keep reading for tips on that.
To deal with those pesky older applications (and some newer ones) that seem to require local administrator privileges, you can use tools such as FileMon, and RegMon that are part of the Sysinternals toolkit available from Microsoft at http://technet.microsoft.com/en-us/sysinternals. These tools will show you in real-time what files and registry keys are being accessed by specific applications. Using these tools will give you the first piece to the puzzle – which is finding out what your users need access to in order to run their applications.
You may already know the steps to use these tools, and if so, you can skip to the next section.
- You’ll want to close as many applications as possible to prevent confusion
- Open FileMon and RegMon (before your application of interest)
- While opening your application, RegMon and FileMon will show all files and registry keys that are used by the application being opened.
This will give you the list of files (most likely all in the same folder) and registry keys that your users will need permission to access in order to run the application. Most applications simply need the user to have access to the folder in which it’s installed (C:\Program Files\application), and possibly its registry key. The next step is to assign those permissions…
This is going to be accomplished via a Group Policy Object (please don’t edit the Default Domain Policy), and you’ll want to make your changes in the Computer Configuration section, as this needs to be applied to the computer in order for it to work for all users that may log in. So, Computer Configuration\Windows Settings\Security Settings will contain the Registry and File System subfolder where you can assign permissions to folders and registry keys. I typically assign the Domain Users Security Group to the folder in question (Full Control), but you could also create a new Security Group in which only the users in need of the application are members, and assign Full Control access to that group. This can become cumbersome if you have multiple applications, which is why I use Domain Users. So far I have not found a problem if the folder did not exist on the computer, so feel free to apply this to all computers in the domain, as it won’t cause any harm if the folder doesn’t exist on a computer – it just won’t apply the permissions to that PC.
You can use the same principle to apply permissions to registry keys as needed, but remember to only provide full control to folders/keys that are necessary as this is providing full access to these locations, and if you just assign Full Control to C:\ and include all subfolders, you’ve done nothing to prevent viruses.
You can also incorporate other measures to help prevent virus outbreaks or spyware issues on your local network, but I will save those for another day. Hopefully this has provided a little insight into providing better security for your network and working with applications to provide that balance between security and user experience. As I talked about in the beginning, virus outbreaks can be costly, and the time invested up front in getting the correct permissions in place will pay for itself in one virus outbreak. And the proof is in the results – in the 14 months I have been in my position, since implementing these protocols, we have not had one single virus outbreak. We have had viruses detected by our AV software (Vipre Enterprise), but they are stopped immediately due to the antivirus and lack of permission for users to install software. It has saved a lot of hours of my time chasing spyware.
One other link I’d like to show you is a local country store that recently had customer credit card information stolen due to a virus/malware of some sort. While I don’t have all the details, I’m going to guess that there was some website popup that started this ordeal, and local admin permissions were probably a factor. http://t.co/PxteS2e
Thanks again for reading.