session id

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

session id

Peter Czanik

Hello,

While working on patterns for syslog-ng's patterndb ( http://www.balabit.com/wiki/patterndb ) we treated session id as a central element (originally for login/logout events, but could be applied to anything). It was often the same as the process identifier, but it could also be a mailq id, or anything suitable to identify opposite events, like login/logout or help to correlate events in logs. I could not find anything similar in the CEE field list. Could something like this introduced?

Benefit: an easy to find field aiding log analysis.

Side effect: the same values might appear in two different fields.

Bye,

-- 
Peter Czanik (CzP) [hidden email]
BalaBit IT Security / syslog-ng upstream
http://czanik.blogs.balabit.com/
Reply | Threaded
Open this post in threaded view
|

Re: session id

heinbockel
There are several ids that we may need to track:

session or audit id -- for events occurring within the same user session
event id -- for distinguishing different events (also useful for references in
correlation/aggregation)
record id -- for combining a single event record that may have been fragmented
across multiple event "messages"

It may be the case that the event id can also be used as the record id, though I
think of the record id as being more of an event transport/protocol issue


William Heinbockel
The MITRE Corporation


>-----Original Message-----
>From: Peter Czanik [mailto:[hidden email]]
>Sent: Wednesday, 24 November 2010 09:06
>To: cee-discussion-list CEE-Related Discussion
>Subject: [CEE-DISCUSSION-LIST] session id
>
>Hello,
>
>
>While working on patterns for syslog-ng's patterndb (
>http://www.balabit.com/wiki/patterndb ) we treated session id as a central
>element (originally for login/logout events, but could be applied to
>anything). It was often the same as the process identifier, but it could
>also be a mailq id, or anything suitable to identify opposite events, like
>login/logout or help to correlate events in logs. I could not find anything
>similar in the CEE field list. Could something like this introduced?
>
>Benefit: an easy to find field aiding log analysis.
>
>Side effect: the same values might appear in two different fields.
>
>
>Bye,
>
>
>--
>Peter Czanik (CzP) <[hidden email]> <mailto:[hidden email]>
>BalaBit IT Security / syslog-ng upstream
>http://czanik.blogs.balabit.com/

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: session id

heinbockel
And I forgot one:

msg id -- the identifier that corresponds to the event type/message (e.g., 528
[MS Windows XP], 106001 [Cisco PIX])


William Heinbockel
The MITRE Corporation


>-----Original Message-----
>From: Heinbockel, Bill [mailto:[hidden email]]
>Sent: Monday, 29 November 2010 11:02
>To: cee-discussion-list CEE-Related Discussion
>Subject: Re: [CEE-DISCUSSION-LIST] session id
>
>There are several ids that we may need to track:
>
>session or audit id -- for events occurring within the same user session
>event id -- for distinguishing different events (also useful for references
>in
>correlation/aggregation)
>record id -- for combining a single event record that may have been
>fragmented
>across multiple event "messages"
>
>It may be the case that the event id can also be used as the record id,
>though I
>think of the record id as being more of an event transport/protocol issue
>
>
>William Heinbockel
>The MITRE Corporation
>
>
>>-----Original Message-----
>>From: Peter Czanik [mailto:[hidden email]]
>>Sent: Wednesday, 24 November 2010 09:06
>>To: cee-discussion-list CEE-Related Discussion
>>Subject: [CEE-DISCUSSION-LIST] session id
>>
>>Hello,
>>
>>
>>While working on patterns for syslog-ng's patterndb (
>>http://www.balabit.com/wiki/patterndb ) we treated session id as a central
>>element (originally for login/logout events, but could be applied to
>>anything). It was often the same as the process identifier, but it could
>>also be a mailq id, or anything suitable to identify opposite events, like
>>login/logout or help to correlate events in logs. I could not find anything
>>similar in the CEE field list. Could something like this introduced?
>>
>>Benefit: an easy to find field aiding log analysis.
>>
>>Side effect: the same values might appear in two different fields.
>>
>>
>>Bye,
>>
>>
>>--
>>Peter Czanik (CzP) <[hidden email]> <mailto:[hidden email]>
>>BalaBit IT Security / syslog-ng upstream
>>http://czanik.blogs.balabit.com/

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: session id

Lawrence Smith
Just some thoughts on this...

Regarding Event ID... There is the potential for duplication. An Event Producer may assign its own ID to a particular Event, while a SIEM system may assign a different ID (such as a GUID).

Off the top of my head, I can think of a few other IDs that SIEM systems track:

* For Managed Security Services providers, there may be some form of Customer ID associated with the Event.
* An upstream agent may identify itself in the Event, so something like an Agent ID may be present.
* An organization may have assigned an Asset ID to the Event Producer. This could be included by the Event Producer, or by an upstream agent.

There's also a CVE or other vulnerability ID, as well as a virus or malware ID. These may or may not be identified by the msg id. (e.g. Maybe the msg id doesn't contain the virus id, but rather another value that means "virus detected," with a secondary field containing the virus id.) 

Regards,

Lawrence Smith, CISSP, CSSLP
On Mon, Nov 29, 2010 at 11:50 AM, Heinbockel, Bill <[hidden email]> wrote:
And I forgot one:

msg id -- the identifier that corresponds to the event type/message (e.g., 528
[MS Windows XP], 106001 [Cisco PIX])


William Heinbockel
The MITRE Corporation


>-----Original Message-----
>From: Heinbockel, Bill [mailto:[hidden email]]
>Sent: Monday, 29 November 2010 11:02
>To: cee-discussion-list CEE-Related Discussion
>Subject: Re: [CEE-DISCUSSION-LIST] session id
>
>There are several ids that we may need to track:
>
>session or audit id -- for events occurring within the same user session
>event id -- for distinguishing different events (also useful for references
>in
>correlation/aggregation)
>record id -- for combining a single event record that may have been
>fragmented
>across multiple event "messages"
>
>It may be the case that the event id can also be used as the record id,
>though I
>think of the record id as being more of an event transport/protocol issue
>
>
>William Heinbockel
>The MITRE Corporation
>
>
>>-----Original Message-----
>>From: Peter Czanik [mailto:[hidden email]]
>>Sent: Wednesday, 24 November 2010 09:06
>>To: cee-discussion-list CEE-Related Discussion
>>Subject: [CEE-DISCUSSION-LIST] session id
>>
>>Hello,
>>
>>
>>While working on patterns for syslog-ng's patterndb (
>>http://www.balabit.com/wiki/patterndb ) we treated session id as a central
>>element (originally for login/logout events, but could be applied to
>>anything). It was often the same as the process identifier, but it could
>>also be a mailq id, or anything suitable to identify opposite events, like
>>login/logout or help to correlate events in logs. I could not find anything
>>similar in the CEE field list. Could something like this introduced?
>>
>>Benefit: an easy to find field aiding log analysis.
>>
>>Side effect: the same values might appear in two different fields.
>>
>>
>>Bye,
>>
>>
>>--
>>Peter Czanik (CzP) <[hidden email]> <mailto:[hidden email]>
>>BalaBit IT Security / syslog-ng upstream
>>http://czanik.blogs.balabit.com/

