As a developer, how can I ask for more freedom when confronted with a tight IT security policy?

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)?

Answer 1

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.

Answer 2

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.

Answer 3

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!

Answer 4

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.

Answer 5

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.}

Answer 6

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.

Answer 7

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.

Answer 8

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".

Answer 9

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.

Answer 10

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.

Answer 11

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.

Answer 12

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.

Answer 13

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.