Re: Draft Sensor Output Specification for T echnical Discussion

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

Re: Draft Sensor Output Specification for T echnical Discussion

Wolfkiel, Joseph
Can you send the URL or document out to the list?  I spent about 10 minutes
digging around to read about the XDAS stuff, but couldn't figure out where
the taxonomy and background information is documented.

Lt Col Joseph L. Wolfkiel

Director, Computer Network Defense Research & Technology (CND R&T) Program
Management Office
Commercial 410-854-5401 DSN 244-5401
Fax 410-854-6700


-----Original Message-----
From: David Corlette [mailto:[hidden email]]
Sent: Monday, January 21, 2008 5:31 PM
To: [hidden email]
Subject: Re: [CEE-DISCUSSION-LIST] Draft Sensor Output Specification for
Technical Discussion


Hi there Rodney,

I've talked previously on this list about the benefit of not re-inventing
the wheel.  I'd recommend you take a look at the existing OpenGroup's XDAS
event format, which defines both the information to be included and an event
taxonomy, both extensible.

We're working on a new version that's a bit more flexible (specifically, the
taxonomy becomes a dot-separated heirarchical field), but the basics are
there, and all the scenarios you describe below are easily handled.

>>> "Caudle, Rodney" <[hidden email]> 01/14/08 8:29 AM >>>

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

Re: Draft Sensor Output Specification for Technical Discussion

David Corlette
Yes, sorry, I had to go find it myself ;-)

The current specification is here:
http://www.opengroup.org/bookstore/catalog/p441.htm

Note that it has languished somewhat for a while, but we are close to releasing a new draft specification which updates the format to slightly more modern conventions.  I'll post to this list once the draft is complete (incidentally, we incorporated many of the suggestions raised by members of this list when we solicited same a few months ago).

>>> On Tue, Jan 22, 2008 at  7:29 AM, in message
<[hidden email]>, "Wolfkiel,
Joseph" <[hidden email]> wrote:

> Can you send the URL or document out to the list?  I spent about 10 minutes
> digging around to read about the XDAS stuff, but couldn't figure out where
> the taxonomy and background information is documented.
>
> Lt Col Joseph L. Wolfkiel
>
> Director, Computer Network Defense Research & Technology (CND R&T) Program
> Management Office
> Commercial 410-854-5401 DSN 244-5401
> Fax 410-854-6700
>
>
> -----Original Message-----
> From: David Corlette [mailto:[hidden email]]
> Sent: Monday, January 21, 2008 5:31 PM
> To: [hidden email]
> Subject: Re: [CEE-DISCUSSION-LIST] Draft Sensor Output Specification for
> Technical Discussion
>
>
> Hi there Rodney,
>
> I've talked previously on this list about the benefit of not re-inventing
> the wheel.  I'd recommend you take a look at the existing OpenGroup's XDAS
> event format, which defines both the information to be included and an event
> taxonomy, both extensible.
>
> We're working on a new version that's a bit more flexible (specifically, the
> taxonomy becomes a dot-separated heirarchical field), but the basics are
> there, and all the scenarios you describe below are easily handled.
>
>>>> "Caudle, Rodney" <[hidden email]> 01/14/08 8:29 AM >>>
>
> 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
Reply | Threaded
Open this post in threaded view
|

Re: Draft Sensor Output Specification for Technical Discussion

C. Church
All,

        Has anyone reviewed the latest syslog draft from the IETF?
The URL is:
http://www.ietf.org/internet-drafts/draft-ietf-syslog-protocol-23.txt

Notably, they include the concept of "structured data." (Section 6.3) Word
from our IETF members is that this may go through as the new syslog standard
very soon.  

So, my question is: would creating an enterprise ID and setting our expected
SD-IDs be sufficient?  Must we define an entirely new logging standard to
compete with all of the others, and notably, with the IETF standard that
will likely be adopted (over time) everywhere?  To be honest, I'm not seeing
how the new syslog structured data section wouldn't be able to provide the
hierarchy information we're looking for.  Our purpose could then be
distilled to defining a standardized set of SD-IDs for given types of
messages - and find that our results get adopted widely, and easily.


