| 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.
Bret
I need to correct myself before someone jumps all over me...
Please add words inside *** to my reply...
The spec is very clear on this... if you *** are not the original producer and you *** change the data in the object in any way when you retransmit, then you must generate a new ID for it. This includes dropping fields, adding fields, or any other change whatsoever.
-
Jason Keirstead
Distinguished Engineer, CTO - IBM Security Threat Management
www.ibm.com/security
Co-Chair - Open Cybersecurity Alliance, Project Governing Board
----- Original message -----
From: "Jason Keirstead" <Jason.Keirstead@ca.ibm.com>
Sent by: <cti@lists.oasis-open.org>
To: Marlon.Taylor@cisa.dhs.gov
Cc: cti@lists.oasis-open.org
Subject: [EXTERNAL] Re: [cti] Preservation of STIX
Date: Fri, Apr 30, 2021 3:49 PM
The spec is very clear on this... if you change the data in the object in any way when you retransmit, then you must generate a new ID for it. This includes dropping fields, adding fields, or any other change whatsoever.
TIPs and other systems that consume an SDO and then retransmit it later, but with different fields, MUST do so with new object IDs (which start over at version 1) - and ideally, a new created_by_ref (in the previous 2.0, interop tests, created_by_ref was required as part of interop)
If a system is simply dropping fields and re-transmitting with the same ID, then they are not compliant with the spec.
--
"STIX Objects have a single object creator, the entity that generates the id for the object and creates the first version. The object creator MAY (but not necessarily will) be identified in the created_by_ref property of the object. Only the object creator is permitted to create new versions of a STIX Object. Producers other than the object creator MUST NOT create new versions of that object. If a producer other than the object creator wishes to create a new version, they MUST instead create a new object with a new id. They SHOULD additionally create a derived-from Relationship object to relate their new object to the original object that it was derived from."
-
Jason Keirstead
Distinguished Engineer, CTO - IBM Security Threat Management
www.ibm.com/security
Co-Chair - Open Cybersecurity Alliance, Project Governing Board
----- Original message -----
From: "Taylor, Marlon" <Marlon.Taylor@cisa.dhs.gov>
Sent by: <cti@lists.oasis-open.org>
To: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Cc:
Subject: [EXTERNAL] [cti] Preservation of STIX
Date: Mon, Apr 19, 2021 1:40 PM
Hi TC, What is the TC stance on the preservation of STIX content? Through engagements with various members of the STIX community it has become apparent that STIX content is handled differently within the community. The difference in STIX handling (e.g. dropped fields) results in confusion and lack of trust between systems. This concern has echoed throughout the STIX community, the Interop subcommittee, and now the TC for the purpose of resolution! This is great timing as we can address this for all while the specification is in public review prior on the way to becoming an OASIS standard! The table below highlights areas of consideration. The âRow #â column provides an unique identifier of each use case. Iâm we hoping we as a TC can provide a decision on this matter and show alignment via the rows below.
Row # | Ingest - Keep Original No â the original STIX is a not accessible
Yes â the original STIX is accessible | Process - Translate to internal Data Model None â no STIX properties are mapped to the data model
Some â some STIX properties are mapped to the data model
All â every STIX property in mapped to the data model | Export â Original No â the original STIX is not exportable Yes â the original STIX is exportable | Export â Processed No â the internal data model is not exportable is STIX Yes â the internal data model is exportable is STIX | 1 | No | None | No | No | 2 | No | None | No | Yes | 3 | No | None | Yes | No | 4 | No | None | Yes | Yes | 5 | No | Some | No | No | 6 | No | Some | No | Yes | 7 | No | Some | Yes | No | 8 | No | Some | Yes | Yes | 9 | No | All | No | No | 10 | No | All | No | Yes | 11 | No | All | Yes | No | 12 | No | All | Yes | Yes | 13 | Yes | None | No | No | 14 | Yes | None | No | Yes | 15 | Yes | None | Yes | No | 16 | Yes | None | Yes | Yes | 17 | Yes | Some | No | No | 18 | Yes | Some | No | Yes | 19 | Yes | Some | Yes | No | 20 | Yes | Some | Yes | Yes | 21 | Yes | All | No | No | 22 | Yes | All | No | Yes | 23 | Yes | All | Yes | No | 24 | Yes | All | Yes | Yes | Addressing the preservation of STIX as a TC will drive a better understanding for all and interoperability. Marlon Taylor <Image.image002.png@01D73519.2F408110.png>
|