Quantcast

Help with taxonomy

classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Help with taxonomy

Evan Rempel
I am entering into a large project to classify ALL of the log messages that our central log server collects. I want to do it correctly from the start since doing things twice is always more time consuming.

The taxonomy.xsd file

http://cee.mitre.org/repository/schemas/v10alpha/taxonomy.xsd

seems to lack the description data for many of the tag values. Is there a human friendly documentation page that describes when each of the tag values should be used?

Information that would differentiate between the open/close actions and the connect/disconnect actions. Wouldn't and open/close action on an object of connection be the same as a connect/disconnect?

Another place where I am having difficulty is classifying a message where a network connection gets dropped (reset by peer). This is not really the same as a close since the end logging the message didn't perform the action of the close. Would the dropped connection be;

action: detect
object: connection
status: failure

Without some clarification on each of the tag values I think that I will be classifying many message in a way that is incompatible with other people's interpretation of the CEE.

Thanks for any pointers you can provide.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Help with taxonomy

Anton Chuvakin
> seems to lack the description data for many of the tag values. Is there a human friendly documentation page that describes when each of the tag values should be used?

This part is still a "work in progress" actually. Some of the precise
tax category meaning are still open to interpretation.

> Another place where I am having difficulty is classifying a message where a network connection gets dropped (reset by peer). This is not really the same as a close since the end logging the message didn't perform the action of the close.

In the past, we used this in our CEE discussions and research:

firewall drops the conn by policy

action: drop (or similar)
object: connection
status: success

conn gets dropped by error, etc

action: detect (or similar - don't have the XSD in from of me now)
object: connection
status: failure

And, yes, if you have addl ideas on how to do it better, it is
absolutely OK to express them at this stage in CEE dev :-)

--
Dr. Anton Chuvakin
Site: http://www.chuvakin.org
Twitter: @anton_chuvakin
Work: http://www.linkedin.com/in/chuvakin
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Help with taxonomy

Evan Rempel
In reply to this post by Evan Rempel
This makes sense. I don't see the equivalent of drop in the action so I am not quit site how to proceed since I understand that the action attribute is not user extensible.

Also, is there a repository of known log lines and their classifications?

If not I think that my group and our current project may be in a position to start to populate such a thing.

Anton Chuvakin <[hidden email]> wrote:


> seems to lack the description data for many of the tag values. Is there a human friendly documentation page that describes when each of the tag values should be used?

This part is still a "work in progress" actually. Some of the precise
tax category meaning are still open to interpretation.

> Another place where I am having difficulty is classifying a message where a network connection gets dropped (reset by peer). This is not really the same as a close since the end logging the message didn't perform the action of the close.

In the past, we used this in our CEE discussions and research:

firewall drops the conn by policy

action: drop (or similar)
object: connection
status: success

conn gets dropped by error, etc

action: detect (or similar - don't have the XSD in from of me now)
object: connection
status: failure

And, yes, if you have addl ideas on how to do it better, it is
absolutely OK to express them at this stage in CEE dev :-)

--
Dr. Anton Chuvakin
Site: http://www.chuvakin.org
Twitter: @anton_chuvakin
Work: http://www.linkedin.com/in/chuvakin
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Help with taxonomy

zrlram
In reply to this post by Evan Rempel
Evan,

I am not sure there is another place where we captured more information about the individual tags. I am happy to try and elaborate on the ones that you have trouble with.

The specific issue you are addressing is an interesting one and you'll keep finding that at other places. The idea of the taxonomy is to put events into buckets. The question is then how many buckets to you want to have or more general, how precise do you want the buckets to express the event. The more precise you get, the more you have to write rules or searches that are super precise (counter to the design goal). If you are too coarse, you will have the problem that you cannot express much.

So, a dopped, a closed, and a reset could be classified the same.

Don't use an action of detect. What does detect mean? That's more of a human thing. I am giving a recommendation here that is not necessarily CEE blessed yet, we are still discussing that: A firewall drop:

object: connection | action: start | status: failure

I am noting this as an action item for the board to put out some examples. Ideally one per tag.

-raffy

--
Raffael Marty
@raffaelmarty                                          http://raffy.ch

On Jun 25, 2012, at 7:36 AM, Evan Rempel wrote:

> I am entering into a large project to classify ALL of the log messages that our central log server collects. I want to do it correctly from the start since doing things twice is always more time consuming.
>
> The taxonomy.xsd file
>
> http://cee.mitre.org/repository/schemas/v10alpha/taxonomy.xsd
>
> seems to lack the description data for many of the tag values. Is there a human friendly documentation page that describes when each of the tag values should be used?
>
> Information that would differentiate between the open/close actions and the connect/disconnect actions. Wouldn't and open/close action on an object of connection be the same as a connect/disconnect?
>
> Another place where I am having difficulty is classifying a message where a network connection gets dropped (reset by peer). This is not really the same as a close since the end logging the message didn't perform the action of the close. Would the dropped connection be;
>
> action: detect
> object: connection
> status: failure
>
> Without some clarification on each of the tag values I think that I will be classifying many message in a way that is incompatible with other people's interpretation of the CEE.
>
> Thanks for any pointers you can provide.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Help with taxonomy

Evan Rempel
In reply to this post by Evan Rempel
i guess that i am looking for something a little more relational. For example, a normal flow of activigy such as;

connect: a pre-authenticaed connection - communicaton channel
authenticate (login):
authorize:
open: a post authenticate/authorized connection or an unauthenticated connection is established.

write:
read:

close: close the authenticated/authorized connection (logout
disconnect: close the communication channel.

Some objects do not have individual authenticat/authorize/open steps since they already have an authecticate context, so just an open gets performed, such as opening a file. In these cases the actions are merly open, read/write, close.

If  a forced close or disconnect occurs it is classified as a drop.
If one end of the connection requests an immediate disconnect without going through the negotiated close and disconnect it will be classified as an abort request.

This should comver all network connections either local (sockets) or remote, either authenticated or unauthenticated (authentication context).


-----
This describes the deifference between open/close pair and the connect/disconnect. It covers how each side of the communcation view the actions, such as an open request - status failed would be seen on the server side as open request - status denied (failed would indicate an error).

If the CEE is open to a complete rewrite (probably would not differ too much) then I could be talked into doing a complete writeup.

My understanding is that there are a few other projects that are well underway using the CEE and that any major changes would be difficult to entegrate.

Evan.


Raffael Marty <[hidden email]> wrote:


Evan,

I am not sure there is another place where we captured more information about the individual tags. I am happy to try and elaborate on the ones that you have trouble with.

The specific issue you are addressing is an interesting one and you'll keep finding that at other places. The idea of the taxonomy is to put events into buckets. The question is then how many buckets to you want to have or more general, how precise do you want the buckets to express the event. The more precise you get, the more you have to write rules or searches that are super precise (counter to the design goal). If you are too coarse, you will have the problem that you cannot express much.

So, a dopped, a closed, and a reset could be classified the same.

Don't use an action of detect. What does detect mean? That's more of a human thing. I am giving a recommendation here that is not necessarily CEE blessed yet, we are still discussing that: A firewall drop:

object: connection | action: start | status: failure

I am noting this as an action item for the board to put out some examples. Ideally one per tag.

 -raffy

--
 Raffael Marty
 @raffaelmarty                                          http://raffy.ch

On Jun 25, 2012, at 7:36 AM, Evan Rempel wrote:

> I am entering into a large project to classify ALL of the log messages that our central log server collects. I want to do it correctly from the start since doing things twice is always more time consuming.
>
> The taxonomy.xsd file
>
> http://cee.mitre.org/repository/schemas/v10alpha/taxonomy.xsd
>
> seems to lack the description data for many of the tag values. Is there a human friendly documentation page that describes when each of the tag values should be used?
>
> Information that would differentiate between the open/close actions and the connect/disconnect actions. Wouldn't and open/close action on an object of connection be the same as a connect/disconnect?
>
> Another place where I am having difficulty is classifying a message where a network connection gets dropped (reset by peer). This is not really the same as a close since the end logging the message didn't perform the action of the close. Would the dropped connection be;
>
> action: detect
> object: connection
> status: failure
>
> Without some clarification on each of the tag values I think that I will be classifying many message in a way that is incompatible with other people's interpretation of the CEE.
>
> Thanks for any pointers you can provide.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Help with taxonomy

zrlram
> connect: a pre-authenticaed connection - communicaton channel
> authenticate (login):
> authorize:
> open: a post authenticate/authorized connection or an unauthenticated
> connection is established.
>
> write:
> read:
>
> close: close the authenticated/authorized connection (logout
> disconnect: close the communication channel.

I like this model a lot! Thanks for putting this here.

> If  a forced close or disconnect occurs it is classified as a drop.

Okay, I can buy into that.

> -----
> This describes the deifference between open/close pair and the
> connect/disconnect. It covers how each side of the communcation view the
> actions, such as an open request - status failed would be seen on the
> server side as open request - status denied (failed would indicate an
> error).

I think denied can just be a failed on the authentication. Right? I like
to keep the number of entries minimal.

I'll see that we can integrate this into the CEE guidelines.

Thanks again!

  -raffy

>
>
> Raffael Marty <[hidden email]> wrote:
>
>
> Evan,
>
> I am not sure there is another place where we captured more information
> about the individual tags. I am happy to try and elaborate on the ones
> that you have trouble with.
>
> The specific issue you are addressing is an interesting one and you'll
> keep finding that at other places. The idea of the taxonomy is to put
> events into buckets. The question is then how many buckets to you want to
> have or more general, how precise do you want the buckets to express the
> event. The more precise you get, the more you have to write rules or
> searches that are super precise (counter to the design goal). If you are
> too coarse, you will have the problem that you cannot express much.
>
> So, a dopped, a closed, and a reset could be classified the same.
>
> Don't use an action of detect. What does detect mean? That's more of a
> human thing. I am giving a recommendation here that is not necessarily CEE
> blessed yet, we are still discussing that: A firewall drop:
>
> object: connection | action: start | status: failure
>
> I am noting this as an action item for the board to put out some examples.
> Ideally one per tag.
>
>  -raffy
>
> --
>  Raffael Marty
>  @raffaelmarty                                          http://raffy.ch
>
> On Jun 25, 2012, at 7:36 AM, Evan Rempel wrote:
>
>> I am entering into a large project to classify ALL of the log messages
>> that our central log server collects. I want to do it correctly from the
>> start since doing things twice is always more time consuming.
>>
>> The taxonomy.xsd file
>>
>> http://cee.mitre.org/repository/schemas/v10alpha/taxonomy.xsd
>>
>> seems to lack the description data for many of the tag values. Is there
>> a human friendly documentation page that describes when each of the tag
>> values should be used?
>>
>> Information that would differentiate between the open/close actions and
>> the connect/disconnect actions. Wouldn't and open/close action on an
>> object of connection be the same as a connect/disconnect?
>>
>> Another place where I am having difficulty is classifying a message
>> where a network connection gets dropped (reset by peer). This is not
>> really the same as a close since the end logging the message didn't
>> perform the action of the close. Would the dropped connection be;
>>
>> action: detect
>> object: connection
>> status: failure
>>
>> Without some clarification on each of the tag values I think that I will
>> be classifying many message in a way that is incompatible with other
>> people's interpretation of the CEE.
>>
>> Thanks for any pointers you can provide.
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Help with taxonomy

Evan Rempel
In reply to this post by Evan Rempel
What i was trying to get to with a denied rather than a failure is that from a "server" perspecitve, denied is working as designed. The notion of a failure is something that should be brought to the attention of a system administrator. "Show me everyting in my infrastructure that is failing".

So I think that a deny and allow should be valid status codes. Even a server side authentication mismatch is denying access. A denied login is different than a failed loging (say the server could not allocate another process ID - that's a failure).

If  I have a process that secure copies a file to another system, I may have a failed login on the client, and a denied login on the server. The "fault" is at the client, not the server. Now I would know where to look for the problem. If both sides log a failed login the problem would be more difficult to iscolate.

Just my $0.02 worth.

Evan.

Raffael Marty <[hidden email]> wrote:


> connect: a pre-authenticaed connection - communicaton channel
> authenticate (login):
> authorize:
> open: a post authenticate/authorized connection or an unauthenticated
> connection is established.
>
> write:
> read:
>
> close: close the authenticated/authorized connection (logout
> disconnect: close the communication channel.

I like this model a lot! Thanks for putting this here.

> If  a forced close or disconnect occurs it is classified as a drop.

Okay, I can buy into that.

> -----
> This describes the deifference between open/close pair and the
> connect/disconnect. It covers how each side of the communcation view the
> actions, such as an open request - status failed would be seen on the
> server side as open request - status denied (failed would indicate an
> error).

I think denied can just be a failed on the authentication. Right? I like
to keep the number of entries minimal.

I'll see that we can integrate this into the CEE guidelines.

Thanks again!

  -raffy

>
>
> Raffael Marty <[hidden email]> wrote:
>
>
> Evan,
>
> I am not sure there is another place where we captured more information
> about the individual tags. I am happy to try and elaborate on the ones
> that you have trouble with.
>
> The specific issue you are addressing is an interesting one and you'll
> keep finding that at other places. The idea of the taxonomy is to put
> events into buckets. The question is then how many buckets to you want to
> have or more general, how precise do you want the buckets to express the
> event. The more precise you get, the more you have to write rules or
> searches that are super precise (counter to the design goal). If you are
> too coarse, you will have the problem that you cannot express much.
>
> So, a dopped, a closed, and a reset could be classified the same.
>
> Don't use an action of detect. What does detect mean? That's more of a
> human thing. I am giving a recommendation here that is not necessarily CEE
> blessed yet, we are still discussing that: A firewall drop:
>
> object: connection | action: start | status: failure
>
> I am noting this as an action item for the board to put out some examples.
> Ideally one per tag.
>
>  -raffy
>
> --
>  Raffael Marty
>  @raffaelmarty                                          http://raffy.ch
>
> On Jun 25, 2012, at 7:36 AM, Evan Rempel wrote:
>
>> I am entering into a large project to classify ALL of the log messages
>> that our central log server collects. I want to do it correctly from the
>> start since doing things twice is always more time consuming.
>>
>> The taxonomy.xsd file
>>
>> http://cee.mitre.org/repository/schemas/v10alpha/taxonomy.xsd
>>
>> seems to lack the description data for many of the tag values. Is there
>> a human friendly documentation page that describes when each of the tag
>> values should be used?
>>
>> Information that would differentiate between the open/close actions and
>> the connect/disconnect actions. Wouldn't and open/close action on an
>> object of connection be the same as a connect/disconnect?
>>
>> Another place where I am having difficulty is classifying a message
>> where a network connection gets dropped (reset by peer). This is not
>> really the same as a close since the end logging the message didn't
>> perform the action of the close. Would the dropped connection be;
>>
>> action: detect
>> object: connection
>> status: failure
>>
>> Without some clarification on each of the tag values I think that I will
>> be classifying many message in a way that is incompatible with other
>> people's interpretation of the CEE.
>>
>> Thanks for any pointers you can provide.
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Help with taxonomy

william.leroy
In reply to this post by zrlram
Raffael Marty,

How many device and or software companies are now considering or have
processes in place to implement CEE? or do you think CEE is still
needs a significant amount of work? Any interest from ArcSight, or
EnVision in implementing.


On Wed, Jun 27, 2012 at 10:57 AM, Raffael Marty <[hidden email]> wrote:

>> connect: a pre-authenticaed connection - communicaton channel
>> authenticate (login):
>> authorize:
>> open: a post authenticate/authorized connection or an unauthenticated
>> connection is established.
>>
>> write:
>> read:
>>
>> close: close the authenticated/authorized connection (logout
>> disconnect: close the communication channel.
>
> I like this model a lot! Thanks for putting this here.
>
>> If  a forced close or disconnect occurs it is classified as a drop.
>
> Okay, I can buy into that.
>
>> -----
>> This describes the deifference between open/close pair and the
>> connect/disconnect. It covers how each side of the communcation view the
>> actions, such as an open request - status failed would be seen on the
>> server side as open request - status denied (failed would indicate an
>> error).
>
> I think denied can just be a failed on the authentication. Right? I like
> to keep the number of entries minimal.
>
> I'll see that we can integrate this into the CEE guidelines.
>
> Thanks again!
>
>  -raffy
>
>>
>>
>> Raffael Marty <[hidden email]> wrote:
>>
>>
>> Evan,
>>
>> I am not sure there is another place where we captured more information
>> about the individual tags. I am happy to try and elaborate on the ones
>> that you have trouble with.
>>
>> The specific issue you are addressing is an interesting one and you'll
>> keep finding that at other places. The idea of the taxonomy is to put
>> events into buckets. The question is then how many buckets to you want to
>> have or more general, how precise do you want the buckets to express the
>> event. The more precise you get, the more you have to write rules or
>> searches that are super precise (counter to the design goal). If you are
>> too coarse, you will have the problem that you cannot express much.
>>
>> So, a dopped, a closed, and a reset could be classified the same.
>>
>> Don't use an action of detect. What does detect mean? That's more of a
>> human thing. I am giving a recommendation here that is not necessarily CEE
>> blessed yet, we are still discussing that: A firewall drop:
>>
>> object: connection | action: start | status: failure
>>
>> I am noting this as an action item for the board to put out some examples.
>> Ideally one per tag.
>>
>>  -raffy
>>
>> --
>>  Raffael Marty
>>  @raffaelmarty                                          http://raffy.ch
>>
>> On Jun 25, 2012, at 7:36 AM, Evan Rempel wrote:
>>
>>> I am entering into a large project to classify ALL of the log messages
>>> that our central log server collects. I want to do it correctly from the
>>> start since doing things twice is always more time consuming.
>>>
>>> The taxonomy.xsd file
>>>
>>> http://cee.mitre.org/repository/schemas/v10alpha/taxonomy.xsd
>>>
>>> seems to lack the description data for many of the tag values. Is there
>>> a human friendly documentation page that describes when each of the tag
>>> values should be used?
>>>
>>> Information that would differentiate between the open/close actions and
>>> the connect/disconnect actions. Wouldn't and open/close action on an
>>> object of connection be the same as a connect/disconnect?
>>>
>>> Another place where I am having difficulty is classifying a message
>>> where a network connection gets dropped (reset by peer). This is not
>>> really the same as a close since the end logging the message didn't
>>> perform the action of the close. Would the dropped connection be;
>>>
>>> action: detect
>>> object: connection
>>> status: failure
>>>
>>> Without some clarification on each of the tag values I think that I will
>>> be classifying many message in a way that is incompatible with other
>>> people's interpretation of the CEE.
>>>
>>> Thanks for any pointers you can provide.
>>



--
Bill LeRoy


[hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Help with taxonomy

Evan Rempel
In reply to this post by Evan Rempel
syslog-ng has a message profiling engine that is used to apply metadata to log lines. Thee community around syslog-ng is building a database of log line matching and profiling rules and they have stated that they will use CEE standards.

This is where I come in.
With approval of my supervisor we will be publishing all of the rules that we write for ALL applications that we run in our infrastructure.

Off the top of my head we are going to profile;

All linux kernel (cron, iptables, tcpwrappers, ssh, rsync etc)
nfsd
postgresql
mysql
sendmail
Tivoli Storage Manager
GPFS clustered filesystem
Apache
Tomcat
Moodle
Oracle middle ware
Cisco - PIX, ACL IPS
DCache
Squid
php


MS Windows even logs
IIS
Exchange



[hidden email] wrote:


Raffael Marty,

How many device and or software companies are now considering or have
processes in place to implement CEE? or do you think CEE is still
needs a significant amount of work? Any interest from ArcSight, or
EnVision in implementing.


On Wed, Jun 27, 2012 at 10:57 AM, Raffael Marty <[hidden email]> wrote:

>> connect: a pre-authenticaed connection - communicaton channel
>> authenticate (login):
>> authorize:
>> open: a post authenticate/authorized connection or an unauthenticated
>> connection is established.
>>
>> write:
>> read:
>>
>> close: close the authenticated/authorized connection (logout
>> disconnect: close the communication channel.
>
> I like this model a lot! Thanks for putting this here.
>
>> If  a forced close or disconnect occurs it is classified as a drop.
>
> Okay, I can buy into that.
>
>> -----
>> This describes the deifference between open/close pair and the
>> connect/disconnect. It covers how each side of the communcation view the
>> actions, such as an open request - status failed would be seen on the
>> server side as open request - status denied (failed would indicate an
>> error).
>
> I think denied can just be a failed on the authentication. Right? I like
> to keep the number of entries minimal.
>
> I'll see that we can integrate this into the CEE guidelines.
>
> Thanks again!
>
>  -raffy
>
>>
>>
>> Raffael Marty <[hidden email]> wrote:
>>
>>
>> Evan,
>>
>> I am not sure there is another place where we captured more information
>> about the individual tags. I am happy to try and elaborate on the ones
>> that you have trouble with.
>>
>> The specific issue you are addressing is an interesting one and you'll
>> keep finding that at other places. The idea of the taxonomy is to put
>> events into buckets. The question is then how many buckets to you want to
>> have or more general, how precise do you want the buckets to express the
>> event. The more precise you get, the more you have to write rules or
>> searches that are super precise (counter to the design goal). If you are
>> too coarse, you will have the problem that you cannot express much.
>>
>> So, a dopped, a closed, and a reset could be classified the same.
>>
>> Don't use an action of detect. What does detect mean? That's more of a
>> human thing. I am giving a recommendation here that is not necessarily CEE
>> blessed yet, we are still discussing that: A firewall drop:
>>
>> object: connection | action: start | status: failure
>>
>> I am noting this as an action item for the board to put out some examples.
>> Ideally one per tag.
>>
>>  -raffy
>>
>> --
>>  Raffael Marty
>>  @raffaelmarty                                          http://raffy.ch
>>
>> On Jun 25, 2012, at 7:36 AM, Evan Rempel wrote:
>>
>>> I am entering into a large project to classify ALL of the log messages
>>> that our central log server collects. I want to do it correctly from the
>>> start since doing things twice is always more time consuming.
>>>
>>> The taxonomy.xsd file
>>>
>>> http://cee.mitre.org/repository/schemas/v10alpha/taxonomy.xsd
>>>
>>> seems to lack the description data for many of the tag values. Is there
>>> a human friendly documentation page that describes when each of the tag
>>> values should be used?
>>>
>>> Information that would differentiate between the open/close actions and
>>> the connect/disconnect actions. Wouldn't and open/close action on an
>>> object of connection be the same as a connect/disconnect?
>>>
>>> Another place where I am having difficulty is classifying a message
>>> where a network connection gets dropped (reset by peer). This is not
>>> really the same as a close since the end logging the message didn't
>>> perform the action of the close. Would the dropped connection be;
>>>
>>> action: detect
>>> object: connection
>>> status: failure
>>>
>>> Without some clarification on each of the tag values I think that I will
>>> be classifying many message in a way that is incompatible with other
>>> people's interpretation of the CEE.
>>>
>>> Thanks for any pointers you can provide.
>>



--
Bill LeRoy


[hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Help with taxonomy

Anton Chuvakin
This would be hugely useful!!! Thanks a lot for doing this!

On Wed, Jun 27, 2012 at 10:36 AM, Evan Rempel <[hidden email]> wrote:

> syslog-ng has a message profiling engine that is used to apply metadata to log lines. Thee community around syslog-ng is building a database of log line matching and profiling rules and they have stated that they will use CEE standards.
>
> This is where I come in.
> With approval of my supervisor we will be publishing all of the rules that we write for ALL applications that we run in our infrastructure.
>
> Off the top of my head we are going to profile;
>
> All linux kernel (cron, iptables, tcpwrappers, ssh, rsync etc)
> nfsd
> postgresql
> mysql
> sendmail
> Tivoli Storage Manager
> GPFS clustered filesystem
> Apache
> Tomcat
> Moodle
> Oracle middle ware
> Cisco - PIX, ACL IPS
> DCache
> Squid
> php
>
>
> MS Windows even logs
> IIS
> Exchange
>
>
>
> [hidden email] wrote:
>
>
> Raffael Marty,
>
> How many device and or software companies are now considering or have
> processes in place to implement CEE? or do you think CEE is still
> needs a significant amount of work? Any interest from ArcSight, or
> EnVision in implementing.
>
>
> On Wed, Jun 27, 2012 at 10:57 AM, Raffael Marty <[hidden email]> wrote:
>>> connect: a pre-authenticaed connection - communicaton channel
>>> authenticate (login):
>>> authorize:
>>> open: a post authenticate/authorized connection or an unauthenticated
>>> connection is established.
>>>
>>> write:
>>> read:
>>>
>>> close: close the authenticated/authorized connection (logout
>>> disconnect: close the communication channel.
>>
>> I like this model a lot! Thanks for putting this here.
>>
>>> If  a forced close or disconnect occurs it is classified as a drop.
>>
>> Okay, I can buy into that.
>>
>>> -----
>>> This describes the deifference between open/close pair and the
>>> connect/disconnect. It covers how each side of the communcation view the
>>> actions, such as an open request - status failed would be seen on the
>>> server side as open request - status denied (failed would indicate an
>>> error).
>>
>> I think denied can just be a failed on the authentication. Right? I like
>> to keep the number of entries minimal.
>>
>> I'll see that we can integrate this into the CEE guidelines.
>>
>> Thanks again!
>>
>>  -raffy
>>
>>>
>>>
>>> Raffael Marty <[hidden email]> wrote:
>>>
>>>
>>> Evan,
>>>
>>> I am not sure there is another place where we captured more information
>>> about the individual tags. I am happy to try and elaborate on the ones
>>> that you have trouble with.
>>>
>>> The specific issue you are addressing is an interesting one and you'll
>>> keep finding that at other places. The idea of the taxonomy is to put
>>> events into buckets. The question is then how many buckets to you want to
>>> have or more general, how precise do you want the buckets to express the
>>> event. The more precise you get, the more you have to write rules or
>>> searches that are super precise (counter to the design goal). If you are
>>> too coarse, you will have the problem that you cannot express much.
>>>
>>> So, a dopped, a closed, and a reset could be classified the same.
>>>
>>> Don't use an action of detect. What does detect mean? That's more of a
>>> human thing. I am giving a recommendation here that is not necessarily CEE
>>> blessed yet, we are still discussing that: A firewall drop:
>>>
>>> object: connection | action: start | status: failure
>>>
>>> I am noting this as an action item for the board to put out some examples.
>>> Ideally one per tag.
>>>
>>>  -raffy
>>>
>>> --
>>>  Raffael Marty
>>>  @raffaelmarty                                          http://raffy.ch
>>>
>>> On Jun 25, 2012, at 7:36 AM, Evan Rempel wrote:
>>>
>>>> I am entering into a large project to classify ALL of the log messages
>>>> that our central log server collects. I want to do it correctly from the
>>>> start since doing things twice is always more time consuming.
>>>>
>>>> The taxonomy.xsd file
>>>>
>>>> http://cee.mitre.org/repository/schemas/v10alpha/taxonomy.xsd
>>>>
>>>> seems to lack the description data for many of the tag values. Is there
>>>> a human friendly documentation page that describes when each of the tag
>>>> values should be used?
>>>>
>>>> Information that would differentiate between the open/close actions and
>>>> the connect/disconnect actions. Wouldn't and open/close action on an
>>>> object of connection be the same as a connect/disconnect?
>>>>
>>>> Another place where I am having difficulty is classifying a message
>>>> where a network connection gets dropped (reset by peer). This is not
>>>> really the same as a close since the end logging the message didn't
>>>> perform the action of the close. Would the dropped connection be;
>>>>
>>>> action: detect
>>>> object: connection
>>>> status: failure
>>>>
>>>> Without some clarification on each of the tag values I think that I will
>>>> be classifying many message in a way that is incompatible with other
>>>> people's interpretation of the CEE.
>>>>
>>>> Thanks for any pointers you can provide.
>>>
>
>
>
> --
> Bill LeRoy
>
>
> [hidden email]



--
Dr. Anton Chuvakin
Site: http://www.chuvakin.org
Twitter: @anton_chuvakin
Work: http://www.linkedin.com/in/chuvakin
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Help with taxonomy

Dominique Karg
Huge +1 from my part also :-)

On 27 June 2012 12:36, Anton Chuvakin <[hidden email]> wrote:
This would be hugely useful!!! Thanks a lot for doing this!

On Wed, Jun 27, 2012 at 10:36 AM, Evan Rempel <[hidden email]> wrote:
> syslog-ng has a message profiling engine that is used to apply metadata to log lines. Thee community around syslog-ng is building a database of log line matching and profiling rules and they have stated that they will use CEE standards.
>
> This is where I come in.
> With approval of my supervisor we will be publishing all of the rules that we write for ALL applications that we run in our infrastructure.
>
> Off the top of my head we are going to profile;
>
> All linux kernel (cron, iptables, tcpwrappers, ssh, rsync etc)
> nfsd
> postgresql
> mysql
> sendmail
> Tivoli Storage Manager
> GPFS clustered filesystem
> Apache
> Tomcat
> Moodle
> Oracle middle ware
> Cisco - PIX, ACL IPS
> DCache
> Squid
> php
>
>
> MS Windows even logs
> IIS
> Exchange
>
>
>
> [hidden email] wrote:
>
>
> Raffael Marty,
>
> How many device and or software companies are now considering or have
> processes in place to implement CEE? or do you think CEE is still
> needs a significant amount of work? Any interest from ArcSight, or
> EnVision in implementing.
>
>
> On Wed, Jun 27, 2012 at 10:57 AM, Raffael Marty <[hidden email]> wrote:
>>> connect: a pre-authenticaed connection - communicaton channel
>>> authenticate (login):
>>> authorize:
>>> open: a post authenticate/authorized connection or an unauthenticated
>>> connection is established.
>>>
>>> write:
>>> read:
>>>
>>> close: close the authenticated/authorized connection (logout
>>> disconnect: close the communication channel.
>>
>> I like this model a lot! Thanks for putting this here.
>>
>>> If  a forced close or disconnect occurs it is classified as a drop.
>>
>> Okay, I can buy into that.
>>
>>> -----
>>> This describes the deifference between open/close pair and the
>>> connect/disconnect. It covers how each side of the communcation view the
>>> actions, such as an open request - status failed would be seen on the
>>> server side as open request - status denied (failed would indicate an
>>> error).
>>
>> I think denied can just be a failed on the authentication. Right? I like
>> to keep the number of entries minimal.
>>
>> I'll see that we can integrate this into the CEE guidelines.
>>
>> Thanks again!
>>
>>  -raffy
>>
>>>
>>>
>>> Raffael Marty <[hidden email]> wrote:
>>>
>>>
>>> Evan,
>>>
>>> I am not sure there is another place where we captured more information
>>> about the individual tags. I am happy to try and elaborate on the ones
>>> that you have trouble with.
>>>
>>> The specific issue you are addressing is an interesting one and you'll
>>> keep finding that at other places. The idea of the taxonomy is to put
>>> events into buckets. The question is then how many buckets to you want to
>>> have or more general, how precise do you want the buckets to express the
>>> event. The more precise you get, the more you have to write rules or
>>> searches that are super precise (counter to the design goal). If you are
>>> too coarse, you will have the problem that you cannot express much.
>>>
>>> So, a dopped, a closed, and a reset could be classified the same.
>>>
>>> Don't use an action of detect. What does detect mean? That's more of a
>>> human thing. I am giving a recommendation here that is not necessarily CEE
>>> blessed yet, we are still discussing that: A firewall drop:
>>>
>>> object: connection | action: start | status: failure
>>>
>>> I am noting this as an action item for the board to put out some examples.
>>> Ideally one per tag.
>>>
>>>  -raffy
>>>
>>> --
>>>  Raffael Marty
>>>  @raffaelmarty                                          http://raffy.ch
>>>
>>> On Jun 25, 2012, at 7:36 AM, Evan Rempel wrote:
>>>
>>>> I am entering into a large project to classify ALL of the log messages
>>>> that our central log server collects. I want to do it correctly from the
>>>> start since doing things twice is always more time consuming.
>>>>
>>>> The taxonomy.xsd file
>>>>
>>>> http://cee.mitre.org/repository/schemas/v10alpha/taxonomy.xsd
>>>>
>>>> seems to lack the description data for many of the tag values. Is there
>>>> a human friendly documentation page that describes when each of the tag
>>>> values should be used?
>>>>
>>>> Information that would differentiate between the open/close actions and
>>>> the connect/disconnect actions. Wouldn't and open/close action on an
>>>> object of connection be the same as a connect/disconnect?
>>>>
>>>> Another place where I am having difficulty is classifying a message
>>>> where a network connection gets dropped (reset by peer). This is not
>>>> really the same as a close since the end logging the message didn't
>>>> perform the action of the close. Would the dropped connection be;
>>>>
>>>> action: detect
>>>> object: connection
>>>> status: failure
>>>>
>>>> Without some clarification on each of the tag values I think that I will
>>>> be classifying many message in a way that is incompatible with other
>>>> people's interpretation of the CEE.
>>>>
>>>> Thanks for any pointers you can provide.
>>>
>
>
>
> --
> Bill LeRoy
>
>
> [hidden email]



--
Dr. Anton Chuvakin
Site: http://www.chuvakin.org
Twitter: @anton_chuvakin
Work: http://www.linkedin.com/in/chuvakin



--
Dominique Karg
Founder/CHO at Alienvault
http://www.alienvault.com | [hidden email]
Skype & GTalk: dominique.karg | Twitter: @dkarg

- In Space no one can hear you scream... 
Hmm, no, sorry, wrong quote;
- Open Source. Open Tools. Open Minds.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Help with taxonomy

rjones21

When will this data be made available ?

 

From: Dominique Karg [mailto:[hidden email]]
Sent: Wednesday, June 27, 2012 3:43 PM
To: [hidden email]
Subject: Re: [CEE-DISCUSSION-LIST] Help with taxonomy

 

Huge +1 from my part also :-)

On 27 June 2012 12:36, Anton Chuvakin <[hidden email]> wrote:

This would be hugely useful!!! Thanks a lot for doing this!


On Wed, Jun 27, 2012 at 10:36 AM, Evan Rempel <[hidden email]> wrote:
> syslog-ng has a message profiling engine that is used to apply metadata to log lines. Thee community around syslog-ng is building a database of log line matching and profiling rules and they have stated that they will use CEE standards.
>
> This is where I come in.
> With approval of my supervisor we will be publishing all of the rules that we write for ALL applications that we run in our infrastructure.
>
> Off the top of my head we are going to profile;
>
> All linux kernel (cron, iptables, tcpwrappers, ssh, rsync etc)
> nfsd
> postgresql
> mysql
> sendmail
> Tivoli Storage Manager
> GPFS clustered filesystem
> Apache
> Tomcat
> Moodle
> Oracle middle ware
> Cisco - PIX, ACL IPS
> DCache
> Squid
> php
>
>
> MS Windows even logs
> IIS
> Exchange
>
>
>
> [hidden email] wrote:
>
>
> Raffael Marty,
>
> How many device and or software companies are now considering or have
> processes in place to implement CEE? or do you think CEE is still
> needs a significant amount of work? Any interest from ArcSight, or
> EnVision in implementing.
>
>
> On Wed, Jun 27, 2012 at 10:57 AM, Raffael Marty <[hidden email]> wrote:
>>> connect: a pre-authenticaed connection - communicaton channel
>>> authenticate (login):
>>> authorize:
>>> open: a post authenticate/authorized connection or an unauthenticated
>>> connection is established.
>>>
>>> write:
>>> read:
>>>
>>> close: close the authenticated/authorized connection (logout
>>> disconnect: close the communication channel.
>>
>> I like this model a lot! Thanks for putting this here.
>>
>>> If  a forced close or disconnect occurs it is classified as a drop.
>>
>> Okay, I can buy into that.
>>
>>> -----
>>> This describes the deifference between open/close pair and the
>>> connect/disconnect. It covers how each side of the communcation view the
>>> actions, such as an open request - status failed would be seen on the
>>> server side as open request - status denied (failed would indicate an
>>> error).
>>
>> I think denied can just be a failed on the authentication. Right? I like
>> to keep the number of entries minimal.
>>
>> I'll see that we can integrate this into the CEE guidelines.
>>
>> Thanks again!
>>
>>  -raffy
>>
>>>
>>>
>>> Raffael Marty <[hidden email]> wrote:
>>>
>>>
>>> Evan,
>>>
>>> I am not sure there is another place where we captured more information
>>> about the individual tags. I am happy to try and elaborate on the ones
>>> that you have trouble with.
>>>
>>> The specific issue you are addressing is an interesting one and you'll
>>> keep finding that at other places. The idea of the taxonomy is to put
>>> events into buckets. The question is then how many buckets to you want to
>>> have or more general, how precise do you want the buckets to express the
>>> event. The more precise you get, the more you have to write rules or
>>> searches that are super precise (counter to the design goal). If you are
>>> too coarse, you will have the problem that you cannot express much.
>>>
>>> So, a dopped, a closed, and a reset could be classified the same.
>>>
>>> Don't use an action of detect. What does detect mean? That's more of a
>>> human thing. I am giving a recommendation here that is not necessarily CEE
>>> blessed yet, we are still discussing that: A firewall drop:
>>>
>>> object: connection | action: start | status: failure
>>>
>>> I am noting this as an action item for the board to put out some examples.
>>> Ideally one per tag.
>>>
>>>  -raffy
>>>
>>> --
>>>  Raffael Marty
>>>  @raffaelmarty                                          http://raffy.ch
>>>
>>> On Jun 25, 2012, at 7:36 AM, Evan Rempel wrote:
>>>
>>>> I am entering into a large project to classify ALL of the log messages
>>>> that our central log server collects. I want to do it correctly from the
>>>> start since doing things twice is always more time consuming.
>>>>
>>>> The taxonomy.xsd file
>>>>
>>>> http://cee.mitre.org/repository/schemas/v10alpha/taxonomy.xsd
>>>>
>>>> seems to lack the description data for many of the tag values. Is there
>>>> a human friendly documentation page that describes when each of the tag
>>>> values should be used?
>>>>
>>>> Information that would differentiate between the open/close actions and
>>>> the connect/disconnect actions. Wouldn't and open/close action on an
>>>> object of connection be the same as a connect/disconnect?
>>>>
>>>> Another place where I am having difficulty is classifying a message
>>>> where a network connection gets dropped (reset by peer). This is not
>>>> really the same as a close since the end logging the message didn't
>>>> perform the action of the close. Would the dropped connection be;
>>>>
>>>> action: detect
>>>> object: connection
>>>> status: failure
>>>>
>>>> Without some clarification on each of the tag values I think that I will
>>>> be classifying many message in a way that is incompatible with other
>>>> people's interpretation of the CEE.
>>>>
>>>> Thanks for any pointers you can provide.
>>>
>
>
>
> --
> Bill LeRoy
>
>
> [hidden email]


--
Dr. Anton Chuvakin
Site: http://www.chuvakin.org
Twitter: @anton_chuvakin
Work: http://www.linkedin.com/in/chuvakin



 

--
Dominique Karg
Founder/CHO at Alienvault
http://www.alienvault.com | [hidden email]
Skype & GTalk: dominique.karg | Twitter: @dkarg

 

- In Space no one can hear you scream... 

Hmm, no, sorry, wrong quote;

- Open Source. Open Tools. Open Minds.

 


_____________________________________________________________
DTCC DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please notify us immediately and delete the email and any attachments from your system. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Help with taxonomy

Evan Rempel
In reply to this post by Evan Rempel
We have the basice components in place and mesage profiling being done on about 30 different messages that cover a lot of one application.
We did this as a test case and to get a generalunderstanding of the CEE.
Unless I can get a clear understainding of CEE and get a reasonably easy mechanism in place to profile each message my boss will not authorize the time investment for all of the CEE tags and all of the default parsed components.

Even if everything goes smoothly we estimate that we have 10-12 thousand distinct messages (300,000 per day) that need to be profiled.
That will take a few weeks to accomplish given all of our regular duties.
The information will be specific to syslog-ng and its pattern database and parsers.

Not sure if that realy answers your question.

Evan

"Jones, Ronald" <[hidden email]> wrote:

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Help with taxonomy

Evan Rempel
In reply to this post by Evan Rempel
The question was how many devices or products are using or plan to use CEE?

I neglected to mention the logging project lumberjack Redhat. A quick Google search should show it. This project is defining a new logging standard that confirms to three standard an all no doubt go into fedora and then their server product.

Evan

Evan Rempel <[hidden email]> wrote:


syslog-ng has a message profiling engine that is used to apply metadata to log lines. Thee community around syslog-ng is building a database of log line matching and profiling rules and they have stated that they will use CEE standards.

This is where I come in.
With approval of my supervisor we will be publishing all of the rules that we write for ALL applications that we run in our infrastructure.

Off the top of my head we are going to profile;

All linux kernel (cron, iptables, tcpwrappers, ssh, rsync etc)
nfsd
postgresql
mysql
sendmail
Tivoli Storage Manager
GPFS clustered filesystem
Apache
Tomcat
Moodle
Oracle middle ware
Cisco - PIX, ACL IPS
DCache
Squid
php


MS Windows even logs
IIS
Exchange



[hidden email] wrote:


Raffael Marty,

How many device and or software companies are now considering or have
processes in place to implement CEE? or do you think CEE is still
needs a significant amount of work? Any interest from ArcSight, or
EnVision in implementing.


On Wed, Jun 27, 2012 at 10:57 AM, Raffael Marty <[hidden email]> wrote:

>> connect: a pre-authenticaed connection - communicaton channel
>> authenticate (login):
>> authorize:
>> open: a post authenticate/authorized connection or an unauthenticated
>> connection is established.
>>
>> write:
>> read:
>>
>> close: close the authenticated/authorized connection (logout
>> disconnect: close the communication channel.
>
> I like this model a lot! Thanks for putting this here.
>
>> If  a forced close or disconnect occurs it is classified as a drop.
>
> Okay, I can buy into that.
>
>> -----
>> This describes the deifference between open/close pair and the
>> connect/disconnect. It covers how each side of the communcation view the
>> actions, such as an open request - status failed would be seen on the
>> server side as open request - status denied (failed would indicate an
>> error).
>
> I think denied can just be a failed on the authentication. Right? I like
> to keep the number of entries minimal.
>
> I'll see that we can integrate this into the CEE guidelines.
>
> Thanks again!
>
>  -raffy
>
>>
>>
>> Raffael Marty <[hidden email]> wrote:
>>
>>
>> Evan,
>>
>> I am not sure there is another place where we captured more information
>> about the individual tags. I am happy to try and elaborate on the ones
>> that you have trouble with.
>>
>> The specific issue you are addressing is an interesting one and you'll
>> keep finding that at other places. The idea of the taxonomy is to put
>> events into buckets. The question is then how many buckets to you want to
>> have or more general, how precise do you want the buckets to express the
>> event. The more precise you get, the more you have to write rules or
>> searches that are super precise (counter to the design goal). If you are
>> too coarse, you will have the problem that you cannot express much.
>>
>> So, a dopped, a closed, and a reset could be classified the same.
>>
>> Don't use an action of detect. What does detect mean? That's more of a
>> human thing. I am giving a recommendation here that is not necessarily CEE
>> blessed yet, we are still discussing that: A firewall drop:
>>
>> object: connection | action: start | status: failure
>>
>> I am noting this as an action item for the board to put out some examples.
>> Ideally one per tag.
>>
>>  -raffy
>>
>> --
>>  Raffael Marty
>>  @raffaelmarty                                          http://raffy.ch
>>
>> On Jun 25, 2012, at 7:36 AM, Evan Rempel wrote:
>>
>>> I am entering into a large project to classify ALL of the log messages
>>> that our central log server collects. I want to do it correctly from the
>>> start since doing things twice is always more time consuming.
>>>
>>> The taxonomy.xsd file
>>>
>>> http://cee.mitre.org/repository/schemas/v10alpha/taxonomy.xsd
>>>
>>> seems to lack the description data for many of the tag values. Is there
>>> a human friendly documentation page that describes when each of the tag
>>> values should be used?
>>>
>>> Information that would differentiate between the open/close actions and
>>> the connect/disconnect actions. Wouldn't and open/close action on an
>>> object of connection be the same as a connect/disconnect?
>>>
>>> Another place where I am having difficulty is classifying a message
>>> where a network connection gets dropped (reset by peer). This is not
>>> really the same as a close since the end logging the message didn't
>>> perform the action of the close. Would the dropped connection be;
>>>
>>> action: detect
>>> object: connection
>>> status: failure
>>>
>>> Without some clarification on each of the tag values I think that I will
>>> be classifying many message in a way that is incompatible with other
>>> people's interpretation of the CEE.
>>>
>>> Thanks for any pointers you can provide.
>>



--
Bill LeRoy


[hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Help with taxonomy

Evan Rempel
In reply to this post by Evan Rempel
Your comments are heard loud and clear.

The "failure of the deny" is one of the most interesting type of events. These are the ones
where somebody got in and the should not have. We must have a way to classify this kind of event.

This does not change that other kinds of operations may be denied such as being able to open and read
a file, but not being able write to the file. The action still needs to be open/read/write etc. (not deny)
and the status has to be something like deny. Perhaps using status of "forbid, permit" and have actions of
"deny, allow" to keep them distinct.

Comments.




David Corlette wrote:

> My company changed my e-mail address so I can't post to the list anymore, but here goes....
> -------------
>
>
>>> -----
>>> This describes the deifference between open/close pair and the
>>> connect/disconnect. It covers how each side of the communcation view the
>>> actions, such as an open request - status failed would be seen on the
>>> server side as open request - status denied (failed would indicate an
>>> error).
>> I think denied can just be a failed on the authentication. Right? I like
>> to keep the number of entries minimal.
>
> No, I don't think so. Consider something that attempts to block a connection/authentication, but fails to do so (like
> IPSs in some configurations). How do you distinguish between a failed attempt to block some activity, and that activity
> itself failing?
>
> You have a major problem with perspective.
>
> XDAS had "denial" as a specific type of outcome, and made a clear distinction between operational "failures" and
> security "denials". In the latest work we're doing at DMTF, we're moving away from denial as an outcome, and making it
> an explicit action. Either way, you have to account for things that successfully block activity.



--
Evan Rempel                               [hidden email]
Senior Systems Administrator                 250.721.7691
Unix Services, University Systems, University of Victoria
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

How many projects support CEE

Evan Rempel
In reply to this post by Evan Rempel
Given William's question below I got to thinking that this is a chicken
and egg type question. Nobody wants to invest the energy into profiling
all of their events until they are confident that the event description
is stable, and without a clear winner in the event expression space,
nobody dedicates time to making it stable.

For years there have been projects that have attempted to standardize
logging and they have all failed. Partly due to the specifics of the
projects, but mostly because it took so long to stabilize the event
expressions that a new expression group started and it took momentum
away from it.

CEE is in an unprecedented place in that the tools to actually
implement the event expressions have just recently become available
(The structured log RFC, the lumberjack project, syslog-ng, ELSA, OSSEC etc.)


All of these have stated that they want to move forward using the CEE, but
if the CEE is not stable in time, these projects will not wait. They will
pick or invent a new standard, and since these projects, which are already
involved in a very significant amount of the Internet's logs (linux) they
will have mass adoption and will win the race regardless of merit.

Like Michael Starks wrote: "Let's fix this".

In my opinion, we only have short weeks before the next Linux releases come out
with some aspect of Lumberjack on them. As for my own in house project, I have even
less time.

I am not sure how much freedom I have in proposing changes to a 1.0alpha document, but
I will write up what I think is a reasonable change to the taxonomy.

Evan Rempel.



> [hidden email] wrote:
>
>
> Raffael Marty,
>
> How many device and or software companies are now considering or have
> processes in place to implement CEE? or do you think CEE is still
> needs a significant amount of work? Any interest from ArcSight, or
> EnVision in implementing.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Help with taxonomy

Sanford Whitehouse-2
In reply to this post by Evan Rempel
Hey Everyone.  It's been a while.

Evan,

The perspective that deny is an action is correct from the perspective
of the code asked to perform the task.  It was asked to do something and
could or couldn't.  It leaves open the event for failure of the code.

The open/read/write is what someone or something is asking the code to
enable.  It is not an action in itself.  The permitting of the
open/read/write and providing the set up necessary to do it is.  So is
the deny.  Another way to look at it is a deny is a response action to
an initial action.

The result of an action failing can be anything.  One of the
characteristics of some failures is it can be complicated and
unpredictable.  It may not be possible, or at the least very complicated
to report that something is happening that shouldn't because of a failure.

Its certain that knowing if someone is doing something they shouldn't is
important.  But it's a stretch to say that a fail implies it might be
happening.

In a sequence of actions the initiator fails when they can't meet the
criteria necessary to succeed.  It's a success when the piece evaluating
the criteria denies the request.

Note that the failure mode becomes important.  The reason for the
failure now enters into the mix.  "Invalid password" is a reason for
initial failure.  "Software failure" or some such is reason the code
couldn't complete the requested task.

Also in many cases, a firewall is one example, a deny is considered an
action taken as a response to a connection attempt.

"failure of the deny" is a conceptual event that may not actually exist.

Sanford

On 7/3/2012 9:38 AM, Evan Rempel wrote:

> Your comments are heard loud and clear.
>
> The "failure of the deny" is one of the most interesting type of events.
> These are the ones
> where somebody got in and the should not have. We must have a way to
> classify this kind of event.
>
> This does not change that other kinds of operations may be denied such
> as being able to open and read
> a file, but not being able write to the file. The action still needs to
> be open/read/write etc. (not deny)
> and the status has to be something like deny. Perhaps using status of
> "forbid, permit" and have actions of
> "deny, allow" to keep them distinct.
>
> Comments.
>
>
>
>
> David Corlette wrote:
>> My company changed my e-mail address so I can't post to the list
>> anymore, but here goes....
>> -------------
>>
>>
>>>> -----
>>>> This describes the deifference between open/close pair and the
>>>> connect/disconnect. It covers how each side of the communcation view
>>>> the
>>>> actions, such as an open request - status failed would be seen on the
>>>> server side as open request - status denied (failed would indicate an
>>>> error).
>>> I think denied can just be a failed on the authentication. Right? I like
>>> to keep the number of entries minimal.
>>
>> No, I don't think so. Consider something that attempts to block a
>> connection/authentication, but fails to do so (like
>> IPSs in some configurations). How do you distinguish between a failed
>> attempt to block some activity, and that activity
>> itself failing?
>>
>> You have a major problem with perspective.
>>
>> XDAS had "denial" as a specific type of outcome, and made a clear
>> distinction between operational "failures" and
>> security "denials". In the latest work we're doing at DMTF, we're
>> moving away from denial as an outcome, and making it
>> an explicit action. Either way, you have to account for things that
>> successfully block activity.
>
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Help with taxonomy

Jake Evans
In reply to this post by william.leroy
Sorry, returning from vacation and a little late to the conversation.

I don't know who else has implemented or plans to implement CEE, but Tripwire has released an implementation for the audit logger contained with Tripwire Log Center.  The tags and their descriptions were based on some fairly early CEE work that we began to look at roughly 2 years ago so we're certainly going to need to go back and do some updating.

That said, the CEE approach was what allowed us to implement log event classification.  We had been going down an entirely different path when we had our first conversations about CEE with Anton Chuvakin, which allowed to take a much more simplified approach from a programmatic standpoint as well as a log classification standpoint.

Best regards,
Jake

Jake Evans, GCIH, GWAPT, GCIA, CISSP, CISA, CRISC, CPISA, CPISM | Sr. Security and Compliance Analyst

Tripwire
101 SW Main St., Ste. 1500
Portland, OR 97204  
Direct: 503.276.7658
Main: 503.276.7500

TRIPWIRE | TAKE CONTROL.
www.tripwire.com


-----Original Message-----
From: [hidden email] [mailto:[hidden email]]
Sent: Wednesday, June 27, 2012 9:31 AM
To: [hidden email]
Subject: Re: [CEE-DISCUSSION-LIST] Help with taxonomy

Raffael Marty,

How many device and or software companies are now considering or have processes in place to implement CEE? or do you think CEE is still needs a significant amount of work? Any interest from ArcSight, or EnVision in implementing.


On Wed, Jun 27, 2012 at 10:57 AM, Raffael Marty <[hidden email]> wrote:

>> connect: a pre-authenticaed connection - communicaton channel
>> authenticate (login):
>> authorize:
>> open: a post authenticate/authorized connection or an unauthenticated
>> connection is established.
>>
>> write:
>> read:
>>
>> close: close the authenticated/authorized connection (logout
>> disconnect: close the communication channel.
>
> I like this model a lot! Thanks for putting this here.
>
>> If  a forced close or disconnect occurs it is classified as a drop.
>
> Okay, I can buy into that.
>
>> -----
>> This describes the deifference between open/close pair and the
>> connect/disconnect. It covers how each side of the communcation view
>> the actions, such as an open request - status failed would be seen on
>> the server side as open request - status denied (failed would
>> indicate an error).
>
> I think denied can just be a failed on the authentication. Right? I
> like to keep the number of entries minimal.
>
> I'll see that we can integrate this into the CEE guidelines.
>
> Thanks again!
>
>  -raffy
>
>>
>>
>> Raffael Marty <[hidden email]> wrote:
>>
>>
>> Evan,
>>
>> I am not sure there is another place where we captured more
>> information about the individual tags. I am happy to try and
>> elaborate on the ones that you have trouble with.
>>
>> The specific issue you are addressing is an interesting one and
>> you'll keep finding that at other places. The idea of the taxonomy is
>> to put events into buckets. The question is then how many buckets to
>> you want to have or more general, how precise do you want the buckets
>> to express the event. The more precise you get, the more you have to
>> write rules or searches that are super precise (counter to the design
>> goal). If you are too coarse, you will have the problem that you cannot express much.
>>
>> So, a dopped, a closed, and a reset could be classified the same.
>>
>> Don't use an action of detect. What does detect mean? That's more of
>> a human thing. I am giving a recommendation here that is not
>> necessarily CEE blessed yet, we are still discussing that: A firewall drop:
>>
>> object: connection | action: start | status: failure
>>
>> I am noting this as an action item for the board to put out some examples.
>> Ideally one per tag.
>>
>>  -raffy
>>
>> --
>>  Raffael Marty
>>  @raffaelmarty                                          
>> http://raffy.ch
>>
>> On Jun 25, 2012, at 7:36 AM, Evan Rempel wrote:
>>
>>> I am entering into a large project to classify ALL of the log
>>> messages that our central log server collects. I want to do it
>>> correctly from the start since doing things twice is always more time consuming.
>>>
>>> The taxonomy.xsd file
>>>
>>> http://cee.mitre.org/repository/schemas/v10alpha/taxonomy.xsd
>>>
>>> seems to lack the description data for many of the tag values. Is
>>> there a human friendly documentation page that describes when each
>>> of the tag values should be used?
>>>
>>> Information that would differentiate between the open/close actions
>>> and the connect/disconnect actions. Wouldn't and open/close action
>>> on an object of connection be the same as a connect/disconnect?
>>>
>>> Another place where I am having difficulty is classifying a message
>>> where a network connection gets dropped (reset by peer). This is not
>>> really the same as a close since the end logging the message didn't
>>> perform the action of the close. Would the dropped connection be;
>>>
>>> action: detect
>>> object: connection
>>> status: failure
>>>
>>> Without some clarification on each of the tag values I think that I
>>> will be classifying many message in a way that is incompatible with
>>> other people's interpretation of the CEE.
>>>
>>> Thanks for any pointers you can provide.
>>



--
Bill LeRoy


[hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Help with taxonomy

Evan Rempel
In reply to this post by Sanford Whitehouse-2
Over the past few weeks I have asked what I thought were straight forward questions, only to
get some wildly differing points of view. Since then I have spent quite a bit of time considering
what the fundamental differences between these views are, and how to express my confusion.
Here is what I have come up with.


When considering a single point of logging such as a stand alone program that reads some input,
makes calculations as presents a result, it is simple to define what action is in progress, which object
is being operated on and the status of the action. As soon a multiple logging point come into play
the situation becomes much less clear. Each logging point can be though of as a different point of
view on the same sequence of events. How each point of view classifies these events leaves a lot
of room for interpretation. To me it is important that a single event be described similarly from all
view points.

I think that at least some of the 5 Taxonomy tags should be common to all view points of an event,
and more specifically I think that at a minimum the action and the object should be the same.
This would aid in event correlation by systems that monitor events being expressed by both
client and server such as intrusion detection.

If (and it is a big if) the premis is that the action and the object are the same when describing
an event from multiple view points, the process of a single network connection becomes.

Client - action:open,object:connection,status:ongoing
Server - action:authenticate,object:account,status:success
Server - action:authorize,object:session,status:success
Server - action:open,object:connection,status:permit
Server - action:allow,object:connection,status:success
Client - action:open,object:connection,status:success

In the case where a connection is denied due to authentiation

Client - action:open,object:connection,status:ongoing
Server - action:authenticate,object:account,status:failure
Server - action:open,object:connection,status:reject
Server - action:deny,object:connection,status:success
Client - action:open,object:connection,status:failure


There are lots of other cases, but the point I am trying to make is that
there is one event which is the open:connection that is described by two view
points and that both descriptions should use the smae open:connection taxonomy.

There are secondary events that are not visible to the client. They may be visible
to the server and a second server (such as ldap etc) but that is out of scope here.
These secondary events are only described from the point of view of the server.

This allows for both a rejected status, and a deny action.

I realize that the current taxonomy does not encompass this set of taxonomy,
nor have I been able to find any writeup on the concept of multiple view points
for a single event. It appears that every view point can describes all events as unique
from its private view point.

Comments on this?

Am I totally mussunderstanding the concept of an event? Is every view point of an action
really its own event, or are there multiple perspectives for events?

Thanks for helping out a newbie.

Evan Rempel.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Help with taxonomy

william.leroy
Dear all,

Microsoft has something like this in their events called "client src".
I thought this additional tag was very useful in parsing their events.


On Sat, Jul 14, 2012 at 8:13 PM, Evan Rempel <[hidden email]> wrote:

> Over the past few weeks I have asked what I thought were straight forward questions, only to
> get some wildly differing points of view. Since then I have spent quite a bit of time considering
> what the fundamental differences between these views are, and how to express my confusion.
> Here is what I have come up with.
>
>
> When considering a single point of logging such as a stand alone program that reads some input,
> makes calculations as presents a result, it is simple to define what action is in progress, which object
> is being operated on and the status of the action. As soon a multiple logging point come into play
> the situation becomes much less clear. Each logging point can be though of as a different point of
> view on the same sequence of events. How each point of view classifies these events leaves a lot
> of room for interpretation. To me it is important that a single event be described similarly from all
> view points.
>
> I think that at least some of the 5 Taxonomy tags should be common to all view points of an event,
> and more specifically I think that at a minimum the action and the object should be the same.
> This would aid in event correlation by systems that monitor events being expressed by both
> client and server such as intrusion detection.
>
> If (and it is a big if) the premis is that the action and the object are the same when describing
> an event from multiple view points, the process of a single network connection becomes.
>
> Client - action:open,object:connection,status:ongoing
> Server - action:authenticate,object:account,status:success
> Server - action:authorize,object:session,status:success
> Server - action:open,object:connection,status:permit
> Server - action:allow,object:connection,status:success
> Client - action:open,object:connection,status:success
>
> In the case where a connection is denied due to authentiation
>
> Client - action:open,object:connection,status:ongoing
> Server - action:authenticate,object:account,status:failure
> Server - action:open,object:connection,status:reject
> Server - action:deny,object:connection,status:success
> Client - action:open,object:connection,status:failure
>
>
> There are lots of other cases, but the point I am trying to make is that
> there is one event which is the open:connection that is described by two view
> points and that both descriptions should use the smae open:connection taxonomy.
>
> There are secondary events that are not visible to the client. They may be visible
> to the server and a second server (such as ldap etc) but that is out of scope here.
> These secondary events are only described from the point of view of the server.
>
> This allows for both a rejected status, and a deny action.
>
> I realize that the current taxonomy does not encompass this set of taxonomy,
> nor have I been able to find any writeup on the concept of multiple view points
> for a single event. It appears that every view point can describes all events as unique
> from its private view point.
>
> Comments on this?
>
> Am I totally mussunderstanding the concept of an event? Is every view point of an action
> really its own event, or are there multiple perspectives for events?
>
> Thanks for helping out a newbie.
>
> Evan Rempel.



--
Bill LeRoy


[hidden email]
Loading...