[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [cti] Kinds of Sources
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]