> given arbitrary write access, intimate knowledge of the system, and the ability to disable any deployment and runtime checks I want, I wouldn’t be able to take out their production system?

I'm reminded of the punchline to an old joke:

"Doctor, it hurts when I do this!"

"Don't do that."

This is a fair point. This press release was not aimed at software engineers, and "rules that prohibit those kind of changes" is vague. It could mean anything from a sign on the wall that says "please don't!" to a robust access control and deployment pipeline that they intentionally circumvented.

If the policy was violated then the policy was violated. If it was properly communicated and taken seriously by management (it may not have been) then the person who violated it is at fault along with management for trusting him.

Good policies account for people not following the policy. Since this is aviation related, let's take "no smoking on a plane" as an example. There are "No smoking" signs everywhere and it's announced over the speakers several times prior to takeoff. Yet there's still an ashtray in the lavatory in case somebody disregards every warning so that they're not throwing a lit cigarette into a bin filled with paper products.

I just assumed it's because smoking was still allowed back when the plane was manufactured.

Think about the request from air crew to switch phones to the flight mode. Many people assume it’s for safety reasons. In fact would it be dangerous for the airplane systems there will be a real measures in place which are enforcing the rule - like a kill switch for all phones, scanners for not turned off devices, collecting devices before boarding a plane; but nothing like that in place. It’s because this particular request is to reinforce that passengers must comply with air crew orders, regardless of what they request (to some reasonable boundaries of course)

Imagine how many laptops, bluetooth speakers, tablets, and other devices are dinging "the waves" for wireless of all kinds from beneath seats and in overhead bins. Peer-to-peer, speakers, wifi, cell, ....

I just realized I have never disabled cell access on my watch.

It isn't clear to me why airplane mode is requested on airplanes. It doesn't reinforce crew control, it reinforces complete lack of crew control, i.e. crew control theatre.

you're giving a completely different, physical example with a clear risk if said policy isn't followed.

What should they have done in this case that didn't involve flat out preventing it?

> If the policy was violated then the policy was violated. If it was properly communicated and taken seriously by management (and it may not have been) then the person who violated it is at fault along with management for choosing the wrong person for the job.

There has to be a limit to this reasoning, though. There is a threshold where an organization is so negligent that they can’t concentrate the blame on an individual, regardless of whether there was a policy violation.

I want more details about that, too. That could be a reckless cowboy but I’ve also seen cases where people routinely bypass the official process because it doesn’t handle all of the work they need to do, or is slow/unreliable in ways incompatible with the volume of work, etc.

It does suggest a big lapse in oversight: if this wasn’t the first time they did this, their security monitoring should have picked it up.

My guess is that this is going to be one of those situations where someone broke the rules in a way their immediate management knew about but sanctioned because the official process was dysfunctional. In those cases it’s really common to crucify the operator and ignore the larger problem.

I think Ethereum developers might be able to say this :P