134

I work at a company with a staff of about 1000+. We currently have programming development staff that work on web based projects (approx 50 people).

Recently due to security concerns our IT and Security department implemented a restriction no longer allowing local admin access on machines . The entire company runs Windows OS for both workstations and servers. I completely agreed with the decision to remove admin, honestly I thought it was long overdue (as the company deals with patient data and requires HIPAA compliance). Unfortunately I believe they took the decision too far. I assumed a subgroup or AD group would be created for users that legitimately needed admin access to do their job (EX my programming team) something like a Tech group that would retain admin access. However this was not the case, the only group created a specific Admin group for Network and Help Desk staff.

The main problem is, as web developers we run programs that require local admin access and unfortunately can't do our job without them running as admin. Example programs include Visual Studio for ASP.NET web development, MAMP for local development, composer, etc. I believe the main reason these programs need admin access is because they need to run and modify local IIS, command line, etc.

Basically there was short notice of when the local admin access was removed. After about 2 days of the development team being dead in the water in terms of being able to work and me and other team leaders basically yelling and screaming at the IT staff to come up with a solution they finally conceded and found a third party program that works as a pass through allowing the administrators to create the ability for certain programs to run as admin even though we don't have local admin access.

Unfortunately, this program we use for local admin access is incredibly buggy and unreliable and not from a reputable source and there doesn't seem to be much for alternatives out there. (I would prefer not to disclose the program we use.)

My question is, is it typical to not allow Programmers/Developers local admin access at a company or corporation? And if it is common practice to do so, then how do developers run the programs they need as local admin?

