Quantcast

Update on CEE - leadership, 1.0-beta, and flat vs. hierarchical field names

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

Update on CEE - leadership, 1.0-beta, and flat vs. hierarchical field names

Wunder, John A.

Hey everyone,

 

Just wanted to give you a quick update on CEE and what the CEE Board has been working on. Things have been a little quiet lately but don’t worry, it’s still moving forward.

 

First of all, as you probably know MITRE has been facilitating development of CEE by running the mailing lists, hosting calls, and publishing the specifications. Bill Heinbockel, the lead of the project at MITRE, recently moved on to a new position and I’ve been brought on as his  replacement. So…hi. Over the past few weeks I’ve been introducing myself to the board and figuring out where CEE is headed. As a side note, I’ll be at the MITRE “Making Security Measurable” booth at BlackHat this week representing CEE so feel free to stop by and say hi, I definitely want to meet you all in person if you’re there.

 

Second, when Bill left he had a new version of CEE, 1.0-beta, almost ready for release. Since I started I’ve been working with the board on finalizing that and getting it ready for release. The board suggested a few changes to the specifications and the schemas that I’m still implementing (related to making sure the taxonomy was included). When that’s done though I plan to bundle it all up and send it to you and get it posted on the website. So that will be coming shortly.

 

Finally, separate from a 1.0-beta release the CEE Board talked about how to formally resolve issues that have been floating around for a long time so we can stop spending time on them. Our conclusion was that we would propose an issue to the CEE discussion list and have a fixed two week voting and discussion period. Each person (not each organization, each person) would get only one vote but could discuss the issue as much as they wanted. Once the time period was over the CEE Board would weigh the votes and publish the decision...it wouldn’t necessarily be “majority rules”, instead the CEE Board would balance organizational and industry votes to make sure that one org or industry doesn’t outweigh everyone else. The changes would then be incorporated into the next CEE release.

 

The first issue we wanted to bring up was the idea of flat vs. hierarchical field names….basically whether or not the field dictionary would support an object structure or whether it would be flat keys and values. I see three options here:

 

1.       Only flat names, no object hierarchy. In this case, source IP address might be represented as “source_ip_address” in the JSON and XML

2.       Allow hierarchical names, require structured representations. In this case, source IP address would be represented as {“source”: {“ip_address”: “…”}} in the JSON and <source><ip_address></ip_address></source> in the XML.

3.       Allow hierarchical names but support a flat representation. In this case, the source IP could be represented EITHER as “source.ip_address” OR as the structured name. Basically there would be a conceptual hierarchy but at a syntax level it could be represented in a flat field list. I would call this a subset of hierarchical because it really is conceptually identical to a hierarchy.

 

If you strongly support one of these viewpoints can you e-mail me separately ([hidden email])? What I want to do is put together a detailed writeup of each of the three positions to kick off discussion, so I need someone who supports each option to write something up. Then once I have that writeup I’ll send out a separate e-mail that will start the two-week voting/discussion period.

 

Thanks,

John Wunder

MITRE

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

Re: Update on CEE - leadership, 1.0-beta, and flat vs. hierarchical field names

Anton Chuvakin

 

1.       Only flat names, no object hierarchy. In this case, source IP address might be represented as “source_ip_address” in the JSON and XML



2.       Allow hierarchical names, require structured representations. In this case, source IP address would be represented as {“source”: {“ip_address”: “…”}} in the JSON and <source><ip_address></ip_address></source> in the XML.


Isn't the an option to only allow hierarchical names for select few fields where it is really, really needed? Otherwise, I am afraid that the complexity will kill it. If we cannot do that, I'd vote for FLAT. JSON/plain text is expected to be used more than XML and so cluttering it with hierarchy is not healthy.
 

3.       Allow hierarchical names but support a flat representation. In this case, the source IP could be represented EITHER as “source.ip_address” OR as the structured name. Basically there would be a conceptual hierarchy but at a syntax level it could be represented in a flat field list. I would call this a subset of hierarchical because it really is conceptually identical to a hierarchy.


My 2nd choice would be that, I guess, but hopefully limited to a few fields only.

Summary: complexity -> lack of adoption.

--
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: Update on CEE - leadership, 1.0-beta, and flat vs. hierarchical field names

George Saylor



On Jul 24, 2012, at 11:10 AM, Anton Chuvakin <[hidden email]> wrote:

 

1.       Only flat names, no object hierarchy. In this case, source IP address might be represented as “source_ip_address” in the JSON and XML



2.       Allow hierarchical names, require structured representations. In this case, source IP address would be represented as {“source”: {“ip_address”: “…”}} in the JSON and <source><ip_address></ip_address></source> in the XML.


Isn't the an option to only allow hierarchical names for select few fields where it is really, really needed? Otherwise, I am afraid that the complexity will kill it. If we cannot do that, I'd vote for FLAT. JSON/plain text is expected to be used more than XML and so cluttering it with hierarchy is not healthy.

Agreed, there are a precious few things that might need this and any extra is likely a barrier to adoption.  IP addressing is one.  Potentially entities in LDAP and X509 are candidates,  if we can get away with flat it would be better IMO.  
 

3.       Allow hierarchical names but support a flat representation. In this case, the source IP could be represented EITHER as “source.ip_address” OR as the structured name. Basically there would be a conceptual hierarchy but at a syntax level it could be represented in a flat field list. I would call this a subset of hierarchical because it really is conceptually identical to a hierarchy.


My 2nd choice would be that, I guess, but hopefully limited to a few fields only.

Summary: complexity -> lack of adoption.

+1....judiciously consider any hierarchical representation.

--
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: Update on CEE - leadership, 1.0-beta, and flat vs. hierarchical field names

Balazs VAMOS
In reply to this post by Wunder, John A.
Hi John and welcome!

We at LOGalyze would like to fully support CEE format.

As I see the hierarchical field representation is only useful when we
would like to show the hierarchy. For storing, indexing, retrieving the
data, we prefer flat field names.
So if I had a vote, I would vote for #1.


Regards,

Balazs Vamos
LOGalyze


On 07/23/2012 08:56 PM, Wunder, John A. wrote:

>
> The first issue we wanted to bring up was the idea of flat vs.
> hierarchical field names….basically whether or not the field
> dictionary would support an object structure or whether it would be
> flat keys and values. I see three options here:
>
> 1.Only flat names, no object hierarchy. In this case, source IP
> address might be represented as “source_ip_address” in the JSON and XML
>
> 2.Allow hierarchical names, require structured representations. In
> this case, source IP address would be represented as {“source”:
> {“ip_address”: “…”}} in the JSON and
> <source><ip_address></ip_address></source> in the XML.
>
> 3.Allow hierarchical names but support a flat representation. In this
> case, the source IP could be represented EITHER as “source.ip_address”
> OR as the structured name. Basically there would be a conceptual
> hierarchy but at a syntax level it could be represented in a flat
> field list. I would call this a subset of hierarchical because it
> really is conceptually identical to a hierarchy.
>
> If you strongly support one of these viewpoints can you e-mail me
> separately ([hidden email])? What I want to do is put together a
> detailed writeup of each of the three positions to kick off
> discussion, so I need someone who supports each option to write
> something up. Then once I have that writeup I’ll send out a separate
> e-mail that will start the two-week voting/discussion period.
>
> Thanks,
>
> John Wunder
>
> MITRE
>
Loading...