CEE charter & Definitions

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

CEE charter & Definitions

Rainer Gerhards
Hi list,

As I have already written, I have recently joined the CEE mailing list
after the "definition question" loganalysis list post. I sent a number
of proposals for potential definitions. After re-reading many of the
post on the CEE list, I noticed that most of us are talking about the
same terms and ideas, but from different level of details and from
different background.

After I noticed that, I began to search for a CEE charter. I have to
admit I did not yet find a sufficiently clear definition of what CEE
itself is all about.

This document provides a good starting point:

http://cee.mitre.org/docs/Common_Event_Expression_White_Paper_June_2008.
pdf

but is still missing the clarity of what is in scope and what not.

The home page also has a brief (but good) mission statement:

"CEE standardizes the way computer events are described, logged, and
exchanged."

If I merge these two, I see that the CEE effort is

a) limited to the domain of computer systems [so why was that discussed
just recently?]
b) finds an upper bound at "We note that CEE focuses on individual
device-generated events, not on whole security incidents." (in section 2
of above paper) [why? CEE does not apply to supersets?]
c) applies to "the industry" (multiple findings) [who is "the
industry"?]
d) in some places "practical" is use as a limit of CEE [what does
"practical" in CEE mean?]

It may be my inability to find the proper charter statement, but from
what I see it looks like the discussion provides room for so many points
of view because there is no clear definition of what are the limits of
CEE. Also, the current documents describe the scope of the effort in
terms which shall be defined by the effort itself (and as such are not
well-defined at the time they are used) - obviously something that is
right now being addressed.

I propose that before doing any detail definitions, CEE should first
define its charter in precise terms and with clear bounds.

For example, my view of logging is very detailed, probably too detailed
for a number of applications. My definitions have the advantage that, so
far, anything that happens inside the logging world can be described by
them. They have the vast disadvantage, however, that they are very
abstract and may confuse others or require too much effort to understand
for "practical" purposes (e.g. for coding). There were a number of less
abstracted definitions given. I could agree to almost all of them. They
may provide a much better view for "practical" purposes. This, however,
comes at the price that they cannot describe a small set of unusual or
complex situations. IMHO it depends much on the audience which
definition is to prefer.

So, in my view, I would find it extremely useful if we define

a) bounds for what CEE intends to cover
b) intended audience

The broader a) is defined, the more generic definitions are needed.

Under a), I would expect answers to questions like:

- what is the domain of this work (electronic system was given)?
- is the domain any further restricted (e.g. compliance applications)?
- what is a system (e.g. does CEE care about transitive relationships)?
- what is "the industry"?

Under b), I would expect to see if CEE tries to address designers,
coders and end-users with a single set of definitions - or if it
provides different definitions for different needs.

It would also be useful if CEE could define deliverables and goals that
must be reached to make the effort successful (e.g. we need to have
CEE-aware applications from at least the 80% of the top-10 vendors from
the x industry - or: minimal level x of CEE compliance should be made
mandatory for government bids on IT systems). What needs to be done to
reach these goals? Are they realistic? That boils down to "why do you
think CEE will do any better than the other - failed - approaches listed
in the CEE doc?". That would also be a motivation for any serious work
done on CEE (and I see that it has the potential to do more than its
predecessors...).

One final thought: reading the CEE docs creates the impression that it
aims at very broad coverage (but I cannot quote a single line where it
is clearly stated). It also claims to be "practical" (which created the
impression of "not being theoretical, with theoretical = abstract in
me). However, broad scope and "practical" definitions do not go well
together. (Because a non-abstract definition needs to limit itself to
limited representatives of a broad entity.) It may be wise to drop
either of these two requirements OR it would be useful to use a layered
definition tree, with some very abstract definitions at the bottom of
the pyramid (quoting Cyril) and with sufficiently well approximations at
higher levels. That, of course, is much more work (but probably also
much more useful).

Let me close with my appreciation for the work done so far with CEE.
This is useful and well done. I hope that my thoughts are useful for the
overall progress of this effort.

Rainer
Reply | Threaded
Open this post in threaded view
|

Re: CEE charter & Definitions

David Corlette
Hi Rainer,

It is my understanding that MITRE is currently in the process of creating an advisor board that would handle this type of definition.  The definition work we've been doing is intended to provide inputs to that group.

Incidentally if you feel you could effectively contribute to the advisory board, there's some sort of nomination process that occurs.  I'm sure once the initial board is set up Bill will send out some clarifications to the list.

>>> On Mon, Aug 4, 2008 at  7:11 AM, in message
<[hidden email]>, Rainer
Gerhards <[hidden email]> wrote:

> Hi list,
>
> As I have already written, I have recently joined the CEE mailing list
> after the "definition question" loganalysis list post. I sent a number
> of proposals for potential definitions. After re-reading many of the
> post on the CEE list, I noticed that most of us are talking about the
> same terms and ideas, but from different level of details and from
> different background.
>
> After I noticed that, I began to search for a CEE charter. I have to
> admit I did not yet find a sufficiently clear definition of what CEE
> itself is all about.
>
> This document provides a good starting point:
>
> http://cee.mitre.org/docs/Common_Event_Expression_White_Paper_June_2008.
> pdf
>
> but is still missing the clarity of what is in scope and what not.
>
> The home page also has a brief (but good) mission statement:
>
> "CEE standardizes the way computer events are described, logged, and
> exchanged."
>
> If I merge these two, I see that the CEE effort is
>
> a) limited to the domain of computer systems [so why was that discussed
> just recently?]
> b) finds an upper bound at "We note that CEE focuses on individual
> device-generated events, not on whole security incidents." (in section 2
> of above paper) [why? CEE does not apply to supersets?]
> c) applies to "the industry" (multiple findings) [who is "the
> industry"?]
> d) in some places "practical" is use as a limit of CEE [what does
> "practical" in CEE mean?]
>
> It may be my inability to find the proper charter statement, but from
> what I see it looks like the discussion provides room for so many points
> of view because there is no clear definition of what are the limits of
> CEE. Also, the current documents describe the scope of the effort in
> terms which shall be defined by the effort itself (and as such are not
> well-defined at the time they are used) - obviously something that is
> right now being addressed.
>
> I propose that before doing any detail definitions, CEE should first
> define its charter in precise terms and with clear bounds.
>
> For example, my view of logging is very detailed, probably too detailed
> for a number of applications. My definitions have the advantage that, so
> far, anything that happens inside the logging world can be described by
> them. They have the vast disadvantage, however, that they are very
> abstract and may confuse others or require too much effort to understand
> for "practical" purposes (e.g. for coding). There were a number of less
> abstracted definitions given. I could agree to almost all of them. They
> may provide a much better view for "practical" purposes. This, however,
> comes at the price that they cannot describe a small set of unusual or
> complex situations. IMHO it depends much on the audience which
> definition is to prefer.
>
> So, in my view, I would find it extremely useful if we define
>
> a) bounds for what CEE intends to cover
> b) intended audience
>
> The broader a) is defined, the more generic definitions are needed.
>
> Under a), I would expect answers to questions like:
>
> - what is the domain of this work (electronic system was given)?
> - is the domain any further restricted (e.g. compliance applications)?
> - what is a system (e.g. does CEE care about transitive relationships)?
> - what is "the industry"?
>
> Under b), I would expect to see if CEE tries to address designers,
> coders and end-users with a single set of definitions - or if it
> provides different definitions for different needs.
>
> It would also be useful if CEE could define deliverables and goals that
> must be reached to make the effort successful (e.g. we need to have
> CEE-aware applications from at least the 80% of the top-10 vendors from
> the x industry - or: minimal level x of CEE compliance should be made
> mandatory for government bids on IT systems). What needs to be done to
> reach these goals? Are they realistic? That boils down to "why do you
> think CEE will do any better than the other - failed - approaches listed
> in the CEE doc?". That would also be a motivation for any serious work
> done on CEE (and I see that it has the potential to do more than its
> predecessors...).
>
> One final thought: reading the CEE docs creates the impression that it
> aims at very broad coverage (but I cannot quote a single line where it
> is clearly stated). It also claims to be "practical" (which created the
> impression of "not being theoretical, with theoretical = abstract in
> me). However, broad scope and "practical" definitions do not go well
> together. (Because a non-abstract definition needs to limit itself to
> limited representatives of a broad entity.) It may be wise to drop
> either of these two requirements OR it would be useful to use a layered
> definition tree, with some very abstract definitions at the bottom of
> the pyramid (quoting Cyril) and with sufficiently well approximations at
> higher levels. That, of course, is much more work (but probably also
> much more useful).
>
> Let me close with my appreciation for the work done so far with CEE.
> This is useful and well done. I hope that my thoughts are useful for the
> overall progress of this effort.
>
> Rainer
Reply | Threaded
Open this post in threaded view
|

Re: CEE charter & Definitions

heinbockel
In reply to this post by Rainer Gerhards

Rainer,

We are currently working on a CEE Charter document
that defines exactly this.

It was due, in part, to this document, why we started
the discussion of the definitions. I disagree with
your point about defining a charter before definitions.
How do we define the scope of CEE without being clear on
definitions... is it a log standard? event standard?
event stream standard?

One of my goals is to bring cohesion to the log
community. So by talking definitions, we force the
community to define the terms that they often use
without a second thought, and provides a basis to
define CEE.

This is important. Initially, we referred to CEE as
a log standard, but as has been pointed out by
many, what about all of the non-event information
that gets stored in logs, is that part of CEE too?
If I were a product marketer, I would say that CEE
standardizes "event expressions". This would avoid
all terminology and scoping problems by defining a
new term, but would cause another issue -- there
would be yet another term related to logs (and thereby
making the log space we're trying to standardize
even more complex).

While I think we are all in agreement that stuff
like debug messages are outside the scope of CEE, the
CEE Charter needs to be very precise on things like
terminology and scope.

I will be working on the draft over the next week
or so. I hoped to have a draft posted to this list
before BlackHat, but have gotten pulled into
another project. Hopefully, I will have a draft
posted next week.


William Heinbockel
The MITRE Corporation


>-----Original Message-----
>From: Rainer Gerhards [mailto:[hidden email]]
>Sent: Monday, 04 August 2008 07:12
>To: cee-discussion-list CEE-Related Discussion
>Subject: [CEE-DISCUSSION-LIST] CEE charter & Definitions
>
>Hi list,
>
>As I have already written, I have recently joined the CEE mailing
>list
>after the "definition question" loganalysis list post. I sent a
>number
>of proposals for potential definitions. After re-reading many of
>the
>post on the CEE list, I noticed that most of us are talking about
>the
>same terms and ideas, but from different level of details and from
>different background.
>
>After I noticed that, I began to search for a CEE charter. I have
>to
>admit I did not yet find a sufficiently clear definition of what
>CEE
>itself is all about.
>
>This document provides a good starting point:
>
>http://cee.mitre.org/docs/Common_Event_Expression_White_Paper_June
>_2008.
>pdf
>
>but is still missing the clarity of what is in scope and what not.
>
>The home page also has a brief (but good) mission statement:
>
>"CEE standardizes the way computer events are described, logged,
>and
>exchanged."
>
>If I merge these two, I see that the CEE effort is
>
>a) limited to the domain of computer systems [so why was that
>discussed
>just recently?]
>b) finds an upper bound at "We note that CEE focuses on individual
>device-generated events, not on whole security incidents." (in
>section 2
>of above paper) [why? CEE does not apply to supersets?]
>c) applies to "the industry" (multiple findings) [who is "the
>industry"?]
>d) in some places "practical" is use as a limit of CEE [what does
>"practical" in CEE mean?]
>
>It may be my inability to find the proper charter statement, but
>from
>what I see it looks like the discussion provides room for so many
>points
>of view because there is no clear definition of what are the
>limits of
>CEE. Also, the current documents describe the scope of the effort
>in
>terms which shall be defined by the effort itself (and as such are
>not
>well-defined at the time they are used) - obviously something that
>is
>right now being addressed.
>
>I propose that before doing any detail definitions, CEE should
>first
>define its charter in precise terms and with clear bounds.
>
>For example, my view of logging is very detailed, probably too
>detailed
>for a number of applications. My definitions have the advantage
>that, so
>far, anything that happens inside the logging world can be
>described by
>them. They have the vast disadvantage, however, that they are very
>abstract and may confuse others or require too much effort to
>understand
>for "practical" purposes (e.g. for coding). There were a number of
>less
>abstracted definitions given. I could agree to almost all of them.
>They
>may provide a much better view for "practical" purposes. This,
>however,
>comes at the price that they cannot describe a small set of
>unusual or
>complex situations. IMHO it depends much on the audience which
>definition is to prefer.
>
>So, in my view, I would find it extremely useful if we define
>
>a) bounds for what CEE intends to cover
>b) intended audience
>
>The broader a) is defined, the more generic definitions are
>needed.
>
>Under a), I would expect answers to questions like:
>
>- what is the domain of this work (electronic system was given)?
>- is the domain any further restricted (e.g. compliance
>applications)?
>- what is a system (e.g. does CEE care about transitive
>relationships)?
>- what is "the industry"?
>
>Under b), I would expect to see if CEE tries to address designers,
>coders and end-users with a single set of definitions - or if it
>provides different definitions for different needs.
>
>It would also be useful if CEE could define deliverables and goals
>that
>must be reached to make the effort successful (e.g. we need to
>have
>CEE-aware applications from at least the 80% of the top-10 vendors
>from
>the x industry - or: minimal level x of CEE compliance should be
>made
>mandatory for government bids on IT systems). What needs to be
>done to
>reach these goals? Are they realistic? That boils down to "why do
>you
>think CEE will do any better than the other - failed - approaches
>listed
>in the CEE doc?". That would also be a motivation for any serious
>work
>done on CEE (and I see that it has the potential to do more than
>its
>predecessors...).
>
>One final thought: reading the CEE docs creates the impression
>that it
>aims at very broad coverage (but I cannot quote a single line
>where it
>is clearly stated). It also claims to be "practical" (which
>created the
>impression of "not being theoretical, with theoretical = abstract
>in
>me). However, broad scope and "practical" definitions do not go
>well
>together. (Because a non-abstract definition needs to limit itself
>to
>limited representatives of a broad entity.) It may be wise to drop
>either of these two requirements OR it would be useful to use a
>layered
>definition tree, with some very abstract definitions at the bottom
>of
>the pyramid (quoting Cyril) and with sufficiently well
>approximations at
>higher levels. That, of course, is much more work (but probably
>also
>much more useful).
>
>Let me close with my appreciation for the work done so far with
>CEE.
>This is useful and well done. I hope that my thoughts are useful
>for the
>overall progress of this effort.
>
>Rainer

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

Re: CEE charter & Definitions

Tina Bird
 
> One of my goals is to bring cohesion to the log
> community. So by talking definitions, we force the
> community to define the terms that they often use
> without a second thought, and provides a basis to
> define CEE.

In response to both Rainer and David -- and in the way of reminding myself
to follow my own advice -- I'd like to remind folks about the Burton Group
use cases, available via David Corlette's collaboration server. Summarizing
(or generalizing) from the use cases, as well as deciding if we have a
"complete enough" list, will presumably make it easier to talk about
definitions, scope of work, etc., and yet despite David's very good
recommendation that we discuss them, none of us (myself included!) have.

