Iyfjky

Question

I've just joined a new company of around 100 employees, 15 of which are developers (including myself).

A very frustrating aspect of the job is the IT security policy. As developers we need access to the latest and greatest tools to get the job done - we know what we're doing. However, we are restricted to a version of Windows with administrator passwords required for any small changes. We follow some ISO standard for security, specifically 27001, from what I can gather.

Over the last month I have been here, I have had to ask for a guy from 'IT' to come up and input his password for:

Driver installations for prototypes I have been asked to work on

Any IDE or application updates

Being able to access certain parts of the control panel to change some device settings

Any new installations what-so-ever

USB access for new devices (R&D stuff)

The most important thing to note here is: we all use VMs anyway to get around this! We tend to work on Ubuntu (Linux is awesome for development), or even in a Windows VM to install something that requires admin privileges on the host computer. 8GB ram isn't that much when you're doing VM stuff all the time.

The IT policy is company-wide. It's very bureaucratic, 'red-taped' and making me consider leaving.

How can I put forward a good case for more freedom on the IT security policy for developers? Explicitly meaning complete access to the base OS instead of doing everything through a VM (which we can use to install dodgy applications if we wanted to anyway)?

I solved this problem once by getting someone with admin/root access at the main corporate level to override my access without telling the local folks. Then, I found a new job 3 months later and didn't have to deal with it. If you have some regulatory reasons for these obstacles, you should work with the IT team and find the best way to get around it. That might mean assigning some of your developers to the IT team (but they still do development work). If you can't get around it and people are actually just being difficult to work with, you might appreciate a new place to work if possible. — Nov 7 '14 at 23:36
@Jimbo if you work for a publicly traded company, you almost definitely have SOX-related compliance issues, because these days most every financial statement says something about information/data security or risk and if it's stated in any of the company's financial statements, SOX compliance is an issue. We have so much stupid SOX compliance stuff because our CIO can't stop bragging and shooting off his mouth that it makes my head spin. — Nov 8 '14 at 5:12
I think this is a real question - could anyone who agrees please ro vote? I'd like to postpone choosing an answer until it's open again. — Dec 2 '14 at 14:39
That meta question is deleted. This meta question is discussing this question, though. — Jan 20 '15 at 21:42
An additional note, I switched to another company 8 months later. Having things in the way of doing your job (which you do every single day) just isn't worth it :-) — Sep 2 '15 at 8:50

NotMe 20.9k55695 · Accepted Answer · 2014-11-06 16:51:07Z

I've been there.

In one case a guy who sat next to me received a new computer because his old one simply died. He was able to log into it but couldn't install visual studio. So, he put a work order into IT and they performed the install.

Then, he had to put a work order in so that he could get it hooked up to our version control system. Another work order to have MS Office installed. Yet another one to get access to the sharepoint sites we used (locked down by MAC address). Time spent thus far: 3 weeks.

Once all of that was done... he couldn't debug the web app. VS required admin privileges to run the debugger. He also couldn't configure IIS locally (locked down). He put in two more work orders to fix this. The local admin access one was rejected outright a week later because developers were now prohibited from that. IT did show up and configure IIS...however he didn't have rights to push anything into the website directories so this was useless.

Every day he spoke to his boss about his lack of ability to do any part of his job. Every day that boss spoke to his boss, who would then fire an email to the IT Director. This went on for months. He did bring his own laptop in, but the company had a strict policy against plugging them up to the network.

The sad thing is that the rest of our small project team had local admin access. This guy even had it on his original machine. It was simply a policy put in place by a new IT director, which was approved by the CTO.

The company was a rather large one with close to 1,000 .Net developers. Due to normal turn over, everyone being hired in quickly found that they were unable to do any work. Some stayed determined to wait it out, some left. After around 4 months the IT Director was fired (for something completely unrelated) and his replacement (promoted from within) immediately changed that policy.

As to your specific situation, all you can do is have a nice talk with your manager about the ludicrous nature of the policy while submitting your requests to the appropriate people and then do the best you can. Some people can work in such silly environments; others find that happiness lay elsewhere.

