No subject

experiences as you implement this.

> In addition, I have been working with some people who cannot
> themselves work in public forums, including mail and news groups.
> They also wish to make contributions, especially in the areas of
> Mandatory Access Control, (we need a less overloaded acroynm than
> "MAC". Any thoughts?) policy description, and security test suites.
> 
> > We're been redesigning how the record gathering mechanism is integrated
> > into FreeBSD, as there are parallel trace mechanisms (such as ktrace) that
> > serve a similar function.
> 
> Good art never borrows. It's much better to steal. Also, it's
> much easier to sell audit if you can call it an extension to
> an existing, well liked mechanism.
>  
> > I'm interested in the possibility of pinning down an IDS module
> > interface--i.e., a standard API by which IDS modules can talk to a
> > provider of audit records, specifying what they are interested in so as to
> > make detecting events more efficient.  This would presumably include
> > functions to describe interesting records, functions to retrieve the
> > records when available, and functions to report events via some
> > event-reporting architecture.
> 
> My understanding is that the state of the art for IDS is to suck
> information out of a relational database. This seperates the security
> function from the data gathering and relationship processing.
> If IDS is a real concern, perhaps defining a set of relations might
> be the best way to go, and design the audit records to fit nicely
> into the relations.

IDS seems to be one of the big ways to sell Audit to a lot of the
developers I've talked to.  They all seem quite cautious to committing to
serious overhead in the OS kernel, until they hear about some immediate
and material benefits (real-time IDS support).  

Do you have any references to papers on pushing audit data into relational
databases for IDS?  I had been envisioning a more UNIX-esque environment
wherein audit records are funneled from the kernel (and optionally via IPC
from other processes) to an auditd, which took care of logging as well as
allowing dynamically linked IDS modules to get a crack at the data as it
arrives, optionally with the ability to push [simple] rules concerning the
usefulness of various records into the kernel so as to reduce the record
flow and improve performance.  The relational model sounds more like an
auditd pushing records (or some cooked result of the records) into a
relational database and letting database clients perform queries/repond to
triggers to generate events in an IDS. 

  Robert N M Watson 

robert at fledge.watson.org              http://www.watson.org/~robert/
PGP key fingerprint: AF B5 5F FF A6 4A 79 37  ED 5F 55 E9 58 04 6A B1
TIS Labs at Network Associates, Safeport Network Services


To Unsubscribe: send mail to majordomo at cyrus.watson.org
with "unsubscribe posix1e" in the body of the message