Reply | Threaded
Open this post in threaded view
|

Re: session id

David Corlette
In reply to this post by heinbockel
Hi Bill,

Within XDAS v2 we are currently proposing (although this has yet to be discussed in great detail) the following:

"Grouping ID" - an identifier used to group together multiple events that are related to each other, like multiple events from a single session, or multiple modifications to a single row/object/file triggered by a single user action.

"Transaction ID" - an identifier used to link events together into a single transaction. This is different from the Grouping ID because a transaction structure implies some degree of structure, like a database query, start session/end session semantics, or caller/callee semantics.

Think of the "Transaction ID" as the parentheses around a set, and the "Grouping ID" as tags that relate the individual elements within the set.

You also mention:
event id
Which I'd call:
"Event ID" - a unique identifier for the specific event.
Note that this gets really tricky - who assigns this ID? How is uniqueness guaranteed?
If you have multiple processes writing to syslog, do the processes create the ID? Or does syslogd/-ng?
One possible structure would be to have e.g. syslog-ng attach an Event ID to the record just before it gets sent to a remote consumer. In that case, having the ID increment by one each time would actually allow you to detect dropped or injected (spoofed) events a little more easily. Or you could do this on a source process/thread basis, or something.
What would be really slick would be to define a standard where event producers presented a raw view of the event if a particular RESTful URL was visited, with the event ID as the key.

And finally, your 'msg id' we've explicitly called:
"Vendor Event Code" - because this field has no real meaning in the context of the standard, it's not unique across all products, it's only an artifact of the vendor's understanding of what the event means above and beyond the canonicalized standard.


>>> On 29.11.2010 at 11:02, in message
<[hidden email]>, "Heinbockel,
Bill" <[hidden email]> wrote:
> There are several ids that we may need to track:
>
> session or audit id -- for events occurring within the same user session
> event id -- for distinguishing different events (also useful for references in
> correlation/aggregation)
> record id -- for combining a single event record that may have been fragmented
> across multiple event "messages"
> msg id -- the identifier that corresponds to the event type/message (e.g., 528
[MS Windows XP], 106001 [Cisco PIX])

>
> It may be the case that the event id can also be used as the record id,
> though I
> think of the record id as being more of an event transport/protocol issue
>
>
> William Heinbockel
> The MITRE Corporation
>
>
>>-----Original Message-----
>>From: Peter Czanik [mailto:[hidden email]]
>>Sent: Wednesday, 24 November 2010 09:06
>>To: cee-discussion-list CEE-Related Discussion
>>Subject: [CEE-DISCUSSION-LIST] session id
>>
>>Hello,
>>
>>
>>While working on patterns for syslog-ng's patterndb (
>>http://www.balabit.com/wiki/patterndb ) we treated session id as a central
>>element (originally for login/logout events, but could be applied to
>>anything). It was often the same as the process identifier, but it could
>>also be a mailq id, or anything suitable to identify opposite events, like
>>login/logout or help to correlate events in logs. I could not find anything
>>similar in the CEE field list. Could something like this introduced?
>>
>>Benefit: an easy to find field aiding log analysis.
>>
>>Side effect: the same values might appear in two different fields.
>>
>>
>>Bye,
>>
>>
>>--
>>Peter Czanik (CzP) <[hidden email]> <mailto:[hidden email]>
>>BalaBit IT Security / syslog-ng upstream
>>http://czanik.blogs.balabit.com/
Reply | Threaded
Open this post in threaded view
|

Re: session id

Eric Fitzgerald-2
Hey David,

Let me expand a little further.

ID's are used to relate events to each other.

It seems to me that "Transaction ID" as you describe is just a special case of "grouping ID" from that perspective.

But I see two other special cases, which I'll call "horizontal peer ID" and "vertical peer ID".

It's sometimes the case that you want to trace a complex activity through several (or many) processing components, each of which generate logs.  The ideal in this situation is the "transaction ID" concept- where the components all share a unique ID with each other and that each component includes this ID in all events related to the activity.

However in my experience it's more often the case that different components in the system have different developers, and that one or more developers is unwilling or unable to make the necessary protocol/messaging/interface changes or the logging changes needed to capture this end-to-end ID.

In that case, you have two kinds of scenarios to deal with.
1. Horizontal peer correlation - my component in the stack on this side of the conversation talks to another component I own on the other side of the conversation.  However I don't control the interfaces/protocols in components between my two peers.  So I put in an ID that can be used to correlate horizontally between my two components.

2. Vertical peer correlation - Same situation, but how do I correlate my events with the events of other intervening components?  By taking a property of the common interface that we share, and using that as an ID in my events.  I then only need to convince the developer of the other component to also include the ID, which is an easier task for them because they already have it by nature of our interface.  For instance, I could use a pointer value or handle ID to identify my "session" with a lower level component in the application stack.  As long as their event records the same value, then my event can be positively correlated with their event.

So my taxonomy would be:

Event grouping correlators
  * Transaction IDs
  * Horizontal peer IDs
  * Vertical peer IDs

Thanks,
Eric

-----Original Message-----
From: David Corlette [mailto:[hidden email]]
Sent: Monday, November 29, 2010 12:59 PM
To: [hidden email]
Subject: Re: [CEE-DISCUSSION-LIST] session id

Hi Bill,

Within XDAS v2 we are currently proposing (although this has yet to be discussed in great detail) the following:

"Grouping ID" - an identifier used to group together multiple events that are related to each other, like multiple events from a single session, or multiple modifications to a single row/object/file triggered by a single user action.

"Transaction ID" - an identifier used to link events together into a single transaction. This is different from the Grouping ID because a transaction structure implies some degree of structure, like a database query, start session/end session semantics, or caller/callee semantics.

Think of the "Transaction ID" as the parentheses around a set, and the "Grouping ID" as tags that relate the individual elements within the set.

