Re: Draft Sensor Output Specification for Technical Discussion

[Caudle, Rodney]

I haven't seen much discussion on this working group so I wanted to propose
a taxonomy to use.  I put forth the following suggestion for a taxonomy:

Technology
Category
  Sub-Category (optional)
    Action
      Result

Placing this in a tiered structure you have two root nodes of information:
Technology and Category.  These two pieces of information would be unrelated
although trends may appear after classification to allow this to be tiered.

The category choice yeilds zero or more sub-categories.  The combination of
category + sub-category provides a selection of Actions that might occur.
Choosing an action would allow a few options for the result.

So for a Unix box logging that a user initiated a login for a user the
information might look like:

Technology = Operating System or OS
Category = System Access
Sub-Category = <empty>
Action = Login Attempt or just Login
Result = Success (S) or Failure (F)

Another example is a database application logging that a user initiated a
login the information would be very similar:

Technology = Database Management
Category = System Access
Sub-Category = <empty>
Action = Login Attempt or just Attempt
Result = Success (S) or Failure (F)

Following one of the examples, Oil Pipeline, you could track the opening of a
pipe valve like this:

Technology = Control System
Category = Flow Control
Sub-Category = <empty>
Action = Valve Open
Result = Success (S) or Failure (F)

Please hash around this proposal and put forth several scenarios so we can
discuss how it works or doesn't work.  Propose some scenarios and fill in the
blanks.

Rodney Caudle
Northrop Grumman
Lead Security Architect - IT-CSL

-----Original Message-----
From: Raffael Marty [mailto:rmarty@...]
Sent: Friday, December 07, 2007 1:41 PM
To: CEE-DISCUSSION-LIST@...
Subject: Re: [CEE-DISCUSSION-LIST] Draft Sensor Output Specification for
Technical Discussion

Good morning!

I couldn't resist. You guys know that I am very opinionated when it comes to
taxonomies:

> - you chose the following taxonomy fields:
>   + Subject
>   + Verb
>   + Object
>   + Result
> - if not based on CEE chat on that very subject, could you share your
> motivations for choosing these field (which I like a lot!)


I don't like it. Sorry, but subject is a fairly bad idea. If we make that an
optional field. Maybe. But Anton, we had quite some discussion around this a
while ago and I thought I had you convinced that it is hardly ever possible
to define an object in a taxonomy concept.

I need to read your document, Heidi. I just haven't had any bandwidth so
far. It's on my todo list.

Thanks and have a good weekend everyone

   -raffy

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

[Assaf Keren]

Hello,

First, I need to introduce myself, my name is Assaf Keren and I'm a
member of the Israeli E-gov Information Security Team. We are heavily
involved in log collection, transfer and analysis and that is the main
reason why I have joined this discussion group.

As for the suggested Taxonomy, I'd be happy to hear how you propose to
use it taking events from security log-oriented machines (such as IDSs,
Application Firewalls, etc). It seems fairly basic in dealing with heavy
logs which supply a multitude of fields and information that will be
drawn into the action/result fields, which will make it very hard to
parse later on. I would also like to see a standard Source/Destination
field which also means a lot for the analysis phase.

Regards,

Assaf Keren
Information Security Team
E - Gov Department
Phone: [phone]
Cellular: (972)-525051686
E-Mail: assafk@...

-----Original Message-----
From: Caudle, Rodney [mailto:Rodney.Caudle@...]
Sent: Friday, January 11, 2008 5:33 PM
To: CEE-DISCUSSION-LIST@...
Subject: Re: [CEE-DISCUSSION-LIST] Draft Sensor Output Specification for
Technical Discussion

I haven't seen much discussion on this working group so I wanted to
propose
a taxonomy to use.  I put forth the following suggestion for a taxonomy:

Technology
Category
  Sub-Category (optional)
    Action
      Result

Placing this in a tiered structure you have two root nodes of
information:
Technology and Category.  These two pieces of information would be
unrelated
although trends may appear after classification to allow this to be
tiered.

