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] Sanity checking on references to other objects


I was going to respond to the earlier discussion with exactly what Terry said…we specifically decided that relationships should be valid across all versions of an object. That may not apply 100% of the time (i.e. to opinion, which is presumably an opinion on a specific version) but I would worry about adding it as a general capability on relationship and having this get bifurcated. I’d like to see more actual usage of STIX 2.0 before we plan to add this (i.e. would like to revisit in the 2.2-2.3 timeframe if it seems necessary).

 

My worry would be that a consumer considers relationships valid across all versions of an object (doesn’t validate the hash) while a producer considers it only to the hashed version, and you have a miscommunication.

 

John

 

From: <cti@lists.oasis-open.org> on behalf of "Struse, Richard J." <rjs@mitre.org>
Date: Thursday, June 15, 2017 at 3:52 PM
To: Terry MacDonald <terry.macdonald@cosive.com>, Marlon Taylor <Marlon.Taylor@hq.dhs.gov>
Cc: CTI TC Discussion List <cti@lists.oasis-open.org>
Subject: Re: [cti] Sanity checking on references to other objects

 

The concept of having an optional hash(es) for the SDOs referenced in a relationship would essentially tie the relationship to a specific version of an object because any change to an SDO would change the hash…  How does that impact your thinking?

 

From: <cti@lists.oasis-open.org> on behalf of Terry MacDonald <terry.macdonald@cosive.com>
Date: Thursday, June 15, 2017 at 3:45 PM
To: Marlon Taylor <Marlon.Taylor@hq.dhs.gov>
Cc: CTI TC Discussion List <cti@lists.oasis-open.org>
Subject: Re: [cti] Sanity checking on references to other objects

 

My understanding was that we decided in the referencing/versioning working group that references would apply to all versions of an object. Therefore we don't want to specify particular versions of an object when we are lining them with references.

 

We managed the possibility of the references data changing greatly by mandating that if the meaning of an object changes greatly then it has to be released under a different STIX id,  so that the relationship should apply through all of the versions of an object.

 

As an aside, this fact show alleviate concerns that Bret has about the location object, as any major changes/revisions to a location object will have to be released as a new object with a new STIX ID.

 

Cheers

Terry MacDonald

 

 

On 16/06/2017 02:14, "Taylor, Marlon" <Marlon.Taylor@hq.dhs.gov> wrote:

Hi All,

 

I’m consolidating the discussion on “linking to other objects” to this thread.

 

References from various threads:

·         http://markmail.org/message/5me3xvamzadvu4jg

·         http://markmail.org/message/cbbw5zilfgzodcpf

·         http://markmail.org/message/githhm4kns6hceom

 

http://markmail.org/message/cbbw5zilfgzodcpf - suggest the use of an object hash.

 

I suggest use of the modified_time of the referenced object.

 

The modified_time is a single comparison which also provides temporal positioning which end recipients can leverage for decision marking either manual or automated.

 

Example:

·         Entity_B creates Object_B at with create/modify_time = 0

·         Entity_A creates an Object_A with reference to Object_B and create/modify_time = 1

·         Entity_B updates Object_B at with modify_time = 2

·         Entity_C gets Object_A and all Object_Bs and has the ability to determine which instance of Object_B Entity_A is referencing.

 

This is less trivial in a fast sharing environment where multiple versions of an object are shared independently.

 

Thoughts?

 

Marlon Taylor
Technology Services Section
National Cybersecurity & Communications Integration Center (NCCIC)
U.S. Department of Homeland Security



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