Quantcast

Unique Event ID (RecordId)

classic Classic list List threaded Threaded
56 messages Options
123
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Unique Event ID (RecordId)

Wunder, John A.

I wanted to restart this discussion and move it to its own thread. For reference, this is the discussion about whether CEE should have a field where producers can (or must) put a unique identifier for individual events.

 

To restart some of the topics:

 

1.       Optional vs. required. People seemed to be leaning towards making the field optional to ease the implementation burden for event producers. Does anyone disagree with this? The main concern of course is that this leads to less compatibility among producers so that consumers can’t rely on consistency. In other words, is the field even still useful if consumers can’t count on it being there?

2.       Do we need to specify a format, or can we just give a field a title and tell producers to stick something unique in it? Upsides of not specifying a particular format is the ease of adoption, downside is that consumers would have to expect basically anything in that field and some producers might not succeed at making it truly unique.

3.       If we do specify a format, what is that format?

a.       UUID?

b.      Hash

c.       Other?

 

My personal opinion is that for ease of implementation and simplicity we have an optional field that, if populated, MUST be populated with a UUID.

 

In particular it would be good to hear from event producers on this. Does anyone from the lumberjack team want to weigh in? Or any other people developing software that will produce CEE events?

 

Lastly, what do people think about scheduling a chat on IRC about topics like this? E-mail is a pretty disjointed way of doing this and a telecom is tough to organize, but maybe a ½ chat on IRC would let people tune in but continue their regular work?

 

Thanks,

John

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Unique Event ID (RecordId)

dpal
On 10/03/2012 02:55 PM, Wunder, John A. wrote:

I wanted to restart this discussion and move it to its own thread. For reference, this is the discussion about whether CEE should have a field where producers can (or must) put a unique identifier for individual events.

 

To restart some of the topics:

 

1.       Optional vs. required. People seemed to be leaning towards making the field optional to ease the implementation burden for event producers. Does anyone disagree with this? The main concern of course is that this leads to less compatibility among producers so that consumers can’t rely on consistency. In other words, is the field even still useful if consumers can’t count on it being there?

2.       Do we need to specify a format, or can we just give a field a title and tell producers to stick something unique in it? Upsides of not specifying a particular format is the ease of adoption, downside is that consumers would have to expect basically anything in that field and some producers might not succeed at making it truly unique.

3.       If we do specify a format, what is that format?

a.       UUID?

b.      Hash

c.       Other?

 

My personal opinion is that for ease of implementation and simplicity we have an optional field that, if populated, MUST be populated with a UUID.

 

In particular it would be good to hear from event producers on this. Does anyone from the lumberjack team want to weigh in? Or any other people developing software that will produce CEE events?

 

Lastly, what do people think about scheduling a chat on IRC about topics like this? E-mail is a pretty disjointed way of doing this and a telecom is tough to organize, but maybe a ½ chat on IRC would let people tune in but continue their regular work?

 

Thanks,

John


IMO it would be nice to augment it with optional vendor ID (registered uuid or string).
This way vendor ID can be used to lookup some public repo where vendors will optionally publish XML schema for the event vendor creates. This schema in turn would be useful for processing the event on the client side.

2c.

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Unique Event ID (RecordId)

Wunder, John A.

 

Good point, we actually already have something that does that. The “profile” field in CEE 1.0-beta1 is a reference to the “profile” (schema, really) that the event complies with. The idea being that a) vendors could have multiple schemas and b) more importantly, vendors should share profiles whenever possible.

 

John

 


IMO it would be nice to augment it with optional vendor ID (registered uuid or string).
This way vendor ID can be used to lookup some public repo where vendors will optionally publish XML schema for the event vendor creates. This schema in turn would be useful for processing the event on the client side.

2c.


-- 
Thank you,
Dmitri Pal
 
Sr. Engineering Manager for IdM portfolio
Red Hat Inc.
 
 
-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
 
 
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Unique Event ID (RecordId)

dpal
On 10/03/2012 03:17 PM, Wunder, John A. wrote:

 

Good point, we actually already have something that does that. The “profile” field in CEE 1.0-beta1 is a reference to the “profile” (schema, really) that the event complies with. The idea being that a) vendors could have multiple schemas and b) more importantly, vendors should share profiles whenever possible.

 


OK, great, my memory of the exact schema is a bit rusty. I remembered that there was something but did not recall what the name was.
I might make sense though to discuss these two fields together as they do not make sense one without another.

John

 


IMO it would be nice to augment it with optional vendor ID (registered uuid or string).
This way vendor ID can be used to lookup some public repo where vendors will optionally publish XML schema for the event vendor creates. This schema in turn would be useful for processing the event on the client side.

2c.



 


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Unique Event ID (RecordId)

Jake Evans
In reply to this post by Wunder, John A.

Here are my answers/thoughts on this:

1.       Optional  seems to be the way to go.  Although I’d like to say “Mandatory,” I think some software producers will back off because of the implied level of additional overhead in maintaining collections of unique events will bring.

2.       For people who do decide to implement Unique Event ID, I do think a simple set of guidelines by which vendors name their events should be followed.  Perhaps something like: UNIQUE_VENDOR_STRING:PRODUCT:VERSION:EVENT_ID.  UNIQUE_VENDOR_STRINGs could be placed on a publically available site (CEE site) where new vendors could verify the uniqueness of the string they’d like to use.  From there, it would be the responsibility of vendors to make sure PRODUCT, VERSION and EVENT_ID string combinations remain unique.

3.       UUID

 

Jake

 

Jake Evans, GPEN, GCIH, GWAPT, GCIA, CISSP, CISA, CRISC, CPISA, CPISM | Sr. Security and Compliance Analyst

 

Tripwire

101 SW Main St., Ste. 1500
Portland, OR 97204  

Direct: 503.276.7658

Main: 503.276.7500

 

TRIPWIRE | TAKE CONTROL.
www.tripwire.com

 

From: Wunder, John A. [mailto:[hidden email]]
Sent: Wednesday, October 03, 2012 11:56 AM
To: [hidden email]
Subject: [CEE-DISCUSSION-LIST] Unique Event ID (RecordId)

 

I wanted to restart this discussion and move it to its own thread. For reference, this is the discussion about whether CEE should have a field where producers can (or must) put a unique identifier for individual events.

 

To restart some of the topics:

 

1.       Optional vs. required. People seemed to be leaning towards making the field optional to ease the implementation burden for event producers. Does anyone disagree with this? The main concern of course is that this leads to less compatibility among producers so that consumers can’t rely on consistency. In other words, is the field even still useful if consumers can’t count on it being there?

2.       Do we need to specify a format, or can we just give a field a title and tell producers to stick something unique in it? Upsides of not specifying a particular format is the ease of adoption, downside is that consumers would have to expect basically anything in that field and some producers might not succeed at making it truly unique.

3.       If we do specify a format, what is that format?

a.       UUID?

b.      Hash

c.       Other?

 

My personal opinion is that for ease of implementation and simplicity we have an optional field that, if populated, MUST be populated with a UUID.

 

In particular it would be good to hear from event producers on this. Does anyone from the lumberjack team want to weigh in? Or any other people developing software that will produce CEE events?

 

Lastly, what do people think about scheduling a chat on IRC about topics like this? E-mail is a pretty disjointed way of doing this and a telecom is tough to organize, but maybe a ½ chat on IRC would let people tune in but continue their regular work?

 

Thanks,

John

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Unique Event ID (RecordId)

zrlram
In reply to this post by Wunder, John A.
I like optional! Just look at existing sources. Hardly any have an ID already.

Format: why specify that? GUID, etc. have some semantic assigned, like needs to be unique with regards to ... Say that vendor and product tuple, which allows for good flexibility. The implementation of an incrementing ID is often very efficient (see a number of products doing this: e.g. ArcSight)

  Raffy

Sent from my iTelephone

On Oct 3, 2012, at 11:55 AM, "Wunder, John A." <[hidden email]> wrote:

I wanted to restart this discussion and move it to its own thread. For reference, this is the discussion about whether CEE should have a field where producers can (or must) put a unique identifier for individual events.

 

To restart some of the topics:

 

1.       Optional vs. required. People seemed to be leaning towards making the field optional to ease the implementation burden for event producers. Does anyone disagree with this? The main concern of course is that this leads to less compatibility among producers so that consumers can’t rely on consistency. In other words, is the field even still useful if consumers can’t count on it being there?

2.       Do we need to specify a format, or can we just give a field a title and tell producers to stick something unique in it? Upsides of not specifying a particular format is the ease of adoption, downside is that consumers would have to expect basically anything in that field and some producers might not succeed at making it truly unique.

3.       If we do specify a format, what is that format?

a.       UUID?

b.      Hash

c.       Other?

 

My personal opinion is that for ease of implementation and simplicity we have an optional field that, if populated, MUST be populated with a UUID.

 

In particular it would be good to hear from event producers on this. Does anyone from the lumberjack team want to weigh in? Or any other people developing software that will produce CEE events?

 

Lastly, what do people think about scheduling a chat on IRC about topics like this? E-mail is a pretty disjointed way of doing this and a telecom is tough to organize, but maybe a ½ chat on IRC would let people tune in but continue their regular work?

 

Thanks,

John

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Unique Event ID (RecordId)

zrlram
In reply to this post by Jake Evans
I am realizing we might e talking about different things... A unique ID per event instance vs. an iD identifying the type of event, like snort SIDs or windows "security:528" type of ID. Which one are we talking a out? I was referring to the former...

  Raffy

Sent from my iTelephone

On Oct 3, 2012, at 12:26 PM, Jake Evans <[hidden email]> wrote:

Here are my answers/thoughts on this:

1.       Optional  seems to be the way to go.  Although I’d like to say “Mandatory,” I think some software producers will back off because of the implied level of additional overhead in maintaining collections of unique events will bring.

2.       For people who do decide to implement Unique Event ID, I do think a simple set of guidelines by which vendors name their events should be followed.  Perhaps something like: UNIQUE_VENDOR_STRING:PRODUCT:VERSION:EVENT_ID.  UNIQUE_VENDOR_STRINGs could be placed on a publically available site (CEE site) where new vendors could verify the uniqueness of the string they’d like to use.  From there, it would be the responsibility of vendors to make sure PRODUCT, VERSION and EVENT_ID string combinations remain unique.

3.       UUID

 

Jake

 

Jake Evans, GPEN, GCIH, GWAPT, GCIA, CISSP, CISA, CRISC, CPISA, CPISM | Sr. Security and Compliance Analyst

 

Tripwire