The category choice yeilds zero or more sub-categories.  The combination
of
category + sub-category provides a selection of Actions that might
occur.
Choosing an action would allow a few options for the result.

So for a Unix box logging that a user initiated a login for a user the
information might look like:

Technology = Operating System or OS
Category = System Access
Sub-Category = <empty>
Action = Login Attempt or just Login
Result = Success (S) or Failure (F)

Another example is a database application logging that a user initiated
a
login the information would be very similar:

Technology = Database Management
Category = System Access
Sub-Category = <empty>
Action = Login Attempt or just Attempt
Result = Success (S) or Failure (F)

Following one of the examples, Oil Pipeline, you could track the opening
of a
pipe valve like this:

Technology = Control System
Category = Flow Control
Sub-Category = <empty>
Action = Valve Open
Result = Success (S) or Failure (F)

Please hash around this proposal and put forth several scenarios so we
can
discuss how it works or doesn't work.  Propose some scenarios and fill
in the
blanks.

Rodney Caudle
Northrop Grumman
Lead Security Architect - IT-CSL

-----Original Message-----
From: Raffael Marty [mailto:rmarty@...]
Sent: Friday, December 07, 2007 1:41 PM
To: CEE-DISCUSSION-LIST@...
Subject: Re: [CEE-DISCUSSION-LIST] Draft Sensor Output Specification for
Technical Discussion

Good morning!

I couldn't resist. You guys know that I am very opinionated when it
comes to
taxonomies:

> - you chose the following taxonomy fields:
>   + Subject
>   + Verb
>   + Object
>   + Result
> - if not based on CEE chat on that very subject, could you share your
> motivations for choosing these field (which I like a lot!)


I don't like it. Sorry, but subject is a fairly bad idea. If we make
that an
optional field. Maybe. But Anton, we had quite some discussion around
this a
while ago and I thought I had you convinced that it is hardly ever
possible
to define an object in a taxonomy concept.

I need to read your document, Heidi. I just haven't had any bandwidth so
far. It's on my todo list.

Thanks and have a good weekend everyone

   -raffy

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

[Lagadec Philippe]

Hello,

the taxonomy is just one part of the fields in an event. Of course there are still many necessary fields for source and destination addresses, timestamps, etc. but these are outside of the taxonomy.

This is why we need to separate:
1) variable fields such as timestamps and addresses
2) taxonomy which describes the meaning of the event using a fixed list/tree of values

Hope this helps,

Philippe.


-----Original Message-----
From: Assaf Keren [mailto:assafk@...]
Sent: 13 January 2008 07:36
To: CEE-DISCUSSION-LIST@...
Subject: Re: [CEE-DISCUSSION-LIST] Draft Sensor Output Specification for Technical Discussion

Hello,

First, I need to introduce myself, my name is Assaf Keren and I'm a member of the Israeli E-gov Information Security Team. We are heavily involved in log collection, transfer and analysis and that is the main reason why I have joined this discussion group.

As for the suggested Taxonomy, I'd be happy to hear how you propose to use it taking events from security log-oriented machines (such as IDSs, Application Firewalls, etc). It seems fairly basic in dealing with heavy logs which supply a multitude of fields and information that will be drawn into the action/result fields, which will make it very hard to parse later on. I would also like to see a standard Source/Destination field which also means a lot for the analysis phase.

Regards,

Assaf Keren
Information Security Team
E - Gov Department
Phone: [phone]
Cellular: (972)-525051686
E-Mail: assafk@...

-----Original Message-----
From: Caudle, Rodney [mailto:Rodney.Caudle@...]
Sent: Friday, January 11, 2008 5:33 PM
To: CEE-DISCUSSION-LIST@...
Subject: Re: [CEE-DISCUSSION-LIST] Draft Sensor Output Specification for Technical Discussion

I haven't seen much discussion on this working group so I wanted to propose a taxonomy to use.  I put forth the following suggestion for a taxonomy:

Technology
Category
  Sub-Category (optional)
    Action
      Result

Placing this in a tiered structure you have two root nodes of
information:
Technology and Category.  These two pieces of information would be unrelated although trends may appear after classification to allow this to be tiered.

The category choice yeilds zero or more sub-categories.  The combination of category + sub-category provides a selection of Actions that might occur.
Choosing an action would allow a few options for the result.

So for a Unix box logging that a user initiated a login for a user the information might look like:

Technology = Operating System or OS
Category = System Access
Sub-Category = <empty>
Action = Login Attempt or just Login
Result = Success (S) or Failure (F)

Another example is a database application logging that a user initiated a login the information would be very similar:

Technology = Database Management
Category = System Access
Sub-Category = <empty>
Action = Login Attempt or just Attempt
Result = Success (S) or Failure (F)

Following one of the examples, Oil Pipeline, you could track the opening of a pipe valve like this:

Technology = Control System
Category = Flow Control
Sub-Category = <empty>
Action = Valve Open
Result = Success (S) or Failure (F)

Please hash around this proposal and put forth several scenarios so we can discuss how it works or doesn't work.  Propose some scenarios and fill in the blanks.

Rodney Caudle
Northrop Grumman
Lead Security Architect - IT-CSL

-----Original Message-----
From: Raffael Marty [mailto:rmarty@...]
Sent: Friday, December 07, 2007 1:41 PM
To: CEE-DISCUSSION-LIST@...
Subject: Re: [CEE-DISCUSSION-LIST] Draft Sensor Output Specification for Technical Discussion

Good morning!

I couldn't resist. You guys know that I am very opinionated when it comes to
taxonomies:

> - you chose the following taxonomy fields:
>   + Subject
>   + Verb
>   + Object
>   + Result
> - if not based on CEE chat on that very subject, could you share your
> motivations for choosing these field (which I like a lot!)


I don't like it. Sorry, but subject is a fairly bad idea. If we make that an optional field. Maybe. But Anton, we had quite some discussion around this a while ago and I thought I had you convinced that it is hardly ever possible to define an object in a taxonomy concept.

I need to read your document, Heidi. I just haven't had any bandwidth so far. It's on my todo list.

Thanks and have a good weekend everyone

   -raffy

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

[Lagadec Philippe]

Hello again,

I just want to add that the XML draft spec we worked on with MITRE and that Heidi sent to this list last year is maybe a good example to illustrate this (even if we know this spec is very draft and far from perfect):

- Taxonomy is stored in the <message> tag, using subject/verb/object/result (which could be replaced by something like technology/category/action/... or any other taxonomy).

- All other fields are variable fields, e.g. they can contain any valid value.

Here is one of the samples:

<Event event_id="ID020">
    <Timestamp>2006-04-12T19:42:17-05:00</Timestamp>
    <MsgId>1:222:2</MsgId>

    <Message>
        <Subject>remote</Subject>
        <Verb type="DDoS" name="tfn2k">attack</Verb>
        <Object>system</Object>
        <Result>attempt</Result>
    </Message>

    <Count>1</Count>
    <NetworkEvent>
        <NetPrtcl>ICMP</NetPrtcl>
        <TransportPrtcl></TransportPrtcl>
        <AppPrtcl></AppPrtcl>
        <PcktSize>6</PcktSize>
        <PcktContents></PcktContents>
    </NetworkEvent>
    <DeviceInformation type="observer">
        <AppName>snort</AppName>
        <AppVer>2.6.15</AppVer>
        <Process id="8688"/>
        <Hostname>solo</Hostname>
         <Location>Somewhere</Location>
    </DeviceInformation>

    <DeviceInformation type="source">
        <AppName></AppName>
        <IP>192.168.25.252</IP>
        <Location>Somewhere</Location>
        <Port>32575</Port>
    </DeviceInformation>

    <DeviceInformation type="destination">
        <AppName></AppName>
        <IP>10.10.2.20</IP>
        <Location>Somewhere else</Location>
        <Port>20</Port>
    </DeviceInformation>