A little more information on our network environment (not that it really relates to the question I just thought I'd add this):

  1. We use AppBlocker to block programs not on an approved list
  2. We use an email security blocker that does things like scan and convert attachments to PDF, etc.
  3. We have at least 2 major antivirus programs on all workstations.
  4. The network and it's servers very segregated, users only have access to certain servers, folders, and databases that they legitimately need access to.
TroySteven
  • 1,329
  • 2
  • 7
  • 11
  • 193
    *A company policy that encourages friction between IT and Development is a risky policy.* If there is one group of people that could seriously undermine the IT department's security efforts, it will be the developers. A good company policy would aim at having IT and Development combine their collective knowledge to reinforce the overall security. Forcing IT to put up barriers for Development is counterproductive to this result. Given enough incentive, people will start looking for creative workarounds. Creative workarounds from developers will be detrimental towards overall security. – Jacco Jul 16 '18 at 08:47
  • 115
    Having two separate antivirus programs on a system will almost certainly do more harm than good. You'll get a negligible increase in detection, whilst doubling your exposure to vulnerabilities in the AV software itself, as well as significantly slowing down the affected systems. – James_pic Jul 16 '18 at 13:03
  • 4
    Not the same question but very related, I was on the other side (the IT side of things, and IT people often do not agree with such a crazy policy either): https://security.stackexchange.com/questions/135359/company-computers-for-competent-developers-how-can-you-deal-with-them – grochmal Jul 16 '18 at 14:12
  • 24
    I don't think you really want to ask if it's "typical". But rather is it justifiable, and what are the cost/benefits? In my experience it's somewhat common for large organizations to try this. The costs are rather high, and it drastically affects productivity for Developers, but the "security people" normally don't care because it's surrounded in an SEP field (Somebody Else's Problem). If you want to get rid of this, you're unlikely to win trying to find that this isn't typical, but rather that it's EXPENSIVE. Companies hate expensive. – Steve Sether Jul 16 '18 at 14:30
  • This largely depends on sector. Banking, military, utilities - they're all more likely to be much more restrictive than most others. Software engineering is a skill that you can move to any industry, but is not always an industry in its own right – UKMonkey Jul 16 '18 at 16:39
  • 2
    Do you /really/ need admin access to use ASP.NET/IIS ? I've been developing those projects for 10 years, and never needed admin access. I've worked with developers who insist on it (on the same code base), but that's usually because they have 'tools' that they (badly) wrote themselves. – Neil Jul 16 '18 at 17:11
  • 1
    @Jacco I couldn't agree more. I used to work for an organization that did this, and it created exactly that friction you're talking about. When Big Evil Corp tried to implement this, my first thoughts centered around jumping the fence. Any halfway skilled developer can come up with half a dozen ways to jump these types of fences without much effort. – Steve Sether Jul 16 '18 at 19:47
  • 53
    @Jacco Not to mention the cognitive dissonance between not trusting a developer with their own machine and simultaneously trusting them to develop custom code to be run on the company's servers and that processes sensitive end user information. If they can't keep a virus off their machine without protections, I don't think I'd want them developing my applications that I could be fined for not doing properly. – jpmc26 Jul 16 '18 at 23:40
  • 4
    Note: If you allow Visual Studio to run "As an Admin" the user can run code, "As an Admin". Code with admin privileges can assign the SeDebug privilege to any security token it wants, and hence the developer has total control of the machine. – Chris Becke Jul 17 '18 at 06:00
  • 3
    Lets not even examine the fallacy that is, adding more antivirus products makes a system more secure. – Chris Becke Jul 17 '18 at 06:01
  • 3
    The way I've dealt with this in the past is by making a rather basic appeal to a boss/director who is above the IT security people in seniority. It goes something like this: "I have a problem which means I can't get any work done, but I've identified the solution and only need your approval to implement it." Funnily enough, the need for the company to make money *always* beats the existential threat that the IT security people invent to justify their draconian measures. HOWEVER: always be pleasant while doing this - you want the IT security team on your side, long-term. – Aaron F Jul 17 '18 at 07:29
  • In many companies the devs also double as sysadmins so they'll naturally have privileges. – Magisch Jul 17 '18 at 09:28
  • Have you tried setting the WAAS endpoints to give your user/group access to http://+:80/? Google for "netsh http add urlacl"... – Aron Jul 17 '18 at 10:45
  • Of note, some development tools will not run if the account is not admin. This tends to be more true the older the software tools are. – UnhandledExcepSean Jul 17 '18 at 17:54
  • 3
    One downside to software developers running as local admins is they may never encounter end-user issues which only happen when you do not have such rights. I've personally seen this happen many times. – barbecue Jul 17 '18 at 19:51
  • I am a contract programmer in the defence industry. Every company I work for has a program which will give temp admin rights while logging the action taken for security reasons. To answer your question: "is it common?" - yes, but that's really a well defined security question (no offence intended) – Mawg says reinstate Monica Jul 18 '18 at 07:52
  • 3
    If you let appdevs ladmin their machines, then they will install unauth FTP, RSH, Webmin, Jenkins, Tomcat, ColdFusion, JBoss/WildFly, Splunkd, ElasticSearch, etc -- and they will never upgrade. They'll configure SimpleHTTPServer, SMB, AFP, and/or NFS to allow willy-nilly read-write access to their local filesystems over the network (or portions thereof) and then they'll leave shell scripts and key material on those shared folders. They'll do the same with databases and anything else that can bind to a network socket. – atdre Jul 18 '18 at 16:27
  • It's sometimes required for debugging. For example, when using Visual Studio without local admin rights then you can't debug a process that's started under another user. But a company can setup some process to request temporary local admin rights on the workstation for a specific user. – LukStorms Jul 19 '18 at 07:34
  • 1
    Any dev worth a damn will gain root access on a machine he has physical access to :) – Navin Jul 19 '18 at 18:02
  • 1
    @Neil Yes, you need to be a local admin to even open iis manager or to attach a debugger to an iis worker process. – Andy Jul 19 '18 at 23:52
  • @Andy Or just use IIS Express, and then you don't. – Neil Jul 20 '18 at 06:18
  • 1
    @Navin at some places that will get you a short trip to HR to get your P45. Yes really ! – Neil Jul 20 '18 at 06:20
  • @matwonk Please keep us posted on how the issue played out. – Jacco Jul 20 '18 at 10:10
  • 1
    @Neil Except when you can't use IIS Express, like when you need to deploy an app to another computer and have it connect to your workstation. – Andy Jul 20 '18 at 22:09
  • @Andy That sounds more like integration issues, rather than development. 100% of your development work can be done without admin rights. – Neil Jul 21 '18 at 14:07
  • 2
    @Neil Its not an integration issue; unless you think that a developer running the app his is working on locally to test it before committing is "integration." There are plenty of other things that developers will need to do which require local admin, and not having local admin is a severe impediment to being production, which is probably why most developers end up with it (and I personally would not work somewhere I didn't). – Andy Jul 21 '18 at 14:11
  • 1
    Since the company sees devs as a problem and not as a solution (apparently your boss was either not heard or ignored) I suggest looking for a more developer-friendly environment elsewhere. And since we are on Stackexchange, our great founder has a [strong opinion](https://www.joelonsoftware.com/2006/09/07/a-field-guide-to-developers/) on how your company treats you. – Martin Schröder Jul 22 '18 at 22:39
  • 3
    An anecdote: I've never worked for a company that locked down their employee's this way that had any sort of real competent security. Any company I've worked for that did this failed at the basics, while making work for their employees extremely difficult. I'll also say that I will never work for a company like that again. I'd rather actually do meaningful work than deal with a bureaucratic waste of everyone's time. – Brad Jul 23 '18 at 05:01
  • @atdre Hire compentent engineers. Besides, if things are set up correctly, none of what you just complained about is of any real risk. – Brad Jul 23 '18 at 05:03
  • @Brad: Past about 300 employees, that’s impossible. There is strong evidence that even cybersecurity pros fall victim to generic phishing and spear phishing. When you pit a financially-motivated actor, or nation state, against one person — it’s usually the person that caves. Nah, it always is. There is no proper “set up” that I’ve heard of that reduces the risk of access expansion in a Windows Server Forest environment. Not even Microsoft sells one. – atdre Jul 23 '18 at 14:48
  • @atdre That is completly possible, you just need to organize yourself better. When I worked at a huge software shop, every project was a entirely separated "virtual company" in IT-Related matters, with it is own servers, team, and fully isolated infraestructure. There was no need to put everyone on the same network all the time. It worked wonders. It also had a plus that you could move a team anywhere without compromising its work or having to set up access to a central server - when one of our offices burned up, we rented space on a cyber cafe and kept going until things were fixed. – T. Sar Jul 23 '18 at 16:34
  • @atdre Also, by having fully separated infraestructures, we could run upgrades and different setups in each team as needed. Since the IT team was also compartimentalized per "virtual company", each professional also had way less to take care off at all times. – T. Sar Jul 23 '18 at 16:37
  • Idk, you have great ideas but I have never seen them implemented well. I think it's best to implement JitJea regardless. Nobody should even have admin for long (seconds), especially not a local admin to a workstation or domain admin/group to large-installation networks. – atdre Jul 23 '18 at 18:46
  • 2
    In my work life I always had admin access. One Company tried to remove this from us but stopped it quite fast after realizing the devs not only get frustrated but simply stopped working. Not because they did not want to, but because they could not work anymore. So at least from my personal experiance (in germany) it is quite common to have admin access for developers. (I know from SOME devs that they have to use VMs (with admin rights) as a compromise for strong security environments – Ole Albers Jul 24 '18 at 09:52
  • 1
    This is actually one of the questions I commonly ask in job interviews, if the answer is no, developers aren't allowed local admin rights, then I politely decline to proceed any further. – Dark Hippo Jul 24 '18 at 13:17

19 Answers19

116

Here's one data point from a software company that has an interest in security. I know this is common in similar organisations.

There is a number of networks. They are physically separated and airgapped, run different colour-coded network cables.

Each employee has an 'administration' machine, which can connect to the Internet (via a proxy) for doing email etc. All users are strictly locked down, and there's strict device and access control.

In addition to this, each developer has an 'engineering' machine. This has full admin access, and the user can do whatever they like. However it is connected only to the engineering network (no route to the Internet).

In most software development contexts this could be seen as extreme, but in orgs that have conflicting requirements of high security and developer freedom, this is a common solution.

To answer your question, yes it is common to allow developers admin access, but this doesn't always mean admin access to a machine that could cause information security issues.

Joe
  • 1,284
  • 1
  • 9
  • 10
  • 24
    +1, some development teams in our company use the same practice. Although we don't air-gap the development network. We handle it using VLANs. – Philipp Jul 16 '18 at 10:58
  • 1
    +1 That’s how the Infosec/A/V vendor I worked for did it as well. They took the network segmentation pretty seriously - it was a terminalable offense to plug the dev machine into the prod/internal infrastructure network, and I had to term more than one developer for doing so. Still, I think it’s the best, developer-friendliest approach to the problem - “here’s your dev laptop on your dev network, and we’ll isolate you from anything that might be harmed by the evelated permissions you require to do your job well.” – HopelessN00b Jul 16 '18 at 18:10
  • Is your "engineering network" really a production network? Do you really need to have two boxes, one to read docs on, another to code? If it's a dev/test network, I'm confused about the worry, infiltration of attackers getting code? Exfiltration of code (your devs will work around that in about 5 seconds)? If it was a production network, you could probably avoid giving engineers access to it at all (QA/ops deploys into prod). – Nick T Jul 16 '18 at 21:47
  • 85
    Hm, the development machines not having any internet connection seems a rather severe restriction. – Deduplicator Jul 16 '18 at 23:41
  • 8
    @Deduplicator how so? You can copy stuff over easily enough via USB drives. It makes you think about what you really want instead of randomly clicking on junk and installing everything. Lack of admin access has made me organize my downloads in batches so I'm far more selective with what I install. – Nelson Jul 17 '18 at 02:09
  • 2
    @NickT Sourcecode leaks are usually a secondary concern. Or in many organization, no concern at all, because their software is so specialized that it has no value for anyone but them / their client. The danger which affects everyone is unintentional malware spreading. A machine running on full admin privileges and accessing the Internet with software not vetted by the IT department is a malware magnet – Philipp Jul 17 '18 at 08:47
  • 12
    @Nelson: How can you vet that what you're copying over the USB stick is safe? While you obviously need to allow copying from administration to engineering; would you allow copying _to_ the administration machine? Because if you allow both, the data exchanged on a stick is as safe as the data exchanged on a physical network cable (directly between the two machines), it's just a slower process. – Flater Jul 17 '18 at 13:16
  • @Flater even if it's unsafe, – Nelson Jul 17 '18 at 14:29
  • 53
    This is not a decision to make lightly. There will be a considerable impact on development. Not saying it's impossible to do, just pointing out some of the consequences. From technical things such as nuget/npm packages (you won't have realtime access to the public feeds and will need to copy everything manually), but also more trivial issues (developers can't copy/paste from StackOverflow anymore. And let's be real here, we all do it, even if we agree that vetting the code is necessary (which imo, it is), manually having to type the whole thing is not going to be conducive to efficient work). – Flater Jul 17 '18 at 14:37
  • 16
    Having to buy a second pc/laptop for the employees seems like a rather expensive way to make people less productive – J_rite Jul 18 '18 at 13:51
  • 9
    Frankly, I would hand in my notice the very moment this policy was introduced... Not having internet access on a dev machine is just madness. – fgysin Jul 19 '18 at 09:15
  • 3
    @Nelson That approach becomes very painful in practice. It's common nowadays to use frameworks to speed up development. Many modern frameworks depend on a number of libraries, and it can be complex and error-prone to identify the exact dependencies of the framework you are using, in order to save them to a USB device. You also lose access to important security tooling that way. Some modern package managers can automatically check if your dependencies have security alerts, and upgrade them if so. If you need to do that on a different machine, then that machine becomes your de facto dev machine. – James_pic Jul 19 '18 at 10:33
  • 3
    @Nelson, Actually, to improve security, all USB used ports on the engineering environment should be disabled, they are inherently insecure. Far more useful and safer would be the use of a Data Diode to allow for the controlled download of external updates. https://en.wikipedia.org/wiki/Unidirectional_network – Jodrell Jul 19 '18 at 11:41
  • 2
    I'd had to work in a somewhat similar setup when working at a DoD contractor. In that case my main dev machine was connected to the main network, internet, and had local admin. The production machines were airgapped from the world behind locked doors and massively locked down. Being able to do most of my dev/initial testing normally reduced the pain a lot, but there were times it wasn't feasible to create a usable unclass dataset and I had to do everything on the high side. That was miserable because it was at least a 20 foot walk to an internet connected PC, and only hardcopy xfer to dev. – Dan Is Fiddling By Firelight Jul 19 '18 at 15:56
  • At my workplace the USB (and other removable media) is disabled (and only allowed for a white list of dev devices for a limited time for work purposes) but we have 2 accounts, an Admin one for dev work with no/limited internet access and a low permission user that can browse the web. No need for 2 machines. – Stephen Jul 20 '18 at 14:32
  • Most places you'd see deployments like this are well past the concept of user machines and well into the concept of Accounts: They all operate VMs or Network wide managed accounting with shared storage. Your Admin PC can easily have RW access to a NAS, or even be a VM VPN/SSH target that is only allowed to run one client per room (to stop people leaving it logged in). This is usually ideal as then IT can access admin from any system, Devs can run installs via it, but are required to login from a std user account first, identifying the Admin user. – user1901982 Jul 20 '18 at 21:08
  • Blocking access to the open web is of course madness, but in all honesty if you want to dev in an admin environment whilst maintaining security your IT side should be virtualizing your suite so it can have sandboxed admin access. This allows you to do as much administrative work, whilst limiting you to the outer Access control off the VM and keeping anyone from say, getting a virus on shared storage. – user1901982 Jul 20 '18 at 21:12
70

In my experience, it is common for developers to have admin access on their own machines. It is also common for them not to have admin access on their own machines. However, in the latter situation some accommodation is generally made so they can get their jobs done without too much friction.

One very common accommodation is access to a Hypervisor on the workstation (whether some version of VMWare or the Hyper-V that comes with Windows), along with the specific permissions needed to create and destroy VMs within that hypervisor as needed (Hyper-V/VMWare), including creating VMs where they have admin rights to the guest OS. Typically some of these VMs will be long-lived, even if they don't run all the time, where it's rarely a question of needing to prepare an entire VM from scratch just to do what should be a quick test for something that needs administrator privileges.

The Hypervisor may or may not be configured to allow internet access for it's VMs; I've seen it both ways, though personally I strongly favor that internet access should be allowed... at least for the types of development with which I have most experience. But internet access, when granted, can and should at minimum be configured to force VMs into a dedicated vlan, separate from the rest of the corporate network. I'm not sure this is possible to enforce directly via Hyper-V or VMWare, but you can use 802.1x on the ports for many network switches to prevent access to certain vlans from unauthorized machines, including devloper VMs. Then you can give a little tutorial to developers about how to set a vlan tag in a VM and let them know what vlan tags will be permitted on their switch port. I've also seen this enforced via training merely as a policy edict, rather than via technical measures, with perhaps the occasional friendly audit to encourage compliance and make sure devs know it's important.

And, of course, this coincides with providing developers with machines sufficiently powerful to run multiple VMs at one time.

Joel Coehoorn
  • 2,116
  • 1
  • 13
  • 14
  • This sounds like a good solution - a _very_ good solution - but I don't have enough Windows admin-foo to know if it actually works that way (specific privileges or rights to spin up VMs without having general local admin privs) - so IMO this answer could be much improved with links to some documentation/white papers/cookbook items/or such that confirm this. – davidbak Jul 16 '18 at 20:59
  • 1
    @davidbak Better? – Joel Coehoorn Jul 17 '18 at 02:02
  • Yes, great link! Ben Armstrong is the guy to go to! Plus the detail on the VLAN stuff. – davidbak Jul 17 '18 at 02:33
  • @davidbak I've worked on a machine with a hypervisor (VirtualBox) installed while having no admin rights – anna328p Jul 18 '18 at 09:14
  • 1
    VMs also provide other benefits for the developers. One physical computer can host several VMs, running different OS versions, or versions of the software under test. As they are disposable, it is easier to repeat tests by reverting to a chosen checkpoint. – Raedwald Aug 09 '18 at 19:43
49

I work for a fairly large investment management firm (~6000 employees) and developers are one of the groups that we approve for local admin access. We tell them not to install any software, as that is handled by local desktop/software compliance.

We also have a Developers AD Group that allows members to change the execution policy on their machines without requiring local admin.

Justin
  • 702
  • 5
  • 9
  • 6
    This does not answer the question. It does not give any explanation if or why this would be "typical". – Tom K. Jul 16 '18 at 14:43
  • 8
    @TomK. It answers the actual question, which is "Why is my organization making my life very, very hard, for seemingly no good reason, and what can I do about it?". The OP is clearly trying to fit this (quite frankly bizarre and paranoid) practice into his world view. People are trying to point out how their organizations have balanced the paranoid security people with the real life needs of Developers. – Steve Sether Jul 16 '18 at 18:08
  • 4
    @Steve - unfortunately that is as misguidedly extreme a view as that you get from some extreme security folks. It's not paranoid to protect organisations from insider threat. In fact for many it is the biggest threat to their existence. – Rory Alsop Jul 17 '18 at 09:45
35

In my experience allowing and disallowing local admin access is common, just as common as dirty workarounds for the latter. - So you should ask yourself:

Which threat to your network is made worse by local admin rights?

To which the answer shoud be: NONE - The access to resources in your network should be restricted on a per user basis, completely unrelated to the fact if this user has local root, admin or masterOfTheUniverse access on his machine. If the user has rights to blow up your network, a local virus does not even need admin access, it can just use the user account to blow up your network. - And if the user-account cannot access something on your network, local admin rights will not change anything about that.

You should trust your developers to handle their own machine responsibly - and with a sensible security configuration in your company local admin rights should be dangerous only for one thing: The local machine. So the only risk you accept by giving out local admin is that a developer breaks his own machine (which he can already do with a cup of coffee).

Addendum: You should grant your developers the possibility to use local-admin rights whenever they need to. This doesn't mean they should be logged in with an unsecured admin-account all the time, but you should trust them to use it sensibly whenever they need it - without asking for permission every time.

Why developers should have local admin-rights

Your developers are people which you entrust the design of core operations of your business. Most companies today are very dependent on their software, so developers are a vital resource to shape a very important part of your company.

First there is the benefit of higher productivity, because the developer can just configure, install and test everything he needs to on his local machine. He may need certain software, helper tools or unusual configurations to experiment with certain aspects of his software (for example run his software on an older version of a OS or with older drivers/SDK).

Second there is the (in my opinion even bigger) benefit of showing your developers how you value them. You show them that you trust them with their own machine - you treat your developers like responsible IT-savy people who can administer their own machine without a babysitter. (In many companies where devs don't get local admin, they will have to ask tech-support or security for every installation/configuration they need. And in many cases these tech-support people know less about the software than your senior lead developer, but they still have to beg for things they simply needs to do their work, which can be very frustrating.)

Falco
  • 1,493
  • 10
  • 14
  • 3
    @Downvoter care to comment how my answer could be improved, or why you think it is completely wrong ? – Falco Jul 23 '18 at 10:30
  • In short, this answer violates the principle of least-privilege and the whole concept of defence-in-depth. The reason for limiting local admin is to help to mitigate attacks which do get through and good devs will understand that. Where there's a demonstrable need then it's a different ballgame, often it can be met with a separate local admin account so that the use of elevated privileges is temporary; but the OP says they're web developers, so there should be very little need for local admin rights. See https://security.stackexchange.com/a/190182/17321 – James Snell Jul 23 '18 at 19:48
  • 7
    @JamesSnell Visual Studio needs local admin rights, which is (imo) a large reason, as developing without Visual Studio just does not happen. Not disagreeing with the rest of your comment, just the need for local admin rights. – Belle Jul 24 '18 at 06:15
  • 6
    @JamesSnell I'm a big advocate of defense in depth, but I just don't see a local restricted account securing anything of value, except the local hardware. Anything of business value can be accessed with user rights https://xkcd.com/1200/ – Falco Jul 24 '18 at 06:35
  • 2
    Defense in depth for me includes an encrypted hard drive, a strong password on the local account, a secure hardware module... But local user right restriction on a single user laptop is just security theatre – Falco Jul 24 '18 at 06:39
  • @Falco - the point is that the machine is prevented from being used as a platform to launch further attacks... read the linked question. – James Snell Jul 25 '18 at 16:06
  • @JamesSnell how is the machine protected? An attacker with user rights on the machine is enough to launch a full scale attack on your network. The Laptop can already be an infected host without any admin access. – Falco Jul 25 '18 at 16:09
  • @Falco - it reduces the attack surface, did you not read the linked answer? Plus... https://www.theregister.co.uk/2018/07/25/developers_malware_vectors/ – James Snell Jul 26 '18 at 20:16
  • 1
    @JamesSnell ironically an IDE which they could install without local admin rights ;-) But I see your point: Yes it widens the potential attack surface, but only by a small margin. And if your developers don't get local admin and download some "helper tools" to work around that, you likely have even more of an attack surface. - I would like to see a survey if developers use their machine more responsible if they are trusted with responsibility, instead of mistrusted. – Falco Jul 31 '18 at 07:18
  • @Falco - it's not an issue of trust. I run my own systems this way. I restrict my own rights when I don't need them. – James Snell Aug 06 '18 at 19:42
  • 1
    @JamesSnell As can every developer so of his own free will, if you trust him. Local admin does not mean "uses root all the time" but "may use root of necessary" – Falco Aug 06 '18 at 20:17
  • 4
    Maybe I should edit my answer to set this clear - I think developers should use a secured account normally, but have the option to enable local admin if necessary without the need to fill out a form and ask for permission. And I trust them to use this privilege sensible and sparingly – Falco Aug 06 '18 at 20:20
  • I didn't downvote, but you should rephrase some parts since especially your first point reads misleading at the first glance: Threats by local admin rights: The malware has access to cached user passwords including domain admins, access to the data of other users, access to different security tokens that can be used on the network to escalate to domain admin rights, ... . Btw. it seems that malware like Emotet already does this according to reports. Your last point is not so correct for inexperienced/junior developers whom I saw to download and install even very non-legit looking tools. – H. Idden Dec 20 '19 at 22:25
  • 1
    @H.Idden You are right. My answer is completely operating under the assumption that the targeted individuals are trusted developers, each using their own machine with a single user-account. In this case there should be no cached domain passwords or any information which is not tied to the user. So a malware accessing user-files (like browser password-store) will already have everything it needs without admin rights. - And of course inexperienced devs should be supported by seniors. – Falco Jan 02 '20 at 11:50
30

In my career, with rather small companies (less than 100 people), we always had local admin rights. We either have real desktop machines which are maintained by IT, but got the rights, or we were allowed to have virtual machines of all sorts that we completely managed by our own.

If we had not local admin access, we would try all sorts of bad "solutions" which, as in your case, leads to less security. This is one of those cases, that restrictions actually lead to the opposite of their intention.

Marcel
  • 3,494
  • 1
  • 18
  • 35
  • 5
    This does not answer the question. It does not give any explanation if or why this would be "typical". – Tom K. Jul 16 '18 at 14:45
  • 13
    @TomK. This answers the question *partially.* If 10 people out of 10 say "I always had admin rights" then *together* that is the answer. No single person can canonically answer a global question like this; each single answer is to a degree anecdotal, a "data point" as Joe called it. (Joe also claimed "I know this is common in other origanisations", failing to add "which I know of".) – Peter - Reinstate Monica Jul 17 '18 at 16:13
  • 1
    @PeterA.Schneider: Correct, typically no single person can canonically answer a global question like this just with his/her **experiences**. But fortunately there are such things called "best practices" that are written down and open to scrutiny. Other possibilities are studies or articles. Just saying "For me, it's like this" is not enough. – Tom K. Jul 18 '18 at 07:16
  • @TomK. There's no way to know what is typical short of some kind of survey, so answering that part of the question isn't going to happen. – Andy Jul 20 '18 at 00:11
  • @Andy Correct. These surveys or studies are done by scientists or often times by consultants who develop - as I mentioned - best practices. Citing these best practices or studies would constitute a valid answer. – Tom K. Jul 20 '18 at 06:51
  • 1
    @TomK. Those surveys or studies, if they even exist, would be junk. As you said, itd just be a collection of what might be "typical" and just because something is typical doesn't mean its the right way to go. – Andy Jul 20 '18 at 22:12
29

In a rather small department of a larger organization (~100 in department, ~3500 in full organization) we chose an in the middle solution:

  • sysadmins had 2 accounts, one (non administrator even for the local machine) that was used for non administative tasks (mail, document edition, etc.) and one with AD administrator priviledges that was supposed to be only used for AD administration
  • all other users had only one single non administrator account
  • devs (and some power users) were provided a local account with local machine administrator privileges. It was supposed to be seldom used when local administration was required.

Refusing administrator rights to devs will be a cause of loss of productivity, and that has an immediate cost for any organization. The choice of granting admin privileges on the local machine to the primary account or to a secondary account should depend on the frequency of administrator operation:

  • If more than several times a day, I would advise using the primary account.
  • If less than once a week, I would use a secondary account.

Choose your own if you are in between...

Nisarg Shah
  • 109
  • 5
Serge Ballesta
  • 25,636
  • 4
  • 42
  • 84
  • 1
    Yep, we did this too. Although our AD admin accounts also had local admin privileges on every machine (that was part of domain/ad). – mroman Jul 16 '18 at 13:57
  • 2
    We had a meeting today with our IT team regarding this and I'm leaning towards marking this answer as answered simply because this is the solution they came up for us. – TroySteven Jul 17 '18 at 01:53
  • 1
    Considerations: how much internet access for the AD account. At my workplace, my AD has virtually no internet access (Visual Studio updates excepted). I must use my regular account for internet/download/etc. – Nigel Touch Jul 19 '18 at 14:51
13

In my experience working for larger organizations, it is absolutely not common for developers to have full rights to anything other than development specific resources.

It seems like your organization is on the border of small and large, so...

It sounds like it's time for your organization to develop some more mature development practices.

To be fair, this kind of a change isn't something operations groups should surprise development teams with, like it seems was done in your case.

Security and developer productivity need not oppose each other for your company. You can avoid this clash altogether by performing your development activities on a network that doesn't have access to resources on your core business network.

You aren't doing development against your production assets anyway, right?

If you are, you shouldn't be - it introduces a significant risk to your assets, particularly to their availability.

Much better practice is to have an entire development environment setup that replicates key portions of functionality and data sets (without exposing something like private information about real individuals in your company). This replicated environment makes the separation fairly simple. Your developers need full control of machines in this development environment. They do not need full control of assets outside of the development environment.

There are a number of ways to implement a separate development environment:

  • Completely separate hardware (workstations, servers, network devices, etc.), connected to the internet or not
  • Virtualized environments (including virtual networking); hosted on your hardware or with a cloud service provider and with or without internet access
  • A combination of the two approaches above

You can also implement some kind of bridge (if you're not already using a service of some sort already) for any sharing you need to do in and out of the development environment.

Development environments should be protected like most networks. Don't just throw all your code and development assets online without some thought to access control or basic security measures.

I've also seen some places take this one step further and write all of their code in one environment then build/deploy it all to another completely separate environment for integration testing.

John-M
  • 251
  • 1
  • 5
  • 3
    Rather than writing my own answer, I want to build upon this one. At my job, we distinguish between: 1)Development servers, 2) Other non-production (QA, TST etc.) servers, and 3) Production. Developers can have admin access to do development work, but they're expected to package their code and other assets and give them to us to deploy in the other non-prod environments, along with all of the documentation about any OS tweaks that need to be done. I don't even want them on those group 2 systems introducing differences from Prod, which defeats the purpose of group 2. – Monty Harder Jul 16 '18 at 17:54
  • 11
    This is the correct answer. Developers should/must have admin access to their development workstations but should NOT have access to production systems, dbs with sensitive data etc from those workstations. – Chris Becke Jul 17 '18 at 05:54
  • 1
    In the GDPR era, keeping developers off production systems is pretty much a legal obligation. The good thing about laws is that they can trump internal company policies. – MSalters Jul 17 '18 at 13:00
  • 3
    **

    You don't need huge and bold text to get your answer read or your point across.

    **
    – Luc Jul 17 '18 at 15:32
