QotW #29: Risks of giving developers admin rights to their own PCs

2012-06-08 by . 3 comments

Post to Twitter

Carolinegordon asked Question of the Week number 29 to try and understand what risks are posed by giving developers admin rights to their machines, as it is something many developers expect in order to be able to use their machines effectively, but that security or IT may deny based on company policy.

Interestingly, for a question asked on a security site, the highest voted answers all agree that developers should be given admin rights:

alanbarber listed two very good points – developer toolsets are frequently updated, so the IT load for implementing updates can be high, and debugging tools may need admin rights. His third point, that developers are more security conscious, I’m not so sure about. I tend to think developers are just like other people – some are good at security, some are bad.

Bruno answered along similar lines, but also added the human aspect in two important areas. Giving developers and sysadmins can lead to a divide, and a them-and-us culture, which may impact productivity. Additionally, as developers tend to be skilled in their particular platform, you run the risk of them getting around your controls anyway – which could open up wider risks.

DKNUCKLES made some strong points on what could happen if developers have admin rights:

  • Violation of security practices – especially the usual rule of least privilege
  • Legal violations – you may be liable if you don’t protect code/data appropriately (a grey area at best here, but worth thinking about)
  • Installation of malware – deliberately or accidentally

wrb posted a short answer, but with an important key concept:

The development environment is always isolated from the main network. It is IT’s job to make sure you provide them with what ever setup they need while making sure nothing in the dev environment can harm the main network. Plan ahead and work with management to buy the equipment/software you need to accomplish this.

Todd Dill has a viewpoint which I see a lot in the regulated industries I work in most often – there could be a regulatory requirement which specifies the separation between developers and administrator access. Admittedly this is usually managed by strongly segregating Development, Testing, Staging and Live environments, as at the end of the day there is a business requirement that developers can do their job and deliver application code that works in the timelines required.

Daniel Azuelos came at it with a very practical approach, which is to ask what the difference in risk is between the two scenarios. As these developers are expected to be skilled, and have physical access to their computers, they could in theory run whatever applications they want to, so taking the view that preventing admin access protects from the “evil inside” is a false risk reduction.

This question also generated a large number of highly rated comments, some of which may be more tongue in cheek than others:

The biggest risk is that the developers would actually be able to get some work done. Explain them that the biggest security risk to their network is an angry developer …or just let them learn that the hard way. It should be noted that access to machine hardware is the same as granting admin rights in security terms. A smart malicious agent can easily transform one into the other. If you can attach a debugger to a process you don’t own, you can make that process do anything you want. So debugging rights = admin

My summary of the various points:

While segregating and limiting access is a good security tenet, practicality must rule – developers need to have the functionality to produce applications and code to support the business, and often have the skills to get around permissions, so why not accept that they need admin rights to the development environment, but restrict them elsewhere.

This is an excellent question, as it not only generated interest from people on both sides of the argument, but they produced well thought out answers which helped the questioner and are of value to others who find themselves in the same boat.

Liked this question of the week? Interested in reading it or adding an answer? See the question in full. Have questions of a security nature of your own? Security expert and want to help others? Come and join us at security.stackexchange.com.

3 Comments

Subscribe to comments with RSS.

  • Iszi says:

    Good QotW post, but I still can’t say I agree with the conclusion.

    Maybe I just don’t understand the work environment of software developers enough, but it would seem to me (as @wrb looks to have touched on in an answer) that Dev environments should be separated enough from Production that Devs don’t really need Admin rights on their “office” workstations.

    Then again, it was never really clarified in the question whether the asker was inquiring about development workstations or office workstations – or if the two are even separate in their company’s environment.

    • scottpack says:

      Good distinction to bring up. I read this assuming that the developers had entirely separate systems on which to do their development. I suspect Rory was in the same boat.

      I’m of the opinion that the conversation is entirely different depending on which system is actually being discussed.

    • roryalsop says:

      This is an essential distinction: in an ideal world, developers could use specific machines in a Dev environment to do all the development ‘stuff’, and their office machines to do office ‘stuff’

      I’m not sure how often that happens though, I know one of the big gripes is that developers just want to do their job without hindrances – I wonder if having to switch machines would be exactly that. I know in most enterprise organisations I know, the developers have their machine, and it does everything they need, both office and Dev. Some are ahead of the curve and just allow a terminal instance into a machine on the Dev environment, which seems better.

  • Leave a comment

    Log in
    with Stack Exchange
    or