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

[Jerome Athias <athiasjerome@gmail.com>]

This is basically what I suggested (ref. Asset thread): to have top
level constructs for Organization, Person and Tool
(with some optimizations of this)

2016-02-10 18:14 GMT+03:00 Patrick Maroney <Pmaroney@specere.org>:
> I hesitate going too far down the rabbit-hole, but since I jumped in:
>
> My thinking was that a "tool" sub-class should be an independent construct
> (perhaps within TTP?  - presuming one subscribes to the notion of White Hat
> TTPs).  Relationships to COA, Sightings, etc.
>
> Therefore one can reference the "Tool" (i.e., Yara & Yara Rule) in the
> original assertion that I established the "badness" of "threat x"  using
> "Tool".
>
> ...Then others can share sightings of "threat x" based on "Tool" : using
> "Tool" I 'sighted ' this activity.
>
> ....And others can report I mitigated "threat x" using COA "Tool"
>
> In other words make the Tool a global and interchangeable construct.  Note
> that the "Yara Rule" itself in this example would have a "Source",
> Versioning, and Provenance...
>
> Patrick Maroney
> President
> Integrated Networking Technologies, Inc.
> Desk: (856)983-0001
> Cell: (609)841-5104
> Email: pmaroney@specere.org
>
>
>
>
> On Wed, Feb 10, 2016 at 6:42 AM -0800, "Barnum, Sean D." <sbarnum@mitre.org>
> wrote:
>
> 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
>
>
>
>