Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

I need to convince my internal IT department to give my new team of developers admin rights to our own PCs. They seem to think this will create some security risk to the network. Can anyone explain why this would be? What are the risks? What do IT departments usually set up for developers who need ability to install software on their PCs.

This question was IT Security Question of the Week.
Read the June 8, 2012 blog entry for more details or submit your own Question of the Week.

share|improve this question
7  
Something seems missing from this question: what kind of software are they expected to develop? Web application? Graphics drivers? (Knowing the language/platform may help.) –  Bruno May 15 '12 at 15:33
35  
The biggest risk is that the developers would actually be able to get some work done. –  Dunk May 15 '12 at 19:36
13  
Explain them that the biggest security risk to their network is an angry developer ...or just let them learn that the hard way. –  Sandman4 May 15 '12 at 20:11
4  
"I need to convince my internal software development department to give my sysadmins rights to write and deploy their own scripts. They seem to think this will create unmaintainable spaghetti code." –  Nathan Long May 15 '12 at 21:06
9  
Put it this way: either give developers admin rights, or developers will get admin rights by their own means. –  Sonic42 May 16 '12 at 12:55
show 3 more comments

9 Answers

up vote 47 down vote accepted

At every place I have worked (as a contract developer) developers are given local admin rights on their desktops.

The reasons are:

1) Developers toolsets are often updated very regularly. Graphics libraries, code helpers, visual studio updates; they end up having updates coming out almost weekly that need to be installed. Desktop support usually gets very tired of getting 20 tickets every week to go install updated software on all the dev machines so they just give the devs admin rights to do it themselves.

2) Debugging / Testing tools sometimes need admin rights to be able to function. No admin access means developers can’t do their job of debugging code. Managers don't like that.

3) Developer tend to be more security conscious and so are less likely to run/install dangerous malware. Obviously, it still happens but all in all developers can usually be trusted to have higher level access to be able to do their work.

share|improve this answer
3  
Local admin rights don't/shouldn't affect their network rights either. You've just given them access to their network endpoint, which they have physical access to anyways. –  pdubs May 15 '12 at 16:13
8  
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. –  Roy Tinker May 15 '12 at 16:27
5  
@DanNeely: 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. –  Jay Bazuzi May 16 '12 at 5:55
3  
I need to learn about how local admin rights can be given without giving network rights, our IT admin people tell me it can't be done. Any pointers to where I can read up on this appreciated. –  carolineggordon May 16 '12 at 10:28
4  
@carolineggordon, if they're concerned about network sniffing, maybe there's a wider issue here. Essentially, that would imply that sensitive data may go on the network, where normal workstations are plugged in, and where some employees cannot be trusted. Maybe that's the problem that should be fixed instead: make users use SSL/TLS-protected services for sensitive data instead. There will otherwise always be a (possibly small) risk of someone plugging in their own capturing device. –  Bruno May 16 '12 at 11:31
show 6 more comments

You have a few questions to answer.

  1. What applications do these developers need to use daily require admin privilages and is there any way to setup these applications so thats no the case?
  2. What reasons do these developers need admin privilages in order to do trivial daily tasks and is there a way to avoid this?
  3. Are these developer machines connected to the internet?

The question should not be what are the risks, the question should be (which you can only answer) what are the reasons the developers even need to have an admin account. You can them up with a "power user" account and give them the ability to do exactly what they need but also limit their ability to do harm to your network.

If these machines are connected to the internet....then you will introduce a large amount of risk because of their ability to run anything and install anything on these machines. These developers are well developers, they are not security experts, it's only a question of WHEN they will make a mistake that exposes the network to malware.

Take a look at Google for instance. A Google employee click on a link contained in a MSN Messenger window, downloaded malware that took advantage of an exploit that had already been fixed by Microsoft, and infected the entire network.

I should add the Google employee clicking on the link had nothing to do with this question, it was to point out, people WILL make a mistake so limit your exposer.

share|improve this answer
add comment

You give them Local admin rights to their workstation and anything else they want. 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.

share|improve this answer
add comment

A workaround is to install a virtual machine, not connected to the domain. It will be quite a hassle but it's better than being totally crippled by policies.

share|improve this answer
add comment

carolineggordon:

You mentioned you wanted to give the end user local admin rights, if you are running a windows machine and it has been joined to the domain, then you simply have go to the user accounts section in the control panel on the users computer you want to make the change to.

Search out the user account and make it part of the Administrator group, if it is not there yet, then the user profile is running off a default domain policy. If that is the case then click on the "add user" button or perhaps its just "add" in any event you will be able enter the username you wish to give rights to or resolve the domain user name in that text field. The next step is to make that user an Administrator by placing them in to that security group. This will only make them the admin for that machine you are working on and not the domain. Or you could use the command that someone else had mentioned I just thought I would give you the GUI option if you were more comfortable with that.

share|improve this answer
    
I'm not able to add users so I can't do that. Likewise the command line option doesn't work. I believe this is all because an admin user needs to do these things. –  carolineggordon May 18 '12 at 4:57
add comment

Risk is an increasing function of access

There is a simple rule of risk computation which explains the fear of your colleagues of the IT team. The more access you have on any operating system the higher are the impacts of any error or attack.
For example, if one of your colleague, lets say Bob, is attacked through a standard phishing attack, then Bob account is available to cyber-criminal and sold on the Internet within minutes. If Bob account has admin priviledges then this account will be used to send SPAM at a large scale on the Internet, then to steal other accounts with phishing attacks at a large scale, and very quickly (within minutes) will open a back door to your network (this is possible because the Bob account is an admin one) permitting a total remote control of Bob's PC (through tools as ssh, VNC, VPN...). This attack initiated from an internal PC, from a privileged account is able to break any firewall, stop any anti-virus, anti-spam protection.

The evil is inside.

Even your best network admins, system admins or security admins may leave this corrupted PC undected for months (cf. Stuxnet).

False risk reduction

If your developper colleagues are good at managing the OS on which they works, and have a physical access to the computer, then this difference in risk is null.

Any engineer on any OS
can grant himself admin access
if he has a physical access to the computer.

Blocking the admin access on any OS is a valid risk reduction approach for users who are unable to make a difference between admin privileges and normal user privileges. Here is the key question I would ask to your developper team colleagues and act upon their awareness of risk:

"What will you take care of if you are granted
admin privilege on your OS?"

If they are good enough to be risk aware, then they are good enough to get the access they want. Then there is no risk reduction in refusing them this admin access. Beware: there is a collateral risk for your company as a whole if you refuse them an access they can easily get: they will do it the dirty way, they will behave as outlaw, they won't be able to ask any help, they'll have to cover any mishap.

share|improve this answer
add comment

A few things that have not been mentioned in previous answers and comments that would be an argument for developers working under least privilege:

  1. Depending on the industry in which you are working, there may be legal or regulatory reasons that restrict employees from having elevated privileges on their workstations. Allowing administrative access to developers could put the organization at risk of being out of compliance.

  2. When components are developed with elevated privileges, there could be a risk of failure during deployment to other environments that do not have those privileges. Developers may have inadvertently upgraded or added libraries to their local machines that do not exist in other environments, and the components may have dependencies on specific versions of those libraries. Also user accounts under which the components will run in other environments may not have the required database or other access that was assumed by the developer working with elevated privileges. I have seen this happen many times in the past. Sometimes its obvious why the deployment failed, sometimes its not, and you have to roll everything back until you can figure it out.

  3. If developers install open source tools or libraries and use those for development, there could be unintentional license restrictions on how the software they produce is eventually distributed, particularly where "copyleft" terms are part of the license. There is nothing wrong with using open source tools or libraries, it just should be intentional. You don't want to find out upon delivery that you now need to release all of your source code back into the community because your developers used some open source component that had strict copyleft terms in the license that they didn't really read before they installed it.

Something I have seen done is to have the developers work under least privilege, but allow them request elevated privileges for a specified period of time. Then, this "fire call" request for elevated privileges it recorded and monitored, and is reset automatically at the end of the requested time.

share|improve this answer
    
Point 1 is tricky. I've seen organisations trying to restrict the usage to approved software, but it's of course virtually impossible to audit software during its development. Point 2 is just good dev/testing practice, it doesn't have much to do with the security of the devs workstation itself. Point 3 is just normal dev practice too, this has nothing to do with open/close source: any soft or lib used will have a licence that should be respected, devs always have to check, whether-or-not they have admin rights. (Note that very few OSS tools imply that what they're used for must be OSS.) –  Bruno May 16 '12 at 11:39
    
2. Should be handled by a continuous integration server –  Brendan Long Jun 27 '12 at 17:28
add comment

This partly depends on the kind of software the dev team is expected to develop. Some types of software are easier to develop without administrative rights than others.

For example, you can do a fair amount of web-based Java development using the likes of Eclipse with Maven artifacts, all installed locally (and typically tested on port 8080), without needing much admin rights (you may need to open certain ports). Developing tools that need closer access to hardware may prove impossible without admin rights. This being said, even for web development, it's good practice to be able to re-build a test machine from scratch (typically a VM), which may need admin rights.

If this is about trust (i.e. some members of your dev team could have malicious intents), you're in trouble anyway. It's unlikely that the sysadmins who would approve/disapprove certain rights will be able to check what the code they've written does in details. That doesn't mean either that you should give your dev team unrestricted access to your production services, nor that they should have admin access on more machines than they need, of course. It's good to have mechanisms in place to mitigate risks, but you'll need some basic level of trust for your organisation to function. Putting the dev team on a separate physical network is a first step to mitigate trust issues and possible mistakes.

A typical risk by having someone with admin access is to be able to capture packets on the network. This is a risk that you may have to accept depending on the nature of what's developed. Tools like Wireshark can be useful for development sometimes. Even within your organisation, IT or non-IT people should use services with SSL/TLS enabled if possible, this should help against eavesdropping and MITM attacks.

