Closed nicocti closed 2 years ago
My impressions are that:
From a STIX content consumer point of view, the extension definition IDs seen where extensions are used, are analogous to reference properties (whose value is STIX ID(s)). Consumers must be prepared to deal with IDs of STIX objects they don't possess. Section 3.3 includes the statement: ... ID references can refer to objects to which the consumer/producer may not currently have. This specification does not address the implementation of ID reference resolution.
In other words, the spec allows this situation but does not tell consumers what to do. The matter is left up to implementations, I guess.
From a STIX content producer point of view, section 7.3 has this to say: If a producer does not include the STIX Extension Definition object with the STIX objects that use it, consumers should refer to section 3.3 for information in resolving references.
(And section 3.3 is as described above.) This implies producers need not include the extension definitions along with the objects which use the extensions.
So, my read is that not including the extension definitions alongside the objects which use the extensions doesn't make your content non-compliant. In fact, I think from a large-scale design perspective, if you had to include the definition alongside every usage, it would create a lot of wasteful repetition (of the definition objects). I think you would want the definition objects to be made available, but separately from all of their usages. Consumers could acquire the definitions once, and locally store and reuse them.
For smaller scale usage, maybe including extension definitions alongside their usages would be convenient. I think that decision is up to you. This library does not force inclusion of extension definitions in bundles, and I don't think it should.
Hello @chisholm
Thanks for your detailed answer. It makes perfect sense.
I wonder if the TAXII spec could introduce a standard endpoint to retrieve extension definitions from a producer.
@nicocti - using TAXII to access objects that are referenced within a Bundle, but not part of the Bundle, is something that has been discussed, especially for Extension_Definitions.
On the other hand, the TC for STIX is working on an Extension Definition use policy document, and one of the things it proposes is the use of the Common STIX Object Repository (https://github.com/oasis-open/cti-stix-common-objects) as community resource for discovering extension definition objects.
Another solution might be to create a TAXII collection for holding your extension definitions, and then telling your sharing partners to use that collection for this purpose. Not ideal because it wouldn't be standardized, but you wouldn't need to wait for any future TAXII spec updates.
What @clenk mentioned makes a lot of sense, because your extension definition might not be something that is appropriate for the common object repository (i.e., something just for your trust group).
Thanks for your insights.
I'm actually working on new & extended cyber observables to better translate threat hunting investigations (eg. a TLS Fingerprint entity for JA3 & JARM). This is internal stuff for now, but we might get in touch with the TC in the future once stabilized.
Hello,
I used Custom Extensions on some entities (using https://stix2.readthedocs.io/en/latest/guide/extensions.html). If I understand the 2.1 spec correctly, I'll need to export my Extensions Definitions along my entities to be Stix compliant.
It seems that serializing my entities within a Bundle won't export the Extensions Definitions. Should a Bundle with objects containing custom Extensions include related Extension Definitions when serialized ?