[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: Re: Re: [cti] Re: [EXT] Re: [cti] Working Call Recap
Jason I really see and understand your use case. I think it is very valid. This is why I propose we do this at various levels so organizations can do it how they need. I think the key is, with these approaches there is no need to support these properties on individual objects since the SCO-LIST could be used for this. This would greatly simplify a lot of things with transport.
Bret
Thanks Bret.
I would be fine with any of the suggested options a) bundle changes b) taxii envelope changes c) identity properties where that identity is associated with creation of the object.
My preference would lie primarily with either a) or b). With a slight preference for a) because a bundle is and can be used to provide a wrapper of STIX content outside of TAXII transport whereas making the change for a TAXII transport only fixes TAXII not all cases on how STIX is exchanged.
The challenge with c) is that it would still require a property on every SCO to point to the identity creating the SCO and that somewhat defeats the purposes of a SCO (given that they are meant for re-use across any vendor that uses the same deterministic id).
allan
From:
Bret Jordan <Bret_Jordan@symantec.com>
Date: Friday, May 17, 2019 at 7:41 AM
To: Sean Barnum <sean.barnum@FireEye.com>, "drew.varner@ninefx.com"
<drew.varner@ninefx.com>, Allan Thomson <athomson@lookingglasscyber.com>
Cc: "Piazza, Rich" <rpiazza@mitre.org>, "Kelley,
Sarah E." <skelley@mitre.org>, "cti@lists.oasis-open.org"
<cti@lists.oasis-open.org>
Subject: Re: [cti] Re: [EXT] Re: [cti] Working Call Recap
From:Sean
Barnum <sean.barnum@FireEye.com>
Sent: Thursday, May 16, 2019 9:50:28 AM
To: drew.varner@ninefx.com; Allan Thomson
Cc: Piazza, Rich; Kelley, Sarah E.; Bret Jordan; cti@lists.oasis-open.org
Subject: Re: [cti] Re: [EXT] Re: [cti] Working Call Recap
> Bundles are a way to package STIX objects. They are not âtheâ way to package them. TAXII 2.1 packages them in an Envelope without a Bundle.
Sure, but this proposal does not require anyone to use Bundle.
If a producer/sharer wanted to exchange objects via TAXII without a Bundle (which I do not necessarily recommend) they would need to assert the properties on each object.
This proposal is simply providing a mechanism for producers/sharers who choose to use Bundle to convey their content in a vastly more efficient way that makes it practical/possible to use.
This does not preclude anyoneâs choices on how they wish to share. It simply provides a viable option for a portion of the community to be able to use STIX to share.
The alternative of forcing the properties onto ALL SCOs would basically double the size of most commonly shared high volume SCOs (IP addresses, URLs, DomainNames, etc). Bloat like that would make STIX impractical for many users and the Bundle approach proposal at hand offers a simple and effective solution.
Sean Barnum
Principal Architect
FireEye
M: 703.473.8262
E: sean.barnum@fireeye.com
From:
"drew.varner@ninefx.com" <drew.varner@ninefx.com>
Date: Thursday, May 16, 2019 at 10:23 AM
To: Allan Thomson <athomson@lookingglasscyber.com>
Cc: "Piazza, Rich" <rpiazza@mitre.org>, "Kelley,
Sarah E." <skelley@mitre.org>, Sean Barnum <sean.barnum@FireEye.com>,
Bret Jordan <Bret_Jordan@symantec.com>, "cti@lists.oasis-open.org"
<cti@lists.oasis-open.org>
Subject: Re: [cti] Re: [EXT] Re: [cti] Working Call Recap
We
removed it in 2.1 because we realized that a bundle could contain objects
of multiple versions. STIX objects have a spec_version property so they
are now-self-describing.
Bundles are a way to package STIX objects. They are not âtheâ way to
package them. TAXII 2.1 packages them in an Envelope without a Bundle.
On May 16, 2019, at 10:07 AM, Allan Thomson <athomson@lookingglasscyber.com>
wrote:
It was one example. There are other properties on bundle and my point remains.
If I remember rightly the reason we moved it (?) was because TAXII request/response took the version instead to make sure the bundle contained the right set of objects for the exchange. So instead of the bundle the TAXII req/response contained the version information.
Thatâs just another way of doing the same thing.
That is -> a parameter applied to a group of objects within a wrapper (in this case it would be TAXII req/resp).
I still think itâs a valid thing to do.
Allan
From:
"Piazza, Rich" <rpiazza@mitre.org>
Date: Thursday, May 16, 2019 at 6:48 AM
To: Allan Thomson <athomson@lookingglasscyber.com>,
"Kelley, Sarah E." <skelley@mitre.org>,
Sean Barnum <sean.barnum@FireEye.com>,
Bret Jordan <Bret_Jordan@symantec.com>
Cc: "cti@lists.oasis-open.org"
<cti@lists.oasis-open.org>
Subject: Re: [cti] Re: [EXT] Re: [cti] Working Call Recap
The spec_version property has been removed from Bundle in 2.1.
Whether or not this was the right decisionâ
From:
<cti@lists.oasis-open.org>
on behalf of Allan Thomson <athomson@lookingglasscyber.com>
Date: Thursday, May 16, 2019 at 9:30 AM
To: "Kelley, Sarah E." <skelley@mitre.org>,
Sean Barnum <sean.barnum@FireEye.com>,
Rich Piazza <rpiazza@mitre.org>,
Bret Jordan <Bret_Jordan@symantec.com>
Cc: "cti@lists.oasis-open.org"
<cti@lists.oasis-open.org>
Subject: Re: [cti] Re: [EXT] Re: [cti] Working Call Recap
Just because it is non-persistent does *not* mean that it can not convey meaning and value to the recipient on how to model/capture the objects within the bundle once they ingest those objects.
Just as the bundle conveys version information (stating that this bundle has objects with version X) then an additional property on the bundle for other aspects that apply to the objects in the bundle is really not that different.
STIX2 should focus on how to efficient and effectively transmit information between 2 or more systems.
It does not represent a database.
So I think the proposal does not break or undermine the current definition of Bundle and does allow consumers to read those properties and apply any logic on conversion to their internal database schemaâetc. appropriately quite easily just as much as the version property on a bundle is used.
Allan
From:
"cti@lists.oasis-open.org"
<cti@lists.oasis-open.org>
on behalf of "Kelley, Sarah E." <skelley@mitre.org>
Date: Thursday, May 16, 2019 at 4:40 AM
To: Sean Barnum <sean.barnum@FireEye.com>,
"Piazza, Rich" <rpiazza@mitre.org>,
Bret Jordan <Bret_Jordan@symantec.com>
Cc: "cti@lists.oasis-open.org"
<cti@lists.oasis-open.org>
Subject: RE: [cti] Re: [EXT] Re: [cti] Working Call Recap
Arenât bundles designed to be thrown away? So if the information is only kept at the bundle level for how the identifier is generated, you would lose that information as soon as the bundle drops on the floor. You could never retransmit with that information (in the use case that you were passing along data you didnât create), and the consumer wouldnât be able to go back and reference it in the future.
Am I missing something?
Sarah Kelley
Lead Cybersecurity Engineer, T8B2
Defensive Operations
The MITRE Corporation
703-983-6242
From:cti@lists.oasis-open.org<cti@lists.oasis-open.org>
On Behalf Of Sean Barnum
Sent: Wednesday, May 15, 2019 5:15 PM
To: Piazza, Rich <rpiazza@mitre.org>;
Bret Jordan <Bret_Jordan@symantec.com>
Cc: cti@lists.oasis-open.org
Subject: Re: [cti] Re: [EXT] Re: [cti] Working Call Recap
I see two options.
Sean Barnum
Principal Architect
FireEye
M: 703.473.8262
From:
<cti@lists.oasis-open.org>
on behalf of "Piazza, Rich" <rpiazza@mitre.org>
Date: Wednesday, May 15, 2019 at 3:56 PM
To: Bret Jordan <Bret_Jordan@symantec.com>,
Sean Barnum <sean.barnum@FireEye.com>
Cc: "cti@lists.oasis-open.org"
<cti@lists.oasis-open.org>
Subject: Re: [cti] Re: [EXT] Re: [cti] Working Call Recap
How do we handle bundles that contain SCOs with different methods of creating the UUID?
For instance - Iâm just passing on various SCOs I received from different producers, who used different methodsâ
From:
<cti@lists.oasis-open.org>
on behalf of Bret Jordan <Bret_Jordan@symantec.com>
Date: Wednesday, May 15, 2019 at 3:50 PM
To: Sean Barnum <sean.barnum@fireeye.com>
Cc: "cti@lists.oasis-open.org"
<cti@lists.oasis-open.org>
Subject: [cti] Re: [EXT] Re: [cti] Working Call Recap
After talking with Sean on the phone about this, even though this is very late in the game, I think this really makes a lot of sense. I think if we would have thought about this during the Mini-Group we probably would have done this from the get go.
Basically, to be really clear, what he is proposing is that we move the id_method and id_method_details from individual SCOs to the Bundle.
The pros I see are:
1) less bloat on the wire
2) simplify some of the indicator text
We can talk about this in next weekâs working call.
Bret
Sent from my Commodore 128D
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050
On May 15, 2019, at 8:33 PM, Sean Barnum <sean.barnum@fireeye.com>
wrote:
I have reviewed the changes highlighted below and added various comments in the doc.
I see that Bret has already accepted many of them.
There is one very major issue we have with a proposed change that would require id_method and id_method_details on EVERY SCO for a producer using a non-default approach for deterministic id generation.
This proposed change would require MASSIVE unnecessary bloat in STIX content as the same exact ~7 lines of JSON would need to be added to every SCO produced. Given the fact that we (and I am sure others) deal with SCOs on the scale of billions this proposed change would make STIX untenable as an option for us.
I would like to propose an alternate approach that I think achieves the intended purpose in a MUCH more efficient and unbloated fashion.
I propose that the id_method and id_method_details properties be added to the Bundle object and would assert the deterministic id method used for content within the bundle.
Sean Barnum
Principal Architect
FireEye
M: 703.473.8262
From:
<cti@lists.oasis-open.org>
on behalf of Bret Jordan <Bret_Jordan@symantec.com>
Date: Tuesday, May 14, 2019 at 5:56 PM
To: "cti@lists.oasis-open.org"
<cti@lists.oasis-open.org>
Subject: [cti] Working Call Recap
a) 2.7 Hashes
b) 3.2 Spec Version
c) 10.13 Infrastructure Type Vocabulary
d) 4.3 Course of Action os_execution_envs
e) 4.13 Observed Data
f) 4.18 Vulnerability Relationships
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.
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.
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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]