Some for any confusion. I do remember the TC talking about GUIDs and HASHes but I don't remember the use-cases/scenarios/etc. which lead the TC go against HASH based. Are they available for TC consideration in this discussion?
I'm unaware of any conceptual workflows/use-cases that will break with insurmountable repair due to this change. I think it's more important for the TC to be able review any rationale that was to make its decisions so we as a whole can quickly reference and
re-evaluate its stand on any decision.
Why are HASH IDs bad?
-Marlon
From: on behalf of Mates, Jeffrey CIV DC3/DCCI
Sent: Monday, March 14, 2016 12:43:46 PM
To: 'Jordan, Bret'; Mark Davidson
Cc: Jason Keirstead; Taylor, Marlon; ;
Subject: RE: [cti] RE: [Non-DoD Source] RE: [cti] RE: Versioning Background Docs
I certainly understand concerns about deterministic IDs breaking workflows and not working in a number of potential use cases. It might make sense to simply allow IDs to follow the UUID v4 and UUID v5 specs. That way organizations that
want to use deterministic IDs can, while those that don't have no need to. Ultimately because of how the UUID spec works out both will have the same length, and an outside observer will only notice a single character change between the two.
From a parsing standpoint handling something like xxxxxxxx-xxxx-4xxx-xxxx-xxxxxxxxxxxx instead of xxxxxxxx-xxxx-5xxx-xxxx-xxxxxxxxxxxx is pretty trivial as both will accomplish the same thing.
Jeffrey Mates, Civ DC3/DCCI
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Computer Scientist
Defense Cyber Crime Institute
410-694-4335
-----Original Message-----
From: [mailto:] On Behalf Of Jordan, Bret
Sent: Monday, March 14, 2016 12:09 PM
To: Mark Davidson
Cc: Mates, Jeffrey CIV DC3/DCCI; Jason Keirstead; Taylor, Marlon; ;
Subject: Re: [cti] RE: [Non-DoD Source] RE: [cti] RE: Versioning Background Docs
And for further clarification and to support Trey's statements. This TC talked about deterministic IDs at great length and it was decided that we would not go down that path. With Mark, I believe we have strong consensus to stick with the current ID patterns
we have. If this is not the case, then we will need to take this to a ballot. Things like IDs are fundamental and we need to figure these out before we do anything else. Thus the reason we had this discussion a few months ago.
Deterministic IDs may offer interesting use cases but also run the risk of breaking a lot of workflow that we are now building.
Thanks,
Bret
Bret Jordan CISSP
Director 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."
On Mar 14, 2016, at 10:03, Mark Davidson <> wrote:
Jeff,
Can you help me understand your perspective? In STIX 1.x, versioning was handled using the timestamp field (and would seem to align with your post, unless I’m mis-reading it) but I’m not sure I’ve seen any discussion about using timestamp for versioning
in 2.0. Are you proposing that we use timestamps for versioning in 2.0, or am I misunderstanding your comment?
Thank you.
-Mark
On 3/14/16, 11:52 AM, "Mates, Jeffrey CIV DC3/DCCI" < on behalf of > wrote:
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
410-694-4335
-----Original Message-----
From: [mailto:] On Behalf
Of Jason Keirstead
Sent: Monday, March 14, 2016 11:27 AM
To: Taylor, Marlon
Cc: ; Mates, Jeffrey CIV DC3/DCCI;
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" <>
To: Jason Keirstead/CanEast/IBM@IBMCA
Cc: "Mates, Jeffrey CIV DC3/DCCI" <>,
"" <>,
"" <>
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; ;
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" <>
To: "Mates, Jeffrey CIV DC3/DCCI" <>,
"" <>
Cc: "" <>
Date: 03/14/2016 11:42 AM
Subject: RE: [cti] RE: Versioning Background Docs Sent by:
<>
________________________________
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
________________________________
