131–140 of 216 posts
> #1) Default Permit I guess author of this post is no longer with us because they got heart attack when npm and similar rose to prominence.
https://i.kym-cdn.com/photos/images/original/001/270/123/1c1...
Earlier quoted context omitted.
> my iPhone is more secure than linux for the same reason The phrase "more secure" doesn't mean anything, I wish it wasn't used. One needs to talk about the threat model(s) you care about and how a particular solution addresses them (or not). Any given solution can be both more secure and less secure than an alternative, depending on what threat models you care about. Which may well be different than the threat model…
> The phrase "more secure" doesn't mean anything Fair point. I'll elaborate: The linux (UNIX) security model is designed to protect users from other (potentially malicious) users on the same computer. The system as a whole is designed such that a malicious (or incompetent) user can't make the system as a whole stop working. The system is more important than any particular users' data. Software is assumed to be correc…
Earlier quoted context omitted.
1. Default deny is one of the oldest best practices in security engineering; it barely needed saying in 1995 (but Cheswick & Bellovin said exactly that in Firewalls & Internet Security). 2. "Enumerating badness" is simultaneously an attempt to connect vulnerability research to antivirus (security practitioners have had contempt, mostly justified, for AV since the late 1980s) and an endorsement of the heuristic detect…
> 4. "Hacking is cool": literally, this is "get off my lawn". I do not quite agree with this verdict. Back in the early two thousands there were lots of people who thought it rather cool to just hack around (or more precisely crack around), for example by exploiting SQL injection bugs in whatever web form they encountered. Of course I might not have a representative impression of the community, but I think this kind…
Technically "hacking" is often portrait as totally cool and often not negatively connotated ("getting/being hacked" however clearly is). The problem with this is that the meaning has shifted a lot in the meantime. He means mostly cracking I think, while the meaning of "hacking" has shifted to be broadly just altering state/behavior often to something that was not originally intended.
At least he also includes penetration testing as something bad and this has clearly not aged well. For one you can also employ people to do just that and it's pretty essential for applications with big security implications and the other part is the invitation to "hack" the application/system at hand seen with bug bounty programs. The actual practice seems to contradict his point here.
You can also interpret it in a way that it is not going to improve your security just by virtue of having pen testing, which is true. However I feel like nobody argued that. Pen testing/bug bounties are there to actually get attention of exploits you might not get otherwise and therefore a prerequisite for fixing exploits. Or said differently: If you think you hardened your application/system so much that it's impenetrable, how could it hurt if people try to break it and tell you if they are able to. People will try anyway, but they might not tell you.
Earlier quoted context omitted.
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.
Except when they don't, then you get the Boeing 747 MAX literally avoiding mandatory safety evaluations and ignoring engineers
Earlier quoted context omitted.
> Its much more likely that me or my family suffers from a keylogger or ransomware attack than we suffer as a result of government intrusion into our digital lives. Are you sure? How would you know? We can't know how many people the government blackmails with data taken from their iphones, because it's illegal to publish information about them doing so, whereas ransomware attacks are widely publicised.
As key component of threat modelling is risk management and modelling. I would counter the “government blackmailing people” by questioning the risk this poses to me as an individual. As much as we’d like to imagine it, and as much as it can often times feel like it, we don’t live in a Kafkaesque society, by and large, as the significant majority of us are of zero interest and have little of anything worth blackmailin…
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…
The points didn’t age well, but there’s a kernel of truth in there: none of those things will ever work 100%, so if you’re trying to really lock things down you need defense in depth, which was also not a new security concept in 2005, but it was one we were, as an industry, less sophisticated about.
You have a relatively thin front-line of defence, with orders to fall back if they are in danger of being overrun. Then you have a very strong second line, manned with assault troops. As the first line falls back, the second line counterattacks.
This strategy was developed by the Germans in WWII, and adopted by the Russians.
I disapprove of it's use in computer security. There, it means something different; it means basically having multiple lines of defence, without any notion of counterattack.
> Wouldn't it be more sensible to learn how to design security systems that are hack-proof than to learn how to identify security systems that are dumb? That’s like saying “Why don’t they just design locks that are unpickable?” They’ve been working on that, for a while. But you need to know what you’re protecting against. Anyone who watches The Lock Picking Lawyer knows about the swaths of new locks vulnerable to com…
I think the author could have phrased it better, in that the best approach is having a good security design, and then taking out all the bugs it couldn’t cover.
An odd suggestion in an otherwise relatively uncontroversial article. It implicitly trains your users in a bunch of unpleasant things:
* clicking on some URL in an email, typing your password into whatever webpage pops up, downloading the blob it serves you and opening it (after clicking through the browser's "this was downloaded from the internet, are you sure?" warning) is a perfectly normal and legitimate part of the working day
* one needs to find ways to obfuscate documents of types that aren't on the IT whitelist so one can send them to one's colleagues so they can do their jobs (and no, the corporate whitelists never capture everything people urgently need to share in order to do their jobs)
* since everyone now does that habitually, receiving an automangled email with a link to an attachment which has its actual payload contained in several layers of archive obfuscation wrapper is perfectly normal because that's just what you have to do to share stuff with your colleagues now
These could, of course, be mitigated by suitably educating users, but since the practice is advocated in a section about user education never working, that is unlikely to happen.
Earlier quoted context omitted.
With respect to this example, I think he is saying it would be better if we were using memory safe languages, rather than trying to come up with these sorts of mitigations (which is enumerating the bad). Of course it’s probably not possible in every scenario because we’ve been doing it badly for so long, but I think the principle still holds.
Remember the log4j thing? And yet java is memory safe.
Yes, memory safe languages have bugs. But, we’ve been spared a world where big enterprise Java apps also have a bunch of trivial stack buffer overflows, in addition to log4j issues.
It’s like saying seatbelts are pointless because folks still get hurt in car accidents, while ignoring all the times they saved lives.
Earlier quoted context omitted.
> The phrase "more secure" doesn't mean anything Fair point. I'll elaborate: The linux (UNIX) security model is designed to protect users from other (potentially malicious) users on the same computer. The system as a whole is designed such that a malicious (or incompetent) user can't make the system as a whole stop working. The system is more important than any particular users' data. Software is assumed to be correc…
[flagged]
I hope the situation will change once Flatpak becomes more widespread and polished. On paper, it offers a comparable experience to smartphones — you get sandboxing with granular permissions, easy installation without messing with the command line, and so on. In practice, I had enough issues with Flatpak apps breaking in non-obvious ways to make me not recommend it to others. As a recent example, I tried using a JetBrains IDE from a Flatpak and spent quite a bit of time diagnosing issues with paths before resorting to Google and finding out that it's not supposed to work at all (https://intellij-support.jetbrains.com/hc/en-us/community/po...).
