Re: Putting together a server/network...

[Mike Ayers <mike.ayers@earthling.net>]

"Dr. Evil" wrote:

> >       In any case, an argument of "I say so, so you have to do what I say
> > unless you can PROVE to me that you shouldn't" doesn't wash after second
> > grade!
> 
> It does wash with security stuff; you have a choice between having a
> vulnerability and not having it.  You need to prove why you should
> have the vulnerability, not why you shouldn't have it.  The proof
> could be really simple, as in the case you gave: "There aren't any
> valuable resources on this network, the threat is small and I don't
> want to waste time (money) installing ssh."

	I still beg to differ.  Consider: ssh/scp, kerberos, PAM, IPSEC, IKE,
SNMPv3, secure sockets, link layer security and more are all good
security measures.  However, using them all at once is costly (in
training and staff time even if the software is all free), reduces the
computational efficiency of equipment (and raises the bar for minimum
systems, thus causing earlier end of life), and carries maintenance
risks (maintaining databases, changing keys, etc.).  It is therefore
only in extreme situations that one would want to use all.  Therefore it
is necessary to pick and choose between them.  There are situations in
which security is desired, but for which ssh may not be the best choice
(operating over the Internet definitely NOT being one of them).  I'd
rather not go into the scenarios, those familiar with the various tools
(and I am passingly but not highly familiar with them) will be able to
imagine a few, I am just trying to point out that the vulnerability that
one security system is designed to cover may already be covered by
another.  In that case, it may be counterproductive to cover it again. 
Neither do I feel that the proper way to determine security policy is to
pile up the tools, then remove only those that can be shown pointless,
since there is still all the bits that one doesn't quite understand.

>   But the decision should
> be made consciously and with some understanding.

	We certainly agree on this.


	Hope this helps,

/|/|ike