101 SW Main St., Ste. 1500
Portland, OR 97204  

Direct: 503.276.7658

Main: 503.276.7500

 

TRIPWIRE | TAKE CONTROL.
www.tripwire.com

 

From: Wunder, John A. [[hidden email]]
Sent: Wednesday, October 03, 2012 11:56 AM
To: [hidden email]
Subject: [CEE-DISCUSSION-LIST] Unique Event ID (RecordId)

 

I wanted to restart this discussion and move it to its own thread. For reference, this is the discussion about whether CEE should have a field where producers can (or must) put a unique identifier for individual events.

 

To restart some of the topics:

 

1.       Optional vs. required. People seemed to be leaning towards making the field optional to ease the implementation burden for event producers. Does anyone disagree with this? The main concern of course is that this leads to less compatibility among producers so that consumers can’t rely on consistency. In other words, is the field even still useful if consumers can’t count on it being there?

2.       Do we need to specify a format, or can we just give a field a title and tell producers to stick something unique in it? Upsides of not specifying a particular format is the ease of adoption, downside is that consumers would have to expect basically anything in that field and some producers might not succeed at making it truly unique.

3.       If we do specify a format, what is that format?

a.       UUID?

b.      Hash

c.       Other?

 

My personal opinion is that for ease of implementation and simplicity we have an optional field that, if populated, MUST be populated with a UUID.

 

In particular it would be good to hear from event producers on this. Does anyone from the lumberjack team want to weigh in? Or any other people developing software that will produce CEE events?

 

Lastly, what do people think about scheduling a chat on IRC about topics like this? E-mail is a pretty disjointed way of doing this and a telecom is tough to organize, but maybe a ½ chat on IRC would let people tune in but continue their regular work?

 

Thanks,

John

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

FW: [CEE-DISCUSSION-LIST] Unique Event ID (RecordId)

Jake Evans

Just forwarding this conversation back into the list to include a simple example below.

 

Jake

 

Jake Evans, GPEN, GCIH, GWAPT, GCIA, CISSP, CISA, CRISC, CPISA, CPISM | Sr. Security and Compliance Analyst

 

Tripwire

101 SW Main St., Ste. 1500
Portland, OR 97204  

Direct: 503.276.7658

Main: 503.276.7500

 

TRIPWIRE | TAKE CONTROL.
www.tripwire.com

 

From: Raffael Marty [mailto:[hidden email]]
Sent: Wednesday, October 03, 2012 2:55 PM
To: Jake Evans
Subject: Re: [CEE-DISCUSSION-LIST] Unique Event ID (RecordId)

 

+1

Sent from my iTelephone


On Oct 3, 2012, at 1:56 PM, Jake Evans <[hidden email]> wrote:

I was thinking UUID format would look something like this:

 

SourceFire:Snort:2.9:75647

Vendor:Product:Version:EventID

 

So I was referring to the latter.  Additionally, a unique instance of an event type (what you’re talking about) could be assigned an incremental value as well, sort of like a ticket number.

 

Jake

 

Jake Evans, GPEN, GCIH, GWAPT, GCIA, CISSP, CISA, CRISC, CPISA, CPISM | Sr. Security and Compliance Analyst

 

Tripwire

101 SW Main St., Ste. 1500
Portland, OR 97204  

Direct: 503.276.7658

Main: 503.276.7500

 

TRIPWIRE | TAKE CONTROL.
www.tripwire.com

 

From: Raffael Marty [[hidden email]]
Sent: Wednesday, October 03, 2012 1:37 PM
To: Jake Evans
Cc: <[hidden email]>
Subject: Re: [CEE-DISCUSSION-LIST] Unique Event ID (RecordId)

 

I am realizing we might e talking about different things... A unique ID per event instance vs. an iD identifying the type of event, like snort SIDs or windows "security:528" type of ID. Which one are we talking a out? I was referring to the former...

 

  Raffy

Sent from my iTelephone


On Oct 3, 2012, at 12:26 PM, Jake Evans <[hidden email]> wrote:

Here are my answers/thoughts on this:

1.       Optional  seems to be the way to go.  Although I’d like to say “Mandatory,” I think some software producers will back off because of the implied level of additional overhead in maintaining collections of unique events will bring.

2.       For people who do decide to implement Unique Event ID, I do think a simple set of guidelines by which vendors name their events should be followed.  Perhaps something like: UNIQUE_VENDOR_STRING:PRODUCT:VERSION:EVENT_ID.  UNIQUE_VENDOR_STRINGs could be placed on a publically available site (CEE site) where new vendors could verify the uniqueness of the string they’d like to use.  From there, it would be the responsibility of vendors to make sure PRODUCT, VERSION and EVENT_ID string combinations remain unique.

3.       UUID

 

Jake

 

Jake Evans, GPEN, GCIH, GWAPT, GCIA, CISSP, CISA, CRISC, CPISA, CPISM | Sr. Security and Compliance Analyst

 

Tripwire

101 SW Main St., Ste. 1500
Portland, OR 97204  

Direct: 503.276.7658

Main: 503.276.7500

 

TRIPWIRE | TAKE CONTROL.
www.tripwire.com

 

From: Wunder, John A. [[hidden email]]
Sent: Wednesday, October 03, 2012 11:56 AM
To: [hidden email]
Subject: [CEE-DISCUSSION-LIST] Unique Event ID (RecordId)

 

I wanted to restart this discussion and move it to its own thread. For reference, this is the discussion about whether CEE should have a field where producers can (or must) put a unique identifier for individual events.

 

To restart some of the topics:

 

1.       Optional vs. required. People seemed to be leaning towards making the field optional to ease the implementation burden for event producers. Does anyone disagree with this? The main concern of course is that this leads to less compatibility among producers so that consumers can’t rely on consistency. In other words, is the field even still useful if consumers can’t count on it being there?

2.       Do we need to specify a format, or can we just give a field a title and tell producers to stick something unique in it? Upsides of not specifying a particular format is the ease of adoption, downside is that consumers would have to expect basically anything in that field and some producers might not succeed at making it truly unique.

3.       If we do specify a format, what is that format?

a.       UUID?

b.      Hash

c.       Other?

 

My personal opinion is that for ease of implementation and simplicity we have an optional field that, if populated, MUST be populated with a UUID.

 

In particular it would be good to hear from event producers on this. Does anyone from the lumberjack team want to weigh in? Or any other people developing software that will produce CEE events?

 

Lastly, what do people think about scheduling a chat on IRC about topics like this? E-mail is a pretty disjointed way of doing this and a telecom is tough to organize, but maybe a ½ chat on IRC would let people tune in but continue their regular work?

 

Thanks,

John

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Unique Event ID (RecordId)

Wunder, John A.
In reply to this post by Wunder, John A.
Sorry, I was referring to a unique ID per event instance, not per event type.

Do you think there's value in having an optional ID?

>-----Original Message-----
>From: William Heinbockel [mailto:[hidden email]]
>Sent: Wednesday, October 03, 2012 5:44 PM
>To: Wunder, John A.
>Cc: cee-discussion-list CEE-Related Discussion
>Subject: Re: [CEE-DISCUSSION-LIST] Unique Event ID (RecordId)
>
>On Wed, 2012-10-03 at 14:55 -0400, Wunder, John A. wrote:
>> I wanted to restart this discussion and move it to its own thread. For
>> reference, this is the discussion about whether CEE should have a
>> field where producers can (or must) put a unique identifier for
>> individual events.
>>
>
>From the question and lead up it is not clear whether you are talking
>about the event ID (unique ID per event type) or record ID (unique ID
>per individual event record). Based on your subject line, I'm going to
>assume the latter.
>
>Requiring a record id is an awful idea:
>1. You won't be able to guarantee uniqueness for multi-threaded apps
>2. Waste of space; nobody uses them except to detect duplicate events
>3. Most event consumers assign their own instance ID
>
>>
>>
>> To restart some of the topics:
>>
>>
>>
>> 1.      Optional vs. required. People seemed to be leaning towards
>> making the field optional to ease the implementation burden for event
>> producers. Does anyone disagree with this? The main concern of course
>> is that this leads to less compatibility among producers so that
>> consumers can’t rely on consistency. In other words, is the field even
>> still useful if consumers can’t count on it being there?
>> 2.      Do we need to specify a format, or can we just give a field a
>> title and tell producers to stick something unique in it? Upsides of
>> not specifying a particular format is the ease of adoption, downside
>> is that consumers would have to expect basically anything in that
>> field and some producers might not succeed at making it truly unique.
>>
>> 3.      If we do specify a format, what is that format?
>>
>> a.      UUID?
>>
>> b.     Hash
>>
>> c.      Other?
>>
>>
>>
>> My personal opinion is that for ease of implementation and simplicity
>> we have an optional field that, if populated, MUST be populated with a
>> UUID.
>>
>>
>>
>> In particular it would be good to hear from event producers on this.
>> Does anyone from the lumberjack team want to weigh in? Or any other
>> people developing software that will produce CEE events?
>>
>>
>>
>> Lastly, what do people think about scheduling a chat on IRC about
>> topics like this? E-mail is a pretty disjointed way of doing this and
>> a telecom is tough to organize, but maybe a ½ chat on IRC would let
>> people tune in but continue their regular work?
>>
>>
>>
>> Thanks,
>>
>> John
>>
>>
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Unique Event ID (RecordId)

Wunder, John A.
In reply to this post by Jake Evans

Just to clear up terms UUID has a specific meaning in some circles; what you’re proposing here isn’t so much a UUID as a namespaced unique identifier.

 

I like the approach, just wanted to clarify the term in case other people are like me and think of something specific when they hear UUID.

 

Anyone object to what Jake proposed as an OPTIONAL identifier? CPE uses a similar namespace mechanism for its products, I’ll ask around to see if they have any lessons learned from that approach.

 

John

 

From: Jake Evans [mailto:[hidden email]]
Sent: Wednesday, October 03, 2012 6:04 PM
To: cee-discussion-list CEE-Related Discussion
Subject: [CEE-DISCUSSION-LIST] FW: [CEE-DISCUSSION-LIST] Unique Event ID (RecordId)

 

Just forwarding this conversation back into the list to include a simple example below.

 

Jake

 

Jake Evans, GPEN, GCIH, GWAPT, GCIA, CISSP, CISA, CRISC, CPISA, CPISM | Sr. Security and Compliance Analyst

 

Tripwire

101 SW Main St., Ste. 1500
Portland, OR 97204  

Direct: 503.276.7658

Main: 503.276.7500

 

TRIPWIRE | TAKE CONTROL.
www.tripwire.com

 

From: Raffael Marty [hidden email]
Sent: Wednesday, October 03, 2012 2:55 PM
To: Jake Evans
Subject: Re: [CEE-DISCUSSION-LIST] Unique Event ID (RecordId)

 

+1

Sent from my iTelephone


On Oct 3, 2012, at 1:56 PM, Jake Evans <[hidden email]> wrote:

I was thinking UUID format would look something like this:

 

SourceFire:Snort:2.9:75647

Vendor:Product:Version:EventID

 

So I was referring to the latter.  Additionally, a unique instance of an event type (what you’re talking about) could be assigned an incremental value as well, sort of like a ticket number.

 

Jake

 

Jake Evans, GPEN, GCIH, GWAPT, GCIA, CISSP, CISA, CRISC, CPISA, CPISM | Sr. Security and Compliance Analyst

 

Tripwire

101 SW Main St., Ste. 1500
Portland, OR 97204  

Direct: 503.276.7658

Main: 503.276.7500

 

TRIPWIRE | TAKE CONTROL.
www.tripwire.com

 

From: Raffael Marty [[hidden email]]
Sent: Wednesday, October 03, 2012 1:37 PM
To: Jake Evans
Cc: <[hidden email]>
Subject: Re: [CEE-DISCUSSION-LIST] Unique Event ID (RecordId)

 

I am realizing we might e talking about different things... A unique ID per event instance vs. an iD identifying the type of event, like snort SIDs or windows "security:528" type of ID. Which one are we talking a out? I was referring to the former...

 

  Raffy

Sent from my iTelephone


On Oct 3, 2012, at 12:26 PM, Jake Evans <[hidden email]> wrote:

Here are my answers/thoughts on this:

1.       Optional  seems to be the way to go.  Although I’d like to say “Mandatory,” I think some software producers will back off because of the implied level of additional overhead in maintaining collections of unique events will bring.

2.       For people who do decide to implement Unique Event ID, I do think a simple set of guidelines by which vendors name their events should be followed.  Perhaps something like: UNIQUE_VENDOR_STRING:PRODUCT:VERSION:EVENT_ID.  UNIQUE_VENDOR_STRINGs could be placed on a publically available site (CEE site) where new vendors could verify the uniqueness of the string they’d like to use.  From there, it would be the responsibility of vendors to make sure PRODUCT, VERSION and EVENT_ID string combinations remain unique.

3.       UUID

 

Jake

 

Jake Evans, GPEN, GCIH, GWAPT, GCIA, CISSP, CISA, CRISC, CPISA, CPISM | Sr. Security and Compliance Analyst

 

Tripwire

101 SW Main St., Ste. 1500
Portland, OR 97204  

Direct: 503.276.7658

Main: 503.276.7500

 

TRIPWIRE | TAKE CONTROL.
www.tripwire.com

 

From: Wunder, John A. [[hidden email]]
Sent: Wednesday, October 03, 2012 11:56 AM
To: [hidden email]
Subject: [CEE-DISCUSSION-LIST] Unique Event ID (RecordId)

 

I wanted to restart this discussion and move it to its own thread. For reference, this is the discussion about whether CEE should have a field where producers can (or must) put a unique identifier for individual events.

 

To restart some of the topics:

 

1.       Optional vs. required. People seemed to be leaning towards making the field optional to ease the implementation burden for event producers. Does anyone disagree with this? The main concern of course is that this leads to less compatibility among producers so that consumers can’t rely on consistency. In other words, is the field even still useful if consumers can’t count on it being there?

2.       Do we need to specify a format, or can we just give a field a title and tell producers to stick something unique in it? Upsides of not specifying a particular format is the ease of adoption, downside is that consumers would have to expect basically anything in that field and some producers might not succeed at making it truly unique.

3.       If we do specify a format, what is that format?

a.       UUID?

b.      Hash

c.       Other?

 

My personal opinion is that for ease of implementation and simplicity we have an optional field that, if populated, MUST be populated with a UUID.

 

In particular it would be good to hear from event producers on this. Does anyone from the lumberjack team want to weigh in? Or any other people developing software that will produce CEE events?

 

Lastly, what do people think about scheduling a chat on IRC about topics like this? E-mail is a pretty disjointed way of doing this and a telecom is tough to organize, but maybe a ½ chat on IRC would let people tune in but continue their regular work?

 

Thanks,

John

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Unique Event ID (RecordId)

Lange, Jeffrey K (GE Energy)

For what it’s worth, we have had a request from a customer to include a UUID in each event that we generate the format of the UUID was a follows:

 

PEN RES PN SN

Where:

PEN [3 bytes] – IANA private Enterprise Number

RES [2 bytes] – Reserved field (all zeros)

PN [4 bytes] – Product Number

SN [7 bytes] – Serial number

 

So in effect this is both a UUID, and a namespaced unique id

 

 

Jeff Lange
Lead Software Engineer
GE Energy Services
Digital Energy

GE imagination at work

 

 

From: Wunder, John A. [mailto:[hidden email]]
Sent: Thursday, October 04, 2012 7:50 AM
To: [hidden email]
Subject: Re: [CEE-DISCUSSION-LIST] Unique Event ID (RecordId)

 

Just to clear up terms UUID has a specific meaning in some circles; what you’re proposing here isn’t so much a UUID as a namespaced unique identifier.

 

I like the approach, just wanted to clarify the term in case other people are like me and think of something specific when they hear UUID.

 

Anyone object to what Jake proposed as an OPTIONAL identifier? CPE uses a similar namespace mechanism for its products, I’ll ask around to see if they have any lessons learned from that approach.

 

John

 

From: Jake Evans [hidden email]
Sent: Wednesday, October 03, 2012 6:04 PM
To: cee-discussion-list CEE-Related Discussion
Subject: [CEE-DISCUSSION-LIST] FW: [CEE-DISCUSSION-LIST] Unique Event ID (RecordId)

 

Just forwarding this conversation back into the list to include a simple example below.

 

Jake

 

Jake Evans, GPEN, GCIH, GWAPT, GCIA, CISSP, CISA, CRISC, CPISA, CPISM | Sr. Security and Compliance Analyst

 

Tripwire

101 SW Main St., Ste. 1500
Portland, OR 97204  

Direct: 503.276.7658

Main: 503.276.7500

 

TRIPWIRE | TAKE CONTROL.
www.tripwire.com

 

From: Raffael Marty [hidden email]
Sent: Wednesday, October 03, 2012 2:55 PM
To: Jake Evans
Subject: Re: [CEE-DISCUSSION-LIST] Unique Event ID (RecordId)

 

+1

Sent from my iTelephone


On Oct 3, 2012, at 1:56 PM, Jake Evans <[hidden email]> wrote:

I was thinking UUID format would look something like this:

 

SourceFire:Snort:2.9:75647

Vendor:Product:Version:EventID

 

So I was referring to the latter.  Additionally, a unique instance of an event type (what you’re talking about) could be assigned an incremental value as well, sort of like a ticket number.

 

Jake

 

Jake Evans, GPEN, GCIH, GWAPT, GCIA, CISSP, CISA, CRISC, CPISA, CPISM | Sr. Security and Compliance Analyst

 

Tripwire

101 SW Main St., Ste. 1500
Portland, OR 97204  

Direct: 503.276.7658

Main: 503.276.7500

 

TRIPWIRE | TAKE CONTROL.
www.tripwire.com

 

From: Raffael Marty [[hidden email]]
Sent: Wednesday, October 03, 2012 1:37 PM
To: Jake Evans
Cc: <[hidden email]>
Subject: Re: [CEE-DISCUSSION-LIST] Unique Event ID (RecordId)

 

I am realizing we might e talking about different things... A unique ID per event instance vs. an iD identifying the type of event, like snort SIDs or windows "security:528" type of ID. Which one are we talking a out? I was referring to the former...

 

  Raffy

Sent from my iTelephone


On Oct 3, 2012, at 12:26 PM, Jake Evans <[hidden email]> wrote:

Here are my answers/thoughts on this:

1.       Optional  seems to be the way to go.  Although I’d like to say “Mandatory,” I think some software producers will back off because of the implied level of additional overhead in maintaining collections of unique events will bring.

2.       For people who do decide to implement Unique Event ID, I do think a simple set of guidelines by which vendors name their events should be followed.  Perhaps something like: UNIQUE_VENDOR_STRING:PRODUCT:VERSION:EVENT_ID.  UNIQUE_VENDOR_STRINGs could be placed on a publically available site (CEE site) where new vendors could verify the uniqueness of the string they’d like to use.  From there, it would be the responsibility of vendors to make sure PRODUCT, VERSION and EVENT_ID string combinations remain unique.

3.       UUID

 

Jake

 

Jake Evans, GPEN, GCIH, GWAPT, GCIA, CISSP, CISA, CRISC, CPISA, CPISM | Sr. Security and Compliance Analyst

 

Tripwire

101 SW Main St., Ste. 1500
Portland, OR 97204  

Direct: 503.276.7658

Main: 503.276.7500

 

TRIPWIRE | TAKE CONTROL.
www.tripwire.com

 

From: Wunder, John A. [[hidden email]]
Sent: Wednesday, October 03, 2012 11:56 AM
To: [hidden email]
Subject: [CEE-DISCUSSION-LIST] Unique Event ID (RecordId)

 

I wanted to restart this discussion and move it to its own thread. For reference, this is the discussion about whether CEE should have a field where producers can (or must) put a unique identifier for individual events.

 

To restart some of the topics:

 

1.       Optional vs. required. People seemed to be leaning towards making the field optional to ease the implementation burden for event producers. Does anyone disagree with this? The main concern of course is that this leads to less compatibility among producers so that consumers can’t rely on consistency. In other words, is the field even still useful if consumers can’t count on it being there?

2.       Do we need to specify a format, or can we just give a field a title and tell producers to stick something unique in it? Upsides of not specifying a particular format is the ease of adoption, downside is that consumers would have to expect basically anything in that field and some producers might not succeed at making it truly unique.

3.       If we do specify a format, what is that format?

a.       UUID?

b.      Hash

c.       Other?

 

My personal opinion is that for ease of implementation and simplicity we have an optional field that, if populated, MUST be populated with a UUID.

 

In particular it would be good to hear from event producers on this. Does anyone from the lumberjack team want to weigh in? Or any other people developing software that will produce CEE events?

 

Lastly, what do people think about scheduling a chat on IRC about topics like this? E-mail is a pretty disjointed way of doing this and a telecom is tough to organize, but maybe a ½ chat on IRC would let people tune in but continue their regular work?

 

Thanks,

