Updated CEE Whitepaper for review

[heinbockel]

Just in case some of you were wondering what you
should do over the extended weekend, attached
is some potential reading material...

I have updated the whitepaper to address most of
the feedback I received over the past couple of
weeks. I am anticipating that this will be the last
round of reviews before the whitepaper is formatted
and submitted for public release. So, speak now and
flood the discussion list with feedback.



Have a great (holiday) weekend,

William Heinbockel
Infosec Engineer, Sr.
The MITRE Corporation
202 Burlington Rd. MS S145
Bedford, MA 01730
heinbockel@...
781-271-2615

[Caudle, Rodney]

Here's my thoughts on the whitepaper:

(1) No mention of High Availability, Disaster Recovery or other uses of
multiple-event stream scenarios.  Perhaps this was decided that it
didn't need to be covered by CEE.  If not then designing this into the
CLT layer would be advantageous for adoption.

(2) What about encryption of data or non-repudiation (certificates) of
event sources?  Should these be covered by CEE?  In the CLT section or
another section?

(3) Pages 12/13 cover various possibilities for transport + syntax.
However, none of these possibilities cover a cooperative system where
the event producer registers with the event consumer thus reducing the
amount of information it needs to send with each event.  Consider the
scenario where EPA (event producer A) connects to the event consumer ECB
(event consumer B).  Upon initialization of this connection ECB assigns
EPA a unique ID for sending events to it:  "EPA, use id 1234567890ABCDEF
for your identifier when you send me events".  EPA responds and says
"OK, I'll be sending the following events 1,3,7,13a,25b,49".  Because
CEE controls the expression of events with the CEET layer we know what
fields will be needed for the events identified by 1,3,7,etc.  This
means that EPA only needs to send the information that changes with each
event thus reducing the amount of overhead and increasing the speed of
the connection.  If we consider cooperative transportation then there
may be other possibilities for these pages.  Also, text-only transport
becomes more efficient under a cooperative system.

(4) What about utilizing multiple timestamps?  (Event Timestamp,
Recorded Timestamp, and Logged Timestamp)  Are multiple timestamps a
valid concern for CEE?

(5) Should there be a different example than the oil pipeline example?
The recommendation for SCADA systems that follow good security
engineering is not to connect them to the Internet.  Should we pick a
different example that more closely aligns with good security practices?


Please feel free to respond.

Thanks,
Rodney Caudle
Lead Security Architect
Northrop Grumman - VITA

[heinbockel]

Thank you for the feedback; my comments are inline.

Also, I would like to make clear that the purpose of the whitepaper
is not to cover CEE specification or implementation details. It is
simply to explain the effort and to set forth why a "new" logging
standard is necessary.


>-----Original Message-----
>From: Caudle, Rodney [mailto:Rodney.Caudle@...]
>Sent: Monday, 12 November, 2007 10:54
>To: cee-discussion-list CEE-Related Discussion
>Subject: Re: [CEE-DISCUSSION-LIST] Updated CEE Whitepaper for review
>
>Here's my thoughts on the whitepaper:
>
>(1) No mention of High Availability, Disaster Recovery or other uses
of
>multiple-event stream scenarios.  Perhaps this was decided that it
>didn't need to be covered by CEE.  If not then designing this into the
>CLT layer would be advantageous for adoption.
>
Actually, we have not discussed the possibility of addressing Disaster
Recovery in CEE. Personally, I have little familiarity in this area and
implore any of you that are interested having this sort of support
covered by CEE to submit proposals to this discussion list. I am not
saying
that it will or will not be added, but it has no chance of being
supported
if nobody proposes it.

For example, what are some examples of such scenarios (for those not
familiar)?
What elements would need to be covered by the transport to support the
use
cases?


>(2) What about encryption of data or non-repudiation (certificates) of
>event sources?  Should these be covered by CEE?  In the CLT section or
>another section?
>
This is one topic that I plan for CEE to address as part of the
transport.
However, this is outside the scope of the whitepaper. The purpose of
the
whitepaper is to motivate the need and possibilities of a log standard
and
address what sets CEE apart from other attempts at a log standard.
Implementation and support level details were intentionally left out of
the
paper. I plan on drafting papers that will cover the components
individually.
I will keep these issues in mind and will actively encourage this
community to contribute to the component-level requirements and
details.


