CEE Field List

[Raffael Marty-3]

We have been busy working on the Common Event Syntax. As part of the  
syntax, we came up with a list of field names that should be used in  
log messages. A common name for fields helps cross-correlate log  
records between different products and log files. The list of field  
names is independent of the exact syntax that is used to write the log  
messages or the transport/format. Whether the data is written in an  
XML file, a flat text file, a CSV file, or using a binary encoding, a  
common set of field names helps cross-correlating these log messages.

A sample message that uses these field names could look as follows:

Feb 22 08:57:21 ram sudo[11033]: src_ip=10.2.2.1 dest_host=ram
name=what an event dvc_location=home

Here are some specific questions we would like to pose to the
community:

- is the list more or less complete?
- are the descriptions meaningful? where do we need to tighten them up?
- do the data types make sense?
- how should we handle lists of values? For example, an event might  
talk about multiple ports.
- any other comments?






--
   Raffael Marty
   Chief Security Strategist                           @ Splunk>
   Security Visualization: http://secviz.org       raffy.ch/blog

[Andrew Hay-2]

The only other one I can think of would be a field for OSVDB entries but
I haven't even finished convincing myself that's a good idea yet :)

Other than that, the list looks great! The one thing I thought would be
left out was start/end-time but I noticed it was in there (which will
make some of the vendors, for example Juniper, happy). Good work!

Andrew Hay
Integration Services Program Manager
Q1 Labs Inc - The Nexus of Security and Networking
Office: [phone] x124
Fax: [phone]
andrew.hay@... | www.q1labs.com

-----Original Message-----
From: Raffael Marty [mailto:rmarty@...]
Sent: Thursday, March 06, 2008 3:12 PM
To: CEE-DISCUSSION-LIST@...
Subject: [CEE-DISCUSSION-LIST] CEE Field List


We have been busy working on the Common Event Syntax. As part of the  
syntax, we came up with a list of field names that should be used in  
log messages. A common name for fields helps cross-correlate log  
records between different products and log files. The list of field  
names is independent of the exact syntax that is used to write the log  
messages or the transport/format. Whether the data is written in an  
XML file, a flat text file, a CSV file, or using a binary encoding, a  
common set of field names helps cross-correlating these log messages.

A sample message that uses these field names could look as follows:

Feb 22 08:57:21 ram sudo[11033]: src_ip=10.2.2.1 dest_host=ram name=what
an event dvc_location=home

Here are some specific questions we would like to pose to the
community:

- is the list more or less complete?
- are the descriptions meaningful? where do we need to tighten them up?
- do the data types make sense?
- how should we handle lists of values? For example, an event might  
talk about multiple ports.
- any other comments?

[Eric Fitzgerald]

I think you are going in a slightly wrong direction.

I also am confused.  I thought that this mailing list was the working group but I continually see working group products coming from off-list; I feel excluded.

Here is a radical proposal.  Instead of name value pairs, use triplets.

It occurs to me that there are two interesting pieces of "name/type" metadata, the representational or syntactic type and the semantic type, for lack of better terms.

The representational type defines the syntax of the information that follows, e.g. ipv4 address, string, integer, timestamp, float, whatever.

The semantic type defines the usage of the data in the context of the event record, e.g. source address, user name, source port, detection time, event duration (ms), etc.

Taken together these map to a more complete story.

Separately they are also useful.  One might choose to correlate all ipv4 addresses regardless of whether they are source or destination addresses.  One might choose to store them in a manner that is most efficient based on the representational type (timestamps as 64-bit numerics vs. variable-length strings, etc.).  It also allows for semantic types that might have different representational types, e.g. an ipv6 packet teredo tunneled over an ipv4 network would cause events on intervening devices that would differ in representational type (ipv6addr vs. ipv4addr) but would be the same in semantic type (srcaddr).  Clever manipulation might even provide for correlation in such a case.

Also: an event record processing device might choose to only operate on representational types if it performs storage and/or forwarding functions but does not perform analysis functions.

This does not invalidate your principle of transport/log file format independence although you might require some syntactic sugar for non-delimited formats, e.g. ipv4addr_srcaddr=192.168.0.1

Best regards,
Eric

Eric Fitzgerald
Microsoft Corporation

