xml documentation

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

xml documentation

Peter Czanik
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/
Reply | Threaded
Open this post in threaded view
|

Re: xml documentation

Grimaila, Michael R Civ USAF AETC AFIT/ENV
Peter,

I agree that this is an issue.

One problem we have encountered is ambiguity in the interpretation if
there is not a clearly defined context and meaning for each field.

Michael

//SIGNED//

MICHAEL R. GRIMAILA, Ph.D., CISM, CISSP, IAM/IEM
Associate Professor of Information Resource Management
Department of Systems and Engineering Management
Center for Cyberspace Research
Air Force Institute of Technology

AFIT/ENV
2950 Hobson Way
Building 640, Room 107C
Wright-Patterson AFB, OH 45433-7765
Telephone: 937-255-3636 ext 4800 (DSN 785)
Fax: 937-656-4699 (DSN 986)
[hidden email]
[hidden email]

-----Original Message-----
From: Peter Czanik [mailto:[hidden email]]
Sent: Monday, November 22, 2010 3:40 AM
To: [hidden email]
Subject: [CEE-DISCUSSION-LIST] xml documentation

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/
Reply | Threaded
Open this post in threaded view
|

Re: xml documentation

bleroy
In reply to this post by Peter Czanik
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: xml documentation

heinbockel
In reply to this post by Peter Czanik
We are still missing most of the descriptions -- the priority thus far has been
to determine the specifications. We will be working on filling out the
descriptions
I do like your idea of adding examples and we should consider adding them as
optional elements.

The end goal is to make the XML available as browse-able and linkable HTML on
the website.
I think this will help with navigation and such.


William Heinbockel
The MITRE Corporation

>-----Original Message-----
>From: Peter Czanik [mailto:[hidden email]]
>Sent: Monday, 22 November 2010 03:40
>To: cee-discussion-list CEE-Related Discussion
>Subject: [CEE-DISCUSSION-LIST] xml documentation
>
>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/

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

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

heinbockel
In reply to this post by bleroy
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

Gabrielson, Bruce C.
Bill

I found it necessary to incorporate both a transport signature and an event
authentication in my current program.

Bruce

-----Original Message-----
From: Heinbockel, Bill [mailto:[hidden email]]
Sent: Monday, November 22, 2010 1:17 PM
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 (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Adam Montville
In reply to this post by heinbockel
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
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

* 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.

 

I agree that event level signatures are needed. There is no doubt that “upstream agents” enrich/augment events. However, these upstream systems can simply copy the original event and proceed to do whatever it needs to do with the copy. The original, signed events are retained separately for evidentiary purposes. This is what many Log Management systems do now anyway, with or without event level signing.

 

Therefore there is no reason to over-complicate the specification with field level signing.

 

Bill Frank

 

From: Lawrence Smith [mailto:[hidden email]]
Sent: Saturday, November 27, 2010 1:43 AM
To: [hidden email]
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
Bill,

Thanks for the feedback! In the scenario you suggest (where the upstream agent copies the original event), what happens to that original event? Does it continue upstream along with the new message? Is it encapsulated in the new message? Is it immediately saved separately for evidentiary purposes?

Regards,

Lawrence Smith, CISSP, CSSLP

On Sat, Nov 27, 2010 at 10:09 AM, Bill Frank <[hidden email]> wrote:

* 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.

 

I agree that event level signatures are needed. There is no doubt that “upstream agents” enrich/augment events. However, these upstream systems can simply copy the original event and proceed to do whatever it needs to do with the copy. The original, signed events are retained separately for evidentiary purposes. This is what many Log Management systems do now anyway, with or without event level signing.

 

Therefore there is no reason to over-complicate the specification with field level signing.

 

Bill Frank

 

From: Lawrence Smith [mailto:[hidden email]]
Sent: Saturday, November 27, 2010 1:43 AM

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

It depends on the architecture of the SIEM. Usually, the original message continues on upstream along with the enriched version of the message. You can think of the original message as a field within the enriched message. The original message is stored separately for evidentiary purposes.

 

Bill Frank

Cymbel

 

From: Lawrence Smith [mailto:[hidden email]]
Sent: Saturday, November 27, 2010 10:54 PM
To: Bill Frank
Cc: [hidden email]
Subject: Re: [CEE-DISCUSSION-LIST] event integrity RE: [CEE-DISCUSSION-LIST] xml documentation

 

Bill,

 

Thanks for the feedback! In the scenario you suggest (where the upstream agent copies the original event), what happens to that original event? Does it continue upstream along with the new message? Is it encapsulated in the new message? Is it immediately saved separately for evidentiary purposes?

 

Regards,

 

Lawrence Smith, CISSP, CSSLP

On Sat, Nov 27, 2010 at 10:09 AM, Bill Frank <[hidden email]> wrote:

* 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.

 

I agree that event level signatures are needed. There is no doubt that “upstream agents” enrich/augment events. However, these upstream systems can simply copy the original event and proceed to do whatever it needs to do with the copy. The original, signed events are retained separately for evidentiary purposes. This is what many Log Management systems do now anyway, with or without event level signing.

 

Therefore there is no reason to over-complicate the specification with field level signing.

 

Bill Frank

 

From: Lawrence Smith [mailto:[hidden email]]
Sent: Saturday, November 27, 2010 1:43 AM

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
I think that encapsulating an event inside another another would work for preserving the validity of any signature.

Does CEE then need to define how to encapsulate one event inside of another?

What about multiple upstream agents? We could wind up with an event inside of an event inside of an event.

Lawrence Smith, CISSP, CSSLP



On Sun, Nov 28, 2010 at 1:29 PM, Bill Frank <[hidden email]> wrote:

It depends on the architecture of the SIEM. Usually, the original message continues on upstream along with the enriched version of the message. You can think of the original message as a field within the enriched message. The original message is stored separately for evidentiary purposes.

 

Bill Frank

Cymbel

 

From: Lawrence Smith [mailto:[hidden email]]
Sent: Saturday, November 27, 2010 10:54 PM
To: Bill Frank
Cc: [hidden email]


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

 

Bill,

 

Thanks for the feedback! In the scenario you suggest (where the upstream agent copies the original event), what happens to that original event? Does it continue upstream along with the new message? Is it encapsulated in the new message? Is it immediately saved separately for evidentiary purposes?

 

Regards,

 

Lawrence Smith, CISSP, CSSLP

On Sat, Nov 27, 2010 at 10:09 AM, Bill Frank <[hidden email]> wrote:

* 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.

 

I agree that event level signatures are needed. There is no doubt that “upstream agents” enrich/augment events. However, these upstream systems can simply copy the original event and proceed to do whatever it needs to do with the copy. The original, signed events are retained separately for evidentiary purposes. This is what many Log Management systems do now anyway, with or without event level signing.

 

Therefore there is no reason to over-complicate the specification with field level signing.

 

Bill Frank

 

From: Lawrence Smith [mailto:[hidden email]]
Sent: Saturday, November 27, 2010 1:43 AM

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

Rainer Gerhards
> -----Original Message-----
> From: Lawrence Smith [mailto:[hidden email]]
> Sent: Sunday, November 28, 2010 9:50 PM
> To: [hidden email]
> Subject: Re: [CEE-DISCUSSION-LIST] event integrity RE: [CEE-DISCUSSION-
> LIST] xml documentation
>
> I think that encapsulating an event inside another another would work
> for preserving the validity of any signature.
>
> Does CEE then need to define how to encapsulate one event inside of
> another?

It is not explicitly defined, but within the spec. You need to think of the
original event just as an opaque string. CEE supports encoding opaque strings
within a field. As such, one event a can be encoded inside a field of event b
by simple encoding a according the CEE encoding rules for opaque strings. Of
course the result may look a bit puzzling to a human, but I do not think this
is too big a problem. The advantage is that from this PoV you can even nicely
have multiple recursive levels of events within events.

Rainer
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 Lawrence Smith

It’s been my experience that there is only one point in the process to encapsulate the original message. If there are multiple points of enrichment, the one enriched event continues to get enriched.  Does that make sense?

 

Bill Frank

Cymbel

508-878-4943

 

From: Lawrence Smith [mailto:[hidden email]]
Sent: Sunday, November 28, 2010 3:50 PM
To: Bill Frank
Cc: [hidden email]
Subject: Re: [CEE-DISCUSSION-LIST] event integrity RE: [CEE-DISCUSSION-LIST] xml documentation

 

I think that encapsulating an event inside another another would work for preserving the validity of any signature.

 

Does CEE then need to define how to encapsulate one event inside of another?

 

What about multiple upstream agents? We could wind up with an event inside of an event inside of an event.

 

Lawrence Smith, CISSP, CSSLP

 

 

On Sun, Nov 28, 2010 at 1:29 PM, Bill Frank <[hidden email]> wrote:

It depends on the architecture of the SIEM. Usually, the original message continues on upstream along with the enriched version of the message. You can think of the original message as a field within the enriched message. The original message is stored separately for evidentiary purposes.

 

Bill Frank

Cymbel

 

From: Lawrence Smith [mailto:[hidden email]]
Sent: Saturday, November 27, 2010 10:54 PM
To: Bill Frank
Cc: [hidden email]


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

 

Bill,

 

Thanks for the feedback! In the scenario you suggest (where the upstream agent copies the original event), what happens to that original event? Does it continue upstream along with the new message? Is it encapsulated in the new message? Is it immediately saved separately for evidentiary purposes?

 

Regards,

 

Lawrence Smith, CISSP, CSSLP

On Sat, Nov 27, 2010 at 10:09 AM, Bill Frank <[hidden email]> wrote:

* 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.

 

I agree that event level signatures are needed. There is no doubt that “upstream agents” enrich/augment events. However, these upstream systems can simply copy the original event and proceed to do whatever it needs to do with the copy. The original, signed events are retained separately for evidentiary purposes. This is what many Log Management systems do now anyway, with or without event level signing.

 

Therefore there is no reason to over-complicate the specification with field level signing.

 

Bill Frank

 

From: Lawrence Smith [mailto:[hidden email]]
Sent: Saturday, November 27, 2010 1:43 AM

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
In reply to this post by Rainer Gerhards
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?

Bill Frank
Cymbel
508-878-4943

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

> -----Original Message-----
> From: Lawrence Smith [mailto:[hidden email]]
> Sent: Sunday, November 28, 2010 9:50 PM
> To: [hidden email]
> Subject: Re: [CEE-DISCUSSION-LIST] event integrity RE: [CEE-DISCUSSION-
> LIST] xml documentation
>
> I think that encapsulating an event inside another another would work
> for preserving the validity of any signature.
>
> Does CEE then need to define how to encapsulate one event inside of
> another?

It is not explicitly defined, but within the spec. You need to think of the
original event just as an opaque string. CEE supports encoding opaque
strings
within a field. As such, one event a can be encoded inside a field of event
b
by simple encoding a according the CEE encoding rules for opaque strings. Of
course the result may look a bit puzzling to a human, but I do not think
this
is too big a problem. The advantage is that from this PoV you can even
nicely
have multiple recursive levels of events within events.

Rainer
Reply | Threaded
Open this post in threaded view
|

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

Rainer Gerhards
> -----Original Message-----
> From: Bill Frank [mailto:[hidden email]]
> Sent: Monday, November 29, 2010 1:35 PM
> To: Rainer Gerhards; [hidden email]
> Subject: RE: [CEE-DISCUSSION-LIST] event integrity RE: [CEE-DISCUSSION-
> LIST] xml documentation
>
> 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?

That's a good point. I tend to think that we should at least mention the
potential problem and tell the simple solution that the original event must
be preserved if any transformations need to be done AND the signature must
remain valid.

But my personal view is that I don't think that it would be wise to go
further than that for the initial release of CEE. That will complicate things
and I think it will lead to CEE becoming available (much?) later. That in
turn would mean that we postpone all features "just" because we could not get
some features in. IMHO it is better to release a set of core features and
then extend on that. So at least part of the benefits will become available
as early as possible.

Rainer  

>
> Bill Frank
> Cymbel
> 508-878-4943
>
> -----Original Message-----
> From: Rainer Gerhards [mailto:[hidden email]]
> Sent: Monday, November 29, 2010 5:14 AM
> To: [hidden email]
> Subject: Re: [CEE-DISCUSSION-LIST] event integrity RE: [CEE-DISCUSSION-
> LIST]
> xml documentation
>
> > -----Original Message-----
> > From: Lawrence Smith [mailto:[hidden email]]
> > Sent: Sunday, November 28, 2010 9:50 PM
> > To: [hidden email]
> > Subject: Re: [CEE-DISCUSSION-LIST] event integrity RE: [CEE-
> DISCUSSION-
> > LIST] xml documentation
> >
> > I think that encapsulating an event inside another another would work
> > for preserving the validity of any signature.
> >
> > Does CEE then need to define how to encapsulate one event inside of
> > another?
>
> It is not explicitly defined, but within the spec. You need to think of
> the
> original event just as an opaque string. CEE supports encoding opaque
> strings
> within a field. As such, one event a can be encoded inside a field of
> event
> b
> by simple encoding a according the CEE encoding rules for opaque
> strings. Of
> course the result may look a bit puzzling to a human, but I do not
> think
> this
> is too big a problem. The advantage is that from this PoV you can even
> nicely
> have multiple recursive levels of events within events.
>
> Rainer
Reply | Threaded
Open this post in threaded view
|

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

Bill Frank
Makes sense.

Bill Frank
Cymbel
508-878-4943


-----Original Message-----
From: Rainer Gerhards [mailto:[hidden email]]
Sent: Monday, November 29, 2010 8:29 AM
To: Bill Frank; [hidden email]
Subject: RE: [CEE-DISCUSSION-LIST] event integrity RE: [CEE-DISCUSSION-LIST]
xml documentation

> -----Original Message-----
> From: Bill Frank [mailto:[hidden email]]
> Sent: Monday, November 29, 2010 1:35 PM
> To: Rainer Gerhards; [hidden email]
> Subject: RE: [CEE-DISCUSSION-LIST] event integrity RE: [CEE-DISCUSSION-
> LIST] xml documentation
>
> 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?

That's a good point. I tend to think that we should at least mention the
potential problem and tell the simple solution that the original event must
be preserved if any transformations need to be done AND the signature must
remain valid.

But my personal view is that I don't think that it would be wise to go
further than that for the initial release of CEE. That will complicate
things
and I think it will lead to CEE becoming available (much?) later. That in
turn would mean that we postpone all features "just" because we could not
get
some features in. IMHO it is better to release a set of core features and
then extend on that. So at least part of the benefits will become available
as early as possible.

Rainer  

>
> Bill Frank
> Cymbel
> 508-878-4943
>
> -----Original Message-----
> From: Rainer Gerhards [mailto:[hidden email]]
> Sent: Monday, November 29, 2010 5:14 AM
> To: [hidden email]
> Subject: Re: [CEE-DISCUSSION-LIST] event integrity RE: [CEE-DISCUSSION-
> LIST]
> xml documentation
>
> > -----Original Message-----
> > From: Lawrence Smith [mailto:[hidden email]]
> > Sent: Sunday, November 28, 2010 9:50 PM
> > To: [hidden email]
> > Subject: Re: [CEE-DISCUSSION-LIST] event integrity RE: [CEE-
> DISCUSSION-
> > LIST] xml documentation
> >
> > I think that encapsulating an event inside another another would work
> > for preserving the validity of any signature.
> >
> > Does CEE then need to define how to encapsulate one event inside of
> > another?
>
> It is not explicitly defined, but within the spec. You need to think of
> the
> original event just as an opaque string. CEE supports encoding opaque
> strings
> within a field. As such, one event a can be encoded inside a field of
> event
> b
> by simple encoding a according the CEE encoding rules for opaque
> strings. Of
> course the result may look a bit puzzling to a human, but I do not
> think
> this
> is too big a problem. The advantage is that from this PoV you can even
> nicely
> have multiple recursive levels of events within events.
>
> Rainer
Reply | Threaded
Open this post in threaded view
|

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

heinbockel
In reply to this post by Adam Montville
Well, yes and no
Key management is an aspect that transcends audit management.
Encrypted/authenticated event or audit streams are a feature that needs support
built into the audit systems.


William Heinbockel
The MITRE Corporation


>-----Original Message-----
>From: Adam Montville [mailto:[hidden email]]
>Sent: Tuesday, 23 November 2010 14:26
>To: Heinbockel, Bill; cee-discussion-list CEE-Related Discussion
>Subject: RE: event integrity RE: [CEE-DISCUSSION-LIST] xml documentation
>
>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

heinbockel
In reply to this post by Lawrence Smith
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

heinbockel
In reply to this post by Bill Frank
>
>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)

smime.p7s (4K) Download Attachment
12