[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [cti] Kinds of Sources
|
Report and Package are two different use cases. One is about contextual correlation and the other is about provenance.
You are correct that Report is for expressing some correlation between a set of objects based on some explicit shared context (“intent”).
The use case I was describing below is not that use case.
The use case of maintaining linkages between content and the Packages it was seen in is a provenance use case not an analysis context use case.
This is an area where we have heard different intended implementation approaches from different members of the community.
Some have clearly expressed that they will treat Packages as pure envelopes, pull out the content and throw away the Package.
Others have expressed that they will pull out the content but also keep the Package itself around as a useful element of provenance.
I would suggest that neither approach is wrong. Different users and communities view the value of various content differently.
Supporting the latter approach places no requirement on the users of the former approach to support this operationally.
Those taking the former approach would not care about the example scenario I in the thread below.
Those taking the latter approach would care.
Does that make sense?
sean
From: Rich Piazza <rpiazza@mitre.org>
Date: Monday, February 8, 2016 at 10:41 AM To: "Barnum, Sean D." <sbarnum@mitre.org>, "ppatrick@isightpartners.com" <ppatrick@isightpartners.com> Cc: John Wunder <jwunder@mitre.org>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org> Subject: RE: [cti] Kinds of Sources I understand your use case, but I wasn’t expecting that we needed to support it, given the introduction of Report object. If you want to talk about TLOs that have are grouped together for some “intent”, use the Report. My impression of a Package, going forward, was just a container
to hold a group of objects – like a non-descript cardboard box filled with TLOs. From: Barnum, Sean D.
Rich, on your comment below, you are correct that Packages do contain EMBEDDED STIX objects. I was referring to situations where after receiving a Package you may want to break out objects from the Package they were received in
but wish to maintain the fact that they were contained in that package. You receive: Package A
Indicator 1 You break out the Indicator and keep the Package for provenance (with the relationship fact that the Indicator was contained in the Package)
so in your system you have: Package A
Indicator 1 Indicator 1 Relationship 1 from Indicator 1 to Package A with nature=“Contained_In" You later send: Package B
Indicator 1
Relationship 1 from Indicator 1 to Package A with nature=“Contained_In” That was the basic case I was referring to. Does that make sense? sean From:
Rich Piazza <rpiazza@mitre.org> Looks good. Minor comment below: From: Barnum, Sean D.
So, after thinking on this and talking through it with a couple of people here is where I have landed. I agree with Rich that it makes sense to identify the various use cases and forms of “sources” in order to determine the best way to capture and relate
them to content that they are the source for. I took the use cases Rich had, added a bit more and then analyzed and reorganized them a bit. What I came away with is an initial breakdown of sources external to STIX and sources internal to STIX:
·
sources external to STIX
·
sources internal to STIX The sources internal to STIX are really STIX objects from which another STIX object was abstracted
or generated. An obvious example would be content contained within a Package but many others are also likely. I’m confused by this – I thought a package contained EMBEDDED STIX objects. Maybe that is why you say it is “obvious”? Maybe you were
thinking Report? The sources external to STIX then broke down into the who or what the content came from (person, organization or system) and representations of similar information
external to STIX (references). So at this point:
·
sources external to STIX
o
Person, organization or system
o
Representation of similar information external to STIX
·
sources internal to STIX
o
STIX objects from which another STIX object was abstracted or generated
§
Obvious example would be Package but others are also possible External sources of person, organization or system then broke down into various roles these sorts of sources play including:
·
producer (who created the actual STIX content)
·
original source of the thinking
·
original source of the content (structured or unstructured capture)
·
any translation/transformation steps along the way
·
anonymizer
·
reviewer
·
transmitter (who was the STIX content received from) Similarly, the external representations of similar information external to STIX broke down into
·
general references - simple URLs to documents, blog posts, web pages, etc.
·
Identifier specific references - external resource that has a specific identifier (would need both the identifier and the defining context for the identifier) So at this point:
·
sources external to STIX
o
Person, organization or system
§
producer (who created the actual STIX content)
§
original source of the thinking
§
original source of the content (structured or unstructured capture)
§
any translation/transformation steps along the way
§
anonymizer
§
reviewer
§
transmitter (who was the STIX content received from)
o
Representation of similar information external to STIX
§
general references - simple URLs to documents, blog posts, web pages, etc.
§
Identifier specific references - external resource that has a specific identifier (would need both the identifier and the defining context for the identifier)
·
sources internal to STIX
o
STIX objects from which another STIX object was abstracted or generated
§
Obvious example would be Package but others are also possible I think this gives a pretty good overview of the types of sources we should support. I then took a look across this thinking about the most appropriate way to represent these. InformationSource in 1.2 currently captures identity information, tool information and references dealing with where the information came from and how
it was generated. The abstraction of a separate Source object was really primarily focused on the identity portion of this and how to handle the other (tool and reference)
dimensions was a remaining open question. The breakdown above was beneficial in clarifying this issue and even how it was related to the external_id question. Here is what I propose:
·
Remove the new Source object from the picture and simply utilize a top level Identity object as identity is really what the intent was focused on. This also offers the foundation for the primary
topic of discussion for next week (identity-based objects like Source, Victim, Actor, etc.)
·
Add a new Tool top level object based on ToolInformationType. This offers a basis for use here within information
source but also for malicious tool as a TTP and potentially for use with COA.
·
Add a new Reference top level object for capturing general and identifier specific references. Object would have the following properties:
·
Define a specific Has Source relationship with an extra Roles (required)(1..*) property with the following draft list of valid values:
o
Producer
Analysis Originator
Codification Originator
Translator
Transformer
Anonymizer
Reviewer
Transmitter
Derivation Resource
·
Relate STIX content to instances of Identity, Tool or Reference as appropriate to convey sources utilizing the Has Source relationship.
·
Relate STIX content to other STIX content using the Relationship object and various other relationship nature values (Derived_From, Abstracted_From, etc.) For now we move forward with an approach that also requires a “created_by_ref” property on all top level objects specifying the “producer” source of the object. It is non-ideal that
the producer could potentially be specified both by the embedded ref and by an explicit relationship but this would be perfectly valid anyway if we chose the embedded approach and taking this hybrid path enables all parties. Those wishing to only embed the
producer ref may do so. Those wishing for consistency in relationships may utilize an additional Has Source relationship with Role=“Producer”. A few months from now when we are wrapping up the details of 2.0 we can revisit this issue to see if one approach
of the other is clearly preferable and potentially remove one option. John Wunder and I talked through this proposed approach and have concurrence that it looks like a good solution. I have attached a simple diagram showing a few various example use cases and how this approach would support them. Obviously, this will require more specific proposed normative text but since it represents a non-trivial shift from the approach we had
been discussing I thought it wise to get out to you all as soon as possible rather than delaying it to capture all the details first. Please let us know what you think. Sean From:
"Barnum, Sean D." <sbarnum@mitre.org> Great conversation everyone. Just wanted to let you know that this is not stagnating. I am back from the SANS CTI Summit and working on catching up, trying to figure out how to make progress on these issues and pulling together
normative text where we can. I am doing a lot of thinking and talking with some folks on this issue in particular. It is looking like the issue of source, the issue of external_ids and next weeks main focus of identity-based objects are all beginning
to coalesce together to some degree. I think solving any one of them in a good way will likely involve finding a way to solve all of them coherently. I should have some thoughts out soon on this that I hope might move us forward. sean From:
<cti@lists.oasis-open.org> on behalf of "ppatrick@isightpartners.com" <ppatrick@isightpartners.com> Comments inline
Paul> I would agree that this would be in a chain
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]