</Event>


So maybe for the CEE discussion we should first agree on a list of variable fields (these are roughly the same in most log formats), and then focus on the taxonomy, which is the most interesting part.

Philippe.



-----Original Message-----
From: Lagadec Philippe [mailto:Philippe.Lagadec@...]
Sent: 14 January 2008 09:02
To: CEE-DISCUSSION-LIST@...
Subject: Re: [CEE-DISCUSSION-LIST] Draft Sensor Output Specification for Technical Discussion

Hello,

the taxonomy is just one part of the fields in an event. Of course there are still many necessary fields for source and destination addresses, timestamps, etc. but these are outside of the taxonomy.

This is why we need to separate:
1) variable fields such as timestamps and addresses
2) taxonomy which describes the meaning of the event using a fixed list/tree of values

Hope this helps,

Philippe.


-----Original Message-----
From: Assaf Keren [mailto:assafk@...]
Sent: 13 January 2008 07:36
To: CEE-DISCUSSION-LIST@...
Subject: Re: [CEE-DISCUSSION-LIST] Draft Sensor Output Specification for Technical Discussion

Hello,

First, I need to introduce myself, my name is Assaf Keren and I'm a member of the Israeli E-gov Information Security Team. We are heavily involved in log collection, transfer and analysis and that is the main reason why I have joined this discussion group.

As for the suggested Taxonomy, I'd be happy to hear how you propose to use it taking events from security log-oriented machines (such as IDSs, Application Firewalls, etc). It seems fairly basic in dealing with heavy logs which supply a multitude of fields and information that will be drawn into the action/result fields, which will make it very hard to parse later on. I would also like to see a standard Source/Destination field which also means a lot for the analysis phase.

Regards,

Assaf Keren
Information Security Team
E - Gov Department
Phone: [phone]
Cellular: (972)-525051686
E-Mail: assafk@...

-----Original Message-----
From: Caudle, Rodney [mailto:Rodney.Caudle@...]
Sent: Friday, January 11, 2008 5:33 PM
To: CEE-DISCUSSION-LIST@...
Subject: Re: [CEE-DISCUSSION-LIST] Draft Sensor Output Specification for Technical Discussion

I haven't seen much discussion on this working group so I wanted to propose a taxonomy to use.  I put forth the following suggestion for a taxonomy:

Technology
Category
  Sub-Category (optional)
    Action
      Result

Placing this in a tiered structure you have two root nodes of
information:
Technology and Category.  These two pieces of information would be unrelated although trends may appear after classification to allow this to be tiered.

The category choice yeilds zero or more sub-categories.  The combination of category + sub-category provides a selection of Actions that might occur.
Choosing an action would allow a few options for the result.

So for a Unix box logging that a user initiated a login for a user the information might look like:

Technology = Operating System or OS
Category = System Access
Sub-Category = <empty>
Action = Login Attempt or just Login
Result = Success (S) or Failure (F)

Another example is a database application logging that a user initiated a login the information would be very similar:

Technology = Database Management
Category = System Access
Sub-Category = <empty>
Action = Login Attempt or just Attempt
Result = Success (S) or Failure (F)

Following one of the examples, Oil Pipeline, you could track the opening of a pipe valve like this:

Technology = Control System
Category = Flow Control
Sub-Category = <empty>
Action = Valve Open
Result = Success (S) or Failure (F)

Please hash around this proposal and put forth several scenarios so we can discuss how it works or doesn't work.  Propose some scenarios and fill in the blanks.

Rodney Caudle
Northrop Grumman
Lead Security Architect - IT-CSL

-----Original Message-----
From: Raffael Marty [mailto:rmarty@...]
Sent: Friday, December 07, 2007 1:41 PM
To: CEE-DISCUSSION-LIST@...
Subject: Re: [CEE-DISCUSSION-LIST] Draft Sensor Output Specification for Technical Discussion