You also mention:
event id
Which I'd call:
"Event ID" - a unique identifier for the specific event.
Note that this gets really tricky - who assigns this ID? How is uniqueness guaranteed?
If you have multiple processes writing to syslog, do the processes create the ID? Or does syslogd/-ng?
One possible structure would be to have e.g. syslog-ng attach an Event ID to the record just before it gets sent to a remote consumer. In that case, having the ID increment by one each time would actually allow you to detect dropped or injected (spoofed) events a little more easily. Or you could do this on a source process/thread basis, or something.
What would be really slick would be to define a standard where event producers presented a raw view of the event if a particular RESTful URL was visited, with the event ID as the key.

And finally, your 'msg id' we've explicitly called:
"Vendor Event Code" - because this field has no real meaning in the context of the standard, it's not unique across all products, it's only an artifact of the vendor's understanding of what the event means above and beyond the canonicalized standard.


>>> On 29.11.2010 at 11:02, in message
<[hidden email]>, "Heinbockel, Bill" <[hidden email]> wrote:

> There are several ids that we may need to track:
>
> session or audit id -- for events occurring within the same user
> session event id -- for distinguishing different events (also useful
> for references in
> correlation/aggregation)
> record id -- for combining a single event record that may have been
> fragmented across multiple event "messages"
> msg id -- the identifier that corresponds to the event type/message
> (e.g., 528
[MS Windows XP], 106001 [Cisco PIX])

>
> It may be the case that the event id can also be used as the record
> id, though I think of the record id as being more of an event
> transport/protocol issue
>
>
> William Heinbockel
> The MITRE Corporation
>
>
>>-----Original Message-----
>>From: Peter Czanik [mailto:[hidden email]]
>>Sent: Wednesday, 24 November 2010 09:06
>>To: cee-discussion-list CEE-Related Discussion
>>Subject: [CEE-DISCUSSION-LIST] session id
>>
>>Hello,
>>
>>
>>While working on patterns for syslog-ng's patterndb (
>>http://www.balabit.com/wiki/patterndb ) we treated session id as a
>>central element (originally for login/logout events, but could be
>>applied to anything). It was often the same as the process identifier,
>>but it could also be a mailq id, or anything suitable to identify
>>opposite events, like login/logout or help to correlate events in
>>logs. I could not find anything similar in the CEE field list. Could something like this introduced?
>>
>>Benefit: an easy to find field aiding log analysis.
>>
>>Side effect: the same values might appear in two different fields.
>>
>>
>>Bye,
>>
>>
>>--
>>Peter Czanik (CzP) <[hidden email]> <mailto:[hidden email]>
>>BalaBit IT Security / syslog-ng upstream
>>http://czanik.blogs.balabit.com/
Reply | Threaded
Open this post in threaded view
|

Re: session id

David Corlette
Hi Eric,

I like your basic approach, although I find your "horizontal" and "vertical" labels a bit obscure.

Just as you describe, I have been imagining using something like the originating host:port of an SSH connection as the "transaction ID" (vertical ID in your terminology) for both sides of the connection. As you mention, that means that neither side has to add a new method to their APIs or anything.

From what I can tell, there are N scenarios where some form of correlation ID is required, but many of the cases can collapse into just a couple required fields. I think at least two are necessary, so you can for example track a workflow process ID plus various subgroups of steps, but this is more of a gut instinct than anything I've actually spent a lot of time validating.

Perhaps we can come up with as full a set of correlation scenarios, and then talk about the minimum number of such fields?

Examples:
- Long-running DB transaction
- Bunch of related changes, like changing many attributes on a set of objects in a single operation
- Workflow and multi-step process IDs
- Remote procedure calls and remote sessions
- ...

P.S. I've cross-posted to the sec-das (xdas) list, as the discussion will be germane over there as well.

>>> On 29.11.2010 at 19:52, in message
<[hidden email]
.microsoft.com>, Eric Fitzgerald <[hidden email]> wrote:

> Hey David,
>
> Let me expand a little further.
>
> ID's are used to relate events to each other.
>
> It seems to me that "Transaction ID" as you describe is just a special case
> of "grouping ID" from that perspective.
>
> But I see two other special cases, which I'll call "horizontal peer ID" and
> "vertical peer ID".
>
> It's sometimes the case that you want to trace a complex activity through
> several (or many) processing components, each of which generate logs.  The
> ideal in this situation is the "transaction ID" concept- where the components
> all share a unique ID with each other and that each component includes this
> ID in all events related to the activity.
>
> However in my experience it's more often the case that different components
> in the system have different developers, and that one or more developers is
> unwilling or unable to make the necessary protocol/messaging/interface
> changes or the logging changes needed to capture this end-to-end ID.
>
> In that case, you have two kinds of scenarios to deal with.
> 1. Horizontal peer correlation - my component in the stack on this side of
> the conversation talks to another component I own on the other side of the
> conversation.  However I don't control the interfaces/protocols in components
> between my two peers.  So I put in an ID that can be used to correlate
> horizontally between my two components.
>
> 2. Vertical peer correlation - Same situation, but how do I correlate my
> events with the events of other intervening components?  By taking a property
> of the common interface that we share, and using that as an ID in my events.  
> I then only need to convince the developer of the other component to also
> include the ID, which is an easier task for them because they already have it
> by nature of our interface.  For instance, I could use a pointer value or
> handle ID to identify my "session" with a lower level component in the
> application stack.  As long as their event records the same value, then my
> event can be positively correlated with their event.
>
> So my taxonomy would be:
>
> Event grouping correlators
>   * Transaction IDs
>   * Horizontal peer IDs
>   * Vertical peer IDs
>
> Thanks,
> Eric
>
> -----Original Message-----
> From: David Corlette [mailto:[hidden email]]
> Sent: Monday, November 29, 2010 12:59 PM
> To: [hidden email]
> Subject: Re: [CEE-DISCUSSION-LIST] session id
>
> Hi Bill,
>
> Within XDAS v2 we are currently proposing (although this has yet to be
> discussed in great detail) the following:
>
> "Grouping ID" - an identifier used to group together multiple events that are
> related to each other, like multiple events from a single session, or
> multiple modifications to a single row/object/file triggered by a single user
> action.
>
> "Transaction ID" - an identifier used to link events together into a single
> transaction. This is different from the Grouping ID because a transaction
> structure implies some degree of structure, like a database query, start
> session/end session semantics, or caller/callee semantics.
>
> Think of the "Transaction ID" as the parentheses around a set, and the
> "Grouping ID" as tags that relate the individual elements within the set.
>
> You also mention:
> event id
> Which I'd call:
> "Event ID" - a unique identifier for the specific event.
> Note that this gets really tricky - who assigns this ID? How is uniqueness
> guaranteed?
> If you have multiple processes writing to syslog, do the processes create
> the ID? Or does syslogd/-ng?
> One possible structure would be to have e.g. syslog-ng attach an Event ID to
> the record just before it gets sent to a remote consumer. In that case,
> having the ID increment by one each time would actually allow you to detect
> dropped or injected (spoofed) events a little more easily. Or you could do
> this on a source process/thread basis, or something.
> What would be really slick would be to define a standard where event
> producers presented a raw view of the event if a particular RESTful URL was
> visited, with the event ID as the key.
>
> And finally, your 'msg id' we've explicitly called:
> "Vendor Event Code" - because this field has no real meaning in the context
> of the standard, it's not unique across all products, it's only an artifact
> of the vendor's understanding of what the event means above and beyond the
> canonicalized standard.
>
>
>>>> On 29.11.2010 at 11:02, in message
> <[hidden email]>, "Heinbockel,
> Bill" <[hidden email]> wrote:
>> There are several ids that we may need to track:
>>
>> session or audit id -- for events occurring within the same user
>> session event id -- for distinguishing different events (also useful
>> for references in
>> correlation/aggregation)
>> record id -- for combining a single event record that may have been
>> fragmented across multiple event "messages"
>> msg id -- the identifier that corresponds to the event type/message
>> (e.g., 528
> [MS Windows XP], 106001 [Cisco PIX])
>>
>> It may be the case that the event id can also be used as the record
>> id, though I think of the record id as being more of an event
>> transport/protocol issue
>>
>>
>> William Heinbockel
>> The MITRE Corporation
>>
>>
>>>-----Original Message-----
>>>From: Peter Czanik [mailto:[hidden email]]
>>>Sent: Wednesday, 24 November 2010 09:06
>>>To: cee-discussion-list CEE-Related Discussion
>>>Subject: [CEE-DISCUSSION-LIST] session id
>>>
>>>Hello,
>>>
>>>
>>>While working on patterns for syslog-ng's patterndb (
>>>http://www.balabit.com/wiki/patterndb ) we treated session id as a
>>>central element (originally for login/logout events, but could be
>>>applied to anything). It was often the same as the process identifier,
>>>but it could also be a mailq id, or anything suitable to identify
>>>opposite events, like login/logout or help to correlate events in
>>>logs. I could not find anything similar in the CEE field list. Could
> something like this introduced?
>>>
>>>Benefit: an easy to find field aiding log analysis.
>>>
>>>Side effect: the same values might appear in two different fields.
>>>
>>>
>>>Bye,
>>>
>>>
>>>--
>>>Peter Czanik (CzP) <[hidden email]> <mailto:[hidden email]>
>>>BalaBit IT Security / syslog-ng upstream
>>>http://czanik.blogs.balabit.com/
Reply | Threaded
Open this post in threaded view
|

