OSEC

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

Rodney W. Grimes (freebsdgndrsh.dnsmgr.net)
Mon, 20 Sep 1999 00:18:27 -0700 (PDT)

>
>
> On Sun, 19 Sep 1999, Rodney W. Grimes wrote:
>
> *snipped*
> > > 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
> generated?

I am trying to seperate ``method'' from ``policy''. The primary goal, IMHO,
should be to create a method of getting events from the kernel that could be
used to implement all sorts of security policies. So basically your last
statement ``create the auditing system and let the user define the events''
is what I am after first. Then we can implement the tools that allow
the user to define the events that create alarms or what have you. 

-- 
Rod Grimes - KD7CAX - (RWG25)                    rgrimesgndrsh.dnsmgr.net

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:16:47 CDT