Christopher Church, Chief Architect
Alert Logic, Inc.
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Draft Sensor Output Specification for Technical Discussion

heinbockel

Thanks for the pointer Chris.

I will follow-up and see what they are doing.
I imagine that this will at least address some
of the gap that CEE is aiming for.

We can at least add some our input into the
IETF draft to get the some of this stuff fasttracked
into Syslog.



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

>-----Original Message-----
>From: C. Church [mailto:[hidden email]]
>Sent: Tuesday, 22 January, 2008 10:26
>To: cee-discussion-list CEE-Related Discussion
>Subject: Re: [CEE-DISCUSSION-LIST] Draft Sensor Output
>Specification for Technical Discussion
>
>All,
>
> Has anyone reviewed the latest syslog draft from the IETF?
>The URL is:
>http://www.ietf.org/internet-drafts/draft-ietf-syslog-protocol-23.txt
>
>Notably, they include the concept of "structured data."
>(Section 6.3) Word
>from our IETF members is that this may go through as the new
>syslog standard
>very soon.  
>
>So, my question is: would creating an enterprise ID and
>setting our expected
>SD-IDs be sufficient?  Must we define an entirely new logging
>standard to
>compete with all of the others, and notably, with the IETF
>standard that
>will likely be adopted (over time) everywhere?  To be honest,
>I'm not seeing
>how the new syslog structured data section wouldn't be able to
>provide the
>hierarchy information we're looking for.  Our purpose could then be
>distilled to defining a standardized set of SD-IDs for given types of
>messages - and find that our results get adopted widely, and easily.
>
>
>Christopher Church, Chief Architect
>Alert Logic, Inc.
>[hidden email]
>

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

Re: Draft Sensor Output Specification for Technical Discussion

C. Church
Bill,

        That's excellent - I believe the next gathering for IETF is in March
and I will probably be there with our representative (my boss) to discuss
the impact and urgency of the new specification.  Noting that over 4,000
companies have already reserved Enterprise IDs for the new spec, I have a
good feeling that this RFC will be ratified.


Christopher Church, Chief Architect
Alert Logic, Inc.
[hidden email]


> -----Original Message-----
> From: Heinbockel, Bill [mailto:[hidden email]]
> Sent: Friday, January 25, 2008 8:30 AM
> To: [hidden email]
> Subject: Re: [CEE-DISCUSSION-LIST] Draft Sensor Output Specification for
> Technical Discussion
>
>
> Thanks for the pointer Chris.
>
> I will follow-up and see what they are doing.
> I imagine that this will at least address some
> of the gap that CEE is aiming for.
>
> We can at least add some our input into the
> IETF draft to get the some of this stuff fasttracked
> into Syslog.
>
>
>
> William Heinbockel
> Infosec Engineer, Sr.
> The MITRE Corporation
> 202 Burlington Rd. MS S145
> Bedford, MA 01730
> [hidden email]
> 781-271-2615
>
> >-----Original Message-----
> >From: C. Church [mailto:[hidden email]]
> >Sent: Tuesday, 22 January, 2008 10:26
> >To: cee-discussion-list CEE-Related Discussion
> >Subject: Re: [CEE-DISCUSSION-LIST] Draft Sensor Output
> >Specification for Technical Discussion
> >
> >All,
> >
> > Has anyone reviewed the latest syslog draft from the IETF?
> >The URL is:
> >http://www.ietf.org/internet-drafts/draft-ietf-syslog-protocol-23.txt
> >
> >Notably, they include the concept of "structured data."
> >(Section 6.3) Word
> >from our IETF members is that this may go through as the new
> >syslog standard
> >very soon.
> >
> >So, my question is: would creating an enterprise ID and
> >setting our expected
> >SD-IDs be sufficient?  Must we define an entirely new logging
> >standard to
> >compete with all of the others, and notably, with the IETF
> >standard that
> >will likely be adopted (over time) everywhere?  To be honest,
> >I'm not seeing
> >how the new syslog structured data section wouldn't be able to
> >provide the
> >hierarchy information we're looking for.  Our purpose could then be
> >distilled to defining a standardized set of SD-IDs for given types of
> >messages - and find that our results get adopted widely, and easily.
> >
> >
> >Christopher Church, Chief Architect
> >Alert Logic, Inc.
> >[hidden email]
> >
Reply | Threaded
Open this post in threaded view
|