John

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Unique Event ID (RecordId)

Jake Evans
In reply to this post by Wunder, John A.

Thanks for clarifying.  Regarding the original question (now that I’m on the same page as you), I feel more strongly that it should be optional (could be seen as overly cumbersome) and that the format should be up to the producers.  Guidance on the format should be provided.

 

Jake

 

Jake Evans, GPEN, GCIH, GWAPT, GCIA, CISSP, CISA, CRISC, CPISA, CPISM | Sr. Security and Compliance Analyst

 

Tripwire

101 SW Main St., Ste. 1500
Portland, OR 97204  

Direct: 503.276.7658

Main: 503.276.7500

 

TRIPWIRE | TAKE CONTROL.
www.tripwire.com

 

From: Wunder, John A. [mailto:[hidden email]]
Sent: Thursday, October 04, 2012 4:50 AM
To: [hidden email]
Subject: Re: [CEE-DISCUSSION-LIST] Unique Event ID (RecordId)

 

Just to clear up terms UUID has a specific meaning in some circles; what you’re proposing here isn’t so much a UUID as a namespaced unique identifier.

 

I like the approach, just wanted to clarify the term in case other people are like me and think of something specific when they hear UUID.

 

Anyone object to what Jake proposed as an OPTIONAL identifier? CPE uses a similar namespace mechanism for its products, I’ll ask around to see if they have any lessons learned from that approach.

 

John

 

From: Jake Evans [mailto:[hidden email]]
Sent: Wednesday, October 03, 2012 6:04 PM
To: cee-discussion-list CEE-Related Discussion
Subject: [CEE-DISCUSSION-LIST] FW: [CEE-DISCUSSION-LIST] Unique Event ID (RecordId)

 

Just forwarding this conversation back into the list to include a simple example below.

 

Jake

 

Jake Evans, GPEN, GCIH, GWAPT, GCIA, CISSP, CISA, CRISC, CPISA, CPISM | Sr. Security and Compliance Analyst

 

Tripwire

101 SW Main St., Ste. 1500
Portland, OR 97204  

Direct: 503.276.7658

Main: 503.276.7500

 

TRIPWIRE | TAKE CONTROL.
www.tripwire.com

 

From: Raffael Marty [hidden email]
Sent: Wednesday, October 03, 2012 2:55 PM
To: Jake Evans
Subject: Re: [CEE-DISCUSSION-LIST] Unique Event ID (RecordId)

 

+1

Sent from my iTelephone


On Oct 3, 2012, at 1:56 PM, Jake Evans <[hidden email]> wrote:

I was thinking UUID format would look something like this:

 

SourceFire:Snort:2.9:75647

Vendor:Product:Version:EventID

 

So I was referring to the latter.  Additionally, a unique instance of an event type (what you’re talking about) could be assigned an incremental value as well, sort of like a ticket number.

 

Jake

 

Jake Evans, GPEN, GCIH, GWAPT, GCIA, CISSP, CISA, CRISC, CPISA, CPISM | Sr. Security and Compliance Analyst

 

Tripwire

101 SW Main St., Ste. 1500
Portland, OR 97204  

Direct: 503.276.7658

Main: 503.276.7500

 

TRIPWIRE | TAKE CONTROL.
www.tripwire.com

 

From: Raffael Marty [[hidden email]]
Sent: Wednesday, October 03, 2012 1:37 PM
To: Jake Evans
Cc: <[hidden email]>
Subject: Re: [CEE-DISCUSSION-LIST] Unique Event ID (RecordId)

 

I am realizing we might e talking about different things... A unique ID per event instance vs. an iD identifying the type of event, like snort SIDs or windows "security:528" type of ID. Which one are we talking a out? I was referring to the former...

 

  Raffy

Sent from my iTelephone


On Oct 3, 2012, at 12:26 PM, Jake Evans <[hidden email]> wrote:

Here are my answers/thoughts on this:

1.       Optional  seems to be the way to go.  Although I’d like to say “Mandatory,” I think some software producers will back off because of the implied level of additional overhead in maintaining collections of unique events will bring.

2.       For people who do decide to implement Unique Event ID, I do think a simple set of guidelines by which vendors name their events should be followed.  Perhaps something like: UNIQUE_VENDOR_STRING:PRODUCT:VERSION:EVENT_ID.  UNIQUE_VENDOR_STRINGs could be placed on a publically available site (CEE site) where new vendors could verify the uniqueness of the string they’d like to use.  From there, it would be the responsibility of vendors to make sure PRODUCT, VERSION and EVENT_ID string combinations remain unique.

3.       UUID

 

Jake

 

Jake Evans, GPEN, GCIH, GWAPT, GCIA, CISSP, CISA, CRISC, CPISA, CPISM | Sr. Security and Compliance Analyst

 

Tripwire

101 SW Main St., Ste. 1500
Portland, OR 97204  

Direct: 503.276.7658

Main: 503.276.7500

 

TRIPWIRE | TAKE CONTROL.
www.tripwire.com

 

From: Wunder, John A. [[hidden email]]
Sent: Wednesday, October 03, 2012 11:56 AM
To: [hidden email]
Subject: [CEE-DISCUSSION-LIST] Unique Event ID (RecordId)

 

I wanted to restart this discussion and move it to its own thread. For reference, this is the discussion about whether CEE should have a field where producers can (or must) put a unique identifier for individual events.

 

To restart some of the topics:

 

1.       Optional vs. required. People seemed to be leaning towards making the field optional to ease the implementation burden for event producers. Does anyone disagree with this? The main concern of course is that this leads to less compatibility among producers so that consumers can’t rely on consistency. In other words, is the field even still useful if consumers can’t count on it being there?

2.       Do we need to specify a format, or can we just give a field a title and tell producers to stick something unique in it? Upsides of not specifying a particular format is the ease of adoption, downside is that consumers would have to expect basically anything in that field and some producers might not succeed at making it truly unique.

3.       If we do specify a format, what is that format?

a.       UUID?

b.      Hash

c.       Other?

 

My personal opinion is that for ease of implementation and simplicity we have an optional field that, if populated, MUST be populated with a UUID.

 

In particular it would be good to hear from event producers on this. Does anyone from the lumberjack team want to weigh in? Or any other people developing software that will produce CEE events?

 

Lastly, what do people think about scheduling a chat on IRC about topics like this? E-mail is a pretty disjointed way of doing this and a telecom is tough to organize, but maybe a ½ chat on IRC would let people tune in but continue their regular work?

 

Thanks,

John

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Unique Event ID (RecordId)

William Heinbockel
I agree; per event record IDs should be optional.

My reasons include the following:

1. You won't be able to guarantee uniqueness for multi-threaded apps
2. Waste of space; most event consumers only use them to detect
duplicate events
3. Most event consumers assign their own instance ID


On Thu, 2012-10-04 at 15:58 +0000, Jake Evans wrote:

> Thanks for clarifying.  Regarding the original question (now that I’m
> on the same page as you), I feel more strongly that it should be
> optional (could be seen as overly cumbersome) and that the format
> should be up to the producers.  Guidance on the format should be
> provided.
>
>  
>
> Jake
>
>  
>
> Jake Evans, GPEN, GCIH, GWAPT, GCIA, CISSP, CISA, CRISC, CPISA, CPISM|
> Sr. Security and Compliance Analyst
>
>  
>
> Tripwire
>
> 101 SW Main St., Ste. 1500
> Portland, OR 97204  
>
> Direct: 503.276.7658
>
> Main: 503.276.7500
>
>  
>
> TRIPWIRE |TAKE CONTROL.
> www.tripwire.com
>
>
>  
>
> From: Wunder, John A. [mailto:[hidden email]]
> Sent: Thursday, October 04, 2012 4:50 AM
> To: [hidden email]
> Subject: Re: [CEE-DISCUSSION-LIST] Unique Event ID (RecordId)
>
>
>  
>
> Just to clear up terms UUID has a specific meaning in some circles;
> what you’re proposing here isn’t so much a UUID as a namespaced unique
> identifier.
>
>  
>
> I like the approach, just wanted to clarify the term in case other
> people are like me and think of something specific when they hear
> UUID.
>
>  
>
> Anyone object to what Jake proposed as an OPTIONAL identifier? CPE
> uses a similar namespace mechanism for its products, I’ll ask around
> to see if they have any lessons learned from that approach.
>
>  
>
> John
>
>  
>
> From: Jake Evans [mailto:[hidden email]]
> Sent: Wednesday, October 03, 2012 6:04 PM
> To: cee-discussion-list CEE-Related Discussion
> Subject: [CEE-DISCUSSION-LIST] FW: [CEE-DISCUSSION-LIST] Unique Event
> ID (RecordId)
>
>
>  
>
> Just forwarding this conversation back into the list to include a
> simple example below.
>
>  
>
> Jake
>
>  
>
> Jake Evans, GPEN, GCIH, GWAPT, GCIA, CISSP, CISA, CRISC, CPISA, CPISM|
> Sr. Security and Compliance Analyst
>
>  
>
> Tripwire
>
> 101 SW Main St., Ste. 1500
> Portland, OR 97204  
>
> Direct: 503.276.7658
>
> Main: 503.276.7500
>
>  
>
> TRIPWIRE |TAKE CONTROL.
> www.tripwire.com
>
>
>  
>
> From: Raffael Marty [mailto:[hidden email]]
> Sent: Wednesday, October 03, 2012 2:55 PM
> To: Jake Evans
> Subject: Re: [CEE-DISCUSSION-LIST] Unique Event ID (RecordId)
>
>
>  
>
> +1
>
> Sent from my iTelephone
>
>
>
> On Oct 3, 2012, at 1:56 PM, Jake Evans <[hidden email]> wrote:
>
>
>         I was thinking UUID format would look something like this:
>        
>          
>        
>         SourceFire:Snort:2.9:75647
>        
>         Vendor:Product:Version:EventID
>        
>          
>        
>         So I was referring to the latter.  Additionally, a unique
>         instance of an event type (what you’re talking about) could be
>         assigned an incremental value as well, sort of like a ticket
>         number.
>        
>          
>        
>         Jake
>        
>          
>        
>         Jake Evans, GPEN, GCIH, GWAPT, GCIA, CISSP, CISA, CRISC,
>         CPISA, CPISM| Sr. Security and Compliance Analyst
>        
>          
>        
>         Tripwire
>        
>         101 SW Main St., Ste. 1500
>         Portland, OR 97204  
>        
>         Direct: 503.276.7658
>        
>         Main: 503.276.7500
>        
>          
>        
>         TRIPWIRE |TAKE CONTROL.
>         www.tripwire.com
>        
>        
>          
>        
>         From: Raffael Marty [mailto:[hidden email]]
>         Sent: Wednesday, October 03, 2012 1:37 PM
>         To: Jake Evans
>         Cc: <[hidden email]>
>         Subject: Re: [CEE-DISCUSSION-LIST] Unique Event ID (RecordId)
>        
>        
>          
>        
>         I am realizing we might e talking about different things... A
>         unique ID per event instance vs. an iD identifying the type of
>         event, like snort SIDs or windows "security:528" type of ID.
>         Which one are we talking a out? I was referring to the
>         former...
>        
>        
>          
>        
>        
>           Raffy
>        
>         Sent from my iTelephone
>        
>        
>        
>         On Oct 3, 2012, at 12:26 PM, Jake Evans <[hidden email]>
>         wrote:
>        
>        
>                 Here are my answers/thoughts on this:
>                
>                 1.      Optional  seems to be the way to go.  Although
>                 I’d like to say “Mandatory,” I think some software
>                 producers will back off because of the implied level
>                 of additional overhead in maintaining collections of
>                 unique events will bring.
>                
>                 2.      For people who do decide to implement Unique
>                 Event ID, I do think a simple set of guidelines by
>                 which vendors name their events should be followed.
>                 Perhaps something like:
>                 UNIQUE_VENDOR_STRING:PRODUCT:VERSION:EVENT_ID.
>                 UNIQUE_VENDOR_STRINGs could be placed on a publically
>                 available site (CEE site) where new vendors could
>                 verify the uniqueness of the string they’d like to
>                 use.  From there, it would be the responsibility of
>                 vendors to make sure PRODUCT, VERSION and EVENT_ID
>                 string combinations remain unique.
>                
>                 3.      UUID
>                
>                  
>                
>                 Jake
>                
>                  
>                
>                 Jake Evans, GPEN, GCIH, GWAPT, GCIA, CISSP, CISA,
>                 CRISC, CPISA, CPISM| Sr. Security and Compliance
>                 Analyst
>                
>                  
>                
>                 Tripwire
>                
>                 101 SW Main St., Ste. 1500
>                 Portland, OR 97204  
>                
>                 Direct: 503.276.7658
>                
>                 Main: 503.276.7500
>                
>                  
>                
>                 TRIPWIRE |TAKE CONTROL.
>                 www.tripwire.com
>                
>                
>                  
>                
>                 From: Wunder, John A. [mailto:[hidden email]]
>                 Sent: Wednesday, October 03, 2012 11:56 AM
>                 To: [hidden email]
>                 Subject: [CEE-DISCUSSION-LIST] Unique Event ID
>                 (RecordId)
>                
>                
>                  
>                
>                 I wanted to restart this discussion and move it to its
>                 own thread. For reference, this is the discussion
>                 about whether CEE should have a field where producers
>                 can (or must) put a unique identifier for individual
>                 events.
>                
>                  
>                
>                 To restart some of the topics:
>                
>                  
>                
>                 1.      Optional vs. required. People seemed to be
>                 leaning towards making the field optional to ease the
>                 implementation burden for event producers. Does anyone
>                 disagree with this? The main concern of course is that
>                 this leads to less compatibility among producers so
>                 that consumers can’t rely on consistency. In other
>                 words, is the field even still useful if consumers
>                 can’t count on it being there?
>                
>                 2.      Do we need to specify a format, or can we just
>                 give a field a title and tell producers to stick
>                 something unique in it? Upsides of not specifying a
>                 particular format is the ease of adoption, downside is
>                 that consumers would have to expect basically anything
>                 in that field and some producers might not succeed at
>                 making it truly unique.
>                
>                 3.      If we do specify a format, what is that
>                 format?
>                
>                 a.      UUID?
>                
>                 b.     Hash
>                
>                 c.      Other?
>                
>                  
>                
>                 My personal opinion is that for ease of implementation
>                 and simplicity we have an optional field that, if
>                 populated, MUST be populated with a UUID.
>                
>                  
>                
>                 In particular it would be good to hear from event
>                 producers on this. Does anyone from the lumberjack
>                 team want to weigh in? Or any other people developing
>                 software that will produce CEE events?
>                
>                  
>                
>                 Lastly, what do people think about scheduling a chat
>                 on IRC about topics like this? E-mail is a pretty
>                 disjointed way of doing this and a telecom is tough to
>                 organize, but maybe a ½ chat on IRC would let people
>                 tune in but continue their regular work?
>                
>                  
>                
>                 Thanks,
>                
>                 John
>                
>                
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Unique Event ID (RecordId)

Anton Chuvakin
> I agree; per event record IDs should be optional.

It simply CANNOT be mandatory as 99% of logs on the planet don't have it.

--
Dr. Anton Chuvakin
Site: http://www.chuvakin.org
Twitter: @anton_chuvakin
Work: http://www.linkedin.com/in/chuvakin
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Unique Event ID (RecordId)

Fletcher, Boyd C IV Mr CIV OSD
In reply to this post by William Heinbockel
1.  uniqueness is easy to do if you pick an approach that doesn't use
monotonically increasing numbers

2.  Uniqueness of event records is very important for CND and auditing of
systems for legal/financial reasons






On 10/4/12 2:38 PM, "William Heinbockel" <[hidden email]> wrote:

>I agree; per event record IDs should be optional.
>
>My reasons include the following:
>
>1. You won't be able to guarantee uniqueness for multi-threaded apps
>2. Waste of space; most event consumers only use them to detect
>duplicate events
>3. Most event consumers assign their own instance ID
>
>
>On Thu, 2012-10-04 at 15:58 +0000, Jake Evans wrote:
>> Thanks for clarifying.  Regarding the original question (now that I¹m
>> on the same page as you), I feel more strongly that it should be
>> optional (could be seen as overly cumbersome) and that the format
>> should be up to the producers.  Guidance on the format should be
>> provided.
>>
>>  
>>
>> Jake
>>
>>  
>>
>> Jake Evans, GPEN, GCIH, GWAPT, GCIA, CISSP, CISA, CRISC, CPISA, CPISM|
>> Sr. Security and Compliance Analyst
>>
>>  
>>
>> Tripwire
>>
>> 101 SW Main St., Ste. 1500
>> Portland, OR 97204
>>
>> Direct: 503.276.7658
>>
>> Main: 503.276.7500
>>
>>  
>>
>> TRIPWIRE |TAKE CONTROL.
>> www.tripwire.com
>>
>>
>>  
>>
>> From: Wunder, John A. [mailto:[hidden email]]
>> Sent: Thursday, October 04, 2012 4:50 AM
>> To: [hidden email]
>> Subject: Re: [CEE-DISCUSSION-LIST] Unique Event ID (RecordId)
>>
>>
>>  
>>
>> Just to clear up terms UUID has a specific meaning in some circles;
>> what you¹re proposing here isn¹t so much a UUID as a namespaced unique
>> identifier.
>>
>>  
>>
>> I like the approach, just wanted to clarify the term in case other
>> people are like me and think of something specific when they hear
>> UUID.
>>
>>  
>>
>> Anyone object to what Jake proposed as an OPTIONAL identifier? CPE
>> uses a similar namespace mechanism for its products, I¹ll ask around
>> to see if they have any lessons learned from that approach.
>>
>>  
>>
>> John
>>
>>  
>>
>> From: Jake Evans [mailto:[hidden email]]
>> Sent: Wednesday, October 03, 2012 6:04 PM
>> To: cee-discussion-list CEE-Related Discussion
>> Subject: [CEE-DISCUSSION-LIST] FW: [CEE-DISCUSSION-LIST] Unique Event
>> ID (RecordId)
>>
>>
>>  
>>
>> Just forwarding this conversation back into the list to include a
>> simple example below.
>>
>>  
>>
>> Jake
>>
>>  
>>
>> Jake Evans, GPEN, GCIH, GWAPT, GCIA, CISSP, CISA, CRISC, CPISA, CPISM|
>> Sr. Security and Compliance Analyst
>>
>>  
>>
>> Tripwire
>>
>> 101 SW Main St., Ste. 1500
>> Portland, OR 97204
>>
>> Direct: 503.276.7658
>>
>> Main: 503.276.7500
>>
>>  
>>
>> TRIPWIRE |TAKE CONTROL.
>> www.tripwire.com
>>
>>
>>  
>>
>> From: Raffael Marty [mailto:[hidden email]]
>> Sent: Wednesday, October 03, 2012 2:55 PM
>> To: Jake Evans
>> Subject: Re: [CEE-DISCUSSION-LIST] Unique Event ID (RecordId)
>>
>>
>>  
>>
>> +1
>>
>> Sent from my iTelephone
>>
>>
>>
>> On Oct 3, 2012, at 1:56 PM, Jake Evans <[hidden email]> wrote:
>>
>>
>>         I was thinking UUID format would look something like this:
>>        
>>          
>>        
>>         SourceFire:Snort:2.9:75647
>>        
>>         Vendor:Product:Version:EventID
>>        
>>          
>>        
>>         So I was referring to the latter.  Additionally, a unique
>>         instance of an event type (what you¹re talking about) could be
>>         assigned an incremental value as well, sort of like a ticket
>>         number.
>>        
>>          
>>        
>>         Jake
>>        
>>          
>>        
>>         Jake Evans, GPEN, GCIH, GWAPT, GCIA, CISSP, CISA, CRISC,
>>         CPISA, CPISM| Sr. Security and Compliance Analyst
>>        
>>          
>>        
>>         Tripwire
>>        
>>         101 SW Main St., Ste. 1500
>>         Portland, OR 97204
>>        
>>         Direct: 503.276.7658
>>        
>>         Main: 503.276.7500
>>        
>>          
>>        
>>         TRIPWIRE |TAKE CONTROL.
>>         www.tripwire.com
>>        
>>        
>>          
>>        
>>         From: Raffael Marty [mailto:[hidden email]]
>>         Sent: Wednesday, October 03, 2012 1:37 PM
>>         To: Jake Evans
>>         Cc: <[hidden email]>
>>         Subject: Re: [CEE-DISCUSSION-LIST] Unique Event ID (RecordId)
>>        
>>        
>>          
>>        
>>         I am realizing we might e talking about different things... A
>>         unique ID per event instance vs. an iD identifying the type of
>>         event, like snort SIDs or windows "security:528" type of ID.
>>         Which one are we talking a out? I was referring to the
>>         former...
>>        
>>        
>>          
>>        
>>        
>>           Raffy
>>        
>>         Sent from my iTelephone
>>        
>>        
>>        
>>         On Oct 3, 2012, at 12:26 PM, Jake Evans <[hidden email]>
>>         wrote:
>>        
>>        
>>                 Here are my answers/thoughts on this:
>>                
>>                 1.      Optional  seems to be the way to go.  Although
>>                 I¹d like to say ³Mandatory,² I think some software
>>                 producers will back off because of the implied level
>>                 of additional overhead in maintaining collections of
>>                 unique events will bring.
>>                
>>                 2.      For people who do decide to implement Unique
>>                 Event ID, I do think a simple set of guidelines by
>>                 which vendors name their events should be followed.
>>                 Perhaps something like:
>>                 UNIQUE_VENDOR_STRING:PRODUCT:VERSION:EVENT_ID.
>>                 UNIQUE_VENDOR_STRINGs could be placed on a publically
>>                 available site (CEE site) where new vendors could
>>                 verify the uniqueness of the string they¹d like to
>>                 use.  From there, it would be the responsibility of
>>                 vendors to make sure PRODUCT, VERSION and EVENT_ID
>>                 string combinations remain unique.
>>                
>>                 3.      UUID
>>                
>>                
>>                
>>                 Jake
>>                
>>                
>>                
>>                 Jake Evans, GPEN, GCIH, GWAPT, GCIA, CISSP, CISA,
>>                 CRISC, CPISA, CPISM| Sr. Security and Compliance
>>                 Analyst
>>                
>>                
>>                
>>                 Tripwire
>>                
>>                 101 SW Main St., Ste. 1500
>>                 Portland, OR 97204
>>                
>>                 Direct: 503.276.7658
>>                
>>                 Main: 503.276.7500
>>                
>>                
>>                
>>                 TRIPWIRE |TAKE CONTROL.
>>                 www.tripwire.com
>>                
>>                
>>                
>>                
>>                 From: Wunder, John A. [mailto:[hidden email]]
>>                 Sent: Wednesday, October 03, 2012 11:56 AM
>>                 To: [hidden email]
>>                 Subject: [CEE-DISCUSSION-LIST] Unique Event ID
>>                 (RecordId)
>>                
>>                
>>                
>>                
>>                 I wanted to restart this discussion and move it to its
>>                 own thread. For reference, this is the discussion
>>                 about whether CEE should have a field where producers
>>                 can (or must) put a unique identifier for individual
>>                 events.
>>                
>>                
>>                
>>                 To restart some of the topics:
>>                
>>                
>>                
>>                 1.      Optional vs. required. People seemed to be
>>                 leaning towards making the field optional to ease the
>>                 implementation burden for event producers. Does anyone
>>                 disagree with this? The main concern of course is that
>>                 this leads to less compatibility among producers so
>>                 that consumers can¹t rely on consistency. In other
>>                 words, is the field even still useful if consumers
>>                 can¹t count on it being there?
>>                
>>                 2.      Do we need to specify a format, or can we just
>>                 give a field a title and tell producers to stick
>>                 something unique in it? Upsides of not specifying a
>>                 particular format is the ease of adoption, downside is
>>                 that consumers would have to expect basically anything
>>                 in that field and some producers might not succeed at
>>                 making it truly unique.
>>                
>>                 3.      If we do specify a format, what is that
>>                 format?
>>                
>>                 a.      UUID?
>>                
>>                 b.     Hash
>>                
>>                 c.      Other?
>>                
>>                
>>                
>>                 My personal opinion is that for ease of implementation
>>                 and simplicity we have an optional field that, if
>>                 populated, MUST be populated with a UUID.
>>                
>>                
>>                
>>                 In particular it would be good to hear from event
>>                 producers on this. Does anyone from the lumberjack
>>                 team want to weigh in? Or any other people developing
>>                 software that will produce CEE events?
>>                
>>                
>>                
>>                 Lastly, what do people think about scheduling a chat
>>                 on IRC about topics like this? E-mail is a pretty
>>                 disjointed way of doing this and a telecom is tough to
>>                 organize, but maybe a 1Ž2 chat on IRC would let people
>>                 tune in but continue their regular work?
>>                
>>                
>>                
>>                 Thanks,
>>                
>>                 John
>>                
>>                
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Unique Event ID (RecordId)

Mitch Thomas
In reply to this post by William Heinbockel
I agree that they should be optional.

Once present they will be incredibly useful for:

1) External references.  For example a set of event ID(s) could be sent
along with other meta-data, which would allow further "drill down" into
event details
2) Audit-ability


3) De-duplication


On 10/4/12 11:38 AM, "William Heinbockel" <[hidden email]> wrote:

>I agree; per event record IDs should be optional.
>
>My reasons include the following:
>
>1. You won't be able to guarantee uniqueness for multi-threaded apps
>2. Waste of space; most event consumers only use them to detect
>duplicate events
>3. Most event consumers assign their own instance ID
>
>
>On Thu, 2012-10-04 at 15:58 +0000, Jake Evans wrote:
>> Thanks for clarifying.  Regarding the original question (now that I¹m
>> on the same page as you), I feel more strongly that it should be
>> optional (could be seen as overly cumbersome) and that the format
>> should be up to the producers.  Guidance on the format should be
>> provided.
>>
>>  
>>
>> Jake
>>
>>  
>>
>> Jake Evans, GPEN, GCIH, GWAPT, GCIA, CISSP, CISA, CRISC, CPISA, CPISM|
>> Sr. Security and Compliance Analyst
>>
>>  
>>
>> Tripwire
>>
>> 101 SW Main St., Ste. 1500
>> Portland, OR 97204
>>
>> Direct: 503.276.7658
>>
>> Main: 503.276.7500
>>
>>  
>>
>> TRIPWIRE |TAKE CONTROL.
>> www.tripwire.com
>>
>>
>>  
>>
>> From: Wunder, John A. [mailto:[hidden email]]
>> Sent: Thursday, October 04, 2012 4:50 AM
>> To: [hidden email]
>> Subject: Re: [CEE-DISCUSSION-LIST] Unique Event ID (RecordId)
>>
>>
>>  
>>
>> Just to clear up terms UUID has a specific meaning in some circles;
>> what you¹re proposing here isn¹t so much a UUID as a namespaced unique
>> identifier.
>>
>>  
>>
>> I like the approach, just wanted to clarify the term in case other
>> people are like me and think of something specific when they hear
>> UUID.
>>
>>  
>>
>> Anyone object to what Jake proposed as an OPTIONAL identifier? CPE
>> uses a similar namespace mechanism for its products, I¹ll ask around
>> to see if they have any lessons learned from that approach.
>>
>>  
>>
>> John
>>
>>  
>>
>> From: Jake Evans [mailto:[hidden email]]
>> Sent: Wednesday, October 03, 2012 6:04 PM
>> To: cee-discussion-list CEE-Related Discussion
>> Subject: [CEE-DISCUSSION-LIST] FW: [CEE-DISCUSSION-LIST] Unique Event
>> ID (RecordId)
>>
>>
>>  
>>
>> Just forwarding this conversation back into the list to include a
>> simple example below.
>>
>>  
>>
>> Jake
>>
>>  
>>
>> Jake Evans, GPEN, GCIH, GWAPT, GCIA, CISSP, CISA, CRISC, CPISA, CPISM|
>> Sr. Security and Compliance Analyst
>>
>>  
>>
>> Tripwire
>>
>> 101 SW Main St., Ste. 1500
>> Portland, OR 97204
>>
>> Direct: 503.276.7658
>>
>> Main: 503.276.7500
>>
>>  
>>
>> TRIPWIRE |TAKE CONTROL.
>> www.tripwire.com
>>
>>
>>  
>>
>> From: Raffael Marty [mailto:[hidden email]]
>> Sent: Wednesday, October 03, 2012 2:55 PM
>> To: Jake Evans
>> Subject: Re: [CEE-DISCUSSION-LIST] Unique Event ID (RecordId)
>>
>>
>>  
>>
>> +1
>>
>> Sent from my iTelephone
>>
>>
>>
>> On Oct 3, 2012, at 1:56 PM, Jake Evans <[hidden email]> wrote:
>>
>>
>>         I was thinking UUID format would look something like this:
>>        
>>          
>>        
>>         SourceFire:Snort:2.9:75647
>>        
>>         Vendor:Product:Version:EventID
>>        
>>          
>>        
>>         So I was referring to the latter.  Additionally, a unique
>>         instance of an event type (what you¹re talking about) could be
>>         assigned an incremental value as well, sort of like a ticket
>>         number.
>>        
>>          
>>        
>>         Jake
>>        
>>          
>>        
>>         Jake Evans, GPEN, GCIH, GWAPT, GCIA, CISSP, CISA, CRISC,
>>         CPISA, CPISM| Sr. Security and Compliance Analyst
>>        
>>          
>>        
>>         Tripwire
>>        
>>         101 SW Main St., Ste. 1500
>>         Portland, OR 97204
>>        
>>         Direct: 503.276.7658
>>        
>>         Main: 503.276.7500
>>        
>>          
>>        
>>         TRIPWIRE |TAKE CONTROL.
>>         www.tripwire.com
>>        
>>        
>>          
>>        
>>         From: Raffael Marty [mailto:[hidden email]]
>>         Sent: Wednesday, October 03, 2012 1:37 PM
>>         To: Jake Evans
>>         Cc: <[hidden email]>
>>         Subject: Re: [CEE-DISCUSSION-LIST] Unique Event ID (RecordId)
>>        
>>        
>>          
>>        
>>         I am realizing we might e talking about different things... A
>>         unique ID per event instance vs. an iD identifying the type of
>>         event, like snort SIDs or windows "security:528" type of ID.
>>         Which one are we talking a out? I was referring to the
>>         former...
>>        
>>        
>>          
>>        
>>        
>>           Raffy
>>        
>>         Sent from my iTelephone
>>        
>>        
>>        
>>         On Oct 3, 2012, at 12:26 PM, Jake Evans <[hidden email]>
>>         wrote:
>>        
>>        
>>                 Here are my answers/thoughts on this:
>>                
>>                 1.      Optional  seems to be the way to go.  Although
>>                 I¹d like to say ³Mandatory,² I think some software
>>                 producers will back off because of the implied level
>>                 of additional overhead in maintaining collections of
>>                 unique events will bring.
>>                
>>                 2.      For people who do decide to implement Unique
>>                 Event ID, I do think a simple set of guidelines by
>>                 which vendors name their events should be followed.
>>                 Perhaps something like:
>>                 UNIQUE_VENDOR_STRING:PRODUCT:VERSION:EVENT_ID.
>>                 UNIQUE_VENDOR_STRINGs could be placed on a publically
>>                 available site (CEE site) where new vendors could
>>                 verify the uniqueness of the string they¹d like to
>>                 use.  From there, it would be the responsibility of
>>                 vendors to make sure PRODUCT, VERSION and EVENT_ID
>>                 string combinations remain unique.
>>                
>>                 3.      UUID
>>                
>>                
>>                
>>                 Jake
>>                
>>                
>>                
>>                 Jake Evans, GPEN, GCIH, GWAPT, GCIA, CISSP, CISA,
>>                 CRISC, CPISA, CPISM| Sr. Security and Compliance
>>                 Analyst
>>                
>>                
>>                
>>                 Tripwire
>>                
>>                 101 SW Main St., Ste. 1500
>>                 Portland, OR 97204
>>                
>>                 Direct: 503.276.7658
>>                
>>                 Main: 503.276.7500
>>                
>>                
>>                
>>                 TRIPWIRE |TAKE CONTROL.
>>                 www.tripwire.com
>>                
>>                
>>                
>>                
>>                 From: Wunder, John A. [mailto:[hidden email]]
>>                 Sent: Wednesday, October 03, 2012 11:56 AM
>>                 To: [hidden email]
>>                 Subject: [CEE-DISCUSSION-LIST] Unique Event ID
>>                 (RecordId)
>>                
>>                
>>                
>>                
>>                 I wanted to restart this discussion and move it to its
>>                 own thread. For reference, this is the discussion
>>                 about whether CEE should have a field where producers
>>                 can (or must) put a unique identifier for individual
>>                 events.
>>                
>>                
>>                
>>                 To restart some of the topics:
>>                
>>                
>>                
>>                 1.      Optional vs. required. People seemed to be
>>                 leaning towards making the field optional to ease the
>>                 implementation burden for event producers. Does anyone
>>                 disagree with this? The main concern of course is that
>>                 this leads to less compatibility among producers so
>>                 that consumers can¹t rely on consistency. In other
>>                 words, is the field even still useful if consumers
>>                 can¹t count on it being there?
>>                
>>                 2.      Do we need to specify a format, or can we just
>>                 give a field a title and tell producers to stick
>>                 something unique in it? Upsides of not specifying a
>>                 particular format is the ease of adoption, downside is
>>                 that consumers would have to expect basically anything
>>                 in that field and some producers might not succeed at
>>                 making it truly unique.
>>                
>>                 3.      If we do specify a format, what is that
>>                 format?
>>                
>>                 a.      UUID?
>>                
>>                 b.     Hash
>>                
>>                 c.      Other?
>>                
>>                
>>                
>>                 My personal opinion is that for ease of implementation
>>                 and simplicity we have an optional field that, if
>>                 populated, MUST be populated with a UUID.
>>                
>>                
>>                
>>                 In particular it would be good to hear from event
>>                 producers on this. Does anyone from the lumberjack
>>                 team want to weigh in? Or any other people developing
>>                 software that will produce CEE events?
>>                
>>                
>>                
>>                 Lastly, what do people think about scheduling a chat
>>                 on IRC about topics like this? E-mail is a pretty
>>                 disjointed way of doing this and a telecom is tough to
>>                 organize, but maybe a 1Ž2 chat on IRC would let people
>>                 tune in but continue their regular work?
>>                
>>                
>>                
>>                 Thanks,
>>                
>>                 John
>>                
>>                
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Unique Event ID (RecordId)

