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.
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.
You have a few questions to answer.
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.
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.
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.
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.
Even your best network admins, system admins or security admins
may leave this corrupted PC undected for months (cf.
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.
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:
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.
A few things that have not been mentioned in previous answers and comments that would be an argument for developers working under least privilege:
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.
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):
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.