Mailing List Archives Now Available

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

Mailing List Archives Now Available

heinbockel

For those of you who may not be on the CEE Announce
Mailing list, after many requests, I just want to
let all of you know that the archives for both the
cee-announce and cee-discussion lists are now available
on Nabble.com.
URL: http://www.nabble.com/CEE-Log-Event-Standard-f30667.html

A link will also be on the CEE website when the update
goes live.


William Heinbockel
Infosec Engineer, Sr.
The MITRE Corporation
202 Burlington Rd. MS S145
Bedford, MA 01730
[hidden email]
781-271-2615

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

Re: Mailing List Archives Now Available

Raffael Marty-3
This is great, Bill! Are the archives real-time or are they updated on  
a schedule?

Thx

   -raffy

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



On Feb 7, 2008, at 11:54 AM, Heinbockel, Bill wrote:

>
> For those of you who may not be on the CEE Announce
> Mailing list, after many requests, I just want to
> let all of you know that the archives for both the
> cee-announce and cee-discussion lists are now available
> on Nabble.com.
> URL: http://www.nabble.com/CEE-Log-Event-Standard-f30667.html
>
> A link will also be on the CEE website when the update
> goes live.
>
>
> William Heinbockel
> Infosec Engineer, Sr.
> The MITRE Corporation
> 202 Burlington Rd. MS S145
> Bedford, MA 01730
> [hidden email]
> 781-271-2615
Reply | Threaded
Open this post in threaded view
|

Re: Mailing List Archives Now Available

heinbockel

Why don't you check them out for yourself?!

They are updated in near realtime. Probably a
delay of a couple of minutes from when the
e-mail is sent and the archive is updated.


William Heinbockel
Infosec Engineer, Sr.
The MITRE Corporation
202 Burlington Rd. MS S145
Bedford, MA 01730
[hidden email]
781-271-2615

>-----Original Message-----
>From: Raffael Marty [mailto:[hidden email]]
>Sent: Thursday, 07 February, 2008 15:01
>To: cee-discussion-list CEE-Related Discussion
>Subject: Re: [CEE-DISCUSSION-LIST] Mailing List Archives Now Available
>
>This is great, Bill! Are the archives real-time or are they
>updated on  
>a schedule?
>
>Thx
>
>   -raffy
>
>--
>   Raffael Marty
>   Chief Security Strategist                           @ Splunk>
>   Security Visualization: http://secviz.org       raffy.ch/blog
>
>
>
>On Feb 7, 2008, at 11:54 AM, Heinbockel, Bill wrote:
>
>>
>> For those of you who may not be on the CEE Announce
>> Mailing list, after many requests, I just want to
>> let all of you know that the archives for both the
>> cee-announce and cee-discussion lists are now available
>> on Nabble.com.
>> URL: http://www.nabble.com/CEE-Log-Event-Standard-f30667.html
>>
>> A link will also be on the CEE website when the update
>> goes live.
>>
>>
>> William Heinbockel
>> Infosec Engineer, Sr.
>> The MITRE Corporation
>> 202 Burlington Rd. MS S145
>> Bedford, MA 01730
>> [hidden email]
>> 781-271-2615
>

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

Questions, thoughts & ideas re: CEE

Sullivan, Dan [BSD] - ADM
In reply to this post by Raffael Marty-3
Hi Everyone,

My name is Dan Sullivan and I work as an information security
administrator at the University of Chicago.  I am excited for the
opportunity to participate in forming the CEE standard.  I've read
through all of the mailing list threads and the whitepaper, and as a
result have some feature 'wants' and a few questions I was hoping
somebody could help me clarify as to the scope of this project;

With respect to CEE's taxonomy, I think that expressing whether or not a
particular CEE log was created as a direct result of processing another
inbound CEE log would be useful.  I think it would be audit-conscious if
the CEE taxonomy allowed for expressing all other CEE logs that created
a condition causing a particular CEE log to be generated.   The CEE
specification would then have an inherent auditing mechanism for devices
to account for their reactive behavior in regards to other CEE log
messages (or potentially even any inbound message type, such as SNMP, or
OPSEC LEA, WMI, etc).
 
I guess this type of event would probably fit into the taxonomy as an
event of type "Response Event, or "Response to multiple events" which
would essentially mean that CEE could also be used as a sort of
auditable rudimentary asynchronous communication; (i.e. it allows a
response to be expressed in terms of its stimuli).  Traditionally, I
think of logging as more of a record of the stimuli, much less a record
of the response.   I feel like I'm missing something big here or that I
could be looking at this the wrong way, so just throw a brick at me if
I'm way out in left field with this notion of "stimulus vs. response".
I realize that CEE isn't a bidirectional communications protocol and I
don't want to overcomplicate things with this type of a suggestion, but
I would like to hear if anybody has any thoughts about the topic.