11

First of all you need to learn that it does not matter what "is common" or "typical" because: typically such situations are handled horribly. You are making the best case for this statement.

If local admin access is needed for a person (be it a contractor or an employee) then it is the obligation of the security team/person - whoever is in charge of that particular area - to find a solution. There are manifold solutions: creating an isolated VLAN, virtual machines and others were named here.

It does not make any sense to inquire upon the setup of other organizations just to hear "we also have admin rights on our machines". You won't find an infrastructure that is exactly the same as yours. The only thing that matters is, that the security team/person plans a secure solution that is then implemented by the IT deparment in this particular organization.

If the solution that has been implemented does not work properly and is therefore still rendering you unable to work, bring it up with the security team/person again. If this does not work, bring it up to your boss or your contractee.

What you are doing right now is burning money and nothing else. If the other participants in this game have not figured this out by now it is bad. But it is good if you do.

Tom K.
  • 7,913
  • 3
  • 30
  • 53
  • 7
    In all reality, since you remarked on Marcel's answer: It appears that *your* reply does not answer the question and actually explicitly refuses to do so. If you want to encourage the OP to ask a different, more relevant question, consider doing that in a comment. – Peter - Reinstate Monica Jul 17 '18 at 16:19
  • 1
    There's a difference between not answering the question and giving a different perspective or trying to show OP the problem in another light. – Tom K. Jul 18 '18 at 06:59
