[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [cti] Re: [EXT] Re: [cti] Working Call Recap
All,
I would like to step back and focus this discussion a bit, since we seem to be all over the place. First a bit of background to bring everyone up to speed.
1) Back at the DC3 F2F the main objection to having SCOs be TLOs was the explosion of objects with the same data (e.g.. ip address 1.2.3.4). At that point, many said we could use deterministic IDs, but also at that point NO ONE has produced a solid proposal for how that could or should be done. Thanks to Allan's works, we now have a solution that solves that problem.
2) Some people will want to use deterministic IDs to try and figure out of content is the same or not. On the flip side, some people will not care at all, and will just treat every IDs as unique. We can not force people to pay attention to the IDs.
3) It is super critical that we do not have un-intended collisions on IDs. The importances of this is carved in stone. Our whole versioning model and graph design hinges on this.
4) Drew is correct, we removed the spec_version from Bundle because we realized that using a spec_version on bundle to describe the spec version of the content in side the bundle was wrong.
5) A bundle in STIX or an envelope in TAXII can contain meta data about the data it transmits. This is perfectly valid.
6) There has been significant concerned raised many times over about bloat on SCOs. We also need to remember as Allan reminds us, that STIX is about "TRANSPORT" it is not about how your local system stores or uses data locally. It is an "interchange" format. As such, we should constantly remind ourselves of that. Yes, even I need to be reminded of this from time to time.
My _personal_ proposal:
We no longer look at "id_method" and "id_method_details" as common properties. We do, however, add them to the STIX Bundle and we may consider adding them to the TAXII envelope and or TAXII http headers. But these properties would no longer be an option on SCOs themselves. I would also be open to adding these properties to an identity object as well. This way if someone wanted to say that they "ALWAYS" generate their IDs in this method, they can just do it via the identity object.
Producers SHOULD tell consumers about how their IDs were created. But they are not required to do so. What they are required to do is guarantee that non-SCO ID's are globally unique and do not un-intentionally collide with someone else's IDs. Meaning, they SHOULD be UUIDv4 or the likes. If they want to use UUIDv5 then it is up to them to figure out a namespace and such that makes sure they do not collide.
For consumers that want to know and track the information about how the IDs were created, they can. If they do not care, they do not care. For organizations that want to track how the IDs were created so they can re-share that information back out, then they can do so, how ever they want in their datastore. But these fields will not be used as part of any future digital signatures as they are purely meta-data that may be learned outside of STIX.
I would also suggest that we add the spec_version back to Bundle and say that it represents the spec version of the Bundle container. This way we can add extra meta data "things" to the bundle at a later time if needed.
Bret
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>
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.
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]