OASIS Cyber Threat Intelligence (CTI) TC

  • 1.  [cti] Option 1 vs. Option 7 Powerpoint Example

    Posted 10-31-2018 13:21
      |   view attached




    Thank you to everyone for taking time to discuss Option 1 and Option 7.  As usual, Jane did an excellent job capturing the discussion, including screen shots from the presentation.  John-Mark requested that I resend out the slides from
    yesterday s discussion with any updates, which I believe is valuable as it will allow us to continue the discussion over email.  As an update, I did include an optional Observed Data object in Option 1.  The inclusion of an Observed Data object would show
    that the producer directly observed the email with an attachment vs. indirectly having that information (ex. Gathered the information from external reporting). 

     
    The purpose of this example is to show a very reasonable use-case for a cyber security analyst and discuss how that data can be represented in the STIX standard using either Option 1 or Option 7.  I have not created JSON versions of the
    example in both Option 1 and Option 7 form.  My assumption would be, to Allan s point, that the Option 1 version is more verbose, although only slightly.  This does mean that the data size of the document is larger and to earlier points, in other use cases
    this difference can be even larger.  This example though highlights an even larger issue.  Option 7 does not allow some common useful relationships to be represented within the format.  Having relationships to show that a file found in an email, which analysis
    shows beacons to a C2 that resolved to a specific domain is not possible in Option 7.  The receiver must infer this information through 3 disjointed objects. 

     
    Our greatest risk to adoption is not asking companies and organizations to update their STIX implementations to support Option 1 or the increase in data size for certain use cases.  Our greatest risk is having the trust of the userbase. 
    One day, far in the future (if we do our jobs well), analysts will not even be aware of STIX being used in the background to transfer their data.  Today though, they are paying attention, they will be asked by their leadership to look at the standard and provide
    their opinion on how valuable it is to adopt STIX, and analysts will not understand why they can t represent a file found in an email has a C2 beacon that resolves to a domain (or something similar).  The answer to just trust us that the receiver is going
    to auto-correlate that information back together, probably won t fly. 
     
    Some of these issues were masked by the limited use cases possible in STIX 2.0 and 2.1.  As the standard evolves to support Malware, Infrastructure and Incident objects these issues will become very pronounced.  We will continue to put
    band-aids on the standard as a result of the deficiency (ex. See the malware proposal submitted by Jeff Mates and I earlier this year).  Option 1 will resolve these deficiencies.  Will it take work and effort, yes, but that work and effort will only continue
    to grow the longer we wait.
     
    -Gary
     
    Some Metrics on the two implementations of the use cases:
    Option 1:
    8 Objects (1 optional)  (2 SDOs, 6 SOOs)
    5 Embedded refs (3 optional)
    6 Relationships (6 SROs)
     
    Option 7
    15 Objects* (6 SDOs, 9 cyber observables)
    5 Embedded refs (2 within Malware not shown)
    2 Relationships (2 SROs) Note some relationships in the example cannot be represented in this option
    * Cyber Observables are not full objects in this option.  Therefore must be embedded in an SDO but are lighter objects that take less text to represent.
     
     

    From: <cti@lists.oasis-open.org> on behalf of Jane Ginn <jg@ctin.us>
    Date: Tuesday, October 30, 2018 at 6:10 PM
    To: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
    Subject: [cti] Groups - Weekly Working Call - Notes uploaded


     

    Submitter's message
    CTI TC:

    Here is the PDF of the notes from the Working Call. I included the figures in this version.

    Best regards,

    -- Ms. Jane Ginn




    Document Name :

    Weekly Working Call - Notes





    Description
    Discussed Option 1 and Option 7 for Cyber Observables
    Download Latest Revision
    Public Download Link





    Submitter : Ms. Jane Ginn
    Group : OASIS Cyber Threat Intelligence (CTI) TC
    Folder : Meeting Notes
    Date submitted : 2018-10-30 15:10:05




     

    This email and any attachments thereto may contain private, confidential, and/or privileged material for the sole use of the intended recipient. Any review, copying, or distribution of this email (or any attachments thereto) by others is strictly prohibited.
    If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto.


    Attachment: STIX Example Opt1 Op7.pptx Description: STIX Example Opt1 Op7.pptx

    Attachment(s)

    pptx
    STIX Example Opt1 Op7.pptx   45 KB 1 version


  • 2.  Re: [cti] Option 1 vs. Option 7 Powerpoint Example

    Posted 10-31-2018 14:44




    Gary thanks for sharing.
     
    One of the things that I ve realized as part of reviewing the use cases is the differences in how we talk about things.
     
    I ve come to the conclusion that we are talking about 2 different aspects of our problem set.
     

    Event-based
    Vs

    State-based
     
    From my perspective, Option 1 is really representing a state of entities and connectedness between those entities after multiple events have occurred.
     
    Option 7 (current observed-data model) represents discrete individual events that would occur over time.
     
    This would be similar to having a state-machine defined (I,.e. the resultant intel model) and then individual events (intel events) that cause you to update the state-model.

     
    Think of the intel model as the campaigns, actors, email-addresses, ips .etc.
     
    Think of the events as changes to those intel objects (i.e. observed data model).
     
    Conflating the 2 of these is not the solution.
     
    The question is whether we are defining STIX to communicate event-based model or a state-based model.
     
    I think we should consider the possibility that both are valid things to do and therefore we should consider how to approach using STIX to clearly articulate when we are
     

    Sending discrete events that have been observed at a specific time and any associated meta data to that event Sending a state model that represents the collective intelligence and associated relationships across that state built up over time
     
    I think if we recognize that both models require something different and factor that into our STIX data model discussion then we might find a way to solve both.
     
    I have some ideas but this email is already too long.
     
    Allan
     

    From: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org> on behalf of Gary Jay Katz <gary.katz@FireEye.com>
    Date: Wednesday, October 31, 2018 at 6:20 AM
    To: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
    Subject: [cti] Option 1 vs. Option 7 Powerpoint Example


     

    Thank you to everyone for taking time to discuss Option 1 and Option 7.  As usual, Jane did an excellent job capturing the discussion, including screen shots from the presentation.  John-Mark requested that I resend out the slides from
    yesterday s discussion with any updates, which I believe is valuable as it will allow us to continue the discussion over email.  As an update, I did include an optional Observed Data object in Option 1.  The inclusion of an Observed Data object would show
    that the producer directly observed the email with an attachment vs. indirectly having that information (ex. Gathered the information from external reporting). 

     
    The purpose of this example is to show a very reasonable use-case for a cyber security analyst and discuss how that data can be represented in the STIX standard using either Option 1 or Option 7.  I have not created JSON versions of the
    example in both Option 1 and Option 7 form.  My assumption would be, to Allan s point, that the Option 1 version is more verbose, although only slightly.  This does mean that the data size of the document is larger and to earlier points, in other use cases
    this difference can be even larger.  This example though highlights an even larger issue.  Option 7 does not allow some common useful relationships to be represented within the format.  Having relationships to show that a file found in an email, which analysis
    shows beacons to a C2 that resolved to a specific domain is not possible in Option 7.  The receiver must infer this information through 3 disjointed objects. 

     
    Our greatest risk to adoption is not asking companies and organizations to update their STIX implementations to support Option 1 or the increase in data size for certain use cases.  Our greatest risk is having the trust of the userbase. 
    One day, far in the future (if we do our jobs well), analysts will not even be aware of STIX being used in the background to transfer their data.  Today though, they are paying attention, they will be asked by their leadership to look at the standard and provide
    their opinion on how valuable it is to adopt STIX, and analysts will not understand why they can t represent a file found in an email has a C2 beacon that resolves to a domain (or something similar).  The answer to just trust us that the receiver is going
    to auto-correlate that information back together, probably won t fly. 
     
    Some of these issues were masked by the limited use cases possible in STIX 2.0 and 2.1.  As the standard evolves to support Malware, Infrastructure and Incident objects these issues will become very pronounced.  We will continue to put
    band-aids on the standard as a result of the deficiency (ex. See the malware proposal submitted by Jeff Mates and I earlier this year).  Option 1 will resolve these deficiencies.  Will it take work and effort, yes, but that work and effort will only continue
    to grow the longer we wait.
     
    -Gary
     
    Some Metrics on the two implementations of the use cases:
    Option 1:
    8 Objects (1 optional)  (2 SDOs, 6 SOOs)
    5 Embedded refs (3 optional)
    6 Relationships (6 SROs)
     
    Option 7
    15 Objects* (6 SDOs, 9 cyber observables)
    5 Embedded refs (2 within Malware not shown)
    2 Relationships (2 SROs) Note some relationships in the example cannot be represented in this option
    * Cyber Observables are not full objects in this option.  Therefore must be embedded in an SDO but are lighter objects that take less text to represent.
     
     

    From: <cti@lists.oasis-open.org> on behalf of Jane Ginn <jg@ctin.us>
    Date: Tuesday, October 30, 2018 at 6:10 PM
    To: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
    Subject: [cti] Groups - Weekly Working Call - Notes uploaded


     

    Submitter's message
    CTI TC:

    Here is the PDF of the notes from the Working Call. I included the figures in this version.

    Best regards,

    -- Ms. Jane Ginn




    Document Name :

    Weekly Working Call - Notes







    Description
    Discussed Option 1 and Option 7 for Cyber Observables
    Download Latest Revision
    Public Download Link







    Submitter : Ms. Jane Ginn
    Group : OASIS Cyber Threat Intelligence (CTI) TC
    Folder : Meeting Notes
    Date submitted : 2018-10-30 15:10:05




     
    This email and any attachments thereto may contain private, confidential, and/or privileged material for the sole use of the intended recipient. Any review, copying, or distribution of this email (or any attachments thereto) by others is
    strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto.







  • 3.  RE: [cti] Option 1 vs. Option 7 Powerpoint Example

    Posted 10-31-2018 18:04
      |   view attached




    Allan (and all),
     
    I think this is a really profound realization. I have been coming at this with a state-based idea, as in give me everything you know about X . Having worked in a SOC, I also realize the use cases for event-based data.  I, for one,
    would be curious about your possible ideas for being able to represent both.
     
    Thanks,
     

    Sarah Kelley
    Lead Cybersecurity Engineer, T8B2
    Defensive Operations
    The MITRE Corporation
    703-983-6242
    skelley@mitre.org


     


    From: cti@lists.oasis-open.org <cti@lists.oasis-open.org>
    On Behalf Of Allan Thomson
    Sent: Wednesday, October 31, 2018 10:44 AM
    To: Gary Jay Katz <gary.katz@FireEye.com>; cti@lists.oasis-open.org
    Subject: Re: [cti] Option 1 vs. Option 7 Powerpoint Example


     
    Gary thanks for sharing.
     
    One of the things that I ve realized as part of reviewing the use cases is the differences in how we talk about things.
     
    I ve come to the conclusion that we are talking about 2 different aspects of our problem set.
     

    Event-based
    Vs

    State-based
     
    From my perspective, Option 1 is really representing a state of entities and connectedness between those entities after multiple events have occurred.
     
    Option 7 (current observed-data model) represents discrete individual events that would occur over time.
     
    This would be similar to having a state-machine defined (I,.e. the resultant intel model) and then individual events (intel events) that cause you to update the state-model.

     
    Think of the intel model as the campaigns, actors, email-addresses, ips .etc.
     
    Think of the events as changes to those intel objects (i.e. observed data model).
     
    Conflating the 2 of these is not the solution.
     
    The question is whether we are defining STIX to communicate event-based model or a state-based model.
     
    I think we should consider the possibility that both are valid things to do and therefore we should consider how to approach using STIX to clearly articulate when we are
     

    Sending discrete events that have been observed at a specific time and any associated meta data to that event Sending a state model that represents the collective intelligence and associated relationships across that state built up over time
     
    I think if we recognize that both models require something different and factor that into our STIX data model discussion then we might find a way to solve both.
     
    I have some ideas but this email is already too long.
     
    Allan
     

    From: " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >
    on behalf of Gary Jay Katz < gary.katz@FireEye.com >
    Date: Wednesday, October 31, 2018 at 6:20 AM
    To: " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >
    Subject: [cti] Option 1 vs. Option 7 Powerpoint Example


     

    Thank you to everyone for taking time to discuss Option 1 and Option 7.  As usual, Jane did an excellent job capturing the discussion, including screen shots from the presentation.  John-Mark requested that I resend out the slides from
    yesterday s discussion with any updates, which I believe is valuable as it will allow us to continue the discussion over email.  As an update, I did include an optional Observed Data object in Option 1.  The inclusion of an Observed Data object would show
    that the producer directly observed the email with an attachment vs. indirectly having that information (ex. Gathered the information from external reporting). 

     
    The purpose of this example is to show a very reasonable use-case for a cyber security analyst and discuss how that data can be represented in the STIX standard using either Option 1 or Option 7.  I have not created JSON versions of the
    example in both Option 1 and Option 7 form.  My assumption would be, to Allan s point, that the Option 1 version is more verbose, although only slightly.  This does mean that the data size of the document is larger and to earlier points, in other use cases
    this difference can be even larger.  This example though highlights an even larger issue.  Option 7 does not allow some common useful relationships to be represented within the format.  Having relationships to show that a file found in an email, which analysis
    shows beacons to a C2 that resolved to a specific domain is not possible in Option 7.  The receiver must infer this information through 3 disjointed objects. 

     
    Our greatest risk to adoption is not asking companies and organizations to update their STIX implementations to support Option 1 or the increase in data size for certain use cases.  Our greatest risk is having the trust of the userbase. 
    One day, far in the future (if we do our jobs well), analysts will not even be aware of STIX being used in the background to transfer their data.  Today though, they are paying attention, they will be asked by their leadership to look at the standard and provide
    their opinion on how valuable it is to adopt STIX, and analysts will not understand why they can t represent a file found in an email has a C2 beacon that resolves to a domain (or something similar).  The answer to just trust us that the receiver is going
    to auto-correlate that information back together, probably won t fly. 
     
    Some of these issues were masked by the limited use cases possible in STIX 2.0 and 2.1.  As the standard evolves to support Malware, Infrastructure and Incident objects these issues will become very pronounced.  We will continue to put
    band-aids on the standard as a result of the deficiency (ex. See the malware proposal submitted by Jeff Mates and I earlier this year).  Option 1 will resolve these deficiencies.  Will it take work and effort, yes, but that work and effort will only continue
    to grow the longer we wait.
     
    -Gary
     
    Some Metrics on the two implementations of the use cases:
    Option 1:
    8 Objects (1 optional)  (2 SDOs, 6 SOOs)
    5 Embedded refs (3 optional)
    6 Relationships (6 SROs)
     
    Option 7
    15 Objects* (6 SDOs, 9 cyber observables)
    5 Embedded refs (2 within Malware not shown)
    2 Relationships (2 SROs) Note some relationships in the example cannot be represented in this option
    * Cyber Observables are not full objects in this option.  Therefore must be embedded in an SDO but are lighter objects that take less text to represent.
     
     

    From: < cti@lists.oasis-open.org > on behalf of Jane Ginn < jg@ctin.us >
    Date: Tuesday, October 30, 2018 at 6:10 PM
    To: " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >
    Subject: [cti] Groups - Weekly Working Call - Notes uploaded


     

    Submitter's message
    CTI TC:

    Here is the PDF of the notes from the Working Call. I included the figures in this version.

    Best regards,

    -- Ms. Jane Ginn




    Document Name :

    Weekly Working Call - Notes







    Description
    Discussed Option 1 and Option 7 for Cyber Observables
    Download Latest Revision
    Public Download Link







    Submitter : Ms. Jane Ginn
    Group : OASIS Cyber Threat Intelligence (CTI) TC
    Folder : Meeting Notes
    Date submitted : 2018-10-30 15:10:05




     
    This email and any attachments thereto may contain private, confidential, and/or privileged material for the sole use of the intended recipient. Any review, copying, or distribution of this email (or any attachments thereto) by others is
    strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto.







  • 4.  Re: [EXT] RE: [cti] Option 1 vs. Option 7 Powerpoint Example

    Posted 10-31-2018 19:23
      |   view attached
    All, When I look at it, the problem I see / hear from Gary / Jeff / Sean / Sarah is that internal relationships on the observable container do not really work for what people need. Thus having external relationships and all their goodness is what people need. You can do that in one of three ways.   a) Make cyber observables top level objects (option 1 prime from previous discussions) b) Provide some sort of deep referencing inside of Observed Data (people have consistently shot down this idea) c) Try and pull out the relationships that really need to be external and leave the rest. (A combination of option 7 with some tweaks that John Wunder has brought up) So options a, b, and c are technically all possible, though o ption b where you do deep referencing inside of an Observed Data is just awful and will probably be the no-end-to-pain. Bret From: cti@lists.oasis-open.org <cti@lists.oasis-open.org> on behalf of Kelley, Sarah E. <skelley@mitre.org> Sent: Wednesday, October 31, 2018 12:04:09 PM To: Allan Thomson; Gary Jay Katz; cti@lists.oasis-open.org Subject: [EXT] RE: [cti] Option 1 vs. Option 7 Powerpoint Example   Allan (and all),   I think this is a really profound realization. I have been coming at this with a “state-based” idea, as in “give me everything you know about X”. Having worked in a SOC, I also realize the use cases for “event-based” data.  I, for one, would be curious about your possible ideas for being able to represent both.   Thanks,   Sarah Kelley Lead Cybersecurity Engineer, T8B2 Defensive Operations The MITRE Corporation 703-983-6242 skelley@mitre.org   From: cti@lists.oasis-open.org <cti@lists.oasis-open.org> On Behalf Of Allan Thomson Sent: Wednesday, October 31, 2018 10:44 AM To: Gary Jay Katz <gary.katz@FireEye.com>; cti@lists.oasis-open.org Subject: Re: [cti] Option 1 vs. Option 7 Powerpoint Example   Gary – thanks for sharing.   One of the things that I’ve realized as part of reviewing the use cases is the differences in how we talk about things.   I’ve come to the conclusion that we are talking about 2 different aspects of our problem set.   Event-based Vs State-based   From my perspective, Option 1 is really representing a state of entities and connectedness between those entities after multiple events have occurred.   Option 7 (current observed-data model) represents discrete individual events that would occur over time.   This would be similar to having a state-machine defined (I,.e. the resultant intel model) and then individual events (intel events) that cause you to update the state-model.   Think of the intel model as the campaigns, actors, email-addresses, ips….etc.   Think of the events as changes to those intel objects (i.e. observed data model).   Conflating the 2 of these is not the solution.   The question is whether we are defining STIX to communicate event-based model or a state-based model.   I think we should consider the possibility that both are valid things to do and therefore we should consider how to approach using STIX to clearly articulate when we are   Sending discrete events that have been observed at a specific time and any associated meta data to that event Sending a state model that represents the collective intelligence and associated relationships across that state built up over time   I think if we recognize that both models require something different and factor that into our STIX data model discussion then we might find a way to solve both.   I have some ideas but this email is already too long.   Allan   From: " cti@lists.oasis-open.org " < cti@lists.oasis-open.org > on behalf of Gary Jay Katz < gary.katz@FireEye.com > Date: Wednesday, October 31, 2018 at 6:20 AM To: " cti@lists.oasis-open.org " < cti@lists.oasis-open.org > Subject: [cti] Option 1 vs. Option 7 Powerpoint Example   Thank you to everyone for taking time to discuss Option 1 and Option 7.  As usual, Jane did an excellent job capturing the discussion, including screen shots from the presentation.  John-Mark requested that I resend out the slides from yesterday’s discussion with any updates, which I believe is valuable as it will allow us to continue the discussion over email.  As an update, I did include an optional Observed Data object in Option 1.  The inclusion of an Observed Data object would show that the producer directly observed the email with an attachment vs. indirectly having that information (ex. Gathered the information from external reporting).    The purpose of this example is to show a very reasonable use-case for a cyber security analyst and discuss how that data can be represented in the STIX standard using either Option 1 or Option 7.  I have not created JSON versions of the example in both Option 1 and Option 7 form.  My assumption would be, to Allan’s point, that the Option 1 version is more verbose, although only slightly.  This does mean that the data size of the document is larger and to earlier points, in other use cases this difference can be even larger.  This example though highlights an even larger issue.  Option 7 does not allow some common useful relationships to be represented within the format.  Having relationships to show that a file found in an email, which analysis shows beacons to a C2 that resolved to a specific domain is not possible in Option 7.  The receiver must infer this information through 3 disjointed objects.    Our greatest risk to adoption is not asking companies and organizations to update their STIX implementations to support Option 1 or the increase in data size for certain use cases.  Our greatest risk is having the trust of the userbase.  One day, far in the future (if we do our jobs well), analysts will not even be aware of STIX being used in the background to transfer their data.  Today though, they are paying attention, they will be asked by their leadership to look at the standard and provide their opinion on how valuable it is to adopt STIX, and analysts will not understand why they can’t represent a file found in an email has a C2 beacon that resolves to a domain (or something similar).  The answer to just trust us that the receiver is going to auto-correlate that information back together, probably won’t fly.    Some of these issues were masked by the limited use cases possible in STIX 2.0 and 2.1.  As the standard evolves to support Malware, Infrastructure and Incident objects these issues will become very pronounced.  We will continue to put band-aids on the standard as a result of the deficiency (ex. See the malware proposal submitted by Jeff Mates and I earlier this year).  Option 1 will resolve these deficiencies.  Will it take work and effort, yes, but that work and effort will only continue to grow the longer we wait.   -Gary   Some Metrics on the two implementations of the use cases: Option 1: 8 Objects (1 optional)  (2 SDOs, 6 SOOs) 5 Embedded refs (3 optional) 6 Relationships (6 SROs)   Option 7 15 Objects* (6 SDOs, 9 cyber observables) 5 Embedded refs (2 within Malware not shown) 2 Relationships (2 SROs) – Note some relationships in the example cannot be represented in this option * Cyber Observables are not full objects in this option.  Therefore must be embedded in an SDO but are lighter objects that take less text to represent.     From: < cti@lists.oasis-open.org > on behalf of Jane Ginn < jg@ctin.us > Date: Tuesday, October 30, 2018 at 6:10 PM To: " cti@lists.oasis-open.org " < cti@lists.oasis-open.org > Subject: [cti] Groups - Weekly Working Call - Notes uploaded   Submitter's message CTI TC: Here is the PDF of the notes from the Working Call. I included the figures in this version. Best regards, -- Ms. Jane Ginn Document Name : Weekly Working Call - Notes Description Discussed Option 1 and Option 7 for Cyber Observables Download Latest Revision Public Download Link Submitter : Ms. Jane Ginn Group : OASIS Cyber Threat Intelligence (CTI) TC Folder : Meeting Notes Date submitted : 2018-10-30 15:10:05   This email and any attachments thereto may contain private, confidential, and/or privileged material for the sole use of the intended recipient. Any review, copying, or distribution of this email (or any attachments thereto) by others is strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto.


  • 5.  Re: [cti] Re: [EXT] RE: [cti] Option 1 vs. Option 7 Powerpoint Example

    Posted 11-01-2018 01:33
    What I have come to realize, in conjunction
    with what Allan is pointing out, is the fundamental disconnect between
    an event-based concern and a state-based concern is the following: * an event-based system has no need
    to currently maintain the observed_data object* - it is likely currently
    thrown away. The observations inside are consumed for whatever purposes
    they are meant for, but the container is likely not preserved. This is why this discussion I think
    is so hard to have. The relationships to objects inside an observable container,
    only make sense if the container is even thought as data that needs to
    be preserved at all - which implies it is conveying persistent state, not
    just events to be accumulated. It's two totally different use cases. - Jason Keirstead Lead Architect - IBM Security Connect www.ibm.com/security "Things may come to those who wait, but only the things left by those
    who hustle." - Unknown From:      
      Bret Jordan <Bret_Jordan@symantec.com> To:      
      "Kelley, Sarah
    E." <skelley@mitre.org>, Allan Thomson <athomson@lookingglasscyber.com>,
    Gary Jay Katz <gary.katz@FireEye.com>, "cti@lists.oasis-open.org"
    <cti@lists.oasis-open.org> Date:      
      10/31/2018 04:22 PM Subject:    
        [cti] Re: [EXT]
    RE: [cti] Option 1 vs. Option 7 Powerpoint Example Sent by:    
        <cti@lists.oasis-open.org> All, When I look at it, the problem I see / hear
    from Gary / Jeff / Sean / Sarah is that internal relationships on the observable
    container do not really work for what people need. Thus having external
    relationships and all their goodness is what people need. You can do that in one of three ways.   a) Make cyber observables top level objects
    (option 1 prime from previous discussions) b) Provide some sort of deep referencing
    inside of Observed Data (people have consistently shot down this idea) c) Try and pull out the relationships that
    really need to be external and leave the rest. (A combination of option
    7 with some tweaks that John Wunder has brought up) So options a, b, and c are technically
    all possible, though option b where you do deep referencing inside of an
    Observed Data is just awful and will probably be the no-end-to-pain. Bret From: cti@lists.oasis-open.org <cti@lists.oasis-open.org>
    on behalf of Kelley, Sarah E. <skelley@mitre.org> Sent: Wednesday, October 31, 2018 12:04:09 PM To: Allan Thomson; Gary Jay Katz; cti@lists.oasis-open.org Subject: [EXT] RE: [cti] Option 1 vs. Option 7 Powerpoint Example   Allan (and all),   I think this is a really profound realization.
    I have been coming at this with a state-based idea, as in give me
    everything you know about X . Having worked in a SOC, I also realize the
    use cases for event-based data.  I, for one, would be curious
    about your possible ideas for being able to represent both.   Thanks,   Sarah Kelley Lead Cybersecurity Engineer, T8B2 Defensive Operations The MITRE Corporation 703-983-6242 skelley@mitre.org   From: cti@lists.oasis-open.org <cti@lists.oasis-open.org>
    On Behalf Of Allan Thomson Sent: Wednesday, October 31, 2018 10:44 AM To: Gary Jay Katz <gary.katz@FireEye.com>; cti@lists.oasis-open.org Subject: Re: [cti] Option 1 vs. Option 7 Powerpoint Example   Gary thanks for sharing.   One of the things that I ve realized as
    part of reviewing the use cases is the differences in how we talk about
    things.   I ve come to the conclusion that we are
    talking about 2 different aspects of our problem set.   Event-based Vs State-based   From my perspective, Option 1 is really
    representing a state of entities and connectedness between those entities
    after multiple events have occurred.   Option 7 (current observed-data model)
    represents discrete individual events that would occur over time.   This would be similar to having a state-machine
    defined (I,.e. the resultant intel model) and then individual events (intel
    events) that cause you to update the state-model.   Think of the intel model as the campaigns,
    actors, email-addresses, ips .etc.   Think of the events as changes to those
    intel objects (i.e. observed data model).   Conflating the 2 of these is not the solution.   The question is whether we are defining
    STIX to communicate event-based model or a state-based model.   I think we should consider the possibility
    that both are valid things to do and therefore we should consider how to
    approach using STIX to clearly articulate when we are   Sending discrete events that have
    been observed at a specific time and any associated meta data to that event Sending a state model that represents
    the collective intelligence and associated relationships across that state
    built up over time   I think if we recognize that both models
    require something different and factor that into our STIX data model discussion
    then we might find a way to solve both.   I have some ideas but this email is already
    too long.   Allan   From: " cti@lists.oasis-open.org "
    < cti@lists.oasis-open.org >
    on behalf of Gary Jay Katz < gary.katz@FireEye.com > Date: Wednesday, October 31, 2018 at 6:20 AM To: " cti@lists.oasis-open.org "
    < cti@lists.oasis-open.org > Subject: [cti] Option 1 vs. Option 7 Powerpoint Example   Thank you to everyone for taking time to
    discuss Option 1 and Option 7.  As usual, Jane did an excellent job
    capturing the discussion, including screen shots from the presentation.
     John-Mark requested that I resend out the slides from yesterday s
    discussion with any updates, which I believe is valuable as it will allow
    us to continue the discussion over email.  As an update, I did include
    an optional Observed Data object in Option 1.  The inclusion of an
    Observed Data object would show that the producer directly observed the
    email with an attachment vs. indirectly having that information (ex. Gathered
    the information from external reporting).     The purpose of this example is to show
    a very reasonable use-case for a cyber security analyst and discuss how
    that data can be represented in the STIX standard using either Option 1
    or Option 7.  I have not created JSON versions of the example in both
    Option 1 and Option 7 form.  My assumption would be, to Allan s point,
    that the Option 1 version is more verbose, although only slightly.  This
    does mean that the data size of the document is larger and to earlier points,
    in other use cases this difference can be even larger.  This example
    though highlights an even larger issue.  Option 7 does not allow some
    common useful relationships to be represented within the format.  Having
    relationships to show that a file found in an email, which analysis shows
    beacons to a C2 that resolved to a specific domain is not possible in Option
    7.  The receiver must infer this information through 3 disjointed
    objects.     Our greatest risk to adoption is not asking
    companies and organizations to update their STIX implementations to support
    Option 1 or the increase in data size for certain use cases.  Our
    greatest risk is having the trust of the userbase.  One day, far in
    the future (if we do our jobs well), analysts will not even be aware of
    STIX being used in the background to transfer their data.  Today though,
    they are paying attention, they will be asked by their leadership to look
    at the standard and provide their opinion on how valuable it is to adopt
    STIX, and analysts will not understand why they can t represent a file
    found in an email has a C2 beacon that resolves to a domain (or something
    similar).  The answer to just trust us that the receiver is going
    to auto-correlate that information back together, probably won t fly.
        Some of these issues were masked by the
    limited use cases possible in STIX 2.0 and 2.1.  As the standard evolves
    to support Malware, Infrastructure and Incident objects these issues will
    become very pronounced.  We will continue to put band-aids on the
    standard as a result of the deficiency (ex. See the malware proposal submitted
    by Jeff Mates and I earlier this year).  Option 1 will resolve these
    deficiencies.  Will it take work and effort, yes, but that work and
    effort will only continue to grow the longer we wait.   -Gary   Some Metrics on the two implementations
    of the use cases: Option 1: 8 Objects (1 optional)  (2 SDOs, 6
    SOOs) 5 Embedded refs (3 optional) 6 Relationships (6 SROs)   Option 7 15 Objects* (6 SDOs, 9 cyber observables) 5 Embedded refs (2 within Malware not shown) 2 Relationships (2 SROs) Note some relationships
    in the example cannot be represented in this option * Cyber Observables are not full objects
    in this option.  Therefore must be embedded in an SDO but are lighter
    objects that take less text to represent.     From: < cti@lists.oasis-open.org >
    on behalf of Jane Ginn < jg@ctin.us > Date: Tuesday, October 30, 2018 at 6:10 PM To: " cti@lists.oasis-open.org "
    < cti@lists.oasis-open.org > Subject: [cti] Groups - Weekly Working Call - Notes uploaded   Submitter's message CTI TC: Here is the PDF of the notes from the Working Call. I included the figures
    in this version. Best regards, -- Ms. Jane Ginn Document
    Name : Weekly
    Working Call - Notes Description Discussed Option 1 and Option 7 for Cyber Observables Download
    Latest Revision Public
    Download Link Submitter : Ms. Jane Ginn Group : OASIS Cyber Threat Intelligence (CTI) TC Folder : Meeting Notes Date submitted : 2018-10-30 15:10:05   This email and any attachments thereto
    may contain private, confidential, and/or privileged material for the sole
    use of the intended recipient. Any review, copying, or distribution of
    this email (or any attachments thereto) by others is strictly prohibited.
    If you are not the intended recipient, please contact the sender immediately
    and permanently delete the original and any copies of this email and any
    attachments thereto. [attachment "image002.jpg" deleted by Jason
    Keirstead/CanEast/IBM]



  • 6.  RE: [EXT] RE: [cti] Option 1 vs. Option 7 Powerpoint Example

    Posted 11-01-2018 11:59
    I’d like to explore what you define here as option c, which I believe is close to option 7 from the original list. It seems like Observed data would basically become a container object that could contain one or more (related) observables, BUT where we also take whatever relationships from the Observables Section that need to be SROs and define them that way. The ones that are immutable could stay embedded. (The examples for this, as Sean was saying, are that something like Domain resolving to IP would be an SRO because it can change and the sender email address on an email object would be embedded as it’s fixed.)   It would almost make observed-data act like a generic wrapper around observables, so they would look SDO-ish (if you put one observable inside one observed-data object), which might solve some of the same cases that Option 1 is trying to solve.   The major hangup I can see with this approach, which would need to be fleshed out and resolved, is if we have we let observed-data act like a generic SDO that can house any observable, the relationships (SROs) become more difficult. I don’t know that they’re impossible, just more difficult.   This seems like a middle ground that might allow both camps to have (at least some of) their cake and eat it too.   Thanks,   Sarah Kelley Lead Cybersecurity Engineer, T8B2 Defensive Operations The MITRE Corporation 703-983-6242 skelley@mitre.org   From: cti@lists.oasis-open.org <cti@lists.oasis-open.org> On Behalf Of Bret Jordan Sent: Wednesday, October 31, 2018 3:23 PM To: Kelley, Sarah E. <skelley@mitre.org>; Allan Thomson <athomson@lookingglasscyber.com>; Gary Jay Katz <gary.katz@FireEye.com>; cti@lists.oasis-open.org Subject: [cti] Re: [EXT] RE: [cti] Option 1 vs. Option 7 Powerpoint Example   All,   When I look at it, the problem I see / hear from Gary / Jeff / Sean / Sarah is that internal relationships on the observable container do not really work for what people need. Thus having external relationships and all their goodness is what people need.   You can do that in one of three ways.     a) Make cyber observables top level objects (option 1 prime from previous discussions) b) Provide some sort of deep referencing inside of Observed Data (people have consistently shot down this idea) c) Try and pull out the relationships that really need to be external and leave the rest. (A combination of option 7 with some tweaks that John Wunder has brought up)   So options a, b, and c are technically all possible, though option b where you do deep referencing inside of an Observed Data is just awful and will probably be the no-end-to-pain.   Bret   From: cti@lists.oasis-open.org < cti@lists.oasis-open.org > on behalf of Kelley, Sarah E. < skelley@mitre.org > Sent: Wednesday, October 31, 2018 12:04:09 PM To: Allan Thomson; Gary Jay Katz; cti@lists.oasis-open.org Subject: [EXT] RE: [cti] Option 1 vs. Option 7 Powerpoint Example   Allan (and all),   I think this is a really profound realization. I have been coming at this with a “state-based” idea, as in “give me everything you know about X”. Having worked in a SOC, I also realize the use cases for “event-based” data.  I, for one, would be curious about your possible ideas for being able to represent both.   Thanks,   Sarah Kelley Lead Cybersecurity Engineer, T8B2 Defensive Operations The MITRE Corporation 703-983-6242 skelley@mitre.org   From: cti@lists.oasis-open.org < cti@lists.oasis-open.org > On Behalf Of Allan Thomson Sent: Wednesday, October 31, 2018 10:44 AM To: Gary Jay Katz < gary.katz@FireEye.com >; cti@lists.oasis-open.org Subject: Re: [cti] Option 1 vs. Option 7 Powerpoint Example   Gary – thanks for sharing.   One of the things that I’ve realized as part of reviewing the use cases is the differences in how we talk about things.   I’ve come to the conclusion that we are talking about 2 different aspects of our problem set.   Event-based Vs State-based   From my perspective, Option 1 is really representing a state of entities and connectedness between those entities after multiple events have occurred.   Option 7 (current observed-data model) represents discrete individual events that would occur over time.   This would be similar to having a state-machine defined (I,.e. the resultant intel model) and then individual events (intel events) that cause you to update the state-model.   Think of the intel model as the campaigns, actors, email-addresses, ips….etc.   Think of the events as changes to those intel objects (i.e. observed data model).   Conflating the 2 of these is not the solution.   The question is whether we are defining STIX to communicate event-based model or a state-based model.   I think we should consider the possibility that both are valid things to do and therefore we should consider how to approach using STIX to clearly articulate when we are   Sending discrete events that have been observed at a specific time and any associated meta data to that event Sending a state model that represents the collective intelligence and associated relationships across that state built up over time   I think if we recognize that both models require something different and factor that into our STIX data model discussion then we might find a way to solve both.   I have some ideas but this email is already too long.   Allan   From: " cti@lists.oasis-open.org " < cti@lists.oasis-open.org > on behalf of Gary Jay Katz < gary.katz@FireEye.com > Date: Wednesday, October 31, 2018 at 6:20 AM To: " cti@lists.oasis-open.org " < cti@lists.oasis-open.org > Subject: [cti] Option 1 vs. Option 7 Powerpoint Example   Thank you to everyone for taking time to discuss Option 1 and Option 7.  As usual, Jane did an excellent job capturing the discussion, including screen shots from the presentation.  John-Mark requested that I resend out the slides from yesterday’s discussion with any updates, which I believe is valuable as it will allow us to continue the discussion over email.  As an update, I did include an optional Observed Data object in Option 1.  The inclusion of an Observed Data object would show that the producer directly observed the email with an attachment vs. indirectly having that information (ex. Gathered the information from external reporting).    The purpose of this example is to show a very reasonable use-case for a cyber security analyst and discuss how that data can be represented in the STIX standard using either Option 1 or Option 7.  I have not created JSON versions of the example in both Option 1 and Option 7 form.  My assumption would be, to Allan’s point, that the Option 1 version is more verbose, although only slightly.  This does mean that the data size of the document is larger and to earlier points, in other use cases this difference can be even larger.  This example though highlights an even larger issue.  Option 7 does not allow some common useful relationships to be represented within the format.  Having relationships to show that a file found in an email, which analysis shows beacons to a C2 that resolved to a specific domain is not possible in Option 7.  The receiver must infer this information through 3 disjointed objects.    Our greatest risk to adoption is not asking companies and organizations to update their STIX implementations to support Option 1 or the increase in data size for certain use cases.  Our greatest risk is having the trust of the userbase.  One day, far in the future (if we do our jobs well), analysts will not even be aware of STIX being used in the background to transfer their data.  Today though, they are paying attention, they will be asked by their leadership to look at the standard and provide their opinion on how valuable it is to adopt STIX, and analysts will not understand why they can’t represent a file found in an email has a C2 beacon that resolves to a domain (or something similar).  The answer to just trust us that the receiver is going to auto-correlate that information back together, probably won’t fly.    Some of these issues were masked by the limited use cases possible in STIX 2.0 and 2.1.  As the standard evolves to support Malware, Infrastructure and Incident objects these issues will become very pronounced.  We will continue to put band-aids on the standard as a result of the deficiency (ex. See the malware proposal submitted by Jeff Mates and I earlier this year).  Option 1 will resolve these deficiencies.  Will it take work and effort, yes, but that work and effort will only continue to grow the longer we wait.   -Gary   Some Metrics on the two implementations of the use cases: Option 1: 8 Objects (1 optional)  (2 SDOs, 6 SOOs) 5 Embedded refs (3 optional) 6 Relationships (6 SROs)   Option 7 15 Objects* (6 SDOs, 9 cyber observables) 5 Embedded refs (2 within Malware not shown) 2 Relationships (2 SROs) – Note some relationships in the example cannot be represented in this option * Cyber Observables are not full objects in this option.  Therefore must be embedded in an SDO but are lighter objects that take less text to represent.     From: < cti@lists.oasis-open.org > on behalf of Jane Ginn < jg@ctin.us > Date: Tuesday, October 30, 2018 at 6:10 PM To: " cti@lists.oasis-open.org " < cti@lists.oasis-open.org > Subject: [cti] Groups - Weekly Working Call - Notes uploaded   Submitter's message CTI TC: Here is the PDF of the notes from the Working Call. I included the figures in this version. Best regards, -- Ms. Jane Ginn Document Name : Weekly Working Call - Notes Description Discussed Option 1 and Option 7 for Cyber Observables Download Latest Revision Public Download Link Submitter : Ms. Jane Ginn Group : OASIS Cyber Threat Intelligence (CTI) TC Folder : Meeting Notes Date submitted : 2018-10-30 15:10:05   This email and any attachments thereto may contain private, confidential, and/or privileged material for the sole use of the intended recipient. Any review, copying, or distribution of this email (or any attachments thereto) by others is strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto.


  • 7.  RE: [EXT] RE: [cti] Option 1 vs. Option 7 Powerpoint Example

    Posted 11-01-2018 12:45
    Hey all,   Bret alluded to some changes I suggested…I had kept these to a small group because I wasn’t sure whether it would really help the conversation, but maybe it’s time to share them.  It was also the hybrid proposal I tried and failed to describe at the F2F.   I didn’t really have this terminology at the time, but the changes are kind of along the lines of acknowledging the distinction that Allan brought up about about stateful vs. event-based information. The way I would think about it, the “stateful” relationships would be described using standard SROs using Observed Data as a container, while the description of an object itself (e.g. something you collected from a network observation) should be defined all in one place using our current approach. This enables the important use cases like relating another SDO to an observable object or describing like, domain name resolution, but doesn’t require that everyone rewrite how they currently produce an observable object definition.   Link is here: https://gist.github.com/johnwunder/a72eea28c6c1ad3a570b55d6a60583f7   FWIW I do think that the use case to capture relationships between other SDOs and observable objects are important, as is the ability to describe things like domain name resolutions in a more intuitive way. That’s what I came up with this option. It may not be exactly what the Option 1 folks want, but it does let you describe these things so that we can’t currently and so gives us an option to move forward with a smaller changeset while still enabling these use cases.   John   From: cti@lists.oasis-open.org <cti@lists.oasis-open.org> On Behalf Of Kelley, Sarah E. Sent: Thursday, November 1, 2018 7:59 AM To: Bret Jordan <Bret_Jordan@symantec.com>; Allan Thomson <athomson@lookingglasscyber.com>; Gary Jay Katz <gary.katz@FireEye.com>; cti@lists.oasis-open.org Subject: [cti] RE: [EXT] RE: [cti] Option 1 vs. Option 7 Powerpoint Example   I’d like to explore what you define here as option c, which I believe is close to option 7 from the original list. It seems like Observed data would basically become a container object that could contain one or more (related) observables, BUT where we also take whatever relationships from the Observables Section that need to be SROs and define them that way. The ones that are immutable could stay embedded. (The examples for this, as Sean was saying, are that something like Domain resolving to IP would be an SRO because it can change and the sender email address on an email object would be embedded as it’s fixed.)   It would almost make observed-data act like a generic wrapper around observables, so they would look SDO-ish (if you put one observable inside one observed-data object), which might solve some of the same cases that Option 1 is trying to solve.   The major hangup I can see with this approach, which would need to be fleshed out and resolved, is if we have we let observed-data act like a generic SDO that can house any observable, the relationships (SROs) become more difficult. I don’t know that they’re impossible, just more difficult.   This seems like a middle ground that might allow both camps to have (at least some of) their cake and eat it too.   Thanks,   Sarah Kelley Lead Cybersecurity Engineer, T8B2 Defensive Operations The MITRE Corporation 703-983-6242 skelley@mitre.org   From: cti@lists.oasis-open.org < cti@lists.oasis-open.org > On Behalf Of Bret Jordan Sent: Wednesday, October 31, 2018 3:23 PM To: Kelley, Sarah E. < skelley@mitre.org >; Allan Thomson < athomson@lookingglasscyber.com >; Gary Jay Katz < gary.katz@FireEye.com >; cti@lists.oasis-open.org Subject: [cti] Re: [EXT] RE: [cti] Option 1 vs. Option 7 Powerpoint Example   All,   When I look at it, the problem I see / hear from Gary / Jeff / Sean / Sarah is that internal relationships on the observable container do not really work for what people need. Thus having external relationships and all their goodness is what people need.   You can do that in one of three ways.     a) Make cyber observables top level objects (option 1 prime from previous discussions) b) Provide some sort of deep referencing inside of Observed Data (people have consistently shot down this idea) c) Try and pull out the relationships that really need to be external and leave the rest. (A combination of option 7 with some tweaks that John Wunder has brought up)   So options a, b, and c are technically all possible, though option b where you do deep referencing inside of an Observed Data is just awful and will probably be the no-end-to-pain.   Bret   From: cti@lists.oasis-open.org < cti@lists.oasis-open.org > on behalf of Kelley, Sarah E. < skelley@mitre.org > Sent: Wednesday, October 31, 2018 12:04:09 PM To: Allan Thomson; Gary Jay Katz; cti@lists.oasis-open.org Subject: [EXT] RE: [cti] Option 1 vs. Option 7 Powerpoint Example   Allan (and all),   I think this is a really profound realization. I have been coming at this with a “state-based” idea, as in “give me everything you know about X”. Having worked in a SOC, I also realize the use cases for “event-based” data.  I, for one, would be curious about your possible ideas for being able to represent both.   Thanks,   Sarah Kelley Lead Cybersecurity Engineer, T8B2 Defensive Operations The MITRE Corporation 703-983-6242 skelley@mitre.org   From: cti@lists.oasis-open.org < cti@lists.oasis-open.org > On Behalf Of Allan Thomson Sent: Wednesday, October 31, 2018 10:44 AM To: Gary Jay Katz < gary.katz@FireEye.com >; cti@lists.oasis-open.org Subject: Re: [cti] Option 1 vs. Option 7 Powerpoint Example   Gary – thanks for sharing.   One of the things that I’ve realized as part of reviewing the use cases is the differences in how we talk about things.   I’ve come to the conclusion that we are talking about 2 different aspects of our problem set.   Event-based Vs State-based   From my perspective, Option 1 is really representing a state of entities and connectedness between those entities after multiple events have occurred.   Option 7 (current observed-data model) represents discrete individual events that would occur over time.   This would be similar to having a state-machine defined (I,.e. the resultant intel model) and then individual events (intel events) that cause you to update the state-model.   Think of the intel model as the campaigns, actors, email-addresses, ips….etc.   Think of the events as changes to those intel objects (i.e. observed data model).   Conflating the 2 of these is not the solution.   The question is whether we are defining STIX to communicate event-based model or a state-based model.   I think we should consider the possibility that both are valid things to do and therefore we should consider how to approach using STIX to clearly articulate when we are   Sending discrete events that have been observed at a specific time and any associated meta data to that event Sending a state model that represents the collective intelligence and associated relationships across that state built up over time   I think if we recognize that both models require something different and factor that into our STIX data model discussion then we might find a way to solve both.   I have some ideas but this email is already too long.   Allan   From: " cti@lists.oasis-open.org " < cti@lists.oasis-open.org > on behalf of Gary Jay Katz < gary.katz@FireEye.com > Date: Wednesday, October 31, 2018 at 6:20 AM To: " cti@lists.oasis-open.org " < cti@lists.oasis-open.org > Subject: [cti] Option 1 vs. Option 7 Powerpoint Example   Thank you to everyone for taking time to discuss Option 1 and Option 7.  As usual, Jane did an excellent job capturing the discussion, including screen shots from the presentation.  John-Mark requested that I resend out the slides from yesterday’s discussion with any updates, which I believe is valuable as it will allow us to continue the discussion over email.  As an update, I did include an optional Observed Data object in Option 1.  The inclusion of an Observed Data object would show that the producer directly observed the email with an attachment vs. indirectly having that information (ex. Gathered the information from external reporting).    The purpose of this example is to show a very reasonable use-case for a cyber security analyst and discuss how that data can be represented in the STIX standard using either Option 1 or Option 7.  I have not created JSON versions of the example in both Option 1 and Option 7 form.  My assumption would be, to Allan’s point, that the Option 1 version is more verbose, although only slightly.  This does mean that the data size of the document is larger and to earlier points, in other use cases this difference can be even larger.  This example though highlights an even larger issue.  Option 7 does not allow some common useful relationships to be represented within the format.  Having relationships to show that a file found in an email, which analysis shows beacons to a C2 that resolved to a specific domain is not possible in Option 7.  The receiver must infer this information through 3 disjointed objects.    Our greatest risk to adoption is not asking companies and organizations to update their STIX implementations to support Option 1 or the increase in data size for certain use cases.  Our greatest risk is having the trust of the userbase.  One day, far in the future (if we do our jobs well), analysts will not even be aware of STIX being used in the background to transfer their data.  Today though, they are paying attention, they will be asked by their leadership to look at the standard and provide their opinion on how valuable it is to adopt STIX, and analysts will not understand why they can’t represent a file found in an email has a C2 beacon that resolves to a domain (or something similar).  The answer to just trust us that the receiver is going to auto-correlate that information back together, probably won’t fly.    Some of these issues were masked by the limited use cases possible in STIX 2.0 and 2.1.  As the standard evolves to support Malware, Infrastructure and Incident objects these issues will become very pronounced.  We will continue to put band-aids on the standard as a result of the deficiency (ex. See the malware proposal submitted by Jeff Mates and I earlier this year).  Option 1 will resolve these deficiencies.  Will it take work and effort, yes, but that work and effort will only continue to grow the longer we wait.   -Gary   Some Metrics on the two implementations of the use cases: Option 1: 8 Objects (1 optional)  (2 SDOs, 6 SOOs) 5 Embedded refs (3 optional) 6 Relationships (6 SROs)   Option 7 15 Objects* (6 SDOs, 9 cyber observables) 5 Embedded refs (2 within Malware not shown) 2 Relationships (2 SROs) – Note some relationships in the example cannot be represented in this option * Cyber Observables are not full objects in this option.  Therefore must be embedded in an SDO but are lighter objects that take less text to represent.     From: < cti@lists.oasis-open.org > on behalf of Jane Ginn < jg@ctin.us > Date: Tuesday, October 30, 2018 at 6:10 PM To: " cti@lists.oasis-open.org " < cti@lists.oasis-open.org > Subject: [cti] Groups - Weekly Working Call - Notes uploaded   Submitter's message CTI TC: Here is the PDF of the notes from the Working Call. I included the figures in this version. Best regards, -- Ms. Jane Ginn Document Name : Weekly Working Call - Notes Description Discussed Option 1 and Option 7 for Cyber Observables Download Latest Revision Public Download Link Submitter : Ms. Jane Ginn Group : OASIS Cyber Threat Intelligence (CTI) TC Folder : Meeting Notes Date submitted : 2018-10-30 15:10:05   This email and any attachments thereto may contain private, confidential, and/or privileged material for the sole use of the intended recipient. Any review, copying, or distribution of this email (or any attachments thereto) by others is strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto.


  • 8.  Re: [EXT] [cti] Option 1 vs. Option 7 Powerpoint Example

    Posted 11-01-2018 02:34
    Gary, I like the way you have phrased the issue in this email, and after talking with you and Jeff, I agree.  The needs for this that we have identified is just the tip of the iceberg.  Malware, Infrastructure, and Incident are going to need some way of connecting to individual cyber observables.  Without that, organizations will be forced to just do their own thing.  We need to think long and hard about things like this: " Having relationships to show that a file found in an email, which analysis shows beacons to a C2 that resolved to a specific domain is not possible in Option 7." Or as Sarah brought up, Threat Actor X used this IP address with this Domain Name from Jan-2018 to Feb-2018 and registered that Domain Name in May 2017 using the email address foo@example.com. That domain name while attached to IP address 1 was used as a C2 location from 2016-2017 and the domain name while attached to IP address 2 was used as an exfil site from 2017-2018. Bret From: cti@lists.oasis-open.org <cti@lists.oasis-open.org> on behalf of Gary Jay Katz <gary.katz@FireEye.com> Sent: Wednesday, October 31, 2018 7:20:48 AM To: cti@lists.oasis-open.org Subject: [EXT] [cti] Option 1 vs. Option 7 Powerpoint Example   Thank you to everyone for taking time to discuss Option 1 and Option 7.  As usual, Jane did an excellent job capturing the discussion, including screen shots from the presentation.  John-Mark requested that I resend out the slides from yesterday’s discussion with any updates, which I believe is valuable as it will allow us to continue the discussion over email.  As an update, I did include an optional Observed Data object in Option 1.  The inclusion of an Observed Data object would show that the producer directly observed the email with an attachment vs. indirectly having that information (ex. Gathered the information from external reporting).    The purpose of this example is to show a very reasonable use-case for a cyber security analyst and discuss how that data can be represented in the STIX standard using either Option 1 or Option 7.  I have not created JSON versions of the example in both Option 1 and Option 7 form.  My assumption would be, to Allan’s point, that the Option 1 version is more verbose, although only slightly.  This does mean that the data size of the document is larger and to earlier points, in other use cases this difference can be even larger.  This example though highlights an even larger issue.  Option 7 does not allow some common useful relationships to be represented within the format.  Having relationships to show that a file found in an email, which analysis shows beacons to a C2 that resolved to a specific domain is not possible in Option 7.  The receiver must infer this information through 3 disjointed objects.    Our greatest risk to adoption is not asking companies and organizations to update their STIX implementations to support Option 1 or the increase in data size for certain use cases.  Our greatest risk is having the trust of the userbase.  One day, far in the future (if we do our jobs well), analysts will not even be aware of STIX being used in the background to transfer their data.  Today though, they are paying attention, they will be asked by their leadership to look at the standard and provide their opinion on how valuable it is to adopt STIX, and analysts will not understand why they can’t represent a file found in an email has a C2 beacon that resolves to a domain (or something similar).  The answer to just trust us that the receiver is going to auto-correlate that information back together, probably won’t fly.    Some of these issues were masked by the limited use cases possible in STIX 2.0 and 2.1.  As the standard evolves to support Malware, Infrastructure and Incident objects these issues will become very pronounced.  We will continue to put band-aids on the standard as a result of the deficiency (ex. See the malware proposal submitted by Jeff Mates and I earlier this year).  Option 1 will resolve these deficiencies.  Will it take work and effort, yes, but that work and effort will only continue to grow the longer we wait.   -Gary   Some Metrics on the two implementations of the use cases: Option 1: 8 Objects (1 optional)  (2 SDOs, 6 SOOs) 5 Embedded refs (3 optional) 6 Relationships (6 SROs)   Option 7 15 Objects* (6 SDOs, 9 cyber observables) 5 Embedded refs (2 within Malware not shown) 2 Relationships (2 SROs) – Note some relationships in the example cannot be represented in this option * Cyber Observables are not full objects in this option.  Therefore must be embedded in an SDO but are lighter objects that take less text to represent.     From: <cti@lists.oasis-open.org> on behalf of Jane Ginn <jg@ctin.us> Date: Tuesday, October 30, 2018 at 6:10 PM To: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org> Subject: [cti] Groups - Weekly Working Call - Notes uploaded   Submitter's message CTI TC: Here is the PDF of the notes from the Working Call. I included the figures in this version. Best regards, -- Ms. Jane Ginn Document Name : Weekly Working Call - Notes Description Discussed Option 1 and Option 7 for Cyber Observables Download Latest Revision Public Download Link Submitter : Ms. Jane Ginn Group : OASIS Cyber Threat Intelligence (CTI) TC Folder : Meeting Notes Date submitted : 2018-10-30 15:10:05   This email and any attachments thereto may contain private, confidential, and/or privileged material for the sole use of the intended recipient. Any review, copying, or distribution of this email (or any attachments thereto) by others is strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto.