|
|
|
|
|
|
by foohbarbaz
4472 days ago
|
|
|
Everything you said is very general. The article in question talks about "Linux servers" (or that's what I read). Speaking of those, could you explain specifically, what is the point of a wholesale update, as opposed to what is described? What I mean is running specific set of services (which most often built from source anyway) and keeping those services up to date. What you get in return is both stability and security, since you don't wait for vendor to release a patch and actually understand what the vulnerability is. With wholesale patching, in fact, you can never be sure whether your system is secure with respect to all published vulnerabilities. Another interesting detail is, that with services running built from sources often you end up with vulnerabilities not applicable to your configuration. Oftentimes, you can just tweak the config instead of changing code (and potentially breaking running things). Software updates is just a cop out for people that are too lazy to pay attention to security. |
|
|
> Everything you said is very general.
Ok, here's specifically how this approach fails in the real world:
A guy is ignoring vulnerabilities that don't seem to apply to his configuration. So there's a kernel flaw that allows privilege escalation. He thought it was no big deal because he doesn't allow a guest login. Then there's a flaw that allows remote users to trigger memory corruption, allowing remote guest access. No risk there, he thought, because guests have no privileges on the box.
You see how the attacker got in?
You might counter that that admin was just too "lazy" to line up all the vulnerabilities and see how they interact. But there were almost 200 vulnerabilities last year just in the kernel. Are you going to conduct the 19,000 security audits required to see how they interact? What about groups of three? What about vulnerabilities in other packages? This workload doesn't just go up linearly.
Also, this approach is weaker against unpublished vulnerabilities. If you're strapping together older software, especially deprecated stuff no one else is using, you're losing one perk of open source software, the many eyes shallow bugs bit. People not using your configuration means no one is going to discover vulnerabilities on it except for attackers. You may think, "good, that makes it harder for attackers," but that's security by obscurity, it doesn't actually hurt attackers very much. Vulnerabilities patched in newer versions of software give insight into vulnerabilities lingering in older versions, so often exploits can be crafted for previous versions far more easily than for newer.
This is why security professionals recommend defense in depth. You don't know which part of your platform is going to break and allow attackers to exploit vulnerabilities that you didn't think were relevant.
Also, for a lot of systems, eventually the admin will change. The guy or gal that follows you will be dependent on the system you set up, and may be less experienced or less capable. If they inherit a patch management system that basically entails, "Become a security expert in addition to your other duties," they are not going to strictly adhere.
You know your system and your situation, so I don't want to sound like your approach can never ever work. But if we're giving advice to the unwashed masses, I think we need more advice tailored for the people you dismiss as "too lazy to pay attention to security," because that describes basically everyone.
PS - When you describe other people's opinions as "lazy cop outs," it can kill discussions. You might watch out for that. HN isn't Reddit, people sometimes bury stuff that has good substance but poor tone.