xml documentation

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

Re: event integrity RE: [CEE-DISCUSSION-LIST] xml documentation

David Corlette
As a point of discussion, I would modify "APPEND" to be something more like "ATTACH" - in our view, the original message is the original message, and should be untouched. As a SIEM, we can *attach* additional context and metadata to the event, and we can extract and analyze the data within the event (e.g. to calculate a subnet from an IP, for example), but the original data is untouched and unmodified.

Also note that compliance regs, when they talk about forensic value of events, are talking about the *original* message only - since everything that happens after that is a repeatable, algorithm-driven process, in theory even if all that data is lost it can be reconstructed from the original event only.

The approach we take in Novell's Sentinel Log Manager, for reference, is that each distributed Log Manager node stores a copy of the raw data in a signed log, and the parsed/normalized/enhanced data is forwarded upstream. If the user of the upstream LM or SIEM console wants to "drill-down" through the enhanced data to the raw data, that is supported. This lessens the need for storing duplicates of data all over the place, but still protects the forensic value of the data.

The point being, I'm not sure we should care what SIEMs want to do with the raw event data - for all we care, they could replace the entire raw event with an assigned event GUID, and then just mash that up with the context data that they provide. As long as the raw data, signed and protected, is stored *somewhere* in the customer's environment (or, even better, at a trusted third-party site), then the forensic aspect is covered.

>>> On 29.11.2010 at 11:11, in message
<[hidden email]>, "Heinbockel,
Bill" <[hidden email]> wrote:

> Going back to your previous e-mail, if we are worried about forensically-sound
> logs, then we must be able to maintain a signature for each event record
> (and
> modification thereof).
>
> From my standpoint, there are only 3 operations on an event record:
> CREATE  -- create a new record. This can be to reflect a new event, to
> summarize
> a previously created event, correlated events, etc.
> APPEND  -- add new fields to an existing record
> DELETE  -- delete or filter records
>
> If an upstream SIM agent wants to modify an event, then a new record should
> be
> created that references the existing record and has a new signature
>
> The support for multiple event signatures might be necessary for appending
> fields to an existing record. For this case, we could either create a new
> record
> or somehow wrap the old record with the new fields (and signature)
>
>
>>-----Original Message-----
>>From: Lawrence Smith [mailto:[hidden email]]
>>Sent: Saturday, 27 November 2010 01:43
>>To: cee-discussion-list CEE-Related Discussion
>>Subject: Re: [CEE-DISCUSSION-LIST] event integrity RE: [CEE-DISCUSSION-LIST]
>>xml documentation
>>
>>Adam,
>>
>>I agree that other specifications can make use of signatures and
>>authentication. I think, however, that the others you mentioned - since they
>>are XML based - may at least be able to make use of XML Signature. Since CEE
>>is designed to be Encoding Neutral, its requirements are somewhat different.
>>
>>Regardless of how signatures and authentication are implemented, I also
>>agree that key management is a significant issue. Not sure if it needs to be
>>addressed in the standard, but I'll remain open on the subject.
>>
>>Bill,
>>
>>I definitely think that event level signatures are a necessary option for
>>the end user. Consider that events may be tampered with after being stored
>>in a database. Stream and transport signatures will not help there. Event
>>level signatures do present a few interesting problems...
>>
>>* Besides the actual signature, you'd probably need to store a lot of
>>additional information with each and every event (algorithms, certificate
>>identifiers, etc.). This means either interdependent fields (e.g. a sig
>>field without a cert-id field is an error condition) or complex fields.
>>
>>* I'm not sure how much this has been talked about, but upstream agents may
>>augment or annotate the event. The original event generator may sign the
>>events that were generated, but this signature would have to specify which
>>fields were being signed. The upstream agent may add additional fields, and
>>may sign those as well (or all fields). I.e. I think the standard should be
>>able to support multiple signatures per event.
>>
>>* Some existing SEM Solutions have agents that may modify received events
>>(e.g. reducing a FQDN to just a hostname, translating a NAT-ed address). If
>>events are signed, then an upstream agent should not modify those fields
>>that have been signed. This makes it mandatory that upstream agents are
>>signature-aware.
>>
>>Regards,
>>
>>Lawrence
>>
>>
>>On Tue, Nov 23, 2010 at 1:26 PM, Adam Montville <[hidden email]>
>>wrote:
>>
>>
>> It seems that the key management implications of these features would
>>be significant.  Not saying that these features don't make sense, in fact,
>>just the opposite.  It seems, however, that this might be a set of features
>>that transcend CEE - other specifications may need this functionality as
>>well.  Consider XCCDF benchmarks with OVAL/OCIL checks as one example.
>>
>> How does everyone plan to deal with the key management aspect of these
>>features?
>>
>> Adam
>>
>>
>> -----Original Message-----
>> From: Heinbockel, Bill [mailto:[hidden email]]
>>
>> Sent: Monday, November 22, 2010 10:17 AM
>> To: [hidden email]
>>
>> Subject: [CEE-DISCUSSION-LIST] event integrity RE: [CEE-DISCUSSION-
>>LIST] xml documentation
>>
>> Bill,
>>
>> My thoughts on this is that there should be several features that
>>event-based
>> products may support.
>>
>> 1. Event level signatures - provide a hash or digital signature within
>>the event
>> content (possibly requiring canonicalization rules)
>> 2. Transport signatures - provide content integrity validation in the
>>event
>> transport or external envelope (e.g., ws sig, checksum, etc.)
>> 3. Event "stream" authentication - allow an event source and
>>destination to
>> authenticate an encrypted or other integrity-validated stream (BEEP
>>auth, DTLS
>> Syslog, etc.)
>>
>>
>> Depending on the environment and integrity needs, the end user should
>>have some
>> option to pick the level of integrity and overhead trade-off they are
>>willing to
>> accept
>>
>>
>> William Heinbockel
>> The MITRE Corporation
>>
>>
>> >-----Original Message-----
>> >From: Bill LeRoy [mailto:[hidden email]]
>> >Sent: Monday, 22 November 2010 10:39
>> >To: cee-discussion-list CEE-Related Discussion
>> >Subject: Re: [CEE-DISCUSSION-LIST] xml documentation
>> >
>> >Dear all,
>> >
>> >I don't know if there is any discussions in regard to non-repudiation
>> >of the event content.
>> >I have seen several methods from the BSD community with respect to
>> >digital signing of the event message
>> >but with respect to speed in sending signed events from devices there
>> >might be some significant overhead in performing
>> >such tasks. I believe one of the issues of the event content for
>> >example in syslog is the validity of the event source
>> >and the transaction of receiving the event. In the world of
>> >situational awareness the validity of the event becomes
>> >critical if all the members in a Family of Systems or Services are
>> >going to be aware of a common event or the correlation
>> >of numerous events. Although there might be front end controls that
>> >are put in place that might verify the transport between
>> >the source and destination but I believe that it is could be more
>> >efficient especially in historical examination if the source
>> >and destinations were able to sign the content in some agreeable
>> >format especially with event forwarding.
>> >
>> >Sincerely,
>> >Bill Le Roy
>> >CISA, CISM, CCSA
>> >
>> >On Mon, Nov 22, 2010 at 3:39 AM, Peter Czanik <[hidden email]>
>>wrote:
>> >> Hello,
>> >>
>> >> Most of cee-base-20100929.xml is not documented. Even where there
>>is a
>> >> few words of documentation, it's not always straightforward, in
>>which
>> >> form data is expected. So I'd be glad to see a 1-2 sentence
>> >> <Description></Description> for any tag or field in the file, as it
>> >> increases the chance, that I'll find the tag or field while
>>browsing the
>> >> XML.
>> >>
>> >> It would be great to also have an <Example></Example> line. For
>>example
>> >> for src_ipv4 it could be:
>> >>
>> >> <Field>
>> >> <Name>SourceIPv4Address</Name>
>> >> <ValueType>ipv4Address</ValueType>
>> >> <ShortName>src_ipv4</ShortName>
>> >> <FieldSet>SourceFieldSet</FieldSet>
>> >> <Description>The IPv4 address of the network communication
>> >> source</Description>
>> >> <Example>192.168.2.179</Example>
>> >> </Field>
>> >>
>> >>
>> >> I'd go as far as making these fields mandatory for other than Union
>> >> value types, like:
>> >>
>> >>                                <Name>systemname</Name>
>> >>                                <Union memberTypes="fqdn
>>ipAddress"/>
>> >>
>> >> As in this case there would already be examples at fqdn and
>>ipAdress
>> >> (which is in itself already a Union...).
>> >>
>> >> Bye,
>> >>
>> >> --
>> >> Peter Czanik (CzP) <[hidden email]>
>> >> BalaBit IT Security / syslog-ng upstream
>> >> http://czanik.blogs.balabit.com/
>> >>
>> >
>> >
>> >
>> >--
>> >Bill LeRoy
>> >
>> >
>> >[hidden email]
>>
>>
Reply | Threaded
Open this post in threaded view
|

Re: event integrity RE: [CEE-DISCUSSION-LIST] xml documentation

Lawrence Smith
In reply to this post by heinbockel
Glad to hear. I can speak from experience when I say that not all "Event Signatures" in current SIEM solutions are implemented well. I'd hesitate to even call them "signatures."

On Mon, Nov 29, 2010 at 10:18 AM, Heinbockel, Bill <[hidden email]> wrote:
>
>Sounds like an acceptable solution from a field definition perspective.
>
>Should CEE be more specific about signing a message so it's protected for
>evidentiary purposes?
>

It is our intention to provide guidance on how to sign and verify event
signatures

CEE will probably define an event canonicalization process. We just need to
decide whether we should do this for the encoded event (e.g., XML, Syslog)
record or the record data (or both)

Reply | Threaded
Open this post in threaded view
|

Re: event integrity RE: [CEE-DISCUSSION-LIST] xml documentation

Bill Frank
In reply to this post by heinbockel
Hi BillH,

Not sure I see why the SIM-modified record would need to be signed. Only the
original message generated by the device or application would be signed and
used for evidentiary purposes. The SIM simply takes a copy of the original
record and continues with whatever the appropriate processing is needed. The
copied "operational" record could be modified as often as needed and would
not be relevant for evidentiary purposes. Only the original signed record
would be stored for evidentiary purposes.

What am I missing?

Bill Frank
Cymbel
508-878-4943


-----Original Message-----
From: Heinbockel, Bill [mailto:[hidden email]]
Sent: Monday, November 29, 2010 11:11 AM
To: [hidden email]
Subject: Re: [CEE-DISCUSSION-LIST] event integrity RE: [CEE-DISCUSSION-LIST]
xml documentation

Going back to your previous e-mail, if we are worried about
forensically-sound
logs, then we must be able to maintain a signature for each event record
(and
modification thereof).

From my standpoint, there are only 3 operations on an event record:
CREATE  -- create a new record. This can be to reflect a new event, to
summarize
a previously created event, correlated events, etc.
APPEND  -- add new fields to an existing record
DELETE  -- delete or filter records

If an upstream SIM agent wants to modify an event, then a new record should
be
created that references the existing record and has a new signature

The support for multiple event signatures might be necessary for appending
fields to an existing record. For this case, we could either create a new
record
or somehow wrap the old record with the new fields (and signature)


>-----Original Message-----
>From: Lawrence Smith [mailto:[hidden email]]
>Sent: Saturday, 27 November 2010 01:43
>To: cee-discussion-list CEE-Related Discussion
>Subject: Re: [CEE-DISCUSSION-LIST] event integrity RE:
[CEE-DISCUSSION-LIST]
>xml documentation
>
>Adam,
>
>I agree that other specifications can make use of signatures and
>authentication. I think, however, that the others you mentioned - since
they
>are XML based - may at least be able to make use of XML Signature. Since
CEE
>is designed to be Encoding Neutral, its requirements are somewhat
different.
>
>Regardless of how signatures and authentication are implemented, I also
>agree that key management is a significant issue. Not sure if it needs to
be

>addressed in the standard, but I'll remain open on the subject.
>
>Bill,
>
>I definitely think that event level signatures are a necessary option for
>the end user. Consider that events may be tampered with after being stored
>in a database. Stream and transport signatures will not help there. Event
>level signatures do present a few interesting problems...
>
>* Besides the actual signature, you'd probably need to store a lot of
>additional information with each and every event (algorithms, certificate
>identifiers, etc.). This means either interdependent fields (e.g. a sig
>field without a cert-id field is an error condition) or complex fields.
>
>* I'm not sure how much this has been talked about, but upstream agents may
>augment or annotate the event. The original event generator may sign the
>events that were generated, but this signature would have to specify which
>fields were being signed. The upstream agent may add additional fields, and
>may sign those as well (or all fields). I.e. I think the standard should be
>able to support multiple signatures per event.
>
>* Some existing SEM Solutions have agents that may modify received events
>(e.g. reducing a FQDN to just a hostname, translating a NAT-ed address). If
>events are signed, then an upstream agent should not modify those fields
>that have been signed. This makes it mandatory that upstream agents are
>signature-aware.
>
>Regards,
>
>Lawrence
>
>
>On Tue, Nov 23, 2010 at 1:26 PM, Adam Montville <[hidden email]>
>wrote:
>
>
> It seems that the key management implications of these features
would
>be significant.  Not saying that these features don't make sense, in fact,
>just the opposite.  It seems, however, that this might be a set of features
>that transcend CEE - other specifications may need this functionality as
>well.  Consider XCCDF benchmarks with OVAL/OCIL checks as one example.
>
> How does everyone plan to deal with the key management aspect of
these

>features?
>
> Adam
>
>
> -----Original Message-----
> From: Heinbockel, Bill [mailto:[hidden email]]
>
> Sent: Monday, November 22, 2010 10:17 AM
> To: [hidden email]
>
> Subject: [CEE-DISCUSSION-LIST] event integrity RE: [CEE-DISCUSSION-
>LIST] xml documentation
>
> Bill,
>
> My thoughts on this is that there should be several features that
>event-based
> products may support.
>
> 1. Event level signatures - provide a hash or digital signature
within
>the event
> content (possibly requiring canonicalization rules)
> 2. Transport signatures - provide content integrity validation in
the

>event
> transport or external envelope (e.g., ws sig, checksum, etc.)
> 3. Event "stream" authentication - allow an event source and
>destination to
> authenticate an encrypted or other integrity-validated stream (BEEP
>auth, DTLS
> Syslog, etc.)
>
>
> Depending on the environment and integrity needs, the end user
should
>have some
> option to pick the level of integrity and overhead trade-off they
are

>willing to
> accept
>
>
> William Heinbockel
> The MITRE Corporation
>
>
> >-----Original Message-----
> >From: Bill LeRoy [mailto:[hidden email]]
> >Sent: Monday, 22 November 2010 10:39
> >To: cee-discussion-list CEE-Related Discussion
> >Subject: Re: [CEE-DISCUSSION-LIST] xml documentation
> >
> >Dear all,
> >
> >I don't know if there is any discussions in regard to
non-repudiation
> >of the event content.
> >I have seen several methods from the BSD community with respect to
> >digital signing of the event message
> >but with respect to speed in sending signed events from devices
there

> >might be some significant overhead in performing
> >such tasks. I believe one of the issues of the event content for
> >example in syslog is the validity of the event source
> >and the transaction of receiving the event. In the world of
> >situational awareness the validity of the event becomes
> >critical if all the members in a Family of Systems or Services are
> >going to be aware of a common event or the correlation
> >of numerous events. Although there might be front end controls that
> >are put in place that might verify the transport between
> >the source and destination but I believe that it is could be more
> >efficient especially in historical examination if the source
> >and destinations were able to sign the content in some agreeable
> >format especially with event forwarding.
> >
> >Sincerely,
> >Bill Le Roy
> >CISA, CISM, CCSA
> >
> >On Mon, Nov 22, 2010 at 3:39 AM, Peter Czanik <[hidden email]>
>wrote:
> >> Hello,
> >>
> >> Most of cee-base-20100929.xml is not documented. Even where there
>is a
> >> few words of documentation, it's not always straightforward, in
>which
> >> form data is expected. So I'd be glad to see a 1-2 sentence
> >> <Description></Description> for any tag or field in the file, as
it

> >> increases the chance, that I'll find the tag or field while
>browsing the
> >> XML.
> >>
> >> It would be great to also have an <Example></Example> line. For
>example
> >> for src_ipv4 it could be:
> >>
> >> <Field>
> >> <Name>SourceIPv4Address</Name>
> >> <ValueType>ipv4Address</ValueType>
> >> <ShortName>src_ipv4</ShortName>
> >> <FieldSet>SourceFieldSet</FieldSet>
> >> <Description>The IPv4 address of the network communication
> >> source</Description>
> >> <Example>192.168.2.179</Example>
> >> </Field>
> >>
> >>
> >> I'd go as far as making these fields mandatory for other than
Union