I have no idea how much overlap there is going to be between the people
included in the Burton group meeting, and those who will be in Vegas on
Friday, but I'd like to suggest that perhaps those of us in attendance
should review the use cases before we get to the meeting...

cheers -- tbird
Reply | Threaded
Open this post in threaded view
|

Re: CEE charter & Definitions

joël Winteregg-3
In reply to this post by Rainer Gerhards
Hello Rainer,


I totally agree with your point of view. It is hard (at least for me) to
understand the exact focus of CEE. On my side, the following question is
still open http://www.nabble.com/Whitepaper-feedback-td16551029.html and
I think its answer could drive CEE to completely different directions:
A) Ending with a common format, a common taxonomy and logging APIs
B) Ending with a common format, a common taxonomy and format
transformation tools

I really look forward to have some more inputs about CEE "operational
focus" and/or I would also be happy to discuss about it (if possible).

I'm also always surprised to see IDMEF out of scope (too narrow, too IDS
focused, etc.) because every paper I read looks quite close to IDMEF. I
should finish to read XDAS v2 this evening (will also try to test its
Java impl) and I will post, as soon as possible, a short benchmark with
IDMEF to outline their similarities (in terms of data structure).


Thanks again to CEE for their really good initiative !


Regards,


Joel


On Mon, 2008-08-04 at 13:11 +0200, Rainer Gerhards wrote:

> Hi list,
>
> As I have already written, I have recently joined the CEE mailing list
> after the "definition question" loganalysis list post. I sent a number
> of proposals for potential definitions. After re-reading many of the
> post on the CEE list, I noticed that most of us are talking about the
> same terms and ideas, but from different level of details and from
> different background.
>
> After I noticed that, I began to search for a CEE charter. I have to
> admit I did not yet find a sufficiently clear definition of what CEE
> itself is all about.
>
> This document provides a good starting point:
>
> http://cee.mitre.org/docs/Common_Event_Expression_White_Paper_June_2008.
> pdf
>
> but is still missing the clarity of what is in scope and what not.
>
> The home page also has a brief (but good) mission statement:
>
> "CEE standardizes the way computer events are described, logged, and
> exchanged."
>
> If I merge these two, I see that the CEE effort is
>
> a) limited to the domain of computer systems [so why was that discussed
> just recently?]
> b) finds an upper bound at "We note that CEE focuses on individual
> device-generated events, not on whole security incidents." (in section 2
> of above paper) [why? CEE does not apply to supersets?]
> c) applies to "the industry" (multiple findings) [who is "the
> industry"?]
> d) in some places "practical" is use as a limit of CEE [what does
> "practical" in CEE mean?]
>
> It may be my inability to find the proper charter statement, but from
> what I see it looks like the discussion provides room for so many points
> of view because there is no clear definition of what are the limits of
> CEE. Also, the current documents describe the scope of the effort in
> terms which shall be defined by the effort itself (and as such are not
> well-defined at the time they are used) - obviously something that is
> right now being addressed.
>
> I propose that before doing any detail definitions, CEE should first
> define its charter in precise terms and with clear bounds.
>
> For example, my view of logging is very detailed, probably too detailed
> for a number of applications. My definitions have the advantage that, so
> far, anything that happens inside the logging world can be described by
> them. They have the vast disadvantage, however, that they are very
> abstract and may confuse others or require too much effort to understand
> for "practical" purposes (e.g. for coding). There were a number of less
> abstracted definitions given. I could agree to almost all of them. They
> may provide a much better view for "practical" purposes. This, however,
> comes at the price that they cannot describe a small set of unusual or
> complex situations. IMHO it depends much on the audience which
> definition is to prefer.
>
> So, in my view, I would find it extremely useful if we define
>
> a) bounds for what CEE intends to cover
> b) intended audience
>
> The broader a) is defined, the more generic definitions are needed.
>
> Under a), I would expect answers to questions like:
>
> - what is the domain of this work (electronic system was given)?
> - is the domain any further restricted (e.g. compliance applications)?
> - what is a system (e.g. does CEE care about transitive relationships)?
> - what is "the industry"?
>
> Under b), I would expect to see if CEE tries to address designers,
> coders and end-users with a single set of definitions - or if it
> provides different definitions for different needs.
>
> It would also be useful if CEE could define deliverables and goals that
> must be reached to make the effort successful (e.g. we need to have
> CEE-aware applications from at least the 80% of the top-10 vendors from
> the x industry - or: minimal level x of CEE compliance should be made
> mandatory for government bids on IT systems). What needs to be done to
> reach these goals? Are they realistic? That boils down to "why do you
> think CEE will do any better than the other - failed - approaches listed
> in the CEE doc?". That would also be a motivation for any serious work
> done on CEE (and I see that it has the potential to do more than its
> predecessors...).
>
> One final thought: reading the CEE docs creates the impression that it
> aims at very broad coverage (but I cannot quote a single line where it
> is clearly stated). It also claims to be "practical" (which created the
> impression of "not being theoretical, with theoretical = abstract in
> me). However, broad scope and "practical" definitions do not go well
> together. (Because a non-abstract definition needs to limit itself to
> limited representatives of a broad entity.) It may be wise to drop
> either of these two requirements OR it would be useful to use a layered
> definition tree, with some very abstract definitions at the bottom of
> the pyramid (quoting Cyril) and with sufficiently well approximations at
> higher levels. That, of course, is much more work (but probably also
> much more useful).
>
> Let me close with my appreciation for the work done so far with CEE.
> This is useful and well done. I hope that my thoughts are useful for the
> overall progress of this effort.
>
> Rainer
Reply | Threaded
Open this post in threaded view
|

