Re: [logs] Defining Events, Logs, and Alerts (Round 2)

[David Corlette]

Apologies for the cross-post, but this discussion is going on simultaneously on both lists, with some members replying to different lists than the one the original post went to!

My take on this is as follows:

-  The term "event" is problematic, I think I would agree with Raffy that saying "events" occur in computing systems is artificial.  I would also clarify the language a bit to say:

1. Event
* An observable occurrence in a system. This implies that some action or activity has taken place, but what types of actions and activities are relevant, and their
classification, may be dependent on the observer and domain.


- For the most part I am happy with the definition of "event record", although Eric did make an interesting call to distinguish between the internal, machine-oriented record and an external, displayable representation. I think however that I lean toward letting the implementation handle that and not embedding it in our definitions.

2. Event Record
* A persistent representation of the details of an individual event.


- I really don't like the term "log" because of its quite problematic and confusing overlapping meanings.  Same for "Event Log", "Log Record".  I would instead suggest:

3. Event Stream
* A set of time-stamped event records.

4. Data Stream
* A set of time stamped event records as well as records containing other types of data.

5. Log
* A colloquial term used to indicate a static collection of event records and other informational data.  Not used in this standard, but typically an event stream is ultimately stored in some sort of log depending on the implementation.


- Similarly "alert" doesn't really seem to be anything that we care about in this standard - if an implementation chooses to generate alerts based on event records in the stream, so be it, but it has nothing to do with the standard per se.

6. Alert (n):
* A colloquial term used to indicate a warning or notification to a user or system, usually indicating that some action should be taken in response to
one or more events.  Not used in this standard.

7. Alert (v):
* The act of generating, transporting, or displaying a warning or notification.  Not used in this standard.


- "Log" rears its ugly head again. As Raffy points out, this term fails to differentiate between generating vs. storing.  So I would replace this with:

8. Audit (v)
* The act of observing an event and generating an event record with details about the event.

9. Store (v)
* The act of committing an event record that is part of a data stream to some form of implementation-dependent storage. Colloquially the term "log" is often used for this activity but is deprecated.



>>> "Heinbockel, Bill" <[hidden email]> 07/31/08 9:31 AM >>>
Thank you for all of the great feedback and discussion.

After compiling all of the suggestions, we have gone
through and revised our definitions.

The main points of feedback were that (1) logs have
a temporal quality that is important, and (2) that
there are different connotations regarding the term
"log" -- some think of logs as only containing
records of events, while others point out that there
are other things (e.g., "reports", debug info) that
also appear in today's log files.

To help clarify this, we define both "log" and
"event log". An "event log" contains only "event
records", and is a subset of a "log".

Without further ado:


1. Event

* An observable occurrence in a computer system. The
classification of events may be dependent on the observer
and domain.


2. Event Record

* A persistent representation of the details of an
individual event.


3. Event Log

* A collection of time-stamped event records.


4. Log

* A collection of event records and other informational
data pertaining to a particular domain.