> >> value types, like:
> >>
> >>                                <Name>systemname</Name>
> >>                                <Union memberTypes="fqdn
>ipAddress"/>
> >>
> >> As in this case there would already be examples at fqdn and
>ipAdress
> >> (which is in itself already a Union...).
> >>
> >> Bye,
> >>
> >> --
> >> Peter Czanik (CzP) <[hidden email]>
> >> BalaBit IT Security / syslog-ng upstream
> >> http://czanik.blogs.balabit.com/
> >>
> >
> >
> >
> >--
> >Bill LeRoy
> >
> >
> >[hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: event integrity RE: [CEE-DISCUSSION-LIST] xml documentation

bleroy
Bill Frank and Bill Heinbockel,  the only time that I see the SIM signing the record is, if it was sent it out to other correlation engines further on up the road or to distributed devices for event notification especially in correlated events
I have seen devices sending correlation information with the top-level event and pointers to all the sub events in the correlation.
Will the correlated event and their linked events be in CEE format so that other readers or processors would be able to process them
or alert on them?  It might be debatable let's say in the incident management system if the correlated event was not validated in some respect.
Also if there was some sort of uniqueness about having events pass between multi-vendors besides an eventid that for some reason may not be unique.  Whatever the SIM does internally with the information from the raw message is the function of the SIM but if any device needs to communicate with another service then there should be some CEE commonality and a signing when communicating with other devices.
The SIM should be able to keep the raw message of the signed or hashed event in a logging system or in its database or both.

Signing a logfile is ok but what if the logfile contained forged events especially if events gathered were through udp protocol or were
caused by unwarranted administrative access.




 
 




Bill Leroy | netForensics | Information Security Management and Compliance Evangelist
CISA, CISM, CCSA



Office: 732-896-8948 | Mobile: 732-896-8948 | [hidden email]
Visit netForensics: WEBSITE | BLOG | TWITTER | LINKEDIN


-----Original Message-----
From: Bill Frank [mailto:[hidden email]]
Sent: Monday, November 29, 2010 4:53 PM
To: [hidden email]
Subject: Re: [CEE-DISCUSSION-LIST] event integrity RE: [CEE-DISCUSSION-LIST] xml documentation

Hi BillH,

Not sure I see why the SIM-modified record would need to be signed. Only the
original message generated by the device or application would be signed and
used for evidentiary purposes. The SIM simply takes a copy of the original
record and continues with whatever the appropriate processing is needed. The
copied "operational" record could be modified as often as needed and would
not be relevant for evidentiary purposes. Only the original signed record
would be stored for evidentiary purposes.

What am I missing?

Bill Frank
Cymbel
508-878-4943


-----Original Message-----
From: Heinbockel, Bill [mailto:[hidden email]]
Sent: Monday, November 29, 2010 11:11 AM
To: [hidden email]
Subject: Re: [CEE-DISCUSSION-LIST] event integrity RE: [CEE-DISCUSSION-LIST]
xml documentation

Going back to your previous e-mail, if we are worried about
forensically-sound
logs, then we must be able to maintain a signature for each event record
(and
modification thereof).

From my standpoint, there are only 3 operations on an event record:
CREATE  -- create a new record. This can be to reflect a new event, to
summarize
a previously created event, correlated events, etc.
APPEND  -- add new fields to an existing record
DELETE  -- delete or filter records

If an upstream SIM agent wants to modify an event, then a new record should
be
created that references the existing record and has a new signature

The support for multiple event signatures might be necessary for appending
fields to an existing record. For this case, we could either create a new
record
or somehow wrap the old record with the new fields (and signature)


>-----Original Message-----
>From: Lawrence Smith [mailto:[hidden email]]
>Sent: Saturday, 27 November 2010 01:43
>To: cee-discussion-list CEE-Related Discussion
>Subject: Re: [CEE-DISCUSSION-LIST] event integrity RE:
[CEE-DISCUSSION-LIST]
>xml documentation
>
>Adam,
>
>I agree that other specifications can make use of signatures and
>authentication. I think, however, that the others you mentioned - since
they
>are XML based - may at least be able to make use of XML Signature. Since
CEE
>is designed to be Encoding Neutral, its requirements are somewhat
different.
>
>Regardless of how signatures and authentication are implemented, I also
>agree that key management is a significant issue. Not sure if it needs to
be

>addressed in the standard, but I'll remain open on the subject.
>
>Bill,
>
>I definitely think that event level signatures are a necessary option for
>the end user. Consider that events may be tampered with after being stored
>in a database. Stream and transport signatures will not help there. Event
>level signatures do present a few interesting problems...
>
>* Besides the actual signature, you'd probably need to store a lot of
>additional information with each and every event (algorithms, certificate
>identifiers, etc.). This means either interdependent fields (e.g. a sig
>field without a cert-id field is an error condition) or complex fields.
>
>* I'm not sure how much this has been talked about, but upstream agents may
>augment or annotate the event. The original event generator may sign the
>events that were generated, but this signature would have to specify which
>fields were being signed. The upstream agent may add additional fields, and
>may sign those as well (or all fields). I.e. I think the standard should be
>able to support multiple signatures per event.
>
>* Some existing SEM Solutions have agents that may modify received events
>(e.g. reducing a FQDN to just a hostname, translating a NAT-ed address). If
>events are signed, then an upstream agent should not modify those fields
>that have been signed. This makes it mandatory that upstream agents are
>signature-aware.
>
>Regards,
>
>Lawrence
>
>
>On Tue, Nov 23, 2010 at 1:26 PM, Adam Montville <[hidden email]>
>wrote:
>
>
> It seems that the key management implications of these features
would
>be significant.  Not saying that these features don't make sense, in fact,
>just the opposite.  It seems, however, that this might be a set of features
>that transcend CEE - other specifications may need this functionality as
>well.  Consider XCCDF benchmarks with OVAL/OCIL checks as one example.
>
> How does everyone plan to deal with the key management aspect of
these

>features?
>
> Adam
>
>
> -----Original Message-----
> From: Heinbockel, Bill [mailto:[hidden email]]
>
> Sent: Monday, November 22, 2010 10:17 AM
> To: [hidden email]
>
> Subject: [CEE-DISCUSSION-LIST] event integrity RE: [CEE-DISCUSSION-
>LIST] xml documentation
>
> Bill,
>
> My thoughts on this is that there should be several features that
>event-based
> products may support.
>
> 1. Event level signatures - provide a hash or digital signature
within
>the event
> content (possibly requiring canonicalization rules)
> 2. Transport signatures - provide content integrity validation in
the

>event
> transport or external envelope (e.g., ws sig, checksum, etc.)
> 3. Event "stream" authentication - allow an event source and
>destination to
> authenticate an encrypted or other integrity-validated stream (BEEP
>auth, DTLS
> Syslog, etc.)
>
>
> Depending on the environment and integrity needs, the end user
should
>have some
> option to pick the level of integrity and overhead trade-off they
are

>willing to
> accept
>
>
> William Heinbockel
> The MITRE Corporation
>
>
> >-----Original Message-----
> >From: Bill LeRoy [mailto:[hidden email]]
> >Sent: Monday, 22 November 2010 10:39
> >To: cee-discussion-list CEE-Related Discussion
> >Subject: Re: [CEE-DISCUSSION-LIST] xml documentation
> >
> >Dear all,
> >
> >I don't know if there is any discussions in regard to
non-repudiation
> >of the event content.
> >I have seen several methods from the BSD community with respect to
> >digital signing of the event message
> >but with respect to speed in sending signed events from devices
there

> >might be some significant overhead in performing
> >such tasks. I believe one of the issues of the event content for
> >example in syslog is the validity of the event source
> >and the transaction of receiving the event. In the world of
> >situational awareness the validity of the event becomes
> >critical if all the members in a Family of Systems or Services are
> >going to be aware of a common event or the correlation
> >of numerous events. Although there might be front end controls that
> >are put in place that might verify the transport between
> >the source and destination but I believe that it is could be more
> >efficient especially in historical examination if the source
> >and destinations were able to sign the content in some agreeable
> >format especially with event forwarding.
> >
> >Sincerely,
> >Bill Le Roy
> >CISA, CISM, CCSA
> >
> >On Mon, Nov 22, 2010 at 3:39 AM, Peter Czanik <[hidden email]>
>wrote:
> >> Hello,
> >>
> >> Most of cee-base-20100929.xml is not documented. Even where there
>is a
> >> few words of documentation, it's not always straightforward, in
>which
> >> form data is expected. So I'd be glad to see a 1-2 sentence
> >> <Description></Description> for any tag or field in the file, as
it

> >> increases the chance, that I'll find the tag or field while
>browsing the
> >> XML.
> >>
> >> It would be great to also have an <Example></Example> line. For
>example
> >> for src_ipv4 it could be:
> >>
> >> <Field>
> >> <Name>SourceIPv4Address</Name>
> >> <ValueType>ipv4Address</ValueType>
> >> <ShortName>src_ipv4</ShortName>
> >> <FieldSet>SourceFieldSet</FieldSet>
> >> <Description>The IPv4 address of the network communication
> >> source</Description>
> >> <Example>192.168.2.179</Example>
> >> </Field>
> >>
> >>
> >> I'd go as far as making these fields mandatory for other than
Union

> >> value types, like:
> >>
> >>                                <Name>systemname</Name>
> >>                                <Union memberTypes="fqdn
>ipAddress"/>
> >>
> >> As in this case there would already be examples at fqdn and
>ipAdress
> >> (which is in itself already a Union...).
> >>
> >> Bye,
> >>
> >> --
> >> Peter Czanik (CzP) <[hidden email]>
> >> BalaBit IT Security / syslog-ng upstream
> >> http://czanik.blogs.balabit.com/
> >>
> >
> >
> >
> >--
> >Bill LeRoy
> >
> >
> >[hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: event integrity RE: [CEE-DISCUSSION-LIST] xml documentation

Bill Frank
Bill Leroy and Bill Heinbockel,

At present, I believe most SIM vendors make some effort to assure
evidentiary integrity of the logs they receive, even those where syslog UDP
is the transport. Clearly you are right that received messages can be
fraudulent or repudiated.

The opportunity for fraud and repudiation is less with vendors like Check
Point (OPSEC) and Cisco (SDEE) who require a secure end-to-end protocol.

If the CEE Transport specification requires the event generator to sign each
event, then the SIM will not do any signing unless, as you say, it is
sending an event/message on to a third party.

Bill Frank
Cymbel



-----Original Message-----
From: Bill Leroy [mailto:[hidden email]]
Sent: Monday, November 29, 2010 5:52 PM
To: [hidden email]
Subject: Re: [CEE-DISCUSSION-LIST] event integrity RE: [CEE-DISCUSSION-LIST]
xml documentation

Bill Frank and Bill Heinbockel,  the only time that I see the SIM signing
the record is, if it was sent it out to other correlation engines further on
up the road or to distributed devices for event notification especially in
correlated events
I have seen devices sending correlation information with the top-level event
and pointers to all the sub events in the correlation.
Will the correlated event and their linked events be in CEE format so that
other readers or processors would be able to process them
or alert on them?  It might be debatable let's say in the incident
management system if the correlated event was not validated in some respect.
Also if there was some sort of uniqueness about having events pass between
multi-vendors besides an eventid that for some reason may not be unique.
Whatever the SIM does internally with the information from the raw message
is the function of the SIM but if any device needs to communicate with
another service then there should be some CEE commonality and a signing when
communicating with other devices.
The SIM should be able to keep the raw message of the signed or hashed event
in a logging system or in its database or both.

Signing a logfile is ok but what if the logfile contained forged events
especially if events gathered were through udp protocol or were
caused by unwarranted administrative access.




 
 




Bill Leroy | netForensics | Information Security Management and Compliance
Evangelist
CISA, CISM, CCSA



Office: 732-896-8948 | Mobile: 732-896-8948 | [hidden email]
Visit netForensics: WEBSITE | BLOG | TWITTER | LINKEDIN


-----Original Message-----
From: Bill Frank [mailto:[hidden email]]
Sent: Monday, November 29, 2010 4:53 PM
To: [hidden email]
Subject: Re: [CEE-DISCUSSION-LIST] event integrity RE: [CEE-DISCUSSION-LIST]
xml documentation

Hi BillH,

Not sure I see why the SIM-modified record would need to be signed. Only the
original message generated by the device or application would be signed and
used for evidentiary purposes. The SIM simply takes a copy of the original
record and continues with whatever the appropriate processing is needed. The
copied "operational" record could be modified as often as needed and would
not be relevant for evidentiary purposes. Only the original signed record
would be stored for evidentiary purposes.

What am I missing?

Bill Frank
Cymbel
508-878-4943


-----Original Message-----
From: Heinbockel, Bill [mailto:[hidden email]]
Sent: Monday, November 29, 2010 11:11 AM
To: [hidden email]
Subject: Re: [CEE-DISCUSSION-LIST] event integrity RE: [CEE-DISCUSSION-LIST]
xml documentation

Going back to your previous e-mail, if we are worried about
forensically-sound
logs, then we must be able to maintain a signature for each event record
(and
modification thereof).

From my standpoint, there are only 3 operations on an event record:
CREATE  -- create a new record. This can be to reflect a new event, to
summarize
a previously created event, correlated events, etc.
APPEND  -- add new fields to an existing record
DELETE  -- delete or filter records

If an upstream SIM agent wants to modify an event, then a new record should
be
created that references the existing record and has a new signature

The support for multiple event signatures might be necessary for appending
fields to an existing record. For this case, we could either create a new
record
or somehow wrap the old record with the new fields (and signature)


>-----Original Message-----
>From: Lawrence Smith [mailto:[hidden email]]
>Sent: Saturday, 27 November 2010 01:43
>To: cee-discussion-list CEE-Related Discussion
>Subject: Re: [CEE-DISCUSSION-LIST] event integrity RE:
[CEE-DISCUSSION-LIST]
>xml documentation
>
>Adam,
>
>I agree that other specifications can make use of signatures and
>authentication. I think, however, that the others you mentioned - since
they
>are XML based - may at least be able to make use of XML Signature. Since
CEE
>is designed to be Encoding Neutral, its requirements are somewhat
different.
>
>Regardless of how signatures and authentication are implemented, I also
>agree that key management is a significant issue. Not sure if it needs to
be

>addressed in the standard, but I'll remain open on the subject.
>
>Bill,
>
>I definitely think that event level signatures are a necessary option for
>the end user. Consider that events may be tampered with after being stored
>in a database. Stream and transport signatures will not help there. Event
>level signatures do present a few interesting problems...
>
>* Besides the actual signature, you'd probably need to store a lot of
>additional information with each and every event (algorithms, certificate
>identifiers, etc.). This means either interdependent fields (e.g. a sig
>field without a cert-id field is an error condition) or complex fields.
>
>* I'm not sure how much this has been talked about, but upstream agents may
>augment or annotate the event. The original event generator may sign the
>events that were generated, but this signature would have to specify which
>fields were being signed. The upstream agent may add additional fields, and
>may sign those as well (or all fields). I.e. I think the standard should be
>able to support multiple signatures per event.
>
>* Some existing SEM Solutions have agents that may modify received events
>(e.g. reducing a FQDN to just a hostname, translating a NAT-ed address). If
>events are signed, then an upstream agent should not modify those fields
>that have been signed. This makes it mandatory that upstream agents are
>signature-aware.
>
>Regards,
>
>Lawrence
>
>
>On Tue, Nov 23, 2010 at 1:26 PM, Adam Montville <[hidden email]>
>wrote:
>
>
> It seems that the key management implications of these features
would
>be significant.  Not saying that these features don't make sense, in fact,
>just the opposite.  It seems, however, that this might be a set of features
>that transcend CEE - other specifications may need this functionality as
>well.  Consider XCCDF benchmarks with OVAL/OCIL checks as one example.
>
> How does everyone plan to deal with the key management aspect of
these

>features?
>
> Adam
>
>
> -----Original Message-----
> From: Heinbockel, Bill [mailto:[hidden email]]
>
> Sent: Monday, November 22, 2010 10:17 AM
> To: [hidden email]
>
> Subject: [CEE-DISCUSSION-LIST] event integrity RE: [CEE-DISCUSSION-
>LIST] xml documentation
>
> Bill,
>
> My thoughts on this is that there should be several features that
>event-based
> products may support.
>
> 1. Event level signatures - provide a hash or digital signature
within
>the event
> content (possibly requiring canonicalization rules)
> 2. Transport signatures - provide content integrity validation in
the

>event
> transport or external envelope (e.g., ws sig, checksum, etc.)
> 3. Event "stream" authentication - allow an event source and
>destination to
> authenticate an encrypted or other integrity-validated stream (BEEP
>auth, DTLS
> Syslog, etc.)
>
>
> Depending on the environment and integrity needs, the end user
should
>have some
> option to pick the level of integrity and overhead trade-off they
are

>willing to
> accept
>
>
> William Heinbockel
> The MITRE Corporation
>
>
> >-----Original Message-----
> >From: Bill LeRoy [mailto:[hidden email]]
> >Sent: Monday, 22 November 2010 10:39
> >To: cee-discussion-list CEE-Related Discussion
> >Subject: Re: [CEE-DISCUSSION-LIST] xml documentation
> >
> >Dear all,
> >
> >I don't know if there is any discussions in regard to
non-repudiation
> >of the event content.
> >I have seen several methods from the BSD community with respect to
> >digital signing of the event message
> >but with respect to speed in sending signed events from devices
there

> >might be some significant overhead in performing
> >such tasks. I believe one of the issues of the event content for
> >example in syslog is the validity of the event source
> >and the transaction of receiving the event. In the world of
> >situational awareness the validity of the event becomes
> >critical if all the members in a Family of Systems or Services are
> >going to be aware of a common event or the correlation
> >of numerous events. Although there might be front end controls that
> >are put in place that might verify the transport between
> >the source and destination but I believe that it is could be more
> >efficient especially in historical examination if the source
> >and destinations were able to sign the content in some agreeable
> >format especially with event forwarding.
> >
> >Sincerely,
> >Bill Le Roy
> >CISA, CISM, CCSA
> >
> >On Mon, Nov 22, 2010 at 3:39 AM, Peter Czanik <[hidden email]>
>wrote:
> >> Hello,
> >>
> >> Most of cee-base-20100929.xml is not documented. Even where there
>is a
> >> few words of documentation, it's not always straightforward, in
>which
> >> form data is expected. So I'd be glad to see a 1-2 sentence
> >> <Description></Description> for any tag or field in the file, as
it

> >> increases the chance, that I'll find the tag or field while
>browsing the
> >> XML.
> >>
> >> It would be great to also have an <Example></Example> line. For
>example
> >> for src_ipv4 it could be:
> >>
> >> <Field>
> >> <Name>SourceIPv4Address</Name>
> >> <ValueType>ipv4Address</ValueType>
> >> <ShortName>src_ipv4</ShortName>
> >> <FieldSet>SourceFieldSet</FieldSet>
> >> <Description>The IPv4 address of the network communication
> >> source</Description>
> >> <Example>192.168.2.179</Example>
> >> </Field>
> >>
> >>
> >> I'd go as far as making these fields mandatory for other than
Union

> >> value types, like:
> >>
> >>                                <Name>systemname</Name>
> >>                                <Union memberTypes="fqdn
>ipAddress"/>
> >>
> >> As in this case there would already be examples at fqdn and
>ipAdress
> >> (which is in itself already a Union...).
> >>
> >> Bye,
> >>
> >> --
> >> Peter Czanik (CzP) <[hidden email]>
> >> BalaBit IT Security / syslog-ng upstream
> >> http://czanik.blogs.balabit.com/
> >>
> >
> >
> >
> >--
> >Bill LeRoy
> >
> >
> >[hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: event integrity RE: [CEE-DISCUSSION-LIST] xml documentation

Chris Lonvick
Hi,

I havn't been following this thread too closely.  :-)  But I do recall
that Counterpane did a lot of work with securing logs about 10 years or so
ago.  The best pointer I can find to that work is here:
   http://www.schneier.com/paper-auditlogs.html

I'll review the thread more carefully when I get some time.

Thanks,
Chris

On Mon, 29 Nov 2010, Bill Frank wrote:

> Bill Leroy and Bill Heinbockel,
>
> At present, I believe most SIM vendors make some effort to assure
> evidentiary integrity of the logs they receive, even those where syslog UDP
> is the transport. Clearly you are right that received messages can be
> fraudulent or repudiated.
>
> The opportunity for fraud and repudiation is less with vendors like Check
> Point (OPSEC) and Cisco (SDEE) who require a secure end-to-end protocol.
>
> If the CEE Transport specification requires the event generator to sign each
> event, then the SIM will not do any signing unless, as you say, it is
> sending an event/message on to a third party.
>
> Bill Frank
> Cymbel
>
>
>
> -----Original Message-----
> From: Bill Leroy [mailto:[hidden email]]
> Sent: Monday, November 29, 2010 5:52 PM
> To: [hidden email]
> Subject: Re: [CEE-DISCUSSION-LIST] event integrity RE: [CEE-DISCUSSION-LIST]
> xml documentation
>
> Bill Frank and Bill Heinbockel,  the only time that I see the SIM signing
> the record is, if it was sent it out to other correlation engines further on
> up the road or to distributed devices for event notification especially in
> correlated events
> I have seen devices sending correlation information with the top-level event
> and pointers to all the sub events in the correlation.
> Will the correlated event and their linked events be in CEE format so that
> other readers or processors would be able to process them
> or alert on them?  It might be debatable let's say in the incident
> management system if the correlated event was not validated in some respect.
> Also if there was some sort of uniqueness about having events pass between
> multi-vendors besides an eventid that for some reason may not be unique.
> Whatever the SIM does internally with the information from the raw message
> is the function of the SIM but if any device needs to communicate with
> another service then there should be some CEE commonality and a signing when
> communicating with other devices.
> The SIM should be able to keep the raw message of the signed or hashed event
> in a logging system or in its database or both.
>
> Signing a logfile is ok but what if the logfile contained forged events
> especially if events gathered were through udp protocol or were
> caused by unwarranted administrative access.
>
>
>
>
>
>
>
>
>
>
> Bill Leroy | netForensics | Information Security Management and Compliance
> Evangelist
> CISA, CISM, CCSA
>
>
>
> Office: 732-896-8948 | Mobile: 732-896-8948 | [hidden email]
> Visit netForensics: WEBSITE | BLOG | TWITTER | LINKEDIN
>
>
> -----Original Message-----
> From: Bill Frank [mailto:[hidden email]]
> Sent: Monday, November 29, 2010 4:53 PM
> To: [hidden email]
> Subject: Re: [CEE-DISCUSSION-LIST] event integrity RE: [CEE-DISCUSSION-LIST]
> xml documentation
>
> Hi BillH,
>
> Not sure I see why the SIM-modified record would need to be signed. Only the
> original message generated by the device or application would be signed and
> used for evidentiary purposes. The SIM simply takes a copy of the original
> record and continues with whatever the appropriate processing is needed. The
> copied "operational" record could be modified as often as needed and would
> not be relevant for evidentiary purposes. Only the original signed record
> would be stored for evidentiary purposes.
>
> What am I missing?
>
> Bill Frank
> Cymbel
> 508-878-4943
>
>
> -----Original Message-----
> From: Heinbockel, Bill [mailto:[hidden email]]
> Sent: Monday, November 29, 2010 11:11 AM
> To: [hidden email]
> Subject: Re: [CEE-DISCUSSION-LIST] event integrity RE: [CEE-DISCUSSION-LIST]
> xml documentation
>
> Going back to your previous e-mail, if we are worried about
> forensically-sound
> logs, then we must be able to maintain a signature for each event record
> (and
> modification thereof).
>
> From my standpoint, there are only 3 operations on an event record:
> CREATE  -- create a new record. This can be to reflect a new event, to
> summarize
> a previously created event, correlated events, etc.
> APPEND  -- add new fields to an existing record
> DELETE  -- delete or filter records
>
> If an upstream SIM agent wants to modify an event, then a new record should
> be
> created that references the existing record and has a new signature
>
> The support for multiple event signatures might be necessary for appending
> fields to an existing record. For this case, we could either create a new
> record
> or somehow wrap the old record with the new fields (and signature)
>
>
>> -----Original Message-----
>> From: Lawrence Smith [mailto:[hidden email]]
>> Sent: Saturday, 27 November 2010 01:43
>> To: cee-discussion-list CEE-Related Discussion
>> Subject: Re: [CEE-DISCUSSION-LIST] event integrity RE:
> [CEE-DISCUSSION-LIST]
>> xml documentation
>>
>> Adam,
>>
>> I agree that other specifications can make use of signatures and
>> authentication. I think, however, that the others you mentioned - since
> they
>> are XML based - may at least be able to make use of XML Signature. Since
> CEE
>> is designed to be Encoding Neutral, its requirements are somewhat
> different.
>>
>> Regardless of how signatures and authentication are implemented, I also
>> agree that key management is a significant issue. Not sure if it needs to
> be
>> addressed in the standard, but I'll remain open on the subject.
>>
>> Bill,
>>
>> I definitely think that event level signatures are a necessary option for
>> the end user. Consider that events may be tampered with after being stored
>> in a database. Stream and transport signatures will not help there. Event
>> level signatures do present a few interesting problems...
>>
>> * Besides the actual signature, you'd probably need to store a lot of
>> additional information with each and every event (algorithms, certificate
>> identifiers, etc.). This means either interdependent fields (e.g. a sig
>> field without a cert-id field is an error condition) or complex fields.
>>
>> * I'm not sure how much this has been talked about, but upstream agents may
>> augment or annotate the event. The original event generator may sign the
>> events that were generated, but this signature would have to specify which
>> fields were being signed. The upstream agent may add additional fields, and
>> may sign those as well (or all fields). I.e. I think the standard should be
>> able to support multiple signatures per event.
>>
>> * Some existing SEM Solutions have agents that may modify received events
>> (e.g. reducing a FQDN to just a hostname, translating a NAT-ed address). If
>> events are signed, then an upstream agent should not modify those fields
>> that have been signed. This makes it mandatory that upstream agents are
>> signature-aware.
>>
>> Regards,
>>
>> Lawrence
>>
>>
>> On Tue, Nov 23, 2010 at 1:26 PM, Adam Montville <[hidden email]>
>> wrote:
>>
>>
>> It seems that the key management implications of these features
> would
>> be significant.  Not saying that these features don't make sense, in fact,
>> just the opposite.  It seems, however, that this might be a set of features
>> that transcend CEE - other specifications may need this functionality as
>> well.  Consider XCCDF benchmarks with OVAL/OCIL checks as one example.
>>
>> How does everyone plan to deal with the key management aspect of
> these
>> features?
>>
>> Adam
>>
>>
>> -----Original Message-----
>> From: Heinbockel, Bill [mailto:[hidden email]]
>>
>> Sent: Monday, November 22, 2010 10:17 AM
>> To: [hidden email]
>>
>> Subject: [CEE-DISCUSSION-LIST] event integrity RE: [CEE-DISCUSSION-
>> LIST] xml documentation
>>
>> Bill,
>>
>> My thoughts on this is that there should be several features that
>> event-based
>> products may support.
>>
>> 1. Event level signatures - provide a hash or digital signature
> within
>> the event
>> content (possibly requiring canonicalization rules)
>> 2. Transport signatures - provide content integrity validation in
> the
>> event
>> transport or external envelope (e.g., ws sig, checksum, etc.)
>> 3. Event "stream" authentication - allow an event source and
>> destination to
>> authenticate an encrypted or other integrity-validated stream (BEEP
>> auth, DTLS
>> Syslog, etc.)
>>
>>
>> Depending on the environment and integrity needs, the end user
> should
>> have some
>> option to pick the level of integrity and overhead trade-off they
> are
>> willing to
>> accept
>>
>>
>> William Heinbockel
>> The MITRE Corporation
>>
>>
>>> -----Original Message-----
>>> From: Bill LeRoy [mailto:[hidden email]]
>>> Sent: Monday, 22 November 2010 10:39
>>> To: cee-discussion-list CEE-Related Discussion
>>> Subject: Re: [CEE-DISCUSSION-LIST] xml documentation
>>>
>>> Dear all,
>>>
>>> I don't know if there is any discussions in regard to
> non-repudiation
>>> of the event content.
>>> I have seen several methods from the BSD community with respect to
>>> digital signing of the event message
>>> but with respect to speed in sending signed events from devices
> there
>>> might be some significant overhead in performing
>>> such tasks. I believe one of the issues of the event content for
>>> example in syslog is the validity of the event source
>>> and the transaction of receiving the event. In the world of
>>> situational awareness the validity of the event becomes
>>> critical if all the members in a Family of Systems or Services are
>>> going to be aware of a common event or the correlation
>>> of numerous events. Although there might be front end controls that
>>> are put in place that might verify the transport between
>>> the source and destination but I believe that it is could be more
>>> efficient especially in historical examination if the source
>>> and destinations were able to sign the content in some agreeable
>>> format especially with event forwarding.
>>>
>>> Sincerely,
>>> Bill Le Roy
>>> CISA, CISM, CCSA
>>>
>>> On Mon, Nov 22, 2010 at 3:39 AM, Peter Czanik <[hidden email]>
>> wrote:
>>>> Hello,
>>>>
>>>> Most of cee-base-20100929.xml is not documented. Even where there
>> is a
>>>> few words of documentation, it's not always straightforward, in
>> which
>>>> form data is expected. So I'd be glad to see a 1-2 sentence
>>>> <Description></Description> for any tag or field in the file, as
> it
>>>> increases the chance, that I'll find the tag or field while
>> browsing the
>>>> XML.
>>>>
>>>> It would be great to also have an <Example></Example> line. For
>> example
>>>> for src_ipv4 it could be:
>>>>
>>>> <Field>
>>>> <Name>SourceIPv4Address</Name>
>>>> <ValueType>ipv4Address</ValueType>
>>>> <ShortName>src_ipv4</ShortName>
>>>> <FieldSet>SourceFieldSet</FieldSet>
>>>> <Description>The IPv4 address of the network communication
>>>> source</Description>
>>>> <Example>192.168.2.179</Example>
>>>> </Field>
>>>>
>>>>
>>>> I'd go as far as making these fields mandatory for other than
> Union
>>>> value types, like:
>>>>
>>>>                                <Name>systemname</Name>
>>>>                                <Union memberTypes="fqdn
>> ipAddress"/>
>>>>
>>>> As in this case there would already be examples at fqdn and
>> ipAdress
>>>> (which is in itself already a Union...).
>>>>
>>>> Bye,
>>>>
>>>> --
>>>> Peter Czanik (CzP) <[hidden email]>
>>>> BalaBit IT Security / syslog-ng upstream
>>>> http://czanik.blogs.balabit.com/
>>>>
>>>
>>>
>>>
>>> --
>>> Bill LeRoy
>>>
>>>
>>> [hidden email]
>>
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: event integrity RE: [CEE-DISCUSSION-LIST] xml documentation

bleroy
Chris,

That is interesting that you mention that document in particular, I do remember reviewing that document myself.


Bill Leroy | netForensics | Information Security Management and Compliance Evangelist
CISA, CISM, CCSA



Office: 732-896-8948 | Mobile: 732-896-8948 | [hidden email]
Visit netForensics: WEBSITE | BLOG | TWITTER | LINKEDIN


-----Original Message-----
From: Chris Lonvick [mailto:[hidden email]]
Sent: Tuesday, November 30, 2010 10:01 AM
To: [hidden email]
Subject: Re: [CEE-DISCUSSION-LIST] event integrity RE: [CEE-DISCUSSION-LIST] xml documentation

Hi,

I havn't been following this thread too closely.  :-)  But I do recall
that Counterpane did a lot of work with securing logs about 10 years or so
ago.  The best pointer I can find to that work is here:
   http://www.schneier.com/paper-auditlogs.html

I'll review the thread more carefully when I get some time.

Thanks,
Chris

On Mon, 29 Nov 2010, Bill Frank wrote:

> Bill Leroy and Bill Heinbockel,
>
> At present, I believe most SIM vendors make some effort to assure
> evidentiary integrity of the logs they receive, even those where syslog UDP
> is the transport. Clearly you are right that received messages can be
> fraudulent or repudiated.
>
> The opportunity for fraud and repudiation is less with vendors like Check
> Point (OPSEC) and Cisco (SDEE) who require a secure end-to-end protocol.
>
> If the CEE Transport specification requires the event generator to sign each
> event, then the SIM will not do any signing unless, as you say, it is
> sending an event/message on to a third party.
>
> Bill Frank
> Cymbel
>
>
>
> -----Original Message-----
> From: Bill Leroy [mailto:[hidden email]]
> Sent: Monday, November 29, 2010 5:52 PM
> To: [hidden email]
> Subject: Re: [CEE-DISCUSSION-LIST] event integrity RE: [CEE-DISCUSSION-LIST]
> xml documentation
>
> Bill Frank and Bill Heinbockel,  the only time that I see the SIM signing
> the record is, if it was sent it out to other correlation engines further on
> up the road or to distributed devices for event notification especially in
> correlated events
> I have seen devices sending correlation information with the top-level event
> and pointers to all the sub events in the correlation.
> Will the correlated event and their linked events be in CEE format so that
> other readers or processors would be able to process them
> or alert on them?  It might be debatable let's say in the incident
> management system if the correlated event was not validated in some respect.
> Also if there was some sort of uniqueness about having events pass between
> multi-vendors besides an eventid that for some reason may not be unique.
> Whatever the SIM does internally with the information from the raw message
> is the function of the SIM but if any device needs to communicate with
> another service then there should be some CEE commonality and a signing when
> communicating with other devices.
> The SIM should be able to keep the raw message of the signed or hashed event
> in a logging system or in its database or both.
>
> Signing a logfile is ok but what if the logfile contained forged events
> especially if events gathered were through udp protocol or were
> caused by unwarranted administrative access.
>
>
>
>
>
>
>
>
>
>
> Bill Leroy | netForensics | Information Security Management and Compliance
> Evangelist
> CISA, CISM, CCSA
>
>
>
> Office: 732-896-8948 | Mobile: 732-896-8948 | [hidden email]
> Visit netForensics: WEBSITE | BLOG | TWITTER | LINKEDIN
>
>
> -----Original Message-----
> From: Bill Frank [mailto:[hidden email]]
> Sent: Monday, November 29, 2010 4:53 PM
> To: [hidden email]
> Subject: Re: [CEE-DISCUSSION-LIST] event integrity RE: [CEE-DISCUSSION-LIST]
> xml documentation
>
> Hi BillH,
>
> Not sure I see why the SIM-modified record would need to be signed. Only the
> original message generated by the device or application would be signed and
> used for evidentiary purposes. The SIM simply takes a copy of the original
> record and continues with whatever the appropriate processing is needed. The
> copied "operational" record could be modified as often as needed and would
> not be relevant for evidentiary purposes. Only the original signed record
> would be stored for evidentiary purposes.
>
> What am I missing?
>
> Bill Frank
> Cymbel
> 508-878-4943
>
>
> -----Original Message-----
> From: Heinbockel, Bill [mailto:[hidden email]]
> Sent: Monday, November 29, 2010 11:11 AM
> To: [hidden email]
> Subject: Re: [CEE-DISCUSSION-LIST] event integrity RE: [CEE-DISCUSSION-LIST]
> xml documentation
>
> Going back to your previous e-mail, if we are worried about
> forensically-sound
> logs, then we must be able to maintain a signature for each event record
> (and
> modification thereof).
>
> From my standpoint, there are only 3 operations on an event record:
> CREATE  -- create a new record. This can be to reflect a new event, to
> summarize
> a previously created event, correlated events, etc.
> APPEND  -- add new fields to an existing record
> DELETE  -- delete or filter records
>
> If an upstream SIM agent wants to modify an event, then a new record should
> be
> created that references the existing record and has a new signature
>
> The support for multiple event signatures might be necessary for appending
> fields to an existing record. For this case, we could either create a new
> record
> or somehow wrap the old record with the new fields (and signature)
>
>
>> -----Original Message-----
>> From: Lawrence Smith [mailto:[hidden email]]
>> Sent: Saturday, 27 November 2010 01:43
>> To: cee-discussion-list CEE-Related Discussion
>> Subject: Re: [CEE-DISCUSSION-LIST] event integrity RE:
> [CEE-DISCUSSION-LIST]
>> xml documentation
>>
>> Adam,
>>
>> I agree that other specifications can make use of signatures and
>> authentication. I think, however, that the others you mentioned - since
> they
>> are XML based - may at least be able to make use of XML Signature. Since
> CEE
>> is designed to be Encoding Neutral, its requirements are somewhat
> different.
>>
>> Regardless of how signatures and authentication are implemented, I also
>> agree that key management is a significant issue. Not sure if it needs to
> be
>> addressed in the standard, but I'll remain open on the subject.
>>
>> Bill,
>>
>> I definitely think that event level signatures are a necessary option for
>> the end user. Consider that events may be tampered with after being stored
>> in a database. Stream and transport signatures will not help there. Event
>> level signatures do present a few interesting problems...
>>
>> * Besides the actual signature, you'd probably need to store a lot of
>> additional information with each and every event (algorithms, certificate
>> identifiers, etc.). This means either interdependent fields (e.g. a sig
>> field without a cert-id field is an error condition) or complex fields.
>>
>> * I'm not sure how much this has been talked about, but upstream agents may
>> augment or annotate the event. The original event generator may sign the
>> events that were generated, but this signature would have to specify which
>> fields were being signed. The upstream agent may add additional fields, and
>> may sign those as well (or all fields). I.e. I think the standard should be
>> able to support multiple signatures per event.
>>
>> * Some existing SEM Solutions have agents that may modify received events
>> (e.g. reducing a FQDN to just a hostname, translating a NAT-ed address). If
>> events are signed, then an upstream agent should not modify those fields
>> that have been signed. This makes it mandatory that upstream agents are
>> signature-aware.
>>
>> Regards,
>>
>> Lawrence
>>
>>
>> On Tue, Nov 23, 2010 at 1:26 PM, Adam Montville <[hidden email]>
>> wrote:
>>
>>
>> It seems that the key management implications of these features
> would
>> be significant.  Not saying that these features don't make sense, in fact,
>> just the opposite.  It seems, however, that this might be a set of features
>> that transcend CEE - other specifications may need this functionality as
>> well.  Consider XCCDF benchmarks with OVAL/OCIL checks as one example.
>>
>> How does everyone plan to deal with the key management aspect of
> these
>> features?
>>
>> Adam
>>
>>
>> -----Original Message-----
>> From: Heinbockel, Bill [mailto:[hidden email]]
>>
>> Sent: Monday, November 22, 2010 10:17 AM
>> To: [hidden email]
>>
>> Subject: [CEE-DISCUSSION-LIST] event integrity RE: [CEE-DISCUSSION-
>> LIST] xml documentation
>>
>> Bill,
>>
>> My thoughts on this is that there should be several features that
>> event-based
>> products may support.
>>
>> 1. Event level signatures - provide a hash or digital signature
> within
>> the event
>> content (possibly requiring canonicalization rules)
>> 2. Transport signatures - provide content integrity validation in
> the
>> event
>> transport or external envelope (e.g., ws sig, checksum, etc.)
>> 3. Event "stream" authentication - allow an event source and
>> destination to
>> authenticate an encrypted or other integrity-validated stream (BEEP
>> auth, DTLS
>> Syslog, etc.)
>>
>>
>> Depending on the environment and integrity needs, the end user
> should
>> have some
>> option to pick the level of integrity and overhead trade-off they
> are
>> willing to
>> accept
>>
>>
>> William Heinbockel
>> The MITRE Corporation
>>
>>
>>> -----Original Message-----
>>> From: Bill LeRoy [mailto:[hidden email]]
>>> Sent: Monday, 22 November 2010 10:39
>>> To: cee-discussion-list CEE-Related Discussion
>>> Subject: Re: [CEE-DISCUSSION-LIST] xml documentation
>>>
>>> Dear all,
>>>
>>> I don't know if there is any discussions in regard to
> non-repudiation
>>> of the event content.
>>> I have seen several methods from the BSD community with respect to
>>> digital signing of the event message
>>> but with respect to speed in sending signed events from devices
> there
>>> might be some significant overhead in performing
>>> such tasks. I believe one of the issues of the event content for
>>> example in syslog is the validity of the event source
>>> and the transaction of receiving the event. In the world of
>>> situational awareness the validity of the event becomes
>>> critical if all the members in a Family of Systems or Services are
>>> going to be aware of a common event or the correlation
>>> of numerous events. Although there might be front end controls that
>>> are put in place that might verify the transport between
>>> the source and destination but I believe that it is could be more
>>> efficient especially in historical examination if the source
>>> and destinations were able to sign the content in some agreeable
>>> format especially with event forwarding.
>>>
>>> Sincerely,
>>> Bill Le Roy
>>> CISA, CISM, CCSA
>>>
>>> On Mon, Nov 22, 2010 at 3:39 AM, Peter Czanik <[hidden email]>
>> wrote:
>>>> Hello,
>>>>
>>>> Most of cee-base-20100929.xml is not documented. Even where there
>> is a
>>>> few words of documentation, it's not always straightforward, in
>> which
>>>> form data is expected. So I'd be glad to see a 1-2 sentence
>>>> <Description></Description> for any tag or field in the file, as
> it
>>>> increases the chance, that I'll find the tag or field while
>> browsing the
>>>> XML.
>>>>
>>>> It would be great to also have an <Example></Example> line. For
>> example
>>>> for src_ipv4 it could be:
>>>>
>>>> <Field>
>>>> <Name>SourceIPv4Address</Name>
>>>> <ValueType>ipv4Address</ValueType>
>>>> <ShortName>src_ipv4</ShortName>
>>>> <FieldSet>SourceFieldSet</FieldSet>
>>>> <Description>The IPv4 address of the network communication
>>>> source</Description>
>>>> <Example>192.168.2.179</Example>
>>>> </Field>
>>>>
>>>>
>>>> I'd go as far as making these fields mandatory for other than
> Union
>>>> value types, like:
>>>>
>>>>                                <Name>systemname</Name>
>>>>                                <Union memberTypes="fqdn
>> ipAddress"/>
>>>>
>>>> As in this case there would already be examples at fqdn and
>> ipAdress
>>>> (which is in itself already a Union...).
>>>>
>>>> Bye,
>>>>
>>>> --
>>>> Peter Czanik (CzP) <[hidden email]>
>>>> BalaBit IT Security / syslog-ng upstream
>>>> http://czanik.blogs.balabit.com/
>>>>
>>>
>>>
>>>
>>> --
>>> Bill LeRoy
>>>
>>>
>>> [hidden email]
>>
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: event integrity RE: [CEE-DISCUSSION-LIST] xml documentation

heinbockel
In reply to this post by Bill Frank
Sorry, I should have been more specific.

If the SIM-modified record is passed along or is used anywhere outside of the
context of the SIM system, then there should be an option to have that record
signed as well. For example if the SIM records are stored offline, I would like
to have some validation that the record's integrity was not compromised.

For evidentiary purposes, we'd like to have the entire stack of events signed,
with the original messages being most critical.


William Heinbockel
The MITRE Corporation


>-----Original Message-----
>From: Bill Frank [mailto:[hidden email]]
>Sent: Monday, 29 November 2010 16:53
>To: Heinbockel, Bill; cee-discussion-list CEE-Related Discussion
>Subject: RE: [CEE-DISCUSSION-LIST] event integrity RE: [CEE-DISCUSSION-LIST]
>xml documentation
>
>Hi BillH,
>
>Not sure I see why the SIM-modified record would need to be signed. Only the
>original message generated by the device or application would be signed and
>used for evidentiary purposes. The SIM simply takes a copy of the original
>record and continues with whatever the appropriate processing is needed. The
>copied "operational" record could be modified as often as needed and would
>not be relevant for evidentiary purposes. Only the original signed record
>would be stored for evidentiary purposes.
>
>What am I missing?
>
>Bill Frank
>Cymbel
>508-878-4943
>
>
>-----Original Message-----
>From: Heinbockel, Bill [mailto:[hidden email]]
>Sent: Monday, November 29, 2010 11:11 AM
>To: [hidden email]
>Subject: Re: [CEE-DISCUSSION-LIST] event integrity RE: [CEE-DISCUSSION-LIST]
>xml documentation
>
>Going back to your previous e-mail, if we are worried about
>forensically-sound
>logs, then we must be able to maintain a signature for each event record
>(and
>modification thereof).
>
>From my standpoint, there are only 3 operations on an event record:
>CREATE  -- create a new record. This can be to reflect a new event, to
>summarize
>a previously created event, correlated events, etc.
>APPEND  -- add new fields to an existing record
>DELETE  -- delete or filter records
>
>If an upstream SIM agent wants to modify an event, then a new record should
>be
>created that references the existing record and has a new signature
>
>The support for multiple event signatures might be necessary for appending
>fields to an existing record. For this case, we could either create a new
>record
>or somehow wrap the old record with the new fields (and signature)
>
>
>>-----Original Message-----
>>From: Lawrence Smith [mailto:[hidden email]]
>>Sent: Saturday, 27 November 2010 01:43
>>To: cee-discussion-list CEE-Related Discussion
>>Subject: Re: [CEE-DISCUSSION-LIST] event integrity RE:
>[CEE-DISCUSSION-LIST]
>>xml documentation
>>
>>Adam,
>>
>>I agree that other specifications can make use of signatures and
>>authentication. I think, however, that the others you mentioned - since
>they
>>are XML based - may at least be able to make use of XML Signature. Since
>CEE
>>is designed to be Encoding Neutral, its requirements are somewhat
>different.
>>
>>Regardless of how signatures and authentication are implemented, I also
>>agree that key management is a significant issue. Not sure if it needs to
>be
>>addressed in the standard, but I'll remain open on the subject.
>>
>>Bill,
>>
>>I definitely think that event level signatures are a necessary option for
>>the end user. Consider that events may be tampered with after being stored
>>in a database. Stream and transport signatures will not help there. Event
>>level signatures do present a few interesting problems...
>>
>>* Besides the actual signature, you'd probably need to store a lot of
>>additional information with each and every event (algorithms, certificate
>>identifiers, etc.). This means either interdependent fields (e.g. a sig
>>field without a cert-id field is an error condition) or complex fields.
>>
>>* I'm not sure how much this has been talked about, but upstream agents may
>>augment or annotate the event. The original event generator may sign the
>>events that were generated, but this signature would have to specify which
>>fields were being signed. The upstream agent may add additional fields, and
>>may sign those as well (or all fields). I.e. I think the standard should be
>>able to support multiple signatures per event.
>>
>>* Some existing SEM Solutions have agents that may modify received events
>>(e.g. reducing a FQDN to just a hostname, translating a NAT-ed address). If
>>events are signed, then an upstream agent should not modify those fields
>>that have been signed. This makes it mandatory that upstream agents are
>>signature-aware.
>>
>>Regards,
>>
>>Lawrence
>>
>>
>>On Tue, Nov 23, 2010 at 1:26 PM, Adam Montville <[hidden email]>
>>wrote:
>>
>>
>> It seems that the key management implications of these features
>would
>>be significant.  Not saying that these features don't make sense, in fact,
>>just the opposite.  It seems, however, that this might be a set of features
>>that transcend CEE - other specifications may need this functionality as
>>well.  Consider XCCDF benchmarks with OVAL/OCIL checks as one example.
>>
>> How does everyone plan to deal with the key management aspect of
>these
>>features?
>>
>> Adam
>>
>>
>> -----Original Message-----
>> From: Heinbockel, Bill [mailto:[hidden email]]
>>
>> Sent: Monday, November 22, 2010 10:17 AM
>> To: [hidden email]
>>
>> Subject: [CEE-DISCUSSION-LIST] event integrity RE: [CEE-DISCUSSION-
>>LIST] xml documentation
>>
>> Bill,
>>
>> My thoughts on this is that there should be several features that
>>event-based
>> products may support.
>>
>> 1. Event level signatures - provide a hash or digital signature
>within
>>the event
>> content (possibly requiring canonicalization rules)
>> 2. Transport signatures - provide content integrity validation in
>the
>>event
>> transport or external envelope (e.g., ws sig, checksum, etc.)
>> 3. Event "stream" authentication - allow an event source and
>>destination to
>> authenticate an encrypted or other integrity-validated stream (BEEP
>>auth, DTLS
>> Syslog, etc.)
>>
>>
>> Depending on the environment and integrity needs, the end user
>should
>>have some
>> option to pick the level of integrity and overhead trade-off they
>are
>>willing to
>> accept
>>
>>
>> William Heinbockel
>> The MITRE Corporation
>>
>>
>> >-----Original Message-----
>> >From: Bill LeRoy [mailto:[hidden email]]
>> >Sent: Monday, 22 November 2010 10:39
>> >To: cee-discussion-list CEE-Related Discussion
>> >Subject: Re: [CEE-DISCUSSION-LIST] xml documentation
>> >
>> >Dear all,
>> >
>> >I don't know if there is any discussions in regard to
>non-repudiation
>> >of the event content.
>> >I have seen several methods from the BSD community with respect to
>> >digital signing of the event message
>> >but with respect to speed in sending signed events from devices
>there
>> >might be some significant overhead in performing
>> >such tasks. I believe one of the issues of the event content for
>> >example in syslog is the validity of the event source
>> >and the transaction of receiving the event. In the world of
>> >situational awareness the validity of the event becomes
>> >critical if all the members in a Family of Systems or Services are
>> >going to be aware of a common event or the correlation
>> >of numerous events. Although there might be front end controls that
>> >are put in place that might verify the transport between
>> >the source and destination but I believe that it is could be more
>> >efficient especially in historical examination if the source
>> >and destinations were able to sign the content in some agreeable
>> >format especially with event forwarding.
>> >
>> >Sincerely,
>> >Bill Le Roy
>> >CISA, CISM, CCSA
>> >
>> >On Mon, Nov 22, 2010 at 3:39 AM, Peter Czanik <[hidden email]>
>>wrote:
>> >> Hello,
>> >>
>> >> Most of cee-base-20100929.xml is not documented. Even where there
>>is a
>> >> few words of documentation, it's not always straightforward, in
>>which
>> >> form data is expected. So I'd be glad to see a 1-2 sentence
>> >> <Description></Description> for any tag or field in the file, as
>it
>> >> increases the chance, that I'll find the tag or field while
>>browsing the
>> >> XML.
>> >>
>> >> It would be great to also have an <Example></Example> line. For
>>example
>> >> for src_ipv4 it could be:
>> >>
>> >> <Field>
>> >> <Name>SourceIPv4Address</Name>
>> >> <ValueType>ipv4Address</ValueType>
>> >> <ShortName>src_ipv4</ShortName>
>> >> <FieldSet>SourceFieldSet</FieldSet>
>> >> <Description>The IPv4 address of the network communication
>> >> source</Description>
>> >> <Example>192.168.2.179</Example>
>> >> </Field>
>> >>
>> >>
>> >> I'd go as far as making these fields mandatory for other than
>Union
>> >> value types, like:
>> >>
>> >>                                <Name>systemname</Name>
>> >>                                <Union memberTypes="fqdn
>>ipAddress"/>
>> >>
>> >> As in this case there would already be examples at fqdn and
>>ipAdress
>> >> (which is in itself already a Union...).
>> >>
>> >> Bye,
>> >>
>> >> --
>> >> Peter Czanik (CzP) <[hidden email]>
>> >> BalaBit IT Security / syslog-ng upstream
>> >> http://czanik.blogs.balabit.com/
>> >>
>> >
>> >
>> >
>> >--
>> >Bill LeRoy
>> >
>> >
>> >[hidden email]
>>
>>
>


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

Re: event integrity RE: [CEE-DISCUSSION-LIST] xml documentation

Eric Fitzgerald
Event-level signing fails to address the issue of log integrity.

I could have a completely false log consisting of event records with valid record-level signatures.  Ordering and completeness matter.  I read Counterpane's papers on this some time back, and recall that one of the more efficient ways to do integrity was hash chaining- e.g. each record is hashed, not signed, but the hash of the previous record was part of the data that was hashed for the current record.  (I will forgo deeply technical discussion of engineering optimizations for periodic checkpoint events, etc.).

I think that an event stream level signature combined with hash chaining would probably be a far superior solution to event level signing.


-----Original Message-----
From: Heinbockel, Bill [mailto:[hidden email]]
Sent: Wednesday, December 01, 2010 10:54 AM
To: [hidden email]
Subject: Re: [CEE-DISCUSSION-LIST] event integrity RE: [CEE-DISCUSSION-LIST] xml documentation

Sorry, I should have been more specific.

If the SIM-modified record is passed along or is used anywhere outside of the
context of the SIM system, then there should be an option to have that record
signed as well. For example if the SIM records are stored offline, I would like
to have some validation that the record's integrity was not compromised.

For evidentiary purposes, we'd like to have the entire stack of events signed,
with the original messages being most critical.


William Heinbockel
The MITRE Corporation


>-----Original Message-----
>From: Bill Frank [mailto:[hidden email]]
>Sent: Monday, 29 November 2010 16:53
>To: Heinbockel, Bill; cee-discussion-list CEE-Related Discussion
>Subject: RE: [CEE-DISCUSSION-LIST] event integrity RE: [CEE-DISCUSSION-LIST]
>xml documentation
>
>Hi BillH,
>
>Not sure I see why the SIM-modified record would need to be signed. Only the
>original message generated by the device or application would be signed and
>used for evidentiary purposes. The SIM simply takes a copy of the original
>record and continues with whatever the appropriate processing is needed. The
>copied "operational" record could be modified as often as needed and would
>not be relevant for evidentiary purposes. Only the original signed record
>would be stored for evidentiary purposes.
>
>What am I missing?
>
>Bill Frank
>Cymbel
>508-878-4943
>
>
>-----Original Message-----
>From: Heinbockel, Bill [mailto:[hidden email]]
>Sent: Monday, November 29, 2010 11:11 AM
>To: [hidden email]
>Subject: Re: [CEE-DISCUSSION-LIST] event integrity RE: [CEE-DISCUSSION-LIST]
>xml documentation
>
>Going back to your previous e-mail, if we are worried about
>forensically-sound
>logs, then we must be able to maintain a signature for each event record
>(and
>modification thereof).
>
>From my standpoint, there are only 3 operations on an event record:
>CREATE  -- create a new record. This can be to reflect a new event, to
>summarize
>a previously created event, correlated events, etc.
>APPEND  -- add new fields to an existing record
>DELETE  -- delete or filter records
>
>If an upstream SIM agent wants to modify an event, then a new record should
>be
>created that references the existing record and has a new signature
>
>The support for multiple event signatures might be necessary for appending
>fields to an existing record. For this case, we could either create a new
>record
>or somehow wrap the old record with the new fields (and signature)
>
>
>>-----Original Message-----
>>From: Lawrence Smith [mailto:[hidden email]]
>>Sent: Saturday, 27 November 2010 01:43
>>To: cee-discussion-list CEE-Related Discussion
>>Subject: Re: [CEE-DISCUSSION-LIST] event integrity RE:
>[CEE-DISCUSSION-LIST]
>>xml documentation
>>
>>Adam,
>>
>>I agree that other specifications can make use of signatures and
>>authentication. I think, however, that the others you mentioned - since
>they
>>are XML based - may at least be able to make use of XML Signature. Since
>CEE
>>is designed to be Encoding Neutral, its requirements are somewhat
>different.
>>
>>Regardless of how signatures and authentication are implemented, I also
>>agree that key management is a significant issue. Not sure if it needs to
>be
>>addressed in the standard, but I'll remain open on the subject.
>>
>>Bill,
>>
>>I definitely think that event level signatures are a necessary option for
>>the end user. Consider that events may be tampered with after being stored
>>in a database. Stream and transport signatures will not help there. Event
>>level signatures do present a few interesting problems...
>>
>>* Besides the actual signature, you'd probably need to store a lot of
>>additional information with each and every event (algorithms, certificate
>>identifiers, etc.). This means either interdependent fields (e.g. a sig
>>field without a cert-id field is an error condition) or complex fields.
>>
>>* I'm not sure how much this has been talked about, but upstream agents may
>>augment or annotate the event. The original event generator may sign the
>>events that were generated, but this signature would have to specify which
>>fields were being signed. The upstream agent may add additional fields, and
>>may sign those as well (or all fields). I.e. I think the standard should be
>>able to support multiple signatures per event.
>>
>>* Some existing SEM Solutions have agents that may modify received events
>>(e.g. reducing a FQDN to just a hostname, translating a NAT-ed address). If
>>events are signed, then an upstream agent should not modify those fields
>>that have been signed. This makes it mandatory that upstream agents are
>>signature-aware.
>>
>>Regards,
>>
>>Lawrence
>>
>>
>>On Tue, Nov 23, 2010 at 1:26 PM, Adam Montville <[hidden email]>
>>wrote:
>>
>>
>> It seems that the key management implications of these features
>would
>>be significant.  Not saying that these features don't make sense, in fact,
>>just the opposite.  It seems, however, that this might be a set of features
>>that transcend CEE - other specifications may need this functionality as
>>well.  Consider XCCDF benchmarks with OVAL/OCIL checks as one example.
>>
>> How does everyone plan to deal with the key management aspect of
>these
>>features?
>>
>> Adam
>>
>>
>> -----Original Message-----
>> From: Heinbockel, Bill [mailto:[hidden email]]
>>
>> Sent: Monday, November 22, 2010 10:17 AM
>> To: [hidden email]
>>
>> Subject: [CEE-DISCUSSION-LIST] event integrity RE: [CEE-DISCUSSION-
>>LIST] xml documentation
>>
>> Bill,
>>
>> My thoughts on this is that there should be several features that
>>event-based
>> products may support.
>>
>> 1. Event level signatures - provide a hash or digital signature
>within
>>the event
>> content (possibly requiring canonicalization rules)
>> 2. Transport signatures - provide content integrity validation in
>the
>>event
>> transport or external envelope (e.g., ws sig, checksum, etc.)
>> 3. Event "stream" authentication - allow an event source and
>>destination to
>> authenticate an encrypted or other integrity-validated stream (BEEP
>>auth, DTLS
>> Syslog, etc.)
>>
>>
>> Depending on the environment and integrity needs, the end user
>should
>>have some
>> option to pick the level of integrity and overhead trade-off they
>are
>>willing to
>> accept
>>
>>
>> William Heinbockel
>> The MITRE Corporation
>>
>>
>> >-----Original Message-----
>> >From: Bill LeRoy [mailto:[hidden email]]
>> >Sent: Monday, 22 November 2010 10:39
>> >To: cee-discussion-list CEE-Related Discussion
>> >Subject: Re: [CEE-DISCUSSION-LIST] xml documentation
>> >
>> >Dear all,
>> >
>> >I don't know if there is any discussions in regard to
>non-repudiation
>> >of the event content.
>> >I have seen several methods from the BSD community with respect to
>> >digital signing of the event message
>> >but with respect to speed in sending signed events from devices
>there
>> >might be some significant overhead in performing
>> >such tasks. I believe one of the issues of the event content for
>> >example in syslog is the validity of the event source
>> >and the transaction of receiving the event. In the world of
>> >situational awareness the validity of the event becomes
>> >critical if all the members in a Family of Systems or Services are
>> >going to be aware of a common event or the correlation
>> >of numerous events. Although there might be front end controls that
>> >are put in place that might verify the transport between
>> >the source and destination but I believe that it is could be more
>> >efficient especially in historical examination if the source
>> >and destinations were able to sign the content in some agreeable
>> >format especially with event forwarding.
>> >
>> >Sincerely,
>> >Bill Le Roy
>> >CISA, CISM, CCSA
>> >
>> >On Mon, Nov 22, 2010 at 3:39 AM, Peter Czanik <[hidden email]>
>>wrote:
>> >> Hello,
>> >>
>> >> Most of cee-base-20100929.xml is not documented. Even where there
>>is a
>> >> few words of documentation, it's not always straightforward, in
>>which
>> >> form data is expected. So I'd be glad to see a 1-2 sentence
>> >> <Description></Description> for any tag or field in the file, as
>it
>> >> increases the chance, that I'll find the tag or field while
>>browsing the
>> >> XML.
>> >>
>> >> It would be great to also have an <Example></Example> line. For
>>example
>> >> for src_ipv4 it could be:
>> >>
>> >> <Field>
>> >> <Name>SourceIPv4Address</Name>
>> >> <ValueType>ipv4Address</ValueType>
>> >> <ShortName>src_ipv4</ShortName>
>> >> <FieldSet>SourceFieldSet</FieldSet>
>> >> <Description>The IPv4 address of the network communication
>> >> source</Description>
>> >> <Example>192.168.2.179</Example>
>> >> </Field>
>> >>
>> >>
>> >> I'd go as far as making these fields mandatory for other than
>Union
>> >> value types, like:
>> >>
>> >>                                <Name>systemname</Name>
>> >>                                <Union memberTypes="fqdn
>>ipAddress"/>
>> >>
>> >> As in this case there would already be examples at fqdn and
>>ipAdress
>> >> (which is in itself already a Union...).
>> >>
>> >> Bye,
>> >>
>> >> --
>> >> Peter Czanik (CzP) <[hidden email]>
>> >> BalaBit IT Security / syslog-ng upstream
>> >> http://czanik.blogs.balabit.com/
>> >>
>> >
>> >
>> >
>> >--
>> >Bill LeRoy
>> >
>> >
>> >[hidden email]
>>
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: event integrity RE: [CEE-DISCUSSION-LIST] xml documentation

Adam Montville
Hash chaining doesn't sound like such a bad idea.  Is there a standard for that or is it more or less an ad hoc technique?  Hashes are quick and there's no key management required.

Adam

-----Original Message-----
From: Eric Fitzgerald [mailto:[hidden email]]
Sent: Wednesday, December 01, 2010 5:55 PM
To: [hidden email]
Subject: Re: [CEE-DISCUSSION-LIST] event integrity RE: [CEE-DISCUSSION-LIST] xml documentation

Event-level signing fails to address the issue of log integrity.

I could have a completely false log consisting of event records with valid record-level signatures.  Ordering and completeness matter.  I read Counterpane's papers on this some time back, and recall that one of the more efficient ways to do integrity was hash chaining- e.g. each record is hashed, not signed, but the hash of the previous record was part of the data that was hashed for the current record.  (I will forgo deeply technical discussion of engineering optimizations for periodic checkpoint events, etc.).

I think that an event stream level signature combined with hash chaining would probably be a far superior solution to event level signing.


-----Original Message-----
From: Heinbockel, Bill [mailto:[hidden email]]
Sent: Wednesday, December 01, 2010 10:54 AM
To: [hidden email]
Subject: Re: [CEE-DISCUSSION-LIST] event integrity RE: [CEE-DISCUSSION-LIST] xml documentation

Sorry, I should have been more specific.

If the SIM-modified record is passed along or is used anywhere outside of the
context of the SIM system, then there should be an option to have that record
signed as well. For example if the SIM records are stored offline, I would like
to have some validation that the record's integrity was not compromised.

For evidentiary purposes, we'd like to have the entire stack of events signed,
with the original messages being most critical.


William Heinbockel
The MITRE Corporation


>-----Original Message-----
>From: Bill Frank [mailto:[hidden email]]
>Sent: Monday, 29 November 2010 16:53
>To: Heinbockel, Bill; cee-discussion-list CEE-Related Discussion
>Subject: RE: [CEE-DISCUSSION-LIST] event integrity RE: [CEE-DISCUSSION-LIST]
>xml documentation
>
>Hi BillH,
>
>Not sure I see why the SIM-modified record would need to be signed. Only the
>original message generated by the device or application would be signed and
>used for evidentiary purposes. The SIM simply takes a copy of the original
>record and continues with whatever the appropriate processing is needed. The
>copied "operational" record could be modified as often as needed and would
>not be relevant for evidentiary purposes. Only the original signed record
>would be stored for evidentiary purposes.
>
>What am I missing?
>
>Bill Frank
>Cymbel
>508-878-4943
>
>
>-----Original Message-----
>From: Heinbockel, Bill [mailto:[hidden email]]
>Sent: Monday, November 29, 2010 11:11 AM
>To: [hidden email]
>Subject: Re: [CEE-DISCUSSION-LIST] event integrity RE: [CEE-DISCUSSION-LIST]
>xml documentation
>
>Going back to your previous e-mail, if we are worried about
>forensically-sound
>logs, then we must be able to maintain a signature for each event record
>(and
>modification thereof).
>
>From my standpoint, there are only 3 operations on an event record:
>CREATE  -- create a new record. This can be to reflect a new event, to
>summarize
>a previously created event, correlated events, etc.
>APPEND  -- add new fields to an existing record
>DELETE  -- delete or filter records
>
>If an upstream SIM agent wants to modify an event, then a new record should
>be
>created that references the existing record and has a new signature
>
>The support for multiple event signatures might be necessary for appending
>fields to an existing record. For this case, we could either create a new
>record
>or somehow wrap the old record with the new fields (and signature)
>
>
>>-----Original Message-----
>>From: Lawrence Smith [mailto:[hidden email]]
>>Sent: Saturday, 27 November 2010 01:43
>>To: cee-discussion-list CEE-Related Discussion
>>Subject: Re: [CEE-DISCUSSION-LIST] event integrity RE:
>[CEE-DISCUSSION-LIST]
>>xml documentation
>>
>>Adam,
>>
>>I agree that other specifications can make use of signatures and
>>authentication. I think, however, that the others you mentioned - since
>they
>>are XML based - may at least be able to make use of XML Signature. Since
>CEE
>>is designed to be Encoding Neutral, its requirements are somewhat
>different.
>>
>>Regardless of how signatures and authentication are implemented, I also
>>agree that key management is a significant issue. Not sure if it needs to
>be
>>addressed in the standard, but I'll remain open on the subject.
>>
>>Bill,
>>
>>I definitely think that event level signatures are a necessary option for
>>the end user. Consider that events may be tampered with after being stored
>>in a database. Stream and transport signatures will not help there. Event
>>level signatures do present a few interesting problems...
>>
>>* Besides the actual signature, you'd probably need to store a lot of
>>additional information with each and every event (algorithms, certificate
>>identifiers, etc.). This means either interdependent fields (e.g. a sig
>>field without a cert-id field is an error condition) or complex fields.
>>
>>* I'm not sure how much this has been talked about, but upstream agents may
>>augment or annotate the event. The original event generator may sign the
>>events that were generated, but this signature would have to specify which
>>fields were being signed. The upstream agent may add additional fields, and
>>may sign those as well (or all fields). I.e. I think the standard should be
>>able to support multiple signatures per event.
>>
>>* Some existing SEM Solutions have agents that may modify received events
>>(e.g. reducing a FQDN to just a hostname, translating a NAT-ed address). If
>>events are signed, then an upstream agent should not modify those fields
>>that have been signed. This makes it mandatory that upstream agents are
>>signature-aware.
>>
>>Regards,
>>
>>Lawrence
>>
>>
>>On Tue, Nov 23, 2010 at 1:26 PM, Adam Montville <[hidden email]>
>>wrote:
>>
>>
>> It seems that the key management implications of these features
>would
>>be significant.  Not saying that these features don't make sense, in fact,
>>just the opposite.  It seems, however, that this might be a set of features
>>that transcend CEE - other specifications may need this functionality as
>>well.  Consider XCCDF benchmarks with OVAL/OCIL checks as one example.
>>
>> How does everyone plan to deal with the key management aspect of
>these
>>features?
>>
>> Adam
>>
>>
>> -----Original Message-----
>> From: Heinbockel, Bill [mailto:[hidden email]]
>>
>> Sent: Monday, November 22, 2010 10:17 AM
>> To: [hidden email]
>>
>> Subject: [CEE-DISCUSSION-LIST] event integrity RE: [CEE-DISCUSSION-
>>LIST] xml documentation
>>
>> Bill,
>>
>> My thoughts on this is that there should be several features that
>>event-based
>> products may support.
>>
>> 1. Event level signatures - provide a hash or digital signature
>within
>>the event
>> content (possibly requiring canonicalization rules)
>> 2. Transport signatures - provide content integrity validation in
>the
>>event
>> transport or external envelope (e.g., ws sig, checksum, etc.)
>> 3. Event "stream" authentication - allow an event source and
>>destination to
>> authenticate an encrypted or other integrity-validated stream (BEEP
>>auth, DTLS
>> Syslog, etc.)
>>
>>
>> Depending on the environment and integrity needs, the end user
>should
>>have some
>> option to pick the level of integrity and overhead trade-off they
>are
>>willing to
>> accept
>>
>>
>> William Heinbockel
>> The MITRE Corporation
>>
>>
>> >-----Original Message-----
>> >From: Bill LeRoy [mailto:[hidden email]]
>> >Sent: Monday, 22 November 2010 10:39
>> >To: cee-discussion-list CEE-Related Discussion
>> >Subject: Re: [CEE-DISCUSSION-LIST] xml documentation
>> >
>> >Dear all,
>> >
>> >I don't know if there is any discussions in regard to
>non-repudiation
>> >of the event content.
>> >I have seen several methods from the BSD community with respect to
>> >digital signing of the event message
>> >but with respect to speed in sending signed events from devices
>there
>> >might be some significant overhead in performing
>> >such tasks. I believe one of the issues of the event content for
>> >example in syslog is the validity of the event source
>> >and the transaction of receiving the event. In the world of
>> >situational awareness the validity of the event becomes
>> >critical if all the members in a Family of Systems or Services are
>> >going to be aware of a common event or the correlation
>> >of numerous events. Although there might be front end controls that
>> >are put in place that might verify the transport between
>> >the source and destination but I believe that it is could be more
>> >efficient especially in historical examination if the source
>> >and destinations were able to sign the content in some agreeable
>> >format especially with event forwarding.
>> >
>> >Sincerely,
>> >Bill Le Roy
>> >CISA, CISM, CCSA
>> >
>> >On Mon, Nov 22, 2010 at 3:39 AM, Peter Czanik <[hidden email]>
>>wrote:
>> >> Hello,
>> >>
>> >> Most of cee-base-20100929.xml is not documented. Even where there
>>is a
>> >> few words of documentation, it's not always straightforward, in
>>which
>> >> form data is expected. So I'd be glad to see a 1-2 sentence
>> >> <Description></Description> for any tag or field in the file, as
>it
>> >> increases the chance, that I'll find the tag or field while
>>browsing the
>> >> XML.
>> >>
>> >> It would be great to also have an <Example></Example> line. For
>>example
>> >> for src_ipv4 it could be:
>> >>
>> >> <Field>
>> >> <Name>SourceIPv4Address</Name>
>> >> <ValueType>ipv4Address</ValueType>
>> >> <ShortName>src_ipv4</ShortName>
>> >> <FieldSet>SourceFieldSet</FieldSet>
>> >> <Description>The IPv4 address of the network communication
>> >> source</Description>
>> >> <Example>192.168.2.179</Example>
>> >> </Field>
>> >>
>> >>
>> >> I'd go as far as making these fields mandatory for other than
>Union
>> >> value types, like:
>> >>
>> >>                                <Name>systemname</Name>
>> >>                                <Union memberTypes="fqdn
>>ipAddress"/>
>> >>
>> >> As in this case there would already be examples at fqdn and
>>ipAdress
>> >> (which is in itself already a Union...).
>> >>
>> >> Bye,
>> >>
>> >> --
>> >> Peter Czanik (CzP) <[hidden email]>
>> >> BalaBit IT Security / syslog-ng upstream
>> >> http://czanik.blogs.balabit.com/
>> >>
>> >
>> >
>> >
>> >--
>> >Bill LeRoy
>> >
>> >
>> >[hidden email]
>>
>>
>
12