LogAnalysis
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)
Hi Rainer,

----------------
David Corlette
GRC Solution Architect
DCorlette (at) novell (dot) com [email concealed]
703.663.5517

Novell, Inc.
Secure Your Enterprise with Sentinel from Novell
http://www.novell.com/products/sentinel/

>>> 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]
http://www.loganalysis.org/mailman/listinfo/loganalysis

[ reply ]


 

Privacy Statement
Copyright 2010, SecurityFocus