A log may be electronic (e.g. stored in memory, disk,
software, database, text file, etc), physical (e.g. on
paper), or even verbal (e.g., "Between 10:00 and 10:01 we
received a series of several thousand SYN packets that we
acknowledged, but full TCP connections were not completed.
At 10:02, our server resources exceeded the maximum
tolerable level and crashed.").



5. Log Record

* A single entry in a log. Entries may take the form of an
Event Record, status or attribute report, debug data, or
similar environmental information.



6. Alert (n):

* A warning or notification to a user or system, usually
indicating that some action should be taken in response to
one or more events.


7. Alert (v):

* The act of generating, transporting, or displaying a
warning or notification.


8. Log (v):

* The act of recording or storing one or more events.





William Heinbockel
Infosec Engineer, Sr.
The MITRE Corporation
202 Burlington Rd. MS S145
Bedford, MA 01730
[hidden email]
781-271-2615

[Eric Fitzgerald]

David Corlette wrote:

> - I really don't like the term "log" because of its quite problematic
> and confusing overlapping meanings.  Same for "Event Log", "Log
> Record".  I would instead suggest:
>
> 3. Event Stream
> * A set of time-stamped event records.
>
> 4. Data Stream
> * A set of time stamped event records as well as records containing
> other types of data.

I agree with adding "Event Stream" and agree with the definition although my personal preference is to insert the word "ordered" (perhaps that is implied by "stream" though).

I don't like "data stream" as it doesn't have any connotation with logs, in my mind.

I think "Event Log" is unambiguous, but I agree that the unqualified "Log" is ambiguous.

> 8. Audit (v)
> * The act of observing an event and generating an event record with
> details about the event.

"Audit" is a very overloaded word and I would prefer to avoid it.  The common use as a term of art is something along the lines of "to compare an IT system's configuration against a baseline".  A distant second in terms of usage is "a security-relevant event record" or "to generate a security-relevant event record".

> 9. Store (v)
> * The act of committing an event record that is part of a data stream
> to some form of implementation-dependent storage. Colloquially the term
> "log" is often used for this activity but is deprecated.

"Store" is also a noun meaning a persistent data repository.  We haven't agreed that "Log" is deprecated.

Note also that to "raise" an event is distinct from storing an event.  "Raising" an event does not imply persisting it.

Eric


> -----Original Message-----
> From: David Corlette [mailto:[hidden email]]
> Sent: Thursday, July 31, 2008 11:11 AM
> To: [hidden email]
> Subject: Re: [CEE-DISCUSSION-LIST] [logs] Defining Events, Logs, and
> Alerts (Round 2)

[David Corlette]

> 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.


>> 8. Audit (v)
>> * The act of observing an event and generating an event record with
>> details about the event.
>
> "Audit" is a very overloaded word and I would prefer to avoid it.  The
> common use as a term of art is something along the lines of "to compare an IT
> system's configuration against a baseline".  A distant second in terms of
> usage is "a security-relevant event record" or "to generate a security-relevant
> event record".

>> 9. Store (v)
>> * The act of committing an event record that is part of a data stream
>> to some form of implementation-dependent storage. Colloquially the term
>> "log" is often used for this activity but is deprecated.
>
> "Store" is also a noun meaning a persistent data repository.  We haven't
> agreed that "Log" is deprecated.

Yes, but that's my suggestion.
 
> Note also that to "raise" an event is distinct from storing an event.  
> "Raising" an event does not imply persisting it.

I think I was using "audit" in the same sense as you use the word "raise".  I'd be happy to use "raise" instead, as that is indeed clearer.  And the whole point was to differentiate that from the activity of storing an event record.

[Rainer Gerhards]

> -----Original Message-----
> From: David Corlette [mailto:[hidden email]]
> Sent: Thursday, July 31, 2008 10:35 PM
> To: [hidden email]
> Subject: [CEE-DISCUSSION-LIST] Fwd: RE: [CEE-DISCUSSION-LIST] [logs]
> Defining Events, Logs, and Alerts(Round 2)
>
> > 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?

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.

Rainer

[David Corlette]

Hi Rainer,



----------------
David Corlette
GRC Solution Architect
[hidden email]
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
<[hidden email]>, "Rainer
Gerhards" <[hidden email]> 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.

[Rainer Gerhards]

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.

Rainer


On Fri, 2008-08-01 at 09:00 -0600, David Corlette wrote:

> >>> On Fri, Aug 1, 2008 at  2:44 AM, in message
> <[hidden email]>, "Rainer
> Gerhards" <[hidden email]> 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.

[Wolfkiel, Joseph]

I would caution against limiting "event" definitions to state changes.
There is a well established lexicon in the intrusion detection community
that a signature match against a text string is an "event," however,
there is no defined state change involved.

From a top level perspective, a compliance test resulting in an
assessment of compliance should be considered an event-- call it an
"assessment event".  I just wouldn't advocate for making it a
"reportable event" from a CEE standpoint since the results formats for
OVAL and XCCDF already define timestamped reporting formats (equivalent
to audit logs) for assessment event reporting.  No point in reinventing
the wheel.

I think any definition of event should encompass conceptual metadata we
eventually want to assign an event -- start/stop time, sensor,
collection criterion, etc.  I think, if we want to limit ourselves to
audit records only, then we should create a specific type of "event"
that we're defining and not create a definition of "event" that
conflicts with everyone else's -- call it an "auditable event" that is
constrained to a state change described by an audit policy , collected
in an audit log, and transmitted as an alert according to a reporting
policy.

Lt Col Joseph L. Wolfkiel
Director, Computer Network Defense Research & Technology (CND R&T)
Program Management Office
9800 Savage Rd Ste 6767
Ft Meade, MD 20755-6767
Commercial 410-854-5401 DSN 244-5401
Fax [phone]



-----Original Message-----
From: Rainer Gerhards [mailto:[hidden email]]
Sent: Friday, August 01, 2008 11:37 AM
To: [hidden email]
Subject: Re: [CEE-DISCUSSION-LIST] Fwd: RE: [CEE-DISCUSSION-LIST] [logs]
Defining Events, Logs, and Alerts(Round 2)


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.

Rainer


On Fri, 2008-08-01 at 09:00 -0600, David Corlette wrote:
> >>> On Fri, Aug 1, 2008 at  2:44 AM, in message
> <[hidden email]>,
"Rainer
> Gerhards" <[hidden email]> 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.

[Rainer Gerhards]

Hi Joseph,

On Fri, 2008-08-01 at 19:15 +0200, Wolfkiel, Joseph wrote:
> I would caution against limiting "event" definitions to state changes.
> There is a well established lexicon in the intrusion detection community
> that a signature match against a text string is an "event," however,
> there is no defined state change involved.

I'd say it depends on what you look at. If I look from the signature
matching machinery's point of view, there *is* a state change (matching
state has changed from "unknown" to "match"). I elaborated on this on
the loganalysis mailing list and think the post did not make it to this
list here (as I was not subscribed at that time). You can find it in the
archives:

