As we get communities to implement 2.1 and start exchanging objects, we will learn a ton about exactly what people and systems need. We can use this experience to inform our thinking post 2.1
From: <firstname.lastname@example.org> on behalf of Bret Jordan <Bret_Jordan@symantec.com>
Date: Tuesday, October 3, 2017 at 9:47 PM
To: Sean Barnum <sean.barnum@FireEye.com>
Cc: "Kirillov, Ivan A." <email@example.com>, Sarah Kelley <Sarah.Kelley@cisecurity.org>, "Wunder, John A." <firstname.lastname@example.org>, "email@example.com" <firstname.lastname@example.org>
Subject: [cti-stix] Re: [EXT] Re: [cti-stix] Grouping SDO Open Questions
My concern with #1 is that we probably need a way of asserting if something has been verified and validated and tested and etc to all objects, not just this grouping.
If we designed the classification object or common properties right, this could solve a lot of problems.
- I agree that it is currently unclear how Classification Object would appropriately support validation information. I would support leaving it alone for now.
- I believe we should keep Grouping and Report as separate objects.
- To clarify, the suggestion is that “context” would be an open vocabulary not simply another open string like description. This would help improve consistency
for common contexts but also enable the _expression_ of more custom or esoteric contexts. Given this and with a clear definition for the “context” property I do not believe it should be confusing. I would disagree with changing the description for “description”
to specify it should be used for constructive rather than informative purposes. I think that would be a very major change to the way description has been envisioned and is very likely to be used. We continue to assert that this explicit context property is
necessary for the practical usefulness of Grouping objects for collaborative intel sharing/evolution.
- I’m with Sarah on this one – as the Classification Object currently stands, it’s unclear how it would capture validation information. Also, I’m wary of adding
yet another SDO for something so simple.
- I think we’ve debated this one enough, and it stands that there are good reasons for having a separate Report vs. Grouping.
- In my opinion, Description and Context are way too similar semantically and it would be confusing for end-users to figure out which to use for what purpose.
I think we can simply update the text for Description to explain that it should also be used for constructive purposes, with a few examples.
I think the Grouping object looks fairly good. My thoughts:
- The classification object is currently being discussed as a way to convey risk. This doesn’t seem to align (currently) with if the data is ‘validated’ or not.
I would say leave it alone for now, but if the classification proposal changes in the future, we can revisit this decision.
- I think we’ve already agreed they should be separate, once we make that call, we shouldn’t reopen it unless there is a VERY good reason to do so
- I can understand with the desire for the shared context field, but I agree with John. I think people won’t know when to use which and it will be confusing.
Plus, what would you put in the description of a grouping if not the description of why you made the group (aka the context)?
<image002.png> <image003.png> <image004.png> <image005.png>
I wanted to get the Grouping SDO out there for another round of reviews. To remind everyone, this is an SDO similar to Report but targeted less at finished reports that you would publish as a PDF and more
at ad-hoc collections/groupings of intelligence that may not even be fully validated. This was a use case initially requested by MISP, then supported by FireEye.
I believe we’re approaching consensus on a few discussion topics:
- Most people feel that Grouping should be a separate SDO from Report, based on the idea that they’re used differently.
- People seemed mostly amenable to adding some kind of label to indicate whether the information in the Grouping had been fully validated (this was initially
discussed as “automatable”, but we moved to “validated” because it described what the producer meant rather than what the consumer should do).
There are still a few open questions:
- Jason has brought up the idea of using his risk scoring classifications to track whether the information is validated. Proposal is here:
- Bret brought up that if we end up doing that, we may want to go back to merging Grouping into Report
- Sean has suggested adding a required “context” field, separate from description. This would track the shared context in the referenced grouping. Sean’s comment:
“I do not believe that the description property is adequate for this purpose. The description property is used almost exclusively for informative expository purposes (e.g. to be presented in a UI) but is not used for constructive purposes. Given the purpose
of this object to convey a set of content with a shared context, it should require a statement of what that shared context is.
Please let us know what you think about those open questions.
- Maybe, though I worry that the “Classification” object would create a lot of markup if it ends up as a separate SDO…it would require like 10-20 lines of markup
and 1-2 separate objects just to add the label, which seems bulky. IMO we should conditionally go with the label for now, discuss the risk proposal, and if we end up doing it and eventually arrive at something that conveys the same thing we can revert to that.
But I don’t think the classifications proposal as-is is really workable.
- While I can see how the classification proposal might change the need for the label indicating “unverified”, I don’t think we should revisit the Grouping vs.
Report discussion based on representing whether information has been validated differently. And I say that having been one of the people that originally said they should be one SDO.
- I think I can see the conceptual distinction here, but in practice I don’t know how people will know when to use one field (description) vs. the other (context).
It would become one of those cases where we create a subtle distinction and end up having “two ways of doing something”. I do see Sean’s point though that you need to represent the context for why you’re grouping these things, and therefore I’d suggest that
we just update the description of the description property to make it clearer that you should include why the things are related there. I would also be open to renaming it and/or making it required, but feel pretty strongly that having both “description” and
“context” will just confuse people.
This message and attachments may contain confidential information. If it appears that this message was sent to you by mistake, any retention, dissemination, distribution or copying of this message and attachments
is strictly prohibited. Please notify the sender immediately and permanently delete the message and any attachments.
. . . . .
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.