Journeyman Geek 2,1791019 · Answer 2 · 2014-11-06 10:54:48Z

Its probably worth looking at both sides of the issue

"We follow some ISO standard for security, specifically 27001, from what I can gather" These are generally a pain in the ass requiring much box ticking. Your IT department is probably doing what they are supposed to be doing, and getting in their face about it isn't going to help any. In fact, even looking at the wikipedia makes it clear that its pedantic by design, and I thankfully am not reading through the whole thing for an answer.

Spare a thought for the IT guys who actually have to read, understand and implement this!

If you're going to have to ask for changes, consider that the decision is probably made higher up, and possibly by less technical folk. You're probably going to have to work out the right person and way to ask, and its as much a political as much as a technical decision.

One possibility would be to see if you can get an isolated development/test environment, airgapped from the main network (but once again, this depends on your corporate standards.)

Some of these requests may be more feasable than others.

Driver installations for prototypes I have been asked to work on

You can probably make a case for this fairly easily, and this should be done on an isolated test lab system anyway.

Any IDE or application updates

Less likely - you're probably going to have to go through corporate to do this. You might be able to talk a sympathetic IT department into letting you test updates for them before a wider deployment tho

Being able to access certain parts of the control panel to change some device settings

Once again, essential part of your job, and best done on a separate test lab anyway

Any new installations what-so-ever

Nuh huh. NOT happening. Eventually you end up with a lot of ~~tribbles~~ unmanaged anarchic systems, with no central management. You might be able to talk them into letting you have some test systems, but building and deploying your own as needed is unlikely.

In a sense you're going to have to convince management that the changes you need are essential to get things running. You're probably also going to need to handle politics, and compliance, and so on. Its not going to be easy.

I would like to add as a software dev who is also a former network admin for a company who worked for the US DOJ, many of these issues are requirements which cannot be waved. If we want to continue business we have to follow guidelines. Likely running OSs in VMs to facilitate these unauthorized installations is in itself a violation requirements. Yes the beurocracy is REALLY annoying and frustrating, and often gets in the way of productivity, but it is required, and often has reason. That said, ask IT what is the recommended process and adhere to it. If you're stuck, make sure your boss knows. — Nov 7 '14 at 21:32
Having isolated systems is an exelent idea DOD has built entire seperate networks to support it organic engineering efforts on top of its broader IT networks that everyone uses. 15 people supports investing a couple grand into a small computer lab. You don't need IDE updates, plan those for a certain date every month — Nov 8 '14 at 3:23
I'm just throwing away ideas here, but in PCI DSS compliance you just need to keep your devs away from production data and then there's no data to be protected, so devs are free to do what they want with their machines. — Apr 22 '16 at 21:37
It's terrible in order to work like this! I'm suffering this stuff working in a travels company. It's absolutely frustrating wasting time sending E-mails and calling people instead of making code and developing software. The funny thing is that bosses want to see breakhtroughs but it's almost impossible with this pain-ass approach. I think if someone wants to become Senior Security Director or something with Security for a SOFTWARE COMPANY, first of all, He / She OUGHT TO BE A SOFTWARE DEV in the past! He / She would understand the needs of a developer. — Mar 18 '17 at 17:10

BrianH 4,1731323 · Answer 3 · 2014-11-06 15:42:21Z

Having been in this position, I usually just took a moment to have a chat with management/supervisor or senior developers. This shakes out various ways:

1) The Company has a strict policy, IT has to handle all these things - even for developers. They know it's a pain, but they have to have it this way. You'll be asking for a lot of passwords, unless...

2) The Company has a strict policy and can't/won't change, but developers tend to do whatever they want anyway. A senior tech once asked me what I used for a given task, and I told him, and he responded, "You developers...you just can't use the approved program list, can you?" - with a knowing smile.

