OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cti message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [cti] RE: [Non-DoD Source] RE: [cti] RE: Versioning Background Docs


I could be wrong, but the CTI Common 1.0 spec document includes "created_at" as part of the CTI Core and its description is " The time that the object with this ID was created".  So I assumed that it was to be used for version tracking.

This was on page 12 of the working spec found here: https://docs.google.com/document/d/1FM-ojdKeaC-3mhf2v1FfXY0Q-s0uCiSDG80tDh23k3E/edit?pref=2&pli=1#

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 Mark Davidson
Sent: Monday, March 14, 2016 12:04 PM
To: Mates, Jeffrey CIV DC3/DCCI; 'Jason Keirstead'; Taylor, Marlon
Cc: cti@lists.oasis-open.org; marlon.taylor@us-cert.gov
Subject: Re: [cti] RE: [Non-DoD Source] RE: [cti] RE: Versioning Background Docs

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" <cti@lists.oasis-open.org on behalf of Jeffrey.Mates@dc3.mil> 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
>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
>
>
>
>________________________________
>
>
>
>
>
>
>
>
>
>
>
>

Attachment: smime.p7s
Description: S/MIME cryptographic signature



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]