Re: session id

Eric Fitzgerald-2
Hey David,

In hindsight I realize that "horizontal" and "vertical" were pretty obscure terms.  If you imagine a picture with a vertically oriented OSI stack on each side of a connection, then horizontal and vertical make more sense.  Basically "horizontal" means that I control two peer layers that I want to correlate but not intervening components.  "Vertical" means I want to correlate with logs from a peer layer that I don't control.

I believe that either 2 or 3 is the magic number of required correlation fields.  I can conceive of edge cases where you need two vertical correlators ("up" and "down") but I have no example use case to support that conjecture.  A transaction ID typically trumps a horizontal correlator, or at least a horizontal correlator is a specific limited case of a transaction ID.

More scenarios:
- Correlation with a dependent component or protocol, e.g. correlating application layer events with network layer events on the same device
- Generalized session - many independent operations are correlated with a single longer-lived piece of state for another component on the system.  This is kind of a mix between your "database transaction" and "remote session" cases.  I'm specifically thinking of logon sessions in Windows, which is also close to Peter's original use case.

I wrote a short paper on correlation scenarios earlier this year and posted it to the sharepoint.  I'll try to dig that up.

Eric

-----Original Message-----
From: David Corlette [mailto:[hidden email]]
Sent: Monday, November 29, 2010 6:31 PM
To: [hidden email]
Subject: Re: [CEE-DISCUSSION-LIST] session id

Hi Eric,

I like your basic approach, although I find your "horizontal" and "vertical" labels a bit obscure.

Just as you describe, I have been imagining using something like the originating host:port of an SSH connection as the "transaction ID" (vertical ID in your terminology) for both sides of the connection. As you mention, that means that neither side has to add a new method to their APIs or anything.

From what I can tell, there are N scenarios where some form of correlation ID is required, but many of the cases can collapse into just a couple required fields. I think at least two are necessary, so you can for example track a workflow process ID plus various subgroups of steps, but this is more of a gut instinct than anything I've actually spent a lot of time validating.

Perhaps we can come up with as full a set of correlation scenarios, and then talk about the minimum number of such fields?

Examples:
- Long-running DB transaction
- Bunch of related changes, like changing many attributes on a set of objects in a single operation
- Workflow and multi-step process IDs
- Remote procedure calls and remote sessions
- ...

P.S. I've cross-posted to the sec-das (xdas) list, as the discussion will be germane over there as well.

>>> On 29.11.2010 at 19:52, in message
<[hidden email]
.microsoft.com>, Eric Fitzgerald <[hidden email]> wrote:

> Hey David,
>
> Let me expand a little further.
>
> ID's are used to relate events to each other.
>
> It seems to me that "Transaction ID" as you describe is just a special
> case of "grouping ID" from that perspective.
>
> But I see two other special cases, which I'll call "horizontal peer
> ID" and "vertical peer ID".
>
> It's sometimes the case that you want to trace a complex activity
> through several (or many) processing components, each of which
> generate logs.  The ideal in this situation is the "transaction ID"
> concept- where the components all share a unique ID with each other
> and that each component includes this ID in all events related to the activity.
>
> However in my experience it's more often the case that different
> components in the system have different developers, and that one or
> more developers is unwilling or unable to make the necessary
> protocol/messaging/interface changes or the logging changes needed to capture this end-to-end ID.
>
> In that case, you have two kinds of scenarios to deal with.
> 1. Horizontal peer correlation - my component in the stack on this
> side of the conversation talks to another component I own on the other
> side of the conversation.  However I don't control the
> interfaces/protocols in components between my two peers.  So I put in
> an ID that can be used to correlate horizontally between my two components.
>
> 2. Vertical peer correlation - Same situation, but how do I correlate
> my events with the events of other intervening components?  By taking
> a property of the common interface that we share, and using that as an ID in my events.
> I then only need to convince the developer of the other component to
> also include the ID, which is an easier task for them because they
> already have it by nature of our interface.  For instance, I could use
> a pointer value or handle ID to identify my "session" with a lower
> level component in the application stack.  As long as their event
> records the same value, then my event can be positively correlated with their event.
>
> So my taxonomy would be:
>
> Event grouping correlators
>   * Transaction IDs
>   * Horizontal peer IDs
>   * Vertical peer IDs
>
> Thanks,
> Eric
>
> -----Original Message-----
> From: David Corlette [mailto:[hidden email]]
> Sent: Monday, November 29, 2010 12:59 PM
> To: [hidden email]
> Subject: Re: [CEE-DISCUSSION-LIST] session id
>
> Hi Bill,
>
> Within XDAS v2 we are currently proposing (although this has yet to be
> discussed in great detail) the following:
>
> "Grouping ID" - an identifier used to group together multiple events
> that are related to each other, like multiple events from a single
> session, or multiple modifications to a single row/object/file
> triggered by a single user action.
>
> "Transaction ID" - an identifier used to link events together into a
> single transaction. This is different from the Grouping ID because a
> transaction structure implies some degree of structure, like a
> database query, start session/end session semantics, or caller/callee semantics.
>
> Think of the "Transaction ID" as the parentheses around a set, and the
> "Grouping ID" as tags that relate the individual elements within the set.
>
> You also mention:
> event id
> Which I'd call:
> "Event ID" - a unique identifier for the specific event.
> Note that this gets really tricky - who assigns this ID? How is
> uniqueness guaranteed?
> If you have multiple processes writing to syslog, do the processes
> create the ID? Or does syslogd/-ng?
> One possible structure would be to have e.g. syslog-ng attach an Event
> ID to the record just before it gets sent to a remote consumer. In
> that case, having the ID increment by one each time would actually
> allow you to detect dropped or injected (spoofed) events a little more
> easily. Or you could do this on a source process/thread basis, or something.
> What would be really slick would be to define a standard where event
> producers presented a raw view of the event if a particular RESTful
> URL was visited, with the event ID as the key.
>
> And finally, your 'msg id' we've explicitly called:
> "Vendor Event Code" - because this field has no real meaning in the
> context of the standard, it's not unique across all products, it's
> only an artifact of the vendor's understanding of what the event means
> above and beyond the canonicalized standard.
>
>
>>>> On 29.11.2010 at 11:02, in message
> <[hidden email]>,
> "Heinbockel, Bill" <[hidden email]> wrote:
>> There are several ids that we may need to track:
>>
>> session or audit id -- for events occurring within the same user
>> session event id -- for distinguishing different events (also useful
>> for references in
>> correlation/aggregation)
>> record id -- for combining a single event record that may have been
>> fragmented across multiple event "messages"
>> msg id -- the identifier that corresponds to the event type/message
>> (e.g., 528
> [MS Windows XP], 106001 [Cisco PIX])
>>
>> It may be the case that the event id can also be used as the record
>> id, though I think of the record id as being more of an event
>> transport/protocol issue
>>
>>
>> William Heinbockel
>> The MITRE Corporation
>>
>>
>>>-----Original Message-----
>>>From: Peter Czanik [mailto:[hidden email]]
>>>Sent: Wednesday, 24 November 2010 09:06
>>>To: cee-discussion-list CEE-Related Discussion
>>>Subject: [CEE-DISCUSSION-LIST] session id
>>>
>>>Hello,
>>>
>>>
>>>While working on patterns for syslog-ng's patterndb (
>>>http://www.balabit.com/wiki/patterndb ) we treated session id as a
>>>central element (originally for login/logout events, but could be
>>>applied to anything). It was often the same as the process
>>>identifier, but it could also be a mailq id, or anything suitable to
>>>identify opposite events, like login/logout or help to correlate
>>>events in logs. I could not find anything similar in the CEE field
>>>list. Could
> something like this introduced?
>>>
>>>Benefit: an easy to find field aiding log analysis.
>>>
>>>Side effect: the same values might appear in two different fields.
>>>
>>>
>>>Bye,
>>>
>>>
>>>--
>>>Peter Czanik (CzP) <[hidden email]> <mailto:[hidden email]>
>>>BalaBit IT Security / syslog-ng upstream
>>>http://czanik.blogs.balabit.com/
Reply | Threaded
Open this post in threaded view
|

Re: session id

Mark Poepping
I'm having a hard time with the way you're presenting correlation semantics.
Is there a use case documented somewhere that represents your understanding
of this (these?) correlation identifier(s)?  is that in your 'short paper'?
Is that coming (or posted someplace I can look)?

There are *lots* of examples where I'd want correlation up and down the
stack (through many layers), across 'peer' (and 'co-resident') systems, in
and across time.  I'm having a hard time mapping that to two fields...

Thanks.


>-----Original Message-----
>From: Eric Fitzgerald [mailto:[hidden email]]
>Sent: Monday, November 29, 2010 9:45 PM
>To: [hidden email]
>Subject: Re: [CEE-DISCUSSION-LIST] session id
>Importance: Low
>
>Hey David,
>
>In hindsight I realize that "horizontal" and "vertical" were pretty obscure
>terms.  If you imagine a picture with a vertically oriented OSI stack on
each
>side of a connection, then horizontal and vertical make more sense.
Basically
>"horizontal" means that I control two peer layers that I want to correlate
but
>not intervening components.  "Vertical" means I want to correlate with logs
>from a peer layer that I don't control.
>
>I believe that either 2 or 3 is the magic number of required correlation
>fields.  I can conceive of edge cases where you need two vertical
correlators
>("up" and "down") but I have no example use case to support that
conjecture.  A
>transaction ID typically trumps a horizontal correlator, or at least a
>horizontal correlator is a specific limited case of a transaction ID.
>
>More scenarios:
>- Correlation with a dependent component or protocol, e.g. correlating
>application layer events with network layer events on the same device
>- Generalized session - many independent operations are correlated with a
>single longer-lived piece of state for another component on the system.
This
>is kind of a mix between your "database transaction" and "remote session"
>cases.  I'm specifically thinking of logon sessions in Windows, which is
also
>close to Peter's original use case.
>
>I wrote a short paper on correlation scenarios earlier this year and posted
it