-----Original Message-----
From: Raffael Marty [mailto:rmarty@...]
Sent: Thursday, March 06, 2008 11:12 AM
To: CEE-DISCUSSION-LIST@...
Subject: [CEE-DISCUSSION-LIST] CEE Field List

We have been busy working on the Common Event Syntax. As part of the syntax, we came up with a list of field names that should be used in log messages. A common name for fields helps cross-correlate log records between different products and log files. The list of field names is independent of the exact syntax that is used to write the log messages or the transport/format. Whether the data is written in an XML file, a flat text file, a CSV file, or using a binary encoding, a common set of field names helps cross-correlating these log messages.

A sample message that uses these field names could look as follows:

Feb 22 08:57:21 ram sudo[11033]: src_ip=10.2.2.1 dest_host=ram name=what an event dvc_location=home

Here are some specific questions we would like to pose to the
community:

- is the list more or less complete?
- are the descriptions meaningful? where do we need to tighten them up?
- do the data types make sense?
- how should we handle lists of values? For example, an event might talk about multiple ports.
- any other comments?

[Andrew Hay-2]

I'll second Eric's exclusion comment.

Andrew Hay
Integration Services Program Manager
Q1 Labs Inc - The Nexus of Security and Networking
Office: [phone] x124
Fax: [phone]
andrew.hay@... | www.q1labs.com

-----Original Message-----
From: Eric Fitzgerald [mailto:Eric.Fitzgerald@...]
Sent: Thursday, March 06, 2008 3:50 PM
To: CEE-DISCUSSION-LIST@...
Subject: Re: [CEE-DISCUSSION-LIST] CEE Field List


I think you are going in a slightly wrong direction.

I also am confused.  I thought that this mailing list was the working
group but I continually see working group products coming from off-list;
I feel excluded.

Here is a radical proposal.  Instead of name value pairs, use triplets.

It occurs to me that there are two interesting pieces of "name/type"
metadata, the representational or syntactic type and the semantic type,
for lack of better terms.

The representational type defines the syntax of the information that
follows, e.g. ipv4 address, string, integer, timestamp, float, whatever.

The semantic type defines the usage of the data in the context of the
event record, e.g. source address, user name, source port, detection
time, event duration (ms), etc.

Taken together these map to a more complete story.

Separately they are also useful.  One might choose to correlate all ipv4
addresses regardless of whether they are source or destination
addresses.  One might choose to store them in a manner that is most
efficient based on the representational type (timestamps as 64-bit
numerics vs. variable-length strings, etc.).  It also allows for
semantic types that might have different representational types, e.g. an
ipv6 packet teredo tunneled over an ipv4 network would cause events on
intervening devices that would differ in representational type (ipv6addr
vs. ipv4addr) but would be the same in semantic type (srcaddr).  Clever
manipulation might even provide for correlation in such a case.

Also: an event record processing device might choose to only operate on
representational types if it performs storage and/or forwarding
functions but does not perform analysis functions.

This does not invalidate your principle of transport/log file format
independence although you might require some syntactic sugar for
non-delimited formats, e.g. ipv4addr_srcaddr=192.168.0.1

Best regards,
Eric

Eric Fitzgerald
Microsoft Corporation

-----Original Message-----
From: Raffael Marty [mailto:rmarty@...]
Sent: Thursday, March 06, 2008 11:12 AM
To: CEE-DISCUSSION-LIST@...
Subject: [CEE-DISCUSSION-LIST] CEE Field List

We have been busy working on the Common Event Syntax. As part of the
syntax, we came up with a list of field names that should be used in log
messages. A common name for fields helps cross-correlate log records
between different products and log files. The list of field names is
independent of the exact syntax that is used to write the log messages
or the transport/format. Whether the data is written in an XML file, a
flat text file, a CSV file, or using a binary encoding, a common set of
field names helps cross-correlating these log messages.

A sample message that uses these field names could look as follows:

Feb 22 08:57:21 ram sudo[11033]: src_ip=10.2.2.1 dest_host=ram name=what
an event dvc_location=home

Here are some specific questions we would like to pose to the
community:

