You've already included the answer - "using their machines as remote terminals, doing most their actual work on some remote server".
The developer uses MFA (TOTP, Push Notification, Yubikey etc) into a virtual desktop inside the organisation (Citrix, VMWare Horizon, etc).
From there, the developer can SSH / whatever into their development environment - which is hosted "inside" the corporate network, or their cloud provider, via internal links.
All code, and dev boxes live "inside" the corporate network, and only keypresses, mouse movement, and screen diffs are sent back and forth.
Most remote access packages can prevent clipboard, USB device, file transfer etc.
If you need a password manager for work purposes, then it lives on the corporate managed network - not your remote laptop/desktop - and to be really paranoid - you only ever "copy/paste" those passwords - you don't type them in.
If you really want to lock it down further, give the remote workers dedicated corporate equipment that they only use to access the remote desktops, so you can prevent some things like screen capturing, and really lock down the software to prevent things like keylogging software/malware.
You also should have the entire development environment segregated from the "business" corporate network as well.
It's only really an issue if you want to have offline developers - in which case I don't have any thoughts ready to hand - (but would expect it to be a very locked down machine, possibly with an even more locked down VM inside it).
As someone who regularly uses multiple layers of Virtual Desktop -> Virtual Desktop -> Remote Desktop, provided the network can handle it (on both your local network, and the corporate network), it works surprisingly well.
This is both a misunderstanding of the problem and an attempt to solve an administrative problem using technology... which cannot really solve it.
Developers have nothing to do with this. It's a common practice in companies that have "expensive" production environment (eg. VMs rented from AWS) that developers never get any kind of access to production environment. Ever. At all. No need to tie developers' hand by putting them behind a ton of unnecessary firewalls. They have no need for the sensitive information and shouldn't be burdened by protecting it.
The few people who do have access to company's "expensive" production environment are / should be very few people, most likely in the infra / DevOps department. These people do need to follow special protocol for communicating with the "expensive" environment, which, likely, doesn't happen all that often. Depends on the product, of course, but unlikely to be more than once a day, or even once a week.
----
PS. In many, many years of being in infra / system / automation I had never typed any passwords for any important services I had to use. They are usually difficult to type due to having all kinds of Unicode characters I wouldn't know how to reproduce w/o a little research. It's also very rare that they end up in system clipboard, since I usually end up using something like vi+tmux over SSH in Emacs' ascii-term to copy the password from somewhere and paste it somewhere else. So, stuff like AWS keys would have to be stolen by taking screenshots of my screen or something like that...
I mean, why on Earth would anyone deploy to production environment from their personal laptop? Normally, deployment is made from some sort of a testing / staging environment where the system was being tested / archived before shipping it to the next stop... It sounds like some kind of emergency / unplanned situation where a DevOps had to log into the remote system from their laptop.
Are you misunderstanding the term "DevOps"? You build it, you run it. If a DevOps team only runs things other developers have build, it is not a DevOps team.
In this case, DevOps shouldn't be rearchitecting, developing, or changing a password management's solution, crypto, architechture, or design in any way. Not in the slightest.
I'm all in for VM based privilege separation, but that won't protect you from infected endpoint. Assuming this was a targeted attack, folks that achieved RCE on DevOp engineer's machine could have waited for her to authenticate and then inject keystrokes into VM, SSH, VNC, Remote Desktop, Citrix or whatever remote management system they're using.
Honestly, this HN thread is full of bad advice and factually incorrect patronizing. Okta-style system asking to accept every single permission would not have protected from an attack, because Okta caches and reuses authentication tokens. Clipboard snooping / keylogger detection wouldn't have worked because none of these solutions are robust against targeted attacks.
The only thing I can think of which would have (and should have) helped is alert SOC / incident reponse team. Good luck finding one though.
Glad to see someone else with the same reaction, because a lot of this advice is... interesting, like people who are worried about keyloggers but think the clipboard is safe.
In my experience, I find that working with Virtual Desktops is the most frustrating user experience as a developer you could have. I prefer working in containerized environments which are more efficient and do not require the same amount of configuration processes as a Virtual Desktop.
For most development work, this would probably cause a serious productivity drop, but it definitely makes sense for the portion of the work that involves accessing critical production resources. For DevOps roles, that could well be the majority.
Toyota had identified the strategic risk of chip supply some years earlier, and made sure they had access to large buffers of them, reducing the impact.
In the mid-90's, I worked at a place that had one used for our intranet server running Win NT with IIS.
Mostly used a DEC Alpha as a "visible" competitor to our major server provider at the time (Compaq) to try and manage the prices they were charging (at least until Compaq bought Digital, and then eventually bought by/merged with HP).
One interesting thing was that we had a faulty RAM chip that we only discovered due to a bug in website publishing to IIS causing a big memory leak which crashed the server. Once the the chip was replaced, we still had the underlying leak - but at least the server didn't crash any more.
I wonder if it could be a net positive for the connection point areas.
I'm speculating that areas with undersea cables are often marked as "no anchor" zones due to the risk of damage (in areas where such practices are followed).
So the drop in damage from anchors and extended motor boat presence might eventually outweigh the initial damage from laying the cable.
The idea of net positive is flawed, as multiple local net positives from different disruptions (other than cables) might lead to deterioration of global quality thresholds for sensitive issues, e.g. chains of wetlands required for migratory birds. These global connections are most often unwisely accounted.
Although I don't have a wireless groupset on my bicycle, I'm attracted to the idea of dual batteries (like in the SRAM system) - at least that way if you forget to charge a battery - you can swap them between front and rear so you have a slightly better ability to limp home.
With Di2 it kind of does the same thing, when your battery is getting low the front derailleur will stop working. Not sure how many shifts that leaves you at the back though so you might still be in trouble if you’re far from home.
The front derailleur stops working at a nominal 10% charge. You'll have plenty of rear shifting left on all but the longest rides.
That being said, it's really easy to avoid the battery getting that low. It lasts months under normal conditions. And your head unit will tell you when the battery gets low. Except Hammerhead units won't get that warning anymore? #thanksshimano.
The high level issue here is around data ownership, and device ownership.
I think the nearest car analogy is ODBII ports and data access - ANT+ is a wireless communication protocol, mostly for reading statistics (I think it can also be used for issuing commands).
Hammerhead had a license to access the privately configured Shimano data - and then they were purchased by SRAM (who are Shimano Bike division's main competitor).
As a result, Shimano is (for now) limiting a competitors ability to see the data produced by Shimano components.
This feels very petty to me - most of the data is essentially going to be "which gear is the front/rear in", and "what shifting pattern do you want to use" - though it might also extend to preventing future interoperability (like preventing competing wireless shifting levers triggering the other manufacturers components) - which would be a loss for consumers.
The "data" You're talking about is basically just battery level and which gear are You in.
Just for context, SRAM (the second biggest component producer and the new owner of Hammerhead) publishes the same data in plain ANT+ format. It's basically an open standard over which sensors broadcast their data. Anyone who is interested can read it, no license agreements necessary.
AFAIK Shimano has decided to encrypt their packages and the license is for the encryption keys / algorithms.
I have a Hammerhead 2 and Di2. The most commonly used functionality for me was using the buttons on the brake shifter hoods to control the screens on the HH. It meant you could control the device without moving your hands and I use it all the time.
Having access to shifter position and Di2 battery levels was also super useful. This move really pisses me off!
Guess I will not be updating the firmware of my HH2 for a while at least.
yeah, exactly what I was thinking when I saw the news. I've been specing a groupset update on my current bike just last week and although the primary factor has been component availability (the only Shimano groupsets I could find were on used market), I'm really glad I went for SRAM AXS (though their wireless protocol does raise some hair as well, need to look into it a bit more when I have a chance).
Lack of interoperability in any system is a bad thing for consumers. However in this case you could argue that Shimano are right. It's fine to allow interoperability without the data. A KMC chain will work with a Shimano derailleur. Shimano should have no problem with that. But Shimano have to assume that SRAM would now get all the aggregate data on the operation of thousands of their Di2 systems. So SRAM could see how much faster or slower the Di2 gear shifts are. How many times the user had to make the same shift twice maybe because of failure. If a user tends not to use the largest sprocket when putting in a lot of effort then maybe it means their gears aren't tuned correctly etc. So it's competitive intelligence that SRAM can use to out compete. When Shimano allowed Di2 interoperability their intention was that it would be for the benefit of the consumer, not their direct competitor.
yeah, that used to be true up to 11 speed groupsets. Things are changing however. Take a look into the 12 speeds now. Good luck finding a non-shimano 12 speed chain that works on Shimano derailleurs / chainrings.
As for the part about speed and quality info, sorry, but that's "not even wrong". There's absolutely no way You could get this kind of info from Di2 ANT messages.
All You have is things like "the gear has changed" and "battery level is now X", not "when" has the user pressed the button or how many microsteps has the derailleur done at which speed. That goes through their own wires (I think it's basically a version of CAN).
I guess that SRAM can afford to buy a dozen of Shimano gear shifts, put them on a bench and measure any parameter they care even without accessing the software. Real world data could be interesting but are they really so useful?
They could. They tried to make a metric chain (2cm spacing rather than 1 inch) but it didn't catch on. Campy has kind of done that with their weird pull ratios right? Or does that only make sense if Campy was second to some drivetrain size (I'm not sure who was first or second to each cassette size).
It's not that they want to control the person. They want to control what is sent to the competitor. There's a phrase "good fences make good neighbours". This is the history of industrial competition and cooperation. So we want to have cooperation and sharing which is what advances prosperity for everyone. But as soon as you share stuff people can abuse it. We see this with social network data. We see this with AWS abuse of open source. The practical way to have cooperation is to have sharing over which you have some control otherwise people will stop cooperating. So Shimano need some way of saying: We want to share this data with the user and with third party software companies. But we do not want to share this data with a competitor. At the moment there is no way to do this so they just do not share at all (or at least not with that "third party" software company). Shimano probably want to cooperate but they also want to be able to compete fairly. Right now it's not fair competition because SRAM are not sharing SRAM aggregate data with Shimano.
> It's not that they want to control the person. They want to control what is sent to the competitor.
Distinction without a difference. Shimano is using technical and legal means to prevent owners of their devices from using their property as they wish. And we have bought into the confusion that just because someone manufactured an item, they have some sort of legitimate claim to how it is used even after they sell it.
> There's a phrase "good fences make good neighbours".
I couldn't agree more. Which is why it angers me that Shimano is moving its fence, expanding into consumer's back yards. I don't want every company that sells me something to then try and control how I use that something.
> So Shimano need some way of saying: We want to share this data with the user and with third party software companies. But we do not want to share this data with a competitor.
The bike is mine, the components are mine- I bought them, why does shimano need any way of saying where I can put my data produced by my devices?
What's next, is a fridge company going go turn off the fridge if I pup non-approved food in it, will an oven refuse to heat an unauthorised meal?
Is a smart lock going to refuse to open the door if I bring in more people than my rental contract allows?
We are on a high-way to a feudal kindom and tyranny.
