On Sat, 8 Aug 1998, Jim Hebert wrote: > > > The main purpose of that paper was to discuss the fact that computer > > systems today are amazingly homogeneous at a binary level, and this > > lack of diversity leads to many of the security problems that we see. > > One cracker writing a script to break in to one machine is generally > > not a big deal; one cracker spreading a script on the net that can > > break into thousands of machines _is_ a problem. <SNIP> > > First off: Things that I can do on my machine to stop script kiddies, slow > them down, or even make it easy for me to catch klutzy script kiddies (eg > tripwire) are good. OTOH, the goal is not simply to stop script kiddies. agreed. While the main purpose of this list seems to be about protecting systems from crackers and kode-kiddies, one who reads and practices the suggestions here can not help but gain a better understanding of their system, as well as software and computer hardware (to some extent) in general. > > We can avoid this by making computer systems unique - the trick is to > > do this while providing a uniform interface to users. We discussed > > several approaches in: > > This stops the script kiddies, and O(zero) more, where O(zero) reaslly is > my attempt to sum up the advantages of security through obscurity. Aain, I agree. Merely saying that we should have a different system for everyone will not solve tha problem, in fact I believe that the situatin will be worse of. A person running a system today can turn to thousands of people for help on Usenet, the web, or other resources on the internet. Books are available for almost all systems. This is becasue everyone runs similar systems. If everyone was running their own flavour of something then the problem of security might have been solved, but then what I think would be a much bigger problem would arise- systems which don't run well/efficiently, not because of crackers, but becasue of admins that have to track down every bug themselves, with no where to turn to.. > Saying "we need to make all these computers a little different from one > another" is really just saying "we need to obscure various details about > this computer that, when known, will make the attack possible again." I believe an analogy is in order: Phreakers often used to use tones to get free calls out of the phone company..now the phone company could have used different tones in different parts of the same country/state/city to restrict the ability of phreakers to do this. But by using obscurity to solve a problem they would have essentially rendered the telephone infrastructure useless. I believe that the same thing will happen if we "diversify" all computer systems. > Again, yes, it's good if it stops script kiddies. Some people run domains > that are so low-on-the-totem-pole that any 31337 4@|<3|~ who's looking to > really land the big fish will bother. But both proprietary and open source > offerings are trying to win spots in "bet your business on this" lists, > and military contractors, nuclear research centers, and naval warships > to name 3 will regard things which "make it annoying to build the same > exploit that runs everywhere" (my rather rude characterization :-) as > being on the order of zero. Then again, maybe not, since the above named > things also think obscurity is a great security tool. =( Organizations that attract crackers, such as the three you named above, will always attract crackers. By the original argument, crackers start on these systems and then port their script/codes to other similar systems. By obscuring the network of systems, you might remove the portability of an exploit, but the original system that a cracker was working on will still be targetted. Ty.
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:11:59 PDT