RE: How to define Log, Event, and Alert?

 
> Same thing. Event is not necessarily "a state change."  It is a
> broader thing, basically,   "something that happened" (even though a
> state is the same - e.g. backup is proceeding, attack was seen, etc)

> >> Event:
> >>        A discrete, distinct, and discernible state change in an
> >> environment.
> >
> > In some aspects, state changes such as processes dieing or starting
> > are surely events, but I also think that some logs which 
> don't indicate
> > a state change such as login failures, port scanning, intrusion
> > detection logs, and so on are noteworthy and worth alerting on.

[Now's the time to ask the question -- how much overlap *is* there between
the CEE discussion list and this list?]...pardon the cross-posting, I've
been meaning to respond to this since yesterday...

The whole point of this discussion is to clarify terms, so I guess this is
one place where nit-picking is actually encouraged ;-)

The word "event" carries the connotation of something happening. "Something"
may be a state change; in the discussions of nomenclature in which I've
participated "something" has been used primarily to describe authentication,
application functions and errors, alarms generated by IDS, etc.

In the situation in which I've discussed possible candidates for "action" in
a message template (you know who you are ;-)), I've strongly advocated
"report" as an action. "Report" complicates things, because most actions can
be assigned a success or failure token, but knowing that the "report" action
was successful doesn't help you much -- you don't want to know the report
*worked*, you want to know what the report *reported*.

Consider the large number of UNIXen running cron jobs to verify disk
utilization, available memory etc. and dumping the results into syslog. And
then consider the impressive amounts of frustration generated in all those
sysadmins who get the message "cron job ran" or "cron job failed" and then
realized they had to go back and actually capture the output somehow....

If we stick with the word "event," I argue that it needs to be defined in
such a way that it includes reporting activities, and also allows for a
result other than success or failure. For instance, the result may store the
numeric result of the report, if applicable, or the name of a file in which
the report is stored. If we structure the definition to include only state
changes, we disregard the often critical contextual information that gives
the event significance.

The more I think about it, though, the more I wonder if we can't just skip
over the definition of event -- at least temporarily (like writers do when
they leave the introduction or first chapter of the book for last) -- and
work on the components of the entry/record first. That might make it easier
to clarify what "event" means in the context of data collection, after we've
got a reasonable amount of use cases and data samples to play with.

cheers -- tbird