3 ms·

I really don't understand how "3) Penetrate and Patch" is a bad idea. The argument is: > Your software and systems should be secure by design and should have

I really don't understand how "3) Penetrate and Patch" is a bad idea. The argument is: > Your software and systems should be secure by design and should have been designed with flaw-handling in mind I'm not sure I would argue that systems that have been hacked were intentionally insecure by design, but that the developers thought it was secure by design but they were just wrong. It seems totally unrealistic to say "just make it secure instead" as the solution, especially when machines are connected to the outside world.

deleted 12y ago
[deleted]
andrewfong 12y ago
I read it as "fixing the symptom" vs. "fixing the underlying problem". Suppose a remote attacker can trigger a buffer overflow by sending a malformed packet to your software. Your response might be to simply patch in a regex that checks for malformed packets, which fixes the immediate problem, but ignores possible deeper issues with memory management, remote access, etc.
geoffsanders 12y ago
Agreed. It would seem that unless your system is totally free of all forms of dependencies (including the human kind), arguing that patching is a bad idea simply because it shouldn't have to be patched in the first place is just poor advice.
NickNameNick 12y ago
It's more than that, it's a statement that adding software to fix software just means there's more software to fix. The correct solution is to remove software - there's no point in fixing it if you have no legitimate need for it anyway. Then you can concentrate on the software that you do need. For example, do you remember Blaster? It was a worm that exploited a service in windows 2000 and XP, a service that very few people actually need, and probably shouldn't have been included in home versions of windows at all. If it hadn't been included or enabled, Blaster, walachia and other worms would never have had the reach that they did.

deleted 12y ago

[deleted]

andrewfong 12y ago

I read it as "fixing the symptom" vs. "fixing the underlying problem". Suppose a remote attacker can trigger a buffer overflow by sending a malformed packet to your software. Your response might be to simply patch in a regex that checks for malformed packets, which fixes the immediate problem, but ignores possible deeper issues with memory management, remote access, etc.

geoffsanders 12y ago

Agreed. It would seem that unless your system is totally free of all forms of dependencies (including the human kind), arguing that patching is a bad idea simply because it shouldn't have to be patched in the first place is just poor advice.

NickNameNick 12y ago

It's more than that, it's a statement that adding software to fix software just means there's more software to fix. The correct solution is to remove software - there's no point in fixing it if you have no legitimate need for it anyway. Then you can concentrate on the software that you do need. For example, do you remember Blaster? It was a worm that exploited a service in windows 2000 and XP, a service that very few people actually need, and probably shouldn't have been included in home versions of windows at all. If it hadn't been included or enabled, Blaster, walachia and other worms would never have had the reach that they did.