Posts tagged Security

Developers and Local Admin, productivity lost in 60 seconds

Recently at a company I work for they started rolling our new Windows 8 boxes to the developers, sans local administration authority for the developer on the box. This of course is for the safety and security of the organization as a whole, what if the developer downloads a virus or other malicious software.

Lock-iconThe fact that this is still happening to developers in 2015 amazes me. Developers and IT should be a force for good in side a company but too many times I see these absurd lines drawn in the sand that just create a “us verses them” mentality, inhibit productivity, cause numerous issues and just overall create increased stress and friction for no good reason.

Let me be clear this isn’t domain admin rights, elevated rights to servers or infrastructure, just local administration rights on the developers computer. The days of developers, and frankly any IT worker, running around with domain admin/su/sa all the time for their primary account are long, long gone.

So why should you give your developers local admin rights on their development workstations, well here are my reasons.

  1. Drivers, Software, Tools, Environments and more almost all require admin permissions to install. Developers almost always have to install tools in a ad-hoc fashion. I recently needed to look inside a compiled .Net DLL to ensure it matched the emit of a build process. This required me to install Telerik’s JustDecompile to do this. Without local admin I couldn’t do this on the fly and the delay could have halted a production deployment. The toolset developers need today, will be different tomorrow, the world we work in advances too fast.
  2. Debugging is a dark art, not cut and dry. This is the most difficult thing to explain to non-developers and the business. Debugging is as much as on feel, trial and error or random chance as it is on pure knowledge or process. We’ve all been at the end of our ropes debugging an issue, tried something random and that lead to the discovery of the issue. A lot of debugging, like when attaching to other processes (i.e. IIS worker processes) requires elevation. I currently work on mobile applications, which means I use Fiddler to debug network traffic between a mobile device and our service stack. Can’t install Fiddler without local admin.
  3. Configuration Changes, Process\System Changes and Testing. We’ve all changed system settings to try and figure out an issue, for example giving ‘Everyone’ write access to a temp folder to ensure a log file get created, or trying to figure out other permission issues. I’ve changed IIS Settings/Modified Registry keys, etc. It’s impossible to properly convey all the things you may possibly need to do to get things to work or get around an issue.
  4. Every developer is different. Oh boy is every developer different. Developers are not factory workers or even IT workers, what we do is so very creative and tied to flow and proper mindset. To create an environment conductive to being creative it needs to feel like your space. That includes your system and hows it’s setup past just the colors of the desktop.
  5. It’s Insulting to most developers. Developers are usually intelligent, technical, skilled, passionate and opinionated. Most take pride in what they produce and how it’s produced. Locking them out of their own local machines or severely hampering won’t go over well, moral will drop, discontent will grow and your output will drop and turnover will increase.
  6. Chances are there is no law or regulations affecting the private sector that can be applied local admin. I’m sure there are some IT guys out there right now screaming “SOX” at their monitors, but no, that doesn’t apply to a developers local workstation. You find me a law or regulation for a private sector company that expressly limits local workstation administrator rights and I’ll buy you a shot of Macallan.
  7. If your worried about those evil developers installing bad software you’ve hired wrong. A developer can cause far, far more damage to your company. There is no control you can put in place that will prevent a developer from completely running a system if they wanted to. If you don’t trust a developer to use local admin properly why would you trust them with your product, or IP?

If there truly is a requirement then find a way that doesn’t involve adding more friction to a developers life. We deal with a lot of performance sapping, flow crippling, joy eating friction in general, to then be chained and inhibited from working to our full capacity is straw that should never end up on our backs, especially when so much rides on what we produce.

Open Source is not inherently more secure

If your not following the Heartbleed issue, it’s an amazing issue that affects a large portion of the Internet’s secure traffic. The gist is that there was a change committed to the main codebase at the end of 2011 that allows an attacker access to the memory of the server. Any secure connection utilizing the OpenSSL project could be affected, from your email, your private computer systems to your bank. Almost every major company has been affected in one way or another.

The OpenSSL project is a pillar of Open Source Software and utilized by almost everyone. Mashable has a great list of companies/services where you should immediately change your password. I believe that it’s been known for some time that there is nothing about OSS that makes it more secure then closed source, but somehow the myth is still out there.


It is true that because the source is available for anyone to see that anyone can catch and fix bugs or security issues. But what a lot of people miss is that there has to be a motivating factor for people to do so. Just because the source is out there there doesn’t mean that it will happen.

Additionally the people maintaining or responsible for the project a lot of times have little motivation to spend more time on finding these issues. In the case of Heartbleed the code was reviewed before it was accepted, someone looked at the code that would 2 years latter send the Internet into a frenzy and accepted it as good.

OpenSSL is a vital project and utilized by a large portion of the Internet, yet it’s run on donations and a shoestring budget. It’s completely maintained by volunteers that have to worry about their real jobs to pay bills, and it’s not their fault for skimming over stuff. The motivational factors are not there as they would be in a full time position, if something like this got missed, someone is getting fired. In an OSS project, “Oh I don’t have to spend all my free time contribution to this thing, oh darn”.

The sad fact is that the people who do have the motivation most of the time are the ones who will profit from the mistake. Think the NSA or hackers looking for ways to steal information. How long have they been actively using this exploit over the last 2 years?

Heartbleed should be a call to arms for companies to contribute more to major open source projects they utilize. A project of OpenSSL’s importance should have a full time staff and should be well supported, I have always tried and contribute to projects I use, I rarely have the time to do anything more then give money, but that’s vital, because it gives motivation. Helping out a project with code, patches and reviews are nice, but major companies need to give money to these projects.

Resgrid will also start donating yearly to open source project we utilize and we want to make it part of our culture of giving back to open source. Resgrid is a cloud service company providing logistics and management tools to first responder organizations like volunteer fire, career fire, EMS, search and rescue, public safety, disaster relief organizations, etc. It was founded in 2012 by myself and Jason Jarrett (staxmanade).

It’s small companies that should start leading the charge, even though we can’t give much we hopefully can start shaming the big companies into giving to OSS projects that help build their products and services.

Sign Your .Net Assemblies, Please!

I can’t tell you how many times I’ve referenced an Open Source .Net project and tried to compile only to be greeted with the “Assembly Generation Failed” compiler error. Some of my absolutely favorite projects StructreMap, NUnit, CommandLine and more never have a problem with this.

But more often then not with some “off the beaten path” OSS .Net projects…


I sign all my .Net projects with a Strong Name Key, first it provides a ‘small’ amount of security to ensure that the assembly hasn’t been tampered with or corrupt. I say small because with about 10 minutes of work you can remove an SNK form a .Net assembly. But if your creating a library that you expect people to use, it should always be signed, why, because you cannot reference a non-signed assembly from a signed project, but you can do the reverse.

So by signing your assembly you make it more usable to those of us who sign our projects, and don’t impact anyone else, seems like a Win-Win to me.

Go to Top