- is the list more or less complete?
- are the descriptions meaningful? where do we need to tighten them up?
- do the data types make sense?
- how should we handle lists of values? For example, an event might talk
about multiple ports.
- any other comments?

[Vicente Aceituno]

Dear All,

Let me break it down:

>Feb 22 08:57:21
This is the date and time when the request is performed. For
consistency if the other fields are formatted something=something
else, this should be
datetime=Feb 22 08:57:21

>ram sudo[11033]:
I assume this is the agent of the request. For consistency

agentid=ram sudo[11033]

If we want the syntax to be universal, perhaps an agentdirectoryid
would be desirable, as other systems might have their own "ram
sudo[110033]"

>src_ip=10.2.2.1
I assume this is the address of the agent. I suppose MAC address (and
other types) can be logged as well, so I suggest:

agentaddress=10.2.2.1

>dest_host=ram
This must be the address of the subject/resource of the request.

I'd write subjectadddress=ram or resourceaddress=ram

If we want the syntax to be universal, perhaps an resourcedirectoryid
or subjectdirectoryid would be desirable, as other systems might have
their own "ram"

>name=what an event
"name" is not very explicit, I suggest:
requesttype=what an event

>dvc_location=home
This must be the id of the subject/resource of the request.

I'd write either subjetcid=ram or resourceid=ram

>  - is the list more or less complete?
I'd like to have a field to store a "serial number", a requestid

The event can be logged by the subject, the object or a third party
(listener). I would add fields than can distinguish that.

If user/password or other credentials are necessary to perform the
request, I would add fields than can express that.

I would add fields for the payload, for a signature and for a hash

>  - do the data types make sense?
What do you mean exactly? For example datetime does not seem
universal, some systems might use more digits for subsecond
divisions...

>  - how should we handle lists of values? For example, an event might
>  talk about multiple ports.
That should go in the payload.

>  - any other comments?
The request can be successful, fail or an error can happen. I would
add a field for the result of the request, and a separate field for
the associated message.

I feel excluded too, BTW

Best Regards

Vicente

[Vicente Aceituno]

Oops! I didn't realize there was an attached csv file

On 3/6/08, Vicente Aceituno <vac@...> wrote:

> Dear All,
>
>  Let me break it down:
>
>
>  >Feb 22 08:57:21
>
> This is the date and time when the request is performed. For
>  consistency if the other fields are formatted something=something
>  else, this should be
>  datetime=Feb 22 08:57:21
>
>  >ram sudo[11033]:
>  I assume this is the agent of the request. For consistency
>
>  agentid=ram sudo[11033]
>
>  If we want the syntax to be universal, perhaps an agentdirectoryid
>  would be desirable, as other systems might have their own "ram
>  sudo[110033]"
>
>
>  >src_ip=10.2.2.1
>
> I assume this is the address of the agent. I suppose MAC address (and
>  other types) can be logged as well, so I suggest:
>
>  agentaddress=10.2.2.1
>
>  >dest_host=ram
>  This must be the address of the subject/resource of the request.
>
>  I'd write subjectadddress=ram or resourceaddress=ram
>
>  If we want the syntax to be universal, perhaps an resourcedirectoryid
>  or subjectdirectoryid would be desirable, as other systems might have
>  their own "ram"
>
>  >name=what an event
>  "name" is not very explicit, I suggest:
>  requesttype=what an event
>
>  >dvc_location=home
>  This must be the id of the subject/resource of the request.
>
>  I'd write either subjetcid=ram or resourceid=ram
>
>
>  >  - is the list more or less complete?
>
> I'd like to have a field to store a "serial number", a requestid
>
>  The event can be logged by the subject, the object or a third party
>  (listener). I would add fields than can distinguish that.
>
>  If user/password or other credentials are necessary to perform the
>  request, I would add fields than can express that.
>
>  I would add fields for the payload, for a signature and for a hash
>
>
>  >  - do the data types make sense?
>
> What do you mean exactly? For example datetime does not seem
>  universal, some systems might use more digits for subsecond
>  divisions...
>
>
>  >  - how should we handle lists of values? For example, an event might
>  >  talk about multiple ports.
>
> That should go in the payload.
>
>  >  - any other comments?
>  The request can be successful, fail or an error can happen. I would
>  add a field for the result of the request, and a separate field for
>  the associated message.
>
>  I feel excluded too, BTW
>
>  Best Regards
>
>
>  Vicente
>

