Airliners have to deal with all sorts of problems on the fly, literally. You can't stop lightning strikes, birds, engines catching fire, or any other myriad problems.

It's such a terrible analogy I'm a little flabbergasted. Planes need to reboot all the time to clear out hardware and software faults. The occasional problem is planned for.

It sounds like you’re disagreeing but you’re restating his point: all of the things you listed are how rare events are prevented from becoming worse.

I am disagreeing because this person doesn't understand the concept of defense in depth: Occasional problems will happen, will ye or nil ye, and the best you can do is to, as you say, prevent them from becoming worse. Thinking airliners don't have occasional problems is missing a lot of what the air industry does that we can implement in other realms.

He clearly does elsewhere, so I would suggest reading this more charitably with the assumption that you’re talking about the same idea from different perspectives. If I’m the passenger, I don’t even know about something which is caught by a checklist or redundant hardware before it progresses. If I’m the pilot or mechanic, the reverse is true. In both cases, what matters is the spirit of the point: saying something is too infrequent to prevent is defeatist.

Maybe, but I interpreted that as him insisting we must eventually become perfect, which isn't going to happen.

>> "We can't stop the occasional problem" - yes, you can. Would you travel on commercial airliners if you thought that the aviation industry took this approach with your life? I didn't think so.

Also, security is like reliability/uptime: You pay for every nine. You want to keep the server up on a best effort basis and have only the most basic security? Cheap, easy, minimal time investment. You want 1 minute down per month and good security? It'll take time and effort. You want... IIRC airplanes have a failure rate around 1 in 14 million flights, give or take? How many billions of dollars do you have? Because quality still ain't cheap.

I don't think the author intended to say that you can prevent all problems, I think they meant you can't just shrug and say "we can't help but get hacked". You can stop all problems from becoming critical, which is what airlines attempt to do.

They talk earlier about defense in depth, so it's obvious that they're not oblivious to the need for redundant safety measures:

> "We don't need a firewall, we have good host security" - no, you don't. If your network fabric is untrustworthy every single application that goes across the network is potentially a target. 3 words: Domain Naming System.

> "We don't need host security, we have a good firewall" - no, you don't. If your firewall lets traffic through to hosts behind it, then you need to worry about the host security of those systems.

Maybe I'm being too harsh, but my interpretation of that point is that they expect we'll eventually become perfect, which isn't going to happen in the software world as it hasn't happened in the airline world, even though the airline world has more incentives to be perfect in the form of more penalties when it isn't.

My understanding is the author suggestion is to start with a security first approach, rather than wait-and-fix.

They don't expect the airline to be infallible, but they expect the airline to be proactively avoiding trouble.

The most secure plane is the one that stays on the ground.

It's always point of contention between people with security mindset and people that need to earn money to even hire people with security mindset.

You’re not being too harsh, you’re missing the point. Defense in depth is not something you advocate for if you expect perfection.

There is the flipside of that problem. If you say "We can never get hacked" then you will find that you breed a culture of denial if there is a problem.

> "We can't stop the occasional problem" - yes, you can.

All those tools (checklists, redundancies, etc) exist to increase the reliability rate. And to stop the occasional problem (ground crew forgets to refuel plane) from turning into a disaster[1].

I might be overly generous, but thats my read of the author's intent. That just like in the airline industry, we have tools to stop occasional problems from turning into disasters. Things like:

- Deployment scripts instead of manual processes

- Dependency auditing (ideally automated)

- Automatic OS-level security updates

- Memory-safe languages (Go, Rust, Java) instead of C/C++

- Defence-in-depth (firewalls, host security, etc)

- Sandboxing (OpenBSD's pledge, Linux's seccomp, Deno's capabilities, etc)

Just like checklists in the aeroplane industry, these approaches require active effort. We don't get secure software if nobody cares enough to make it a priority.

[1] https://en.wikipedia.org/wiki/Gimli_Glider

I wonder how well the swiss cheese model works when there is an adversary actively targeting you as opposed to accidental disasters.

> checklists, redundancies

These things are created and extended because occasional problems happened.

As long as software has bugs and accepts user input, there are going to be ways to make it do things it shouldn't. You can avoid running specific known vulnerabilities. You can avoid creating certain kinds of dumb and obvious ones. But barring, like, formal verification, it is always possible for someone smarter or more patient than the original software development team to think real hard and come up with an edge case they didn't. And operational or system-level controls can only do so much about that.

Preventing every security vulnerability is the same problem as writing bug-free code. And that is manifestly not happening, not even in the most sophisticated software development operations in the world.

Right; which is why all the things on that list are so important. We can’t seem to stop the endless flood of memory bugs in C/C++ code. Iirc 65% of security issues in chrome are due to memory corruption. But we can move to Rust and friends, where those bugs are a lot harder to write.

We’ll never get the bug count to 0. That isn’t the goal. The goal is to get the number of in-the-wild exploited vulnerabilities as low as possible. And there’s all sorts of ways to move the needle on that, which don’t require humans to suddenly become infallible.

Well said: The point is to make a proper effort to make the tools we use better.

Humans will always make errors. Let's stop denying that and start fixing the mess we are making.

> And to stop the occasional problem (ground crew forgets to refuel plane) from turning into a disaster[1]. > [1] https://en.wikipedia.org/wiki/Gimli_Glider

While I agree with your general point I have to disagree the particulars here.

The ground crew did not refuel the plane, because the pilots did not request refuelling. There was no-one "forgetting" to refuel, least of all the ground crew.

The pilots did not request fuel because they thought they have enough. And they thought they have enough because they made a unit conversion error in their calculations. (there are even more layers and twists and turns to this cheese lasagne, but no one "forgot" to refuel that is for sure.)

The fundamental flaw is normally "but doing it correctly would cost too much and take too long, what can we do for $5 and a chocolate bar?".

Airline projects don't have the same level of issues because the FAA (or equivalent domestic authority) tells them to do it correctly.

Is there any real equivalent process for tech? It seems like the majority of security certifications is a box checking exercise where actually being secure has very little relation to how many boxes you checked.

Except when they don't, then you get the Boeing 747 MAX literally avoiding mandatory safety evaluations and ignoring engineers

But that is notable for being unusual.

After the FAA agreed that the two crashes were similar it grounded all planes, revoked Boeings certification authority, and fined Boeing.

Has Lastpass received anything other than bad publicity?

737 MAX, but otherwise correct.

I think the analogy is highly flawed. Flying is mostly a safe and predictable environment.

Aviation industry mostly protects against random failures and human mistakes, not targeted attacks so comparison there is silly from the start.

There are lessons to be learned, but they are about building resilient systems, not secure ones. All of the "security" of airplanes pretty much relies on pilot noticing something is wrong, without that man with SDR could fuck up a lot of stuff

Came here to say this.

Protecting the average corporate networks against the most sophisticated state actors is like protecting an airliner against an F35 armed with AIM-260 missiles.

Also, "penetrate and patch" is definitely at work in the airline industry. Yes, airliners are well designed as safe systems, but every now and again a problem does occur, to varying degrees of seriousness, and when such a problem is identified, it is patched.

Defence in depth. Sure, design a system well. But "penetrate and patch" is another layer of protection. I mean, if you find your system is penetrated, what else can you do right now but patch it?