It's necessary where the relationship with IT becomes adversarial, often with IT that's less skilled, or more constrained by their management.
Where possible though a mutual beneficial relationship is best.
Where I work I have two laptops. One is my corporate laptop, less powerful but it can connect to our internal network. The other is my dev laptop, more powerful but it can only connect to Internet and our dev network. I can install whatever I need on the dev laptop, as long as I a) keep a running log of installed software and update IT when that changes, b) regularly check NVDB for the software I have installed and apply mitigations as needed, c) keep versions updated to current versions where possible (and never to versions that have known vulns).
If you think you're in a position to change it and you're motivated to do so, go for it, otherwise my experience is that you're better off finding somewhere else to work.
I've seen too many companies set up systems that you cannot be in compliance with but there is no punishment for non-compliance unless they are looking to get rid of you.
At my workplace apps are whitelisted and it's honestly not a big deal. Very rarely do I find myself in a situation where I can't access the tools that I need.
My experience, after working in many big and small companies in several countries and multiple continents matches perfectly what the above poster has said, i.e. at least for any kind of design or testing work that involves external hardware, the only way to get anything important done is to circumvent any restrictive IT policies, which are always made by people who might have worked in a bank, so they have no idea about how a computer is used for designing or testing hardware or software for embedded computers.
Most of the work that I have ever done could not be done on company-managed computers, so I usually had to do it on my own computer and transfer then the results to the company computer, which was used only for communication inside the company, through e-mail/Teams/internal file servers etc., and for writing reports or other documents.
The approach normally doesn't count project local tools which don't install like normal applications. E.g. some frameworks you install into your project instead of having user or system wide installations (e.g. with npm for web-dev stuff).
I know that for embedding computing a lot of tools which are normally ad-hoc project installations are instead system wide "normally installed programs".
But that isn't the case for most software development fields. In many other fields that new tool-chain you want to try out is just a dependency you add to your projects dependency management tool. And keeping it up to date is done in the same way you keep your other dependencies up to date (e.g. a scheduled CI job checking for updates).
Rootless OCI (docker) containers can help with that. But embedding also often touches on driver aspects so it might not be an option.
Anyway if you ignore embedding programming, parts of system programming (e.g. linux kernel), some legacy software and some cases of important C/C++ tools needing too many permissions nearly all other programming jobs should be viable on a locked down system as long as you have the right not too big set of tools preinstalled and access to rootless containers (independent of weather they run in a VM or not).
EDIT: formulations, for clearity
But when it comes to the aspect of managing updates, project specific installs are better.
And when it comes to security then the answer for both installed and project tool-chains is: Sandboxing.
- run your toolchain in a container
- run your IDE in a different container
- run hardly trusted tools in another container
- use reasonable phishing proof 2FA (i.e. FIDO2) for authentication, use authentication tokens.
This applies to "normal" applications, too. They also should run in their own container. Just because it has an installer or is signed by a company or is on a app store doesn't mean it's trustable.
Thats one of the things phones at least somewhat got right, their apps are containerized by default (through they might give too much permissions to apps but that's a different problem)
Furthermore if possible stand alone tooling which tend to not be very version sensitive can be nice to not include: E.g. git, npm, rustup, pip and similar are preferable system installations.
Furthermore frameworks and similar tend to go through the package manager and whatever update handling you have for it. But a drop in IDE likely would not.
Ouch.
I wonder if those apps are one-off for particular task or you just find so many useful apps every day. Anyway, Windows now features Sandbox mode - a great place to install untrusted apps as the sandbox is discarded on close. https://learn.microsoft.com/en-us/windows/security/threat-pr...
I found it to be a better strategy to start from a prioritised list of risks and tackling the high priority items in an actually meaningful way. But I can see how that doesn't work at companies with >300 employees - at one point security just pushes for whatever they can get, disconnected from the true needs and relevant risks at the company.
Almost every day. Sometimes multiple times a day in case of a new project / new embedded hardware (toolchain) / new devkit to "quickly test" / tight deadlines, etc.
> If it is a regular occurrence then you need a process by which you can request it and the IT team can assess how they manage it.
There isn't. It has been attempted to get such a process multiple times over the past years. With and without escalation to higher ups all the way up to the CEO. The IT team promises they'll speed things up, but a software approval for 1 app still takes at least 3 months. Now what?
I'll tell you now what: employees and contractors alike just start using their own fully unlocked (perhaps badly updated) machines out of desperation and transfer files to and from locked-down company machines using email or onedrive or whatever other means possible.
Maybe better companies exist?