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?
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.
Brew is a pretty regular part of my workflow, although that's more often restoring the environment after an IT-mandated OS upgrade than net-new software.
Also there's a couple of thousand third-party dependencies in the monorepo, seeing ~100 changes per month.
I'm grateful that engineering workflow is managed by engineering platform teams... corporate IT is a totally different beast, and it'd be pretty dysfunctional if they micromanaged this stuff..
> Realistically, how often do you need to install brand-new non-standard software?
There is some cognitive dissonance happening here.
I think the two lines actually work together. If the IT team works with the users rather than against them, the friction of adding new software is "low". It is, of course, strictly higher than if the user can just install whatever whenever.
But, GP posits, this increase (from "none" to "low") is further mitigated by the fact that, in practice, this friction-generating need does not arise often.
I don't think I've gone more than one week in my professional live without installing some sort of new executable on my dev machine. How do you test out software/libraries before you use them in a project? Do you make the decision ex nihilo and then ask IT to install them for you? That would be insane. How do you test out new toolchains? What if you need a random tool for processing a file format you're working with that isn't approved yet? Without root, what do you do when your Linux gets messed up? Ping IT and.. wait? Just stare out the window?
Sure, to simply try it the best way might be to set up a new machine not connected to the corporate network/domain.
If it's an open source library it might be easier, but still the questions are the same: is it secure, is the added maintenance worth it, does it have a community maintaining it, what is its security track record... it might be as easy to answer this as "nobody got fired for using OpenSSL/Oracle/IBM" or "no single committer libs ever"
There's no universal right/wrong answer.
> What if you need a random tool for processing a file format you're working with that isn't approved yet?
you don't. this is how companies grow to these enormous headcounts. there are specialists for everything, everybody has their own cubicle, and there is a huge support:corebiz ratio.
also, in practice, there are usually hybrid ways. eg. you can install whatever, but it silently disappears overnight. is that better? who knows.
Also out of interest, is the answer to this:
> what do you do when your Linux gets messed up?
indeed just "wait for IT to fix it"? What do you do until then, have lunch?
> That sounds horrible^Hy unproductive
A friend of mine works for BlackRock, they simply work on remote Windows virtual desktops. He is not complaining about speed/efficiency.
A different friend works for ALDI (like Walmart just smaller), he got an issued MacBook (Pro?). When he connected an external USB hard drive the next day (or sooner?) he got an email about it because some automated scanner thing found something suspicious on it.
So at these sizes software development is already inefficient. But mostly because of the complexity. (You know ... https://www.youtube.com/watch?v=y8OnoxKotPQ&t=95s )
Having something go wrong on your personal system can be an 'oops', having something go wrong in any number of regulated industries can be a 'news generating event'.
I did say that if you work in a tightly regulated industry, obviously stuff is different. This should be pointed out though! You can't give advice for the medical or financial sector to someone with a 15-person startup that builds low-stake products. It's just not going to be the right advice, as you well know security is a tradeoff. I guarantee that disabling root on dev computers is a huge productivity hit -- you need to be sure of the pros/cons of making that decision.
Nothing says empathy for your users like making caricatures out of them.
What exactly is IT doing when a dev requests to install randomtool.exe? Why is it a developer is incapable of that same thing?
> Realistically, how often do you need to install brand-new non-standard software?
Well, does my own software count? I mean, I've run an executable that didn't exist 5 second ago more times than I could possibly count. I've also built installers for said software, and then executed and installed it on my machine.
Is that ok? If so, why (if I also can't download and run something from github)? If it's not ok... how I supposed to do my job?
Selecting/paying for secure repositories from legitimate well maintained sources.
Packaging the software and deploying it through some means, so all users who need the software can get the software.
Regular patching of software across many users who may only be intermittently connected to the internet.
Lots of busywork updating configurations as new teams are formed, teams dissolve, people come, people leave, new patches come out, new software comes out, have to move to a new OS with old software. Company policy or circumstances might require some tweaks.
Generally though as to your question, there’s no reason you can’t do what the IT department does. The IT department can also have such a setup and then have a dev sandbox environment you can pull random code into. The larger point of what they’re doing is building a software supply chain, and once you actually have every piece of software you’re using in a secure repository, you can do BIG things like blocking all applications that aren’t whitelisted in prod which essentially shuts down entire classes of security threats against a company, and maybe that’s what a company wants.
Maybe a company shouldn’t be trying to maintain a centralized repository and that’s a dumb idea…
Some basic research on its creator/distributor and history, particularly with regard to security issues and how well/quickly they were addressed. Also perhaps running the software in a constrained environment to see what calling home it tries to do, or does as part of its core function¹, if it is monitoring the clipboard, etc.
> Why is it a developer is incapable of that same thing?
It isn't really a question of capability, it is a question of whether they are convinced⁵ of the necessity and can all be relied upon to be appropriately diligent.
For many all that "contracts", "auditing", and "data protection law" stuff is someone else's problem, not interesting, and thinking about it wastes time & gets in the way of getting the interesting stuff done.
> how I supposed to do my job?
Do you want all that compliance stuff to become part of your job? Is that what you got into development for? Do you want to be held responsible if something is missed? If not then accept that someone else has to do it so that you don't have to, which sometimes means waiting for them to do it properly.
----
[1] we work with banks, we have to be very careful about potential accidental data exfiltration routes because we sometimes handle PII (and, more cynically, because we'd fail an external audit required by some big contracts if we didn't!)², we have a local instance of languagetool if someone needs that sort of thing but people still try to install grammarly³ and done seem bemused that potentially sending everything you edit⁴ is being sent to another country could be a bad thing. And that one is obvious, as it is part if the products core function.
[2] for other companies, their own "trade secrets" could be the concern
[3] nothing against grammarly, that is just a good glaring example of a tool with which we could accidentally breach promises made to clients about where information could reside or be processed. The same concerns, along with a few extras like licensing and stability, are also relevant for dependencies that actually become part of our products.
[4] yes, of course we have proper data access controls in place and all but a few of us have no access to real data if all is well with that, and even then that access is gated and used sparingly, but security-in-depth is a thing...
[5] from your question, you don't sound convinced currently
So this comes back to: do you block "potentially malicious" executables or not? How do you tell if a new never-before-seen executable needs to be blocked, without either just blocking every unknown executable ("dev can't get anything done") or opening a giant loophole ("anything in x directory is safe")?
Let me write it a different way: An exe with an unrecognized name and unrecognized sha256 suddenly appears on my computer. Maybe I just compiled it from source I wrote, or maybe it is a random thing I downloaded and unzipped. How does a decision get made on whether my system will run that or not?
There are plenty of ways for a local dev to self sign local trusted executables that can only run on their own machine for testing purposes (that would not be trusted being distributed to the public).
At least in Windows there are a few different systems that protect against running unknown executables, and downloading and running unknown executables would be a resume generating event that would get you walked out the door by security.
What if your insurance only covered certain brands and explicitly excluded the ones your cook used? That would probably make the cook less happy and less effective. Yes, happiness is important. Your employees perform their best when they use their favourite tools. This can either be Vim, their own ergonomic keyboard or even Linux instead of Windows.
Every restriction you add increases friction and decreases output.
No, it's not about installing Bonzi Buddy, it's about giving your people the best tools (the tools they like) to perform their best. Sometimes this incurs risks like unpatched vulnerabilities, like any software, but to go and paint this as some sort of entitled attitude developers have is plain ridiculous, honestly.
If you are not an administrator on the computer that you are using, you should run Visual Studio as an administrator while you are using the profiler. (Right-click the Visual Studio application icon, and then click Run as administrator.
Then you realize that Visual Studio has a menu where you can launch a command prompt which will inherit the privileges the IDE was started with...
That depends on the definition of non-standard I guess. If I want to quickly throw together a proof of concept product I might need to grab node/npm/postgres/ for example. Waiting even a half day for approval is too much in that scenario I think. So it's problematic in some situations to have an approval process. But in a typical month I'd say it's around once or twice that I need to run new software.
Some times I feel that we should just take the opposite approach. Don't trust employee machines! In my work I just commit code to a repo that isn't on a company machine anyway (github/azure devops etc). I don't use documents/network shares/databases/vpns whatever that is on a company network. I could work on my personal machine and no one would notice.
The threat model for a laptop connected to a private github repo is what? a) that a compromised machine can be used in a supply chain attack, and b) that a compromised machine could be used to read secrets/IP from the private repo. That's it. I wonder whether that threat, for normal "low risk" development work is worth the hassle of even bothering with locked down machines?
In some situations I have resorted to running tools inside a VM on my dev machine, where I can play god if I need to. But really this isn't any different from the above. There is a machine where you can do anything, and which hasn't got access to anything sensitive.
Depends on the definition of 'software' also. Strictly speaking, every npm package is someone else's code running on your machine. Often with quite wide ranging permissions.
If you need approval from IT to add a package or increment a version then your development process is going to be slow for sure.
Ticketing still needs to be in place, but it can also be a managed repository that can be audited/reviewed by IT team as well - tickets could be as simple as a Pull request.
That's a so annoying thing, I understand enough about admin stuff to understand that I have huge knowledge gaps but I'm seeing people all the time assuming they can securely administrate docents of servers while having less knowledge then I just because they made things somehow run (but then I also have seen more then just one or two really bad admins).
The worst case was someone who through because they have a doctor title in numerical math that and a (small) bit of programming/admin experience that they know what is needed to securely administrate a "private cloud" (cloud isn't quite the right term here,but good enough).
As expected it lead to the company being hacked due to some major security gaps in less then 2 years.
Security itself is a set of processes and policies where different teams monitor and ensure compliance with said policies. If security policies get in the way of the software compiling/working developers will disable security (and sometimes for short periods of time this is needed for testing to figure out why something has gone wrong). But it becomes easy and commonplace for developers to turn off the security because it gets in the way of productivity. And that's the problem with security, you don't generally get punished for violating it immediately by an attacker. It can be months or even years before someone downloads your source code and posts it online. You may not notice for months that your database was breached and everyone that you don't want has a list of your customers.
Agreed.
> But your needs aren't more important than protecting the integrity of the network and company.
Uh... no. Never put the needs of a company over your personal needs. (bonzibuddy.exe isn't a need)
Would a "recommended"/typical MDM rule set mean you can't install "unidentified developer" licenses on Macbooks? The usually checkbox every mac user normally enables in security settings?
As a researcher, I used to work on Linux and I never ever even imagined I could ask for administrator privileges.
In the industry, it's Microsoft all around. And it shows. And R&D software managers sign administrator privilege requests without batting an eyelid because they know that otherwise they are paying us for nothing.
Firstly, an IT team which works with users rather than against users. That might be as simple as adding all the "core" apps to MDM to ensure they always get patched regularly.
Secondly, it requires a development team to realise that just because they're good at programming computers it doesn't mean they're good at administering them. Yes, it sucks that you're not allowed to install bonzibuddy.exe from Limewire. But your needs aren't more important than protecting the integrity of the network and company.
Realistically, how often do you need to install brand-new non-standard software? 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.