Re: Decoding BSM audit trail

Steve Smaha (Smaha@DOCKMASTER.NCSC.MIL)
Thu, 12 Oct 95 19:20 EDT 

General question:

Does anyone else get dumb automated mail messages from various gateways
after posting to this list?   Complaints about unknown recipients?
New userids from anonymous remailers?  Why can't the list maintainer 
be the lucky recipient of that kind of traffic?
[ Just let me know which addressess are causing the problems - ob I dont
get them B) ]

Anyway:

From:  amo at INFO.FUNDP.AC.BE (Aziz MOUNJI)

  >>> You mean you haven't done a massive hex/ascii dump yet ;)?  We've done
  >>> analyzers for over a dozen audit trails, and invariably end up doing that.
  >>> This is not a joke.
  >>
  >>> There are no audit trails that are laid out exactly the way they are
  >>> documented.
  >>
  >>This is a very sad situation. I would say that audit trails weren't initially
  >>designed with audit trail analysis in mind. This strangely sounds like
  >>"Unix wasn't initially designed with security in mind" ;-)
I have spent 8 years working in this area, and here is what I have learned.

Unix audit trails were developed by as few people as the vendor could
arrange, with "appearing to satisfy Orange Book C2 requirements" the 
only objective.  None of those people are still around to work on the 
code.  In several cases they were contractors; in others they have moved 
into other areas.

Auditing is the bastard child of security, and security is the bastard 
child of operating system design.  The audit trail is what the vendor
gives you.  Love it or leave it.  Or maybe try to convince the rest of 
the world to patch their kernels with your "better audit" (highly unlikely),
or design a new operating system with better security (not a very
productive way to get rich - ask the CMW vendors).  Or maybe go out
for a long walk.

  >>In fact, I am presently designing a generic format converter tool. It
  >>receives a (C-like) definition of a native audit trail records and allows
  >>to produce automatically the code of a program that converts to ASAX's
  >>private format.
Obviously you decided to do this before actually looking at any real
audit trails ;).  While I think automated code generation is a great idea,
it is normally applied to situations where you have some control over
the input data (unlike the audit trail layouts).

  >>The fact that audit trails are not always confomant to the specs makes
  >>the implementation of the generic converter a more desperate task
  >>than I expected. I think it is not realistic to have a fully generic
  >>converter, but we hope to cover as a great number of audit trails as
  >>possible.
Unless you expect to have dozens of new audit trails appearing on
the block in the next couple of years, I think it is not worth
spending much time on building fully generic converters,
though there will undoubtedly be some reusable components if you
do it right on a case-by-case basis.  One cardinal rule of object-oriented
design is that generalization is best done AFTER a couple of instances,
not before.

>From personal experience, I suggest that you get the filters built and
spend your time learning to analyze the data.  We have much less
than 5% of our Stalker C++ source code doing parsing/record conversion
to our internal object representation.

  >>> Sun has even managed to make this work across Sparc and Intel byte
  >>> architectures!  (But you'll need to use their macros, or reverse
  >>> engineer them, to get the byte ordering stuff right.  Maybe that level
  >>> of interest is reserved for us commercial vendors.)
  >>
  >>Which macros do you mean? Are they documented somewhere ?
On SunOS BSM, look in /usr/include/bsm/adr.h.  On Solaris, look in 
/usr/include/bsm/libbsm.h.  I don't think there's a lot of documentation.
We bribed the developers with ice cream, and even that didn't work very well.
We spent a lot of time figuring the internals out for ourselves.