Clarification/Conformance on Preservation of STIX

[marlontaylor]

Originally posted on the mailing list https://lists.oasis-open.org/archives/cti/202104/msg00006.html

Additional specific instances to be addressed in the table within the mailing list post: • All optional fields – not required per conformance • Extensions used in both Section 7 and Section 3.2 common properties • Specification use of “parse”

[jordan2175]

The definition of "parse" is ambiguous. To address this would be a material change.

[allant0]

You can't modify someone else's intel without creating a new object with a new ID. This is part of interop tests and has existed for years as a requirement. In fact, if someone is modifying someone else's intel and either adding or removing content I would argue this is both a) fraud (in a commercial environment b) bad practice for an intel source to be modifying someone else's intel causing the destination to think the intel was original defined by 1 source when in fact its defined by multiple sources in a chain. This is effectively messing with the intel supply chain.

Would any other industry allow a distributor to modify a product without it being explicitly approved and identified as such? Imagine if this happened with food, water or any other consumed products.

Imagine if a bad actor were to get into the middle of the supply chain and modify the content to help themselves avoid detection? Is that different from a 'legitimate' modification by a 'legimitmate' intel supply chain product? There is none.

Do not change this.

[jordan2175]

We did not add anything in the conformance section that talks about optional properties. This is a good find and catch. We should probably address this in the future. About the general comment about preserving STIX, here is what I sent to the list.

This issue has been discussed at length over and over. The consensus of the TC is with the text as it is written. From a level of specificity the versioning rules are general and apply to all of STIX object. However, there is a caveat and additional clarification that was given to Custom Properties. That text was well understood, the ramification of it well understood, and what it meant was well understood and debated. This is how standards are written. Broad rules that cover everything and when needed specific sometimes other rules are given for very specific purposes. That was the case here.

It is also important to note that there was a very small and very vocal minority of people that disagreed with that decision that was made by the TC ever so long ago. But the majority made a decision and it has been in the document for a long time, early early on in STIX 2.0.

There are all kinds of issues in STIX that various people, even myself, do not like. If we could go back in time, I am sure we would change some of them. But that is the nature of consensus and community built things.

[jordan2175]

We talked about this on the call today, and decided to push any changes to address this to a future release.

[jmgnc]

This was briefly discussed on the interop call today.

In reviewing 12.1 STIX Consumer point 1 says:

It MUST support parsing all required properties for the content that it consumes.

I agree that parsing is undefined, BUT I believe that changing content to STIX content (which is defined) will help clarify things. As the statement stands, it is not clear what "content" the statement is referring to. Is it referring to the properties? IMO, this change would be classified as a BUG, and be non-material.

This change would make it clear, that a STIX object that has required properties must be considered valid and parseable. It does not define WHAT the consumer should do.

======

As for requiring support for parsing optional properties, I do wish the conformance clause contained it, BUT I do think it would be a material change. I also don't think anyone will produce such a product that cannot parse many/most of the optional properties. I do think that adding required support for parsing optional properties should be added in the next version/draft.

[srrelitz2]

Reviewed existing language. Request and it is a breaking change -- for conformance on both Required and optional properties. Also extensions would be in this discussion. Moving to STIX 2.2 work.