[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: Initial stab at grouping-context-ov values based on real-world use cases
|
Comments inline below trying to explain the intent/use of Grouping as it differs from first-order domain object relationships.
My comments are very brief and may be inadequate to explain the issue. Unfortunately, I do not have the cycles currently to provide a full explanation with scenario breakdowns and examples. It is also likely unnecessary at this time as the intent of the below list was not to force all listed values (especially the second and third sets) to be included. I was asked to come up with a list
of values based on real-world experience to act as a starting point for our discussion and that is what the list below represents. The entire purpose of breaking the proposed list into three sets was to convey that the “common case” values were not necessarily understood by the TC today and do not have consensus and that this is
even more true of the third set of values. The initial stab proposal was to use the first set of values for now and to get people’s thoughts on whether or not to include the second set of values. I think it is clear from your comments and those of others that
we should not include the second or third set of values at this time. We are perfectly fine with that. Keeping the initial values to a minimum does not preclude us from using “open” values needed for our use cases. We can let real-world use drive expansion of the vocab. Sean Barnum Principal Architect FireEye M: 703.473.8262 E: sean.barnum@fireeye.com From: "Katz, Gary CTR DC3\DCCI" <Gary.Katz.ctr@dc3.mil> Hey Sean, I’ve been thinking about your proposal these last couple of days and had some comments I wished to share. I’m interested in if I am thinking about this incorrectly or if there are others
that have a similar view. In your email you state that the ‘Grouping object is to convey a specific set of STIX content shares some context.’ In my view, the fact that STIX content shares some context should be shown
through the relationship links that the content has to other content. i.e. If you are trying to show Malware analysis relationships, we have a malware analysis object and we have observable data that can be linked. Do we need a grouping object to further
connect it all together? Don’t the relationships in of themselves show that grouping? Similarly an objects-relationships grouping would just be shown by sending the core object, related objects and the links between them, we don’t need another object to
then encapsulate that information. Threat-actor-content, campaign-content, intrusion-set-content can all be explained similarly, just send the threat-actor, campaign, or intrusion-set, related objects and relationships and we’re good.
[sean] >> “we don’t need another object to then encapsulate that information” Let me start by clarifying that Grouping is NOT about encapsulation. It is not containing the content. That is done with Bundle. Grouping is a separate assertion of context against a set
of other content objects conveyed by references to their identifiers not by embedding their content. The intent of Grouping is not to assert (or duplicate the assertion of) the first-order relationships between objects such as that a particular file hash is a characteristic of an instance
of a particular malware. Those first-order relationships are asserted between existing domain objects as you describe. The Grouping provides a contextual hint of the relationship between content where first-order relationships may not exist or where a set
of content contains underlying first-order (or deeper) relationships but you don’t want to force the consumer to have to do a deep analysis to figure out how it is all related. For the “common case” values below, it is a contextual hint where content does
not necessarily all share first-order relationships to a domain object that is the locus of context for the grouping. In exchange of a large body of related content, how does a consumer know what all of the content is (what the relevance of that set of content is)? In order to “know” (really guess) that
all of the content is related you would have to identify, walk and interpret many relationships (embedded and separate; and potentially at several orders of depth) to put the clues together around what context the content shares. With Grouping the producer
can make it much easier for the consumer by explicitly asserting the shared context. There is also the question of how to know if the set of content with shared context is complete if all you have are the pieces and not the contextual frame. Grouping may refer to content
transmitted along with the Grouping but also may refer to other content either previously transmitted (the producer and consumer (tool-to-tool or suborg-to-suborg) may also be operating against the same repository of intel), still yet untransmitted, or known
to the producer but not produced by the producer. In such cases, again, how do you know the set is complete or what context it shares if you must implicitly deduce it from only the (potentially incomplete) content itself? I will not belabor the point further at this time as it does not really need to be fully understood or settled for v2.1 but I can assert with very high confidence that the ability to express
contextual groupings like this is fundamental to real-world effective CTI. In my view this is a key distinction between the suspicious-activity-event and the other grouping types. For the other grouping types, we have ways to relate the data together, either through
a malware object, an intrusion set object, a campaign object, threat actor object, etc. In the case of the suspicious-activity-event, that IS the object to provide context and relate that data together.
[sean] See above comments Interested in everyone’s thoughts, -Gary From: cti-stix@lists.oasis-open.org [mailto:cti-stix@lists.oasis-open.org]
On Behalf Of Sean Barnum A couple of weeks ago on the working call I took an action item to provide an initial minimal stab at grouping-context-ov values based on real-world use cases. I got busy and did not follow through. So, at the F2F last week we had a small side discussion where I provided an initial minimal stab at grouping-context-ov values based on real-world use cases that we see and then we discussed which ones we
might have consensus on as a small initial set, which ones might make longer term sense but not have consensus for an initial set and which ones might be considered a bit more esoteric and considerable for future versions if real-world use proved out their
value. To reiterate for clarity, the purpose of the Grouping object is to convey that a specific set of STIX content shares some context.
It is not intended to be the first choice for sharing any set of related STIX content and is not intended to replace CTI domain-relevant objects.
It is the generalized last resort for specifying this sort of thing when there is no STIX domain-relevant object already available for the given type of context (e.g. STIX content that describes the structure
or behavior of a piece of malware would utilize the Malware object, STIX content that characterizes details of infrastructure would utilize the Infrastructure object, etc). The context property of the Grouping object is intended to convey the nature of context that the referenced content shares.
The intent of the grouping-context-ov is to provide consistently defined values for common cases of Grouping context while also leaving open the option of specifying values not defined by the standard. Values of grouping-context-ov fall below the threshold required (at least for now) for defining a new SDO for that sort of context but above the threshold for uncommon or highly specialized forms of grouping
context. Here is the initial stab that resulted from the discussion at the F2F:
A set of STIX content related to a particular suspicious activity event.
(Answers question: what do we know about what happened in this suspicious activity/attack?)
A set of STIX Sightings for a given Indicator.
(Answers question: what sightings are known for this indicator?)
A set of STIX objects related to a given object along with any relevant Relationship objects.
(Answers question: what objects are related to this specific object (embedded/external relationship from this object, embedded/external relationship to this object)?)
A set of STIX content from a malware analysis action (sandbox execution, structural analysis, etc).
A set of STIX content related to a given Malware object. **It should be noted that this is not details of the malware which would
be conveyed in a Malware object but rather other STIX content related to the Malware object
A set of STIX content related to a given ThreatActor object. **It should be noted that this is not details of the threat actor which
would be conveyed in a ThreatActor object but rather other STIX content related to the ThreatActor object
A set of STIX content related to a given Campaign object. **It should be noted that this is not details of the campaign which
would be conveyed in a Campaign object but rather other STIX content related to the Campaign object
A set of STIX content related to a given IntrusionSet object. **It should be noted that this is not details of the intrusion set which
would be conveyed in a IntrusionSet object but rather other STIX content related to the IntrusionSet object
A set of STIX content related to a given Identity object. **It should be noted that this is not details of the identity which
would be conveyed in an Identity object but rather other STIX content related to the Identity object
A set of STIX content related to a given Location object. **It should be noted that this is not details of the location which
would be conveyed in a Location object but rather other STIX content related to the Location object
A set of STIX content related to a given Tool object. **It should be noted that this is not details of the tool which
would be conveyed in a Tool object but rather other STIX content related to the Tool object
A set of STIX content related to a given Vulnerability object. **It should be noted that this is not details of the vulnerability which
would be conveyed in a Vulnerability object but rather other STIX content related to the Vulnerability object
A set of STIX content related to a given Observable object. **It should be noted that this is not details of the observable which
would be conveyed in an Observable object but rather other STIX content related to the Observable object
A set of STIX activity content that occurred within a given time window
A set of STIX content created within a given time window
A set of STIX content that matches a specific selector pattern
Please feel free to offer your thoughts. Do you disagree with including any of these values? Do you think that we should start with only the suggested values? Do you think we should also include any/all of the “common case” or “outlier” values? Sean Barnum Principal Architect FireEye M: 703.473.8262 E: sean.barnum@fireeye.com 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.
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]