[Tina Bird]

Quoting Andrew Hay <andrew.hay@...>:

> I'll second Eric's exclusion comment.

Guess that makes me #3, unless there are more to follow...

[David Corlette]

Hi Raffy,

So, we've been struggling with this very same issue for years, because in our product what we do is try to map vendor's event data into our standard event structure. I will point out that the tags and semantic meaning that vendors choose for their data seems to be essentially random. ;-)

The latest work we've done in this area is based on some of the concepts within XDAS.  For example, we are now treating an "event" as an interaction between three things: an initiator, an originator, and a target. The initiator is the "thing(s)" that caused the event to occur, the originator is the "thing(s)" that detected the event and reported it, and the target is the "thing(s)" affected by the event.

What this leads to is four fundamental classes of data within an event structure, e.g. the initiator, originator, target, and action.

Within each class of data there are various attributes that can be set. For example, the initiator could be a networked asset, a service (e.g. application), or a user. The target could be an asset, user, data object, service, group, etc. The action has a name, time, severity, etc.  But note that an "asset" is always the same type of thing, so for example both the initiator, target, and originator assets will have associated IPs, hostnames, and so forth.

The upshot of all this is that it's really nice to represent each of these interacting components as an object with attributes, but if you are going to "flatten" it out, at least you should have a common prefix to allow you to group the tags together.  So for example I would change your tags as follows:

src_host        --> init_sys_name
src_ipv6        --> init_sys_ipv6
src_ip           --> init_sys_ip
src_port        --> init_svc_port
                     --> init_svc_name
src_user_id   --> init_user_id
src_user        --> init_user_name

actedon_user    --> target_user_name
user                  --> (not sure how this is different)
user_group_id   --> target_group_id
user_group       --> target_group_name
user_id             --> target_user_id
database_name  (and)
database_table  (and)
file_name          (and)
file_path           (and)
url                     --> target_data_uri
Express all of the above as URI's and be done with it

action               --> action_name
name                --> (not sure how this is different)
start_time         --> action_start-time
event_id           --> action_vendor-id


dvc_host           --> orig_sys_name
dvc_ip               --> orig_sys_ip


I've found this paradigm to be an extremely useful way of thinking about what an event actually is, and much simpler to remember because of its hierarchical, repetitive structure.  Note also that to incorporate Eric's comments about data typing, you don't actually need to define a data type per element, you can say things like:

*_sys_ip        --> IPv4
*_svc_port    --> integer
*_user_name --> string


Please take a moment to review the XDAS document as some of the work that you are trying to do here was previously accomplished by the OpenGroup committee that worked on that standard, noting of course that a new XDAS is being developed that will incorporate more of the thinking that you see above.


>>> On Thu, Mar 6, 2008 at  2:11 PM, in message
<3A25D597-3262-4E17-AE65-F30AFFDDAD1B@...>, Raffael Marty
<rmarty@...> wrote:

> We have been busy working on the Common Event Syntax. As part of the  
> syntax, we came up with a list of field names that should be used in  
> log messages. A common name for fields helps cross-correlate log  
> records between different products and log files. The list of field  
> names is independent of the exact syntax that is used to write the log  
> messages or the transport/format. Whether the data is written in an  
> XML file, a flat text file, a CSV file, or using a binary encoding, a  
> common set of field names helps cross-correlating these log messages.
>
> A sample message that uses these field names could look as follows:
>
> Feb 22 08:57:21 ram sudo[11033]: src_ip=10.2.2.1 dest_host=ram
> name=what an event dvc_location=home
>
> Here are some specific questions we would like to pose to the
> community:
>
> - is the list more or less complete?
> - are the descriptions meaningful? where do we need to tighten them up?
> - do the data types make sense?
> - how should we handle lists of values? For example, an event might  
> talk about multiple ports.
> - any other comments?

[Vicente Aceituno]

David,

