Fwd: RE: [CEE-DISCUSSION-LIST] [logs] Defining Events, Logs,and Alerts(Round 2) Jul 31 2008 08:34PM
David Corlette (DCorlette novell com) (1 replies)
RE: [CEE-DISCUSSION-LIST] Fwd: RE: [CEE-DISCUSSION-LIST] [logs]Defining Events, Logs, and Alerts(Round 2) Aug 01 2008 06:44AM
Rainer Gerhards (rgerhards hq adiscon com) (1 replies)
RE: [CEE-DISCUSSION-LIST] Fwd: RE: [CEE-DISCUSSION-LIST][logs] Defining Events, Logs, and Alerts(Round 2) Aug 01 2008 03:00PM
David Corlette (DCorlette novell com) (1 replies)
Re: [CEE-DISCUSSION-LIST] Fwd: RE: [CEE-DISCUSSION-LIST] [logs]Defining Events, Logs, and Alerts(Round 2) Aug 01 2008 03:37PM
Rainer Gerhards (rgerhards hq adiscon com)
Hi David,

you made a couple of good points. But I think it all boils down to that
we have different views of what an event is (which is further proof that
a unifying definition is needed).

Let me explain... To me, an event is simply a set of state change
information. The debug event was caused by internal state changes
(though I agree in a subtle way, bear with me for a moment).

In my understanding, you have described why you are not interested in
debug events, and gave some perfectly useful arguments for this
dis-interest. But we had this discussion of an as broad as possible
definition of event, just yesterday, where we came down to an
"electronic system".

Your definition below now restricts the domain of the "electronic
system" to an "electronic auditing system". So in my point of view, you
are simply restricting the set of possible events to the subset that is
useful for some specific use case.

There are other use cases where debugging events are useful, but (SOX)
compliance events are not. Obviously, this is the case if a debugger is
attached. I could also run a debugger offline, based on some "log file".
The later is quite uncommon (but not unseen, e.g. think about space
robots and a lot of other situations where you need to run a "debugger"
detached from what is being debugged simply because you can not access
it). The attached debug is quite common and the dominating scenario, so
debug events are typically not seen in logs. In any case, I am still of
the view that we talk about events.

Of course, both views are correct (at least I think so ;)). The question
is what CEE will address: Is an event defined in the domain of an
"electronic system" - then we have debug events. If it is defined in the
domain of an "electronic auditing system", then we do not have them. In
this case, for my needs, I just replace "event" with "state change set"
and "event" becomes a subset of "state change sets" - those that deal
with auditing. Not much different to the view that all is an event and
than that set is restricted to those that are of interest for auditing.

Under this scenario, I can also describe why I have "event records" as
well "non-event records" (being "state change sets" without "event")
inside a "persisted state change set stream". I just need to duplicate
all the terms. I personally would find it simpler to speak of events in
all cases and restrict them to the proper domain where needed, but
that's more or less personal taste.

CEE needs to decide what scope it intends to cover.


On Fri, 2008-08-01 at 09:00 -0600, David Corlette wrote:
> >>> On Fri, Aug 1, 2008 at 2:44 AM, in message
> <577465F99B41C842AAFBE9ED71E70ABA44EEFB (at) grfint2.intern.adiscon (dot) com [email concealed]>, "Rainer
> Gerhards" <rgerhards (at) hq.adiscon (dot) com [email concealed]> wrote:
> >>
> >> > I don't like "data stream" as it doesn't have any connotation with logs, in
> >> > my mind.
> >>
> >> Exactly, as I was trying to differentiate between a persisted stream of
> >> events (could maybe be called an "event log") and an object that
> >> contains events as well as "other things" that people have been
> >> alluding to, like debug records. I'd be fine just leaving it off and
> >> saying that's out of scope for our event standard.
> >
> > IMHO this brings up the question how to qualify an object as either an
> > "event" or an "other thing". "Debug logs" contain "debug events" (in my
> > POV), so why not classify them as such?
> Although I'm sure there are gray areas here, this distinction has always been clear to me. A debug record in my mind has no Initiator, or Subject if you will, in that nobody explicitly caused it to happen. An Initiator doesn't need to be a person, but it does need to be something that is attempting to perform operational, security, or business functions in an environment. A debug record generated by an application based on what it's doing internally or whether its input is corrupt is none of these.
> Which isn't to say that an application might not be acting as an Initiator and performing some activity at the same time as it is generating debug records. But in this case it should generate a true event record stating "I tried to do X and it failed", and then *also* generate a traditional debug message. XDAS has specific outcome codes designed to capture application failure states, and actually distinguishes these from application denial states (e.g. access denied), which I think is a critical and oft-underused distinction.
> As a developer, I think this distinction would be pretty clear. If I'm sitting down and writing an app, I generate debug records so I can tell what's going on internally. I write regular events when I try to perform any action that a business-level administrator of the system might possibly want to know about, especially when accessing or modifying any object or service outside my application.
> > If you look at syslog, this distinction becomes quite problematic. If we
> > say a debug record is not an event, how do we handle syslog logs that
> > contain records that are explicitly flagged as being debug records (be
> > virtue of their assigned priority). Does that mean that a syslog log is
> > a superset of an event log, one that contains both events and "other
> > things"? If so, must we first build the event subset before we can
> > process a syslog log as a log? I can't think this is desired behavior.
> > So I conclude it is counter-productive to try to exclude debug-like
> > information from the definition of an event.
> I think the whole point is that syslog is pretty broken, and we're trying to fix it. Let's not get hung up on historical anachronisms. Syslog was designed in an era when the concept of enterprise SOX audits was not on the radar.
LogAnalysis mailing list
LogAnalysis (at) loganalysis (dot) org [email concealed]

[ reply ]


Privacy Statement
Copyright 2010, SecurityFocus