Re: Draft Sensor Output Specification for Technical Discussion

John Calcote-2
Christopher,

Does this new IETF initiative have anything to do with the syslog
working group? The reason I asked is that I spent 6 months on that
mailing list, helping out where I could, and found that it was basically
going no where. They just kept arguing about silly little details, and
never got anything done. In fairness, the moderators seemed to know what
they were doing, but they kept having to put out flame wars initiated by
the other WG members. But because of these issues, they just never
seemed to come up with a spec that everyone could agree on. Perhaps
things have improved since I left the list in October.

As I left the group, I thought that the only way they were ever going to
get an updated syslog going was to start a new project that had
literally no dependencies on backward compatibility with the old syslog
service. They, they might have half a chance - the other half would have
to come from the community's willingness to switch over to another
system that might not be as prolific as syslog (yet).

John

C. Church wrote:

> Bill,
>
> That's excellent - I believe the next gathering for IETF is in March
> and I will probably be there with our representative (my boss) to discuss
> the impact and urgency of the new specification.  Noting that over 4,000
> companies have already reserved Enterprise IDs for the new spec, I have a
> good feeling that this RFC will be ratified.
>
>
> Christopher Church, Chief Architect
> Alert Logic, Inc.
> [hidden email]
>
>
>  
>> -----Original Message-----
>> From: Heinbockel, Bill [mailto:[hidden email]]
>> Sent: Friday, January 25, 2008 8:30 AM
>> To: [hidden email]
>> Subject: Re: [CEE-DISCUSSION-LIST] Draft Sensor Output Specification for
>> Technical Discussion
>>
>>
>> Thanks for the pointer Chris.
>>
>> I will follow-up and see what they are doing.
>> I imagine that this will at least address some
>> of the gap that CEE is aiming for.
>>
>> We can at least add some our input into the
>> IETF draft to get the some of this stuff fasttracked
>> into Syslog.
>>
>>
>>
>> William Heinbockel
>> Infosec Engineer, Sr.
>> The MITRE Corporation
>> 202 Burlington Rd. MS S145
>> Bedford, MA 01730
>> [hidden email]
>> 781-271-2615
>>
>>    
>>> -----Original Message-----
>>> From: C. Church [mailto:[hidden email]]
>>> Sent: Tuesday, 22 January, 2008 10:26
>>> To: cee-discussion-list CEE-Related Discussion
>>> Subject: Re: [CEE-DISCUSSION-LIST] Draft Sensor Output
>>> Specification for Technical Discussion
>>>
>>> All,
>>>
>>> Has anyone reviewed the latest syslog draft from the IETF?
>>> The URL is:
>>> http://www.ietf.org/internet-drafts/draft-ietf-syslog-protocol-23.txt
>>>
>>> Notably, they include the concept of "structured data."
>>> (Section 6.3) Word
>>>      
>> >from our IETF members is that this may go through as the new
>>    
>>> syslog standard
>>> very soon.
>>>
>>> So, my question is: would creating an enterprise ID and
>>> setting our expected
>>> SD-IDs be sufficient?  Must we define an entirely new logging
>>> standard to
>>> compete with all of the others, and notably, with the IETF
>>> standard that
>>> will likely be adopted (over time) everywhere?  To be honest,
>>> I'm not seeing
>>> how the new syslog structured data section wouldn't be able to
>>> provide the
>>> hierarchy information we're looking for.  Our purpose could then be
>>> distilled to defining a standardized set of SD-IDs for given types of
>>> messages - and find that our results get adopted widely, and easily.
>>>
>>>
>>> Christopher Church, Chief Architect
>>> Alert Logic, Inc.
>>> [hidden email]
>>>
>>>      
>
>  
Reply | Threaded
Open this post in threaded view
|

Re: Draft Sensor Output Specification for Technical Discussion

C. Church
John,
       
        If you mean the syslog WG of the IETF, then yes. The RFC was the
latest settled format, and that much has been agreed upon to this point, as
I understand.  