Re: CEE charter & Definitions

David Corlette
Hi Joel,

I believe that we are working on exactly the issues you and Rainer describe, so hopefully we can resolve this soon. I think what's happened thus far is that we have CEE, conceived as a top-down standard (with the corresponding issues of attempting to encompass too much, and therefore becoming complicated), and XDAS, conceived as a bottom-up standard (fairly narrow, compliance, audit event focus, with corresponding difficulty covering unanticipated domains), and these are converging.

Regarding IDMEF - if there are parallels that we could leverage to converge that standard, that would be excellent.  One thing I proposed at one point was the concept of treating CEE as a "wrapper" around other event standards' data.  So one could include an XDAS event as well as an IDMEF message with the appropriate flags.  Not sure if this jibes with your thinking.

And finally - XDAS?  Do you mean OpenXDAS?  Just to be clear, OpenXDAS is the open-source implementation of XDAS.  XDAS itself was originally released as a preliminary specification which AFAICT did not have a "version".  There's now a proposal for a new version, which I supposed might be called XDAS 2.0.  But note that the API specified in the original spec has been removed.  Also note that until we have some consensus, it's unlikely that OpenXDAS will move to implement the new standard.

Hope that clarifies things...


>>> On Mon, Aug 4, 2008 at  4:19 PM, in message
<1217881191.5609.37.camel@localhost>, Joël Winteregg
<[hidden email]> wrote:

> Hello Rainer,
>
>
> I totally agree with your point of view. It is hard (at least for me) to
> understand the exact focus of CEE. On my side, the following question is
> still open http://www.nabble.com/Whitepaper-feedback-td16551029.html and
> I think its answer could drive CEE to completely different directions:
> A) Ending with a common format, a common taxonomy and logging APIs
> B) Ending with a common format, a common taxonomy and format
> transformation tools
>
> I really look forward to have some more inputs about CEE "operational
> focus" and/or I would also be happy to discuss about it (if possible).
>
> I'm also always surprised to see IDMEF out of scope (too narrow, too IDS
> focused, etc.) because every paper I read looks quite close to IDMEF. I
> should finish to read XDAS v2 this evening (will also try to test its
> Java impl) and I will post, as soon as possible, a short benchmark with
> IDMEF to outline their similarities (in terms of data structure).
>
>
> Thanks again to CEE for their really good initiative !
>
>
> Regards,
>
>
> Joel
>
>
> On Mon, 2008-08-04 at 13:11 +0200, Rainer Gerhards wrote:
>> Hi list,
>>
>> As I have already written, I have recently joined the CEE mailing list
>> after the "definition question" loganalysis list post. I sent a number
>> of proposals for potential definitions. After re-reading many of the
>> post on the CEE list, I noticed that most of us are talking about the
>> same terms and ideas, but from different level of details and from
>> different background.
>>
>> After I noticed that, I began to search for a CEE charter. I have to
>> admit I did not yet find a sufficiently clear definition of what CEE
>> itself is all about.
>>
>> This document provides a good starting point:
>>
>> http://cee.mitre.org/docs/Common_Event_Expression_White_Paper_June_2008.
>> pdf
>>
>> but is still missing the clarity of what is in scope and what not.
>>
>> The home page also has a brief (but good) mission statement:
>>
>> "CEE standardizes the way computer events are described, logged, and
>> exchanged."
>>
>> If I merge these two, I see that the CEE effort is
>>
>> a) limited to the domain of computer systems [so why was that discussed
>> just recently?]
>> b) finds an upper bound at "We note that CEE focuses on individual
>> device-generated events, not on whole security incidents." (in section 2
>> of above paper) [why? CEE does not apply to supersets?]
>> c) applies to "the industry" (multiple findings) [who is "the
>> industry"?]
>> d) in some places "practical" is use as a limit of CEE [what does
>> "practical" in CEE mean?]
>>
>> It may be my inability to find the proper charter statement, but from
>> what I see it looks like the discussion provides room for so many points
>> of view because there is no clear definition of what are the limits of
>> CEE. Also, the current documents describe the scope of the effort in
>> terms which shall be defined by the effort itself (and as such are not
>> well-defined at the time they are used) - obviously something that is
>> right now being addressed.
>>
>> I propose that before doing any detail definitions, CEE should first
>> define its charter in precise terms and with clear bounds.
>>
>> For example, my view of logging is very detailed, probably too detailed
>> for a number of applications. My definitions have the advantage that, so
>> far, anything that happens inside the logging world can be described by
>> them. They have the vast disadvantage, however, that they are very
>> abstract and may confuse others or require too much effort to understand
>> for "practical" purposes (e.g. for coding). There were a number of less
>> abstracted definitions given. I could agree to almost all of them. They
>> may provide a much better view for "practical" purposes. This, however,
>> comes at the price that they cannot describe a small set of unusual or
>> complex situations. IMHO it depends much on the audience which
>> definition is to prefer.
>>
>> So, in my view, I would find it extremely useful if we define
>>
>> a) bounds for what CEE intends to cover
>> b) intended audience
>>
>> The broader a) is defined, the more generic definitions are needed.
>>
>> Under a), I would expect answers to questions like:
>>
>> - what is the domain of this work (electronic system was given)?
>> - is the domain any further restricted (e.g. compliance applications)?
>> - what is a system (e.g. does CEE care about transitive relationships)?
>> - what is "the industry"?
>>
>> Under b), I would expect to see if CEE tries to address designers,
>> coders and end-users with a single set of definitions - or if it
>> provides different definitions for different needs.
>>
>> It would also be useful if CEE could define deliverables and goals that
>> must be reached to make the effort successful (e.g. we need to have
>> CEE-aware applications from at least the 80% of the top-10 vendors from
>> the x industry - or: minimal level x of CEE compliance should be made
>> mandatory for government bids on IT systems). What needs to be done to
>> reach these goals? Are they realistic? That boils down to "why do you
>> think CEE will do any better than the other - failed - approaches listed
>> in the CEE doc?". That would also be a motivation for any serious work
>> done on CEE (and I see that it has the potential to do more than its
>> predecessors...).
>>
>> One final thought: reading the CEE docs creates the impression that it
>> aims at very broad coverage (but I cannot quote a single line where it
>> is clearly stated). It also claims to be "practical" (which created the
>> impression of "not being theoretical, with theoretical = abstract in
>> me). However, broad scope and "practical" definitions do not go well
>> together. (Because a non-abstract definition needs to limit itself to
>> limited representatives of a broad entity.) It may be wise to drop
>> either of these two requirements OR it would be useful to use a layered
>> definition tree, with some very abstract definitions at the bottom of
>> the pyramid (quoting Cyril) and with sufficiently well approximations at
>> higher levels. That, of course, is much more work (but probably also
>> much more useful).
>>
>> Let me close with my appreciation for the work done so far with CEE.
>> This is useful and well done. I hope that my thoughts are useful for the
>> overall progress of this effort.
>>
>> Rainer
Reply | Threaded
Open this post in threaded view
|

