OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cti message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [cti] Kinds of Sources


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.
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 
    • Person, organization or system
    • Representation of similar information external to STIX
  • sources internal to STIX
    • 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 
    • 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)
    • 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
    • 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:
  • “reference_URL” (optional) - specifies a URL to the external reference
    “external_identifier” (optional) - specifies an identifier for the external reference content
    “defining_context” (optional) - specifies the context within which the external_identifier is defined (system, registry, organization, etc.)
  • Define a specific Has Source relationship with an extra Roles (required)(1..*) property with the following draft list of valid values:
    • 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>
Date: Friday, February 5, 2016 at 10:41 AM
To: "ppatrick@isightpartners.com" <ppatrick@isightpartners.com>, Rich Piazza <rpiazza@mitre.org>
Cc: John Wunder <jwunder@mitre.org>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: Re: [cti] Kinds of Sources

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>
Date: Thursday, February 4, 2016 at 8:41 PM
To: Rich Piazza <rpiazza@mitre.org>
Cc: John Wunder <jwunder@mitre.org>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: Re: [cti] Kinds of Sources

Comments inline

Sent from my iPhone

On Feb 4, 2016, at 1:26 PM, Piazza, Rich <rpiazza@mitre.org> wrote:

Comments below:

 

From:cti@lists.oasis-open.org [mailto:cti@lists.oasis-open.org] On Behalf Of Wunder, John A.
Sent: Thursday, February 04, 2016 2:18 PM
To: cti@lists.oasis-open.org
Subject: Re: [cti] Kinds of Sources

 

Maybe you want something like “reviewed”? Are the there organizations that will accept an intel stream, review it for…something?…and then pass that along and note that? Or is that more of this opinion/assertion object?

 

This seems like one of the “chain” use case from Bret.  I think this would be handled by relationships.


Paul> I would agree that this would be in a chain

 

For the “reference” item in Rich’s list, I’d say that could be to either a STIX or to a non-STIX item. I also suspect in most cases this will be an actual content object rather than just an identity.

 

I was hoping to make a distinction between references to non-STIX objects, and my last bullet – source associations between STIX objects, which I was thinking would be handled by relationships.

 

Attachment: Source examples.png
Description: Source examples.png



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]