On 3/6/08, David Corlette <DCorlette@...> wrote:
>we are now treating an "event" as an interaction between three
things: an initiator, an
>originator, and a target. The initiator is the "thing(s)" that caused
the event to occur, the
>originator is the "thing(s)" that detected the event and reported it,
and the target is the
>"thing(s)" affected by the event.
>  What this leads to is four fundamental classes of data within an event structure, e.g. the
>initiator, originator, target, and action.
I agree with this approach. While in my lingo initiator, originator,
target and action are object, subject, logger and request, my previous
comments are perfectly aligned with your view.

I would add to these general concepts that most recorded events are
successful, this is the reason often the result of the action/request
is not recorded. I think a standard should make this explicit. As I
posted before, the action/request can result in success, failure or
error.

Best regards

Vicente

[David Corlette]

Hello Vicente,

XDAS defines a separate Outcome field, which is actually hierarchical as well, so you can have a generic failure or a failure because resources were exhausted, connection was down, etc.  There's also an explicit "denied" which is different from "failed".

You're never supposed to send an XDAS event without defining the proper outcome, although I suppose you could default it to success.

Again, worth reviewing the XDAS if only to avoid doing the same work all over again.  Here's a link:

http://www.opengroup.org/publications/catalog/p441.htm

>>> On Thu, Mar 6, 2008 at  6:38 PM, in message
<d88419760803061538r6390e183ra7a29b18d4d7ec1f@...>, Vicente Aceituno
<vac@...> wrote:

> David,
>
> On 3/6/08, David Corlette <DCorlette@...> wrote:
>>we are now treating an "event" as an interaction between three
> things: an initiator, an
>>originator, and a target. The initiator is the "thing(s)" that caused
> the event to occur, the
>>originator is the "thing(s)" that detected the event and reported it,
> and the target is the
>>"thing(s)" affected by the event.
>>  What this leads to is four fundamental classes of data within an event
> structure, e.g. the
>>initiator, originator, target, and action.
> I agree with this approach. While in my lingo initiator, originator,
> target and action are object, subject, logger and request, my previous
> comments are perfectly aligned with your view.
>
> I would add to these general concepts that most recorded events are
> successful, this is the reason often the result of the action/request
> is not recorded. I think a standard should make this explicit. As I
> posted before, the action/request can result in success, failure or
> error.
>
> Best regards
>
> Vicente

[Eric Fitzgerald]

-----Original Message-----
From: David Corlette [mailto:DCorlette@...]
Sent: Thursday, March 06, 2008 2:35 PM
To: CEE-DISCUSSION-LIST@...
Subject: Re: [CEE-DISCUSSION-LIST] CEE Field List

> So, we've been struggling with this very same issue for years,
> because in our product what we do is try to map vendor's event
> data into our standard event structure. I will point out that
> the tags and semantic meaning that vendors choose for their
> data seems to be essentially random. ;-)

Agreed, but this happens because in the absence of a standard taxonomy, every vendor is forced to start from scratch and create a new taxonomy out of thin air.  Perhaps if we agreed on a standard taxonomy with a fairly rich set of "default" tags we could start to change this...

> The latest work we've done in this area is based on some of the
> concepts within XDAS.  For example, we are now treating an "event"
> as an interaction between three things: an initiator, an
> originator, and a target. The initiator is the "thing(s)" that
> caused the event to occur, the originator is the "thing(s)" that
> detected the event and reported it, and the target is the "thing(s)"
> affected by the event.

> What this leads to is four fundamental classes of data within an
> event structure, e.g. the initiator, originator, target, and action.

I strongly concur with the idea of a [subject (initiator), action, object (target), source (originator)] tuple for each event record, although I prefer different nomenclature.

I also hope that whatever we end up with, adequately captures the "Who what where when how" idea that Tina Bird suggested; ultimately log data is intended for human beings even if logs themselves are not, and too often the events are not rich enough, even with correlation, to answer these simple human questions.

We started the taxonomy discussion several times, failed to reach agreement, and dropped the issue.  Fundamentally today's discussion is about the root taxonomy and I think that we can't have a useful discussion about more complex issues without accidentally re-raising this issue over and over until it's agreed on.

I propose that we try to settle the core issue once and for all.  I am willing to propose a process to achieve that if anyone thinks it would be helpful.

Eric

Eric Fitzgerald
Microsoft Corporation

[Onwubiko, Cyril]

