Why would you go through all the hassle of setting up an air-gapped system, only to stop at enforcing strict code signing for any executable delivered via USB?
Just the fact that one can insert a USB drive into the air-gapped system amazes me. I remember my days as a contractor at NATO and nothing could be plugged into those machines!
I guess the problem is that most air-gapped guides and practices out there mostly focus on sucking the "air" out of computers: internet, networking, bluetooth, etc from the get-go ("remove the network card before starting!"). But even air-gapped systems need some sort of input/output, so a keyboard, mouse/trackpad, displays and monitors will be connected to it - all pretty much vectors for an attack; a base sw will be installed (making possible supply-chain attacks); largely USB drives and even local networking may be present.
As a general rule, I'd say anything that executes code in a processor can be breached to execute malicious code somehow. Signing executables helps, but it's just another hoop to jump over. In fact I thought the threat in OP was about a USB firmware issue, but alas, it was just an executable disguised with a folder icon some user probably clicked on.
To make things worse, critical hardware (trains, power plants...) vendor's fondness for Windows is notorious. Just try to find nix-compatible infrastructure hardware controllers at, say, a supplier like ABB who (among other many things) makes hydroelectric power-plant turbines and controllers: https://library.abb.com/r?dkg=dkg_software - spoiler, everything is Windows-centric, there's plenty of non-signed .EXEs for download at their website. This is true in many other critical industries. So common it's scary these things could be compromised and the flood gates, literally, opened wide open.
Air gaps are easily enforced and require absolutely zero technical knowledge.
You just need a PC and then have a CD delivered through a trusted source – embassies should already have a way of ensuring physical integrity of their mail.
The technical knowledge needed for code signing, especially now with trusted hardware modules, is orders of magnitute more complicated than that.
Not just knowledge: code signing is going to be a lot of whack-a-mole work dealing with every tool you use. I’d expect that to cost more than you expect and get political blowback from whoever needs tools which get broken.
Why worry about the blowback? That's the corpse talking, if I hear, "This disrupts our workflow," I'm even more confident that I should rip the band-aid.
Offices that don't follow security practices uncovered because they never called for help, another chance for drifters on autopilot to walk away from the job because it just got too hectic, stop paying licenses for a bunch of tools you didn't realize you were paying for and don't need, find replacements for all the tools that are not actively maintained, or don't have cooperative maintainers.
It's a healthy shake-up and our society at large should be less scared of making decisions like these
You’re assuming that everyone shares the IT security department’s priorities. If you tell someone senior that they can’t use a tool they need, you might learn that they have political clout as well – and the context here makes that especially plausible.
I guess the problem is that most air-gapped guides and practices out there mostly focus on sucking the "air" out of computers: internet, networking, bluetooth, etc from the get-go ("remove the network card before starting!"). But even air-gapped systems need some sort of input/output, so a keyboard, mouse/trackpad, displays and monitors will be connected to it - all pretty much vectors for an attack; a base sw will be installed (making possible supply-chain attacks); largely USB drives and even local networking may be present.
As a general rule, I'd say anything that executes code in a processor can be breached to execute malicious code somehow. Signing executables helps, but it's just another hoop to jump over. In fact I thought the threat in OP was about a USB firmware issue, but alas, it was just an executable disguised with a folder icon some user probably clicked on.
To make things worse, critical hardware (trains, power plants...) vendor's fondness for Windows is notorious. Just try to find nix-compatible infrastructure hardware controllers at, say, a supplier like ABB who (among other many things) makes hydroelectric power-plant turbines and controllers: https://library.abb.com/r?dkg=dkg_software - spoiler, everything is Windows-centric, there's plenty of non-signed .EXEs for download at their website. This is true in many other critical industries. So common it's scary these things could be compromised and the flood gates, literally, opened wide open.