Re: CEE charter & Definitions

joël Winteregg-3
Hi David,

Thanks for your email.

>
> I believe that we are working on exactly the issues you and Rainer describe, so hopefully we can resolve this soon.

Cool, that sounds great ! Let me know if I can help...

>
> Regarding IDMEF - if there are parallels that we could leverage to
> converge that standard, that would be excellent.  One thing I proposed
> at one point was the concept of treating CEE as a "wrapper" around
> other event standards' data.  So one could include an XDAS event as
> well as an IDMEF message with the appropriate flags.  Not sure if this
> jibes with your thinking.
>

I understand what you mean and I like the concept of "wrapper". But the
danger with wrappers is that you ends with having to understand/know
many standards...

> And finally - XDAS?  Do you mean OpenXDAS?

Yes, I'm reading XDAS Version 2 (I got it on http://12.193.84.139:8080)
and I wanted to try the following stuff:
 http://svn.sourceforge.net/viewvc/openxdas/trunk/openxdas/java/

> Hope that clarifies things...
>

So, if I follow you, sources on openxdas SVN are not related to the
draft I'm reading ?


Joël

>
> >>> On Mon, Aug 4, 2008 at  4:19 PM, in message
> <1217881191.5609.37.camel@localhost>, Joël Winteregg
> <[hidden email]> wrote:
> > Hello Rainer,
> >
> >
> > I totally agree with your point of view. It is hard (at least for me) to
> > understand the exact focus of CEE. On my side, the following question is
> > still open http://www.nabble.com/Whitepaper-feedback-td16551029.html and
> > I think its answer could drive CEE to completely different directions:
> > A) Ending with a common format, a common taxonomy and logging APIs
> > B) Ending with a common format, a common taxonomy and format
> > transformation tools
> >
> > I really look forward to have some more inputs about CEE "operational
> > focus" and/or I would also be happy to discuss about it (if possible).
> >
> > I'm also always surprised to see IDMEF out of scope (too narrow, too IDS
> > focused, etc.) because every paper I read looks quite close to IDMEF. I
> > should finish to read XDAS v2 this evening (will also try to test its
> > Java impl) and I will post, as soon as possible, a short benchmark with
> > IDMEF to outline their similarities (in terms of data structure).
> >
> >
> > Thanks again to CEE for their really good initiative !
> >
> >
> > Regards,
> >
> >
> > Joel
> >
> >
> > On Mon, 2008-08-04 at 13:11 +0200, Rainer Gerhards wrote:
> >> Hi list,
> >>
> >> As I have already written, I have recently joined the CEE mailing list
> >> after the "definition question" loganalysis list post. I sent a number
> >> of proposals for potential definitions. After re-reading many of the
> >> post on the CEE list, I noticed that most of us are talking about the
> >> same terms and ideas, but from different level of details and from
> >> different background.
> >>
> >> After I noticed that, I began to search for a CEE charter. I have to
> >> admit I did not yet find a sufficiently clear definition of what CEE
> >> itself is all about.
> >>
> >> This document provides a good starting point:
> >>
> >> http://cee.mitre.org/docs/Common_Event_Expression_White_Paper_June_2008.
> >> pdf
> >>
> >> but is still missing the clarity of what is in scope and what not.
> >>
> >> The home page also has a brief (but good) mission statement:
> >>
> >> "CEE standardizes the way computer events are described, logged, and
> >> exchanged."
> >>
> >> If I merge these two, I see that the CEE effort is
> >>
> >> a) limited to the domain of computer systems [so why was that discussed
> >> just recently?]
> >> b) finds an upper bound at "We note that CEE focuses on individual
> >> device-generated events, not on whole security incidents." (in section 2
> >> of above paper) [why? CEE does not apply to supersets?]
> >> c) applies to "the industry" (multiple findings) [who is "the
> >> industry"?]
> >> d) in some places "practical" is use as a limit of CEE [what does
> >> "practical" in CEE mean?]
> >>
> >> It may be my inability to find the proper charter statement, but from
> >> what I see it looks like the discussion provides room for so many points
> >> of view because there is no clear definition of what are the limits of
> >> CEE. Also, the current documents describe the scope of the effort in
> >> terms which shall be defined by the effort itself (and as such are not
> >> well-defined at the time they are used) - obviously something that is
> >> right now being addressed.
> >>
> >> I propose that before doing any detail definitions, CEE should first
> >> define its charter in precise terms and with clear bounds.
> >>
> >> For example, my view of logging is very detailed, probably too detailed
> >> for a number of applications. My definitions have the advantage that, so
> >> far, anything that happens inside the logging world can be described by
> >> them. They have the vast disadvantage, however, that they are very
> >> abstract and may confuse others or require too much effort to understand
> >> for "practical" purposes (e.g. for coding). There were a number of less
> >> abstracted definitions given. I could agree to almost all of them. They
> >> may provide a much better view for "practical" purposes. This, however,
> >> comes at the price that they cannot describe a small set of unusual or
> >> complex situations. IMHO it depends much on the audience which
> >> definition is to prefer.
> >>
> >> So, in my view, I would find it extremely useful if we define
> >>
> >> a) bounds for what CEE intends to cover
> >> b) intended audience
> >>
> >> The broader a) is defined, the more generic definitions are needed.
> >>
> >> Under a), I would expect answers to questions like:
> >>
> >> - what is the domain of this work (electronic system was given)?
> >> - is the domain any further restricted (e.g. compliance applications)?
> >> - what is a system (e.g. does CEE care about transitive relationships)?
> >> - what is "the industry"?
> >>
> >> Under b), I would expect to see if CEE tries to address designers,
> >> coders and end-users with a single set of definitions - or if it
> >> provides different definitions for different needs.
> >>
> >> It would also be useful if CEE could define deliverables and goals that
> >> must be reached to make the effort successful (e.g. we need to have
> >> CEE-aware applications from at least the 80% of the top-10 vendors from
> >> the x industry - or: minimal level x of CEE compliance should be made
> >> mandatory for government bids on IT systems). What needs to be done to
> >> reach these goals? Are they realistic? That boils down to "why do you
> >> think CEE will do any better than the other - failed - approaches listed
> >> in the CEE doc?". That would also be a motivation for any serious work
> >> done on CEE (and I see that it has the potential to do more than its
> >> predecessors...).
> >>
> >> One final thought: reading the CEE docs creates the impression that it
> >> aims at very broad coverage (but I cannot quote a single line where it
> >> is clearly stated). It also claims to be "practical" (which created the
> >> impression of "not being theoretical, with theoretical = abstract in
> >> me). However, broad scope and "practical" definitions do not go well
> >> together. (Because a non-abstract definition needs to limit itself to
> >> limited representatives of a broad entity.) It may be wise to drop
> >> either of these two requirements OR it would be useful to use a layered
> >> definition tree, with some very abstract definitions at the bottom of
> >> the pyramid (quoting Cyril) and with sufficiently well approximations at
> >> higher levels. That, of course, is much more work (but probably also
> >> much more useful).
> >>
> >> Let me close with my appreciation for the work done so far with CEE.
> >> This is useful and well done. I hope that my thoughts are useful for the
> >> overall progress of this effort.
> >>
> >> Rainer
Reply | Threaded
Open this post in threaded view
|