>(3) Pages 12/13 cover various possibilities for transport + syntax.
>However, none of these possibilities cover a cooperative system where
>the event producer registers with the event consumer thus reducing the
>amount of information it needs to send with each event.  Consider the
>scenario where EPA (event producer A) connects to the event
>consumer ECB
>(event consumer B).  Upon initialization of this connection ECB
assigns

>EPA a unique ID for sending events to it:  "EPA, use id
>1234567890ABCDEF
>for your identifier when you send me events".  EPA responds and says
>"OK, I'll be sending the following events 1,3,7,13a,25b,49".  Because
>CEE controls the expression of events with the CEET layer we know what
>fields will be needed for the events identified by 1,3,7,etc.  This
>means that EPA only needs to send the information that changes
>with each
>event thus reducing the amount of overhead and increasing the speed of
>the connection.  If we consider cooperative transportation then there
>may be other possibilities for these pages.  Also, text-only transport
>becomes more efficient under a cooperative system.
>

I have seen this approach adopted by several other standards. Right now
this issue has not been addressed as far as if and how CEE might
support
such a functionality.


>(4) What about utilizing multiple timestamps?  (Event Timestamp,
>Recorded Timestamp, and Logged Timestamp)  Are multiple timestamps a
>valid concern for CEE?
>
Timestamps as well as timezones (and DST) are all issues with today's
logging standards. Support for multiple timestamps will likely be
supported in the syntax.


>
>(5) Should there be a different example than the oil pipeline example?
>The recommendation for SCADA systems that follow good security
>engineering is not to connect them to the Internet.  Should we pick a
>different example that more closely aligns with good security
>practices?
>
The pipeline is obviously a hypothetical example. I am willing to
consider other, more "real world" examples if anyone would like
to offer some up...



William Heinbockel
Infosec Engineer, Sr.
The MITRE Corporation
202 Burlington Rd. MS S145
Bedford, MA 01730
heinbockel@...
781-271-2615

[Anton Chuvakin]

> >(4) What about utilizing multiple timestamps?  (Event Timestamp,
> >Recorded Timestamp, and Logged Timestamp)  Are multiple timestamps a
> >valid concern for CEE?
> >
> Timestamps as well as timezones (and DST) are all issues with today's
> logging standards. Support for multiple timestamps will likely be
> supported in the syntax.

Yes, this is needed to be remembered. Multiple timestamps are
sufficiently painful now; thus, CEE effort needs to cover them. For
example,

MUST HAVE - event timestamp
OPTIONAL (if different) - recorded timestamp
OPTIONAL (if available) - when received by log management system

etc


--
Anton Chuvakin, Ph.D., GCIA, GCIH, GCFA
      http://www.chuvakin.org
  http://chuvakin.blogspot.com
    http://www.info-secure.org

[Caudle, Rodney]

<snip>
>(1) No mention of High Availability, Disaster Recovery or other uses
of
>multiple-event stream scenarios.  Perhaps this was decided that it
>didn't need to be covered by CEE.  If not then designing this into the
>CLT layer would be advantageous for adoption.
>
Actually, we have not discussed the possibility of addressing Disaster
Recovery in CEE. Personally, I have little familiarity in this area and
implore any of you that are interested having this sort of support
covered by CEE to submit proposals to this discussion list. I am not
saying that it will or will not be added, but it has no chance of being
supported if nobody proposes it.

For example, what are some examples of such scenarios (for those not
familiar)?
What elements would need to be covered by the transport to support the
use cases?
</snip>

Two scenarios to consider for CEE

(1) The first scenario is the "one-to-many" ... One event producer to
many event receivers.  In a disaster recovery scenario the primary event
receiver consolidation point would be unavailable.  In this case CEE
could provide for the capabilities of transmitting to multiple event
receivers from one event producer.

(2) The second scenario is the "one-to-one conditional"... One event
producer forwards events to many event receivers but only forwards each
event once.  This scenario would support delivery of events from event
producers according to criteria of the event.  (web server events to one
receiver, firewall events to another receiver)

I hope this is an acceptable level of detail at this time.  Please let
me know if I should submit proposals in a specific format and I will do
so.

Regards,
Rodney Caudle
Lead Security Architect
Northrop Grumman - VITA