>to the sharepoint.  I'll try to dig that up.
>
>Eric
>
>-----Original Message-----
>From: David Corlette [mailto:[hidden email]]
>Sent: Monday, November 29, 2010 6:31 PM
>To: [hidden email]
>Subject: Re: [CEE-DISCUSSION-LIST] session id
>
>Hi Eric,
>
>I like your basic approach, although I find your "horizontal" and
"vertical"
>labels a bit obscure.
>
>Just as you describe, I have been imagining using something like the
>originating host:port of an SSH connection as the "transaction ID"
(vertical ID
>in your terminology) for both sides of the connection. As you mention, that
>means that neither side has to add a new method to their APIs or anything.
>
>From what I can tell, there are N scenarios where some form of correlation
ID
>is required, but many of the cases can collapse into just a couple required
>fields. I think at least two are necessary, so you can for example track a
>workflow process ID plus various subgroups of steps, but this is more of a
gut
>instinct than anything I've actually spent a lot of time validating.
>
>Perhaps we can come up with as full a set of correlation scenarios, and
then
>talk about the minimum number of such fields?
>
>Examples:
>- Long-running DB transaction
>- Bunch of related changes, like changing many attributes on a set of
objects
>in a single operation
>- Workflow and multi-step process IDs
>- Remote procedure calls and remote sessions
>- ...
>
>P.S. I've cross-posted to the sec-das (xdas) list, as the discussion will
be
>germane over there as well.
>
>>>> On 29.11.2010 at 19:52, in message
><[hidden email]
.ntd

>e
>.microsoft.com>, Eric Fitzgerald <[hidden email]> wrote:
>> Hey David,
>>
>> Let me expand a little further.
>>
>> ID's are used to relate events to each other.
>>
>> It seems to me that "Transaction ID" as you describe is just a special
>> case of "grouping ID" from that perspective.
>>
>> But I see two other special cases, which I'll call "horizontal peer
>> ID" and "vertical peer ID".
>>
>> It's sometimes the case that you want to trace a complex activity
>> through several (or many) processing components, each of which
>> generate logs.  The ideal in this situation is the "transaction ID"
>> concept- where the components all share a unique ID with each other
>> and that each component includes this ID in all events related to the
>activity.
>>
>> However in my experience it's more often the case that different
>> components in the system have different developers, and that one or
>> more developers is unwilling or unable to make the necessary
>> protocol/messaging/interface changes or the logging changes needed to
capture
>this end-to-end ID.
>>
>> In that case, you have two kinds of scenarios to deal with.
>> 1. Horizontal peer correlation - my component in the stack on this
>> side of the conversation talks to another component I own on the other
>> side of the conversation.  However I don't control the
>> interfaces/protocols in components between my two peers.  So I put in
>> an ID that can be used to correlate horizontally between my two
components.
>>
>> 2. Vertical peer correlation - Same situation, but how do I correlate
>> my events with the events of other intervening components?  By taking
>> a property of the common interface that we share, and using that as an ID
in
>my events.
>> I then only need to convince the developer of the other component to
>> also include the ID, which is an easier task for them because they
>> already have it by nature of our interface.  For instance, I could use
>> a pointer value or handle ID to identify my "session" with a lower
>> level component in the application stack.  As long as their event
>> records the same value, then my event can be positively correlated with
their

>event.
>>
>> So my taxonomy would be:
>>
>> Event grouping correlators
>>   * Transaction IDs
>>   * Horizontal peer IDs
>>   * Vertical peer IDs
>>
>> Thanks,
>> Eric
>>
>> -----Original Message-----
>> From: David Corlette [mailto:[hidden email]]
>> Sent: Monday, November 29, 2010 12:59 PM
>> To: [hidden email]
>> Subject: Re: [CEE-DISCUSSION-LIST] session id
>>
>> Hi Bill,
>>
>> Within XDAS v2 we are currently proposing (although this has yet to be
>> discussed in great detail) the following:
>>
>> "Grouping ID" - an identifier used to group together multiple events
>> that are related to each other, like multiple events from a single
>> session, or multiple modifications to a single row/object/file
>> triggered by a single user action.
>>
>> "Transaction ID" - an identifier used to link events together into a
>> single transaction. This is different from the Grouping ID because a
>> transaction structure implies some degree of structure, like a
>> database query, start session/end session semantics, or caller/callee
>semantics.
>>
>> Think of the "Transaction ID" as the parentheses around a set, and the
>> "Grouping ID" as tags that relate the individual elements within the set.
>>
>> You also mention:
>> event id
>> Which I'd call:
>> "Event ID" - a unique identifier for the specific event.
>> Note that this gets really tricky - who assigns this ID? How is
>> uniqueness guaranteed?
>> If you have multiple processes writing to syslog, do the processes
>> create the ID? Or does syslogd/-ng?
>> One possible structure would be to have e.g. syslog-ng attach an Event
>> ID to the record just before it gets sent to a remote consumer. In
>> that case, having the ID increment by one each time would actually
>> allow you to detect dropped or injected (spoofed) events a little more
>> easily. Or you could do this on a source process/thread basis, or
something.

>> What would be really slick would be to define a standard where event
>> producers presented a raw view of the event if a particular RESTful
>> URL was visited, with the event ID as the key.
>>
>> And finally, your 'msg id' we've explicitly called:
>> "Vendor Event Code" - because this field has no real meaning in the
>> context of the standard, it's not unique across all products, it's
>> only an artifact of the vendor's understanding of what the event means
>> above and beyond the canonicalized standard.
>>
>>
>>>>> On 29.11.2010 at 11:02, in message
>> <[hidden email]>,
>> "Heinbockel, Bill" <[hidden email]> wrote:
>>> There are several ids that we may need to track:
>>>
>>> session or audit id -- for events occurring within the same user
>>> session event id -- for distinguishing different events (also useful
>>> for references in
>>> correlation/aggregation)
>>> record id -- for combining a single event record that may have been
>>> fragmented across multiple event "messages"
>>> msg id -- the identifier that corresponds to the event type/message
>>> (e.g., 528
>> [MS Windows XP], 106001 [Cisco PIX])
>>>
>>> It may be the case that the event id can also be used as the record
>>> id, though I think of the record id as being more of an event
>>> transport/protocol issue
>>>
>>>
>>> William Heinbockel
>>> The MITRE Corporation
>>>
>>>
>>>>-----Original Message-----
>>>>From: Peter Czanik [mailto:[hidden email]]
>>>>Sent: Wednesday, 24 November 2010 09:06
>>>>To: cee-discussion-list CEE-Related Discussion
>>>>Subject: [CEE-DISCUSSION-LIST] session id
>>>>
>>>>Hello,
>>>>
>>>>
>>>>While working on patterns for syslog-ng's patterndb (
>>>>http://www.balabit.com/wiki/patterndb ) we treated session id as a
>>>>central element (originally for login/logout events, but could be
>>>>applied to anything). It was often the same as the process
>>>>identifier, but it could also be a mailq id, or anything suitable to
>>>>identify opposite events, like login/logout or help to correlate
>>>>events in logs. I could not find anything similar in the CEE field
>>>>list. Could
>> something like this introduced?
>>>>
>>>>Benefit: an easy to find field aiding log analysis.
>>>>
>>>>Side effect: the same values might appear in two different fields.
>>>>
>>>>
>>>>Bye,
>>>>
>>>>
>>>>--
>>>>Peter Czanik (CzP) <[hidden email]> <mailto:[hidden email]>
>>>>BalaBit IT Security / syslog-ng upstream
>>>>http://czanik.blogs.balabit.com/
Reply | Threaded
Open this post in threaded view
|

