Re: [cti] Results of today's CTI working call on the topic of refactoring "sources"

[Jerome Athias <athiasjerome@gmail.com>]

While STIX is intended to be a language, I see this refactoring
offering a better way for sentences structure "subject–verb–object
(SVO)", and introducing/allowing the use of  'pronouns' (ref by IDs).

Where subject was suggested/identified as
Organization/Person/Automaton(System/Tool)
(I see it as beneficial; for simplification of the schemas, reduction
of redundancy, easier correlation/analytics, optimization of size,
etc. and not just for 'sources'... )

Basically, when writing:
Sean is the producer of indicator A
Sean is the producer of indicator B and C
He is the analyst of Malware B
Sean is the victim of APT666
Sean is a target of Spear Phishing Campaign Blue Monkeys
...
What is the difference between Sean? (if Sean is Sean - the only one)
Could Sean be defined only once?

In the same way
Tool X is the producer of indicator Y
Sean is the producer of indicator Z and he is the analyst using Tool X




2016-02-10 17:42 GMT+03:00 Barnum, Sean D. <sbarnum@mitre.org>:
> Pat, I would agree that sometimes when talking about a tool you are talking
> about a method. Other times a tool may be the source of the information
> itself (e.g. an ML scanning osint and creating STIX asserting that a
> particular TTP was leveraged as part of a Campaign).
> Can you help us see what would be gained by making a distinction a tool as
> method vs source here? Is the same information not captured either way?
> I think we are looking to keep it as simple as possible and still support
> the necessary use cases.
> Having identities, tools and references treated as types of “sources” seems
> to be simpler than breaking tools off into a new concept of “method”.
>
>>Also note that I may use multiple "Tools" to establish the basis for my
>> assertion(s).
> I believe you can still do this with the current proposal simply by
> specifying each tool and asserting a “has-source” relationship (maybe with a
> new “role” value more specific to this sort of case) between your assertion
> and the tools.
>
> Is there something we are missing by doing it the proposed way? I am
> genuinely interested in understanding.
>
> Thanks,
>
> sean
>
> Fro Patrick Maroney <Pmaroney@Specere.org>
> Date: Wednesday, February 10, 2016 at 9:19 AM
> To: "Jordan, Bret" <bret.jordan@bluecoat.com>, Terry MacDonald
> <terry@soltra.com>
> Cc: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>, "Barnum, Sean D."
> <sbarnum@mitre.org>
>
> Subject: Re: [cti] Results of today's CTI working call on the topic of
> refactoring "sources"
>
> Isn't "Tool" better related to a Method (i.e.: ==Using==>) relationship?
> (I'm paraphrasing here)
>
> In other words,  an entity is still the Source of an assertion, the tool(s)
> used to make that assertion are the Method.  Also note that I may use
> multiple "Tools" to establish the basis for my assertion(s).
>
> Patrick Maroney
> President
> Integrated Networking Technologies, Inc.
> Desk: (856)983-0001
> Cell: (609)841-5104
> Email: pmaroney@specere.org
>
> _____________________________
> From: Jordan, Bret <bret.jordan@bluecoat.com>
> Sent: Tuesday, February 9, 2016 7:25 PM
> Subject: Re: [cti] Results of today's CTI working call on the topic of
> refactoring "sources"
> To: Terry MacDonald <terry@soltra.com>
> Cc: <cti@lists.oasis-open.org>, Barnum, Sean D. <sbarnum@mitre.org>
>
>
> "source-tool" does seem to be more clear.
>
>
> Thanks,
>
> Bret
>
>
>
> Bret Jordan CISSP
> Director of Security Architecture and Standards | Office of the CTO
> Blue Coat Systems
> PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
> "Without cryptography vihv vivc ce xhrnrw, however, the only thing that can
> not be unscrambled is an egg."
>
> On Feb 9, 2016, at 17:00, Terry MacDonald < terry@soltra.com> wrote:
>
> 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:
>
> Identity
>
> ID = id-1
> Name = MITRE
>
> Report
>
> ID = id-3
> Title = FooBar Threat Report
> Reference-url = http://mitre.org/foobarreport.html
>
> Indicator
>
> ID = id-4
> created by ref => id-1
>
> Relationship
>
> ID = id-5
> From = id-4
> To = id-1
> Nature = Has Source
> Role = Producer
>
> Relationship
>
> ID = id-6
> From = id-4
> To = id-3
> Nature = Has Source
> Role = Derivation Resource
>
> 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.
> Sent: Wednesday, 10 February 2016 7:36 AM
> To: cti@lists.oasis-open.org
> Subject: [cti] Results of today's CTI working call on the topic of
> refactoring "sources"
>
> 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:
>
> Break information source out of Top-Level Objects
> Break information source into individual types
>
> Identities: who is the source of the information?
> Tools: from what tool(s) did the information come?
> References: what non-STIX resources were used directly or indirectly
> (background context) as sources for the information
>
> Relate TLOs to identities, tools and references
>
> 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:
>
> Indicator
>
> Information Source
>
> Identity = MITRE
>
> Indicator 2
>
> Information Source
>
> Identity = MITRE
>
> For STIX 2.0, we propose breaking information source into top-level objects,
> for example:
>
> Identity
>
> ID = id-1
> Name = MITRE
>
> Indicator
>
> (created-by) = id-1 (shorthand does not imply how relationship should be
> represented)
>
> Indicator 2
>
> (created-by) = id-1 (shorthand does not imply how relationship should be
> represented)
>
> 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:
>
> Indicator
>
> Information Source
>
> Identity = MITRE
> Tool = CRITS
>
> 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:
>
>
> Identity
>
> Name = MITRE
> ID = id-1
>
> Tool
>
> Name = CRITS 2.3
> ID = id-2
>
> Indicator
>
> (created by) => id-1 (shorthand does not imply how relationship should be
> represented)
> (has source) => id-2 (shorthand does not imply how relationship should be
> represented)
>
> 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.
>
>
> Identity
>
> ID = id-1
> Name = MITRE
>
> Reference
>
> ID = id-3
> Title = FooBar Threat Report
> Reference-url = http://mitre.org/foobarreport.html
>
> Indicator
>
> ID = id-4
> created by ref => id-1
>
> Relationship
>
> ID = id-5
> From = id-4
> To = id-1
> Nature = Has Source
> Role = Producer
>
> Relationship
>
> ID = id-6
> From = id-4
> To = id-3
> Nature = Has Source
> Role = Derivation Resource
>
>
>
>