This is often referred to as "covert" or "black bag" operations, where everyone uses what they want and management knows, and people just don't say anything or particularly care as long as you don't come complaining when something goes wrong (and you don't screw up anything for anyone else). The downside here, by the way, is sometimes political games are played and if anything goes wrong you can get chewed on even if your tools/software/workstation had nothing to do with it - especially if you are junior ("if any of your team is captured or killed the Secretary will disavow all knowledge").

3) The Company has a strict policy...and knows about you pesky developer types, and grants you local admin privileges on your own machines, or even sets up unmanaged virtual machines you can use to run your tools without screwing up their workstations and making them reinstall an image when you inevitably blow the thing up.

We all say we know what we are doing, and we all end up blowing up an OS install at one point or another. "I'm pretty sure manually installing an alpha version of the wrong driver and editing the registry to make the process go faster didn't cause a problem...cough..."

Especially when the company doesn't have a ton of new hires into your department regularly, or if your dev department is just a small edge-case for what IT does in a day, sometimes people just forget how to handle things and they have no checklist for dev installs.

At all non-software companies I've worked the dev tools are not a standard part of any image or install and are handled on a case-by-case basis anyway.

4) The Company has things the way they are for a reason and they do not, or can not, change because you dislike it and it seems unproductive. You end up just having to put up with it, though the good news is usually it dies down once you get everything setup and you rarely need to call for a password anymore.

Sometimes you also get very good at using software that doesn't require admin privileges, or...see #2 above. Sometimes it's just a downside of tough policies, secure infrastructure, bad management, or the nature of bureaucracy...the upside is often that you don't really need to worry about any of it and when the next big security vulnerability pops up and it's revealed the NSA is actually The Missing Butler (gasp!), it's not your problem. You just do your job, or have a visiting hour while IT scrambles to patch and reboot all workstations, secure in the knowledge that it's "Not My Problem". This may or may not suite your style of work and personality, but different environments for different folk!

Thanks for your insight Brian, it's helped in realising some of the downsides of what I've been talking about. — Nov 6 '14 at 15:57

score 10 · Answer 4 · 2014-11-06 13:26:39Z

One thing to consider is that you are new to the job so you need more stuff to install or set up than your colleagues. It may be that over time as your dev environment stabilizes, you will have less such issues. This may be one reason why your colleagues are more willing to accept the status quo.

If this is not the case, the basic question is, why security policy is defined so. Does your company have special security requirements, like a bank, or an organization dealing with classified or sensitive (personal) information? In this case they aren't likely to change their security policy for a relative minority of their employees. Still it may be worth a try, but make sure you do it in a way which doesn't harm your reputation and future career prospects.

So instead of telling about your personal frustration, focus on the business aspect of the problem. Being blocked in your work costs hard money to the company. Can you quantify how many hours you (and your dev colleagues) have been held up on average per week / month by these regulations? That gives management an estimation of lost productivity, which can be monetized if multiplied by the average hourly cost of a developer. If this gives a high enough figure, management may take notice and act on it.

Another useful measure you can get from the IT support staff by asking them how many and how severe security incidents they had to deal with last year, and how many of these were caused by developers. This might give a justification to the claim that you developers "know what you are doing".

If these figures convince management to at least think about a change, make sure that

both management and IT support are involved in finding a solution, and

instead of demanding "more freedom", ask an open ended question like "how can we improve the productivity and reduce the frustration of our IT staff¹ without compromising security?"

_{1 as @Journeyman pointed out, these rules are probably even more tedious and frustrating to the IT support guys than for you developers.}

+1 for the recommendation to translate the "frustration" into figures that management can understand (i.e. money) — Nov 6 '14 at 13:14
One thing to consider is that you are new to the job so you need more stuff to install or set up than your colleagues. Don't most companies use standardized clones/images for that very reason? — Nov 6 '14 at 13:37
@JuhaUntinen, I 've never been at a workplace where the standardized image contained any developer tools. These can be different from team to team and project to project so need to be set up and configured manually. — Nov 6 '14 at 14:00
I've worked as a dev in an environment that regularly handled classified information (we all had at least Secret and many/most had Top Secret clearances.) Even there, most of the devs had full admin accounts. Those accounts got disabled at the end of the workday and had to be reactivated in the morning by calling base network control, but we had them nonetheless. In fact, these accounts had, not just local admin rights, but at least some admin rights to most of the workstations on the unclassified network. — Nov 6 '14 at 20:19
+1 from this sysadmin type: quite a few of us have been there from the other side and been just as frustrated as the devs, but the business itself gets what it deserves when it makes rules like this. Make this a business case, not a personal vendetta against the IT people who have to enforce it, or even the individual manager who mandated it in the first place. — Nov 7 '14 at 14:40

score 10 · Answer 5 · 2014-11-07 16:21:22Z

If you do decide to ask/push for an exception to security policies, you should be aware of the very likely possibility, suggested by the very fact that you're asking, that you are one of the people the policy is for, not someone special who should be exempt from it. What guarantee do you have that the drivers, tools, etc. you're downloading and installing are non-malicious? They very well could contain code designed to impede or slow down your company's operations, leak private information and trade secrets, etc.

If they do turn out to be malicious, what kind of audit trail are you keeping to determine where the malicious code was introduced? Was it original in the version of the driver/tool provided by the vendor? Was it injected via a MITM attack? Internal or external to your organization? Was it just a virus you picked up carrying the software around on your personal USB stick? Etc.

Taking care of all of these concerns is the job of an IT security department/policy, which is in place because the company wants to be able to hire people (like you) who are qualified in their own field (development) but who are either unqualified, or unable to dedicate half of their time, to rigorous attention to security.

If you still do want to go for it, you should make an effort to understand why these issues matter and convey that understanding to the decision makers you need to convince. You should also be prepared to do the kind of record keeping work that the IT department would be doing if you weren't going around them.

Oh, he's definitely one of the people who the policy is for. He is doing dangerous things like installing drivers. The point is, it his job to do dangerous things, and the reason for the policy is to stop dangerous things. That is why those who understand the job also understand that the policy is bollocks. The policy is directly intended to stop an employee from doing his job. So it is only reasonable to question why such a malicious policy exists. Is that incompetence in the IT department, or is it intentional? Either does not reflect well. — Oct 11 '16 at 8:32

reirab 949717 · Answer 6 · 2014-11-06 21:00:39Z

Perhaps one option would be to start documenting all of the situations that you run into where lack of admin rights is preventing you from getting your job done and/or is wasting both your time and IT's time. After collecting data for a while, send it to whatever part of the company is responsible for making these policy decisions along with an explanation of how, while you can understand the need for these policies on most of the workstations in the company, it is both unneeded and extremely detrimental to productivity when applied to the software engineers. And, of course, be polite about it. Also, if it's such a significant burden that you and/or other devs really are considering leaving over it, it might be a good idea to at least mention that the current policy is a big problem for morale on the dev team. I wouldn't advise explicitly threatening to leave over it, though. If they don't take the hint and you do decide it's worth leaving over, mention that in your exit interview as you leave and explain to them that they're likely to lose more talented/valuable devs if they don't change their policy, but I wouldn't recommend explicitly mentioning the possibility of leaving over it until you've already decided to do so and are on the way out.

Of course, a more passive-aggressive approach that could perhaps be tried if the approach above fails would be to go ahead and call IT whenever you need admin rights to do something. Once they start to understand the frequency at which you have legitimate needs for admin access and when they start to understand that they practically have an IT staff member whose full-time job is typing in his password for you, they might start to get the point that you need admin rights. As I said, though, I wouldn't recommend this approach unless you've tried more diplomatic options first. This approach could be particularly useful if the IT department that you would be bugging have been supporting the existing policy of not letting you have local admin.

It is not unusual, even in high-security environments, for the developer groups to be exceptions to the standard security policies because developers usually know enough not to install untrustworthy junk and because developers usually need admin access to their box regularly to get their job done. Of course, this is not to say the devs should be domain administrators for the whole company or shouldn't have to follow procedures designed to protect sensitive information and systems, but developers having admin rights on their own systems is not abnormal. Unfortunately, those in IT that don't have experience in development environments, especially in a new company that hasn't had a dev team very long, don't always fully grasp how necessary admin rights are to your job. It will be up to you and the other devs to help them see the light, but, as with all business situations, you need to be respectful about it to the maximum extent possible.

I guess I fall in the passive-aggressive category by your definition. I have no qualms about asking for the things I need to do my job efficiently. If the IT position is that they won't give me admin rights even after explaining the problem then they'll get a IT Assist every 2 to 15 minutes when I recompile my program and try to run it when it needs admin rights to run. Surprising how fast admin rights are granted once IT realizes how you really do need admin rights to do your job. — Nov 7 '14 at 15:25
@Dunk Agreed. As long as you've tried more diplomatic options (which you apparently have) first and it's the IT staff that won't give you permissions, that's a very effective way to get them to realize how much you need local admin. — Nov 7 '14 at 15:35
Maybe throw in some cost estimates. Look up how much you cost to your company by the hour. Estimate the number of hours per week lost waiting for an admin to do whatever needs to be done as admin. Include the cost of focusing - swapping in and out of the zone. — Oct 15 '16 at 0:07

Joe 8,0322046 · Answer 7 · 2014-11-06 22:18:40Z

up vote
7
down vote

One possible compromise is having separate, privileged accounts specifically for giving you higher access (to servers, to your local machine, whatever) that you can't log into interactively, but have admin privileges, so you can type your own password in.

This allows your IT to feel more secure knowing that a rogue program that you accidentally download and gets your privileges can't install itself or wreak havoc on other systems, but you still can install your own driver updates.

They may still not be willing to allow this, if the real reason for the policy is avoiding you installing whatever you feel like - and you may just have to accept that. But, this may be a suitable compromise if security is the driving factor.

answered Nov 6 '14 at 22:18

Joe

8,0322046

1

To be honest, I think this is the way to go - and for IT/Ops as well as dev. There's no need to be logged in as admin to read email, update helpdesk/bug trackers or read the daily WTF.
â€“Â Rob Moir
Nov 7 '14 at 14:33

If you're using recent versions of Windows (Vista and up,) this is how it works by default, even if you do have an Administrator account. Your processes aren't actually running with admin rights unless you explicitly elevate them. However, rather than having to type a password, you just have to click 'Allow.' Being on the sudoers list on a *Nix box has a similar affect.
â€“Â reirab
Jan 14 '15 at 18:51

@reirab I think you at least partially miss the point here. The point is to not have administrative privileges on the primary account, but to have a separate privileged account. This is useful for security reasons, because something like clicking a malware link that causes a program to be installed wouldn't work in that case (since the separate privileged account isn't logged in - often they're explicitly disallowed from logging in interactively).
â€“Â Joe
Jan 14 '15 at 19:52

@Joe Which is exactly the result of logging in using an account that requires elevation... It's a less inconvenient way of accomplishing the same purpose (assuming, of course, that you don't elevate your browser. haha)
â€“Â reirab
Jan 14 '15 at 19:54

I don't think I can explain sufficiently in comments why this is a different concept, but from my experience in IT it is most certainly - and given every company I've worked for utilizes this concept (separate privileged accounts), I don't think I'm wrong.
â€“Â Joe
Jan 14 '15 at 19:56

Â |Â
show 2 more comments

SJuan76 2,247913 · Answer 8 · 2014-11-06 23:31:48Z

One word: MONEY

Many times, the issue comes from disconnected responsabilities. The IT admins (and especially, if you have some "Head of Security" position) are charged with defending the enterprise from risks, so they see risks everywhere. For example, they see that if they allow unrestricted web access someone could download malware, cause $$$ of damage and they would be blamed for it. They do not see that undiscriminate filtering may also forbid access to sites needed, possibly causing a slowdown in the business an a loss of $$$$ (and even if they see it, they are sure that those $$$ will not come from their budget).

At the opposite, developers want free reign to install software. Hey, even admin rights for end users, so this way if some third party software is needed, the developer itself may install it through a script. That would make development way faster and save $$$ for the company, would not it? And, well, if somebody introduced a virus the issue would be solved with $$$$ and hours from the IT budget, not ours...

If you say up the chain of command that you are having trouble with the IT policies, maybe they will ask the IT manager about that. The IT manager will just answer that the IT policies are "for safety reasons", and the upper management will not know anything new.

Instead of that, report how many hours you estimate that each developer is wasting each week. Bonus points if you can put even an approximate amount of money, and pass the report up. Stating the issues with the policies in terms of money will give the upper management a metric that they will understand; once they have those figures they may ask IT for measures to reduce the impact of their policies, even allowing for allocating some spending (for example, in a separated network for developers) if needed.

Note that the solution is open... maybe your IT policies should not change, but the IT team just should take more effort in properly profiling and documenting which permissions people in Development (and each separate department) need, and providing the new PCs already "customized".

pi31415 89731117 · Answer 9 · 2014-11-06 10:54:32Z

I would explain this as a time and cost issue. Time you're spending getting the access you need to continue on with your work, you could be spending doing your work. Also investigate if this policy change can be made to applies to developers only rather than a company wide change.

Keep in mind, this will probably be very hard policy to change especially if you're company works in a field that generally needs high level of security (defence force contractors etc). I have worked in companies on both sides of the spectrum, and the one that is loose with security always comes back to bite them so their policies might be rooted in past bad experiences.

Hmmm...I've found defense contractors tend to be the best at providing the most flexibility to the developers. Certainly not the most restrictive. I've always theorized that it is probably because the IT department at those companies actually know what they are doing, so they don't need to blindly follow some policy that makes their job easier but costs the company untold dollars in production. — Nov 7 '14 at 15:33
I've only worked for one so I can't really give an accurate overall impression, just my experience with the one I worked at. — Nov 17 '14 at 6:42

Nat 1091 · Answer 10 · 2014-11-06 22:41:36Z

You may be better off asking for a development virtual server(s) that you can remote access to and work that way. Ideally you would also have specific accounts to connect to those servers with that can be used to differentiate traffic at the firewall.
This lets you work in a secure manner and have all the benefits of administrative machine access.

After all, no-one wants to be that guy who let cryptolocker get the shared drive because he had admin rights and clicked the wrong thing by accident.

Paddy 36216 · Answer 11 · 2014-11-08 08:20:03Z

I have had this issue at a previous (very large employer) with a single mandated security policy across all users. They then bought us (a development house) and couldn't figure out how to let us work (requiring local admin access) on their corporate network.

What we wound up with was two computers each (not even a VM). One computer (with the nice blue sticker on it) connected to the corporate network and let us do fun stuff like email and access holiday requests and the other one (with the nice red sticker on it) connected to our own lan, that we managed ourselves.

I don't recommend this as an option (as it's a real nuisance), but it is one option if you really can't get access granted on the corporate network. Also handy for creating your own gaming server...

You can also have a terminal server you can remove desktop into (over vpn) for access to the corporate network. — Apr 21 '16 at 18:14
Not sure how why is downvoted, this is a common policy for computers that need to work on information classified "Top Secret". — Oct 11 '16 at 8:42

Pabs 9 · Answer 12 · 2016-10-10 07:28:34Z

How about just work inside the parameters you've been given?

Everyone else in the organisation has to do it? Why can't you? Just as Senior Dev/Ops, I can't just break down my day and start developing an application (and it's not that I don't know - most senior dev/ops in Government do) but that's not what I'm paid to do.

Following up from that, as Dev you don't know infrastructure. Coming from mail and web administration my opinion of most Devs and their infrastructure is "know enough to be dangerous" level. You may know 3 of the 5 things that can get it done, but you don't realise that those three are going to create a security vulnerability due to other configurations in the organisation. Just as I don't know all the methods or intricacies of the programming language because I haven't spent every day doing it, there will be a plethora of things you think you know about infrastructure but don't well enough to advise when they should be ignored.