Quoting Andrew Hay, and supporting Tina Bird:

> I'll second Eric's exclusion comment.

This takes the count to #4.

 

Regards,

Cyril

 

 

 

Cyril Onwubiko

 

Networking and Communications Group

Faculty of Computing, Information Systems and Mathematics (CISM)

Kingston University

London, UK

---

From: Tina Bird [mailto:tbird@...]
Sent: Thu 06/03/2008 21:15
To: CEE-DISCUSSION-LIST@...
Subject: Re: [CEE-DISCUSSION-LIST] CEE Field List

Quoting Andrew Hay <andrew.hay@...>:

> I'll second Eric's exclusion comment.

Guess that makes me #3, unless there are more to follow...

This email has been scanned for all viruses by the MessageLabs Email
Security System.

This email has been scanned for all viruses by the MessageLabs Email
Security System.

[David Corlette]

Well heck, if people are feeling so left out, come on over and work on the XDAS update!  As I've stated before, we are in the middle of refreshing the standard to meet more modern conventions. Some members of the CEE group have said that they would like to have CEE use the XDAS record structure as part of the standard (the scope of XDAS is somewhat less than CEE), and we are operating under this assumption. So why not help us nail down a good XDAS standard, as well as monitor the CEE work?

If this is of interest, let me know (off-list) and I'll point you in the right direction.


>>> On Fri, Mar 7, 2008 at  3:52 AM, in message
<0D82E9FA4BFD6545BAAB023FA887678B546B0C@...>,
"Onwubiko, Cyril" <K0327645@...> wrote:

> Quoting Andrew Hay, and supporting Tina Bird:
>
>> I'll second Eric's exclusion comment.
>
> This takes the count to #4.
>  
> Regards,
> Cyril
>  
>  
>  
> Cyril Onwubiko
>  
> Networking and Communications Group
> Faculty of Computing, Information Systems and Mathematics (CISM)
> Kingston University
> London, UK
>
> ________________________________
>
> From: Tina Bird [mailto:tbird@...]
> Sent: Thu 06/03/2008 21:15
> To: CEE-DISCUSSION-LIST@...
> Subject: Re: [CEE-DISCUSSION-LIST] CEE Field List
>
>
>
> Quoting Andrew Hay <andrew.hay@...>:
>
>> I'll second Eric's exclusion comment.
>
> Guess that makes me #3, unless there are more to follow...
>
> This email has been scanned for all viruses by the MessageLabs Email
> Security System.
>
>
>
> This email has been scanned for all viruses by the MessageLabs Email
> Security System.

[Wolfkiel, Joseph]

Here's a list of the fields we determined were necessary to publish for
signature matches (e.g. HIDS/HIPS/AV/IDS).  If I find time, I'll check them
off against the XDAS list.

The other set of fields I didn't include are the ones describing the sensor
as a networked asset -- e.g. who owns it, where is it (geolocation), what
classification network is it on, where is it (logically) in the network, who
is its CERT, etc.

Lt Col Joseph L. Wolfkiel

Director, Computer Network Defense Research & Technology (CND R&T) Program
Management Office

9800 Savage Rd Ste 6767
Ft Meade, MD 20755-6767
Commercial 410-854-5401 DSN 244-5401
Fax [phone]


-----Original Message-----
From: David Corlette [mailto:DCorlette@...]
Sent: Friday, March 07, 2008 7:34 AM
To: CEE-DISCUSSION-LIST@...
Subject: Re: [CEE-DISCUSSION-LIST] CEE Field List


Well heck, if people are feeling so left out, come on over and work on the
XDAS update!  As I've stated before, we are in the middle of refreshing the
standard to meet more modern conventions. Some members of the CEE group have
said that they would like to have CEE use the XDAS record structure as part
of the standard (the scope of XDAS is somewhat less than CEE), and we are
operating under this assumption. So why not help us nail down a good XDAS
standard, as well as monitor the CEE work?

If this is of interest, let me know (off-list) and I'll point you in the
right direction.


>>> On Fri, Mar 7, 2008 at  3:52 AM, in message
<0D82E9FA4BFD6545BAAB023FA887678B546B0C@...>,
"Onwubiko, Cyril" <K0327645@...> wrote:

