Re: [cti] Sanity checking on references to other objects

It would effectively break the transitive nature of that relationship, and force is back to the explicit linking of specific versions of relationships.

This then means that if you release an updated version of an SDO, everyone else who released and SRO pointing to that SDO now has to reissue their SRO to update it to point to that new SDO. This will result in a LOT of extra traffic and processing required for all participants in that sharing community.

For that reason I'm not a fan of storing referenced SDO hashes in an SRO. It seems like a good idea on paper, but it will have a major effect on versioning, and the transitive nature of SRO relationships.

Cheers

Terry MacDonald

Cosive

On 16/06/2017 07:52, "Struse, Richard J." <rjs@mitre.org> wrote:

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

cti message