Re: [cti-stix] Updated report proposal

["Wunder, John A." <jwunder@mitre.org>]

All, I wanted to re-up this since we just discussed it on the working call. The proposal is here: https://docs.google.com/document/d/15qD9KBQcVcY4FlG9n_VGhqacaeiLlNcQ7zVEjc8I3b4/edit#heading=h.y3otj21tnvuj

 

As a reminder, this topic is meant to address a need MISP brought up to share collections of threat intelligence (they call them “Events”) that are not at the level of a published report but need to be shared as a cohesive set with some shared context (title, description, labels, etc.)

 

We still have three open questions:

 

1. Is doing this in the Report object the right approach, or do we need to add a new Grouping object? Consensus has been that we should do this in the Report object, though Sean in particular has pointed out that FireEye believes it should be separate (as he said below). Given previous consensus across two working calls here I think we can assume that we’ll do it in Report unless we get a lot of feedback saying otherwise.
2. Should we add a separate status property to capture the status of the report (as in the proposal now), or should we just use the labels property with pre-defined labels to enable automation. Consensus is mixed here, so please weigh in with your reasoning. MISP felt like to enable automation we needed a separate property, JMG and Bret pointed out that we’ve previously put values meant to enable automation in labels.
3. What values should go in that status vocabulary, regardless of which property we end up putting it in? Right now we have a proposal from Allan Thomson for “initial-analysis”, “updated-analysis”, “final”, and “finished-product”. Are these correct? What new/changed values should there be?

 

I think we’re VERY close to finally figuring this one out, so please let us know what you think. My opinions are:

 

1. Do it in Report.
2. Honestly either way seems doable to me, but I lean towards a separate status field so you can easily separate out the status values from other stuff you might put into report labels.
3. I would keep “initial-analysis”, “final”, “finished-product”. I would remove “updated-analysis” because I think you can capture that semantic with the modified property and a value of “initial-analysis” (maybe call them “working-analysis”, “final-analysis”, “finished-product”).

 

Thanks!

John

                                                                                                                                                                                                                                           

From: <cti-stix@lists.oasis-open.org> on behalf of John Wunder <jwunder@mitre.org>
Date: Monday, September 18, 2017 at 4:59 PM
To: Sean Barnum <sean.barnum@FireEye.com>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] Updated report proposal

 

Sorry about that…somewhat ironically, after there were problems with finding all of the stuff we were working on, I moved it over to the Working Concepts doc later last week: https://docs.google.com/document/d/15qD9KBQcVcY4FlG9n_VGhqacaeiLlNcQ7zVEjc8I3b4/edit#heading=h.y3otj21tnvuj

 

John

 

From: Sean Barnum <sean.barnum@FireEye.com>
Date: Monday, September 18, 2017 at 4:56 PM
To: John Wunder <jwunder@mitre.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] Updated report proposal

 

I don’t see any proposal in the linked doc.

 

I would object to attempts to conflate these two objects together. I believe I have given clear reasoning for this position in the past.

 

Sean Barnum

Principal Architect

FireEye

M: 703.473.8262

E: sean.barnum@fireeye.com

 

From: <cti-stix@lists.oasis-open.org> on behalf of "Wunder, John A." <jwunder@mitre.org>
Date: Tuesday, September 12, 2017 at 8:36 AM
To: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: [cti-stix] Updated report proposal

 

All,

 

As I mentioned in an e-mail yesterday, based on the straw poll that we had on the August 29 working call (notes here: https://www.oasis-open.org/committees/download.php/61462/OASIS-CTI-TC_WorkingSession_August29_2017.pdf) I put together a proposal to modify the report object to cover the concept of an evolving collection of content (i.e., the MISP use case).

 

Proposal is here: https://docs.google.com/document/d/1wiG6RoNEFaE2lrblfgjpu3RTAJZOK2q0b5OxXCaCV14/edit#heading=h.n8bjzg1ysgdq

 

The changes are:

1. The description of the Report object was modified slightly to remove the reference to it being “published”. There were also some additional examples added.
2. The published property was made optional, to allow for cases where the report is not yet published.
3. A new status property was added, based on a suggestion from Allan that what we were describing as “published” or “not published” was not really a binary flag. The vocabulary is still somewhat TBD, right now I just put “ongoing-analysis” and “final” in as placeholders.

 

On the call most folks seemed to think that the best option was to modify the Report object, but we did have a couple open questions:

 

1. Now that you’ve seen the proposal, does this general approach seem acceptable?
2. What are the possible values in the “status” vocabulary? The thought on the call was that there were more than two, but I couldn’t think of anything and I asked on Slack and didn’t get anything either.

 

Thanks,

John

This email and any attachments thereto may contain private, confidential, and/or privileged material for the sole use of the intended recipient. Any review, copying, or distribution of this email (or any attachments thereto) by others is strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto.