Well said Jason, and I completely agree.
Thanks,
Bret Bret Jordan CISSPDirector of Security Architecture and Standards | Office of the CTO Blue Coat Systems PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 "Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."
IDs should be immutable and not based on hashing, as having IDs flux based on the content (hash) creates more problems than it solves. I don't want the ID of a threat actor to change because I am correcting a spelling mistake. I also don't want to have to re-author or append to all of my relationships because someone adds a host to a watch list and have that change it's ID.
IE, changing an object should not change all of the relationships people have with that object, it should just increment a version.
Terry McDonald posted a good discourse on why this is important on slack.. I will copy / paste here.
"With Explicit Updates: each ID specifies a particular object, and that updates to that object are actually brand new completely new objects with completly new object IDs, and then they are related to each other as 'updates' using a relationship object.
The problem is when people connect other relationships to earlier versions of the object. How do we handle that? Are all relationships transitive across all versions of the object? In that case the consumers al need to keep all versions of the object and then walk the graph to the latest version every time they want to find all the relationships.
Or we say that relationships aren't transitive, and then when a new update comes out all the realationahips that point to it need to be updated top point to the latest version of that object.
It seems much simpler to go with an implicit versioning scheme, where the object always maintains its Object ID, and we just version control the update through updates to that one object. It makes relationships much easier to handle (they link to the Object ID), it makes it easier for consumers (keep only the latest version of the object if you want) and easier for them to walk the relationships (there are no versioning relationships).
Its also conceptually easier for new users to understand, which is a big plus in my view
...
There should only be one way to version the one object. It should always keep the same ID during it's lifecycle, and should have a version field (or some other field that changes per version) that tracks which version the object is.
There should be no way to version major changes. New objects should be considered to be completely different and should have a completely new ID. There should be ONLY one way to version an object. We had two ways to version in STIX v1.x (i.e. major updates or incremental) and it didn't work." - Jason Keirstead STSM, Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security | www.securityintelligence.comWithout data, all you are is just another person with an opinion - Unknown <graycol.gif>"Mates, Jeffrey CIV DC3---03/14/2016 12:53:13 PM---My understanding is that in general versioning should be handled using the CTI Core "created_at" attFrom: "Mates, Jeffrey CIV DC3/DCCI" <Jeffrey.Mates@dc3.mil>To: Jason Keirstead/CanEast/IBM@IBMCA, "Taylor, Marlon" <Marlon.Taylor@hq.dhs.gov>Cc: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>, "marlon.taylor@us-cert.gov" <marlon.taylor@us-cert.gov>Date: 03/14/2016 12:53 PMSubject: [cti] RE: [Non-DoD Source] RE: [cti] RE: Versioning Background DocsSent by: <cti@lists.oasis-open.org> My understanding is that in general versioning should be handled using the CTI Core "created_at" attribute which exists on both objects and relationships. If this changes any object with a deterministic hash would also have its GUID change. As such different versions of an object would respect each other's unique GUIDs thus protecting referential integrity.
Even without a deterministic hash this would still be possible by simply generating a new GUID every time a new version of an object or relationship is produced.
Jeffrey Mates, Civ DC3/DCCI ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Computer Scientist Defense Cyber Crime Institute jeffrey.mates@dc3.mil 410-694-4335
-----Original Message----- From: cti@lists.oasis-open.org [mailto:cti@lists.oasis-open.org] On Behalf Of Jason Keirstead Sent: Monday, March 14, 2016 11:27 AM To: Taylor, Marlon Cc: cti@lists.oasis-open.org; Mates, Jeffrey CIV DC3/DCCI; marlon.taylor@us-cert.gov Subject: [Non-DoD Source] RE: [cti] RE: Versioning Background Docs
Are you saying that versions will only exist on relationship objects? How will that help me figure out if a given threat actor's description is the most recent.
- Jason Keirstead STSM, Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security | www.securityintelligence.com
Without data, all you are is just another person with an opinion - Unknown
Inactive hide details for "Taylor, Marlon" ---03/14/2016 12:07:46 PM---Correct. Hashing won't provide that capability. Relation"Taylor, Marlon" ---03/14/2016 12:07:46 PM---Correct. Hashing won't provide that capability. Relationships will provide what you're looking for.
From: "Taylor, Marlon" <Marlon.Taylor@hq.dhs.gov> To: Jason Keirstead/CanEast/IBM@IBMCA Cc: "Mates, Jeffrey CIV DC3/DCCI" <Jeffrey.Mates@dc3.mil>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>, "marlon.taylor@us-cert.gov" <marlon.taylor@us-cert.gov> Date: 03/14/2016 12:07 PM Subject: RE: [cti] RE: Versioning Background Docs
________________________________
Correct. Hashing won't provide that capability.
Relationships will provide what you're looking for.
-Marlon
________________________________
From: Jason Keirstead Sent: Monday, March 14, 2016 10:56:04 AM To: Taylor, Marlon Cc: Mates, Jeffrey CIV DC3/DCCI; cti@lists.oasis-open.org; marlon.taylor@us-cert.gov Subject: RE: [cti] RE: Versioning Background Docs
Apologize for my confusion but I don't really understand what is being discussed in this thread.
Are people talking about IDs or Versions? What does hashing have to do with versioning?
I (hope?) people are not advocating to simply hash the contents of the object and use that as a version? That is not workable. A version has to be continually incrementing. I need to be able to look at a version and know if it is the latest version or if it is stale. You can't do that with hashes.
- Jason Keirstead STSM, Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security | www.securityintelligence.com
Without data, all you are is just another person with an opinion - Unknown
Inactive hide details for "Taylor, Marlon" ---03/14/2016 11:42:28 AM---Hi All, Jeff and I spoke offline and we are in agreement"Taylor, Marlon" ---03/14/2016 11:42:28 AM---Hi All, Jeff and I spoke offline and we are in agreement with the hash based approach. Some takeaway
From: "Taylor, Marlon" <Marlon.Taylor@hq.dhs.gov> To: "Mates, Jeffrey CIV DC3/DCCI" <Jeffrey.Mates@dc3.mil>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org> Cc: "marlon.taylor@us-cert.gov" <marlon.taylor@us-cert.gov> Date: 03/14/2016 11:42 AM Subject: RE: [cti] RE: Versioning Background Docs Sent by: <cti@lists.oasis-open.org>
________________________________
Hi All,
Jeff and I spoke offline and we are in agreement with the hash based approach. Some takeaways: - cleared up "shallowness" of shallow objects - conveyed the idea of relationships which contain arrays of ids (he calls them link aggregators)
As we finalize objects across the TC we can go into object-specific required fields. Ex: should every Indicator have an observable?
Keep up the feedback.
-Marlon
________________________________
|