If you company is worth it's salt, the following should have happened:
Driver installations - should have gone through the testing department to ensure compatibility with other drivers in your system.
App Updates - are they leveraging new / different frameworks? What's your new attack surface?
Control Panel - this is locked down for a reason - as Infrastructure I can do anything I want if I have access here.
New installations - see driver installations
USB Access - you don't even know how many people are dropping infected USBs and just waiting for someone with half a bit of access to plug them in

Normally, when I have this conversation with Devs (I'm the one you have to come ask for this) I explain this stuff. And basically, because you don't have the experience in my field to understand why we make these changes then you either need to trust me or find a new, but the reasons are real, and the result of failure will cost me my job.

I'm always dubious about developers who bring this stuff to me. Typically (and not saying you're like this) but they're usually the guys who are so worried about everything around them and not worried about the work in front of them. So a developer saying "this is too tight" doesn't really bother me. That and the fact that if you're actually going to release this software, getting an idea of what problems you might face in a production environment.

I saw there were a few comments about "record how much your time is wasted". I've had a dev pull that on me before and basically the retort that "a failure to prepare on your behalf does not constitute an emergency on mine" was enough for the person asking to feel very embarrassed. As infrastructure, I've always been told that's the devs responsibility to manage their time knowing the company and it's requirements.

Remember at the end of the day, the guys doing your infrastructure work probably went to school just as long as you did (if not more - more postgrads in Computer Science than Programming) so it's not like we don't know what we're doing. We're here to make sure that the system works, is secure - and then finally if those other 2 are done, then we let development occur. (That's always the direction from upper management - always - they don't give a damn about how cool your new feature is if they can't email a client or get their reports).

Finally, one last thing - the fact that you're working on VM (especially a low level linux distro like Ubuntu, Red Hat would be a much better choice) makes absolutely no difference whatsoever. Having built VMs for over 5 years for both linux and Windows web servers this is absolutely true. So please listen to us when the infrastructure guys and gals tell you to do something (as a general rule sys admins are lazy - and won't do something unless we actually have to - because we get paid either way).

(Okay one more thing - you could actually find out what you needed admin rights for - and just grant them explicitly on your personal VM - that's how I would do it).

I just wanted finish off by saving I have an amazing relationship with my devs, and it's because I save them from breaking stuff constantly. The dev/ops relationship is supposed to be symbiotic not confrontational.

Let's go through this briefly. First and foremost, the company pays me for my expertise. Not just to 'do the job'. If I don't like it, I can literally just go somewhere else (and I did). As the architect at a company, and having previously worked in ops, I designed the infrastructure solution. I now work in a forward thinking company, that doesn't have nor need the concept of "IT", and I can focus on the intelligent stuff with no red tape and nothing getting in the way. I'm not a robot, I don't do corporate. — Oct 10 '16 at 8:08
Finally, everyone is equal and this answer, imho, stinks of superiority with "my devs". You don't have any devs. You're all on the same team, you work together, and everyone is needed. Speaking of confrontational, that was pretty much the result of your answer according to the down votes, of which I did not give one. Enjoy. — Oct 10 '16 at 8:09
"Driver installations - should have gone through the testing department". And that is precisely why you should not get generic IT admins to manage developer setups. Here's a secret from a developer. New drivers do not magically come into being. Before IT can put them on a test environment, there first has to be a developer creating them !. And no, you can't just test random drivers in VM's. Not that I expect IT ops to know such things, but I don't expect developers go around telling IT ops how to configure a VLAN on a Cisco box. It works the other way too. — Oct 11 '16 at 8:40

user17426 1 · Answer 13 · 2014-11-07 20:15:49Z

I think it would help your case for enacting change if you could point to examples of successful companies that provide the environment you're looking for without compromising security. Unfortunately, I don't know any specific examples, but perhaps others may.

Downvoting a new users isn't typically helpful if they don't know what they did wrong. @user17426, just so you know, answers typically need to be more concrete. This seems to be more a suggestion, and less a concrete answer, as such would probably do better as a comment instead. — Apr 22 '16 at 23:05

NotMe 20.9k55695 · Accepted Answer · 2014-11-06 16:51:07Z