Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
FreeBSD Security Archives: Re: Real-time alarms

Re: Real-time alarms

Jobe (jobeattrition.org)
Mon, 20 Sep 1999 00:11:07 -0600 (MDT)

On Sun, 19 Sep 1999, Rodney W. Grimes wrote:

> > I guess it that case we need to start discussing the events that need to
> > generate alarms.
> Slow down, your jumped from ``auditing'' to ``alarms'', as Nate points out
> in his mail there really is 2 levels of functionality here. The in kernel
> ``this is what I have done'' auditing mechansim, and the other side that
> does the filtering and decides what is and is not important. It's not
> that important where the 2 pieces live at this time, but it is important
> to decide up front that it is 2 pieces.
> Myself, I like the idea of how bpf handles the filtering side. Compile
> up an expression and shove it into the kernel so you minimize copy out
> operations.
> > Also we need to look at how in depth we want to go. In
> > addition, what are our goals here? What is it exactly that we want to be
> > notified of. Do we consider a single 'unprivilledged' account compromise
> > a breach of security? If so, how do you plan to go about auditing the
> > validity of logins. I think once a list of rogue events is created we can
> > start getting the ball rolling on this. I think it is silly to design the
> > system before we even know what we are trying to monitor. Once we derive
> > the events that will generate the alarms implementation of the alarming
> > system becomes easy. It seems to me that we're trying to bake a pie with
> > no filling here.
> I think your trying to set policy before we even have a method, though Nate
> and Robert Watson look to have a lot of the method work done. We need to
> go dig the differenet pieces before the group and look at what we have
> already implemented and come up with what we want for a method. Besides
> Nate and Roberts work there is jdp work for filesystem modification to
> look at as well.

I think my references to userland scenarios threw us off the track.
Basically what I was trying to get at is that we really need to know what
'events' (in kernel happenings) that we want to be aware of. Otherwise we
will end up developing a method for generating alarms for kernel events
when there are no given events to generate alarms for. Do you see what
I'm trying to get at here? Or is our primary goal to just create the
auditing system and let the user define the events for which alarms are


> Basically in the VMS SYS$AUDIT world you could monitor just about everything,
> I don't think we should predefine a limiting set, it'll only get expanded
> over and over.
> We need to do some research and get as much public detail as is avaliable
> on as many auditing implementations as we can. Then write a book on what
> is out there, then implement something better... :-) :-) :-). We do atleast
> need to take a look around...
> --
> Rod Grimes - KD7CAX - (RWG25) rgrimesgndrsh.dnsmgr.net
> To Unsubscribe: send mail to majordomoFreeBSD.org
> with "unsubscribe freebsd-security" in the body of the message

To Unsubscribe: send mail to majordomoFreeBSD.org
with "unsubscribe freebsd-security" in the body of the message

This archive was generated by hypermail 2.0b3 on Mon Sep 20 1999 - 02:05:38 CDT