Re: CEE charter & Definitions

David Corlette
>
> So, if I follow you, sources on openxdas SVN are not related to the
> draft I'm reading ?

That is correct.  The purpose of the draft XDAS spec is merely to present some new concepts - eliminate the API for one, and the fixed, pre-defined translations from/to JSON, XML, delimited for another - as a strawman for discussion. Once we've firmed up the concepts a bit I know that the OpenXDAS folks plan to implement some new interfaces to the new standard, with the stated goal of making it really easy to create event records that include all the right info.

Where the scope of CEE comes into play here is directly related to the XDAS work - some folks have commented that XDAS (at least the old version) has a bias towards "OS" events and may not incorporate all the types of data they would want to capture. I've recommended that we stick to the use cases that we defined for an event standard to help us with this, but initially here the CEE team seems to want to have a somewhat abstract discussion about definitions.  Like Bill, I think it is important to make sure we're all talking about the same thing when we say "event" - and from this I believe the scope of CEE, and how it might relate to XDAS, will follow.
Reply | Threaded
Open this post in threaded view
|

Re: CEE charter & Definitions

John Calcote-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

David Corlette wrote:

> Where the scope of CEE comes into play here is directly
> related to the XDAS work - some folks have commented that
> XDAS (at least the old version) has a bias towards "OS"
> events and may not incorporate all the types of data they
> would want to capture. I've recommended that we stick to
> the use cases that we defined for an event standard to help
> us with this...

