Is locking down a developers machine more effort than its worth?

Question

Having worked as a developer and in IT admin/support for a development team, I've come across many different types of environment from the completely locked down to the completely non. In my limited support experience I think its been less effort to support with a less locked down machine and I certainly felt this was easier, but of course this could be bias. I'd like to know what the view is from an IT support perspective, is it genuinely harder to support developers who have non locked down machines?

Answer 1

Most developers are technically savy and know what they are doing. They often need to install many specialist apps, having to get permission to do this and getting IT to come down and add it can be very frustrating, particularly in larger companies, for both sides.

I've found what works best is allowing them to do what they want with regards to installing software on their machines, but if they get into problems with something we don't support, then they are on their own. Most developers are happy with this, and prefer being able to look after their own machine anyway.

Locking someone down in accounting to only use IE and open word is fine, but if your a developer who needs to install 4 different types of browser and need to quickly install an app to solve a problem, it can be annoying.

My experience is that companies who have alot of technical knowledge, so development shops, IT suppliers etc, who trust their employees and let them decide what they want installed are much happier and bother IT less

Answer 2

See this Stackoverflow posting for some lively debate about the merits of locking down developer machines. (Disclaimer: I wrote the accepted answer).

From a sysadmin perspective, access to production systems is sensitive and you should restrict such access to people who need it to do their job (this may include developers who have tier-3 support responsibilities for the application). Local admin rights over a development PC or development server does not significantly compromise security of your production systems.

Make an image that you can use to rebuild the machines with if necessary. Manually installing SQL Server dev edition, Visual Studio, Cygwin and MikTex plus a bunch of other apps is quite time consuming. An image with these large apps installed will be reasonably valuable if you have to re-image the machines much.

From a development perspective I find that I can fix most problems with the machine and typically only need help from network support staff on fairly rare occasions. Overly restrictive environments tend to generate spurious dev support traffic to do work that the developers are perfectly capable of doing themselves.

Another place where developers tend to need a lot of admin work done is on database servers hosting development environments. Most developers are capable of learning routine DBA tasks easily, and should get a working knowledge of this anyway (IMHO on principle). Overly restrictive admin access policies on development servers can get underfoot in many ways.

A scratch development network is quite a good idea if it can be arranged - you can firewall this from your production servers if necessary.

• When developers can easily replicate the structure of a production environment it promotes a culture of deployment testing where an integration test can be synthesised without jumping through hoops. This will tend to improve the quality of production release and deployment.

• Being able to emulate a production environment also raises awareness of production deployment and support issues. It encourages development staff to think of how an application might be supported in production, which will probably encourage architectures built with this in mind.

• If this network has a domain controller you can establish a trust relationship so it trusts your main domain controller and its accounts. This trust relationship does not have to be reciprocal, so it does not compromise security of your production network infrastructure. This can let you have an untrusted development network but still allow developers access to domain-authenticated resources such as Exchange accounts or file servers.

• You want developers to have a reasonable amount of scope for experimentation without having to jump through hoops. Placing political obstacles in the path of this work has a tendency to encourage sticking plaster solutions that are politically expedient but generate long-term (and often unrecognized) technical debt. As a sysadmin or support analyst, guess who gets to pick up the pieces ...

I will add that this is much less of an issue on a unix or linux environment; users can pretty heavily customise their own environment from their .profile. You can compile and install things under your own /home/bloggsj/bin directory to your heart's delight. 'Local admin rights' is mostly a windows problem, although there are still a few things that need root access under Unix.

Answer 3

The biggest problem with not locking down a developers machine is that any software they develop will require full administrator privileges to run. The developers access should be the same as the environment that they will need to run in. If they need to be "self supportable" or "self installable" then give them another admin account e.g. Bruce.admin which they need to use when doing admin stuff, but not used day to day.

Just like no decent UNIX admin worth their salt will ever use a root account for their day-to-day non admin work.

Answer 4

The most sensible option I've ever seen (have been on both sides -and still am-) is simply unlocked stuff and unsupported as well. Give them liberty, and if they screw up, all they can get is a restage with a standard image... . In that situation, I find it a good plan to put them on some form of "untrusted" network.

As far as the (non)sense of locking developer desktops: I'm pretty sure all the locking only hinders productivity anyway, moreover, any reasonably skilled developer will easily find the holes... .