My suggestion was not so much that we jump over to the syslog WG and try to
hammer out a format with them, but to settle upon a set of well-defined
SD-IDs for use in whatever new format they come up with.  It appears that
they have left that completely up to producers and consumers of logs - which
we represent both.  I think that this may work better for our ends, as even
though the new syslog would take quite a while to make it to a formal spec,
and even longer to be implemented, we would be enhancing it rather than
competing with it.  

My largest concern is that we spend a lot of time and effort on building a
great system that almost no one ends up using, because the competing systems
are "good enough".  If we could create a taxonomy that could be utilized in
an easily adopted, or dare I say, every format that allows for structured
data, we would find a much higher adoption rate.

That is - developing a taxonomy that requires a specific data structure and
log format may be less important than developing the taxonomy as a guideline
for implementation in any format.  (Additionally, having defined the values
to use in a fairly standard logging format makes it clear how consumers and
producers should utilize it.)


Christopher Church, Chief Architect
Alert Logic, Inc.
[hidden email]


> -----Original Message-----
> From: John Calcote [mailto:[hidden email]]
> Sent: Friday, January 25, 2008 1:26 PM
> To: [hidden email]
> Subject: Re: [CEE-DISCUSSION-LIST] Draft Sensor Output Specification for
> Technical Discussion
>
> Christopher,
>
> Does this new IETF initiative have anything to do with the syslog
> working group? The reason I asked is that I spent 6 months on that
> mailing list, helping out where I could, and found that it was basically
> going no where. They just kept arguing about silly little details, and
> never got anything done. In fairness, the moderators seemed to know what
> they were doing, but they kept having to put out flame wars initiated by
> the other WG members. But because of these issues, they just never
> seemed to come up with a spec that everyone could agree on. Perhaps
> things have improved since I left the list in October.
>
> As I left the group, I thought that the only way they were ever going to
> get an updated syslog going was to start a new project that had
> literally no dependencies on backward compatibility with the old syslog
> service. They, they might have half a chance - the other half would have
> to come from the community's willingness to switch over to another
> system that might not be as prolific as syslog (yet).
>
> John
>
> C. Church wrote:
> > Bill,
> >
> > That's excellent - I believe the next gathering for IETF is in March
> > and I will probably be there with our representative (my boss) to
> discuss
> > the impact and urgency of the new specification.  Noting that over 4,000
> > companies have already reserved Enterprise IDs for the new spec, I have
> a
> > good feeling that this RFC will be ratified.
> >
> >
> > Christopher Church, Chief Architect
> > Alert Logic, Inc.
> > [hidden email]
> >
> >
> >
> >> -----Original Message-----
> >> From: Heinbockel, Bill [mailto:[hidden email]]
> >> Sent: Friday, January 25, 2008 8:30 AM
> >> To: [hidden email]
> >> Subject: Re: [CEE-DISCUSSION-LIST] Draft Sensor Output Specification
> for
> >> Technical Discussion
> >>
> >>
> >> Thanks for the pointer Chris.
> >>
> >> I will follow-up and see what they are doing.
> >> I imagine that this will at least address some
> >> of the gap that CEE is aiming for.
> >>
> >> We can at least add some our input into the
> >> IETF draft to get the some of this stuff fasttracked
> >> into Syslog.
> >>
> >>
> >>
> >> William Heinbockel
> >> Infosec Engineer, Sr.
> >> The MITRE Corporation
> >> 202 Burlington Rd. MS S145
> >> Bedford, MA 01730
> >> [hidden email]
> >> 781-271-2615
> >>
> >>
> >>> -----Original Message-----
> >>> From: C. Church [mailto:[hidden email]]
> >>> Sent: Tuesday, 22 January, 2008 10:26
> >>> To: cee-discussion-list CEE-Related Discussion
> >>> Subject: Re: [CEE-DISCUSSION-LIST] Draft Sensor Output
> >>> Specification for Technical Discussion
> >>>
> >>> All,
> >>>
> >>> Has anyone reviewed the latest syslog draft from the IETF?
> >>> The URL is:
> >>> http://www.ietf.org/internet-drafts/draft-ietf-syslog-protocol-23.txt
> >>>
> >>> Notably, they include the concept of "structured data."
> >>> (Section 6.3) Word
> >>>
> >> >from our IETF members is that this may go through as the new
> >>
> >>> syslog standard
> >>> very soon.
> >>>
> >>> So, my question is: would creating an enterprise ID and
> >>> setting our expected
> >>> SD-IDs be sufficient?  Must we define an entirely new logging
> >>> standard to
> >>> compete with all of the others, and notably, with the IETF
> >>> standard that
> >>> will likely be adopted (over time) everywhere?  To be honest,
> >>> I'm not seeing
> >>> how the new syslog structured data section wouldn't be able to
> >>> provide the
> >>> hierarchy information we're looking for.  Our purpose could then be
> >>> distilled to defining a standardized set of SD-IDs for given types of
> >>> messages - and find that our results get adopted widely, and easily.
> >>>
> >>>
> >>> Christopher Church, Chief Architect
> >>> Alert Logic, Inc.
> >>> [hidden email]
> >>>
> >>>
> >
> >
Reply | Threaded
Open this post in threaded view
|