I can think of a few downsides when not giving devs admin access (unless they really don't need it):

  • It may create a "them v.s. us" culture between devs and sysadmins in your organisation. This already exists in many places, but it's generally not a good thing. Each team is likely to consider the other one as a pain. Security is not a purely technical problem, but a human interaction one too. I think good human communication should help the overall goals of your organisation in general, not just from a security point of view in fact. (I've always found to be able to find better solutions after talking in person to the sysadmins with whom I needed to solve problems rather than replying to a faceless ticket.)

  • Human nature is such that people get creative when limited, but not necessarily in the right way. You may find that the devs end up putting a fair amount of effort (and often succeeding) in circumventing the limitations imposed upon them within the organisation. They should use their creativity on what they're meant to do instead.

  • IT systems are complex and debugging is a dark art. If you need to debug your product against library XYZ version a.b.c_13 and a.b.c_24, the developers may need to be able to install and uninstall each version, which may in turn require admin access. Chasing bugs that depend on version numbers is already annoying as it is. If you have to raise a ticket and wait (perhaps hours or days) for someone else to install/uninstall the right version will make it a nightmare: it will increase the "them v.s. us" cultural problem and, more importantly, it will cost more to the organisation. You can think of this from a risk/cost assessment perspective.

share|improve this answer
1  
The most important reason NOT to give a programmer admin rights is the fact they will make the same mistake people have made for years, not test their code as a limited user, because in the current version of windows there are protected folders. –  Ramhound May 16 '12 at 11:19
5  
@Ramhound, that's not so much a security issue but a bad dev practice. Having admin rights doesn't mean that you have to run everything with full privileges at all times, even as a developer. –  Bruno May 16 '12 at 11:43
1  
@Ramhound - That's why you have separate QA team with a written test plan. It's not an excuse for hogtying your devs for the sake of IT empire building. –  Jim In Texas May 17 '12 at 3:26
add comment

The security risks associated with providing developers the ability to install their computers are numerous. Here's why I would object (speaking as a sys admin)

1) Potential violation of best security practices - One of the 8 rules of security is the rule of least privilege - only give employees access to what they need to complete their task. If someone told me that their dev's needed admin access to install software to do their work then I would reply with "Why can't one of my staff install it for them?". Having a centralized point for installing software ensures that an IT department knows exactly what software is on what machine.

2) Legal Reasons - Perhaps one of your dev's has less than admirable ethics and decides to install pirated software. Not only is that software probably riddled with malware, but you then open up can of worms for litigation should you be caught with pirated software on your computer. An IT department is considered responsible for those computers and, as such they are responsible for auditing them and ensuring that the licensing is in compliance with the TOS of each piece of software. While it's convenient for the dev's in that they can install their own software and not bother the IT department, you create a lot more work for the IT department.

3) Unintentional installation of Malware - mentioned before, but this could be innocent enough. Elevating user privileges so that they can install malware leaves them susceptible to malware by opening an infected PDF they got via an e-mail, or a drive by download. Limiting user access so they can't install software will help mitigate the threat of malware.

4) Malicious activity - Similar to point 2, but what's to say that one of your dev's isn't going to install a back door or purposely open up another security threat on your network. You'd be surprised how many IT professionals do this to exact revenge should they be terminated or their boss pisses them off.

All in all, I would have to advise against it. While people may argue it would save time in preventing them from always bugging IT to install software, I would counter that with "it takes less time to do that than it does to patch up security holes created by allowing users to install their own software". If it's deemed that this IS necessary, they should really be put on a network that doesn't have direct access to the outside world.

share|improve this answer
12  
Pretty much all of these can be done without admin privs. A lot of software does not require admin privs to install. The only way to prevent most of these is having a software whitelist, but that's obviously impossible for devs. –  CodesInChaos May 15 '12 at 13:21
6  
"8 rules of security"? There's only 8? –  Iszi May 15 '12 at 13:54
10  
1, 2 and 3 are all true, however attaching a debugger to a process running as another user requires local admin. Visual Studio 2005 recommends always running it as an admin. Installing windows services requires admin. These are all things that I as a developer have to do, some more often than others, which means that local admin is a permission that I require to do my job. For point 4 I'd say that the dev has physical access to the workstation, so if they were malicious they could get admin rights, unless the PC is locked shut. –  pipTheGeek May 15 '12 at 16:41
15  
I would downvote this answer if I could. I do not see how these problems cannot be solved with good communication with the developers. If you do not trust one deveper to fullfil the requirements you mentioned, then it would be better not to hire him/her on the first place. I think that restricting admin priviledges to (untrusted?) advanced users that have complete access to their hardware is naive, to say the least. –  yms May 15 '12 at 17:21
5  
Besides the points that PipTheGeek made, almost all developers have their private set of helper tools that they use in order to be more productive on the job (hotkeys, luanchers, snippet-orgenizers, code generators, grep, Notepad++, etc...) Besides they use sysinternals-tools like process explorer to kill hanging processes. They also need access to eventlogs and other MMC-snap-ins, and use tools like regsvr32.exe to register their COM stuff... the list goes on and on... I cannot imagine doing my job without being at least local admin. Rather kick me off domain, only providing internet access. –  Louis Somers May 26 '12 at 23:22
show 8 more comments

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.