Answer 5

The answer is really: there is no simple yes or no answer. But security is at least as important for your dev users as for anyone else.

On the one hand, yes devs tend to be technically more savvy. On the other hand, theirs is often a stressful job and their dev milestones are likely to take priority over the extra care needed to maintain one's own system as a secure environment.This isn't a criticism of developers; it's a forthright consideration of their daily duties.

If you are going to give devs full, unfettered access to their systems, then you should really consider the following additional measures:

• Provide another system, locked down as much as normal user systems are locked down, for normal non-dev use.
  • The put their full-access dev machines into a special VLAN, with access only to dev resources.
• Ask what if anything would prevent an infected system from endangering the codebase. Could a backdoor'd machine check in malignant code, or wipe out the codebase, in the hands of a hostile hacker? Take appropriate steps to mitigate this risk.
• Similarly, ask what if anything protects the business data held in systems the devs have access to.
• Regularly do software inventory and security audit of dev systems.
  • Get an idea what they're running and use this information to build your dev system redeployment images.
  • Sooner or later you'll have a dev who gets careless and installs things that are clearly dangerous or completely non-work-related. By sending warnings quickly when this happens, you'll be letting the dev community know that yes, someone is watching, and they do have a responsibility to stay within reasonable standards.
• Are you doing regular malware scans? In some cases, devs will rightly complain of the performance tax levied by on-access AV systems (those AV systems which are always on, always scanning on every file access). It may be preferable to move to a nightly scan strategy, and /or create file/folder exclusions to your on-access scanning. Make sure that excluded files are scanned in some other way, though.
  • Can your admin-enabled devs turn off all AV scanning? How would you detect and remediate this?

If you are going to lockdown dev systems, then you should consider the following:

• Do you have the support capacity to answer their support requests rapidly? Consider the average pay rate of your devs, and ask whether or not they deserve a faster response-time SLA. It probably doesn't make sense to keep your $120k dev (who's key to a multimillion dollar project) waiting around while you're handling support reqs from $60k/year employees.
• Do you have clear and unambiguous policy on what support requests you will and will not service for your devs? If they start getting the feeling that support is arbitrary, you will eventually feel the pain.

Either way, you do need to admit that developers are a special case and they do need extra support of some kind. If you're not budgeting for this, problems are likely festering right now ... or will be in the future.

As a side note, I've seen very similar arguments take place with sysadmins. On at least two different jobs I've seen sysadmins argue quite acrimoniously when it was suggested that they should themselves have locked down systems, or at least use two logins (one with root/admin privs; one without). Many sysadmins felt that they should not be locked down in any way and argued strenuously against such measures. Sooner or later some lockdown-averse admin would have a security incident and the example would have an educational effect on all of us.

I used to be one of those sysadmins who ran with admin privs all the time. When I made the change to dual accounts and only elevating at need, I admit that it was quite frustrating during the first few months. But the silver lining in the cloud was that I learned a lot more about the security of the systems I was administering, when my normal account lived under the same restrictions I was placing on the users. It made me a better admin! I suspect that the same is true of developers. And fortunately in the Windows world, we now have UAC, which makes it easier to run as a limited user and elevate only when needed.

Personally I do not think that anyone should be above some form of security practices. Everyone (sysadmins, devs, upper management included) should be subject to enough security procedures and oversight to keep them on their toes. To say otherwise is to say that company systems and data are not worth the effort to protect.

Let's put it another way. If Mark Russinovich can be taken in by a rootkit, anybody can!

Answer 6

Where you have a few developers, the approach to give them development servers is a possibility, but if you have an entire floor of developers, then I am very much against giving them any admin rights whatsoever.

The problem is that you'll end up with an entire floor of developers, each doing what they do, usually most aren't even security-conscious and just want their app to work. Then you'll be hit with a request of - "We've completed the development phase, please replicate our dev environment onto test, pre-prod, and prod".

They also get into the habit of installing random junk (badly packaged software), and then delegate you to install it on the dozen or so servers in the other tiers.

I make the policy quite simple:

