Re: Question

Bret - <apologize for the long-winded answer but this is a complicated topic that you can't necessarily just fit into a simple response>

Its an interesting question and a good one. My answer would be 'it depends on the objective of stating that your intelligence supports both STIX 2.0 and STIX 2.1 and the intended outcome'.

For example, if you have purely STIX 2.0 objects and no new objects or properties that were introduced in STIX2.1 in your content then this is obviously an easy answer to just provide the same content with the different version marking in the bundle. This is the base case for interoperability that we would want to verify as part of future interoperability tests. So recipients that are STIX2.0 can receive the same content as would STIX2.1 recipients would.

The more complicated scenarios come with the other examples you raise. I think its helpful to break those examples down so that we can answer the question.

1) New Properties ONLY

- STIX 2.1 version of STIX 2.0 object with new properties that were introduced in STIX2.1

- in this case the recipient would have to handle the new properties similar to how custom properties would be handled that the recipient does not understand.

- Therefore, I would suggest that if the producer says they support both STIX 2.1 and STIX 2.0 versions of the object where the only difference is new properties, then the producer just has a single version of the object that includes all new properties and it is incumbent on the recipient to accept the STIX2.1 object and ignore the additional fields. Effectively this means that STIX2.0 recipients must handle any new properties introduced in STIX2.1 or as custom properties the same way. It is up to the STIX2.0 recipient whether they handle processing the STIx2.1 properties or custom properties beyond making sure they dont reject the content completely. See the Interop Test Documents for these tests.

- This only works where there are no changes to the meaning/definition of properties defined in STIX 2.0 that have changed in STIX2.1. i.e. a breaking change.

2) New STIX2.1 object ONLY, separate unrelated STIX 2.0 objects in bundle

- STIX2.1 objects introduced in the bundle but they are not related to any STIX2.0 objects by relationship

- in this case the recipient has to treat those new STIX2.1 objects as custom objects in the bundle too. The producer could still produce the same bundle (with the unrelated STIX2.0 and STIX2.1 objects) and the recipient would just handle the STIX2.1 objects as per our custom object interoperability tests define. That is, it is up to the recipient whether they keep those custom objects or they discard them but they should not just reject the content of the bundle completely.

- Again it is a product choice and preference on whether the product does anything more than parse the custom/STIX2.1 properties beyond accepting the content and parsing it correctly.

3) STIX2.1 objects that are combined via relationships to STIX2.0 objects in bundle

- I suggest that again a STIX2.0 client has to treat this like custom objects that have been related to STIX 2.0 objects. There is no mandate that the STIX2.0 client has to support the custom objects per se but they are also required to not reject out of hand.

- However, from a best practices perspective, I think products that are STIX2.0 that receive STIX2.1 content (put it another way -> Lots of custom objects) will result in many incompatibilities if much of the content shared is a combination of STIX2.0 + STIX2.1 (or custom) related objects. Therefore in practice, products should warn that much of the content they are receiving is being ignored and therefore may be incomplete or unusable.

-> But that choice is up to the product and how they treat custom/new STIX 2.1 objects.

In summary:

1) STIX2.1 content should be handled by STIX2.0 recipients as per the rules of interoperability for custom content defines.

2) Its a product choice, whether the STIX2.0 recipient does anything further beyond parsing the content and not rejecting the content completely.

3) If a STIX2.1 producer does not wish a STIX2.0 recipient to discard new properties or new STIX2.1 related content then they should just state that they only support STIX2.1 clients and avoid the compatibility issues.

Allan

From: cti-stix@lists.oasis-open.org <cti-stix@lists.oasis-open.org> on behalf of Bret Jordan <Bret_Jordan@symantec.com>
Sent: Thursday, October 5, 2017 3:22 AM
To: cti-stix@lists.oasis-open.org
Subject: [cti-stix] Question

I opened this issue in the TAXII Github issue tracker, but it has philosophical / ethical implication for STIX. STIX nor TAXII really addresses this yet..

Ref: https://github.com/oasis-tcs/cti-taxii2/issues/14

-- copy from issue tracker --

Say my server supports STIX 2.0 and STIX 2.1 content. I get some data that is in STIX 2.1 format. Then someone comes along and asks for content in STIX 2.0 format. What do I do with the fields, properties, objects, relationship types, vocab terms, etc that are not valid in STIX 2.0?

What happens in a STIX Bundle or Report that has content that is in both STIX 2.0 and STIX 2.1. Meaning, what happens if it has indicators and notes and opinions. Do you send the indicator and not the note and options? Do you prune the notes and opinions from the report or bundle ? What do you do with confidence fields? Do you delete the confidence field? Does that mean you need to rev the modified timestamp or create a new ID? What happens with digital signatures for this content ?

Bret

cti-stix message