Now where this next feature falls is not entirely clear to me, but I
think it would be useful to be able to uniquely identify each individual
CEE log with a single value or string; this would provide a basic
mechanism to reference a single event, which could be used as a sort of
Dewey decimal system for identifying log events.  This unique identifier
could be used by applications that leverage CEE data or by systems
administrators as a way of expressing a single event that occurred in
the past.  

I'm guessing that if we do need a unique value, actually generating it
would probably fall under transport.  I'll throw out the idea of using
the concatenation of a unique identifier for the CEE log generating node
(for example IP or hostname), a date/timestamp, and a rolling 1-65536
(kind of like TCP sequencing).  This rolling sequence number (and
potentially other metadata), would somehow (optionally?) have to be
attached to the raw log.  Would concatenating host and a timestamp be
enough, or would we really need a uniquely generated value?   Is
association and storage of metadata with the raw log data something that
we can mandate as part of the overall CEE specification?

For transport, should my mindset be similar to that of the OSI model,
where there is an IP packet with a header holding all of the metadata
associated with the event, and then the CEE event itself encapsulated
within the payload?  Because if so, great; I think it would be awesome
to have a framework for storing metadata that indicates relevance to
compliance, retention periods, secure handling, notation of sensitive
fields within the taxonomy, etc.  That way, applications that are
developed in-house could be tailored to pre-populate these fields prior
to transport, and as CEE gets widespread adoption, developers of
commercial applications and vendors for embedded hardware could hardcode
functionality to tweak these fields for specific event types within the
taxonomy.    Long term, maybe we could even come up with a header
taxonomy that dictates how a devices behaves with respect to offloading
and relaying logs, for example changing a service to 'read-only' if a
certain event type can't be delivered with guaranteed transport,
essentially running in "CEE mode " to ensure a strictly enforced audit
trail.  Have there been talks about developing an actual transport
protocol specifically for the CEE event log format? With respect to the
CEE specification, are we supposed to be thinking in these grandiose
terms?

Additionally, I wanted to ask that a consideration be made for the CEE
taxonomy to support multiple values in its fields.  For example, if two
CEE messages from two different devices triggered an action in another,
a CEE message generated as a result of the processing would identify the
causal messages in separate fields, such as stimulusCEE1 and
stimulusCEE2; not in stimulusCEE, a comma-delimited field holding
multiple values.  Ideally, I would like to see a log message syntax
chosen that allows the complete CEE logs of the triggering events to be
populated into these separate fields, not just their unique message
identifiers.  I'm not sure exactly what this would be called, maybe
structured extensibility dictated by taxonomy or something?

A consideration with respect to CEE syntax is that I would like to see
support for storing raw or encoded media in event payloads, for example
a JPG capture from a camera in a data center that logs an image every 2
seconds.

I know I made some technical leaps and wasn't on par conceptually or
technically with a lot of this, but I just wanted to get some of my
ideas down on paper.  I would appreciate any feedback.

Cheers,

Dan Sullivan
Security Administrator
BSD Infosec
 
Ph: 773.834.0740
[hidden email]



This email is intended only for the use of the individual or entity to which it is addressed and may contain information that is privileged and confidential. If the reader of this email message is not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication is prohibited. If you have received this email in error, please notify the sender and destroy/delete all copies of the transmittal. Thank you.
Reply | Threaded
Open this post in threaded view
|

Questions, thoughts & ideas re: CEE

David Corlette
Hello Dan,

Lot to comment on here, but I'll restrict myself to:



----------------
David Corlette
GRC Solution Architect
[hidden email]
703.663.5517

Novell, Inc.
Secure Your Enterprise with Sentinel from Novell
http://www.novell.com/products/sentinel/













>>> On Tue, Feb 12, 2008 at  3:30 AM, in message
<[hidden email]>,
"Sullivan, Dan [BSD] - ADM" <[hidden email]> wrote:
> Hi Everyone,
>  
> A consideration with respect to CEE syntax is that I would like to see
> support for storing raw or encoded media in event payloads, for example
> a JPG capture from a camera in a data center that logs an image every 2
> seconds.

This would make the protocol too heavyweight; better would be to include a reference to where the binary data could be retrieved from.  So for example in XDAS there is a concept of a "Source Reference URL" - the intent is to provide a URI to allow the XDAS user to follow a trail back to the original, possibly more descriptive event:

"Source Reference URL * The source reference URL is an optional component of an audit event record and is provided by the caller. It is a pointer to the original audit event record for those records that have been imported to the XDAS service from a domain-specific audit service. The intention is that this information provides the location of the audit record within the original domain, if more detailed analysis is required. This information is provided by the original domain when calling the XDAS import API."

The way I would see this playing out is that if an application as part of its log wanted to include large binary chunks of information, it would log that locally, and then create a CEE event (with XDAS encoding) that includes a reference to the original data. Ideally a web service would be provided to serve up the full log data on demand.

This would be generally useful for the photo application you mention, and also for IDSs that capture the raw packet data of an attack, for example.