Perhaps you followed the advice in my previous checklist, made Joe only a local administrator and then reduced the rights of the local Administrators group. If you did, good for you! It's a great first step, but ultimately making Joe an administrator at all is not the best plan; he can always give himself back whatever rights you take away. Sure, you can audit his actions, but who has extra time for that? To technically control Joe...
you must follow the principal of least privilege. That is take all his rights away and only give back what he absolutely needs.
This approach is a bit harder, but pays off. When I talk to customers who follow the principal of least privilege, they report enormous reductions in downtime due to worm and virus attacks and help desk calls. Part of their success is based on better standardizing applications and configurations, and part is based on the reduced privileges users have. Perhaps there's also some gain because everyone is now more aware of how their actions influence security, performance and productivity.
So how hard is it to design a security model that gives Joe only the rights and privileges he needs to do his job? It takes a little research and a fair amount of testing. Here's how.
You may download a printer-friendly version.
How to control Joe User's actions
Stop thinking about Joe
The first step is to stop thinking about Joe, and start thinking about the class of users he represents. In other words, stop focusing on the needs of the individual, and instead focus on the needs of "like" individuals. Are there groups of employees that need more access than others? Are there common applications used by everyone? There's more to it than that, but that is a way to start. Either pick an application that is universal to all or pick a specialized group of people and then determine what they need first. By reducing the problem to something unique, it becomes surmountable. Once you've got some identifiable results you can move on to the next problem.
Evaluate what to expect by giving Joe only what he needs
Say there is a common application everyone uses that will only run for people who are administrators. In order to reduce the number of people who must be administrators, you should make these applications run for users instead. This is a good thing; success with highly visible projects is a plus. But if you stumble and make it impossible for people to do their job, you may not get a second chance. On the other hand, if you can make one highly visible group of people happy and reduce risk, you're off to a good start. Just make sure people can still do their jobs, and test before rolling out a solution.
Figure out why a specific application or job task requires administrative privileges
For many applications, administrative privileges are required because of poor coding. It's much easier, for example, to open all files or registry keys with all rights then it is to figure out and code just what is needed in each case. Unfortunately, some resources are permissioned to be read by ordinary users, but only written by members of Administrators. If the application was written correctly, any user could run it. Since it's not, you've got to change the software or work with the permissions. Modifying software requirements means getting the manufacturer to rewrite the code or buying different software. It's easier and faster to find another solution.
Find out which resources an application needs and give Joe access to those resources
Since you can't change the permissions the software required, your job is to find the resources the application needs to access and give Joe User access to those resources. Giving Joe access to resources is less risky than making him a member of local Administrators. To find what Joe needs, use filemon and regmon, two free tools available at Sysinternals. These utilities point out which files and which registry keys an application uses.
Create a new user group and test access
Make a new user group and assign that group access to the resources that filemon and regmon revealed. Make a test user account and give it membership in the group. Log on as give it membership in the group. Log on as that user and run the application. Does it work? If not, try regmon and filemon and try to find out why, then change the permissions for your new group until you get the application to work.
Finally, give Joe and some users membership in this group but not in Administrators. Can they do their job? If so, one problem solved. Find the users who run this application and add them to the group. Do they still need membership in Administrators for other applications? If not, remove their membership from Administrators. Are there more applications that need work? Go back to step one and start again.
Windows Security Checklists offer you step-by-step advice for planning, setting up and hardening your Windows security infrastructure.E-mail the editor to suggest additional checklist topics.
Related Checklists by Roberta Bragg
- If Joe User must have administrative rights, learn how to lock them down
- Educate Joe User so he limits his own actions
- Check out all of Roberta Bragg's Windows Security Checklists
ABOUT THE AUTHOR
Roberta Bragg is author of "Hardening Windows systems" and a SearchWindowsSecurity.com resident expert. She is an MCSE, CISSP and Microsoft MVP, and a well-known information systems security consultant, columnist and speaker.