> Quoting Andrew Hay, and supporting Tina Bird:
>
>> I'll second Eric's exclusion comment.
>
> This takes the count to #4.
>  
> Regards,
> Cyril
>  
>  
>  
> Cyril Onwubiko
>  
> Networking and Communications Group
> Faculty of Computing, Information Systems and Mathematics (CISM)
> Kingston University
> London, UK
>
> ________________________________
>
> From: Tina Bird [mailto:tbird@...]
> Sent: Thu 06/03/2008 21:15
> To: CEE-DISCUSSION-LIST@...
> Subject: Re: [CEE-DISCUSSION-LIST] CEE Field List
>
>
>
> Quoting Andrew Hay <andrew.hay@...>:
>
>> I'll second Eric's exclusion comment.
>
> Guess that makes me #3, unless there are more to follow...
>
> This email has been scanned for all viruses by the MessageLabs Email
> Security System.
>
>
>
> This email has been scanned for all viruses by the MessageLabs Email
> Security System.

[Raffael Marty-3]

Sorry for addressing this so late.

I had a few conversations with people from the list and I think there  
are some mis-understandings. Let me address the concern of feeling  
excluded:

When I published the field list yesterday and when Anton posted the  
logging recommendations, they were an attempt to solicit input from  
everybody. These lists are in no way a standard or any form of final  
product. The field list in specific was an attempt to get a draft  
field list to you and see whether it is useful or not. But again, I  
did not post something that is done. I built the list on things I knew  
from my past and feedback I gathered from other vendors and people  
from the logging community. Now we need input from all of you to make  
this a list that can be used as a standard and then we can start  
driving adoption.

I hope this helps

   -raffy

[Maloof, Michael]

>>I propose that we try to settle the core issue once and for all.  I am willing to propose a process to achieve that if anyone thinks it would be helpful.

Eric, I'd very interested to hear more about the process you'd propose.

--Michael
TriGeo

-----Original Message-----
From: Eric Fitzgerald [mailto:Eric.Fitzgerald@...]
Sent: Thursday, March 06, 2008 3:52 PM
To: CEE-DISCUSSION-LIST@...
Subject: Re: [CEE-DISCUSSION-LIST] CEE Field List

-----Original Message-----
From: David Corlette [mailto:DCorlette@...]
Sent: Thursday, March 06, 2008 2:35 PM
To: CEE-DISCUSSION-LIST@...
Subject: Re: [CEE-DISCUSSION-LIST] CEE Field List

> So, we've been struggling with this very same issue for years,
> because in our product what we do is try to map vendor's event
> data into our standard event structure. I will point out that
> the tags and semantic meaning that vendors choose for their
> data seems to be essentially random. ;-)

Agreed, but this happens because in the absence of a standard taxonomy, every vendor is forced to start from scratch and create a new taxonomy out of thin air.  Perhaps if we agreed on a standard taxonomy with a fairly rich set of "default" tags we could start to change this...

> The latest work we've done in this area is based on some of the
> concepts within XDAS.  For example, we are now treating an "event"
> as an interaction between three things: an initiator, an
> originator, and a target. The initiator is the "thing(s)" that
> caused the event to occur, the originator is the "thing(s)" that
> detected the event and reported it, and the target is the "thing(s)"
> affected by the event.

> What this leads to is four fundamental classes of data within an
> event structure, e.g. the initiator, originator, target, and action.

I strongly concur with the idea of a [subject (initiator), action, object (target), source (originator)] tuple for each event record, although I prefer different nomenclature.

I also hope that whatever we end up with, adequately captures the "Who what where when how" idea that Tina Bird suggested; ultimately log data is intended for human beings even if logs themselves are not, and too often the events are not rich enough, even with correlation, to answer these simple human questions.

We started the taxonomy discussion several times, failed to reach agreement, and dropped the issue.  Fundamentally today's discussion is about the root taxonomy and I think that we can't have a useful discussion about more complex issues without accidentally re-raising this issue over and over until it's agreed on.

I propose that we try to settle the core issue once and for all.  I am willing to propose a process to achieve that if anyone thinks it would be helpful.

Eric

Eric Fitzgerald
Microsoft Corporation