How to restrict developers’ admin rights

Almost every customer I deal with has unhappy developers who feel constrained. Not only are they being forced to develop applications in which users will not always have admin rights, but the dastardly system administrators aren’t letting developers run with full administrator rights all the time, either.

The rationale is obvious: Limiting the number of administrators reduces security risk and makes it harder for successful exploitations to occur and for attackers to do bad things if they are successful. But much of what developers do (such as installing drivers, writing to system directories, running installation programs, and so on) absolutely requires admin rights and permissions, and without them, productivity drops.

[ Learn how to work smarter, not harder with InfoWorld’s roundup of all the tips and trends programmers need to know in the Developers’ Survival Guide. Download the PDF today! | Keep up with key security issues with InfoWorld’s Security Adviser blog and Security Central newsletter. ]

How do you satisfy both sides? First, you need to recognize that the world where everyone is an administrator is gone forever — and whatever the solution, it won’t be as convenient. This is a necessary side effect of improving security.

Beyond that, there’s no single solution to the developer dilemma. It depends on the company’s operational goals and priorities, as well as its risk tolerances. With that said, here are solutions I’ve seen in the real world.

• Give developers two separate accounts, one regular and one admin, and two different computers. They should use only the admin account on the developer box, which is locked down. The other can be their normal computer that they use with the nonadmin account. The admin box should be network shunted and allowed access to only the necessary resources.
• Let developers be full admins only on a local virtual instance that has no access to the local network or Internet.
• Create a custom app service where the developer can request elevated credentials or a particular predefined application or task for a certain period of time. I’ve seen this used a fair amount in big companies, but it has lots of exploit opportunities.
• Let developers use privilege management software, which can automatically elevate pre-assigned development tasks.
• If using Windows, modify UAC (user account control) to do silent elevation (pretty insecure, but a choice).
• Modify the developer workstreams and tasks so that they don’t require elevation all the time, such as modifying registry and file permissions. This removes the need for elevation altogether.
• Require an authentication method for elevation that isn’t as problematic as long, complex passwords — for example, biometrics or a smartcard and PIN. Sometimes easing the multiple elevation log-ons is all it takes to satisfy both sides.
• Give up and let developers run as full admins all the time. This is the riskiest route, of course, but developers retain the freedom they need.

Readers, I’m sure you can contribute other ideas. I’m relaying some existing solutions for making both sys admins and developers happier.

The fact is that world has changed and most of the time we can’t let nonadmins be admins all the time — not even developers. You could argue that developers, since they are directly working on the company’s newest intellectual property, should be locked down the most of any user group in the company. But there’s a happy medium somewhere — one you’ll need to cobble together yourself based on your own needs.

This story, “How to restrict developers’ admin rights,” was originally published at InfoWorld.com. Keep up on the latest developments in network security and read more of Roger Grimes’ Security Adviser blog at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.