RE: [cti-stix] Grouping SDO Open Questions

["Katz, Gary CTR DC3\\DCCI" <Gary.Katz.ctr@dc3.mil>]

Intrusion Sets have a specific meaning within the cyber intelligence community.  Part of the reason why I asked for examples of the context field for groups is so we know how they will be used which would give us an understanding of the use cases.  I have selfish reasons for this (since I’m one of the people that pushed heavily for intrusion set) but similar to our discussion earlier today, we’ve already made a decision on the Intrusion Set object, I would suggest we do not reopen it.

 

In more general terms though, we are trying to get a community (cyber intel analysts) to accept a model that we created for how to perform their job.  I would suggest as much as possible that we use their terminology. 

 

Looking at the example in the STIX specification for groupings though,

“For example, a threat analyst might create a Grouping to contain references to a series of Campaigns and Indicators that they are currently doing some analysis on and that they wish to collaborate with others on.”

I can understand Terry’s question, because that example IS an intrusion set.  If FireEye is planning to use Grouping to share information on something like their APT1 APT12, etc. Intrusion Sets, I would suggest that they just use the Intrusion Set object.  If they are planning to use it for a different purpose, we should examine those examples.

 

I’ll go the opposite way as Sean in saying, I’m not arguing we remove Groupings, but I would certainly resist any suggestions on not including Intrusion Set simply because we are creating a grouping SDO. ;)

 

From: cti-stix@lists.oasis-open.org [mailto:cti-stix@lists.oasis-open.org] On Behalf Of Sean Barnum
Sent: Tuesday, October 3, 2017 3:54 PM
To: Terry MacDonald <terry.macdonald@cosive.com>; John A. Wunder <jwunder@mitre.org>
Cc: cti-stix@lists.oasis-open.org
Subject: [Non-DoD Source] Re: [cti-stix] Grouping SDO Open Questions

 

An intrusion set is a set of intel content that is all believed to share a common attribution.

 

Grouping is MUCH more general than that. It can be any set of content sharing any sort of context.

 

I would consider an intrusion set to be a subset situation of a grouping where the context is shared attribution.

 

I think IntrusionSet makes sense to have separately as it is a specific concept/construct that is fundamental to the CTI domain.

That being said, if we absolutely had to choose either one object or the other I would suggest we should choose Grouping as it allows the intrusion set use case and a ton of other important use cases where IntrusionSet would allow only the one use case and none of the other general ones.

Again, I am not arguing we remove IntrusionSet but I would certainly resist any suggestions of not including Grouping simply because IntrusionSet already exists.

 

Sean Barnum

Principal Architect

FireEye

M: 703.473.8262

E: sean.barnum@fireeye.com

 

From: <cti-stix@lists.oasis-open.org> on behalf of Terry MacDonald <terry.macdonald@cosive.com>
Date: Tuesday, October 3, 2017 at 3:27 PM
To: "John A. Wunder" <jwunder@mitre.org>
Cc: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] Grouping SDO Open Questions

 

Hi John,

 

"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."

 

How is this different from the concept of the Intrusion-set? And how will consumers differentiate between an intrusion-set, a report and a grouping object?

 

Cheers

Terry MacDonald

Cosive

 

On 4/10/2017 03:32, "Wunder, John A." <jwunder@mitre.org> wrote:

Hey all,

 

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:

1. Jason has brought up the idea of using his risk scoring classifications to track whether the information is validated. Proposal is here: https://docs.google.com/document/d/1wiG6RoNEFaE2lrblfgjpu3RTAJZOK2q0b5OxXCaCV14/edit#heading=h.snfvxw2o7p1u
2. Bret brought up that if we end up doing that, we may want to go back to merging Grouping into Report
3. 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.

 

https://docs.google.com/document/d/15qD9KBQcVcY4FlG9n_VGhqacaeiLlNcQ7zVEjc8I3b4/edit#heading=h.t56pn7elv6u7

 

Please let us know what you think about those open questions.

 

My opinions:

 

1. 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.
2. 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.
3. 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.

 

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.

Attachment: smime.p7s
Description: S/MIME cryptographic signature