Category Archives: corporate-policy

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

Posted on by

This is a follow up on Is there a legitimate reason I should be required to use my company’s computer. Mostly, because I see a huge issue in a couple of specific situations.

Had I been in a position of the security engineer for an organization I would definitely put a policy that only company computers shall be used. That does make sense, and protects not only company data but the liability of employees.

Yet, there is one case in which such a policy bugs me: A competent developer (I’m not talking about a junior developer, I’m talking about a middle to senior level developer) will potentially have on his work machine:

  • 17 database engines;
  • 20 docker containers;
  • 10 test virtual machines (let’s say using something like qemu).

That is a very common scenario in startups and post-startups (a startup that managed to survive several years). Moreover, this developer will be changing his docker containers and virtual machines every week, since he will probably be testing new technology.

Requiring this developer to refer to the security engineer to install new software every time is completely impractical. Moreover, since a company would have more than one such developer, going with the typical company managed computers for everyone involves drawbacks:

  • Maintaining the computers of, say, six such developers is a full time job for a competent security engineer.
  • The manager of those developers will be terribly angry because what his team is doing for 50% of their work-time is to wait for the security engineer.

On the other hand allowing the developers to use the machines freely is dangerous: one rogue docker container or virtual machine and you have an insider. I would even say that these developer’s computers are more dangerous than that of a common user (say, a manager with spreadsheet software).

How do you make sensible policies for competent developers?

Here are some other solutions I could think of (or saw in the past), most of which were pretty bad:

  1. Disallow internet access from the development machines:

    • You need internet access to read documentation;
    • You need to access repositories, often found on the internet.

  2. Give developers two computers, one for internet and one for development machines:

    • Complaints about lost productivity: typing Alt+2 to get the browser is faster than switching to another computer;
    • Repository access is cumbersome: download in one place, copy to the other.
    • Encourages the developer to circumvent the security and make a USB-based connection between both machines, so he can work from a single computer (saw it happening more than once).

  3. Move development to the servers (i.e. not development on desk machines):

    • This is just moving the same problem deeper, now the rogue container is on the server;
    • Arguably worse than allowing the developer to do what he pleases on his own machine.

There must be a better way.

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