Fletcher, Boyd C IV Mr CIV OSD
In reply to this post by Anton Chuvakin
The many operating systems have unique record ids (sequence numbers, or
something similar) in addition to an eventID (that maps into some type of
event list profile).


Network devices like routers/switch/firewalls might not but then most
systems that use SYSLOG don't because of lack of robust support in the
protocol.










On 10/4/12 3:03 PM, "Anton Chuvakin" <[hidden email]> wrote:

>> I agree; per event record IDs should be optional.
>
>It simply CANNOT be mandatory as 99% of logs on the planet don't have it.
>
>--
>Dr. Anton Chuvakin
>Site: http://www.chuvakin.org
>Twitter: @anton_chuvakin
>Work: http://www.linkedin.com/in/chuvakin
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Unique Event ID (RecordId)

Fletcher, Boyd C IV Mr CIV OSD
In reply to this post by Mitch Thomas
If the purpose of CEE is to fix the problems with eventing then why would
we want to continue to exacerbate a bad situation by not requiring it?

Just because some systems do not use record ID/sequence numbers today,
doesn't mean they shouldn't in the future. They  are going to have to make
significant changes to support CEE so they might as well address the
defiencies in the their current audit/log implementations at the same time.






On 10/4/12 4:15 PM, "Mitch Thomas" <[hidden email]> wrote:

>I agree that they should be optional.
>
>Once present they will be incredibly useful for:
>
>1) External references.  For example a set of event ID(s) could be sent
>along with other meta-data, which would allow further "drill down" into
>event details
>2) Audit-ability
>
>
>3) De-duplication
>
>
>On 10/4/12 11:38 AM, "William Heinbockel" <[hidden email]> wrote:
>
>>I agree; per event record IDs should be optional.
>>
>>My reasons include the following:
>>
>>1. You won't be able to guarantee uniqueness for multi-threaded apps
>>2. Waste of space; most event consumers only use them to detect
>>duplicate events
>>3. Most event consumers assign their own instance ID
>>
>>
>>On Thu, 2012-10-04 at 15:58 +0000, Jake Evans wrote:
>>> Thanks for clarifying.  Regarding the original question (now that I¹m
>>> on the same page as you), I feel more strongly that it should be
>>> optional (could be seen as overly cumbersome) and that the format
>>> should be up to the producers.  Guidance on the format should be
>>> provided.
>>>
>>>  
>>>
>>> Jake
>>>
>>>  
>>>
>>> Jake Evans, GPEN, GCIH, GWAPT, GCIA, CISSP, CISA, CRISC, CPISA, CPISM|
>>> Sr. Security and Compliance Analyst
>>>
>>>  
>>>
>>> Tripwire
>>>
>>> 101 SW Main St., Ste. 1500
>>> Portland, OR 97204
>>>
>>> Direct: 503.276.7658
>>>
>>> Main: 503.276.7500
>>>
>>>  
>>>
>>> TRIPWIRE |TAKE CONTROL.
>>> www.tripwire.com
>>>
>>>
>>>  
>>>
>>> From: Wunder, John A. [mailto:[hidden email]]
>>> Sent: Thursday, October 04, 2012 4:50 AM
>>> To: [hidden email]
>>> Subject: Re: [CEE-DISCUSSION-LIST] Unique Event ID (RecordId)
>>>
>>>
>>>  
>>>
>>> Just to clear up terms UUID has a specific meaning in some circles;
>>> what you¹re proposing here isn¹t so much a UUID as a namespaced unique
>>> identifier.
>>>
>>>  
>>>
>>> I like the approach, just wanted to clarify the term in case other
>>> people are like me and think of something specific when they hear
>>> UUID.
>>>
>>>  
>>>
>>> Anyone object to what Jake proposed as an OPTIONAL identifier? CPE
>>> uses a similar namespace mechanism for its products, I¹ll ask around
>>> to see if they have any lessons learned from that approach.
>>>
>>>  
>>>
>>> John
>>>
>>>  
>>>
>>> From: Jake Evans [mailto:[hidden email]]
>>> Sent: Wednesday, October 03, 2012 6:04 PM
>>> To: cee-discussion-list CEE-Related Discussion
>>> Subject: [CEE-DISCUSSION-LIST] FW: [CEE-DISCUSSION-LIST] Unique Event
>>> ID (RecordId)
>>>
>>>
>>>  
>>>
>>> Just forwarding this conversation back into the list to include a
>>> simple example below.
>>>
>>>  
>>>
>>> Jake
>>>
>>>  
>>>
>>> Jake Evans, GPEN, GCIH, GWAPT, GCIA, CISSP, CISA, CRISC, CPISA, CPISM|
>>> Sr. Security and Compliance Analyst
>>>
>>>  
>>>
>>> Tripwire
>>>
>>> 101 SW Main St., Ste. 1500
>>> Portland, OR 97204
>>>
>>> Direct: 503.276.7658
>>>
>>> Main: 503.276.7500
>>>
>>>  
>>>
>>> TRIPWIRE |TAKE CONTROL.
>>> www.tripwire.com
>>>
>>>
>>>  
>>>
>>> From: Raffael Marty [mailto:[hidden email]]
>>> Sent: Wednesday, October 03, 2012 2:55 PM
>>> To: Jake Evans
>>> Subject: Re: [CEE-DISCUSSION-LIST] Unique Event ID (RecordId)
>>>
>>>
>>>  
>>>
>>> +1
>>>
>>> Sent from my iTelephone
>>>
>>>
>>>
>>> On Oct 3, 2012, at 1:56 PM, Jake Evans <[hidden email]> wrote:
>>>
>>>
>>>         I was thinking UUID format would look something like this:
>>>        
>>>          
>>>        
>>>         SourceFire:Snort:2.9:75647
>>>        
>>>         Vendor:Product:Version:EventID
>>>        
>>>          
>>>        
>>>         So I was referring to the latter.  Additionally, a unique
>>>         instance of an event type (what you¹re talking about) could be
>>>         assigned an incremental value as well, sort of like a ticket
>>>         number.
>>>        
>>>          
>>>        
>>>         Jake
>>>        
>>>          
>>>        
>>>         Jake Evans, GPEN, GCIH, GWAPT, GCIA, CISSP, CISA, CRISC,
>>>         CPISA, CPISM| Sr. Security and Compliance Analyst
>>>        
>>>          
>>>        
>>>         Tripwire
>>>        
>>>         101 SW Main St., Ste. 1500
>>>         Portland, OR 97204
>>>        
>>>         Direct: 503.276.7658
>>>        
>>>         Main: 503.276.7500
>>>        
>>>          
>>>        
>>>         TRIPWIRE |TAKE CONTROL.
>>>         www.tripwire.com
>>>        
>>>        
>>>          
>>>        
>>>         From: Raffael Marty [mailto:[hidden email]]
>>>         Sent: Wednesday, October 03, 2012 1:37 PM
>>>         To: Jake Evans
>>>         Cc: <[hidden email]>
>>>         Subject: Re: [CEE-DISCUSSION-LIST] Unique Event ID (RecordId)
>>>        
>>>        
>>>          
>>>        
>>>         I am realizing we might e talking about different things... A
>>>         unique ID per event instance vs. an iD identifying the type of
>>>         event, like snort SIDs or windows "security:528" type of ID.
>>>         Which one are we talking a out? I was referring to the
>>>         former...
>>>        
>>>        
>>>          
>>>        
>>>        
>>>           Raffy
>>>        
>>>         Sent from my iTelephone
>>>        
>>>        
>>>        
>>>         On Oct 3, 2012, at 12:26 PM, Jake Evans <[hidden email]>
>>>         wrote:
>>>        
>>>        
>>>                 Here are my answers/thoughts on this:
>>>                
>>>                 1.      Optional  seems to be the way to go.  Although
>>>                 I¹d like to say ³Mandatory,² I think some software
>>>                 producers will back off because of the implied level
>>>                 of additional overhead in maintaining collections of
>>>                 unique events will bring.
>>>                
>>>                 2.      For people who do decide to implement Unique
>>>                 Event ID, I do think a simple set of guidelines by
>>>                 which vendors name their events should be followed.
>>>                 Perhaps something like:
>>>                 UNIQUE_VENDOR_STRING:PRODUCT:VERSION:EVENT_ID.
>>>                 UNIQUE_VENDOR_STRINGs could be placed on a publically
>>>                 available site (CEE site) where new vendors could
>>>                 verify the uniqueness of the string they¹d like to
>>>                 use.  From there, it would be the responsibility of
>>>                 vendors to make sure PRODUCT, VERSION and EVENT_ID
>>>                 string combinations remain unique.
>>>                
>>>                 3.      UUID
>>>                
>>>                
>>>                
>>>                 Jake
>>>                
>>>                
>>>                
>>>                 Jake Evans, GPEN, GCIH, GWAPT, GCIA, CISSP, CISA,
>>>                 CRISC, CPISA, CPISM| Sr. Security and Compliance
>>>                 Analyst
>>>                
>>>                
>>>                
>>>                 Tripwire
>>>                
>>>                 101 SW Main St., Ste. 1500
>>>                 Portland, OR 97204
>>>                
>>>                 Direct: 503.276.7658
>>>                
>>>                 Main: 503.276.7500
>>>                
>>>                
>>>                
>>>                 TRIPWIRE |TAKE CONTROL.
>>>                 www.tripwire.com
>>>                
>>>                
>>>                
>>>                
>>>                 From: Wunder, John A. [mailto:[hidden email]]
>>>                 Sent: Wednesday, October 03, 2012 11:56 AM
>>>                 To: [hidden email]
>>>                 Subject: [CEE-DISCUSSION-LIST] Unique Event ID
>>>                 (RecordId)
>>>                
>>>                
>>>                
>>>                
>>>                 I wanted to restart this discussion and move it to its
>>>                 own thread. For reference, this is the discussion
>>>                 about whether CEE should have a field where producers
>>>                 can (or must) put a unique identifier for individual
>>>                 events.
>>>                
>>>                
>>>                
>>>                 To restart some of the topics:
>>>                
>>>                
>>>                
>>>                 1.      Optional vs. required. People seemed to be
>>>                 leaning towards making the field optional to ease the
>>>                 implementation burden for event producers. Does anyone
>>>                 disagree with this? The main concern of course is that
>>>                 this leads to less compatibility among producers so
>>>                 that consumers can¹t rely on consistency. In other
>>>                 words, is the field even still useful if consumers
>>>                 can¹t count on it being there?
>>>                
>>>                 2.      Do we need to specify a format, or can we just
>>>                 give a field a title and tell producers to stick
>>>                 something unique in it? Upsides of not specifying a
>>>                 particular format is the ease of adoption, downside is
>>>                 that consumers would have to expect basically anything
>>>                 in that field and some producers might not succeed at
>>>                 making it truly unique.
>>>                
>>>                 3.      If we do specify a format, what is that
>>>                 format?
>>>                
>>>                 a.      UUID?
>>>                
>>>                 b.     Hash
>>>                
>>>                 c.      Other?
>>>                
>>>                
>>>                
>>>                 My personal opinion is that for ease of implementation
>>>                 and simplicity we have an optional field that, if
>>>                 populated, MUST be populated with a UUID.
>>>                
>>>                
>>>                
>>>                 In particular it would be good to hear from event
>>>                 producers on this. Does anyone from the lumberjack
>>>                 team want to weigh in? Or any other people developing
>>>                 software that will produce CEE events?
>>>                
>>>                
>>>                
>>>                 Lastly, what do people think about scheduling a chat
>>>                 on IRC about topics like this? E-mail is a pretty
>>>                 disjointed way of doing this and a telecom is tough to
>>>                 organize, but maybe a 1Ž2 chat on IRC would let people
>>>                 tune in but continue their regular work?
>>>                
>>>                
>>>                
>>>                 Thanks,
>>>                
>>>                 John
>>>                
>>>                
>>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Unique Event ID (RecordId)

