Company computers for competent developers, how can you deal with them?

Separate development and production

It is usual practice to give developers local admin / root rights on their workstation. However, developers should only have access to development environments and never have access to live data. Sys-admins - who do have access to production - should have much more controlled workstations. Ideally, sys-admin workstations should have no Internet access, although that is rare in practice.

A variation I have seen is that developers have a locked-down corporate build, but can do whatever they want within virtual machines. However, this can be annoying for developers, as VMs have reduced performance, and the security benefits are not that great. So it's more common to see developers simply having full access to their own workstation.

So this answer is from the point of a developer. Keep that in mind.

First, not having "local admin" rights on my own machine is a sign that I should look for a job elsewhere. It's nearly impossible to write code, fiddle with stuff, and maintain a toolchain if you have to ask permission every-time you need to update (or test out) a new dependency or tool. So, here are the permission levels I require. Keep in mind I am usually pretty high up on the ladder so to speak.

• Total and complete Admin over my local machine
• Total and complete Admin over all development and testing hardware
• Some level of admin access to the production servers (this gets tricky I don't need or want everything, but I need enough to diagnose and fix problems that occur on production, and enough to actually deploy code (assuming that I'm the one that has to oversee code deployment). Usually this level of access evolves over time, but starts with log files.

Less then that, and you can go find a new developer.

That said, there is a lot of risk involved with that level of access. So what I normally recommend is a separate network. Put all the dev "stuff" in its own network. Its own AD, its own file hosting, its own everything, and never let it talk to the production network. (But do let it get out to the internet)

Yes this means duplicate hardware (or VPSs) but you need that anyway for testing. Yes it means a little bit more overhead when upgrading or administrating, but again, it's needed for testing. You also need a place to see "What happens to X software if I upgrade the AD server?" Look at that you have an entire network of test machines ready for that kind of test.

What I have successfully implemented (with the help of a good IT team) is a separate VLAN for all dev "stuff" and a single VPS host that dev has full access to, to do with what ever it wants. On that host is an AD server that is setup by IT to look like a smaller version of the companies AD server. Then a set of documents and guidelines for what a, for example, webserver should run. What a DNS server should run, what a xyz server should run. Then, part of "development" is to install and configure those VPSs for our use. Everything on that VLAN is totally isolated from production, and considered external to the company. Finally a set of "punch throughs" are created for assets that we did need access to (like email). Normally this was handled as if we were external, and the list of these tools were very small.

From a developer's point of view:

Your job is to prevent change (known bugs and vulnerabilities are better than unknown, right?), but mine is to change things. This puts us at an impasse. My job is to create/change things. If your policy prevents that, then, like any other obstacle, a part of my job is finding a way around that.

Which do you think is more of a danger, a developer that you've granted access to the things he needs to do his job, or one who has obtained that access by learning how to circumvent all of your defensive measures? And why is your company paying you and your developers to fight this war against each other when you should be working together?

The simple answer is, give developers access to what they need to do their jobs. And talk with them. There may be rare conditions (clean room reverse-engineering with major legal consequences, or handling top-secret classified government data) where you need a more complicated policy. But for the most part, it's not that big of a deal. If you start a war and make your developers enemies, they will either leave or become much more dangerous than if you work with them.

Sensible measures include not allowing production database dumps on dev laptops (only testing databases with bogus data). That way, if the laptop gets stolen, no confidential data lost. But if the dev needs to debug things, they still need access to copies of the production database somewhere in a controlled environment.

Restricting internet access is ridiculous. You might as well require all of your developers to write their code on paper with a feather quill and ink.

Talk to your developers, find a way to give them what they need to do their jobs while maintaining the security that you need to keep the important data secure. The details will depend on your company and what data you're dealing with. But it isn't likely to need draconian measures.