[alex_young]

My personal favorite was:

Company supplies horrible laptop locked down in ways that prevent any real work from being accomplished, but allows unfettered VM use because they don't understand or care about security outside of the environment they designed. Some developers use an underground system of sneaker net and whisper doc hodgepodge to get real work done, but that largely isn't a problem since productivity is measured on a political basis rather than getting anything accomplished.

Thinking you'll improve the situation for you and your group, you obtain permission from management to procure and install a workstation on your desk and replace its OS with Linux. IT drops the machine, you install the OS and enjoy much better productivity for a few months until a security flag is raised in a distant location and you're hauled in for an interview with HR and your boss, who now claims never to have given such approval.

Back to the VM no one cares about. You get a writeup and final warning, and because the economy is going to hell anyway, you stick it out, and things unexpectedly change for the better. Your boss quits, and everyone forgets about the writeup.

Years later, someone decides it's time for a Linux server push. You get tapped for that effort and can now set some policies. Its too late to help much though, since this is 2008 and this company is named Lehman Brothers.

It was fun while it it lasted.

[koheripbal]

Corporate IT security is always a juggling act - and it's not easy.

I think developers assume those choices are made for political reasons "hey, I did something", but in reality we are often countering known mechanisms of infection propagation.

Remember what happened to Sony? So we disabled SMBv1 and PowerShell - devs complain. Then we see someone in accounting installed a fake version of Adobe something - so we prevent software installs in that department. Then a VP forces us to give him a "dev-mode" OS without restriction and subsequently gets a virus that brings down his department. ...so we have to then role those restrictions to everyone.

...and, you're right, we don't pay much attention to devs setting up VMs and tunneling around firewalls, because the vast majority of risks we combat don't use those methods. But once they do, yes, we'll lock them down too. (and VMs are becoming more common in malware space, fyi).

[Redoubts]

Is there any reason policies have to be universal? It seems odd that a one-size-fits-all approach should be entertained at all.

[koheripbal]

There are two important reasons, and one medium reason...

1. These rules are usually distributed via GPO, and the AD system it uses may or may not have a useful and/or well maintained notion of who is a "developer". At best it's done at the departmental level, which isn't that great - since a lot of IT/dev people work in all departments.

2. Whenever you make an exception to a rule that restricts behavior, it's always the worst actors that game that system to get the exception. It's exactly that one VP who thinks he's tech "enough" to handle the risk that'll figure out how to get the exception for himself - he's also the one to run a torrent client to download a free copy of "PDF Writer" or a malicious keylogger.

3. GPOs can be complex to apply - errors happen. The simpler you have your rules, the less likely there is an error that leaves core/critical systems unprotected.

[ryandrake]

I worked for a large multinational company that everyone here has heard of, whose development machine policy was pretty much: Order (through corp) whatever machine you need to get your work done. You have root. Install what you need to work. We hired you because you are a smart, responsible grown-up and we trust you not to fuck up our IT systems. Don't fuck up our IT systems. And amazingly, it works!

[koheripbal]

If the company is in tech and is big enough, they can manage a process like that. Most companies are not multinational tech companies.