[647] in Intrusion Detection Systems
Re: I'm with Gene
daemon@ATHENA.MIT.EDU (Dan Stromberg)
Thu Feb 29 10:03:17 1996
Date: Mon, 26 Feb 1996 09:09:28 -0800
From: Dan Stromberg <strombrg@test34a.acs.uci.edu>
To: ids@uow.edu.au
.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ids
Precedence: bulk
Reply-To: ids
Steve Smith wrote:
> 1.) Know your users!
> If you have no idea to who your users are you will never know
> the ones that are capable of system breaches, and other secure
> data leaks. By knowing your users, perhaps giving some type of
> interview with them etc. you will begin to build a mental
> database you will know who are capable and who are your normal
> "users."
Ok, maybe I'm a closeted cracker trying to cover my tracks (nope), but
this is really kind of a scary thought to me.
> 2.) Use Eclipsed Passwords!
> By using Eclipsed Passwords only your user will know the
> password. Only the Root, or SU, will have access to the
> Shadowed password, no one else
Yes...
> 3.) Use secure remote systems!
> Sometimes by trying to completely build a secure internal system
> we forget to also secure our remote capability, modems, wans,
> etc. Be sure to use modems that implement hardware passwords,
> this is another big thing for security. If the user can not
> access the system he is not a threat.
Yes, tho this is often < 5% of the problem.
> 4.) Maintain adequate systems Maintenance!
> System breaches come with the territory. If you are always
> maintaining hackers will have to adjust to new devices, bridges,
> firewalls, etc.
Yes, yes, yes. ...and you might then even be current on your security
fixes, too. ;)
> Internal security may be the hardest to trace, but my far it is
> more difficult hacking on-site then from remote site, simply due to time
> scales, and witnesses.
I really disagree about the degree of difficulty.
Off-site exploitable holes are a pretty strict subset of on-site
exploitable holes.