Fletcher, Boyd C IV Mr CIV OSD
In reply to this post by dpal

+1 For UUID and being required.


From: Dmitri Pal <[hidden email]>
Organization: Red Hat
Reply-To: "[hidden email]" <[hidden email]>
Date: Wednesday, October 3, 2012 3:11 PM
To: "[hidden email]" <[hidden email]>
Subject: Re: [CEE-DISCUSSION-LIST] Unique Event ID (RecordId)

On 10/03/2012 02:55 PM, Wunder, John A. wrote:

I wanted to restart this discussion and move it to its own thread. For reference, this is the discussion about whether CEE should have a field where producers can (or must) put a unique identifier for individual events.

 

To restart some of the topics:

 

1.       Optional vs. required. People seemed to be leaning towards making the field optional to ease the implementation burden for event producers. Does anyone disagree with this? The main concern of course is that this leads to less compatibility among producers so that consumers can’t rely on consistency. In other words, is the field even still useful if consumers can’t count on it being there?

2.       Do we need to specify a format, or can we just give a field a title and tell producers to stick something unique in it? Upsides of not specifying a particular format is the ease of adoption, downside is that consumers would have to expect basically anything in that field and some producers might not succeed at making it truly unique.

3.       If we do specify a format, what is that format?

a.       UUID?

b.      Hash

c.       Other?

 

My personal opinion is that for ease of implementation and simplicity we have an optional field that, if populated, MUST be populated with a UUID.

 

In particular it would be good to hear from event producers on this. Does anyone from the lumberjack team want to weigh in? Or any other people developing software that will produce CEE events?

 

Lastly, what do people think about scheduling a chat on IRC about topics like this? E-mail is a pretty disjointed way of doing this and a telecom is tough to organize, but maybe a 1Ž2 chat on IRC would let people tune in but continue their regular work?

 

Thanks,

John


IMO it would be nice to augment it with optional vendor ID (registered uuid or string).
This way vendor ID can be used to lookup some public repo where vendors will optionally publish XML schema for the event vendor creates. This schema in turn would be useful for processing the event on the client side.

2c.

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
<a class="moz-txt-link-abbreviated" href="blockedhttp://www.redhat.com/carveoutcosts/">www.redhat.com/carveoutcosts/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Unique Event ID (RecordId)

Fletcher, Boyd C IV Mr CIV OSD
In reply to this post by Jake Evans
  1. Why? This is  already the case on Windows and has been for over 12 years. Applications should be auditing/logging to the o/s centralized logging system (like the eventing system in windows) so its the job of the o/s to deal with maintaining collection. The linux/unix approach of each application maintaining its own logs is archaic, doesn't scale, and needs to be replaced with a  centralized (within the system) approach. 
  2. I think vendor information should be stored in other parts of the event structure not in the record ID.



From: Jake Evans <[hidden email]>
Reply-To: Jake Evans <[hidden email]>
Date: Wednesday, October 3, 2012 3:26 PM
To: "[hidden email]" <[hidden email]>
Subject: Re: [CEE-DISCUSSION-LIST] Unique Event ID (RecordId)

Here are my answers/thoughts on this:

1.       Optional  seems to be the way to go.  Although I’d like to say “Mandatory,” I think some software producers will back off because of the implied level of additional overhead in maintaining collections of unique events will bring.

2.       For people who do decide to implement Unique Event ID, I do think a simple set of guidelines by which vendors name their events should be followed.  Perhaps something like: UNIQUE_VENDOR_STRING:PRODUCT:VERSION:EVENT_ID.  UNIQUE_VENDOR_STRINGs could be placed on a publically available site (CEE site) where new vendors could verify the uniqueness of the string they’d like to use.  From there, it would be the responsibility of vendors to make sure PRODUCT, VERSION and EVENT_ID string combinations remain unique.

3.       UUID

 

Jake

 

Jake Evans, GPEN, GCIH, GWAPT, GCIA, CISSP, CISA, CRISC, CPISA, CPISM | Sr. Security and Compliance Analyst

 

Tripwire

101 SW Main St., Ste. 1500
Portland, OR 97204  

Direct: 503.276.7658

Main: 503.276.7500

 

TRIPWIRE | TAKE CONTROL.
<a href="blockedhttp://www.tripwire.com/">www.tripwire.com

 

From: Wunder, John A. [[hidden email]]
Sent: Wednesday, October 03, 2012 11:56 AM
To: [hidden email]
Subject: [CEE-DISCUSSION-LIST] Unique Event ID (RecordId)

 

I wanted to restart this discussion and move it to its own thread. For reference, this is the discussion about whether CEE should have a field where producers can (or must) put a unique identifier for individual events.

 

To restart some of the topics:

 

1.       Optional vs. required. People seemed to be leaning towards making the field optional to ease the implementation burden for event producers. Does anyone disagree with this? The main concern of course is that this leads to less compatibility among producers so that consumers can’t rely on consistency. In other words, is the field even still useful if consumers can’t count on it being there?

2.       Do we need to specify a format, or can we just give a field a title and tell producers to stick something unique in it? Upsides of not specifying a particular format is the ease of adoption, downside is that consumers would have to expect basically anything in that field and some producers might not succeed at making it truly unique.

3.       If we do specify a format, what is that format?

a.       UUID?

b.      Hash

c.       Other?

 

My personal opinion is that for ease of implementation and simplicity we have an optional field that, if populated, MUST be populated with a UUID.

 

In particular it would be good to hear from event producers on this. Does anyone from the lumberjack team want to weigh in? Or any other people developing software that will produce CEE events?

 

Lastly, what do people think about scheduling a chat on IRC about topics like this? E-mail is a pretty disjointed way of doing this and a telecom is tough to organize, but maybe a 1Ž2 chat on IRC would let people tune in but continue their regular work?

 

Thanks,

John

123
Loading...