Stix Difficulties: There are too many ways to update an Object (Versioning)

[terrymacdonald]

PROBLEM

In the current version of STIX, an object is identified by a combination of its Object ID, and the Timestamp. One can think of the Object ID + Timestamp representing the composite primary key.
There are two ways to issue an updated STIX Object in the current version of STIX. (information here: http://stixproject.github.io/documentation/concepts/versioning/)

An Incremental Update only updates the Timestamp. This indicates there is a slight change to the underlying object, as it retains the original Object ID; the later timestamp indicates to the receiving consumer that the new object should overwrite the old one. It is an implicit update.

A Major Update creates a completely new STIX Object, with a modified Object ID + Timestamp. This indicates there is a major change to the underlying object, one large enough to cause a completely new object to be issued. The new STIX Object includes an explicit relationship to the original Object ID + Timestamp, with a type of 'Supersedes' to indicate to the receiving consumer that the new object supersedes the old one. It is an explicit update.

A large problem is that there is no definition (or agreement) as to what update mechanism should be used. The STIX guidance states:

"Current suggested practices suggest using an incremental update whenever you're making very minor changes to a construct that don't change its inherent meaning. Adding an alias to a threat actor, for example, would be an incremental update. Additionally, incremental updates can be used within an organization while it is developing a more final version of the construct in order to avoid churn on IDs. Major updates, on the other hand, are suggested for anything that changes the inherent meaning of a construct or changes of content between organizations. Changing a TTP from "phishing" to "spear phishing", for example, would be a major update because even though phishing and spear phishing are similar the inherent meaning of the construct changed."

Another problem is the recent discussion suggesting using hashes to generate the UUIDs for objects. The use of an Object ID + Timestamp as a composite key does not work with Incremental Updates. If a producer made a mistake and had to reissue the Indicator with a modification, that would result in a completely different Object ID if we were using a hashing function to generate the IDs.

POTENTIAL ANSWER

This could be fixed by enforcing all updates to be new objects (with new Object IDs) with explicitly defined relationships to the old object IDs.

This would mean that:
 

• A STIX object only ever gets 'issued' once.
• That STIX object cannot be updated.
• An object that supersedes the original object must have a new Object ID, and a top-level relationship object describing that the new object supersedes the old object.
• The Object ID can be generated from a hash of the STIX Object contents