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 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
jeffrey.mates@dc3.mil
410-694-4335


-----Original Message-----
From: cti@lists.oasis-open.org [mailto:cti@lists.oasis-open.org] 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; cti@lists.oasis-open.org; marlon.taylor@us-cert.gov
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 <mdavidson@soltra.com> 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" <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]