This is exactly extremely common. In my company there is this constant battle about the devs having admin rights on their machines. We need admin rights to do our job. We have had dozens of meetings explaining the situation but IT can’t come up with a solution so the devs go around security because they have no alternative if they want to finish their work . Same with Dropbox. They block it but we have suppliers who use Dropbox. So the result is that people download confidential files from Dropbox on their home computers or phones and transfer them to their work machines.
In my view security shouldn’t be isolated at corporate headquarters but they should be close to the end users so they see what users need to do and help them to balance security with getting things done. They can’t just block stuff without providing alternatives or they will either hurt the business or they will be circumvented.
I'm one of those assholes that makes security policy. I deal with the same requests. The problem is, I write up a proposal identifying the risks associated with the exemption, along with minimum and recommended compensating controls. This then gets discussed among IT Management, where it is usually decided it's too much overhead, and to just deny the request or if the user can scream loud enough, allow it outright and get some director to sign something. The third oft-used response is ignore the problem and hope the user finds their own work around so we can get back to the 13 projects we're somehow expected to complete this quarter.
It's an incentive misalignment. IT is evaluated in 'how secure things are' or 'how easy is it to maintain' or 'does this give me more headcount'.
Not letting people do their jobs, or in how fast they can do their job. Employees are a captive audience, and if there was competition they would probably chose something else.
> It's an incentive misalignment. IT is evaluated in 'how secure things are' or 'how easy is it to maintain' or 'does this give me more headcount'.
I tend to summarize my experience with IT in large companies and universities like this: IT is evaluated in "how secure things are", or "whether things are not broken". The only sure-fire way to ensure a system is secure and not broken is to make it completely unusable, so that people don't use it. If people don't use a system, they can't break it!
Our outsourced IT has KPI's for closed tickets, so they are very keen to close any ticket for any reason. Then it is up to you to call and restate everything to first-level helpdesk again to reopen a new ticket in order to actually get things to happen, and thus they end up closing double the number of tickets.
Never mind that it took double as long, and sucked the life out of everyone subjected to the system.
We attempt to address this by making IT's annual bonus tied in part to our dev's project completion. It's not perfect, but the heart is in the right place. A big problem with this is that when we're dealing with limited manpower, we'd rather throw it at the easy issues than the hard ones, and ultimately get more things done.
Maybe create a 'time wasted' ticket system to help quantify employee hours wasted by IT roadblocks? It smells like it could be gamed heavily, but it might work better.
the same should then apply to "adopting the tool to the process" instead of "adopting the process to the tool" when a new technology is implemented but process and behavior are declared immutable.
It's proprietary software (adobe, apple/microsoft, autocad, etc) and they file it as a no fix. Or it's open source and it will take $30k+ in engineering time to change it and $100k+ in time wasted waiting.
Now what.
There is also an inversion of responsibility here. It really should be IT's job to 'adapt the tool to the process' instead of externalizing it to their staff. Until they can do it, the staff needs outweigh the lazy 'default no' of IT.
if you buy a new erp, and it comes with a set of best practice process, and your management and employees all insist on transposing the new process onto the new software, in some cases why even buy the new software. its a different coat of paint on the same thing. youre buying a new erp for the change in process, but you refuse to adopt it.
I worked at a very bad company, where IT was aggressively incompetent, and mean about it. At best they were negligent, at worst they actively interfered with anyone who they thought was a threat, which included anyone who was more intelligent than them, which was virtually everyone since the company was full of senior EE/ME/RF/CS folks.
And I mean incompetent-- our network would go do down for hours, every day, and the problem lasted almost a year. It got so bad our "source control" became yelling "Whose got the latest main.cs?!" and walking it over with a USB key.
I realized we needed to disintermediate the IT group, and my boss was supportive. I ended up establishing our own, parallel IT department with a business cable line, some routers, and NAS devices. I outsourced any task to any cloud service (this was over a decade or so ago when that was somewhat unusual) — eventually hiring our own IT person even. People would ask for access to our network because it was more reliable :-)
Then things got vicious. They actively interfered with our group, trying to get us fired (they had some success with this previously). They were able to get our IT guy fired. Things just went on that way for years. They'd find some way to make trouble, and then we'd route around it. Once they even took my computer for two days, denied they had it, then returned it but locked me out of it. I was certain this was part of some scheme to get me fired, so I turned the computer off, zeroed the hard drive, and req'd a MacBook to work on.
They all eventually got fired when someone took note of their gross incompetence. One of their replacements was eventually fired for embezzling, proving that despite thinking we had the worst IT department anyone could imagine-- we really didn't.
Firstly, we had an exciting product to work on. Also, for selfish and foolish and stupid reasons? First of all, I was young. This was my first big gig. Most of all, it was fun. It was fun to keep winning against a determined enemy. At the time in the area I was in, we were considered to be one of the best software groups in our geographical locality. There wasn't really anywhere to go. The employer always ranked as one of the best in the county. Lacking humility, I thought it was simply my intelligence that brought the wins, not a mixture of my intelligence and mostly good luck. I can't imagine how many times I almost got fired but didn't for some reason.
To look on the bright side, my boss was amazing, a truly unique individual whom I thought so much of, I asked to be the godfather of my child.
Despite the chaos of the IT team, almost everyone I worked with was great. Everyone I met was really good at something, but I learned a lot from the people around me and had the opportunity to mentor a young engineer who ended up far exceeded me, which was rewarding in itself. I have several life-long friends from that company. People who have been with me through a messy divorce. A particular friend, when my wife left, called or texted every single day for six months-- just out of the goodness of her heart. The text was always the same, "Hey, wanna get some coffee? How are you doing today?" There are beautiful people working in even the most toxic places.
When I wasn't learning about engineering, I was learning about optics, about politics, and about the real world, and once again, I was winning, which was intoxicating.
So why ultimately did I stay? Because it was comfortable being the smartest person in the room. Because it was fun having latitude enough to start my own department? Because it was fun being engaged in this real-life game and winning? Because I'm crazy?
Things got far nastier than I went into. Once the IT department was openly trying to get me fired, things got personal. Really personal. It would have been easier to move on, but, I hate being bullied. Allow me to repeat myself, I HATE being bullied, and that's what this was in the end, organized harassment.
Through a set of unusual circumstances, I ended up befriending the main IT guys wife-- the man who decided he could play with my life for no reason at all, and his wife had a crush on me. So I and slept with her, and I am still sleeping with her four years later. To quote that great boss of mine, "Revenge is a dish best served every day."
No job is interesting enough that I would tolerate targeting and succeeding in firing a productive employee for internal politics. Doubly so if that behavior is coming from a department nominally in a support role. That's a dog to be put down.
Maybe, but it's that type thinking that permits the behavior in the first place. People built the workplace and people decide what is acceptable.
Deciding to leave doesn't mean put in your notice. It means look elsewhere. Leaving a job without another secured is always precarious absent a nest egg.
I have my own PC strapped under my desk connected to public Wi-Fi. I use it to do all my work. My company pc is left turned on but disconnected, sitting on top of my desk to dissuade suspicion.
I have a WiFi router hidden so we can do some specific network testing. We also have a consumer DSL line so we can test on a network where IT doesn’t block random stuff. It’s not even much of a secret. Everybody local knows this stuff and every six months a guy at IT headquarters throws a fit, doesn’t provide an alternative and gets ignored. I have thought about sending them recordings of previous meetings so we don’t have to repeat the series of same meetings every six to twelve months.
We had the same kind of "hidden" router at my previous employer, as we had a team of ~10 developers who needed a lot of different access to different servers and between eachother. We put the name of another tenant in the office building as the SSID :).
After about a year the network through that router started to slow down. When we checked why we realized that we had more than 40 wifi clients, as other (non-dev) teams learned about the network through the grapevine and actually the new employees from sales (the neighboring office) were told to connect to that network directly - as the process to connect to the "normal" network was too much of a hassle.
The funny thing is that after a recent remodel the router got moved and we don’t know where it is. It still works but nobody knows the exact location. It may be in the ceiling or the floor.
That reminds me about the story of a University that an old DEC VAX that got walled up during a remodel. Machine kept running and no one notice. A decade later another remodel came along and they tore down the wall to find the machine just happily running.
It’s not highly confidential information. Mostly its to use a machine with adequate ram. Besides I’m using end to end encryption instead of being MITMd by their third party ‘security’ gateway
I've consulted for a big bank which blocks most file sharing sites and also blocks you from attaching scripts, server logs, etc to emails.
Luckily, S3 is not blocked. I set up a bucket and have them upload to the bucket, which I then download on my own computer. Mission accomplished.
Just getting free Windows applications procured and installed on the company laptop takes several layers of approval, emails back and forth, etc. Also the lovely forced password resets every 2 months.
This is true for the banks I've worked with/at. Security systems actively block you from the tools you need to do your job, let alone get the job done in an efficient manner.
I work for a local government department. Must try your S3 workaround.
I swear sometime I think our IS dept are playing jenga, they just pull random services at will.
Today I couldn't update our website because the proxy settings allowing me access the login page somehow changed without notice. Last week they blocked USB access to machines without telling anyone who backs up to external 8tb drives. Tomorrow who knows what they'll decide.
And it doesn't make for a secure environment! Everybody tries to figure out workarounds. Staff actively try to undermine security policies. It's a total disaster.
You can switch it to any port you want. Problem is that it's super easy to spot on security monitoring tools. I deal with "SSH not on port 22" alerts at least once a month.
It's possible to get around this by tunneling SSH over other protocols: http://dag.wiee.rs/howto/ssh-http-tunneling/. Bear in mind if you do this in a corporate environment, security will throw the largest book they can find at you.
I used to work at a place like that, it was incredibly frustrating and time-consuming. So I came up with a solution that works even if S3 is blocked: I built https://github.com/OkGoDoIt/UploadAndPaste and set up SCP file hosting on my own server that listens on port 443. (They blocked most outgoing connections to non-standard ports and did MITM sniffing on any port 80 traffic, so this was the only way to get through.) Then I could just easily "paste" a file to a my remote server and download on the other machine via a url.
Be careful. I work for such a bank, and even secure traffic is MITM’d when possible. There are data loss controls in place to analyze outbound traffic for things like source code.
Just because you’ve circumvented IT’s blocks doesn’t mean you won’t land yourself in hot water.
I'm still not sure why developers aren't on their own network for development. Have a red box / blue box type system at the developers desk. Given modern networking, it wouldn't actually be that hard to setup and keep development / integration / system tests (or what names you use) away from a locked down production would not be such a bad thing[1]. Having some dual homed file shares wouldn't be that hard either.
1) I would probably still use different terminal color schemes, but being in front of a different physical box might be quite a good thing.
Developer data can still be confidential/sensitive, so you still need to monitor and control this second network with many of the same restrictions as the main one. You still have most of the same risks to compensate for, like data exfiltration and cryptolocker, etc.
It doesnt introduce that many positives for lots of admin overhead, not just in maintaijg two distinct networks, but also in ensurijg interoperability when needed.
Do you? Why can't you let developers admin their own network? At least some of them will know how to do the bulk of the work and a lot of the typical admin needed for Windows machines won't be that important for them (how often do they need to print something and how many of them would be unable to handle printer drivers themselves)?
It doesn't introduce that many positives for lots of admin overhead
For the IT department sure. But I'm 100% convinced a big reason tech firms exist at all (given that every company uses "tech" in some way, right?) is simply that they know how to manage developers and make them productive. And IT policy is a huge part of that. Sure, the developers might be 1% of a typical non-tech business but they are the 1% that can give you a competitive and productivity edge, so their needs are in many ways more important than other types of employee who may not scale well.
> Why can't you let developers admin their own network?
Being a good software developer doesn't mean you're a good network administrator or good at desktop support. And even if you are, a developer is paid more so it's a poor use of their time.
I'm all for devs having admin access on their own machines, there are too many instances where it's needed, and reasonable exemptions from default policies when they conflict with their work. But a "conflict" would be things like anti-malware software making builds fail, not merely making builds 10% slower.
> But a "conflict" would be things like anti-malware software making builds fail, not merely making builds 10% slower.
Given developer salaries, a friction like making builds 10% slower is hemorrhaging money. And it gets worse if someone is actually waiting for the software to be delivered, and the amount of money the company gets is correlated to keeping the schedule.
If you have a group of developers, it would probably be a decent idea to have at least one sysadmin dedicated to developer services. It would go a long way to make build deploys go a lot more smoothly.
They tend to make builds 2x-3x slower, and the solution usually ends up being 'don't scan git directories and build software' or similar solutions that make them effectively useless anyway.
Developer data can still be confidential/sensitive
Yes, there are confidential data, but it shouldn't be any real customer data. Right?!? Frankly, given best practices from professional developers, stuff like cryptolockers just aren't an issue (blank the machines). Developers need admin, so building a network for them is actually a lot easier.
> Yes, there are confidential data, but it shouldn't be any real customer data. Right?!?
But it might be. Whenever you're doing software other than for purely internal use, you have a customer that gives you sensitive data which devs absolutely need access to - like requirements for the software you're building!
If you're handing customer data to the developers, it's basically already leaked. Most companies limit who can examine things and get customer sign off first.
Let me reiterate: unless you're doing purely internal tooling, everything about how the software you're making should look and work is essentially sensitive customer data.
My personal anecdata is that I've never worked at a place where I couldn't trivially exfiltrate real user data and source code without being traced. This is 20 years across defense contractors, banks, insurance companies, etc.
I understand your argument and in principle I agree with it, but in my experience nobody cares all that much about the data on the primary network, so creating a second network that grants devs things like local admin doesn't seem to increase risk by much.
Shouldn't this kind of thing be a problem for the managers to address? If you just circumvent this kind of nonsense instead of addressing it head on it just proliferates and allows the people who promote it to think they are doing an acceptable job.
At minimum you should inform your direct manager of the situation so they can address it or accept the consequences that the work that depends on the restricted resource won't get done w/o circumventing company policy.
I've heard security management say it is their job to say no all day. They definitely don't care about preventing work getting done. They will only get fired if a data leak occurs, etc.. Preventing work won't even ding their promo outcomes.
Whenever several people of a profession work together in one location, they tend to form a Guild. My dad couldn't plug something into an electrical outlet without having an electrician do it. This is human nature, and is as old as the hills.
The opposite scenario also happens. When security management's job is to never prevent work getting done, their inability to say no to even the most abusive practices can become an issue.
Cloning a production database full of private customer data for testing? Well, we can't interfere with a practice that gets features shipped and the team doesn't have space on their roadmap to build out synthetic data...
Incentive structures always tell the tale, and people have a nasty tendency to figure them out quickly, regardless of what their mission statement says on paper.
That's the point of telling your manager and letting them deal with it. Ultimately the business needs to make money or show some result. If the company policies prevent that then their cost benefit needs to be evaluated and that is a manager's job. "No" is fine as long as a conscious decision is being made with the consequences in mind. That way your security person isn't saying no to Dropbox access they are saying "No" to the successful implementation of the CEO's #X priority for the quarter or "No" to 10% additional revenue for the company or whatever.
> In my company there is this constant battle about the devs having admin rights on their machines.
One company I worked for had two lans. The admin lan and the engineering lan. Your admin machine would always work. The eng lan could go to hell, and it/management wouldn't know/care.
I think it worked well. It was kind of like having the common areas of the house neat and tidy, but giving the kids creative control over their rooms (and being able to close the doors when things got out of hand or guests came over).
> In my company there is this constant battle about the devs having admin rights on their machines.
I ended up leaving my last job over this and more stuff like it. They had a url filter in place for instance, that would randomly block access to our network resources. It would never be the same one so every now and again your stuff would start failing and you would lose a few hours debugging until you realized.... GAH! Then have to email and lose the rest of your day waiting for them to fix it.
I really wish some big shots in the security world would write an ISO standard or something stating how harmful blanket 'block Dropbox' policies are for the reasons you list.
The "dumb" here isn't even limited to "block Dropbox." Lots of my customers have blanket "block everything that could plausibly be used for file sharing" policies, and explicitly include services literally AIMED at corporate/B2B data exchange like Citrix's ShareFile.
No, we don't have an internal FTP site. No, I won't set one up for you. We use Sharefile for distribution so we don't have to do that. Your IT blocks it? Yeah, that's dumb. Go talk to them; it's not my problem. We're not going to do customized delivery channels just because your halfwit CIO decided to block every site with an upload button.
The issue here seems more cultural than technical - it seems non-tech firms are vastly more paranoid about data sharing or leakage, despite usually having less valuable data. The amount of effort put into anti-exfiltration measures in finance is staggering compared to what existed at Google, and it kills productivity to an enormous degree.
This seems to go hand in hand with a much greater obsession over IP. I've seen people actually threaten to start legal fights over whiteboard diagrams of little to no meaning at all. My guess is that outside the tech industry, new ideas are relatively rare so even very simple ideas feel incredibly valuable. This gets generalised to anything employees produce and is why there's no culture of open source development in most traditional industries.
Not really no. I'd guess most tech firms have far more ideas than they can ever execute on. Ideas are cheap. Implementations are expensive.
See how all the big firms file gazillions of patents but actual patent infringement suits between them are quite rare. Patents are seen as a defensive posture: everyone knows everyone violates a million patents so by and large, mutually assured destruction is avoided. In a world where ideas were rare you'd see patents be treated as much more valuable.
Put it this way: if all our engineering design documents and presentations leaked, our competitors would get less value from their contents than they would have to spend on the reading.
The funny thing is that they block Dropbox but then there are plenty of shady upload sites that aren’t blocked. We don’t use them because we think they aren’t secure but our IT guys would have no problem with that.
That highlights a problem woven through the industry which is that the IT department isn’t always the sharpest team in the building, even on security matters.
It's worse than that. I haven't met an IT person yet that wasn't as smart as the developers they worked with, except in slightly different domain. But the incentive structures are aligned in a way that makes IT's real job to execute cover-your-ass directives which freeze work. Doing the right thing is literally the opposite of what IT is being paid for.
And they should commit to talking to my VP every time the VP commits us to working with a supplier who uses Dropbox and also commit to finding solutions that allow us to get our work done within deadlines.
There’s nothing wrong with a block Dropbox policy. The problem here is a failure to establish a standardized method of transferring files in and out of the company.
I have rarely found that they need admin rights on a day to day basis unless the tool is badly designed. I have one software delivery platform that requires full admin rights, it cannot write just to the user configuration!
However developers are very good at presenting it otherwise. Myself, I have run into issues where admin rights were needed, again always because of some poor installer. USB has been blocked as well and you can guess it, cannot do their work.
If they need admin rights all the time then put those particular machines on a protected network and not allow any other business work to occur there.
I think it really depends on what kind of development you are doing. I worked at an IC company, and among other things we developed (and tested) USB drivers for our devices. We installed them on literally hundreds of windows machines for testing before they were signed/ whql approved. This happen all the time. So really no way do our jobs without admin passwords. We did have the machine on isolated networks, but even on the regular networks many of the team member frequently would need to hand install drivers. This is just one of many examples. If you do anything even remotely hardware related, it can really be a totally different problem. We had IT installed USB filter drivers (we were not told about for security reasons) that actually broke a lot of testing in our labs and it took us months to figure out.
On Windows you often can't even predict if you need admin rights for something. I have had plenty of cases when I tried something and couldn't get the f...ing thing to work. Then try with admin and suddenly it works.
The problem may actually be compliance requirements. SOC2/HITRUST/SOX all mandate the removal of admin rights from computers, mandate an approval process w/ manager approval. Regulated industries, especially banking have more security-related compliance requirements causing a lot of the pain.
Unfortunately from a security perspective devs and system admins are probably the highest risk targets since they typically have access to servers and admin rights. At the very least they have source code an attacker could analyze, and likely have access to external services.
The reality is that compliance, security and usability are often in direct conflict that can only be solved to make everyone happy with significant work.
> SOC2/HITRUST/SOX all mandate the removal of admin rights from computers, mandate an approval process w/ manager approval
I’ve heard this before, but never with any detail. Can you explain further, or point to a resource? For example, clearly SOX doesn’t say that nobody can have admin rights - because IT does. And I highly doubt that the law says that only departments with IT in the title can have admin access. So what does it really say?
SOX doesn't actually say much about IT at all. It says mostly that you need internal controls to maintain the integrity of financial information. Anything more specific than that, around IT, is just someone extrapolating out what they think a good set of internal controls are.
Mostly when you hear "because SOX", that person has never actually read the document.
tyingq summed it up tersely pretty well in the sibling comment. Specifically for SOX, it is all about financial information, but that information is stored and manipulated using computers, so IT related controls end up being part of it. It's easy to get away with sourcing your controls from an industry standard list of controls appropriate for SOX, but these are often significantly behind the times and don't acknowledge the state of the art.
These things are all based around "controls", which sometimes can be specified locally and some times are set by outside entities.
In my experience (SOX evidence collecting, and SOC control writing and evidence collecting), a well written control is one that covers the bases without being overly prescriptive or ambiguous. In the case of admin rights on computers, it is more useful to have the control be worded as "Only appropriate people who have legit reason to have high levels of access do" and the audit step is confirming and providing evidence that the people who do are documented and approved as having it for specific reasons, and that people who aren't supposed to have it don't have it.
I've run into crappy controls quite a bit. It's easier to push back on these when you're determining the appropriate controls than it is when you're the sucker who has to collect the evidence that doesn't, and won't, exist. Authentication and authorization controls are often some of the worst. A less useful/less meaningful control is one like "all accounts must have passwords and all passwords must be at least 12 characters long and be composed of a mix of alphanumeric and at least two punctuation characters".
The goal is to say "yes, we do this, and here's the proof" without any qualification.
Sorry, none of our accounts have passwords because we disable password authentication and use ssh public keys for authentication with two-factor via Duo. If you say that, you don't satisfy the control as worded (because none of your accounts have passwords, you can see this in the shadow file and sshd has PasswordAuthentication no, and this is difficult to explain to people who are not familiar with ssh, which is, unfortunately, a significant portion of the people who end up being put on audit projects). If you say that they do have passwords, you're lying/misrepresenting, which isn't good for an audit either. If you say you don't but have compensating controls, this doesn't look as good as it could because it is called out with an addendum/explanation and is a potential exception that needs extra consideration.
These controls should be worded more like "all users have their own accounts and accounts are authenticated using secure methods" with sub-controls specific to the environment/company saying things like "password policy is based on NIST suggestions as of YYYY-MM-DD and enforced via <company-policy-compatible enforcement mechanisms>". The point of the controls is to detect, catch, and re-mediate anomalies, it is for this reason that the controls need to be adjusted as standards change and the state of the art moves forward. The specifics and rationales for why something is in place is for policy documents, which means people usually don't understand why a control is worded the way it is and poorly worded controls make for really rough, drawn out audits.
The cargo culting is unfortunately too true. SOX/SOC reporting exists for a reason and it's actually pretty easy to get real value (which is the intent) out of it, as it formalizes what you should be doing anyway. It's a really good feeling when appropriate processes/controls reveal things that fell through the cracks and they get remediated. Prepping for and performing a successful audit needs to involve the company's subject matter experts from multiple departments. If only the CFO is involved early in the process, it makes life harder for the CTO, CISO, and CIO (or whoever they delegate to) later on.
I think most of the reasons for admin rights are no longer valid. Its easy to change user environment variables and lots of applications can be installed as a user. Why would you need admin rights?
Dropbox/googledrive is a huge security hole that is definitely blocked at most companies I work at.
This is about Windows desktop development. I need admin rights to install sql server, I need them to customize my machine so it’s similar to our target environment. I need to change user permissions all the time yo see how things behave under different conditions . There is a ton more I could walk you through and have done multiple times. Comments like yours come repeatedly from people who don’t know about the work we do. I have offered them to demonstrate doing our job without admin rights but so far nobody has even tried. They just keep sending the same email about not needing admin rights which has repeatedly been showed to not work.
Being punchy about it you've never moved on from thinking you need admin rights on your machine. Chocolatey for Business' self-service installer, SCCM jobs, and a variety of other tools exist to enable you to get specific things that require elevation executed. If you're changing things to test various configurations wouldn't it be handy to have those scripted, get them peer reviewed / linted and you've got yourself the start of a process to get that script executed on demand.
This stuff isn't that hard - but those of us doing it see the mad things that people do when they're given blanket, even time bound, admin access. They're the ones dealing with the support calls when then every SQL Server installation has been done differently with no details of what specifically was done. IaC works.
Then I hit another 'no-admin' roadblock, that requires a day or weeks of hostile IT bureaucracy and the IT department has just wasted another +$3000 of employee time. This behavior might drive them to quit, leading to a premature +$30k recruiting and on ramping cost to replace them.
Now iterate that over 1000s of other instances and you see the financial reason why devs need admin.
Have you ever considered that some people are themselves writing tools like Chocolatey that inherently need elevated rights? I am working on a Windows service that needs to be elevated to work. In addition I need to change TPM keys and change registry settings in the machine hive. The SQL Server installation is local and IT will never be bothered with it. Just let me install it.
Out of curiosity, what's the benefit of me doing bad things in a VM, instead of on my own machine - assuming the VM has full access to the same networks and data as the physical machine?
Unless the VM is somehow sandboxed it's just another box on the same network. So the same reasons for me not being admin on the physical machine (e.g. to not be able to download and run untrusted software because it might spread something on the network) should apply to the VM?
Of course the VM is isolated. That's exactly the point of a VM.
An account inside a VM will only let you play in that VM.
Whereas your account on the host is available and automatically granted access to all machines, fileshares and services on the active directory network. If it got admin rights, then you've got admin pretty much everywhere.
“Whereas your account on the host is available and automatically granted access to all machines, fileshares and services on the active directory network. If it got admin rights, then you've got admin pretty much everywhere.”
Nonsense. You can have local admin rights that work only on one machine.
Nonsense, there are endless ways to escalate and pivot once you get local admin.
That being said, there are indeed restrictions that can and should be set on admin rights. Not that IT would know about it or that it would limit pivoting much.
Let's assume for the sake of discussion that to do what I need to do I not only need to install the program that requires priveleges, I also need a few of my company network drives mapped, access to some company systems, internet access and so on.
If you want a proper dev environment that matches your target you need a proper server to have sql server installed on. I'm pretty sure someone can install sql server on your workstation if you really need it. User permissioning is a dbo task. After that you just have to live with it like the rest of us.
You sound exactly like every other IT guy who doesn’t understand what we are working on. We then explain everything to them and usually they disappear and are never heard of again. That is, until the next guy shows up a year later and the cycle repeats.
Corporate IT can admin the box for corporate training PowerPoint gunk. You get another box to run what you have written, and maybe another to run the development environment. Those don't go on IT's network. You can run a private LAN around the office, not connected to the outside world, in which you break things as you please.
This solution is even good enough for people who are intentionally dealing with malware.
I was a dev in the 90s and the start of the 2000s and always had admin rights. I dont need it any more. If you really had an edge case that requires admin rights I'm surprised. If you really need SQL server on your workstation you should think about using a different database. If your company says you have to use SQL server and you have to have it on your workstation and you need to reinstall it regularly and you're obviously screwed you go up the management chain with your unsolvable problem that breaks their policy. Is very unusual now - most people just moan they want admin rights when they can live perfectly fine without it.
It will be really hard to argue for a complete redesign of a medical device app, complete retesting and waiting for FDA approval only because some guy at IT doesn’t like the devs to have admin.
You're basically saying, "I don't need admin rights anymore and can't think of reasons why anyone else would, so clearly you're wrong, don't know anything about your work, and don't need admin rights either".
Try running Visual Studio without admin rights and you will weep. Regarding other rights, I tried to onboard a new Dev without admin rights, however, after the 25th IT ticket (that take days to get done), I gave up.
I run Visual Studio without admin rights every day. But, if you're doing driver development, working with older IIS, certain parts of the registry or developing installers then yeah you're going to have a bad time.
I'm not sure if your "almost ten years ago" is meant to be hyperbolic, or genuine... I can't even remember why, but I know the project I was on 6 years ago definitely needed visual studio to have admin access, and it was all standard C# app stuff (maybe WPF?)
Are you prepared to supply the appropriate servers out of your budget and provide resources for managing the server while guaranteeing acceptable uptime?
One example off the top of my head: It used to be (may still be) the case that you needed admin rights to install and run the Windows Subsystem for Linux. Sure, you might not need this to do your job, but IT is not really in a position to decide that. It could be that WSL greatly increases your productivity.
Precisely! And then they'll get it wrong (or worse still say they won't do it the way you ask even though you will know better why those choices are needed!)
> lots of applications can be installed as a user.
Because most of the non-insignificant ones still CAN'T be, under Windows, to this day. So special people get a completely separate account with pseudo-admin rights. I have to enter those credentials several times a day.
Then I spoke to a help desk guy, who said he had to enter his domain admin account password 40 TIMES a day.
In my view security shouldn’t be isolated at corporate headquarters but they should be close to the end users so they see what users need to do and help them to balance security with getting things done. They can’t just block stuff without providing alternatives or they will either hurt the business or they will be circumvented.