Motivations for Vendor adoption (was RE: A whitepaper response)

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

Motivations for Vendor adoption (was RE: A whitepaper response)

heinbockel
>-----Original Message-----
>From: Sanford Whitehouse [mailto:[hidden email]]
>Sent: Monday, 22 October, 2007 03:35
>To: cee-discussion-list CEE-Related Discussion
>Subject: [CEE-DISCUSSION-LIST] A whitepaper response
>
<snip>
>
>If there is an aspect of any standard that should be stated, it is the
>reason vendors should adopt it.  What benefit do they receive by
giving
>up ownership of their logs?  What will hurt them if they chose to go
>another direction?  With so many companies moving to multi-function
>products and enterprise scale manageability, why should
>interoperaterability with competitors at any level benefit them?
>

Sanford brings up a point that I have been intentionally avoiding:
what is the motivation for vendor adoption?

There has been a lot of interest in CEE from both vendors and
researchers,
and there is an understandable, realistic interest from IT customers as
CEE would be able to help with regulatory compliance and network
monitoring. However, what is the motivation for vendors?

For log management and SIM vendors, there is an obvious cost reduction
with a decrease in the effort for mapping log data and supporting new
products. For your more generic software vendors, besides the "playing
nice with others" and possibly improving internal log support, what
would you argue as being the major reasons why a vendor should
participate?
Or, if you are a vendor representative, what is your interest in CEE?


William Heinbockel
Infosec Engineer, Sr.
The MITRE Corporation
202 Burlington Rd. MS S145
Bedford, MA 01730
[hidden email]
781-271-2615

Reply | Threaded
Open this post in threaded view
|

Re: Motivations for Vendor adoption (was RE: A whitepaper response)

Caudle, Rodney
<snip>
For log management and SIM vendors, there is an obvious cost reduction
with a decrease in the effort for mapping log data and supporting new
products. For your more generic software vendors, besides the "playing
nice with others" and possibly improving internal log support, what
would you argue as being the major reasons why a vendor should
participate?
</snip>

One of the values of CEE could be to provide guidelines for the use of
CEE.  For example, when a logon fails, what information is critical to
convey, what information is nice to have and what information is
extraneous?  If CEE can answer this type of questions it would make it
easier for vendors to implement logging in their products saving them
cycles.  If CEE can show that they save time (or $$) for vendors they
will adopt the approach.  Perhaps the working group can issue a tool
which qualifies a logstore against CEE to validate compliance?  Just a
thought... How can we make CEE more adoptable for vendors?

This leads to a question that I have.  Does the perspective of how an
event is logged change the information expressed in the event?  For
instance, if a logon fails from a local user at the console versus a
remote user from across the network, is the information needed different
or the same?

Then a follow-up question would be what perspectives are present in
events?  Does anyone have thoughts on this topic?

Regards,
Rodney Caudle
Lead Security Architect
Northrop Grumman - VITA

Reply | Threaded
Open this post in threaded view
|

Re: Motivations for Vendor adoption (was RE: A whitepaper response)

Anton Chuvakin
In reply to this post by heinbockel
> One of the values of CEE could be to provide guidelines for the use of
> CEE.  For example, when a logon fails, what information is critical to
> convey, what information is nice to have and what information is
> extraneous?  If CEE can answer this type of questions it would make it

Yes, this is indeed very true and was one of the original motivations
for CEE, discussed early on. CEE will influence the application
vendors as well as companies writing their own home-grown apps to "do
logging right"

> This leads to a question that I have.  Does the perspective of how an
> event is logged change the information expressed in the event?  For

Not really, I'd go for defining the details needed for various event
taxonomy categories. E.g. for failures - why failed.  For success -
all the details on who succeeded on what, where, etc.

--
Anton Chuvakin, Ph.D., GCIA, GCIH, GCFA
      http://www.chuvakin.org
  http://chuvakin.blogspot.com
    http://www.info-secure.org