OASIS Cyber Threat Intelligence (CTI) TC

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 = href= http://mitre.org/foobarreport.html >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

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 >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 = href= http://mitre.org/foobarreport.html >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



 


 



 


 


 


 


 


 


 


 


 



 


 

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: 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 = 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

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 = 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: 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 = 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

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 = 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:



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 = 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

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 > > > >

I agree with you 100% that this is the clarity of the semantics we are striving for. The lexicality and syntax of a JSON serialization would never “look” like that but the underlying semantics should be consistent enough to enable that sort of alternate serialization if someone desired. Basically, you are writing in tuple form which an RDF serialization would give you. I think this sort of semantics is supported by what is being proposed here without forcing JSON folks to think or write that way. >What is the difference between Sean? (if Sean is Sean - the only one) >Could Sean be defined only once? Yes, that is absolutely the intent here. You would have one “Sean” Identity object and relate all of those other STIX constructs to it with various relationships (the first four examples would use “has-source” with different “roles” and the last two would be part of what will be tackled in the March tranche when we address identity-based construct consistency. sean On 2/10/16, 10:09 AM, "Jerome Athias" <athiasjerome@gmail.com> wrote: >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 >> >> >> >>

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 = href= http://mitre.org/foobarreport.html class= style= color:purple; text-decoration:underline >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 = href= http://mitre.org/foobarreport.html class= style= color:purple; text-decoration:underline >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

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 > > > >

>In other words make the Tool a global and interchangeable construct.  


This is one of the side benefits of this approach for source. Breaking out tool helps us clarify and address the source use case but also gives us a foundation for addressing other tool-related issues as you point out here including the ability to talk
about tools from a malicious, benign or defensive perspective as well as tools used in relation to COAs. 
Breaking out identity has similar benefits in setting us up for some of the issues to be tackled in next month’s tranche (identity-based abstraction for source, victim, actor (threat actor, defender, 3rd party), etc.


I had originally had these side benefits listed in my status email out of the call but removed them as I did not want to sidetrack the conversation around source.
I think we will tackle those issues at the right time and this proposed solution sets us up for better chances of success when we get there.


sean









From: Patrick Maroney < Pmaroney@Specere.org >
Date: Wednesday, February 10, 2016 at 10:14 AM
To: "Jordan, Bret" < bret.jordan@bluecoat.com >, "Barnum, Sean D." < sbarnum@mitre.org >, Terry MacDonald < terry@soltra.com >
Cc: " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >
Subject: Re: [cti] Results of today's CTI working call on the topic of refactoring "sources"






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 = href= http://mitre.org/foobarreport.html class= style= color:purple; text-decoration:underline >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 = href= http://mitre.org/foobarreport.html class= style= color:purple; text-decoration:underline >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

I also do not want to sidetrack the conversation, please table my comments (for now). Patrick Maroney President Integrated Networking Technologies, Inc. Desk: (856)983-0001 Cell: (609)841-5104 Email: pmaroney@specere.org _____________________________ From: Barnum, Sean D. < sbarnum@mitre.org > Sent: Wednesday, February 10, 2016 10:27 AM Subject: Re: [cti] Results of today's CTI working call on the topic of refactoring "sources" To: Patrick Maroney < pmaroney@specere.org >, Jordan, Bret < bret.jordan@bluecoat.com >, Terry MacDonald < terry@soltra.com > Cc: < cti@lists.oasis-open.org > >In other words make the Tool a global and interchangeable construct.   This is one of the side benefits of this approach for source. Breaking out tool helps us clarify and address the source use case but also gives us a foundation for addressing other tool-related issues as you point out here including the ability to talk about tools from a malicious, benign or defensive perspective as well as tools used in relation to COAs.  Breaking out identity has similar benefits in setting us up for some of the issues to be tackled in next month’s tranche (identity-based abstraction for source, victim, actor (threat actor, defender, 3rd party), etc. I had originally had these side benefits listed in my status email out of the call but removed them as I did not want to sidetrack the conversation around source. I think we will tackle those issues at the right time and this proposed solution sets us up for better chances of success when we get there. sean From: Patrick Maroney < Pmaroney@Specere.org > Date: Wednesday, February 10, 2016 at 10:14 AM To: "Jordan, Bret" < bret.jordan@bluecoat.com >, "Barnum, Sean D." < sbarnum@mitre.org >, Terry MacDonald < terry@soltra.com > Cc: " cti@lists.oasis-open.org " < cti@lists.oasis-open.org > Subject: Re: [cti] Results of today's CTI working call on the topic of refactoring "sources" 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 = href= http://mitre.org/foobarreport.html class= style= color:purple; text-decoration:underline >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 = href= http://mitre.org/foobarreport.html class= style= color:purple; text-decoration:underline >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

Sean/all -  Apologize if this question has been asked before and resolved. If it has then appreciate a pointer to the solution. Issue: Many threat intelligence vendors have multiple ‘products’ or ‘feeds’ as separate deliverables the include intel reports, indicators, IOCs…etc. Typically this would be thought of as the source being the company/entity and the feed being the specific name of the feed containing a set of related information. Example: Source: Company X Feed: Malware Reports Source: Company X Feed: New Domains Report Source: Company X Feed: Phishing Sources List QUESTION: How would this information be represented in the new source model? If it is not, then I would suggest we should represent this information somehow. Should feed-name be an additional optional attribute of source? Regards Allan Thomson LookingGlass CTO On Feb 10, 2016, at 7:27 AM, Barnum, Sean D. < sbarnum@MITRE.ORG > wrote: >In other words make the Tool a global and interchangeable construct.   This is one of the side benefits of this approach for source. Breaking out tool helps us clarify and address the source use case but also gives us a foundation for addressing other tool-related issues as you point out here including the ability to talk about tools from a malicious, benign or defensive perspective as well as tools used in relation to COAs.  Breaking out identity has similar benefits in setting us up for some of the issues to be tackled in next month’s tranche (identity-based abstraction for source, victim, actor (threat actor, defender, 3rd party), etc. I had originally had these side benefits listed in my status email out of the call but removed them as I did not want to sidetrack the conversation around source. I think we will tackle those issues at the right time and this proposed solution sets us up for better chances of success when we get there. sean From: Patrick Maroney < Pmaroney@Specere.org > Date: Wednesday, February 10, 2016 at 10:14 AM To: Jordan, Bret < bret.jordan@bluecoat.com >, Barnum, Sean D. < sbarnum@mitre.org >, Terry MacDonald < terry@soltra.com > Cc: cti@lists.oasis-open.org < cti@lists.oasis-open.org > Subject: Re: [cti] Results of today's CTI working call on the topic of refactoring sources 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 = href= http://mitre.org/foobarreport.html class= style= color:purple; text-decoration:underline >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 = href= http://mitre.org/foobarreport.html class= style= color:purple; text-decoration:underline >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

Allan,




I would suggest that the feed would best be represented as a source independently from the just the company itself.




Maybe something like doing this one time:




Identity

Id = id-1

name = Company X




Reference

Id = id-2

title = Company X Malware Reports Feed
Reference-url = >  http://example.com/taxii2/channels/malware-report-feed/

External-Identifier = malware-report-feed

Defining-context = Company X TAXII Server




Reference
Id = id-3
title = Company X New Domains Report Feed
Reference-url = >

External-Identifier = new-domains-report-feed
Defining-context = Company X TAXII Server






Reference
Id = id-4
title = Company X Phishing Sources List Feed
Reference-url = >

External-Identifier = phishing-sources-list-feed
Defining-context = Company X TAXII Server






Relationship

Id = id-5

From = id-2

To = id-1

Nature = has-source

Roles = Analysis Originator, Producer




Relationship
Id = id-5
From = id-3
To = id-1
Nature = has-source
Roles = Analysis Originator, Producer





Relationship
Id = id-5
From = id-4
To = id-1
Nature = has-source
Roles = Analysis Originator, Producer











And then having any STIX content refer to these as sources, like:




Report

Id = id-6

…

Created_by_ref = id-1




Relationship
Id = id-7
From = id-6
To = id-2
Nature = has-source
Roles = Aggregator





Relationship
Id = id-7
From = id-6
To = id-1
Nature = has-source
Roles = Producer








This lets you pivot on a given feed but also on Company X across any feeds they might have.







Does that make sense?

Do you see any issues with this approach?







sean











From: Allan Thomson < athomson@lgscout.com >
Date: Wednesday, February 10, 2016 at 1:05 PM
To: "Barnum, Sean D." < sbarnum@MITRE.ORG >
Cc: Patrick Maroney < Pmaroney@Specere.org >, "Jordan, Bret" < bret.jordan@bluecoat.com >, Terry MacDonald < terry@soltra.com >,
" cti@lists.oasis-open.org " < cti@lists.oasis-open.org >
Subject: Re: [cti] Results of today's CTI working call on the topic of refactoring "sources"





Sean/all - 


Apologize if this question has been asked before and resolved. If it has then appreciate a pointer to the solution.


Issue: Many threat intelligence vendors have multiple ‘products’ or ‘feeds’ as separate deliverables the include intel reports, indicators, IOCs…etc.


Typically this would be thought of as the source being the
company/entity and the feed being the specific name of the feed containing a set of related information.


Example:


Source: Company X
Feed: Malware Reports


Source: Company X
Feed: New Domains Report


Source: Company X
Feed: Phishing Sources List


QUESTION: How would this information be represented in the new source model?


If it is not, then I would suggest we should represent this information somehow.


Should feed-name be an additional optional attribute of source?


Regards


Allan Thomson
LookingGlass CTO





On Feb 10, 2016, at 7:27 AM, Barnum, Sean D. < sbarnum@MITRE.ORG > wrote:





>In other words make the Tool a global and interchangeable construct.  


This is one of the side benefits of this approach for source. Breaking out tool helps us clarify and address the source use case but also gives us a foundation for addressing other tool-related issues as you point out here including the ability
to talk about tools from a malicious, benign or defensive perspective as well as tools used in relation to COAs. 
Breaking out identity has similar benefits in setting us up for some of the issues to be tackled in next month’s tranche (identity-based abstraction for source, victim, actor (threat actor, defender, 3rd party), etc.


I had originally had these side benefits listed in my status email out of the call but removed them as I did not want to sidetrack the conversation around source.
I think we will tackle those issues at the right time and this proposed solution sets us up for better chances of success when we get there.


sean









From: Patrick Maroney < Pmaroney@Specere.org >
Date: Wednesday, February 10, 2016 at 10:14 AM
To: "Jordan, Bret" < bret.jordan@bluecoat.com >, "Barnum, Sean D." < sbarnum@mitre.org >, Terry MacDonald < terry@soltra.com >
Cc: " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >
Subject: Re: [cti] Results of today's CTI working call on the topic of refactoring "sources"






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 = href= http://mitre.org/foobarreport.html class= style= color:purple; text-decoration:underline >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 = href= http://mitre.org/foobarreport.html class= style= color:purple; text-decoration:underline >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

Seems reasonable to me. Thanks. Allan On Feb 10, 2016, at 11:39 AM, Barnum, Sean D. < sbarnum@mitre.org > wrote: Allan, I would suggest that the feed would best be represented as a source independently from the just the company itself. Maybe something like doing this one time: Identity Id = id-1 name = Company X Reference Id = id-2 title = Company X Malware Reports Feed Reference-url = >   http://example.com/taxii2/channels/malware-report-feed/ External-Identifier = malware-report-feed Defining-context = Company X TAXII Server Reference Id = id-3 title = Company X New Domains Report Feed Reference-url = href= http://example.com/taxii2/channels/new-domains-report-feed/ >http://example.com/taxii2/channels/new-domains-report-feed/ External-Identifier = new-domains-report-feed Defining-context = Company X TAXII Server Reference Id = id-4 title = Company X Phishing Sources List Feed Reference-url = href= http://example.com/taxii2/channels/phishing-sources-list-feed/ >http://example.com/taxii2/channels/phishing-sources-list-feed/ External-Identifier = phishing-sources-list-feed Defining-context = Company X TAXII Server Relationship Id = id-5 From = id-2 To = id-1 Nature = has-source Roles = Analysis Originator, Producer Relationship Id = id-5 From = id-3 To = id-1 Nature = has-source Roles = Analysis Originator, Producer Relationship Id = id-5 From = id-4 To = id-1 Nature = has-source Roles = Analysis Originator, Producer And then having any STIX content refer to these as sources, like: Report Id = id-6 … Created_by_ref = id-1 Relationship Id = id-7 From = id-6 To = id-2 Nature = has-source Roles = Aggregator Relationship Id = id-7 From = id-6 To = id-1 Nature = has-source Roles = Producer This lets you pivot on a given feed but also on Company X across any feeds they might have. Does that make sense? Do you see any issues with this approach? sean From: Allan Thomson < athomson@lgscout.com > Date: Wednesday, February 10, 2016 at 1:05 PM To: Barnum, Sean D. < sbarnum@MITRE.ORG > Cc: Patrick Maroney < Pmaroney@Specere.org >, Jordan, Bret < bret.jordan@bluecoat.com >, Terry MacDonald < terry@soltra.com >, cti@lists.oasis-open.org < cti@lists.oasis-open.org > Subject: Re: [cti] Results of today's CTI working call on the topic of refactoring sources Sean/all -  Apologize if this question has been asked before and resolved. If it has then appreciate a pointer to the solution. Issue: Many threat intelligence vendors have multiple ‘products’ or ‘feeds’ as separate deliverables the include intel reports, indicators, IOCs…etc. Typically this would be thought of as the source being the company/entity and the feed being the specific name of the feed containing a set of related information. Example: Source: Company X Feed: Malware Reports Source: Company X Feed: New Domains Report Source: Company X Feed: Phishing Sources List QUESTION: How would this information be represented in the new source model? If it is not, then I would suggest we should represent this information somehow. Should feed-name be an additional optional attribute of source? Regards Allan Thomson LookingGlass CTO On Feb 10, 2016, at 7:27 AM, Barnum, Sean D. < sbarnum@MITRE.ORG > wrote: >In other words make the Tool a global and interchangeable construct.   This is one of the side benefits of this approach for source. Breaking out tool helps us clarify and address the source use case but also gives us a foundation for addressing other tool-related issues as you point out here including the ability to talk about tools from a malicious, benign or defensive perspective as well as tools used in relation to COAs.  Breaking out identity has similar benefits in setting us up for some of the issues to be tackled in next month’s tranche (identity-based abstraction for source, victim, actor (threat actor, defender, 3rd party), etc. I had originally had these side benefits listed in my status email out of the call but removed them as I did not want to sidetrack the conversation around source. I think we will tackle those issues at the right time and this proposed solution sets us up for better chances of success when we get there. sean From: Patrick Maroney < Pmaroney@Specere.org > Date: Wednesday, February 10, 2016 at 10:14 AM To: Jordan, Bret < bret.jordan@bluecoat.com >, Barnum, Sean D. < sbarnum@mitre.org >, Terry MacDonald < terry@soltra.com > Cc: cti@lists.oasis-open.org < cti@lists.oasis-open.org > Subject: Re: [cti] Results of today's CTI working call on the topic of refactoring sources 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 = href= http://mitre.org/foobarreport.html class= style= color:purple; text-decoration:underline >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 = href= http://mitre.org/foobarreport.html class= style= color:purple; text-decoration:underline >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

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:


Identity


ID = id-1
Name = MITRE

Report


ID = id-3
Title = FooBar Threat Report
Reference-url = href= http://mitre.org/foobarreport.html >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 = href= http://mitre.org/foobarreport.html >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



 


 



 


 


 


 


 


 


 


 


 



 


 

I can agree with items 1 and 2.  But I do not yet agree with item 3.  I am curious to know how it is a consensus proposal.    For item 3, some of it makes sense, and other parts seem a bit complicated and non-intuitive.   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 13:36, Barnum, Sean D. < sbarnum@mitre.org > wrote: 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 = href= http://mitre.org/foobarreport.html 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

Comments inline below




Bret, what can we do to help you understand and feel more comfortable with this?


sean









From: "Jordan, Bret" < bret.jordan@bluecoat.com >
Date: Tuesday, February 9, 2016 at 7:24 PM
To: "Barnum, Sean D." < sbarnum@mitre.org >
Cc: " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >
Subject: Re: [cti] Results of today's CTI working call on the topic of refactoring "sources"





I can agree with items 1 and 2.  But I do not yet agree with item 3.  I am curious to know how it is a consensus proposal.   




[sean]Item 1 has been widely discussed on the lists and at the F2f for quite a while and seems to have universal consensus (I don’t recall ever hearing anyone disagree with it).
Item 2 is somewhat new. It has consensus among the players who have been actively working on developing proposals for these issues and often do so from different perspectives (myself, John Wunder and I believe Terry). The intent of putting out the
revised proposal last week and talking about it on the call yesterday was to see if we could get broader consensus. My impression on the call was that specific details needed worked out but the high-level proposal seemed to have pretty good general consensus.
Item 3 is the topic of source referencing which has been talked about for a couple of months now. The two “strawman” proposals going into the F2F took different approaches on this (one using Relationships and the other using an embedded reference
for “producer” relationships). There really did not seem to be a lot of consensus between these two approaches at first but after a lot of discussion and exploration I think that the two sides realized that all non-producer sources would need to use Relationships
anyway and that having an embedded reference for “producer” did not preclude a Relationship being asserted for it as well to align with all the other source relationships. This led to a consensus among the two sides that the hybrid approach proposed here makes
the most sense. We still have details to work out but it also sounded like this had pretty good consensus support on the list, slack and the call from Sarah, Paul, Jason, Marlon and others. I don’t recall anyone other than yourself raising objections or concerns
on the high-level proposal. As I said, we still have details to work out though.


**If I have misunderstood anyone’s opinions and mischaracterized them here please feel free to correct me.**






For item 3, some of it makes sense, and other parts seem a bit complicated and non-intuitive.  





[sean]From my perspective it is actually simpler due to consistency and it appears to align very well with the way that real world analysts think about and relate these things.














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 13:36, Barnum, Sean D. < sbarnum@mitre.org > wrote:







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 = href= http://mitre.org/foobarreport.html 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