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