Live data from Hacker News

The six dumbest ideas in computer security (2005)

ranum.com

31–40 of 216 posts

Re: The six dumbest ideas in computer security (2005)

#31
post #18
post #16

Earlier quoted context omitted.

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.

Re: The six dumbest ideas in computer security (2005)

#32
post #10

I wonder how well we all think this article has aged? "Penetrate and Patch" is supposedly dumb. But what do we practically do with that? We've seen in the last decade or so a lot of long-lived software everyone thought was secure get caught with massive security bugs. Well, once some software you depend on has infact been found to have a bug, what's there to do but patch it? If some software has never had a bug found…

I think this article has aged very well.

> Also web browsers face a constant stream of security issues. What are we supposed to do instead?

There's not much that users can do, but web browsers have spent the last decade moving away from "Penetrate and Patch" to much more proactive approaches. Eg, Chrome pioneered moving each tab to a separate process with full sandbox isolation. Firefox is talking about using webassembly as an intermediate compilation step for 3rd party C++ code to effectively sandbox it at a compilation level. Rust was invented by Mozilla in large part because they wanted to solve memory corruption bugs in the browser in a systematic way.

> "Default Permit" - nice idea in most cases. I've never heard of a computer that's actually capable of only letting your most commonly used apps run though.

MacOS requires user consent for apps to access shared parts of the filesystem. The first time you see dialogues asking "Do you allow this app to open files in your Documents folder" its sort of annoying, but its a fantastic idea.

As you say, my iPhone is more secure than linux for the same reason - because iOS has a "default deny" attitude toward app permissions. A single malicious app (or a single malicious npm package) on linux can cryptolocker all my data without me knowing. The security model of iOS / Android doesn't allow that and thats a good thing.

I wish iOS was more open, but on the flipside I think linux could do a lot more to protect users from malicious code. I think there's plenty of middle ground here that we aren't even exploring. Linux's permission model can be changed. We have all the code - we just need to do the work.

Also since this article was written, we've seen a massive number of data breaches because MongoDB databases were accidentally exposed on the open internet. In retrospect, having a "default permit" policy for mongodb was a terrible idea.

Re: The six dumbest ideas in computer security (2005)

#33
post #12

> "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. This person has a fundamentally mistaken idea of how airliners and, therefore, security systems as a whole work. Yes, airliners have the occasional problem. That's why they have: * checklists and inspections, to catch them bef…

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 s…

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.

Re: The six dumbest ideas in computer security (2005)

#34
>The real question to ask is not "can we educate our users to be better at security?" it is "why do we need to educate our users at all?"

Great point, but the emphasis on system administration instead of the broken nature of operating systems causes the point to be missed.

Re: The six dumbest ideas in computer security (2005)

#35
post #31
post #18

Earlier quoted context omitted.

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 i…

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

Re: The six dumbest ideas in computer security (2005)

#36
post #3

If I could come up with one dumb idea it would be something like: You can trust large-organization to secure your device. (especially for orgs that give themselves, advertisers or apps more access to the device than you have)

I dunno, the question is "against what?"; I trust a Chromebook to resist an evil maid attack, but not to stop an advertiser from stalking the user. Some people are okay with that threat model.

Re: The six dumbest ideas in computer security (2005)

#37
How about "our users can't tell the difference between a DOS attack and us having screwed something up" plus "the people that want to sue us for sucking are at war with the people that want us to look successful to get a promotion for hiring good vendors" etc.

/enterprise

Re: The six dumbest ideas in computer security (2005)

#38
post #12

> "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. This person has a fundamentally mistaken idea of how airliners and, therefore, security systems as a whole work. Yes, airliners have the occasional problem. That's why they have: * checklists and inspections, to catch them bef…

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 s…

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.

Re: The six dumbest ideas in computer security (2005)

#39
post #10

I wonder how well we all think this article has aged? "Penetrate and Patch" is supposedly dumb. But what do we practically do with that? We've seen in the last decade or so a lot of long-lived software everyone thought was secure get caught with massive security bugs. Well, once some software you depend on has infact been found to have a bug, what's there to do but patch it? If some software has never had a bug found…

> Also web browsers face a constant stream of security issues. But so what? What are we supposed to do instead? Any simpler version doesn't have the features we demand, so you're stuck in a boring corner of the world.

The charitable interpretation of the “penetrate and patch” section is the architectural parts, and browsers are a great example. At the time he wrote that, a browser was a single process running everything in traditional C/C++ calling other unsafe code (i.e. Flash) in the same process. People did patch a lot but they also did things like split components into separate processes with different privilege levels, change practices throughout the codebase to harden things like pointers or how memory is allocated, rewrite portions in memory-safe languages, etc. It took a decade but browsers became a lot harder to successfully exploit.

Re: The six dumbest ideas in computer security (2005)

#40
post #33

Earlier quoted context omitted.

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 s…

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.

Post reply on HN