9

This fundamentally depends on context, and in particular on your threat model.

In some organisations, it's common to give developers complete control over their development workstation, to the point of enabling them to install their own OS on it.

In some organisations, all development must be done in an airgapped environment, that no electronic devices can be taken into or out of.

Most organisations fall somewhere between these two extremes. The more locked down the development environment, the less productive your developers will be, and the more likely you are to lose your best talent. Your organisation need to assess the likelihood and impact of a compromised developer workstation, and how much they're willing to reduce developer productivity to mitigate this risk.

James_pic
  • 2,520
  • 2
  • 17
  • 22
9

The problem you actually have is competent IT are attempting to enforce a boneheaded rule. You really only have one choice, give developers effective admin access.

I keep seeing the same advice being repeated over and over again, that boils down to a second machine that the developer has admin but no internet. If you want to have swiss-cheese security that's the way to go. The lists of software installed on a typical developer's computer are usually longer than a screen. Many of these have only one option for check for updates--internet. You can't patch them via WSU because WSU doesn't know they exist.

Here's what the arguments don't understand: breaching the developer's personal accounts isn't a launching point; it's the jackpot. There is no reason to go for admin from there. The breacher has capacity to modify the codebade to insert backdoors. Gaining admin on the developer's box isn't that much more interesting.

