tag:www.nabble.com,2006:forum-30667Nabble - CEE Log Event Standard2008-08-20T11:02:46Z<p><a href="http://cee.mitre.org" target="_top" rel="nofollow">Common Event Expression</a> (CEE) standardizes the way computer events are described, logged, and exchanged. By using CEE’s common language and syntax, enterprise-wide log management, correlation, aggregation, auditing, and incident handling can be performed more efficiently and produce better results than was possible prior to CEE.</p>
<p>CEE and the CEE logo are trademarks of The MITRE Corporation.</p>tag:www.nabble.com,2006:post-19075040CEE Defcon Meetup Notes - 08 Aug 20082008-08-20T11:02:46Z2008-08-20T11:02:46ZWilliam HeinbockelBelow are my notes from the CEE meeting at Defcon
<br>a couple of weeks ago.
<br><br>All in all, things turned out fairly well. Though
<br>I apologize to anyone who wanted to participate
<br>but could not locate us.
<br><br><br>***************************
<br><br>CEE Meeting
<br>Defcon - 08 Aug 2008
<br>Riviera, Las Vegas, NV
<br><br><br> Attendees
<br> =========
<br><br>- Eric Fitzgerald
<br>- Tina Bird
<br>- Raffy Marty
<br>- Sanford Whitehouse
<br>- Steve Christey
<br>- William Heinbockel
<br><br><br> Minutes
<br> =======
<br><br>Group met at the Defcon Registration desk at the Riviera at Noon PST.
<br>Discussion lasted for approximately 2 hours.
<br><br><br> Definitions
<br> ===========
<br><br>Definitions discussion is good, though we are now debating symantic
<br>nuaces. MITRE needs to issue a final version and we can extend that
<br>with additional notes and descriptions.
<br><br>- event definition discussion
<br> - Machine-generated data
<br> - State change may not be good enough, due to problems with
<br> abstration levels the end state might be the same as the start
<br> state. Use activity occured instead.
<br>- We should include a definition for event stream. Generically, the
<br> log flow process seems to be:
<br><br> event -> event record -> event stream -> event log
<br><br>- A log is a general sequential or timestamped repository of
<br> records.
<br>- Logs also hold reports or "informational messages"
<br>- Fidelity: Logged events may not have actually occured, such as
<br> with an IDS signature match.
<br>- Look at Oer Kerr's paper on Machine Logs vs. Hearsay
<br>- Applications, Operations, and Admins partake in various log
<br> activities
<br>- Syntax
<br> - The syntax fields should be self-describing
<br> - Support: Binary vs. XML vs. string formats
<br> - Need to support proper ordering of records
<br> - The log order does not always match the event order
<br> - Needs to support granual timestamps
<br> - Synchronizing timestamps
<br> - Needs to support sequence numbers to properly order events
<br> - Pair-wise vs. Universal IDs
<br><br><br> Questions / Issues
<br> ==================
<br><br>- Can a record consist of 1 or more records?
<br>- How does CEE handle multi-line data?
<br>- Should logs be machine-readable or human-readable?
<br> - This choice depends on the environment and admins
<br> - machine-readable is more condensed and better for wire formats
<br> - machine-readable can be translated for humans
<br>- Who timestamps the records? The application? The event recorder?
<br><br><br> Outcomes
<br> ========
<br><br>- CEE and LogAnalysis.org will partner up
<br> - MITRE will host the CEE drafts and specifications
<br> - LogAnalysis can host a wiki, log repositories, and everything else
<br> - More to come on this later...
<br>- MITRE will finish the CEE WG Charter
<br> - High level usecases for CFO, CIO/Operations, Developers
<br>- MITRE will produce a CEE Project outline
<br> - Deliverables
<br> - Schedule
<br>- We need to get more large players involved: Cisco, Oracle, Apple,
<br>IBM
<br>- We need more diversity in the WG: admins and enterprise users
<br>- Create a Vendor Questionaire
<br> - Technical issues with logs?
<br> - Customer issues with current logging?
<br> - How do you view SIM vendors continually asking for logs?
<br> - If logs were standardized, what potential damage or loss would you
<br> suffer?
<br><br><br><br>William Heinbockel
<br>Infosec Engineer, Sr.
<br>The MITRE Corporation
<br>202 Burlington Rd. MS S145
<br>Bedford, MA 01730
<br><a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=19075040&i=0" target="_top" rel="nofollow">heinbockel@...</a>
<br>781-271-2615
<br><br><br><br /> <div class="small"><br/><img src="http://www.nabble.com/images/icon_attachment.gif" > <strong>smime.p7s</strong> (4K) <a href="http://www.nabble.com/attachment/19075040/0/smime.p7s" target="_top">Download Attachment</a></div><p>From forum: <a href="http://www.nabble.com/CEE-Discussion-List-f29471.html" embed="fixTarget[29471]" target="_top" >CEE Discussion List</a></p>tag:www.nabble.com,2006:post-18833964Re: CEE charter & Definitions2008-08-05T08:47:06Z2008-08-05T08:47:06ZJohn Calcote-2-----BEGIN PGP SIGNED MESSAGE-----
<br>Hash: SHA1
<br><br>David Corlette wrote:
<br><br>> Where the scope of CEE comes into play here is directly
<br>> related to the XDAS work - some folks have commented that
<br>> XDAS (at least the old version) has a bias towards "OS"
<br>> events and may not incorporate all the types of data they
<br>> would want to capture. I've recommended that we stick to
<br>> the use cases that we defined for an event standard to help
<br>> us with this...
<br><br>I'd like to point out that, while the original XDAS 0.9 preliminary
<br>specification _appears_ to be biased toward the OS, these appearances
<br>can be deceiving. The folks who originally worked on the XDAS spec back
<br>in 98 were smart people. They spent a couple of years drafting this
<br>specification based on research, experience, and a solid understanding
<br>of auditing concepts.
<br><br>This is why it's SO important (as David has mentioned several times)
<br>that we generate and consider use cases for event systems in general,
<br>and specifically where XDAS is concerned, security event auditing
<br>systems. Use cases will show us where the primary needs reside for such
<br>systems.
<br><br>To clarify my comments on XDAS's apparent OS specific taxonomy: I'd like
<br>to point out that MOST identity systems (not the largest identity
<br>repositories, mind you - merely the shear number of systems managing
<br>identities) are simply operating systems. There are literally millions
<br>of operating systems in operation in corporate and government data
<br>centers today. Each of these OS's manage identity repositories (however
<br>small they may be) and very often rights to important resources are
<br>granted to identities in these smaller repositories.
<br><br>So, given the fact that the point of a security auditing system is to
<br>track identities and the activities of people associated with those
<br>identities, it makes sense to me that the taxonomy would appear to be
<br>somewhat OS centric, at first glance.
<br><br>Granted, we need to add new taxonomy for XDAS 2.0 to support directory
<br>(eg., LDAP, X.500), RDBMS, RFID, OWL, Infocard and other identity
<br>repositories that exist today or will exist in the near future.
<br><br>John
<br>-----BEGIN PGP SIGNATURE-----
<br>Version: GnuPG v2.0.9 (GNU/Linux)
<br>Comment: Using GnuPG with SUSE - <a href="http://enigmail.mozdev.org" target="_top" rel="nofollow">http://enigmail.mozdev.org</a><br><br>iEYEARECAAYFAkiYdfkACgkQdcgqmRY/OH/k3QCgmnE/jFvLD9YwIpAmsdJjhfka
<br>enIAnjfzZnGyv2+JceVDlCfiSuGcDR1q
<br>=Se9h
<br>-----END PGP SIGNATURE-----
<br><p>From forum: <a href="http://www.nabble.com/CEE-Discussion-List-f29471.html" embed="fixTarget[29471]" target="_top" >CEE Discussion List</a></p>tag:www.nabble.com,2006:post-18820936Re: CEE charter & Definitions2008-08-04T15:12:55Z2008-08-04T15:12:55ZDavid Corlette>
<br>> So, if I follow you, sources on openxdas SVN are not related to the
<br>> draft I'm reading ?
<br><br>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.
<br><br>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.
<br><p>From forum: <a href="http://www.nabble.com/CEE-Discussion-List-f29471.html" embed="fixTarget[29471]" target="_top" >CEE Discussion List</a></p>tag:www.nabble.com,2006:post-18819802Re: CEE charter & Definitions2008-08-04T14:04:13Z2008-08-04T14:04:13ZJoël Winteregg-3Hi David,
<br><br>Thanks for your email.
<br><br>>
<br>> I believe that we are working on exactly the issues you and Rainer describe, so hopefully we can resolve this soon.
<br><br>Cool, that sounds great ! Let me know if I can help...
<br><br>>
<br>> Regarding IDMEF - if there are parallels that we could leverage to
<br>> converge that standard, that would be excellent. One thing I proposed
<br>> at one point was the concept of treating CEE as a "wrapper" around
<br>> other event standards' data. So one could include an XDAS event as
<br>> well as an IDMEF message with the appropriate flags. Not sure if this
<br>> jibes with your thinking.
<br>>
<br><br>I understand what you mean and I like the concept of "wrapper". But the
<br>danger with wrappers is that you ends with having to understand/know
<br>many standards...
<br><br>> And finally - XDAS? Do you mean OpenXDAS?
<br><br>Yes, I'm reading XDAS Version 2 (I got it on <a href="http://12.193.84.139:8080" target="_top" rel="nofollow">http://12.193.84.139:8080</a>)
<br>and I wanted to try the following stuff:
<br> <a href="http://svn.sourceforge.net/viewvc/openxdas/trunk/openxdas/java/" target="_top" rel="nofollow">http://svn.sourceforge.net/viewvc/openxdas/trunk/openxdas/java/</a><br><br>> Hope that clarifies things...
<br>>
<br><br>So, if I follow you, sources on openxdas SVN are not related to the
<br>draft I'm reading ?
<br><br><br>Joël
<br><div class='shrinkable-quote'><br>>
<br>> >>> On Mon, Aug 4, 2008 at 4:19 PM, in message
<br>> <1217881191.5609.37.camel@localhost>, Joël Winteregg
<br>> <<a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=18819802&i=0" target="_top" rel="nofollow">winteregg@...</a>> wrote:
<br>> > Hello Rainer,
<br>> >
<br>> >
<br>> > I totally agree with your point of view. It is hard (at least for me) to
<br>> > understand the exact focus of CEE. On my side, the following question is
<br>> > still open <a href="http://www.nabble.com/Whitepaper-feedback-td16551029.html" target="_top">http://www.nabble.com/Whitepaper-feedback-td16551029.html</a> and
<br>> > I think its answer could drive CEE to completely different directions:
<br>> > A) Ending with a common format, a common taxonomy and logging APIs
<br>> > B) Ending with a common format, a common taxonomy and format
<br>> > transformation tools
<br>> >
<br>> > I really look forward to have some more inputs about CEE "operational
<br>> > focus" and/or I would also be happy to discuss about it (if possible).
<br>> >
<br>> > I'm also always surprised to see IDMEF out of scope (too narrow, too IDS
<br>> > focused, etc.) because every paper I read looks quite close to IDMEF. I
<br>> > should finish to read XDAS v2 this evening (will also try to test its
<br>> > Java impl) and I will post, as soon as possible, a short benchmark with
<br>> > IDMEF to outline their similarities (in terms of data structure).
<br>> >
<br>> >
<br>> > Thanks again to CEE for their really good initiative !
<br>> >
<br>> >
<br>> > Regards,
<br>> >
<br>> >
<br>> > Joel
<br>> >
<br>> >
<br>> > On Mon, 2008-08-04 at 13:11 +0200, Rainer Gerhards wrote:
<br>> >> Hi list,
<br>> >>
<br>> >> As I have already written, I have recently joined the CEE mailing list
<br>> >> after the "definition question" loganalysis list post. I sent a number
<br>> >> of proposals for potential definitions. After re-reading many of the
<br>> >> post on the CEE list, I noticed that most of us are talking about the
<br>> >> same terms and ideas, but from different level of details and from
<br>> >> different background.
<br>> >>
<br>> >> After I noticed that, I began to search for a CEE charter. I have to
<br>> >> admit I did not yet find a sufficiently clear definition of what CEE
<br>> >> itself is all about.
<br>> >>
<br>> >> This document provides a good starting point:
<br>> >>
<br>> >> <a href="http://cee.mitre.org/docs/Common_Event_Expression_White_Paper_June_2008" target="_top" rel="nofollow">http://cee.mitre.org/docs/Common_Event_Expression_White_Paper_June_2008</a>.
<br>> >> pdf
<br>> >>
<br>> >> but is still missing the clarity of what is in scope and what not.
<br>> >>
<br>> >> The home page also has a brief (but good) mission statement:
<br>> >>
<br>> >> "CEE standardizes the way computer events are described, logged, and
<br>> >> exchanged."
<br>> >>
<br>> >> If I merge these two, I see that the CEE effort is
<br>> >>
<br>> >> a) limited to the domain of computer systems [so why was that discussed
<br>> >> just recently?]
<br>> >> b) finds an upper bound at "We note that CEE focuses on individual
<br>> >> device-generated events, not on whole security incidents." (in section 2
<br>> >> of above paper) [why? CEE does not apply to supersets?]
<br>> >> c) applies to "the industry" (multiple findings) [who is "the
<br>> >> industry"?]
<br>> >> d) in some places "practical" is use as a limit of CEE [what does
<br>> >> "practical" in CEE mean?]
<br>> >>
<br>> >> It may be my inability to find the proper charter statement, but from
<br>> >> what I see it looks like the discussion provides room for so many points
<br>> >> of view because there is no clear definition of what are the limits of
<br>> >> CEE. Also, the current documents describe the scope of the effort in
<br>> >> terms which shall be defined by the effort itself (and as such are not
<br>> >> well-defined at the time they are used) - obviously something that is
<br>> >> right now being addressed.
<br>> >>
<br>> >> I propose that before doing any detail definitions, CEE should first
<br>> >> define its charter in precise terms and with clear bounds.
<br>> >>
<br>> >> For example, my view of logging is very detailed, probably too detailed
<br>> >> for a number of applications. My definitions have the advantage that, so
<br>> >> far, anything that happens inside the logging world can be described by
<br>> >> them. They have the vast disadvantage, however, that they are very
<br>> >> abstract and may confuse others or require too much effort to understand
<br>> >> for "practical" purposes (e.g. for coding). There were a number of less
<br>> >> abstracted definitions given. I could agree to almost all of them. They
<br>> >> may provide a much better view for "practical" purposes. This, however,
<br>> >> comes at the price that they cannot describe a small set of unusual or
<br>> >> complex situations. IMHO it depends much on the audience which
<br>> >> definition is to prefer.
<br>> >>
<br>> >> So, in my view, I would find it extremely useful if we define
<br>> >>
<br>> >> a) bounds for what CEE intends to cover
<br>> >> b) intended audience
<br>> >>
<br>> >> The broader a) is defined, the more generic definitions are needed.
<br>> >>
<br>> >> Under a), I would expect answers to questions like:
<br>> >>
<br>> >> - what is the domain of this work (electronic system was given)?
<br>> >> - is the domain any further restricted (e.g. compliance applications)?
<br>> >> - what is a system (e.g. does CEE care about transitive relationships)?
<br>> >> - what is "the industry"?
<br>> >>
<br>> >> Under b), I would expect to see if CEE tries to address designers,
<br>> >> coders and end-users with a single set of definitions - or if it
<br>> >> provides different definitions for different needs.
<br>> >>
<br>> >> It would also be useful if CEE could define deliverables and goals that
<br>> >> must be reached to make the effort successful (e.g. we need to have
<br>> >> CEE-aware applications from at least the 80% of the top-10 vendors from
<br>> >> the x industry - or: minimal level x of CEE compliance should be made
<br>> >> mandatory for government bids on IT systems). What needs to be done to
<br>> >> reach these goals? Are they realistic? That boils down to "why do you
<br>> >> think CEE will do any better than the other - failed - approaches listed
<br>> >> in the CEE doc?". That would also be a motivation for any serious work
<br>> >> done on CEE (and I see that it has the potential to do more than its
<br>> >> predecessors...).
<br>> >>
<br>> >> One final thought: reading the CEE docs creates the impression that it
<br>> >> aims at very broad coverage (but I cannot quote a single line where it
<br>> >> is clearly stated). It also claims to be "practical" (which created the
<br>> >> impression of "not being theoretical, with theoretical = abstract in
<br>> >> me). However, broad scope and "practical" definitions do not go well
<br>> >> together. (Because a non-abstract definition needs to limit itself to
<br>> >> limited representatives of a broad entity.) It may be wise to drop
<br>> >> either of these two requirements OR it would be useful to use a layered
<br>> >> definition tree, with some very abstract definitions at the bottom of
<br>> >> the pyramid (quoting Cyril) and with sufficiently well approximations at
<br>> >> higher levels. That, of course, is much more work (but probably also
<br>> >> much more useful).
<br>> >>
<br>> >> Let me close with my appreciation for the work done so far with CEE.
<br>> >> This is useful and well done. I hope that my thoughts are useful for the
<br>> >> overall progress of this effort.
<br>> >>
<br>> >> Rainer
<br></div><p>From forum: <a href="http://www.nabble.com/CEE-Discussion-List-f29471.html" embed="fixTarget[29471]" target="_top" >CEE Discussion List</a></p>tag:www.nabble.com,2006:post-18819264Re: CEE charter & Definitions2008-08-04T13:35:37Z2008-08-04T13:35:37ZDavid CorletteHi Joel,
<br><br>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.
<br><br>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.
<br><br>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.
<br><br>Hope that clarifies things...
<br><br><br>>>> On Mon, Aug 4, 2008 at 4:19 PM, in message
<br><1217881191.5609.37.camel@localhost>, Joël Winteregg
<br><<a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=18819264&i=0" target="_top" rel="nofollow">winteregg@...</a>> wrote:
<div class='shrinkable-quote'><br>> Hello Rainer,
<br>>
<br>>
<br>> I totally agree with your point of view. It is hard (at least for me) to
<br>> understand the exact focus of CEE. On my side, the following question is
<br>> still open <a href="http://www.nabble.com/Whitepaper-feedback-td16551029.html" target="_top">http://www.nabble.com/Whitepaper-feedback-td16551029.html</a> and
<br>> I think its answer could drive CEE to completely different directions:
<br>> A) Ending with a common format, a common taxonomy and logging APIs
<br>> B) Ending with a common format, a common taxonomy and format
<br>> transformation tools
<br>>
<br>> I really look forward to have some more inputs about CEE "operational
<br>> focus" and/or I would also be happy to discuss about it (if possible).
<br>>
<br>> I'm also always surprised to see IDMEF out of scope (too narrow, too IDS
<br>> focused, etc.) because every paper I read looks quite close to IDMEF. I
<br>> should finish to read XDAS v2 this evening (will also try to test its
<br>> Java impl) and I will post, as soon as possible, a short benchmark with
<br>> IDMEF to outline their similarities (in terms of data structure).
<br>>
<br>>
<br>> Thanks again to CEE for their really good initiative !
<br>>
<br>>
<br>> Regards,
<br>>
<br>>
<br>> Joel
<br>>
<br>>
<br>> On Mon, 2008-08-04 at 13:11 +0200, Rainer Gerhards wrote:
<br>>> Hi list,
<br>>>
<br>>> As I have already written, I have recently joined the CEE mailing list
<br>>> after the "definition question" loganalysis list post. I sent a number
<br>>> of proposals for potential definitions. After re-reading many of the
<br>>> post on the CEE list, I noticed that most of us are talking about the
<br>>> same terms and ideas, but from different level of details and from
<br>>> different background.
<br>>>
<br>>> After I noticed that, I began to search for a CEE charter. I have to
<br>>> admit I did not yet find a sufficiently clear definition of what CEE
<br>>> itself is all about.
<br>>>
<br>>> This document provides a good starting point:
<br>>>
<br>>> <a href="http://cee.mitre.org/docs/Common_Event_Expression_White_Paper_June_2008" target="_top" rel="nofollow">http://cee.mitre.org/docs/Common_Event_Expression_White_Paper_June_2008</a>.
<br>>> pdf
<br>>>
<br>>> but is still missing the clarity of what is in scope and what not.
<br>>>
<br>>> The home page also has a brief (but good) mission statement:
<br>>>
<br>>> "CEE standardizes the way computer events are described, logged, and
<br>>> exchanged."
<br>>>
<br>>> If I merge these two, I see that the CEE effort is
<br>>>
<br>>> a) limited to the domain of computer systems [so why was that discussed
<br>>> just recently?]
<br>>> b) finds an upper bound at "We note that CEE focuses on individual
<br>>> device-generated events, not on whole security incidents." (in section 2
<br>>> of above paper) [why? CEE does not apply to supersets?]
<br>>> c) applies to "the industry" (multiple findings) [who is "the
<br>>> industry"?]
<br>>> d) in some places "practical" is use as a limit of CEE [what does
<br>>> "practical" in CEE mean?]
<br>>>
<br>>> It may be my inability to find the proper charter statement, but from
<br>>> what I see it looks like the discussion provides room for so many points
<br>>> of view because there is no clear definition of what are the limits of
<br>>> CEE. Also, the current documents describe the scope of the effort in
<br>>> terms which shall be defined by the effort itself (and as such are not
<br>>> well-defined at the time they are used) - obviously something that is
<br>>> right now being addressed.
<br>>>
<br>>> I propose that before doing any detail definitions, CEE should first
<br>>> define its charter in precise terms and with clear bounds.
<br>>>
<br>>> For example, my view of logging is very detailed, probably too detailed
<br>>> for a number of applications. My definitions have the advantage that, so
<br>>> far, anything that happens inside the logging world can be described by
<br>>> them. They have the vast disadvantage, however, that they are very
<br>>> abstract and may confuse others or require too much effort to understand
<br>>> for "practical" purposes (e.g. for coding). There were a number of less
<br>>> abstracted definitions given. I could agree to almost all of them. They
<br>>> may provide a much better view for "practical" purposes. This, however,
<br>>> comes at the price that they cannot describe a small set of unusual or
<br>>> complex situations. IMHO it depends much on the audience which
<br>>> definition is to prefer.
<br>>>
<br>>> So, in my view, I would find it extremely useful if we define
<br>>>
<br>>> a) bounds for what CEE intends to cover
<br>>> b) intended audience
<br>>>
<br>>> The broader a) is defined, the more generic definitions are needed.
<br>>>
<br>>> Under a), I would expect answers to questions like:
<br>>>
<br>>> - what is the domain of this work (electronic system was given)?
<br>>> - is the domain any further restricted (e.g. compliance applications)?
<br>>> - what is a system (e.g. does CEE care about transitive relationships)?
<br>>> - what is "the industry"?
<br>>>
<br>>> Under b), I would expect to see if CEE tries to address designers,
<br>>> coders and end-users with a single set of definitions - or if it
<br>>> provides different definitions for different needs.
<br>>>
<br>>> It would also be useful if CEE could define deliverables and goals that
<br>>> must be reached to make the effort successful (e.g. we need to have
<br>>> CEE-aware applications from at least the 80% of the top-10 vendors from
<br>>> the x industry - or: minimal level x of CEE compliance should be made
<br>>> mandatory for government bids on IT systems). What needs to be done to
<br>>> reach these goals? Are they realistic? That boils down to "why do you
<br>>> think CEE will do any better than the other - failed - approaches listed
<br>>> in the CEE doc?". That would also be a motivation for any serious work
<br>>> done on CEE (and I see that it has the potential to do more than its
<br>>> predecessors...).
<br>>>
<br>>> One final thought: reading the CEE docs creates the impression that it
<br>>> aims at very broad coverage (but I cannot quote a single line where it
<br>>> is clearly stated). It also claims to be "practical" (which created the
<br>>> impression of "not being theoretical, with theoretical = abstract in
<br>>> me). However, broad scope and "practical" definitions do not go well
<br>>> together. (Because a non-abstract definition needs to limit itself to
<br>>> limited representatives of a broad entity.) It may be wise to drop
<br>>> either of these two requirements OR it would be useful to use a layered
<br>>> definition tree, with some very abstract definitions at the bottom of
<br>>> the pyramid (quoting Cyril) and with sufficiently well approximations at
<br>>> higher levels. That, of course, is much more work (but probably also
<br>>> much more useful).
<br>>>
<br>>> Let me close with my appreciation for the work done so far with CEE.
<br>>> This is useful and well done. I hope that my thoughts are useful for the
<br>>> overall progress of this effort.
<br>>>
<br>>> Rainer
<br></div><p>From forum: <a href="http://www.nabble.com/CEE-Discussion-List-f29471.html" embed="fixTarget[29471]" target="_top" >CEE Discussion List</a></p>tag:www.nabble.com,2006:post-18818978Re: CEE charter & Definitions2008-08-04T13:19:51Z2008-08-04T13:19:51ZJoël Winteregg-3Hello Rainer,
<br><br><br>I totally agree with your point of view. It is hard (at least for me) to
<br>understand the exact focus of CEE. On my side, the following question is
<br>still open <a href="http://www.nabble.com/Whitepaper-feedback-td16551029.html" target="_top">http://www.nabble.com/Whitepaper-feedback-td16551029.html</a> and
<br>I think its answer could drive CEE to completely different directions:
<br>A) Ending with a common format, a common taxonomy and logging APIs
<br>B) Ending with a common format, a common taxonomy and format
<br>transformation tools
<br><br>I really look forward to have some more inputs about CEE "operational
<br>focus" and/or I would also be happy to discuss about it (if possible).
<br><br>I'm also always surprised to see IDMEF out of scope (too narrow, too IDS
<br>focused, etc.) because every paper I read looks quite close to IDMEF. I
<br>should finish to read XDAS v2 this evening (will also try to test its
<br>Java impl) and I will post, as soon as possible, a short benchmark with
<br>IDMEF to outline their similarities (in terms of data structure).
<br><br><br>Thanks again to CEE for their really good initiative !
<br><br><br>Regards,
<br><br><br>Joel
<br><br><br>On Mon, 2008-08-04 at 13:11 +0200, Rainer Gerhards wrote:
<div class='shrinkable-quote'><br>> Hi list,
<br>>
<br>> As I have already written, I have recently joined the CEE mailing list
<br>> after the "definition question" loganalysis list post. I sent a number
<br>> of proposals for potential definitions. After re-reading many of the
<br>> post on the CEE list, I noticed that most of us are talking about the
<br>> same terms and ideas, but from different level of details and from
<br>> different background.
<br>>
<br>> After I noticed that, I began to search for a CEE charter. I have to
<br>> admit I did not yet find a sufficiently clear definition of what CEE
<br>> itself is all about.
<br>>
<br>> This document provides a good starting point:
<br>>
<br>> <a href="http://cee.mitre.org/docs/Common_Event_Expression_White_Paper_June_2008" target="_top" rel="nofollow">http://cee.mitre.org/docs/Common_Event_Expression_White_Paper_June_2008</a>.
<br>> pdf
<br>>
<br>> but is still missing the clarity of what is in scope and what not.
<br>>
<br>> The home page also has a brief (but good) mission statement:
<br>>
<br>> "CEE standardizes the way computer events are described, logged, and
<br>> exchanged."
<br>>
<br>> If I merge these two, I see that the CEE effort is
<br>>
<br>> a) limited to the domain of computer systems [so why was that discussed
<br>> just recently?]
<br>> b) finds an upper bound at "We note that CEE focuses on individual
<br>> device-generated events, not on whole security incidents." (in section 2
<br>> of above paper) [why? CEE does not apply to supersets?]
<br>> c) applies to "the industry" (multiple findings) [who is "the
<br>> industry"?]
<br>> d) in some places "practical" is use as a limit of CEE [what does
<br>> "practical" in CEE mean?]
<br>>
<br>> It may be my inability to find the proper charter statement, but from
<br>> what I see it looks like the discussion provides room for so many points
<br>> of view because there is no clear definition of what are the limits of
<br>> CEE. Also, the current documents describe the scope of the effort in
<br>> terms which shall be defined by the effort itself (and as such are not
<br>> well-defined at the time they are used) - obviously something that is
<br>> right now being addressed.
<br>>
<br>> I propose that before doing any detail definitions, CEE should first
<br>> define its charter in precise terms and with clear bounds.
<br>>
<br>> For example, my view of logging is very detailed, probably too detailed
<br>> for a number of applications. My definitions have the advantage that, so
<br>> far, anything that happens inside the logging world can be described by
<br>> them. They have the vast disadvantage, however, that they are very
<br>> abstract and may confuse others or require too much effort to understand
<br>> for "practical" purposes (e.g. for coding). There were a number of less
<br>> abstracted definitions given. I could agree to almost all of them. They
<br>> may provide a much better view for "practical" purposes. This, however,
<br>> comes at the price that they cannot describe a small set of unusual or
<br>> complex situations. IMHO it depends much on the audience which
<br>> definition is to prefer.
<br>>
<br>> So, in my view, I would find it extremely useful if we define
<br>>
<br>> a) bounds for what CEE intends to cover
<br>> b) intended audience
<br>>
<br>> The broader a) is defined, the more generic definitions are needed.
<br>>
<br>> Under a), I would expect answers to questions like:
<br>>
<br>> - what is the domain of this work (electronic system was given)?
<br>> - is the domain any further restricted (e.g. compliance applications)?
<br>> - what is a system (e.g. does CEE care about transitive relationships)?
<br>> - what is "the industry"?
<br>>
<br>> Under b), I would expect to see if CEE tries to address designers,
<br>> coders and end-users with a single set of definitions - or if it
<br>> provides different definitions for different needs.
<br>>
<br>> It would also be useful if CEE could define deliverables and goals that
<br>> must be reached to make the effort successful (e.g. we need to have
<br>> CEE-aware applications from at least the 80% of the top-10 vendors from
<br>> the x industry - or: minimal level x of CEE compliance should be made
<br>> mandatory for government bids on IT systems). What needs to be done to
<br>> reach these goals? Are they realistic? That boils down to "why do you
<br>> think CEE will do any better than the other - failed - approaches listed
<br>> in the CEE doc?". That would also be a motivation for any serious work
<br>> done on CEE (and I see that it has the potential to do more than its
<br>> predecessors...).
<br>>
<br>> One final thought: reading the CEE docs creates the impression that it
<br>> aims at very broad coverage (but I cannot quote a single line where it
<br>> is clearly stated). It also claims to be "practical" (which created the
<br>> impression of "not being theoretical, with theoretical = abstract in
<br>> me). However, broad scope and "practical" definitions do not go well
<br>> together. (Because a non-abstract definition needs to limit itself to
<br>> limited representatives of a broad entity.) It may be wise to drop
<br>> either of these two requirements OR it would be useful to use a layered
<br>> definition tree, with some very abstract definitions at the bottom of
<br>> the pyramid (quoting Cyril) and with sufficiently well approximations at
<br>> higher levels. That, of course, is much more work (but probably also
<br>> much more useful).
<br>>
<br>> Let me close with my appreciation for the work done so far with CEE.
<br>> This is useful and well done. I hope that my thoughts are useful for the
<br>> overall progress of this effort.
<br>>
<br>> Rainer
<br></div><p>From forum: <a href="http://www.nabble.com/CEE-Discussion-List-f29471.html" embed="fixTarget[29471]" target="_top" >CEE Discussion List</a></p>tag:www.nabble.com,2006:post-18818947Re: CEE charter & Definitions2008-08-04T13:18:25Z2008-08-04T13:18:25ZTina Bird
<br>> One of my goals is to bring cohesion to the log
<br>> community. So by talking definitions, we force the
<br>> community to define the terms that they often use
<br>> without a second thought, and provides a basis to
<br>> define CEE.
<br><br>In response to both Rainer and David -- and in the way of reminding myself
<br>to follow my own advice -- I'd like to remind folks about the Burton Group
<br>use cases, available via David Corlette's collaboration server. Summarizing
<br>(or generalizing) from the use cases, as well as deciding if we have a
<br>"complete enough" list, will presumably make it easier to talk about
<br>definitions, scope of work, etc., and yet despite David's very good
<br>recommendation that we discuss them, none of us (myself included!) have.
<br><br>I have no idea how much overlap there is going to be between the people
<br>included in the Burton group meeting, and those who will be in Vegas on
<br>Friday, but I'd like to suggest that perhaps those of us in attendance
<br>should review the use cases before we get to the meeting...
<br><br>cheers -- tbird
<br><p>From forum: <a href="http://www.nabble.com/CEE-Discussion-List-f29471.html" embed="fixTarget[29471]" target="_top" >CEE Discussion List</a></p>tag:www.nabble.com,2006:post-18818687Re: CEE charter & Definitions2008-08-04T13:05:20Z2008-08-04T13:05:20ZWilliam Heinbockel<br>Rainer,
<br><br>We are currently working on a CEE Charter document
<br>that defines exactly this.
<br><br>It was due, in part, to this document, why we started
<br>the discussion of the definitions. I disagree with
<br>your point about defining a charter before definitions.
<br>How do we define the scope of CEE without being clear on
<br>definitions... is it a log standard? event standard?
<br>event stream standard?
<br><br>One of my goals is to bring cohesion to the log
<br>community. So by talking definitions, we force the
<br>community to define the terms that they often use
<br>without a second thought, and provides a basis to
<br>define CEE.
<br><br>This is important. Initially, we referred to CEE as
<br>a log standard, but as has been pointed out by
<br>many, what about all of the non-event information
<br>that gets stored in logs, is that part of CEE too?
<br>If I were a product marketer, I would say that CEE
<br>standardizes "event expressions". This would avoid
<br>all terminology and scoping problems by defining a
<br>new term, but would cause another issue -- there
<br>would be yet another term related to logs (and thereby
<br>making the log space we're trying to standardize
<br>even more complex).
<br><br>While I think we are all in agreement that stuff
<br>like debug messages are outside the scope of CEE, the
<br>CEE Charter needs to be very precise on things like
<br>terminology and scope.
<br><br>I will be working on the draft over the next week
<br>or so. I hoped to have a draft posted to this list
<br>before BlackHat, but have gotten pulled into
<br>another project. Hopefully, I will have a draft
<br>posted next week.
<br><br><br>William Heinbockel
<br>The MITRE Corporation
<br><br><div class='shrinkable-quote'><div class='shrinkable-quote'><br>>-----Original Message-----
<br>>From: Rainer Gerhards [mailto:<a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=18818687&i=0" target="_top" rel="nofollow">rgerhards@...</a>]
<br>>Sent: Monday, 04 August 2008 07:12
<br>>To: cee-discussion-list CEE-Related Discussion
<br>>Subject: [CEE-DISCUSSION-LIST] CEE charter & Definitions
<br>>
<br>>Hi list,
<br>>
<br>>As I have already written, I have recently joined the CEE mailing
<br>>list
<br>>after the "definition question" loganalysis list post. I sent a
<br>>number
<br>>of proposals for potential definitions. After re-reading many of
<br>>the
<br>>post on the CEE list, I noticed that most of us are talking about
<br>>the
<br>>same terms and ideas, but from different level of details and from
<br>>different background.
<br>>
<br>>After I noticed that, I began to search for a CEE charter. I have
<br>>to
<br>>admit I did not yet find a sufficiently clear definition of what
<br>>CEE
<br>>itself is all about.
<br>>
<br>>This document provides a good starting point:
<br>>
<br>><a href="http://cee.mitre.org/docs/Common_Event_Expression_White_Paper_June" target="_top" rel="nofollow">http://cee.mitre.org/docs/Common_Event_Expression_White_Paper_June</a><br>>_2008.
<br>>pdf
<br>>
<br>>but is still missing the clarity of what is in scope and what not.
<br>>
<br>>The home page also has a brief (but good) mission statement:
<br>>
<br>>"CEE standardizes the way computer events are described, logged,
<br>>and
<br>>exchanged."
<br>>
<br>>If I merge these two, I see that the CEE effort is
<br>>
<br>>a) limited to the domain of computer systems [so why was that
<br>>discussed
<br>>just recently?]
<br>>b) finds an upper bound at "We note that CEE focuses on individual
<br>>device-generated events, not on whole security incidents." (in
<br>>section 2
<br>>of above paper) [why? CEE does not apply to supersets?]
<br>>c) applies to "the industry" (multiple findings) [who is "the
<br>>industry"?]
<br>>d) in some places "practical" is use as a limit of CEE [what does
<br>>"practical" in CEE mean?]
<br>>
<br>>It may be my inability to find the proper charter statement, but
<br>>from
<br>>what I see it looks like the discussion provides room for so many
<br>>points
<br>>of view because there is no clear definition of what are the
<br>>limits of
<br>>CEE. Also, the current documents describe the scope of the effort
<br>>in
<br>>terms which shall be defined by the effort itself (and as such are
<br>>not
<br>>well-defined at the time they are used) - obviously something that
<br>>is
<br>>right now being addressed.
<br>>
<br>>I propose that before doing any detail definitions, CEE should
<br>>first
<br>>define its charter in precise terms and with clear bounds.
<br>>
<br>>For example, my view of logging is very detailed, probably too
<br>>detailed
<br>>for a number of applications. My definitions have the advantage
<br>>that, so
<br>>far, anything that happens inside the logging world can be
<br>>described by
<br>>them. They have the vast disadvantage, however, that they are very
<br>>abstract and may confuse others or require too much effort to
<br>>understand
<br>>for "practical" purposes (e.g. for coding). There were a number of
<br>>less
<br>>abstracted definitions given. I could agree to almost all of them.
<br>>They
<br>>may provide a much better view for "practical" purposes. This,
<br>>however,
<br>>comes at the price that they cannot describe a small set of
<br>>unusual or
<br>>complex situations. IMHO it depends much on the audience which
<br>>definition is to prefer.
<br>>
<br>>So, in my view, I would find it extremely useful if we define
<br>>
<br>>a) bounds for what CEE intends to cover
<br>>b) intended audience
<br>>
<br>>The broader a) is defined, the more generic definitions are
<br>>needed.
<br>>
<br>>Under a), I would expect answers to questions like:
<br>>
<br>>- what is the domain of this work (electronic system was given)?
<br>>- is the domain any further restricted (e.g. compliance
<br>>applications)?
<br>>- what is a system (e.g. does CEE care about transitive
<br>>relationships)?
<br>>- what is "the industry"?
<br>>
<br>>Under b), I would expect to see if CEE tries to address designers,
<br>>coders and end-users with a single set of definitions - or if it
<br>>provides different definitions for different needs.
<br>>
<br>>It would also be useful if CEE could define deliverables and goals
<br>>that
<br>>must be reached to make the effort successful (e.g. we need to
<br>>have
<br>>CEE-aware applications from at least the 80% of the top-10 vendors
<br>>from
<br>>the x industry - or: minimal level x of CEE compliance should be
<br>>made
<br>>mandatory for government bids on IT systems). What needs to be
<br>>done to
<br>>reach these goals? Are they realistic? That boils down to "why do
<br>>you
<br>>think CEE will do any better than the other - failed - approaches
<br>>listed
<br>>in the CEE doc?". That would also be a motivation for any serious
<br>>work
<br>>done on CEE (and I see that it has the potential to do more than
<br>>its
<br>>predecessors...).
<br>>
<br>>One final thought: reading the CEE docs creates the impression
<br>>that it
<br>>aims at very broad coverage (but I cannot quote a single line
<br>>where it
<br>>is clearly stated). It also claims to be "practical" (which
<br>>created the
<br>>impression of "not being theoretical, with theoretical = abstract
<br>>in
<br>>me). However, broad scope and "practical" definitions do not go
<br>>well
<br>>together. (Because a non-abstract definition needs to limit itself
<br>>to
<br>>limited representatives of a broad entity.) It may be wise to drop
<br>>either of these two requirements OR it would be useful to use a
<br>>layered
<br>>definition tree, with some very abstract definitions at the bottom
<br>>of
<br>>the pyramid (quoting Cyril) and with sufficiently well
<br>>approximations at
<br>>higher levels. That, of course, is much more work (but probably
<br>>also
<br>>much more useful).
<br>>
<br>>Let me close with my appreciation for the work done so far with
<br>>CEE.
<br>>This is useful and well done. I hope that my thoughts are useful
<br>>for the
<br>>overall progress of this effort.
<br>>
<br>>Rainer
</div></div><br /> <div class="small"><br/><img src="http://www.nabble.com/images/icon_attachment.gif" > <strong>smime.p7s</strong> (4K) <a href="http://www.nabble.com/attachment/18818687/0/smime.p7s" target="_top">Download Attachment</a></div><p>From forum: <a href="http://www.nabble.com/CEE-Discussion-List-f29471.html" embed="fixTarget[29471]" target="_top" >CEE Discussion List</a></p>tag:www.nabble.com,2006:post-18813800Re: CEE charter & Definitions2008-08-04T08:42:55Z2008-08-04T08:42:55ZDavid CorletteHi Rainer,
<br><br>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.
<br><br>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.
<br><br>>>> On Mon, Aug 4, 2008 at 7:11 AM, in message
<br><<a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=18813800&i=0" target="_top" rel="nofollow">577465F99B41C842AAFBE9ED71E70ABA44EF1E@...</a>>, Rainer
<br>Gerhards <<a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=18813800&i=1" target="_top" rel="nofollow">rgerhards@...</a>> wrote:
<div class='shrinkable-quote'><br>> Hi list,
<br>>
<br>> As I have already written, I have recently joined the CEE mailing list
<br>> after the "definition question" loganalysis list post. I sent a number
<br>> of proposals for potential definitions. After re-reading many of the
<br>> post on the CEE list, I noticed that most of us are talking about the
<br>> same terms and ideas, but from different level of details and from
<br>> different background.
<br>>
<br>> After I noticed that, I began to search for a CEE charter. I have to
<br>> admit I did not yet find a sufficiently clear definition of what CEE
<br>> itself is all about.
<br>>
<br>> This document provides a good starting point:
<br>>
<br>> <a href="http://cee.mitre.org/docs/Common_Event_Expression_White_Paper_June_2008" target="_top" rel="nofollow">http://cee.mitre.org/docs/Common_Event_Expression_White_Paper_June_2008</a>.
<br>> pdf
<br>>
<br>> but is still missing the clarity of what is in scope and what not.
<br>>
<br>> The home page also has a brief (but good) mission statement:
<br>>
<br>> "CEE standardizes the way computer events are described, logged, and
<br>> exchanged."
<br>>
<br>> If I merge these two, I see that the CEE effort is
<br>>
<br>> a) limited to the domain of computer systems [so why was that discussed
<br>> just recently?]
<br>> b) finds an upper bound at "We note that CEE focuses on individual
<br>> device-generated events, not on whole security incidents." (in section 2
<br>> of above paper) [why? CEE does not apply to supersets?]
<br>> c) applies to "the industry" (multiple findings) [who is "the
<br>> industry"?]
<br>> d) in some places "practical" is use as a limit of CEE [what does
<br>> "practical" in CEE mean?]
<br>>
<br>> It may be my inability to find the proper charter statement, but from
<br>> what I see it looks like the discussion provides room for so many points
<br>> of view because there is no clear definition of what are the limits of
<br>> CEE. Also, the current documents describe the scope of the effort in
<br>> terms which shall be defined by the effort itself (and as such are not
<br>> well-defined at the time they are used) - obviously something that is
<br>> right now being addressed.
<br>>
<br>> I propose that before doing any detail definitions, CEE should first
<br>> define its charter in precise terms and with clear bounds.
<br>>
<br>> For example, my view of logging is very detailed, probably too detailed
<br>> for a number of applications. My definitions have the advantage that, so
<br>> far, anything that happens inside the logging world can be described by
<br>> them. They have the vast disadvantage, however, that they are very
<br>> abstract and may confuse others or require too much effort to understand
<br>> for "practical" purposes (e.g. for coding). There were a number of less
<br>> abstracted definitions given. I could agree to almost all of them. They
<br>> may provide a much better view for "practical" purposes. This, however,
<br>> comes at the price that they cannot describe a small set of unusual or
<br>> complex situations. IMHO it depends much on the audience which
<br>> definition is to prefer.
<br>>
<br>> So, in my view, I would find it extremely useful if we define
<br>>
<br>> a) bounds for what CEE intends to cover
<br>> b) intended audience
<br>>
<br>> The broader a) is defined, the more generic definitions are needed.
<br>>
<br>> Under a), I would expect answers to questions like:
<br>>
<br>> - what is the domain of this work (electronic system was given)?
<br>> - is the domain any further restricted (e.g. compliance applications)?
<br>> - what is a system (e.g. does CEE care about transitive relationships)?
<br>> - what is "the industry"?
<br>>
<br>> Under b), I would expect to see if CEE tries to address designers,
<br>> coders and end-users with a single set of definitions - or if it
<br>> provides different definitions for different needs.
<br>>
<br>> It would also be useful if CEE could define deliverables and goals that
<br>> must be reached to make the effort successful (e.g. we need to have
<br>> CEE-aware applications from at least the 80% of the top-10 vendors from
<br>> the x industry - or: minimal level x of CEE compliance should be made
<br>> mandatory for government bids on IT systems). What needs to be done to
<br>> reach these goals? Are they realistic? That boils down to "why do you
<br>> think CEE will do any better than the other - failed - approaches listed
<br>> in the CEE doc?". That would also be a motivation for any serious work
<br>> done on CEE (and I see that it has the potential to do more than its
<br>> predecessors...).
<br>>
<br>> One final thought: reading the CEE docs creates the impression that it
<br>> aims at very broad coverage (but I cannot quote a single line where it
<br>> is clearly stated). It also claims to be "practical" (which created the
<br>> impression of "not being theoretical, with theoretical = abstract in
<br>> me). However, broad scope and "practical" definitions do not go well
<br>> together. (Because a non-abstract definition needs to limit itself to
<br>> limited representatives of a broad entity.) It may be wise to drop
<br>> either of these two requirements OR it would be useful to use a layered
<br>> definition tree, with some very abstract definitions at the bottom of
<br>> the pyramid (quoting Cyril) and with sufficiently well approximations at
<br>> higher levels. That, of course, is much more work (but probably also
<br>> much more useful).
<br>>
<br>> Let me close with my appreciation for the work done so far with CEE.
<br>> This is useful and well done. I hope that my thoughts are useful for the
<br>> overall progress of this effort.
<br>>
<br>> Rainer
<br></div><p>From forum: <a href="http://www.nabble.com/CEE-Discussion-List-f29471.html" embed="fixTarget[29471]" target="_top" >CEE Discussion List</a></p>tag:www.nabble.com,2006:post-18809317CEE charter & Definitions2008-08-04T04:11:43Z2008-08-04T04:11:43ZRainer GerhardsHi list,
<br><br>As I have already written, I have recently joined the CEE mailing list
<br>after the "definition question" loganalysis list post. I sent a number
<br>of proposals for potential definitions. After re-reading many of the
<br>post on the CEE list, I noticed that most of us are talking about the
<br>same terms and ideas, but from different level of details and from
<br>different background.
<br><br>After I noticed that, I began to search for a CEE charter. I have to
<br>admit I did not yet find a sufficiently clear definition of what CEE
<br>itself is all about.
<br><br>This document provides a good starting point:
<br><br><a href="http://cee.mitre.org/docs/Common_Event_Expression_White_Paper_June_2008" target="_top" rel="nofollow">http://cee.mitre.org/docs/Common_Event_Expression_White_Paper_June_2008</a>.
<br>pdf
<br><br>but is still missing the clarity of what is in scope and what not.
<br><br>The home page also has a brief (but good) mission statement:
<br><br>"CEE standardizes the way computer events are described, logged, and
<br>exchanged."
<br><br>If I merge these two, I see that the CEE effort is
<br><br>a) limited to the domain of computer systems [so why was that discussed
<br>just recently?]
<br>b) finds an upper bound at "We note that CEE focuses on individual
<br>device-generated events, not on whole security incidents." (in section 2
<br>of above paper) [why? CEE does not apply to supersets?]
<br>c) applies to "the industry" (multiple findings) [who is "the
<br>industry"?]
<br>d) in some places "practical" is use as a limit of CEE [what does
<br>"practical" in CEE mean?]
<br><br>It may be my inability to find the proper charter statement, but from
<br>what I see it looks like the discussion provides room for so many points
<br>of view because there is no clear definition of what are the limits of
<br>CEE. Also, the current documents describe the scope of the effort in
<br>terms which shall be defined by the effort itself (and as such are not
<br>well-defined at the time they are used) - obviously something that is
<br>right now being addressed.
<br><br>I propose that before doing any detail definitions, CEE should first
<br>define its charter in precise terms and with clear bounds.
<br><br>For example, my view of logging is very detailed, probably too detailed
<br>for a number of applications. My definitions have the advantage that, so
<br>far, anything that happens inside the logging world can be described by
<br>them. They have the vast disadvantage, however, that they are very
<br>abstract and may confuse others or require too much effort to understand
<br>for "practical" purposes (e.g. for coding). There were a number of less
<br>abstracted definitions given. I could agree to almost all of them. They
<br>may provide a much better view for "practical" purposes. This, however,
<br>comes at the price that they cannot describe a small set of unusual or
<br>complex situations. IMHO it depends much on the audience which
<br>definition is to prefer.
<br><br>So, in my view, I would find it extremely useful if we define
<br><br>a) bounds for what CEE intends to cover
<br>b) intended audience
<br><br>The broader a) is defined, the more generic definitions are needed.
<br><br>Under a), I would expect answers to questions like:
<br><br>- what is the domain of this work (electronic system was given)?
<br>- is the domain any further restricted (e.g. compliance applications)?
<br>- what is a system (e.g. does CEE care about transitive relationships)?
<br>- what is "the industry"?
<br><br>Under b), I would expect to see if CEE tries to address designers,
<br>coders and end-users with a single set of definitions - or if it
<br>provides different definitions for different needs.
<br><br>It would also be useful if CEE could define deliverables and goals that
<br>must be reached to make the effort successful (e.g. we need to have
<br>CEE-aware applications from at least the 80% of the top-10 vendors from
<br>the x industry - or: minimal level x of CEE compliance should be made
<br>mandatory for government bids on IT systems). What needs to be done to
<br>reach these goals? Are they realistic? That boils down to "why do you
<br>think CEE will do any better than the other - failed - approaches listed
<br>in the CEE doc?". That would also be a motivation for any serious work
<br>done on CEE (and I see that it has the potential to do more than its
<br>predecessors...).
<br><br>One final thought: reading the CEE docs creates the impression that it
<br>aims at very broad coverage (but I cannot quote a single line where it
<br>is clearly stated). It also claims to be "practical" (which created the
<br>impression of "not being theoretical, with theoretical = abstract in
<br>me). However, broad scope and "practical" definitions do not go well
<br>together. (Because a non-abstract definition needs to limit itself to
<br>limited representatives of a broad entity.) It may be wise to drop
<br>either of these two requirements OR it would be useful to use a layered
<br>definition tree, with some very abstract definitions at the bottom of
<br>the pyramid (quoting Cyril) and with sufficiently well approximations at
<br>higher levels. That, of course, is much more work (but probably also
<br>much more useful).
<br><br>Let me close with my appreciation for the work done so far with CEE.
<br>This is useful and well done. I hope that my thoughts are useful for the
<br>overall progress of this effort.
<br><br>Rainer
<br><p>From forum: <a href="http://www.nabble.com/CEE-Discussion-List-f29471.html" embed="fixTarget[29471]" target="_top" >CEE Discussion List</a></p>tag:www.nabble.com,2006:post-18808130Re: Fwd: RE: [CEE-DISCUSSION-LIST] [logs] Defining Events, Logs, and Alerts(Round 2)2008-08-04T02:25:39Z2008-08-04T02:25:39ZRainer GerhardsHi Joseph,
<br><br>On Fri, 2008-08-01 at 19:15 +0200, Wolfkiel, Joseph wrote:
<br>> I would caution against limiting "event" definitions to state changes.
<br>> There is a well established lexicon in the intrusion detection community
<br>> that a signature match against a text string is an "event," however,
<br>> there is no defined state change involved.
<br><br>I'd say it depends on what you look at. If I look from the signature
<br>matching machinery's point of view, there *is* a state change (matching
<br>state has changed from "unknown" to "match"). I elaborated on this on
<br>the loganalysis mailing list and think the post did not make it to this
<br>list here (as I was not subscribed at that time). You can find it in the
<br>archives:
<br><br><a href="http://www.loganalysis.org/pipermail/loganalysis/2008-July/000714.html" target="_top" rel="nofollow">http://www.loganalysis.org/pipermail/loganalysis/2008-July/000714.html</a><br><br>The interesting question, however, is the scope and depth CEE is trying
<br>to achive. I'll now try to find the CEE charter and will later comment
<br>on that point.
<br><br>Rainer
<br><div class='shrinkable-quote'><br>>
<br>> From a top level perspective, a compliance test resulting in an
<br>> assessment of compliance should be considered an event-- call it an
<br>> "assessment event". I just wouldn't advocate for making it a
<br>> "reportable event" from a CEE standpoint since the results formats for
<br>> OVAL and XCCDF already define timestamped reporting formats (equivalent
<br>> to audit logs) for assessment event reporting. No point in reinventing
<br>> the wheel.
<br>>
<br>> I think any definition of event should encompass conceptual metadata we
<br>> eventually want to assign an event -- start/stop time, sensor,
<br>> collection criterion, etc. I think, if we want to limit ourselves to
<br>> audit records only, then we should create a specific type of "event"
<br>> that we're defining and not create a definition of "event" that
<br>> conflicts with everyone else's -- call it an "auditable event" that is
<br>> constrained to a state change described by an audit policy , collected
<br>> in an audit log, and transmitted as an alert according to a reporting
<br>> policy.
<br>>
<br>> Lt Col Joseph L. Wolfkiel
<br>> Director, Computer Network Defense Research & Technology (CND R&T)
<br>> Program Management Office
<br>> 9800 Savage Rd Ste 6767
<br>> Ft Meade, MD 20755-6767
<br>> Commercial 410-854-5401 DSN 244-5401
<br>> Fax 410-854-6700
<br>>
<br>>
<br>>
<br>> -----Original Message-----
<br>> From: Rainer Gerhards [mailto:<a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=18808130&i=0" target="_top" rel="nofollow">rgerhards@...</a>]
<br>> Sent: Friday, August 01, 2008 11:37 AM
<br>> To: <a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=18808130&i=1" target="_top" rel="nofollow">CEE-DISCUSSION-LIST@...</a>
<br>> Subject: Re: [CEE-DISCUSSION-LIST] Fwd: RE: [CEE-DISCUSSION-LIST] [logs]
<br>> Defining Events, Logs, and Alerts(Round 2)
<br>>
<br>>
<br>> Hi David,
<br>>
<br>> you made a couple of good points. But I think it all boils down to that
<br>> we have different views of what an event is (which is further proof that
<br>> a unifying definition is needed).
<br>>
<br>> Let me explain... To me, an event is simply a set of state change
<br>> information. The debug event was caused by internal state changes
<br>> (though I agree in a subtle way, bear with me for a moment).
<br>>
<br>> In my understanding, you have described why you are not interested in
<br>> debug events, and gave some perfectly useful arguments for this
<br>> dis-interest. But we had this discussion of an as broad as possible
<br>> definition of event, just yesterday, where we came down to an
<br>> "electronic system".
<br>>
<br>> Your definition below now restricts the domain of the "electronic
<br>> system" to an "electronic auditing system". So in my point of view, you
<br>> are simply restricting the set of possible events to the subset that is
<br>> useful for some specific use case.
<br>>
<br>> There are other use cases where debugging events are useful, but (SOX)
<br>> compliance events are not. Obviously, this is the case if a debugger is
<br>> attached. I could also run a debugger offline, based on some "log file".
<br>> The later is quite uncommon (but not unseen, e.g. think about space
<br>> robots and a lot of other situations where you need to run a "debugger"
<br>> detached from what is being debugged simply because you can not access
<br>> it). The attached debug is quite common and the dominating scenario, so
<br>> debug events are typically not seen in logs. In any case, I am still of
<br>> the view that we talk about events.
<br>>
<br>> Of course, both views are correct (at least I think so ;)). The question
<br>> is what CEE will address: Is an event defined in the domain of an
<br>> "electronic system" - then we have debug events. If it is defined in the
<br>> domain of an "electronic auditing system", then we do not have them. In
<br>> this case, for my needs, I just replace "event" with "state change set"
<br>> and "event" becomes a subset of "state change sets" - those that deal
<br>> with auditing. Not much different to the view that all is an event and
<br>> than that set is restricted to those that are of interest for auditing.
<br>>
<br>> Under this scenario, I can also describe why I have "event records" as
<br>> well "non-event records" (being "state change sets" without "event")
<br>> inside a "persisted state change set stream". I just need to duplicate
<br>> all the terms. I personally would find it simpler to speak of events in
<br>> all cases and restrict them to the proper domain where needed, but
<br>> that's more or less personal taste.
<br>>
<br>> CEE needs to decide what scope it intends to cover.
<br>>
<br>> Rainer
<br>>
<br>>
<br>> On Fri, 2008-08-01 at 09:00 -0600, David Corlette wrote:
<br>> > >>> On Fri, Aug 1, 2008 at 2:44 AM, in message
<br>> > <<a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=18808130&i=2" target="_top" rel="nofollow">577465F99B41C842AAFBE9ED71E70ABA44EEFB@...</a>>,
<br>> "Rainer
<br>> > Gerhards" <<a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=18808130&i=3" target="_top" rel="nofollow">rgerhards@...</a>> wrote:
<br>> >
<br>> > >>
<br>> > >> > I don't like "data stream" as it doesn't have any connotation
<br>> with logs, in
<br>> > >> > my mind.
<br>> > >>
<br>> > >> Exactly, as I was trying to differentiate between a persisted
<br>> stream of
<br>> > >> events (could maybe be called an "event log") and an object that
<br>> > >> contains events as well as "other things" that people have been
<br>> > >> alluding to, like debug records. I'd be fine just leaving it off
<br>> and
<br>> > >> saying that's out of scope for our event standard.
<br>> > >
<br>> > > IMHO this brings up the question how to qualify an object as either
<br>> an
<br>> > > "event" or an "other thing". "Debug logs" contain "debug events" (in
<br>> my
<br>> > > POV), so why not classify them as such?
<br>> >
<br>> > Although I'm sure there are gray areas here, this distinction has
<br>> always been clear to me. A debug record in my mind has no Initiator, or
<br>> Subject if you will, in that nobody explicitly caused it to happen. An
<br>> Initiator doesn't need to be a person, but it does need to be something
<br>> that is attempting to perform operational, security, or business
<br>> functions in an environment. A debug record generated by an application
<br>> based on what it's doing internally or whether its input is corrupt is
<br>> none of these.
<br>> >
<br>> > Which isn't to say that an application might not be acting as an
<br>> Initiator and performing some activity at the same time as it is
<br>> generating debug records. But in this case it should generate a true
<br>> event record stating "I tried to do X and it failed", and then *also*
<br>> generate a traditional debug message. XDAS has specific outcome codes
<br>> designed to capture application failure states, and actually
<br>> distinguishes these from application denial states (e.g. access denied),
<br>> which I think is a critical and oft-underused distinction.
<br>> >
<br>> > As a developer, I think this distinction would be pretty clear. If
<br>> I'm sitting down and writing an app, I generate debug records so I can
<br>> tell what's going on internally. I write regular events when I try to
<br>> perform any action that a business-level administrator of the system
<br>> might possibly want to know about, especially when accessing or
<br>> modifying any object or service outside my application.
<br>> >
<br>> > > If you look at syslog, this distinction becomes quite problematic.
<br>> If we
<br>> > > say a debug record is not an event, how do we handle syslog logs
<br>> that
<br>> > > contain records that are explicitly flagged as being debug records
<br>> (be
<br>> > > virtue of their assigned priority). Does that mean that a syslog log
<br>> is
<br>> > > a superset of an event log, one that contains both events and "other
<br>> > > things"? If so, must we first build the event subset before we can
<br>> > > process a syslog log as a log? I can't think this is desired
<br>> behavior.
<br>> > > So I conclude it is counter-productive to try to exclude debug-like
<br>> > > information from the definition of an event.
<br>> >
<br>> > I think the whole point is that syslog is pretty broken, and we're
<br>> trying to fix it. Let's not get hung up on historical anachronisms.
<br>> Syslog was designed in an era when the concept of enterprise SOX audits
<br>> was not on the radar.
<br></div><p>From forum: <a href="http://www.nabble.com/CEE-Discussion-List-f29471.html" embed="fixTarget[29471]" target="_top" >CEE Discussion List</a></p>tag:www.nabble.com,2006:post-18786578Re: Defining Log, Event, and Alert (Round 2)2008-08-01T23:22:19Z2008-08-01T23:22:19ZOnwubiko, Cyril<HTML><HEAD>
<META content="MSHTML 6.00.6000.16674" name=GENERATOR></HEAD>
<BODY>
<DIV id=idOWAReplyText5025 dir=ltr>
<DIV dir=ltr><FONT face=Arial color=#000000 size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial color=#000000 size=2>
<DIV id=idOWAReplyText65132 dir=ltr>
<DIV dir=ltr><FONT face=Arial color=#000000 size=2>One approach to define a concept for a standard is to visualise the concept as a "pyramid" with a very broad base and a "sharp" or pointed top. So, we could start off from the bottom, which is very broad and then gradually narrow the definition down to a very simple, concise and achievable definition. This, in my opinion is a realistic way to approach this task of coming up with a firm definition of an event, whether it's an event from an "electronic system" or from an "IT system". The definition should still be relevant to most use cases.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>I think given the volume of emails on this, it is time for us to start pruning the contributions down to a definition that is concise, achievable and "meets the need of CEE".</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial color=#000000 size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial color=#000000 size=2>PS: Can we look at an event from a "cause and effect" standpoint? For example:</FONT></DIV>
<DIV dir=ltr><FONT face=Arial color=#000000 size=2>1. An event is generated because a traffic was allowed or denied. </FONT></DIV>
<DIV dir=ltr><FONT face=Arial color=#000000 size=2>2. An event is generated because a debugger showed an error or ran complete without an error.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial color=#000000 size=2></FONT> </DIV>
<DIV dir=ltr> </DIV></DIV>
<DIV id=idSignature87645 dir=ltr>
<DIV><FONT face=Arial color=#000000 size=2>
<DIV>
<DIV><FONT face=Arial size=2></FONT></DIV></DIV>
<DIV><FONT face=Arial size=2>
<DIV dir=ltr><FONT face=Arial size=2>Regards,</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2>Cyril</FONT></DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr>Dr. Cyril Onwubiko</FONT></DIV></DIV>
<DIV><FONT face=Arial size=2><EM></EM></FONT> </DIV>
<DIV><FONT face=Arial size=2>Intelligence and Security Assurance Chair</FONT></DIV>
<DIV>E-Security Group</DIV>
<DIV><FONT face=Arial size=2>Faculty of Computing, Information Systems and Mathematics (CISM)</FONT></DIV>
<DIV><FONT face=Arial size=2>Kingston University</FONT></DIV>
<DIV><FONT face=Arial size=2>London, UK</FONT></DIV></FONT></DIV></DIV></FONT></DIV></DIV>
<DIV id=idSignature11284 dir=ltr>
<DIV><FONT face=Arial color=#000000 size=2>
<DIV DESIGNTIMESP="15716">
<DIV DESIGNTIMESP="15716"><FONT face=Arial size=2></FONT></DIV></DIV>
<DIV DESIGNTIMESP="15716"><FONT face=Arial size=2></FONT> </DIV></FONT></DIV></DIV>
<DIV dir=ltr><BR>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> Sanford Whitehouse [mailto:<a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=18786578&i=0" target="_top" rel="nofollow">swhitehouse@...</a>]<BR><B>Sent:</B> Fri 01/08/2008 18:29<BR><B>To:</B> <a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=18786578&i=1" target="_top" rel="nofollow">CEE-DISCUSSION-LIST@...</a><BR><B>Subject:</B> Re: [CEE-DISCUSSION-LIST] Defining Log, Event, and Alert (Round 2)<BR></FONT><BR></DIV>
<DIV>
<P><FONT size=2>This is the definition of event from the dictionary. It feels good.<BR>It's the definition used at my company.<BR><BR>Event<BR>1. Something that happens or is regarded as happening; an<BR>occurrence, especially one of some importance.<BR>2. The outcome, issue, or result of anything.<BR><BR><BR>A log is a record of information, including events, determined to be<BR>worth recording. Recognizing that information other than events may<BR>exist in a log is an aspect of the challenge.<BR><BR>Sanford<BR><BR>This email has been scanned for all viruses by the MessageLabs Email<BR>Security System.<BR></FONT></P></DIV>
<BR>
This email has been scanned for all viruses by the MessageLabs Email<BR>
Security System.<BR>
</BODY></HTML><p>From forum: <a href="http://www.nabble.com/CEE-Discussion-List-f29471.html" embed="fixTarget[29471]" target="_top" >CEE Discussion List</a></p>tag:www.nabble.com,2006:post-18786381Re: Defining Log, Event, and Alert (Round 2)2008-08-01T22:45:42Z2008-08-01T22:45:42ZOnwubiko, Cyril<HTML dir=ltr><HEAD><TITLE>Re: [CEE-DISCUSSION-LIST] Defining Log, Event, and Alert (Round 2)</TITLE>
<META http-equiv=Content-Type content="text/html; charset=unicode">
<META content="MSHTML 6.00.6000.16674" name=GENERATOR></HEAD>
<BODY>
<DIV id=idOWAReplyText65132 dir=ltr>
<DIV dir=ltr><FONT face=Arial color=#000000 size=2>One approach to define a concept for a standard is to visualise the concept as a "pyramid" with a very broad base and a "sharp" or pointed top. So, we could start off from the bottom, which is very broad and then gradually narrow the definition down to a very simple, concise and achievable definition. This, in my opinion is a realistic way to approach this task of coming up with a firm definition of an event, whether it's an event from an "electronic system" or from an "IT system". The definition should still be relevant to most use cases.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>I think given the volume of emails on this, it is time for us to start pruning the contributions down to a definition that is concise, achievable and "meets the need of CEE".</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial color=#000000 size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial color=#000000 size=2>PS: can we look at an event from a "cause and effect" standpoint? For example:</FONT></DIV>
<DIV dir=ltr><FONT face=Arial color=#000000 size=2>1. An event is generated because a traffic was allowed or denied. </FONT></DIV>
<DIV dir=ltr><FONT face=Arial color=#000000 size=2>2. An event is generated because a debugger showed an error or ran complete without an error.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial color=#000000 size=2>3. One broad way I would approach the definition of an event is to look an event as being gener which is what the email trails have being showcasing. Hence, another </FONT></DIV>
<DIV dir=ltr><FONT face=Arial color=#000000 size=2></FONT> </DIV></DIV>
<DIV id=idSignature87645 dir=ltr>
<DIV><FONT face=Arial color=#000000 size=2>
<DIV DESIGNTIMESP="15716">
<DIV DESIGNTIMESP="15716"><FONT face=Arial size=2></FONT></DIV></DIV>
<DIV DESIGNTIMESP="15716"><FONT face=Arial size=2>
<DIV dir=ltr><FONT face=Arial size=2>Regards,</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2>Cyril</FONT></DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr>Dr. Cyril Onwubiko</FONT></DIV></DIV>
<DIV DESIGNTIMESP="15716"><FONT face=Arial size=2><EM></EM></FONT> </DIV>
<DIV DESIGNTIMESP="15716"><FONT face=Arial size=2>Intelligence and Security Assurance Chair</FONT></DIV>
<DIV DESIGNTIMESP="15716">E-Security Group</DIV>
<DIV DESIGNTIMESP="15716"><FONT face=Arial size=2>Faculty of Computing, Information Systems and Mathematics (CISM)</FONT></DIV>
<DIV DESIGNTIMESP="15716"><FONT face=Arial size=2>Kingston University</FONT></DIV>
<DIV DESIGNTIMESP="15716"><FONT face=Arial size=2>London, UK</FONT></DIV></FONT></DIV></DIV>
<DIV dir=ltr><BR>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> Sanford Whitehouse [mailto:<a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=18786381&i=0" target="_top" rel="nofollow">swhitehouse@...</a>]<BR><B>Sent:</B> Fri 01/08/2008 18:29<BR><B>To:</B> <a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=18786381&i=1" target="_top" rel="nofollow">CEE-DISCUSSION-LIST@...</a><BR><B>Subject:</B> Re: [CEE-DISCUSSION-LIST] Defining Log, Event, and Alert (Round 2)<BR></FONT><BR></DIV>
<DIV>
<P><FONT size=2>This is the definition of event from the dictionary. It feels good.<BR>It's the definition used at my company.<BR><BR>Event<BR>1. Something that happens or is regarded as happening; an<BR>occurrence, especially one of some importance.<BR>2. The outcome, issue, or result of anything.<BR><BR><BR>A log is a record of information, including events, determined to be<BR>worth recording. Recognizing that information other than events may<BR>exist in a log is an aspect of the challenge.<BR><BR>Sanford<BR><BR>This email has been scanned for all viruses by the MessageLabs Email<BR>Security System.<BR></FONT></P></DIV>
<BR>
This email has been scanned for all viruses by the MessageLabs Email<BR>
Security System.<BR>
</BODY></HTML><p>From forum: <a href="http://www.nabble.com/CEE-Discussion-List-f29471.html" embed="fixTarget[29471]" target="_top" >CEE Discussion List</a></p>tag:www.nabble.com,2006:post-18779756Welcome all and thanks for the insight2008-08-01T10:55:47Z2008-08-01T10:55:47ZDurrant, Sheldon A.<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=EN-US link=blue vlink=purple>
<div class=Section1>
<p class=MsoNormal>Hello, everyone. My name is Sheldon Durrant and I’m an
Infosec Engineer/Scientist working with Bill Heinbockel and Rosalie McQuaid on
CEE at MITRE. I’ve been lurking quite a bit on the List taking in all the
comments thus far and thought it was high time I introduced myself! <o:p></o:p></p>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoNormal>I’d like to welcome all to the discussion list and to
thank everyone for the truly insightful contributions to the list content. I’ve
been learning a lot from reading the goings-on on the list thus far. I hope
everyone’s getting as much from the content as I am. Bill and I came up
with all of the initial definitions that kicked this discussion off, so it’s
refreshing, interesting, and informative to see the quantity and quality of
debate and discussion that has ensued from that.<o:p></o:p></p>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoNormal>In response to Gail’s concerns about supporting business
applications as well as networking, the goal of CEE is to create an extensible
structure that is widely applicable across many different use cases. I like to
avoid using clichés where I can, but I think “plug-and-play” would
be a good way to describe what we would want the final standard to look like; a
unified core that we can all help to develop, and an extension capability for
outliers. That’s why I think the current discussions about definitions
are so important; it helps everyone speak a common language, and we can move on
from there to determine the use cases that fit in the scope for a well-defined
core CEE structure (based on our final definitions) and what should not be in
the core. We can then create mechanisms so that others can extend the core to
meet their individual use cases that we either haven’t accounted for, or
are so unique as to be “non-standard.” In short, we would want CEE
to be general enough to meet many use cases, but not so overly broad to invite
the kind of “kitchen sink” mentality that causes overloaded
terminology and arbitrary implementations that has rendered so many other
standards useless in practice.<o:p></o:p></p>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoNormal>Again, thanks to everyone for keeping this interesting and
informative. You’ll definitely hear more from me as time goes on,
particularly when we get to the point where it makes sense for list members to break
up into teams to work on specific tasks.<o:p></o:p></p>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'>Sheldon
A. Durrant</span><o:p></o:p></p>
<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'>Infosec
Engineer/Scientist</span><o:p></o:p></p>
<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'>The
MITRE Corporation<o:p></o:p></span></p>
<p class=MsoNormal><o:p> </o:p></p>
</div>
</body>
</html>
<p>From forum: <a href="http://www.nabble.com/CEE-Discussion-List-f29471.html" embed="fixTarget[29471]" target="_top" >CEE Discussion List</a></p>tag:www.nabble.com,2006:post-18779429Re: Defining Log, Event, and Alert (Round 2)2008-08-01T10:36:06Z2008-08-01T10:36:06ZEric FitzgeraldThanks Gail!
<br><br>I will make sure to bring up your feedback in any discussions that we have. (As a side note I also strongly agree).
<br><br>Best regards,
<br>Eric
<br><br><div class='shrinkable-quote'><br>> -----Original Message-----
<br>> From: Reynolds, Gail K [mailto:<a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=18779429&i=0" target="_top" rel="nofollow">gail.reynolds@...</a>]
<br>> Sent: Friday, August 01, 2008 6:05 AM
<br>> To: <a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=18779429&i=1" target="_top" rel="nofollow">CEE-DISCUSSION-LIST@...</a>
<br>> Subject: Re: [CEE-DISCUSSION-LIST] Defining Log, Event, and Alert
<br>> (Round 2)
<br>>
<br>> I learned of CEE at Catalyst Conference and recently joined the list.
<br>>
<br>> As someone who attempts to architect security for an insurance company,
<br>> I'd like to emphasize my requirement that this standard pertain to
<br>> business applications (purchased and developed internally) as well as
<br>> core infrastructure and network.
<br>>
<br>> Gail
<br>>
<br>>
<br>>
<br>> -----Original Message-----
<br>> From: Sanford Whitehouse [mailto:<a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=18779429&i=2" target="_top" rel="nofollow">swhitehouse@...</a>]
<br>> Sent: Thursday, July 31, 2008 7:18 PM
<br>> To: <a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=18779429&i=3" target="_top" rel="nofollow">CEE-DISCUSSION-LIST@...</a>
<br>> Subject: Re: [CEE-DISCUSSION-LIST] Defining Log, Event, and Alert
<br>> (Round
<br>> 2)
<br>>
<br>> In my mind "IT system" creates an image of events reported by systems
<br>> that involve the systems themselves or what the systems do to support
<br>> the apps running on them.
<br>>
<br>> If the definition is to include anything from creating a file system to
<br>> what an accounting app logs as a transaction, the "IT system"
<br>> qualification isn't necessary. It applies to the standard as a whole,
<br>> not the definition of event. Then, the definition should focus on the
<br>> distinctions between an event and the set of non-events that are
<br>> recorded.
<br>>
<br>> Sanford
<br>>
<br>> -----Original Message-----
<br>> From: Eric Fitzgerald [mailto:<a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=18779429&i=4" target="_top" rel="nofollow">Eric.Fitzgerald@...</a>]
<br>> Sent: Thursday, July 31, 2008 1:11 PM
<br>> To: Sanford Whitehouse; <a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=18779429&i=5" target="_top" rel="nofollow">CEE-DISCUSSION-LIST@...</a>
<br>> Subject: RE: [CEE-DISCUSSION-LIST] Defining Log, Event, and Alert
<br>> (Round
<br>> 2)
<br>>
<br>> Sanford Whitehouse wrote:
<br>> > An event is not limited to an IT system. It can be anything. A
<br>> > accounting app stating an entry has been posted. An oil pipeline
<br>>
<br>> Is an accounting app not part of an IT system? Is a SCADA sensor not
<br>> part of an IT system? It was my intention to capture all such cases.
<br>>
<br>> I am not stuck on the term "IT system", I'd welcome a better term if
<br>> you
<br>> have one, but don't clutter the definition and don't make it overbroad
<br>> so that it includes people writing things down on paper, etc.
<br>>
<br>> Eric
<br>> This e-mail may contain confidential or privileged information. If
<br>> you think you have received this e-mail in error, please advise the
<br>> sender by reply e-mail and then delete this e-mail immediately.
<br>> Thank you. Aetna
<br></div><p>From forum: <a href="http://www.nabble.com/CEE-Discussion-List-f29471.html" embed="fixTarget[29471]" target="_top" >CEE Discussion List</a></p>tag:www.nabble.com,2006:post-18779324Re: Defining Log, Event, and Alert (Round 2)2008-08-01T10:29:24Z2008-08-01T10:29:24ZSanford WhitehouseThis is the definition of event from the dictionary. It feels good.
<br>It's the definition used at my company.
<br><br>Event
<br>1. Something that happens or is regarded as happening; an
<br>occurrence, especially one of some importance.
<br>2. The outcome, issue, or result of anything.
<br><br><br>A log is a record of information, including events, determined to be
<br>worth recording. Recognizing that information other than events may
<br>exist in a log is an aspect of the challenge.
<br><br>Sanford
<br><p>From forum: <a href="http://www.nabble.com/CEE-Discussion-List-f29471.html" embed="fixTarget[29471]" target="_top" >CEE Discussion List</a></p>tag:www.nabble.com,2006:post-18779052Re: Fwd: RE: [CEE-DISCUSSION-LIST] [logs] Defining Events, Logs, and Alerts(Round 2)2008-08-01T10:15:08Z2008-08-01T10:15:08ZWolfkiel, JosephI would caution against limiting "event" definitions to state changes.
<br>There is a well established lexicon in the intrusion detection community
<br>that a signature match against a text string is an "event," however,
<br>there is no defined state change involved.
<br><br>From a top level perspective, a compliance test resulting in an
<br>assessment of compliance should be considered an event-- call it an
<br>"assessment event". I just wouldn't advocate for making it a
<br>"reportable event" from a CEE standpoint since the results formats for
<br>OVAL and XCCDF already define timestamped reporting formats (equivalent
<br>to audit logs) for assessment event reporting. No point in reinventing
<br>the wheel.
<br><br>I think any definition of event should encompass conceptual metadata we
<br>eventually want to assign an event -- start/stop time, sensor,
<br>collection criterion, etc. I think, if we want to limit ourselves to
<br>audit records only, then we should create a specific type of "event"
<br>that we're defining and not create a definition of "event" that
<br>conflicts with everyone else's -- call it an "auditable event" that is
<br>constrained to a state change described by an audit policy , collected
<br>in an audit log, and transmitted as an alert according to a reporting
<br>policy.
<br><br>Lt Col Joseph L. Wolfkiel
<br>Director, Computer Network Defense Research & Technology (CND R&T)
<br>Program Management Office
<br>9800 Savage Rd Ste 6767
<br>Ft Meade, MD 20755-6767
<br>Commercial 410-854-5401 DSN 244-5401
<br>Fax 410-854-6700
<br><br><br><br>-----Original Message-----
<br>From: Rainer Gerhards [mailto:<a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=18779052&i=0" target="_top" rel="nofollow">rgerhards@...</a>]
<br>Sent: Friday, August 01, 2008 11:37 AM
<br>To: <a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=18779052&i=1" target="_top" rel="nofollow">CEE-DISCUSSION-LIST@...</a>
<br>Subject: Re: [CEE-DISCUSSION-LIST] Fwd: RE: [CEE-DISCUSSION-LIST] [logs]
<br>Defining Events, Logs, and Alerts(Round 2)
<br><br><br>Hi David,
<br><br>you made a couple of good points. But I think it all boils down to that
<br>we have different views of what an event is (which is further proof that
<br>a unifying definition is needed).
<br><br>Let me explain... To me, an event is simply a set of state change
<br>information. The debug event was caused by internal state changes
<br>(though I agree in a subtle way, bear with me for a moment).
<br><br>In my understanding, you have described why you are not interested in
<br>debug events, and gave some perfectly useful arguments for this
<br>dis-interest. But we had this discussion of an as broad as possible
<br>definition of event, just yesterday, where we came down to an
<br>"electronic system".
<br><br>Your definition below now restricts the domain of the "electronic
<br>system" to an "electronic auditing system". So in my point of view, you
<br>are simply restricting the set of possible events to the subset that is
<br>useful for some specific use case.
<br><br>There are other use cases where debugging events are useful, but (SOX)
<br>compliance events are not. Obviously, this is the case if a debugger is
<br>attached. I could also run a debugger offline, based on some "log file".
<br>The later is quite uncommon (but not unseen, e.g. think about space
<br>robots and a lot of other situations where you need to run a "debugger"
<br>detached from what is being debugged simply because you can not access
<br>it). The attached debug is quite common and the dominating scenario, so
<br>debug events are typically not seen in logs. In any case, I am still of
<br>the view that we talk about events.
<br><br>Of course, both views are correct (at least I think so ;)). The question
<br>is what CEE will address: Is an event defined in the domain of an
<br>"electronic system" - then we have debug events. If it is defined in the
<br>domain of an "electronic auditing system", then we do not have them. In
<br>this case, for my needs, I just replace "event" with "state change set"
<br>and "event" becomes a subset of "state change sets" - those that deal
<br>with auditing. Not much different to the view that all is an event and
<br>than that set is restricted to those that are of interest for auditing.
<br><br>Under this scenario, I can also describe why I have "event records" as
<br>well "non-event records" (being "state change sets" without "event")
<br>inside a "persisted state change set stream". I just need to duplicate
<br>all the terms. I personally would find it simpler to speak of events in
<br>all cases and restrict them to the proper domain where needed, but
<br>that's more or less personal taste.
<br><br>CEE needs to decide what scope it intends to cover.
<br><br>Rainer
<br><br><br>On Fri, 2008-08-01 at 09:00 -0600, David Corlette wrote:
<br>> >>> On Fri, Aug 1, 2008 at 2:44 AM, in message
<br>> <<a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=18779052&i=2" target="_top" rel="nofollow">577465F99B41C842AAFBE9ED71E70ABA44EEFB@...</a>>,
<br>"Rainer
<br>> Gerhards" <<a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=18779052&i=3" target="_top" rel="nofollow">rgerhards@...</a>> wrote:
<br>>
<br>> >>
<br>> >> > I don't like "data stream" as it doesn't have any connotation
<br>with logs, in
<br>> >> > my mind.
<br>> >>
<br>> >> Exactly, as I was trying to differentiate between a persisted
<br>stream of
<br>> >> events (could maybe be called an "event log") and an object that
<br>> >> contains events as well as "other things" that people have been
<br>> >> alluding to, like debug records. I'd be fine just leaving it off
<br>and
<br>> >> saying that's out of scope for our event standard.
<br>> >
<br>> > IMHO this brings up the question how to qualify an object as either
<br>an
<br>> > "event" or an "other thing". "Debug logs" contain "debug events" (in
<br>my
<br>> > POV), so why not classify them as such?
<br>>
<br>> Although I'm sure there are gray areas here, this distinction has
<br>always been clear to me. A debug record in my mind has no Initiator, or
<br>Subject if you will, in that nobody explicitly caused it to happen. An
<br>Initiator doesn't need to be a person, but it does need to be something
<br>that is attempting to perform operational, security, or business
<br>functions in an environment. A debug record generated by an application
<br>based on what it's doing internally or whether its input is corrupt is
<br>none of these.
<br>>
<br>> Which isn't to say that an application might not be acting as an
<br>Initiator and performing some activity at the same time as it is
<br>generating debug records. But in this case it should generate a true
<br>event record stating "I tried to do X and it failed", and then *also*
<br>generate a traditional debug message. XDAS has specific outcome codes
<br>designed to capture application failure states, and actually
<br>distinguishes these from application denial states (e.g. access denied),
<br>which I think is a critical and oft-underused distinction.
<br>>
<br>> As a developer, I think this distinction would be pretty clear. If
<br>I'm sitting down and writing an app, I generate debug records so I can
<br>tell what's going on internally. I write regular events when I try to
<br>perform any action that a business-level administrator of the system
<br>might possibly want to know about, especially when accessing or
<br>modifying any object or service outside my application.
<br>>
<br>> > If you look at syslog, this distinction becomes quite problematic.
<br>If we
<br>> > say a debug record is not an event, how do we handle syslog logs
<br>that
<br>> > contain records that are explicitly flagged as being debug records
<br>(be
<br>> > virtue of their assigned priority). Does that mean that a syslog log
<br>is
<br>> > a superset of an event log, one that contains both events and "other
<br>> > things"? If so, must we first build the event subset before we can
<br>> > process a syslog log as a log? I can't think this is desired
<br>behavior.
<br>> > So I conclude it is counter-productive to try to exclude debug-like
<br>> > information from the definition of an event.
<br>>
<br>> I think the wh