[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: Results of today's CTI working call on the topic of refactoring "sources"
No, Terry.
That object was intended to be Reference not Report. Reference is one of the new objects being proposed here to represent non-STIX sources of information such as papers, documents, blog posts, web pages, registry entries, etc.
The object in the example is not intended to be a STIX Report object. It is intended to represent a non-STIX threat report document. Maybe I should have had the URL end with .PDF instead of .HTML. Would that make it a little clearer.
Now, I could have also added a Report object in addition to the Reference object and specify an additional Has Source relationship from the STIX Report to the Reference with a Role of “Derivation Source”. I was just trying to keep the example simple and
show an Indicator that was codified out of a non-STIX report.
I agree that Has Source is somewhat general though I am unsure that people would actually misunderstand that it is saying one thing is a source for the other.
The Role property is there to provide some further qualification on the sort of sourcing relationship that exists.
I would not object to a couple of more specific Relationship Nature values for Tool and Reference (e.g., “source-tool” and “source-reference”) though I would assert that they would need to have the “role” property as well.
sean
From: Terry MacDonald <terry@soltra.com>
Date: Tuesday, February 9, 2016 at 7:00 PM To: "Barnum, Sean D." <sbarnum@mitre.org>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org> Subject: RE: Results of today's CTI working call on the topic of refactoring "sources" Hi Sean, I think you meant Report rather than reference in the Relating TLOs to Identities, Tools and References section? Here is the updated
structure reflecting that:
Also, the relationship of ‘has_source’ as described in the ‘Break Information Source into Individual Types’ dsection seems ambiguous to me. It’s too easy for people
to misunderstand its purpose with the name ‘has_source’. What do you think of changing the relationship ‘source-tool’? Then it is easy to understand what the relationship is expected to apply to. Cheers Terry MacDonald Senior STIX Subject Matter Expert SOLTRA | An FS-ISAC and DTCC Company +61 (407) 203 206 |
terry@soltra.com From:
cti@lists.oasis-open.org [mailto:cti@lists.oasis-open.org]
On Behalf Of Barnum, Sean D. We had a good constructive conversation on today’s CTI working call on the topic of refactoring source representations and relationships within STIX. We Invite further comments and discussion on this topic with a goal of reaching official consensus this week. On the call, a request was made to break the problem down into a clear high-level statement of what is being proposed, some of the value propositions asserted for
the proposal, and a breakdown of separate more detailed sub-issues that will need to be decided. Here is my stab at a clear high-level statement of what is being proposed. I will follow this email with a separate one focused on a breakdown of the detailed sub-issues to discuss/decide. High level statement of what is being proposed:
For anyone who was unclear before, does this help? Here is a little more detail if you find it useful. There is also a simple diagram attached showing some more various use case scenarios than just those presented
below. Break Information Source Out of Top-Level Objects In STIX 1.x, Information Source was a field in each top-level object. For example:
For STIX 2.0, we propose breaking information source into top-level objects, for example:
This allows for less repetition, helps prevent consumers from having to correlate identities on name, and allows people to easily pivot on sources. Break Information Source into Individual Types In STIX 1.x, Information Source covered Identity, Tools, and References. For example:
While this somewhat made sense since it was embedded in individual constructs, with the move to separating them out to top-level objects it would be nice to reference
them separately. So, for STIX 2.0, we propose breaking it apart into individual TLOs:
This would allow you to track “MITRE” as a separate identity from “CRITS” as a tool, etc. If MITRE’s SOC later produced something with a different tool, you probably
want to be able to separately pivot on “MITRE” as an identity and that tool that we used. Relating TLOs to Identities, Tools and References In STIX 1.x, we used the “Role” field in information source to describe the role of that source in creating the construct. For 2.x, we’ve developed a consensus proposal that uses a “Has Source” Relationship object to relate TLOs to their various sources. This “Has Source” relationship
has an extended Roles property serving a similar function to the Role field in STIX 1.x. In addition, strictly for the creator of the actual STIX content it also supports an optional “created_by_ref” property on each TLO.
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]