What are you defending against when you want to deny admin? Somebody accessing the codebase? No. Somebody using it as a launching point? If your production LAN isn't protected from your dev boxes you're doing something wrong. The developers installing stuff they shouldn't? No. The dev has a compiler and runs code output by the compiler. This might as well be definition of running unapproved software.

I've heard many many stories of the policy being the devs don't get admin, but the practice of IT looking the other way while the devs overthrew the security policy. I've heard many more of the IT never even finding out. I've heard some of the dev's manager telling the devs to bypass the security checks.

Sooner or later, organizations learn to just give the developers admin. Most of the ones that don't probably end up having done so without actually knowing it.

It's far wiser to just give devs local admin on one box connected to the internet and to the local domain and be prepared to deal with whatever the consequences may be. Protect production instead. There are fewer people who should be accessing production at a high level of privilege, therefore the lockdown is easier, and competent organizations learn to do that.

But suddenly taking away admin like this almost always results in loss of the more important devs. You don't want that.

Since you want to talk about Windows sites, there is one anecdote that outweighs most people's data. Microsoft gives its devs local admin. The maker of Windows has concluded there is insufficient benefit to not giving devs admin to make it worthwhile. Therefore, you should do the same.

Joshua
  • 1,090
  • 7
  • 11
  • Can you provide a reference for this? "Microsoft gives its devs local admin. The maker of Windows has concluded there is insufficient benefit to not giving devs admin to make it worthwhile." – Soenhay Dec 18 '18 at 19:19
  • @Soenhay: https://blogs.msdn.microsoft.com/oldnewthing/20110927-00/?p=9543 and about 50 others – Joshua Dec 18 '18 at 20:00
8

I've seen two approaches that work.

  1. Give developers admin access to their machines. This is the easiest and most common approach. It is usually the best choice
  2. Create a team in the organisation whose whole Job is to ensure that developers can work without admin access. This team will usually be 3-4 people. You will find that developer's hardware requirements increase dramatically as you'll be using containers and or VMs, so budget for buying new hardware for all developers. When you roll out, start with a team of early adopters, then gradually move all of your developers to a machine without admin access. This process will take at least six months.

If you do what your company is doing now then your developers will put up with it for a month or so then start looking for new jobs.

UEFI
  • 222
  • 1
  • 6
  • 3-4 people, full time?! That's a lot of money that I think could be spent better. And you might want to elaborate on why you think giving devs admin permissions is the best choice. – Luc Jul 17 '18 at 15:42
  • 2
    @Luc A lot of development tools rely heavily on Local Administrator privileges. MS Visual Studio for instance doesn't need all local admin privileges to run properly, but needs certain admin privileges. DEBUG_SE for debugging, service management for - well - managing services, Create rights for databases and I could go on for ages. Now detecting why a developer isn't capable of running a database script, debugging an application or installing a service can be extremely time-consuming, and it is either the time of the said developer, or the time of dedicated personnel. – mg30rg Jul 19 '18 at 09:19
  • It's completely unreasonable for any development tools to need any sort of admin access. Whatever they think they need it for, the IT team responsible for setting up and maintaining developers' boxes should be able to reconfigure the software or virtualize the proper interfaces so that the tools work without compromising security of the infrastructure. – R.. GitHub STOP HELPING ICE Jul 19 '18 at 15:27
  • 4
    @R you might want to read up on 'devops', you'll find that modern day developers have very reasonable motives for wanting admin access. For me personally, not having control of my machine is huge red flag. If told in advance, I'll decline your job offer, if not, my first two weeks will be my last. – Douwe Jul 20 '18 at 08:26
  • 1
    @R.. I regularly start a program, then attach a debugger to that program so that I can read it's internal state, pause it's execution and make it execute arbitrary code. This requires admin access. My productivity will drop if you ban me from doing this. – UEFI Jul 20 '18 at 11:13
  • 1
    @Luc It's better to give devs admin access because it's cheaper. It means you won't have to employ 3-4 people full time to keep the developer's machines working and complaint with your security policy. – UEFI Jul 20 '18 at 11:16
  • @UEFI: Instead you'll just have to employ people to re-image developers machines everytime they install viruses and deal with all the lost development time and possible loss of assets... Re: debugging, surely there should be configurable policy to allow non-admin users to debug *their own processes*. – R.. GitHub STOP HELPING ICE Jul 20 '18 at 13:32
  • 1
    @R.. So my web-browser running java-script should by able to access the internal state of another program on my system, such as my password manager? I see no security issues with that .... – UEFI Jul 20 '18 at 15:08
  • @UEFI: No, because the JS is an embedded language that does not run in the privilege domain of your user account. It runs in a complex privilege domain implemented by the browser. It's true that under a sandbox-escape vulnerability in the browser, there would be a vector for debugging other processes (but there are already better vectors for attacking you in the case of sandbox escape). As such, for hardening it's useful for debugger-attach policy to be configurable and off for users who have no interest in using it. But it's not an essential aspect of any privilege model. – R.. GitHub STOP HELPING ICE Jul 20 '18 at 15:12
7

I worked for some time for a company that really believes in security (or so they think).

Every once in a while they would organize a social event, like playing bowling. Joining was free, but you had to add your name to a list in an Excel file, placed in a shared folder. That folder was dedicated to social events, nothing else.

So, you want to play bowling? You want to add your name to that list? Ohhhhhhhhhh, dear... It's not like they can let everybody edit that file, can they? You have to ask for the appropriate permissions.

This is the procedure:

  • Open the company's site
  • Find the section with some modules ready to be filled in
  • Find and download the document called "Release Sheet"
  • Print it
  • Fill it in with your request and sign it
  • Hand it out to the secretary
  • The secretary will take all these requests to the manager in the morning of the following day
  • Sooner or later the manager will sign it
  • The secretary will bring it back to you
  • At this point you can scan it
  • Open the site used by the IT to handle tickets
  • Create a ticket describing (again) what you need, and attach the scanned Release Sheet. Don't forget to set the urgency, from one hour to two weeks.
  • Eventually the IT will do it (hopefully)

