Guy, I believe what he tried to say is the common thought that once you teach people how to protect themselves - it becomes obsolete, as the hackers read it too. However - good security design is NOT one that is based on the ambiguity of the solution, but rather on the design, and therefore - the fact you are basing some or all of your design on known things, doens't nesc. mean that it is obsolete model. Ofer. -----Original Message----- From: guy keren <[EMAIL PROTECTED]> To: Aviram Jenik <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED] <[EMAIL PROTECTED]> Date: יום שישי 04 פברואר 2000 03:14 Subject: security reality check (was: Re: Maximum Linux security) > >On Thu, 3 Feb 2000, Aviram Jenik wrote: > >> I read 'Maximum Security' by anonymous (I imagine the book you're talking >> about is some kind of sequel). It was an excellent book, but keep in mind >> that security books get old the moment they are released. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >i'd like to take a moment discussing this common saying... > >security knowledge or information should probably be split into 3 >different levels. > >the first level is fundamental issues regarding security policies. under >this we could categorize things like the "exclude everything, then enable >on a per-case basis" rule, the "if your system got compromized, you should >wipe it up, re-install, and load from the last backup before the >break-in". there is much more to this level, but it basically covers rules >and policies that remain valid for a very long time (i wouldn't say >forever), and that are relevant to different aspects of security (network >security, host security, removeable media security, etc.) > >the second level would contain understanding general concepts and >algorithms that are not specific to a particular product. things such as >"public key cryptography", "packet filtering", "digital signatures", >"untrusted client - trusted server" and the like would fit here. these >techniques and algorithms tend to remain in use for several years, and are >implemented in a wide range of products. > >the third level would cover security specific products and systems. the >info here could be long lived (when the given product stays in use for a >long time, and does not change much), or short lived (a product is >replaced by a new one with a completely different configuration, or by a >newer version that changes lots of features). > >when you read commonly sold books about security, they seem to tend to be >"practical" - they concentrate more about securing specific systems, >software products, and as such must delve to details that are relevant to >specific software versions. if you try to educate yourself using such >books, then (unless you manage to generalize the details into >general policies and guidelines) your info is bound to become obsolete >slowly (or quickly) but surely. > >if one actually has some patience, and decides to learn this subject >properly, one should take the time to cover a book (or two) that deals >with the first level, then look out for books that discuss various issues >on the second level, and then developes a habbit of reading relevant books >of the third level on a need-to-know basis, and replace those on a regular >bases (even if only for using as a reference material). > >note that the order of reading these books does not have to be kept - it's >quite valid and possible to change the order, or follow several paths in a >mixed manner - in such a case, it is important to take the time every once >in a while, sit back, and think of how all the info you gathered fits >together into a larger picture. > >btw, you will notice that this approach is not unique to studying security >- it is relevant to studying any broad issue, that either changes rapidly, >or that your area of concentration changes rapidly. > >guy > >"For world domination - press 1, > or dial 0, and please hold, for the creator." -- nob o. dy > >p.s. there is a 4th level - reading bugtrack/cert/.. advisories on a daily > basis... > > >================================================================= >To unsubscribe, send mail to [EMAIL PROTECTED] with >the word "unsubscribe" in the message body, e.g., run the command >echo unsubscribe | mail [EMAIL PROTECTED] > > ================================================================= To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