Re: Draft Sensor Output Specification for Technical Discussion

David Corlette
Hi Chris,

To beat the same old drum again: have you looked at the XDAS standard? It defines a complete event structure and complete taxonomy, although if you feel either isn't quite complete enough they are also extensible.

http://www.opengroup.org/bookstore/catalog/p441.htm

I've been encouraging the CEE group to align with this existing standard, at least partially; there's no reason both couldn't be embedded in the syslog format as well.

>>> On Fri, Jan 25, 2008 at  2:44 PM, in message
<009e01c85f8a$c238ff60$[hidden email]>, "C. Church"
<[hidden email]> wrote:

> John,
>
> If you mean the syslog WG of the IETF, then yes. The RFC was the
> latest settled format, and that much has been agreed upon to this point, as
> I understand.  
>
> My suggestion was not so much that we jump over to the syslog WG and try to
> hammer out a format with them, but to settle upon a set of well-defined
> SD-IDs for use in whatever new format they come up with.  It appears that
> they have left that completely up to producers and consumers of logs - which
> we represent both.  I think that this may work better for our ends, as even
> though the new syslog would take quite a while to make it to a formal spec,
> and even longer to be implemented, we would be enhancing it rather than
> competing with it.  
>
> My largest concern is that we spend a lot of time and effort on building a
> great system that almost no one ends up using, because the competing systems
> are "good enough".  If we could create a taxonomy that could be utilized in
> an easily adopted, or dare I say, every format that allows for structured
> data, we would find a much higher adoption rate.
>
> That is - developing a taxonomy that requires a specific data structure and
> log format may be less important than developing the taxonomy as a guideline
> for implementation in any format.  (Additionally, having defined the values
> to use in a fairly standard logging format makes it clear how consumers and
> producers should utilize it.)
>
>
> Christopher Church, Chief Architect
> Alert Logic, Inc.
> [hidden email]
>
>
>> -----Original Message-----
>> From: John Calcote [mailto:[hidden email]]
>> Sent: Friday, January 25, 2008 1:26 PM
>> To: [hidden email]
>> Subject: Re: [CEE-DISCUSSION-LIST] Draft Sensor Output Specification for
>> Technical Discussion
>>
>> Christopher,
>>
>> Does this new IETF initiative have anything to do with the syslog
>> working group? The reason I asked is that I spent 6 months on that
>> mailing list, helping out where I could, and found that it was basically
>> going no where. They just kept arguing about silly little details, and
>> never got anything done. In fairness, the moderators seemed to know what
>> they were doing, but they kept having to put out flame wars initiated by
>> the other WG members. But because of these issues, they just never
>> seemed to come up with a spec that everyone could agree on. Perhaps
>> things have improved since I left the list in October.
>>
>> As I left the group, I thought that the only way they were ever going to
>> get an updated syslog going was to start a new project that had
>> literally no dependencies on backward compatibility with the old syslog
>> service. They, they might have half a chance - the other half would have
>> to come from the community's willingness to switch over to another
>> system that might not be as prolific as syslog (yet).
>>
>> John
>>
>> C. Church wrote:
>> > Bill,
>> >
>> > That's excellent - I believe the next gathering for IETF is in March
>> > and I will probably be there with our representative (my boss) to
>> discuss
>> > the impact and urgency of the new specification.  Noting that over 4,000
>> > companies have already reserved Enterprise IDs for the new spec, I have
>> a
>> > good feeling that this RFC will be ratified.
>> >
>> >
>> > Christopher Church, Chief Architect
>> > Alert Logic, Inc.
>> > [hidden email]
>> >
>> >
>> >
>> >> -----Original Message-----
>> >> From: Heinbockel, Bill [mailto:[hidden email]]
>> >> Sent: Friday, January 25, 2008 8:30 AM
>> >> To: [hidden email]
>> >> Subject: Re: [CEE-DISCUSSION-LIST] Draft Sensor Output Specification
>> for
>> >> Technical Discussion
>> >>
>> >>
>> >> Thanks for the pointer Chris.
>> >>
>> >> I will follow-up and see what they are doing.
>> >> I imagine that this will at least address some
>> >> of the gap that CEE is aiming for.
>> >>
>> >> We can at least add some our input into the
>> >> IETF draft to get the some of this stuff fasttracked
>> >> into Syslog.
>> >>
>> >>
>> >>
>> >> William Heinbockel
>> >> Infosec Engineer, Sr.
>> >> The MITRE Corporation
>> >> 202 Burlington Rd. MS S145
>> >> Bedford, MA 01730
>> >> [hidden email]
>> >> 781-271-2615
>> >>
>> >>
>> >>> -----Original Message-----
>> >>> From: C. Church [mailto:[hidden email]]
>> >>> Sent: Tuesday, 22 January, 2008 10:26
>> >>> To: cee-discussion-list CEE-Related Discussion
>> >>> Subject: Re: [CEE-DISCUSSION-LIST] Draft Sensor Output
>> >>> Specification for Technical Discussion
>> >>>
>> >>> All,
>> >>>
>> >>> Has anyone reviewed the latest syslog draft from the IETF?
>> >>> The URL is:
>> >>> http://www.ietf.org/internet-drafts/draft-ietf-syslog-protocol-23.txt
>> >>>
>> >>> Notably, they include the concept of "structured data."
>> >>> (Section 6.3) Word
>> >>>
>> >> >from our IETF members is that this may go through as the new
>> >>
>> >>> syslog standard
>> >>> very soon.
>> >>>
>> >>> So, my question is: would creating an enterprise ID and
>> >>> setting our expected
>> >>> SD-IDs be sufficient?  Must we define an entirely new logging
>> >>> standard to
>> >>> compete with all of the others, and notably, with the IETF
>> >>> standard that
>> >>> will likely be adopted (over time) everywhere?  To be honest,
>> >>> I'm not seeing
>> >>> how the new syslog structured data section wouldn't be able to
>> >>> provide the
>> >>> hierarchy information we're looking for.  Our purpose could then be
>> >>> distilled to defining a standardized set of SD-IDs for given types of
>> >>> messages - and find that our results get adopted widely, and easily.
>> >>>
>> >>>
>> >>> Christopher Church, Chief Architect
>> >>> Alert Logic, Inc.
>> >>> [hidden email]
>> >>>
>> >>>
>> >
>> >
Reply | Threaded
Open this post in threaded view
|

Re: Draft Sensor Output Specification for Technical Discussion

Mordechai T. Abzug
In reply to this post by C. Church
On Fri, Jan 25, 2008 at 01:13:16PM -0600, C. Church wrote:

> That's excellent - I believe the next gathering for IETF is in
> March and I will probably be there with our representative (my boss)
> to discuss the impact and urgency of the new specification.  Noting
> that over 4,000 companies have already reserved Enterprise IDs for
> the new spec, I have a good feeling that this RFC will be ratified.

[going back through older email.]

If you mean the enterprise IDs referenced in the IETF syslog draft,
these are the IANA private enterprise numbers.  There are over 30,000
registrants right now.

The private enterprise numbers have long been used for other
protocols, such as SNMP, LDAP, and RADIUS.  syslog is leveraging this
pre-existing registry.  So, because private enterprise numbers are
already used for other purposes, their adoption rate doesn't tell you
anything about the success of this particular effort.

- Morty