Re: session id

Eric Fitzgerald-2
Hey Mark,

Our use case document doesn't go into this level of detail on correlation, so it is not much help.  My correlation overview document doesn't go into detail on this area yet but I will update it and find a way to share it.

The reason that I state that you need two (or perhaps 3) fields maximum for dedicated correlation IDs (that is, fields which are purely for correlation and don't have any meaning other than correlation) is as follows:

Consider the case where logging is being done by a component which is part of a stack of components on a single device, and which is communicating with a peer component on another device.  In this simple diagram, consider that component B is communicating with component E, via components C and D.

A     F
|       |
B       E
|       |
C ----- D


By "vertical" correlators, I mean correlation IDs that are shared only between two components in the same stack; e.g. a property of the interfaces between the components and not part of a network protocol.  These would most commonly just be created as needed, but might be gathered opportunistically as a characteristic of the interface between components: for example, a handle ID or pointer, or other token incidental to inter-component communication.  So we might have vertical correlators between A-B, B-C, D-E, and E-F.

By "horizontal" correlators, I mean correlation IDs that are shared between peer components in their messages, i.e. specific to the protocol shared by those two components and independent of lower layer protocols.  In this case, horizontal correlators might be A-F, B-E, or C-D.  Unless the protocol had pre-determined the need for such a correlator, it's likely that this kind of correlator would have to be invented, or opportunistically derived from some aspect of the protocol. As an aside, in Windows we once used a hash of a piece of ciphertext shared between two components as such a correlator- since we had the same ciphertext at both endpoints, the hash computed to the same value at both endpoints and we ended up not having to change the protocol.

So component B, for full correlation with component E, would need at least two of these correlators: a vertical correlator B-C and a horizontal correlator B-E (note that for full correlation you would examine the logs of B, C, D, and E, implying that there's a horizontal correlator between C-D and a vertical correlator between D-E).

The reason that I stated that you probably needed only two correlation fields is that chaining capability.  As a result, component B only needs B-C and B-E correlation IDs.  I hedged and said that perhaps 3 were needed, because there might be scenarios for component A where you need an A-B correlator, which B would have to also log.

It incidentally might be the case that B, C, D, and E all share a common correlator such as a transaction ID.  This actually either does not change, or even reduces, the number of correlation fields needed.

There are scenarios where there is are fields which are used for correlation but which convey information about the state of the system that is independent of correlation usage.  For example, timestamps, IP addresses, RPC session identifiers, Windows logon IDs, etc.  I view those fields as different in character, and you might need an arbitrary number of them in any given event record.  The correlation IDs that I discuss above are "pure" correlation fields, e.g. invented unique IDs solely for log record correlation purposes and conveying no other meaning.

I hope this clarifies my thinking.

Best regards,
Eric

________________________________________
From: Mark Poepping [[hidden email]]
Sent: Monday, November 29, 2010 8:28 PM
To: Eric Fitzgerald; [hidden email]
Subject: RE: [CEE-DISCUSSION-LIST] session id

I'm having a hard time with the way you're presenting correlation semantics.
Is there a use case documented somewhere that represents your understanding
of this (these?) correlation identifier(s)?  is that in your 'short paper'?
Is that coming (or posted someplace I can look)?

There are *lots* of examples where I'd want correlation up and down the
stack (through many layers), across 'peer' (and 'co-resident') systems, in
and across time.  I'm having a hard time mapping that to two fields...

Thanks.


>-----Original Message-----
>From: Eric Fitzgerald [mailto:[hidden email]]
>Sent: Monday, November 29, 2010 9:45 PM
>To: [hidden email]
>Subject: Re: [CEE-DISCUSSION-LIST] session id
>Importance: Low
>
>Hey David,
>
>In hindsight I realize that "horizontal" and "vertical" were pretty obscure
>terms.  If you imagine a picture with a vertically oriented OSI stack on
each
>side of a connection, then horizontal and vertical make more sense.
Basically
>"horizontal" means that I control two peer layers that I want to correlate
but
>not intervening components.  "Vertical" means I want to correlate with logs
>from a peer layer that I don't control.
>
>I believe that either 2 or 3 is the magic number of required correlation
>fields.  I can conceive of edge cases where you need two vertical
correlators
>("up" and "down") but I have no example use case to support that
conjecture.  A
>transaction ID typically trumps a horizontal correlator, or at least a
>horizontal correlator is a specific limited case of a transaction ID.
>
>More scenarios:
>- Correlation with a dependent component or protocol, e.g. correlating
>application layer events with network layer events on the same device
>- Generalized session - many independent operations are correlated with a
>single longer-lived piece of state for another component on the system.
This
>is kind of a mix between your "database transaction" and "remote session"
>cases.  I'm specifically thinking of logon sessions in Windows, which is
also
>close to Peter's original use case.
>
>I wrote a short paper on correlation scenarios earlier this year and posted
it

>to the sharepoint.  I'll try to dig that up.
>
>Eric
>
>-----Original Message-----
>From: David Corlette [mailto:[hidden email]]
>Sent: Monday, November 29, 2010 6:31 PM
>To: [hidden email]
>Subject: Re: [CEE-DISCUSSION-LIST] session id
>
>Hi Eric,
>
>I like your basic approach, although I find your "horizontal" and
"vertical"
>labels a bit obscure.
>
>Just as you describe, I have been imagining using something like the
>originating host:port of an SSH connection as the "transaction ID"
(vertical ID
>in your terminology) for both sides of the connection. As you mention, that
>means that neither side has to add a new method to their APIs or anything.
>
>From what I can tell, there are N scenarios where some form of correlation
ID
>is required, but many of the cases can collapse into just a couple required
>fields. I think at least two are necessary, so you can for example track a
>workflow process ID plus various subgroups of steps, but this is more of a
gut
>instinct than anything I've actually spent a lot of time validating.
>
>Perhaps we can come up with as full a set of correlation scenarios, and
then
>talk about the minimum number of such fields?
>
>Examples:
>- Long-running DB transaction
>- Bunch of related changes, like changing many attributes on a set of
objects
>in a single operation
>- Workflow and multi-step process IDs
>- Remote procedure calls and remote sessions
>- ...
>
>P.S. I've cross-posted to the sec-das (xdas) list, as the discussion will
be
>germane over there as well.
>
>>>> On 29.11.2010 at 19:52, in message
><[hidden email]
.ntd

>e
>.microsoft.com>, Eric Fitzgerald <[hidden email]> wrote:
>> Hey David,
>>
>> Let me expand a little further.
>>
>> ID's are used to relate events to each other.
>>
>> It seems to me that "Transaction ID" as you describe is just a special
>> case of "grouping ID" from that perspective.
>>
>> But I see two other special cases, which I'll call "horizontal peer
>> ID" and "vertical peer ID".
>>
>> It's sometimes the case that you want to trace a complex activity
>> through several (or many) processing components, each of which
>> generate logs.  The ideal in this situation is the "transaction ID"
>> concept- where the components all share a unique ID with each other
>> and that each component includes this ID in all events related to the
>activity.
>>
>> However in my experience it's more often the case that different
>> components in the system have different developers, and that one or
>> more developers is unwilling or unable to make the necessary
>> protocol/messaging/interface changes or the logging changes needed to
capture
>this end-to-end ID.
>>
>> In that case, you have two kinds of scenarios to deal with.
>> 1. Horizontal peer correlation - my component in the stack on this
>> side of the conversation talks to another component I own on the other
>> side of the conversation.  However I don't control the
>> interfaces/protocols in components between my two peers.  So I put in
>> an ID that can be used to correlate horizontally between my two
components.
>>
>> 2. Vertical peer correlation - Same situation, but how do I correlate
>> my events with the events of other intervening components?  By taking
>> a property of the common interface that we share, and using that as an ID
in
>my events.
>> I then only need to convince the developer of the other component to
>> also include the ID, which is an easier task for them because they
>> already have it by nature of our interface.  For instance, I could use
>> a pointer value or handle ID to identify my "session" with a lower
>> level component in the application stack.  As long as their event
>> records the same value, then my event can be positively correlated with
their

>event.
>>
>> So my taxonomy would be:
>>
>> Event grouping correlators
>>   * Transaction IDs
>>   * Horizontal peer IDs
>>   * Vertical peer IDs
>>
>> Thanks,
>> Eric
>>
>> -----Original Message-----
>> From: David Corlette [mailto:[hidden email]]
>> Sent: Monday, November 29, 2010 12:59 PM
>> To: [hidden email]
>> Subject: Re: [CEE-DISCUSSION-LIST] session id
>>
>> Hi Bill,
>>
>> Within XDAS v2 we are currently proposing (although this has yet to be
>> discussed in great detail) the following:
>>
>> "Grouping ID" - an identifier used to group together multiple events
>> that are related to each other, like multiple events from a single
>> session, or multiple modifications to a single row/object/file
>> triggered by a single user action.
>>
>> "Transaction ID" - an identifier used to link events together into a
>> single transaction. This is different from the Grouping ID because a
>> transaction structure implies some degree of structure, like a
>> database query, start session/end session semantics, or caller/callee
>semantics.
>>
>> Think of the "Transaction ID" as the parentheses around a set, and the
>> "Grouping ID" as tags that relate the individual elements within the set.
>>
>> You also mention:
>> event id
>> Which I'd call:
>> "Event ID" - a unique identifier for the specific event.
>> Note that this gets really tricky - who assigns this ID? How is
>> uniqueness guaranteed?
>> If you have multiple processes writing to syslog, do the processes
>> create the ID? Or does syslogd/-ng?
>> One possible structure would be to have e.g. syslog-ng attach an Event
>> ID to the record just before it gets sent to a remote consumer. In
>> that case, having the ID increment by one each time would actually
>> allow you to detect dropped or injected (spoofed) events a little more
>> easily. Or you could do this on a source process/thread basis, or
something.

>> What would be really slick would be to define a standard where event
>> producers presented a raw view of the event if a particular RESTful
>> URL was visited, with the event ID as the key.
>>
>> And finally, your 'msg id' we've explicitly called:
>> "Vendor Event Code" - because this field has no real meaning in the
>> context of the standard, it's not unique across all products, it's
>> only an artifact of the vendor's understanding of what the event means
>> above and beyond the canonicalized standard.
>>
>>
>>>>> On 29.11.2010 at 11:02, in message
>> <[hidden email]>,
>> "Heinbockel, Bill" <[hidden email]> wrote:
>>> There are several ids that we may need to track:
>>>
>>> session or audit id -- for events occurring within the same user
>>> session event id -- for distinguishing different events (also useful
>>> for references in
>>> correlation/aggregation)
>>> record id -- for combining a single event record that may have been
>>> fragmented across multiple event "messages"
>>> msg id -- the identifier that corresponds to the event type/message
>>> (e.g., 528
>> [MS Windows XP], 106001 [Cisco PIX])
>>>
>>> It may be the case that the event id can also be used as the record
>>> id, though I think of the record id as being more of an event
>>> transport/protocol issue
>>>
>>>
>>> William Heinbockel
>>> The MITRE Corporation
>>>
>>>
>>>>-----Original Message-----
>>>>From: Peter Czanik [mailto:[hidden email]]
>>>>Sent: Wednesday, 24 November 2010 09:06
>>>>To: cee-discussion-list CEE-Related Discussion
>>>>Subject: [CEE-DISCUSSION-LIST] session id
>>>>
>>>>Hello,
>>>>
>>>>
>>>>While working on patterns for syslog-ng's patterndb (
>>>>http://www.balabit.com/wiki/patterndb ) we treated session id as a
>>>>central element (originally for login/logout events, but could be
>>>>applied to anything). It was often the same as the process
>>>>identifier, but it could also be a mailq id, or anything suitable to
>>>>identify opposite events, like login/logout or help to correlate
>>>>events in logs. I could not find anything similar in the CEE field
>>>>list. Could
>> something like this introduced?
>>>>
>>>>Benefit: an easy to find field aiding log analysis.
>>>>
>>>>Side effect: the same values might appear in two different fields.
>>>>
>>>>
>>>>Bye,
>>>>
>>>>
>>>>--
>>>>Peter Czanik (CzP) <[hidden email]> <mailto:[hidden email]>
>>>>BalaBit IT Security / syslog-ng upstream
>>>>http://czanik.blogs.balabit.com/