• Developers do NOT get root access - ever - for the development environment.
• The Developers DO get root access to pre-dev VMware servers, but NO support.
• Developers must either provide RPM packages that belong to the OS distribution onto which their app will be running, OR, RPM packages that comply with the FHS and LSB.
• None of their applications can under any circumstances run as root
• The will not have access to su or sudo to the application user - which will be locked down to having NO shell access. (This is for accounting/audit).
• Any commands they need to have run with privileged access will have to be explicitly requested and approved - at which time it will be added to the sudoers file.
  • None of these commands/scripts will be writable by them.
  • No script (directly or indirectly) reference by these commands will be writable by them.

The above will above all, get them thinking about what will and will not be allowed when it comes time to move the project onto the test and above servers.

Answer 7

Locking down developers' machines takes more effort than it worth. It seriously harms productivity as you can't do pretty much anything without administrative rights. Of course, eventually the system will become messed up, but surely your IT dep is not providing support for all those 3rd party tools that are used in development?

So, as Vincent De Baere suggested, the best course of action would be just restoring the system from an image, of course, the environment must be restored after that, but that should not be IT's problem. If it happens N times you can put a said person on a kind of "black list" and, yes, drop his administrative rights for a while.

Either way, the environment should be set up in a way, that makes sure, that an infected (or otherwise messed up) machine does not affect any other machines at all or, say, doesn't send spam or something (ok, now I'm just saying obvious things, sorry).

Answer 8

Well, it may in part depend upon what environment you are running in (e.g. Linux versus Windows); however, assuming a Windows environment, it is usually more trouble than it is worth simply because some of the development software out there requires you to have elevated permissions to work. For example, Visual Studio is known to require Administrator permissions, as such, I don't see the benefit in making someone jump through hoops for a required part of their job.

However, if the company requires that things be locked down your best bet is likely to give all developers virtual machines on their systems that they can go crazy in. While some might not like this that much, it will likely give you the best of both worlds (e.g. restrictive normal desktop and a fully customizable environment).

Update - On the Windows side of things there is a bit more worth noting, apparently the Visual Studio requiring Administrator rights is a bit dated and there are now explicit ways to set the permissions needed (PDF file). However, I don't think this changes my option that much in that most developers I know, myself included, tend to use additional tools beyond just Visual Studio and knowing what all of them need in terms of permissions can be hard to predict.

Answer 9

I agree with the notion of using virtual machines on top of a restricted desktop-

Unless otherwise necessitated, I feel the best setup is a restricted linux desktop with a free-for-all vm on top. Linux lessens overhead for me, a vm can not only be whatever-the-hell OS they want, but also be restored to snapshots or backups, and generally the world looks a bit brighter when there aren't a whole slew of different setups needing support.

Answer 10

I (as a dev myself) prefer to have full control of my machinery, meaning; running as admin when needed.

You could provide special training for devs before they are allowed full access to their computers. Set some rules for them, and maybe you could do an audit every once-in-a-while to see that they follow best practices.

Mostly they'll need to know more about IT infrastructure from a IT admin/IT support view, security-related stuff, as well as why not to develop with elevated rights. (and how to make sure of that you don't...)

"Dont blindly trust us when we tell you that we know all we need to know about computers" ;-)

You'll still have to support them with networking, domain- and account-stuff, software-installs of non-dev tools etc.

Answer 11

My experience is with a user population that was about evenly split between people who only needed a locked down machine and other (developers, scientists) who needed admin access. They high-end people used a lot of different software, some in-house, some not, but lots of it needed admin to run, and their jobs required them to use a lot of packages so it made the most sense to let people do it themselves.

We ended up with the following processes:

• Our standard image had the basic tools: Windows, Office, Anti-virus, Acrobat, a few utilities.
• We provided lots of network disk space: enough so that everything could be stored on the network. About the only exception was in-process video files that had to stay local.
• Staff (in consultation with their supervisors) had two choices: either IT maintained their PC, doing all installs and configuration OR they could have admin access to do it themselves. In either case, all data was backed up on the network.
• If IT maintained the system and it died, we'd put it back to the state it was in, including adding extra software they needed that we'd installed.
• If they had admin access and the system died, we'd have a look and try to fix it, but our commitment was to get them back to the standard image and they'd have to take it from there. If they had any local data, we'd try to get that off first, but our SLA was just to get them a working, standard PC as soon as possible.
• Anyone w/ admin access was required to know how to make sure Windows updates were working, to keep the Anti-virus and anti-malware updated.

We would have liked to put all the people with admin access on an "untrusted" vlan, but we never got to that.