I'd like to point out that, while the original XDAS 0.9 preliminary
specification _appears_ to be biased toward the OS, these appearances
can be deceiving. The folks who originally worked on the XDAS spec back
in 98 were smart people. They spent a couple of years drafting this
specification based on research, experience, and a solid understanding
of auditing concepts.

This is why it's SO important (as David has mentioned several times)
that we generate and consider use cases for event systems in general,
and specifically where XDAS is concerned, security event auditing
systems. Use cases will show us where the primary needs reside for such
systems.

To clarify my comments on XDAS's apparent OS specific taxonomy: I'd like
to point out that MOST identity systems (not the largest identity
repositories, mind you - merely the shear number of systems managing
identities) are simply operating systems. There are literally millions
of operating systems in operation in corporate and government data
centers today. Each of these OS's manage identity repositories (however
small they may be) and very often rights to important resources are
granted to identities in these smaller repositories.

So, given the fact that the point of a security auditing system is to
track identities and the activities of people associated with those
identities, it makes sense to me that the taxonomy would appear to be
somewhat OS centric, at first glance.

Granted, we need to add new taxonomy for XDAS 2.0 to support directory
(eg., LDAP, X.500), RDBMS, RFID, OWL, Infocard and other identity
repositories that exist today or will exist in the near future.

John
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iEYEARECAAYFAkiYdfkACgkQdcgqmRY/OH/k3QCgmnE/jFvLD9YwIpAmsdJjhfka
enIAnjfzZnGyv2+JceVDlCfiSuGcDR1q
=Se9h
-----END PGP SIGNATURE-----
Reply | Threaded
Open this post in threaded view
|

Re: CEE charter & Definitions

Tina Bird
In reply to this post by David Corlette
 
> Do you have a copy of the use cases?  I seem to remember seeing some
> reference, but Tina mentioned that you had them on a wiki..  Are they
> available somewhere?

David -- I'm sending more complete instructions about accessing the current
notes and documents because the web interface is a little opaque; hope you
don't mind.

Mark -- I've just logged in via the generic account since I'm waiting for my
password to be reset *sigh*

In the default configuration, once you've authenticated you are placed into
the "Teaming Navigator" workspace. If you expand the "Workspaces" item in
the left hand navigation bar, you'll see three options: Global workspaces;
Personal workspaces; and Team Workspaces. Click on "Team Workspaces", and
then finally, "Event Standards."

Under the "Wiki" option in the Event Standards left hand nav bar, you'll see
a number of items. I believe that what we've been calling the "Burton use
cases" are documented under the entry "CES SIG Notes" (as well as a number
of other items that we should probably all read). Also of interest, although
I don't know if David's had time to keep them entirely up to date with the
various flurries of activity on the mailing lists: the "Discussion" area
includes things like the debate over definitions; and the "File folder" area
contains the XDAS v2 spec in its current incarnation.

hope that helps -- t.
Reply | Threaded
Open this post in threaded view
|

Re: CEE charter & Definitions

Tina Bird
Since I've gone to the trouble to write this all down and get it in one
place, I should also repeat that the generic account information is
username: visitor, password: standards.

> > Do you have a copy of the use cases?  I seem to remember seeing some
> > reference, but Tina mentioned that you had them on a wiki..
>  Are they
> > available somewhere?
>
> David -- I'm sending more complete instructions about
> accessing the current
> notes and documents because the web interface is a little
> opaque; hope you
> don't mind.
>
> Mark -- I've just logged in via the generic account since I'm
> waiting for my
> password to be reset *sigh*
>
> In the default configuration, once you've authenticated you
> are placed into
> the "Teaming Navigator" workspace. If you expand the
> "Workspaces" item in
> the left hand navigation bar, you'll see three options:
> Global workspaces;
> Personal workspaces; and Team Workspaces. Click on "Team
> Workspaces", and
> then finally, "Event Standards."
>
> Under the "Wiki" option in the Event Standards left hand nav
> bar, you'll see
> a number of items. I believe that what we've been calling the
> "Burton use
> cases" are documented under the entry "CES SIG Notes" (as
> well as a number
> of other items that we should probably all read). Also of
> interest, although
> I don't know if David's had time to keep them entirely up to
> date with the
> various flurries of activity on the mailing lists: the
> "Discussion" area
> includes things like the debate over definitions; and the
> "File folder" area
> contains the XDAS v2 spec in its current incarnation.
>
> hope that helps -- t.
>