6 ms·

> I'm still continually baffled that we ended up in a world where automatically accepting updates from every dev and their dog is not just the norm but recommen

> I'm still continually baffled that we ended up in a world where automatically accepting updates from every dev and their dog is not just the norm but recommended practice. I think it follows from two things: 1. We use open source software for everything. This is also true of our dependencies, so we get hundreds or thousands of transitive dependencies. Many of which are presumably written by dogs, because (i) no one can tell if you're a dog on the internet, and (ii) OSS maintainers are so overworked they ask their dogs for help. 2. Languages and libraries are full of footguns, software is full of bugs and therefore vulnerabilities, and no one cares enough to go through the enormous effort to fix things. And this is true through the whole stack. So the only practical way to stay secure-ish is to reactively patch software as vulnerabilities are publicly discovered. And also defence in depth. (I would distinguish between the publicly known time that a vulnerability is discovered, and the first time it was discovered. You hope the two are the same but for many vulnerabilities, if a clever adversary found them first we'd never know.) With these two things together, you have a ton of questionable dependencies, and you need to update them all the time for security reasons.

xg15 5y ago
Yeah I guess then we can just shrug and go on because there is nothing we can do to stop our app from randomly breaking tomorrow. > So the only practical way to stay secure-ish is to reactively patch software as vulnerabilities are publicly discovered. But this is different from just blindly accepting any update that upstream gives you. > And also defence in depth. This sounds increasingly like security theater. You can always more layers obstacles to make things harder for malware that is already on your system, but it's not clear to me how much this actually reduces your atrack surface.
- bostik 5y ago
  Defense in depth implies a whole lot of things, and is certainly not security theater. Usually it boils down to three major themes: 1. Reduce blast radius: assuming component X is compromised, how far and wide can it be felt? 2: Principle of least privilege: once compromised, what can X do or access? Extend to the credentials X carries or has access to. 3: Detection: how early and how well can you detect the compromise in previous two steps? You can never prevent a compromise, but you can make it easier to notice when it has happened, and you can limit what the attackers can do afterwards.
- tapas73 5y ago
  > This sounds increasingly like security theater. It does help. Quite a bit. Each layer (e.g. firewall rules that require that all internet access go through a proxy), adds non-trivial amount of work for the hacker to get anything useful done. 1. best case - hacker will give up. 2. good case - you have more time to notice and react. How much layer cost you, how much does it cost for hacker to overcome it. Things to remember: 1. Not all hackers are nation states. Most are not. 2. We must accept that no security measure is absolute even against script kidies. Given enough time and luck/misfortune js sandbox will do "rm /sensitive/file". Recent Log4shell example shows that one can follow all best practices and still get bit in unexpected way.
tlavoie 5y ago
I see systems with various system-level vulnerabilities all the time for work, and try to assist my clients (internal project teams) in prioritizing fixes. Besides the usual CVSS scores, I try to focus first on what is being used or exposed. Network services, file-input processes come to mind. Vulns not in this list should also be fixed when found, but my thought is centered on what might be primarily exploitable. This leads to some thoughts on statically-compiled applications; while they might have some vulnerable dependency, I suspect that it's harder when the attacker is limited to the app's "baked-in" functionality that defines how those dependencies get used. Edit: Also, I should note that while I would greatly prefer, and do advise, that they base their environments on minimal OS distributions, this seems rare. The base system patching would be much easier to manage if it started from some BSD-like minimal state, or Alpine Linux, and included only what it needs. Instead, any infrastructure vulnerability assessment leads the teams to chasing down numerous patches in things they have, but never use.

xg15 5y ago

Yeah I guess then we can just shrug and go on because there is nothing we can do to stop our app from randomly breaking tomorrow. > So the only practical way to stay secure-ish is to reactively patch software as vulnerabilities are publicly discovered. But this is different from just blindly accepting any update that upstream gives you. > And also defence in depth. This sounds increasingly like security theater. You can always more layers obstacles to make things harder for malware that is already on your system, but it's not clear to me how much this actually reduces your atrack surface.

bostik 5y ago
Defense in depth implies a whole lot of things, and is certainly not security theater. Usually it boils down to three major themes: 1. Reduce blast radius: assuming component X is compromised, how far and wide can it be felt? 2: Principle of least privilege: once compromised, what can X do or access? Extend to the credentials X carries or has access to. 3: Detection: how early and how well can you detect the compromise in previous two steps? You can never prevent a compromise, but you can make it easier to notice when it has happened, and you can limit what the attackers can do afterwards.
tapas73 5y ago
> This sounds increasingly like security theater. It does help. Quite a bit. Each layer (e.g. firewall rules that require that all internet access go through a proxy), adds non-trivial amount of work for the hacker to get anything useful done. 1. best case - hacker will give up. 2. good case - you have more time to notice and react. How much layer cost you, how much does it cost for hacker to overcome it. Things to remember: 1. Not all hackers are nation states. Most are not. 2. We must accept that no security measure is absolute even against script kidies. Given enough time and luck/misfortune js sandbox will do "rm /sensitive/file". Recent Log4shell example shows that one can follow all best practices and still get bit in unexpected way.

tlavoie 5y ago

I see systems with various system-level vulnerabilities all the time for work, and try to assist my clients (internal project teams) in prioritizing fixes. Besides the usual CVSS scores, I try to focus first on what is being used or exposed. Network services, file-input processes come to mind. Vulns not in this list should also be fixed when found, but my thought is centered on what might be primarily exploitable. This leads to some thoughts on statically-compiled applications; while they might have some vulnerable dependency, I suspect that it's harder when the attacker is limited to the app's "baked-in" functionality that defines how those dependencies get used. Edit: Also, I should note that while I would greatly prefer, and do advise, that they base their environments on minimal OS distributions, this seems rare. The base system patching would be much easier to manage if it started from some BSD-like minimal state, or Alpine Linux, and included only what it needs. Instead, any infrastructure vulnerability assessment leads the teams to chasing down numerous patches in things they have, but never use.