http://www.loganalysis.org/pipermail/loganalysis/2008-July/000714.html

The interesting question, however, is the scope and depth CEE is trying
to achive. I'll now try to find the CEE charter and will later comment
on that point.

Rainer

>
> From a top level perspective, a compliance test resulting in an
> assessment of compliance should be considered an event-- call it an
> "assessment event".  I just wouldn't advocate for making it a
> "reportable event" from a CEE standpoint since the results formats for
> OVAL and XCCDF already define timestamped reporting formats (equivalent
> to audit logs) for assessment event reporting.  No point in reinventing
> the wheel.
>
> I think any definition of event should encompass conceptual metadata we
> eventually want to assign an event -- start/stop time, sensor,
> collection criterion, etc.  I think, if we want to limit ourselves to
> audit records only, then we should create a specific type of "event"
> that we're defining and not create a definition of "event" that
> conflicts with everyone else's -- call it an "auditable event" that is
> constrained to a state change described by an audit policy , collected
> in an audit log, and transmitted as an alert according to a reporting
> policy.
>
> Lt Col Joseph L. Wolfkiel
> Director, Computer Network Defense Research & Technology (CND R&T)
> Program Management Office
> 9800 Savage Rd Ste 6767
> Ft Meade, MD 20755-6767
> Commercial 410-854-5401 DSN 244-5401
> Fax [phone]
>
>
>
> -----Original Message-----
> From: Rainer Gerhards [mailto:[hidden email]]
> Sent: Friday, August 01, 2008 11:37 AM
> To: [hidden email]
> Subject: Re: [CEE-DISCUSSION-LIST] Fwd: RE: [CEE-DISCUSSION-LIST] [logs]
> Defining Events, Logs, and Alerts(Round 2)
>
>
> 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.
>
> Rainer
>
>
> On Fri, 2008-08-01 at 09:00 -0600, David Corlette wrote:
> > >>> On Fri, Aug 1, 2008 at  2:44 AM, in message
> > <[hidden email]>,
> "Rainer
> > Gerhards" <[hidden email]> 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.