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.
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.
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.
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).
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.
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 few things that have not been mentioned in previous answers and comments that would be an argument for developers working under least privilege:
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.
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.
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.
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.
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.
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.
