CTI STIX Subcommittee

 View Only
  • 1.  Finalizing Bundle

    Posted 05-31-2016 16:53




    All,
     
    Like we talked about on the call, “bundle” is getting very close. You can see the current definition here:

    https://docs.google.com/document/d/1HJqhvzO35h62gQGPvghVRIAtQrZn3_J__0UcDAj-NXY/edit#heading=h.c9oxowopqs2 .
     
    As I see it, we just have two major open questions:
     
    1.       
    Should we include an “id” field? If it’s included, should it be required? I’ve been seeing pretty decent consensus that it should be added.
    2.       
    Should we include a “most_restrictive_marking” field? Is it an array? What is the definition, and how does it work across the marking types? We had general consensus to include this field on the
    working calls but since then further questions about how exactly it should work have come up.
     
    My opinions on these two items are:
     
    1.       
    We should just include the ID field, and make it clear on the definition for “bundle” that it CAN be used for tracking but that consumers absolutely don’t need to track it. We also should require
    it…as a matter of principle, I don’t think there should be any optional ID fields in STIX. If something has an ID, it should be required.
    2.       
    I don’t really understand this topic enough, but I will say that in order to include it we need to have a much better definition for how it should work. I’m including it so long as the people who
    want to have it can propose a definition that is workable, unambiguous, and easy for people to implement. I’m also happy leaving it off: the people that need it can define it as a custom field in their implementations and then others don’t need to figure it
    out.
     
    Thoughts? Maybe we can also finish this topic off by Friday as well?
     
    John






  • 2.  Re: [cti-stix] Finalizing Bundle

    Posted 05-31-2016 16:57
    I think having a bundle with a mandatory ID, that we ourselves recommend people don't use for anything, is very confusing. - Jason Keirstead STSM, Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security www.securityintelligence.com Without data, all you are is just another person with an opinion - Unknown "Wunder, John A." ---05/31/2016 01:53:33 PM---All, Like we talked about on the call, “bundle” is getting very close. You can see the current defin From: "Wunder, John A." <jwunder@mitre.org> To: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> Date: 05/31/2016 01:53 PM Subject: [cti-stix] Finalizing Bundle Sent by: <cti-stix@lists.oasis-open.org> All, Like we talked about on the call, “bundle” is getting very close. You can see the current definition here: https://docs.google.com/document/d/1HJqhvzO35h62gQGPvghVRIAtQrZn3_J__0UcDAj-NXY/edit#heading=h.c9oxowopqs2 . As I see it, we just have two major open questions: 1. Should we include an “id” field? If it’s included, should it be required? I’ve been seeing pretty decent consensus that it should be added. 2. Should we include a “most_restrictive_marking” field? Is it an array? What is the definition, and how does it work across the marking types? We had general consensus to include this field on the working calls but since then further questions about how exactly it should work have come up. My opinions on these two items are: 1. We should just include the ID field, and make it clear on the definition for “bundle” that it CAN be used for tracking but that consumers absolutely don’t need to track it. We also should require it…as a matter of principle, I don’t think there should be any optional ID fields in STIX. If something has an ID, it should be required. 2. I don’t really understand this topic enough, but I will say that in order to include it we need to have a much better definition for how it should work. I’m including it so long as the people who want to have it can propose a definition that is workable, unambiguous, and easy for people to implement. I’m also happy leaving it off: the people that need it can define it as a custom field in their implementations and then others don’t need to figure it out. Thoughts? Maybe we can also finish this topic off by Friday as well? John




  • 3.  Re: [cti-stix] Finalizing Bundle

    Posted 05-31-2016 19:16
    I am in favor of supporting those that need an ID on bundle.  I also agree it should be required.   I would be in favor of punting on most_restrictive_marking until we understand it better. This could easily be added in the winter release. Bret Sent from my Commodore 64 On May 31, 2016, at 10:53 AM, Wunder, John A. < jwunder@mitre.org > wrote: All,   Like we talked about on the call, “bundle” is getting very close. You can see the current definition here: https://docs.google.com/document/d/1HJqhvzO35h62gQGPvghVRIAtQrZn3_J__0UcDAj-NXY/edit#heading=h.c9oxowopqs2 .   As I see it, we just have two major open questions:   1.        Should we include an “id” field? If it’s included, should it be required? I’ve been seeing pretty decent consensus that it should be added. 2.        Should we include a “most_restrictive_marking” field? Is it an array? What is the definition, and how does it work across the marking types? We had general consensus to include this field on the working calls but since then further questions about how exactly it should work have come up.   My opinions on these two items are:   1.        We should just include the ID field, and make it clear on the definition for “bundle” that it CAN be used for tracking but that consumers absolutely don’t need to track it. We also should require it…as a matter of principle, I don’t think there should be any optional ID fields in STIX. If something has an ID, it should be required. 2.        I don’t really understand this topic enough, but I will say that in order to include it we need to have a much better definition for how it should work. I’m including it so long as the people who want to have it can propose a definition that is workable, unambiguous, and easy for people to implement. I’m also happy leaving it off: the people that need it can define it as a custom field in their implementations and then others don’t need to figure it out.   Thoughts? Maybe we can also finish this topic off by Friday as well?   John


  • 4.  Re: [cti-stix] Finalizing Bundle

    Posted 06-01-2016 08:01
      |   view attached
    I believe we need an ID to support the transition period from sharing over non-TAXII communication methods to TAXII based communication. The potential negatives of one extra line in a file potentially multiple megabytes in size and the potential confusion that the ID needs to be tracked are minor in my opinion. The generated bundle ID will not need to be tracked by the producer if they don't want to. It is up to the consuming implementation if they want to track the incoming bundle IDs, and that will only be if they want to track incoming bundles to identify missing ones.  An example use case would be if someone was trying to get STIX packages into MISP. They could use a python script to poll a STIX server and then use python to interact with the MISP server to upload the STIX file. The bundle ID is only used by the python script to ensure that it has processed all the files, and can even be used to 'name' the files as they are written to disk.  Cheers Terry MacDonald   Chief Product Officer M:   +61-407-203-026 E:   terry.macdonald@cosive.com W:   www.cosive.com On Wed, Jun 1, 2016 at 5:16 AM, Jordan, Bret < bret.jordan@bluecoat.com > wrote: I am in favor of supporting those that need an ID on bundle.  I also agree it should be required.   I would be in favor of punting on most_restrictive_marking until we understand it better. This could easily be added in the winter release. Bret Sent from my Commodore 64 On May 31, 2016, at 10:53 AM, Wunder, John A. < jwunder@mitre.org > wrote: All,   Like we talked about on the call, “bundle” is getting very close. You can see the current definition here: https://docs.google.com/document/d/1HJqhvzO35h62gQGPvghVRIAtQrZn3_J__0UcDAj-NXY/edit#heading=h.c9oxowopqs2 .   As I see it, we just have two major open questions:   1.        Should we include an “id” field? If it’s included, should it be required? I’ve been seeing pretty decent consensus that it should be added. 2.        Should we include a “most_restrictive_marking” field? Is it an array? What is the definition, and how does it work across the marking types? We had general consensus to include this field on the working calls but since then further questions about how exactly it should work have come up.   My opinions on these two items are:   1.        We should just include the ID field, and make it clear on the definition for “bundle” that it CAN be used for tracking but that consumers absolutely don’t need to track it. We also should require it…as a matter of principle, I don’t think there should be any optional ID fields in STIX. If something has an ID, it should be required. 2.        I don’t really understand this topic enough, but I will say that in order to include it we need to have a much better definition for how it should work. I’m including it so long as the people who want to have it can propose a definition that is workable, unambiguous, and easy for people to implement. I’m also happy leaving it off: the people that need it can define it as a custom field in their implementations and then others don’t need to figure it out.   Thoughts? Maybe we can also finish this topic off by Friday as well?   John


  • 5.  RE: [cti-stix] Finalizing Bundle

    Posted 06-01-2016 13:19
      |   view attached
    Hi All, What's the current bundle structure? -Marlon   From: cti-stix@lists.oasis-open.org on behalf of Terry MacDonald Sent: Wednesday, June 01, 2016 4:00:28 AM To: Jordan, Bret Cc: Wunder, John A.; cti-stix@lists.oasis-open.org Subject: Re: [cti-stix] Finalizing Bundle I believe we need an ID to support the transition period from sharing over non-TAXII communication methods to TAXII based communication. The potential negatives of one extra line in a file potentially multiple megabytes in size and the potential confusion that the ID needs to be tracked are minor in my opinion. The generated bundle ID will not need to be tracked by the producer if they don't want to. It is up to the consuming implementation if they want to track the incoming bundle IDs, and that will only be if they want to track incoming bundles to identify missing ones.  An example use case would be if someone was trying to get STIX packages into MISP. They could use a python script to poll a STIX server and then use python to interact with the MISP server to upload the STIX file. The bundle ID is only used by the python script to ensure that it has processed all the files, and can even be used to 'name' the files as they are written to disk.  Cheers Terry MacDonald   Chief Product Officer M:   +61-407-203-026 E:   terry.macdonald@cosive.com W:   www.cosive.com On Wed, Jun 1, 2016 at 5:16 AM, Jordan, Bret < bret.jordan@bluecoat.com > wrote: I am in favor of supporting those that need an ID on bundle.  I also agree it should be required.   I would be in favor of punting on most_restrictive_marking until we understand it better. This could easily be added in the winter release. Bret Sent from my Commodore 64 On May 31, 2016, at 10:53 AM, Wunder, John A. < jwunder@mitre.org > wrote: All,   Like we talked about on the call, “bundle” is getting very close. You can see the current definition here: https://docs.google.com/document/d/1HJqhvzO35h62gQGPvghVRIAtQrZn3_J__0UcDAj-NXY/edit#heading=h.c9oxowopqs2 .   As I see it, we just have two major open questions:   1.        Should we include an “id” field? If it’s included, should it be required? I’ve been seeing pretty decent consensus that it should be added. 2.        Should we include a “most_restrictive_marking” field? Is it an array? What is the definition, and how does it work across the marking types? We had general consensus to include this field on the working calls but since then further questions about how exactly it should work have come up.   My opinions on these two items are:   1.        We should just include the ID field, and make it clear on the definition for “bundle” that it CAN be used for tracking but that consumers absolutely don’t need to track it. We also should require it…as a matter of principle, I don’t think there should be any optional ID fields in STIX. If something has an ID, it should be required. 2.        I don’t really understand this topic enough, but I will say that in order to include it we need to have a much better definition for how it should work. I’m including it so long as the people who want to have it can propose a definition that is workable, unambiguous, and easy for people to implement. I’m also happy leaving it off: the people that need it can define it as a custom field in their implementations and then others don’t need to figure it out.   Thoughts? Maybe we can also finish this topic off by Friday as well?   John


  • 6.  Re: [cti-stix] Finalizing Bundle

    Posted 06-01-2016 13:29
      |   view attached




    It’s in the Google Doc at the link below:
    https://docs.google.com/document/d/1HJqhvzO35h62gQGPvghVRIAtQrZn3_J__0UcDAj-NXY/edit#heading=h.c9oxowopqs2
     
    -          
    Tentatively has an ID
    -          
    Does not have markings
    -          
    Does not have “most_restrictive_marking”
    -          
    Contains individual lists of TLOs
     

    From:
    Marlon Taylor <Marlon.Taylor@hq.dhs.gov>
    Date: Wednesday, June 1, 2016 at 9:18 AM
    To: Terry MacDonald <terry.macdonald@cosive.com>, "Jordan, Bret" <bret.jordan@bluecoat.com>
    Cc: "Wunder, John A." <jwunder@mitre.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
    Subject: RE: [cti-stix] Finalizing Bundle


     



    Hi All,

    What's the current bundle structure?

    -Marlon

     




    From: cti-stix@lists.oasis-open.org on behalf of Terry MacDonald
    Sent: Wednesday, June 01, 2016 4:00:28 AM
    To: Jordan, Bret
    Cc: Wunder, John A.; cti-stix@lists.oasis-open.org
    Subject: Re: [cti-stix] Finalizing Bundle


    I believe we need an ID to support the transition period from sharing over non-TAXII communication methods to TAXII based communication. The potential negatives of one extra line in a file potentially multiple megabytes in size and the
    potential confusion that the ID needs to be tracked are minor in my opinion. The generated bundle ID will not need to be tracked by the producer if they don't want to. It is up to the consuming implementation if they want to track the incoming bundle IDs,
    and that will only be if they want to track incoming bundles to identify missing ones. 


     


    An example use case would be if someone was trying to get STIX packages into MISP. They could use a python script to poll a STIX server and then use python to interact with the MISP server to upload the STIX file. The bundle ID is only
    used by the python script to ensure that it has processed all the files, and can even be used to 'name' the files as they are written to disk. 










    Cheers


     



    Terry MacDonald   Chief Product Officer


     





     


    M:   +61-407-203-026


    E:   terry.macdonald@cosive.com


    W:   www.cosive.com


     



     


     






     

    On Wed, Jun 1, 2016 at 5:16 AM, Jordan, Bret < bret.jordan@bluecoat.com > wrote:



    I am in favor of supporting those that need an ID on bundle.  I also agree it should be required.  


     


    I would be in favor of punting on most_restrictive_marking until we understand it better. This could easily be added in the winter release.


     


    Bret

    Sent from my Commodore 64





    On May 31, 2016, at 10:53 AM, Wunder, John A. < jwunder@mitre.org > wrote:




    All,
     
    Like we talked about on the call, “bundle” is getting very close. You can see the current definition here:

    https://docs.google.com/document/d/1HJqhvzO35h62gQGPvghVRIAtQrZn3_J__0UcDAj-NXY/edit#heading=h.c9oxowopqs2 .
     
    As I see it, we just have two major open questions:
     
    1.       
    Should we include an “id” field? If it’s included, should it be required? I’ve been seeing pretty decent consensus that it should be added.
    2.       
    Should we include a “most_restrictive_marking” field? Is it an array? What is the definition, and how does it work across the marking types? We had general consensus to include this field on the working calls but since then further
    questions about how exactly it should work have come up.
     
    My opinions on these two items are:
     
    1.       
    We should just include the ID field, and make it clear on the definition for “bundle” that it CAN be used for tracking but that consumers absolutely don’t need to track it. We also should require it…as a matter of principle, I
    don’t think there should be any optional ID fields in STIX. If something has an ID, it should be required.
    2.       
    I don’t really understand this topic enough, but I will say that in order to include it we need to have a much better definition for how it should work. I’m including it so long as the people who want to have it can propose a
    definition that is workable, unambiguous, and easy for people to implement. I’m also happy leaving it off: the people that need it can define it as a custom field in their implementations and then others don’t need to figure it out.
     
    Thoughts? Maybe we can also finish this topic off by Friday as well?
     
    John








     











  • 7.  RE: [cti-stix] Finalizing Bundle

    Posted 06-01-2016 13:35
      |   view attached
    Thanks for the list John! I can't access the link right now so pardon sny questions that I would otherwise be able to answer myself if I read the page.   From: cti-stix@lists.oasis-open.org on behalf of Wunder, John A. Sent: Wednesday, June 01, 2016 9:28:26 AM To: Taylor, Marlon; Terry MacDonald; Jordan, Bret Cc: cti-stix@lists.oasis-open.org Subject: Re: [cti-stix] Finalizing Bundle It’s in the Google Doc at the link below: https://docs.google.com/document/d/1HJqhvzO35h62gQGPvghVRIAtQrZn3_J__0UcDAj-NXY/edit#heading=h.c9oxowopqs2   -           Tentatively has an ID -           Does not have markings -           Does not have “most_restrictive_marking” -           Contains individual lists of TLOs   From: Marlon Taylor <Marlon.Taylor@hq.dhs.gov> Date: Wednesday, June 1, 2016 at 9:18 AM To: Terry MacDonald <terry.macdonald@cosive.com>, "Jordan, Bret" <bret.jordan@bluecoat.com> Cc: "Wunder, John A." <jwunder@mitre.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> Subject: RE: [cti-stix] Finalizing Bundle   Hi All, What's the current bundle structure? -Marlon   From: cti-stix@lists.oasis-open.org on behalf of Terry MacDonald Sent: Wednesday, June 01, 2016 4:00:28 AM To: Jordan, Bret Cc: Wunder, John A.; cti-stix@lists.oasis-open.org Subject: Re: [cti-stix] Finalizing Bundle I believe we need an ID to support the transition period from sharing over non-TAXII communication methods to TAXII based communication. The potential negatives of one extra line in a file potentially multiple megabytes in size and the potential confusion that the ID needs to be tracked are minor in my opinion. The generated bundle ID will not need to be tracked by the producer if they don't want to. It is up to the consuming implementation if they want to track the incoming bundle IDs, and that will only be if they want to track incoming bundles to identify missing ones.    An example use case would be if someone was trying to get STIX packages into MISP. They could use a python script to poll a STIX server and then use python to interact with the MISP server to upload the STIX file. The bundle ID is only used by the python script to ensure that it has processed all the files, and can even be used to 'name' the files as they are written to disk.  Cheers   Terry MacDonald   Chief Product Officer     M:   +61-407-203-026 E:   terry.macdonald@cosive.com W:   www.cosive.com         On Wed, Jun 1, 2016 at 5:16 AM, Jordan, Bret < bret.jordan@bluecoat.com > wrote: I am in favor of supporting those that need an ID on bundle.  I also agree it should be required.     I would be in favor of punting on most_restrictive_marking until we understand it better. This could easily be added in the winter release.   Bret Sent from my Commodore 64 On May 31, 2016, at 10:53 AM, Wunder, John A. < jwunder@mitre.org > wrote: All,   Like we talked about on the call, “bundle” is getting very close. You can see the current definition here: https://docs.google.com/document/d/1HJqhvzO35h62gQGPvghVRIAtQrZn3_J__0UcDAj-NXY/edit#heading=h.c9oxowopqs2 .   As I see it, we just have two major open questions:   1.        Should we include an “id” field? If it’s included, should it be required? I’ve been seeing pretty decent consensus that it should be added. 2.        Should we include a “most_restrictive_marking” field? Is it an array? What is the definition, and how does it work across the marking types? We had general consensus to include this field on the working calls but since then further questions about how exactly it should work have come up.   My opinions on these two items are:   1.        We should just include the ID field, and make it clear on the definition for “bundle” that it CAN be used for tracking but that consumers absolutely don’t need to track it. We also should require it…as a matter of principle, I don’t think there should be any optional ID fields in STIX. If something has an ID, it should be required. 2.        I don’t really understand this topic enough, but I will say that in order to include it we need to have a much better definition for how it should work. I’m including it so long as the people who want to have it can propose a definition that is workable, unambiguous, and easy for people to implement. I’m also happy leaving it off: the people that need it can define it as a custom field in their implementations and then others don’t need to figure it out.   Thoughts? Maybe we can also finish this topic off by Friday as well?   John  


  • 8.  RE: [cti-stix] Finalizing Bundle

    Posted 06-01-2016 13:38
      |   view attached
    Continuing my unfinished message... Where are the markings defined? -Marlon   From: cti-stix@lists.oasis-open.org on behalf of Taylor, Marlon Sent: Wednesday, June 01, 2016 9:35:01 AM To: Wunder, John A.; Terry MacDonald; Jordan, Bret Cc: cti-stix@lists.oasis-open.org Subject: RE: [cti-stix] Finalizing Bundle Thanks for the list John! I can't access the link right now so pardon sny questions that I would otherwise be able to answer myself if I read the page.   From: cti-stix@lists.oasis-open.org on behalf of Wunder, John A. Sent: Wednesday, June 01, 2016 9:28:26 AM To: Taylor, Marlon; Terry MacDonald; Jordan, Bret Cc: cti-stix@lists.oasis-open.org Subject: Re: [cti-stix] Finalizing Bundle It’s in the Google Doc at the link below: https://docs.google.com/document/d/1HJqhvzO35h62gQGPvghVRIAtQrZn3_J__0UcDAj-NXY/edit#heading=h.c9oxowopqs2   -           Tentatively has an ID -           Does not have markings -           Does not have “most_restrictive_marking” -           Contains individual lists of TLOs   From: Marlon Taylor <Marlon.Taylor@hq.dhs.gov> Date: Wednesday, June 1, 2016 at 9:18 AM To: Terry MacDonald <terry.macdonald@cosive.com>, "Jordan, Bret" <bret.jordan@bluecoat.com> Cc: "Wunder, John A." <jwunder@mitre.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> Subject: RE: [cti-stix] Finalizing Bundle   Hi All, What's the current bundle structure? -Marlon   From: cti-stix@lists.oasis-open.org on behalf of Terry MacDonald Sent: Wednesday, June 01, 2016 4:00:28 AM To: Jordan, Bret Cc: Wunder, John A.; cti-stix@lists.oasis-open.org Subject: Re: [cti-stix] Finalizing Bundle I believe we need an ID to support the transition period from sharing over non-TAXII communication methods to TAXII based communication. The potential negatives of one extra line in a file potentially multiple megabytes in size and the potential confusion that the ID needs to be tracked are minor in my opinion. The generated bundle ID will not need to be tracked by the producer if they don't want to. It is up to the consuming implementation if they want to track the incoming bundle IDs, and that will only be if they want to track incoming bundles to identify missing ones.    An example use case would be if someone was trying to get STIX packages into MISP. They could use a python script to poll a STIX server and then use python to interact with the MISP server to upload the STIX file. The bundle ID is only used by the python script to ensure that it has processed all the files, and can even be used to 'name' the files as they are written to disk.  Cheers   Terry MacDonald   Chief Product Officer     M:   +61-407-203-026 E:   terry.macdonald@cosive.com W:   www.cosive.com         On Wed, Jun 1, 2016 at 5:16 AM, Jordan, Bret < bret.jordan@bluecoat.com > wrote: I am in favor of supporting those that need an ID on bundle.  I also agree it should be required.     I would be in favor of punting on most_restrictive_marking until we understand it better. This could easily be added in the winter release.   Bret Sent from my Commodore 64 On May 31, 2016, at 10:53 AM, Wunder, John A. < jwunder@mitre.org > wrote: All,   Like we talked about on the call, “bundle” is getting very close. You can see the current definition here: https://docs.google.com/document/d/1HJqhvzO35h62gQGPvghVRIAtQrZn3_J__0UcDAj-NXY/edit#heading=h.c9oxowopqs2 .   As I see it, we just have two major open questions:   1.        Should we include an “id” field? If it’s included, should it be required? I’ve been seeing pretty decent consensus that it should be added. 2.        Should we include a “most_restrictive_marking” field? Is it an array? What is the definition, and how does it work across the marking types? We had general consensus to include this field on the working calls but since then further questions about how exactly it should work have come up.   My opinions on these two items are:   1.        We should just include the ID field, and make it clear on the definition for “bundle” that it CAN be used for tracking but that consumers absolutely don’t need to track it. We also should require it…as a matter of principle, I don’t think there should be any optional ID fields in STIX. If something has an ID, it should be required. 2.        I don’t really understand this topic enough, but I will say that in order to include it we need to have a much better definition for how it should work. I’m including it so long as the people who want to have it can propose a definition that is workable, unambiguous, and easy for people to implement. I’m also happy leaving it off: the people that need it can define it as a custom field in their implementations and then others don’t need to figure it out.   Thoughts? Maybe we can also finish this topic off by Friday as well?   John  


  • 9.  Re: [cti-stix] Finalizing Bundle

    Posted 06-01-2016 13:48
      |   view attached




    Markings are applied at the TLO level, and reference marking definitions that are contained just as a list in the bundle (like any other TLO).
     

    From:
    Marlon Taylor <Marlon.Taylor@hq.dhs.gov>
    Date: Wednesday, June 1, 2016 at 9:37 AM
    To: "Wunder, John A." <jwunder@mitre.org>, Terry MacDonald <terry.macdonald@cosive.com>, "Jordan, Bret" <bret.jordan@bluecoat.com>
    Cc: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
    Subject: RE: [cti-stix] Finalizing Bundle


     



    Continuing my unfinished message...

    Where are the markings defined?

    -Marlon

     




    From: cti-stix@lists.oasis-open.org on behalf of Taylor, Marlon
    Sent: Wednesday, June 01, 2016 9:35:01 AM
    To: Wunder, John A.; Terry MacDonald; Jordan, Bret
    Cc: cti-stix@lists.oasis-open.org
    Subject: RE: [cti-stix] Finalizing Bundle

    Thanks for the list John!

    I can't access the link right now so pardon sny questions that I would otherwise be able to answer myself if I read the page.







     




    From: cti-stix@lists.oasis-open.org on behalf of Wunder, John A.
    Sent: Wednesday, June 01, 2016 9:28:26 AM
    To: Taylor, Marlon; Terry MacDonald; Jordan, Bret
    Cc: cti-stix@lists.oasis-open.org
    Subject: Re: [cti-stix] Finalizing Bundle


    It’s in the Google Doc at the link below:
    https://docs.google.com/document/d/1HJqhvzO35h62gQGPvghVRIAtQrZn3_J__0UcDAj-NXY/edit#heading=h.c9oxowopqs2
     
    -          
    Tentatively has an ID
    -          
    Does not have markings
    -          
    Does not have “most_restrictive_marking”
    -          
    Contains individual lists of TLOs
     

    From:
    Marlon Taylor <Marlon.Taylor@hq.dhs.gov>
    Date: Wednesday, June 1, 2016 at 9:18 AM
    To: Terry MacDonald <terry.macdonald@cosive.com>, "Jordan, Bret" <bret.jordan@bluecoat.com>
    Cc: "Wunder, John A." <jwunder@mitre.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
    Subject: RE: [cti-stix] Finalizing Bundle


     



    Hi All,

    What's the current bundle structure?

    -Marlon

     




    From: cti-stix@lists.oasis-open.org on behalf of Terry MacDonald
    Sent: Wednesday, June 01, 2016 4:00:28 AM
    To: Jordan, Bret
    Cc: Wunder, John A.; cti-stix@lists.oasis-open.org
    Subject: Re: [cti-stix] Finalizing Bundle


    I believe we need an ID to support the transition period from sharing over non-TAXII communication methods to TAXII based communication. The potential negatives of one extra line in a file potentially multiple megabytes in size and the
    potential confusion that the ID needs to be tracked are minor in my opinion. The generated bundle ID will not need to be tracked by the producer if they don't want to. It is up to the consuming implementation if they want to track the incoming bundle IDs,
    and that will only be if they want to track incoming bundles to identify missing ones. 


     


    An example use case would be if someone was trying to get STIX packages into MISP. They could use a python script to poll a STIX server and then use python to interact with the MISP server to upload the STIX file. The bundle ID is only
    used by the python script to ensure that it has processed all the files, and can even be used to 'name' the files as they are written to disk. 










    Cheers


     



    Terry MacDonald   Chief Product Officer


     





     


    M:   +61-407-203-026


    E:   terry.macdonald@cosive.com


    W:   www.cosive.com


     



     


     






     

    On Wed, Jun 1, 2016 at 5:16 AM, Jordan, Bret < bret.jordan@bluecoat.com > wrote:



    I am in favor of supporting those that need an ID on bundle.  I also agree it should be required.  


     


    I would be in favor of punting on most_restrictive_marking until we understand it better. This could easily be added in the winter release.


     


    Bret

    Sent from my Commodore 64





    On May 31, 2016, at 10:53 AM, Wunder, John A. < jwunder@mitre.org > wrote:




    All,
     
    Like we talked about on the call, “bundle” is getting very close. You can see the current definition here:

    https://docs.google.com/document/d/1HJqhvzO35h62gQGPvghVRIAtQrZn3_J__0UcDAj-NXY/edit#heading=h.c9oxowopqs2 .
     
    As I see it, we just have two major open questions:
     
    1.       
    Should we include an “id” field? If it’s included, should it be required? I’ve been seeing pretty decent consensus that it should be added.
    2.       
    Should we include a “most_restrictive_marking” field? Is it an array? What is the definition, and how does it work across the marking types? We had general consensus to include this field on the working calls but since then further
    questions about how exactly it should work have come up.
     
    My opinions on these two items are:
     
    1.       
    We should just include the ID field, and make it clear on the definition for “bundle” that it CAN be used for tracking but that consumers absolutely don’t need to track it. We also should require it…as a matter of principle, I
    don’t think there should be any optional ID fields in STIX. If something has an ID, it should be required.
    2.       
    I don’t really understand this topic enough, but I will say that in order to include it we need to have a much better definition for how it should work. I’m including it so long as the people who want to have it can propose a
    definition that is workable, unambiguous, and easy for people to implement. I’m also happy leaving it off: the people that need it can define it as a custom field in their implementations and then others don’t need to figure it out.
     
    Thoughts? Maybe we can also finish this topic off by Friday as well?
     
    John