Michal Zalewski On Security's Broken Promises 125
Lipton-Arena writes "In a thought-provoking guest editorial on ZDNet, Google security guru Michal Zalewski laments the IT security industry's broken promises and argues that little has been done over the years to improve the situation. From the article: 'We have in essence completely failed to come up with even the most rudimentary, usable frameworks for understanding and assessing the security of modern software; and spare for several brilliant treatises and limited-scale experiments, we do not even have any real-world success stories to share. The focus is almost exclusively on reactive, secondary security measures: vulnerability management, malware and attack detection, sandboxing, and so forth; and perhaps on selectively pointing out flaws in somebody else's code. The frustrating, jealously guarded secret is that when it comes to actually enabling others to develop secure systems, we deliver far less value than could be expected.'"
It's true. (Score:3, Informative)
Re:So let me get this straight (Score:4, Informative)
In the real world, security is hard because matter is malleable. When an armored vehicle gets blown up, we don't say that it "failed to validate its inputs". It just didn't have enough armor. Even in cases where it survives, all it would have taken is larger projectile, or one moving a bit faster... When somebody pulls an SQL injection or something, though, it is because the targeted program did something wrong, not because of the inescapable limitations of matter.
The only real class of security issues that mirror real-world attacks are DOS attacks and the like, because computational capacity, memory, and bandwidth are finite.
Re:Wrong approach? (Score:2, Informative)
The underlying architecture is fine. Ever since the 286 it's been possible to run code while limiting it to accessing only a specified set of memory addresses. What more is it supposed to do? It's not the CPUs' fault that OSes are failing so hard at the principle of least privilege.
They're just "executing code they're told to execute"? Well, of course - do you want them to refuse to execute "bad" code? If so, please show me an implementation of an IsCodeBad() function.
Re:Security is NP hard? (Score:1, Informative)
[...] isn't that equivalent to the halting problem? Isn't that NP hard?
The halting problem is undecidable.
Re Cabsec - Capability Based Security (Score:3, Informative)
I've read through all the comments, and this is the only sane one that stands out. The principle of least privilege, as I see it, is the idea of letting the user give privileges to a program at run time, and they would chose the least possible set of resources to get the job done.
The main thing is that with cabsec, you NEVER trust a program with the full resources of a user, and thus it never has enough resources to take out your system.
Consider if Outlook were only allowed to talk to a mail server, and a datastore, and use the console IO. It wouldn't be possible for an email to take out anything else, as it would be out of the scope of allowed actions. Everyone could manage profiles for things to automate the normal routine stuff, and use a nice GUI for the tricky bits... saving the settings if the results were favorable.
The big plus of cabsec (CApability Based SECurity) is that it would allow pretty much anyone to manage their own system, and to NEVER worry about virii again.
It can be done, but for many good reasons most users have never heard of it.