-
Notifications
You must be signed in to change notification settings - Fork 21
Design: Versioning
Discussion of the requirements, use cases, and design decisions around versioning.
Note: this is an area for discussion, not for ground truth. Please see the documentation on http://stixproject.github.io if you're looking for information on how things are done now. Otherwise, edit away.
- 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 additional content on top of that published by Party A (i.e. suggested expansion)
- 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)
- Party A asserts new relationships between content they've already published
- Party B asserts new relationships between content published by Party A (and potentially other parties, including themselves).
Information about the current implementation is on the documentation site. A proposal for STIX 1.2 is here.
- 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.
- 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)
Pat Maroney has proposed a CRUD-based implementation:
- ID based on UTC now = time of creation/revision
- Type : {CReate, Revise, Delete}
- Description of /Reason for change
- 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.
- Has explicit action for content creation
- Maps well to existing transactional changes / database update approaches
- Very flexible and very clear what is updated
- 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?
Another potential solution is to not solve versioning in STIX. Systems could use a combination of existing mechanisms and/or custom APIs defined on a per-sharing organization basis. If a community-wide solution is necessary, that solution could be designed external to STIX and either reference or wrap STIX content in order to version it.
- Does not pollute the STIX data model with non-cyber threat concepts
- Allows communities to implement different solutions to fit their needs (or no solution) rather than one-size-fits-all.
- Does not have to be specific to STIX, solution could encompass MAEC, raw CybOX, and other languages.
- Lack of community consensus could create divergent solutions and decrease interoperability
- Solutions external to STIX may not capture STIX-specific semantics
Pat Maroney has proposed that all STIX constructs - not just Indicators - should have the concept of effective dates. See Design: Effective Dates.