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] Results of today's CTI working call on the topic of refactoring "sources"


"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 ="" href="http://mitre.org/foobarreport.html" style="color: purple; text-decoration: underline;" class="">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:
  1. Break information source out of Top-Level Objects
  2. 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
  1. 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 ="" href="http://mitre.org/foobarreport.html" style="color: purple; text-decoration: underline;" class="">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

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail



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