OASIS Cyber Threat Intelligence (CTI) TC

Expand all | Collapse all

Results of today's CTI working call on the topic of refactoring "sources"

  • 1.  Results of today's CTI working call on the topic of refactoring "sources"

    Posted 02-09-2016 20:37







    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









































  • 2.  RE: Results of today's CTI working call on the topic of refactoring "sources"

    Posted 02-10-2016 00:00




    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



     


     



     


     


     


     


     


     


     


     


     



     


     










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

    Posted 02-10-2016 00:25
    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


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

    Posted 02-10-2016 14:19
    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


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

    Posted 02-10-2016 14:42




    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























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

    Posted 02-10-2016 15:10
    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 > > > >


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

    Posted 02-10-2016 15:21
    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 >> >> >> >>


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

    Posted 02-10-2016 15:15
    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


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

    Posted 02-10-2016 15:20
    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 > > > >


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

    Posted 02-10-2016 15:27





    >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


























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

    Posted 02-10-2016 15:34
    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


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

    Posted 02-10-2016 18:05
    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


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

    Posted 02-10-2016 19:40





    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


































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

    Posted 02-10-2016 19:42
    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


  • 15.  Re: Results of today's CTI working call on the topic of refactoring "sources"

    Posted 02-10-2016 14:30





    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



     


     



     


     


     


     


     


     


     


     


     



     


     













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

    Posted 02-10-2016 00:25
    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


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

    Posted 02-10-2016 15:12





    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