Good morning!

I couldn't resist. You guys know that I am very opinionated when it comes to
taxonomies:

> - you chose the following taxonomy fields:
>   + Subject
>   + Verb
>   + Object
>   + Result
> - if not based on CEE chat on that very subject, could you share your
> motivations for choosing these field (which I like a lot!)


I don't like it. Sorry, but subject is a fairly bad idea. If we make that an optional field. Maybe. But Anton, we had quite some discussion around this a while ago and I thought I had you convinced that it is hardly ever possible to define an object in a taxonomy concept.

I need to read your document, Heidi. I just haven't had any bandwidth so far. It's on my todo list.

Thanks and have a good weekend everyone

   -raffy

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

[Caudle, Rodney]

So if we can capture a plan on what needs to be addressed first the order
would look like:

(1) Figure out the variable fields that should be in an event
(2) Figure out an approach to taxonomy
(3) Build a dictionary that ties #1 and #2 together

Assuming this is correct then item #1 is the place to start.  My thoughts on
#1 is that the variable information is ... variable depending on the event
that is received.  For example, consider a login attempt.  There are various
scenarios on how this event can be captured and depending on the scenario of
how the event was captured the information changes.

Scenario #1:

[Lagadec Philippe]

You're right about variable fields. That's why some of them should be optional, while others are mandatory.
A few examples:
- Mandatory fields: timestamp (start and/or end time), observer device, ...
- Optional fields: source, destination, username, user ID, ...

A simple approach is to consider fields as optional or mandatory without any other consideration.
A smarter approach is to define several scenarios and link sets of relevant fields to each of these scenarios. I'm not sure about that, but I think this is the way IDMEF is designed for example.

I'm sure there are several experts on this mailing-list who already have an extensive list of fields in mind.
;-)

Philippe.


-----Original Message-----
From: Caudle, Rodney [mailto:Rodney.Caudle@...]
Sent: 14 January 2008 14:30
To: CEE-DISCUSSION-LIST@...
Subject: Re: [CEE-DISCUSSION-LIST] Draft Sensor Output Specification for Technical Discussion


So if we can capture a plan on what needs to be addressed first the order would look like:

(1) Figure out the variable fields that should be in an event
(2) Figure out an approach to taxonomy
(3) Build a dictionary that ties #1 and #2 together

Assuming this is correct then item #1 is the place to start.  My thoughts on
#1 is that the variable information is ... variable depending on the event that is received.  For example, consider a login attempt.  There are various scenarios on how this event can be captured and depending on the scenario of how the event was captured the information changes.

Scenario #1:
===============================A user logs into the local console and attempts to establish a session.
This event is recorded on the same machine as it was attempted on so there is only a single entity (device) involved.  In addition, the event that is recorded would only have information on a single user (destination) because the other information is unavailable.  There would be 1 device and 1 user available in this event.

Devices: 1
Users: 1

Scenario #2:
===============================A user logs into a remote machine using SSH to establish a session.  This event is recorded on the destination machine because this is where the application receiving the login attempt is running.  This type of login attempt would have information on two devices: source and destination.  In addition, this type of event would have information on at least 1 user but could have information on a second user.

Devices: 2
Users: 1 (2)


Scenario #3:
===============================The third type of scenario for recording a login attempt involves a NIDS sensor detecting an attempt by intercepting traffic between two hosts.  This scenario would have information on three devices and at least one user.

Devices: 3
Users: 1 (2)


In all of these scenarios the taxonomy of the event should be the same because the same action is occuring.  However, the information available in the event depends on the scenario that caused the event to be captured.  I mentioned this in an earlier message and stated that the perspective of the event would change the information available.  By "perspective" I meant the perspective of the host or device that was recording the event.  This perspective will effect the variable fields that are returned as part of the event.

Regards,
Rodney Caudle
Lead Security Architect
Northrop Grumman