Design: Versioning

Discussion of the requirements, use cases, and design decisions around versioning.

Use Cases

• Party A issues new content
• Party A issues an update to existing content
• Party A revokes content that they issued
• Party B issues an update to content published by Party A (i.e. suggested revision)
• Party B issues a revoke for content published by Party A (i.e. suggested revoke)
• Party C confirms content has been revoked, purged, etc (i.e. confirmation. Note that no content is passed in this use case)

Current Implementation

Information about the current implementation is on the documentation site. A proposal for STIX 1.2 is here.

Pros

• Minor versioning use case is supported via a simple mechanism of timestamp updates. This allows for revisions within an organization to occur without churn in the related objects.
• Major versioning use case is supported via relationships, a well-known STIX construct used for many other uses. This means that implementors don't have to use completely separate logic for versioning.
• Doesn't make it clear what part of a construct is updated...you just get a new version without knowing what changed.

Cons

• Is not supported in CybOX, making versioning of CybOX constructs difficult (unless embedded in STIX constructs).
• Versioning of embedded/related constructs can be confusing. If I embed a TTP in an indicator and version the indicator does that also version the TTP?
• Does not support the requirement to describe the reasoning behind a version.
• Does not support transactional use cases (i.e. you tell me that you successfully purged an indicator I revoked)

Proposed Implementations

CRUD-Based

Pat Maroney has proposed a CRUD-based implementation:

1. ID based on UTC now = time of creation/revision
2. Type : {CReate, Revise, Delete}
3. Description of /Reason for change
4. Timestamp (effective date: past, present, future) preferably with full Timestamp timesecfrac precision

Version marking can be applied to anywhere in the path. With implied inheritance for all enclosed content from the marking point. Still allowing more granular specific marking for objects/etc. within same

In other words I can mark the whole STIX Package with initial creation & date. If I need to revise an object I re-issue the package with original versioning, mark the revised content (or content block for compound objects (e.g an object fully describing a file).

Because of the CREATE action and the allowance for versioning anywhere in a construct this would need to be implemented via some mechanism other than relationships.

Pros

• Has explicit action for content creation
• Maps well to existing transactional changes / database update approaches
• Very flexible and very clear what is updated

Cons

• Does not support transactional use cases (i.e. you tell me that you successfully purged an indicator I revoked)
• May be difficult to implement, as versioning can be applied anywhere rather than only in certain places.
• May be awkward in multi-party sharing scenarios: what happens if you get an UPDATE or a DELETE for something you don't have created yet?

Related Topics

Effective Date

Pat Maroney has proposed that all STIX constructs - not just Indicators - should have the concept of effective dates. See Design: Effective Dates.