On average, it would take 3-4 days to get it done. In some cases, weeks. Really efficient, eh? Hey, you asked for access to a certain folder but forgot to mention the subfolder? HA! You've won another round! And, guess what? Since they were following some QA process, they were organizing documents in a lot of different folders. When a new colleague came, he could easily spend weeks trying to get all the permissions he needed.

Now.

  • Do you think the managers bothered to check what they were signing? Certainly not. They recognized the Release Sheet, and that was it.
  • Do you think the secretaries were checking much more? Maybe they tried, but can they really understand the implications of giving me read/write permission on a certain folder on a certain machine? Certainly not.
  • Do you think the IT gave a damn about the urgency? Certainly not.

So, what did this approach lead to? That if you wanted to steal everything the company ever made, you just had to bring in a USB drive and connect it to your PC. No access to that "Confidential_Documents" folder? Just ask for it, they will sign it. And if it's urgent? "Hi, I need that document but I can't access it, can you give me your password?"

So, this "security model" was incredibly slow, clunky and frustrating, and it didn't protect their properties at all, but at least no one could easily mess with the participants to the bowling event (obligatory xkcd).

Please don't be that company. As others have said: don't ask whether it's common (it is), just ask whether it makes sense. And the answer is: no, it doesn't, unless your company likes burning money.

  • And that's probably why my company decided to block USB drives... I assume their next step will be to physically remove them and give everyone a blutooth mouse & keyboard. – Carra Aug 07 '19 at 13:02
5

Yes and no - our senior devs do have a separate admin account that permits them to elevate when needed and install applications/updates. They are not permitted to login to the computer with the account though. Their admin account also permits them admin access to regular dev computers to provide quicker support than going through the IT team.

This is all combined with an application white/blacklist, strong password policies, removable device prohibition, gateway proxies, DLP policies, stringent AV rules and more. Their machines are routinely audited and the IT team visibility is high.

Personally, I'd prefer for the devs to not have local admin access. We could investigate the app(s) that needs UAC (find out the folders, regkeys etc that it needs) and mitigate the UAC prompt but that takes time and research and not all companies have the resources to do this. So, we meet them half way and expect two-way trust. We also use multiple corporate products to enforce a multitude of rules so there is some relief in that.

James
  • 161
  • 3
  • 1
    This does not answer the question. It does not give any explanation if or why this would be "typical". – Tom K. Jul 16 '18 at 14:46
4

We solved this problem by using a Virtual machine.

Every developer has an normals user account without any admin rights. Inside that user account theres a virtual machine without any internet access. Inside of the virtual machine the developer can run his application with admin rights.

That way we can separate internet access and important data from the use of admin rights while still obtaining a way to run the necessary programs in an enclosed environment.

  • 3
    Let's just assume the OP needs (Local) Admin privileges to run a development environment. The above mentioned Microsoft Visual Studio and SQL Management Studio for instance relies heavily on Admin Privileges. The other thing those software relies heavily (in terms of updates, online help, source control and I could go on for ages) is _Internet_ connection. Having a VM with no Internet connection but providing (Local) Admin rights means switching the rock with a hard place. – mg30rg Jul 19 '18 at 08:55
4

I'm in the same boat as your software developers. Our company recently went from workstations with admin access to virtual machines without. It was severely impacting our workflow so much that I times I found myself doing nothing but reading articles for the IT department to run something as admin for me.

The thing that management came up with was a two virtual machine approach.

One of our virtual machines was a basic business machine with Email, Web Access, and Microsoft Suite. This satisfied the need to communicate.

The other virtual machine had local admin rights, but was disconnected from the Internet entirely. That way, we could not download anything on that machine. (Although we could still download it from the other and copy the download over..) We still got access to internal sites and whitelisted a couple of things visual studio uses (Nuget, Symbols, etc..)

That approach left the IT department satisfied in terms of their security, while also giving us our admin access back.

The only negative thing is that we cannot use our dual monitors for just one machine since we needed each machine to be on their own monitor, but we usually just used one screen for code and the other for web browsing anyway.

Jimenemex
  • 181
  • 1
  • 7
  • 1
    This works for a basic Microsoft shop, but falls down when doing cross-platform development (Python, Java, Go, NodeJS - all have their own frameworks / package repositories / set of URLs that need to be whitelisted and can change without notice). It also prevents trying anything new - because you have to jump through hoops to get URLs whitelisted just to test something which you might not ever use if testing does not go well. Want to test out Meteor? Good luck, please submit a ticket to get URLs whitelisted and wait 2 weeks – Erin Drummond Dec 02 '18 at 22:52
  • 1
    @ErinDrummond Very true and one of the major pitfalls of this approach. – Jimenemex Feb 05 '19 at 15:46
4

Short answer: Yes, it is common to have local admin access to selected groups, such as developers or IT admins. Basically, people whose day job is a lot easier with admin access while the usual office worker would need it at most once a month and typically much less than that.

Long answer: It depends...

For the general user population, you don't need to run a full risk analysis to understand that admin access has a lot of potential for things going wrong and little advantages to offset that risk.

However, for developers (and a few other groups), a risk analysis is definitely warranted, and a proper decision on the matter based on the facts, circumstances, risk appetite and threat situation of the company is asked for. Pointing to "best practice" and doing a blanked one-size-fits-all move is a cop-out typically caused by the person(s) responsible for information security lacking the time and/or knowledge to run the numbers and come up with a risk treatment decision based on facts.

That doesn't necessarily mean that they are wrong. A full analysis could very well lead to the same conclusion.

At the point you are, from what you write, that is an unknown. You could ask for a proper risk analysis to be done, adding your expert knowledge to the cost of mitigation side of the equation, putting into numbers the lost productivity and other effects of the current measure. This needs to be weighed against the risk that the information security people identify.

