LogAnalysis
[logs] How to define Log, Event, and Alert? Jul 23 2008 03:26PM
Heinbockel, Bill (heinbockel mitre org) (3 replies)
Re: [logs] How to define Log, Event, and Alert? Jul 23 2008 09:43PM
Jon Stearley (jrstear sandia gov)
Re: [logs] How to define Log, Event, and Alert? Jul 23 2008 05:47PM
Ron Gula (rgula tenablesecurity com) (1 replies)
Re: [logs] How to define Log, Event, and Alert? Jul 23 2008 08:21PM
Anton Chuvakin (anton chuvakin org) (3 replies)
Re: [logs] How to define Log, Event, and Alert? Jul 23 2008 09:22PM
David Corlette (DCorlette novell com)
Re: [logs] How to define Log, Event, and Alert? Jul 23 2008 09:12PM
Andrew Hay (andrewsmhay gmail com) (2 replies)
Re: [logs] How to define Log, Event, and Alert? Jul 24 2008 12:59PM
Ron Gula (rgula tenablesecurity com) (1 replies)
Re: [logs] How to define Log, Event, and Alert? Jul 24 2008 04:17PM
Andrew Hay (andrewsmhay gmail com)
Re: [logs] How to define Log, Event, and Alert? Jul 23 2008 09:33PM
Anton Chuvakin (anton chuvakin org)
RE: [logs] How to define Log, Event, and Alert? Jul 23 2008 08:56PM
Tina Bird (tbird precision-guesswork com) (2 replies)
[logs] RE: How to define Log, Event, and Alert? Jul 24 2008 02:55PM
Heinbockel, Bill (heinbockel mitre org)
RE: [logs] How to define Log, Event, and Alert? Jul 24 2008 09:36AM
Rainer Gerhards (rgerhards hq adiscon com)
Hi,

I am a bit late on this topic, but as I always like to nit-pick on
logging...

I actually tend to agree that an event is *always* *associated* with a
state change. The state change, however, may be subtle and not always
obvious.

Let's take this post excerpt as an example:

##
some logs which don't indicate
a state change such as login failures,
##

At first, a login failure seems to have not changed any state. After
all, nobody was logged in before the event and nobody is logged in after
it. HOWEVER, here our view is just not granular enough.

Let me take the position of the login machinery. That machine obviously
has states for "awaiting login", "authentication requested", "auth
success" and "auth failure" (among many others). What happens in the
failed login case is that the machine transits between these states:

"awaiting login" --> "auth req" --> "auth failure" --> "awaiting login"

Obviously, state in this subsystem has changed three times. An upper
level (e.g. a user process creator) may not have seen a state change,
because the transitions did not request one. So at the upper level, we
have no state change.

Depending on the granularity of logging we would like to have, we need
to look at state changes at different levels. If I am interested in
security logging, I most probably should look at the login machinery.
And there, I see three transitions. As such, I may report three
different events.

In a somewhat more abstract form, I even think an event is *always*
bound to a state change. If we look closely enough at an entity, and
this entity does not change state, so what can we then report? Is it
noteworthy to report that entity x remains in the same state a it had a
while ago? And even if so, couldn't one say that the state of x has
changed in a subtle way - time needs to be considered part of the
entities "state set".

With the "state set" I mean anything that makes up and influences the
state of the entity. It includes all properties that differentiate
between different states. The state set is obviously defined by the
entity, but also by the needs of the observer (so the same entity may
have different state sets if different observers look at it). For a
given observer (use case) and a given entity, there is exactly one state
set, consisting of mutually exclusive states and a set of properties
that identify these states.

In this point of view, an event is actually another word for a state
transition. If there is no state transition, there is no event. And why
should there be one? Let's assume the use case requires tracking of
(identical) states over time. As such, elapsed time is part of the state
set. Now let's assume all other properties of the state set remain
identical, but time elapses. Now we still have a state transition,
because the state set changes between time "than" and time "now". This
justifies an event. If, however, the use case does not require tracking
of continuity, elapsed time is not part of the state set. In the same
example above, we do now not have a state change (all other properties
remain identical) and consequently no event happens. This may sound like
loss of information, but we defined that the observer is not interested
in elapsed time. As such, from the POV of this observer, nothing
happened. So we are correct in not raising an event.

>From this I conclude:

a) there is no such thing like an "absolute event" - an event is always
relative to the needs of the observer
b) thus different observers may have different perception of what
justifies raising an event
c) what the observer is interested in is defined in the "state set"
d) an event is generated when a change in the "state set" is detected

Trying (and probably failing) to get a short grip on this, I would say
"An event is a change in observer-relevant properties of an entity".
Which, of course leads to the need to define observer,
observer-relevant, property and entity...

I haven't looked at CEE enough to know if there are definitions of these
(or similar) terms. Actually, when I looked at CEE some very long time
ago I have to admit it didn't look very appealing. But I now have
subscribed to the mailing list and will see if I can contribute (or use
;)) to/from the work.

An interesting side-note of a) is that one may (try to) define a
superset of state sets of all possible observers. Actually, I think this
is what auditing people try to define when they design audit points. The
knobs that trigger specific events provide the ability to limit the
actual (running) state set to the subset that the configuring observer
is interested in. And if you ever wanted to audit anything but did not
find an audit point in the software for it, auditing designers made a
wrong assumption on the required state superset ;)

Ummm... and this has become a long and somewhat ... well ... condensed
mail. I hope it still is useful ;)

Rainer

> -----Original Message-----
> From: loganalysis-bounces (at) loganalysis (dot) org [email concealed] [mailto:loganalysis-
> bounces (at) loganalysis (dot) org [email concealed]] On Behalf Of Tina Bird
> Sent: Wednesday, July 23, 2008 10:57 PM
> To: loganalysis (at) loganalysis (dot) org [email concealed]; CEE-DISCUSSION-LIST (at) LISTS.MITRE (dot) ORG [email concealed]
> Subject: RE: [logs] 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
> _______________________________________________
> LogAnalysis mailing list
> LogAnalysis (at) loganalysis (dot) org [email concealed]
> http://www.loganalysis.org/mailman/listinfo/loganalysis

_______________________________________________
LogAnalysis mailing list
LogAnalysis (at) loganalysis (dot) org [email concealed]
http://www.loganalysis.org/mailman/listinfo/loganalysis

[ reply ]
Re: [logs] How to define Log, Event, and Alert? Jul 23 2008 03:45PM
Bill Scherr IV (bschnzl cotse net) (2 replies)
Re: [logs] How to define Log, Event, and Alert? Jul 23 2008 05:37PM
Michael Kinsley (michael kinsley sensage com)
Re: [logs] How to define Log, Event, and Alert? Jul 23 2008 04:40PM
Chris Lonvick (clonvick cisco com)


 

Privacy Statement
Copyright 2010, SecurityFocus