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: (972)-26664666
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