There are also other measures that are related. One typical solution that I sometimes recommend (I'm an Information Security Architect by profession, so I get asked these questions on a regular basis) is to seperate the developer network from the ordinary office network to contain the higher-risk area. Harden the developer machines sufficiently and insist on local firewalls and up-to-date virus protection and you are fine against typical attack scenarios. If your company has some outside exposure, you might also add in additional awareness training for developers so they don't fall prey so easily to targeted attacks.

I've personally supervised developer environments of both kinds, and with a little effort both can be made to work well. Just pulling the plug on an established way of work was handling it badly and the backlash you were a part of was to be expected. But what's done is done and it is probably smart to not focus on that and look towards the future.

Tom
  • 10,124
  • 18
  • 51
3

Segregate Your Networks

You should have relatively isolated environments for development, testing, production, and business. This allows your devs to have privileges where they need them.

Proper segregation prevents unauthorized changes, restricts the spread of malware, and impedes the exfiltration of data.

What Happens Where?

Development

The development network is where coding takes places. Developers should have administrative rights in case they want to test code snippets or run something without packaging it for deployment to test/prod.

Computers run IDEs, source repositories, and prerequisite apps/frameworks for your apps. A dedicated collaboration tool or other dev-specific apps are reasonable.

Testing

The testing network is where compiled, ready-to-ship code is tested. Developers may have admin rights, but regular system admins should be deploying applications.

Deployments should reflect what the admins will maintain in production for internal apps. They should be customer-ready packages for external apps (including install wizard and digital signatures, albeit using a separate signature for testing purposes to prevent accident releases).

Developers often need system logs and debug access, and these are the only reasons they should have admin rights. They should not be involved with installation, configuration, and testing unless absolutely necessary.

Production

The production network is where you provide services to clients and partners. Since a formal deployment process should exist, there is no reason for it to connect to your dev/test networks.

To minimize risks of internet-borne malware and accidental changes, accounts from the dev/test/business networks should have no access to production if possible, which translates to limited permissions with occasional arguments in practice.

Ideally, this network would be completely isolated, but in practice this is impossible in a world where production servers must interface with systems for sales, billing, scheduling, netops, and project management. Get as close to the ideal as you can; it's really all we can do.

Business

This is the primary communications network for the enterprise.

Email, web browsing, and partner connectivity all bring a host of risks. Your development, testing, and production networks should be isolated from these risks to the maximum extent possible.

Details, Details, Details

It is possible that your organization went overboard. It is easier to swing the pendulum all the way over than to deal with the myriad details essential to a flexible, secure network architecture.

The developers can have admin access to their machines, at minimal risk to the enterprise, if:

  1. There are separate, unprivileged accounts for internet access
  2. Unique accounts are used in each environment
  3. Restrictive firewall rules/ACLs exist between environments
  4. Standard security measures such as firewall, web proxy, IDS/IPS, etc are in place

Your developers will need four accounts:

  • Unprivileged dev account to access resources on the internet (if they do not want to hop back and forth from the business network, which is onerous)
  • Privileged dev account to configure workstation and test code
  • Privileged test account to debug applications
  • Unprivileged business account for email, web, intranet

If you have developers do some validation or QA work, they may also need unprivileged accounts in the test environment.

Developers should have no access to the production network and no administrative privileges on the business network. If this impossible for the moment, then those roles should be separated or else a rigorous change control process should be put in place.

DoubleD
  • 3,862
  • 1
  • 6
  • 14
2

Despite MS-Windows NT having been a multi-user system system since its inception, its not really easy to operate it in such a manner, and developers (including Micosoft's) still tend to ignore the idea of privilege seperation. This kind of access control is poorly documented, tends not to feature in training, often difficult to access via the UI, hard to audit, lack of patterns/tools for applying the seperation....

In fairness, even on Unix/Linux systems, I see a lot of developers failing to use privilege separation appropriately both for real users and for services. But on any platform, placing barriers in the way of implementors seperating privileges is even more counter-productive for security than giving them full (local) admin privileges.

On the other hand, while I know little about developing on MS-Windows, I do find it surprising that local-admin privilege is required to run Visual Studio. And if the only reason you need admin access is for stopping/starting services or reconfiguring them then I don't have a lot of sympathy for you - possible to provide this facility to designated users without giving them local admin. One of the big changes in IIS7 was the delegated admin capability. And its always been easy to delegate reconfig of Apache, MySQL and PHP.

there was short notice of when the local admin access was removed

It sounds like the issue is the Security team aspiring to a level of competence they are unable to deliver (this, in my experience, is very common). They shouldn't have imposed a policy change without doing a proper impact assessment and considering mitigations for any harm to productivity/security.

We have at least 2 major antivirus programs on all workstations

That's a very naive approach to protecting the integrity of these systems and paints a picture of what you are having to deal with.

there doesn't seem to be much for alternatives out there

Getting into a discussion about that probably isn't going to be very productive at this point.

Overall it sounds as if you are in competition with your local security team. They don't understand what you need to do your job, you don't understand how to meet their objectives. And it seems like neither side is willing to negotiate. No off-the-shelf tool is going to fix that.

symcbean
  • 18,278
  • 39
  • 73
  • 4
    One reason Visual Studio these admin rights is to enable debugging of processes, owned by other users IIS traditionally runs under a system account. As soon as the developer debug another process they could disable virus checkers etc the heads removed in 90% slow down that is not uncommon from them. Hence the choices between not letting the developers use the debugger and trust in the developers..... – Ian Ringrose Jul 17 '18 at 08:46
  • 1
    ....and then I remembered why I avoid doing any programming on Microsoft Windows :) – symcbean Jul 17 '18 at 10:37
  • 2
    Factually incorrect. Visual Studio will run without local admin privileges, and in fact that's **the default**. And if you assign debug privileges to the developer accounts, that means Visual Studio will not need to elevate to admin permissions that often. Is it entirely avoidable? No, driver developers will absolutely need admin access for instance. – MSalters Jul 17 '18 at 12:56
  • 2
    Visual Studio *will* run without admin privileges, but in some cases it won't run _properly_ without admin privileges. Yes, it doesn't need all local admin privileges to run properly, but needs certain admin privileges. DEBUG_SE for debugging, service management for - well - managing services, Create rights for databases and I could go on for ages. Of course one could contact the security team and require the certain rights one needs on a - let's say - daily basis, but do you know how it's called? Productivity-murder. – mg30rg Jul 19 '18 at 09:12
  • @mg30rg: DEBUG_SE actually means "Debug somebody else's process." – Joshua Jul 20 '18 at 15:45
  • 1
    @Joshua And what do you think is required to debug a windows service running under System account for instance? This scenario is far from uncommon in Windows development. – mg30rg Jul 22 '18 at 15:10
  • @mg30rg: True, however if the developer is working on code that normally runs as admin, then he has admin anyway. – Joshua Jul 22 '18 at 15:30
  • 1
    @Joshua M-key, and what about ASP.Net development? For that you need to debug a process started by and running under the IIS service running under the Network Service account? – mg30rg Jul 23 '18 at 09:06
  • @mg30rg: Obsoleted by Kestrel. Now it runs under the developer's name. – Joshua Jul 23 '18 at 13:28
  • 1
    @Joshua Kestrel is hardly IIS. – mg30rg Jul 24 '18 at 07:30
2

It is only typical to have local admin access denied to devs in companies where either the devs are so useless/malicious they abuse those privileges, or where the "IT and Security" department is run by clueless knee-jerk idiots who view everyone not in their inner circle as an obvious security threat out to make them look bad.

Considering your "IT and Security" department also mandates two anti-virus programs when Windows comes with a perfectly good free one, I'm pretty sure you can determine where the problem is in your organisation, and work from there.

Ian Kemp
  • 229
  • 1
  • 12