RE: Some thoughts on Sightings and conversations to date (Part #4): shou

I do believe that it is important for sightings to have IDs for many of the reasons already expressed on the list.

agreed

The ID stays the same over the lifetime of the object even if it is updated and the content changes.

I’ve been doing more thinking on this recently, and tried to identify what problems that having hashed ID’s would create. I’ve come to the conclusion that we could actually do hashing of ID’s. Enabling this requires a few changes…

In the current version of STIX, an object is identified by a combination of its Object ID, and the Timestamp. One can think of the Object ID + Timestamp representing the composite primary key.

There are two ways to issue an updated STIX Object in the current version of STIX. (information here: http://stixproject.github.io/documentation/concepts/versioning/)

· An Incremental Update only updates the Timestamp. This indicates there is a slight change to the underlying object, as it retains the original Object ID; the later timestamp indicates to the receiving consumer that the new object should overwrite the old one. It is an implicit update.

· A Major Update creates a completely new STIX Object, with a modified Object ID + Timestamp. This indicates there is a major change to the underlying object, one large enough to cause a completely new object to be issued. The new STIX Object includes an explicit relationship to the original Object ID + Timestamp, with a type of 'Supersedes' to indicate to the receiving consumer that the new object supersedes the old one. It is an explicit update.

A large problem is that there is no definition (or agreement) as to what update mechanism should be used. The STIX guidance states:

"Current suggested practices suggest using an incremental update whenever you're making very minor changes to a construct that don't change its inherent meaning. Adding an alias to a threat actor, for example, would be an incremental update. Additionally, incremental updates can be used within an organization while it is developing a more final version of the construct in order to avoid churn on IDs. Major updates, on the other hand, are suggested for anything that changes the inherent meaning of a construct or changes of content between organizations. Changing a TTP from "phishing" to "spear phishing", for example, would be a major update because even though phishing and spear phishing are similar the inherent meaning of the construct changed."

Another problem is the recent discussion suggesting using hashes to generate the UUIDs for objects. The use of an Object ID + Timestamp as a composite key does not work with Incremental Updates. If a producer made a mistake and had to reissue the Indicator with a modification, that would result in a completely different Object ID if we were using the a hashing function to generate the IDs.

POTENTIAL ANSWER:

This can be fixed by enforcing all updates to be new objects (with new Object IDs) with explicitly definied relationships to the old object IDs.

This would mean that:

- A STIX object only ever gets 'issued' once.

- That STIX object cannot be updated.

- An object that superseeds the original object must have a new Object ID, and a top-level relationship object describing that the new object superseeds the old object.

- The Object ID can be generated from a STIX hash.

- It would be more difficult to send partial updates to objects - unless we allow 'partial superseeding' of object data. i.e. the first object ID contains the full object, and the new object contains only the 'changed' information with an explicit relationship.

Cheers

Terry MacDonald

Senior STIX Subject Matter Expert

SOLTRA | An FS-ISAC and DTCC Company

+61 (407) 203 206 | terry@soltra.com

From: cti-stix@lists.oasis-open.org [mailto:cti-stix@lists.oasis-open.org] On Behalf Of Barnum, Sean D.
Sent: Wednesday, 4 November 2015 5:55 AM
To: cti-stix@lists.oasis-open.org
Subject: [cti-stix] Some thoughts on Sightings and conversations to date (Part #4): should sightings have IDs?

The fourth sightings sub-topic I wanted to comment on is around the question of whether sightings should have IDs or not.

I think there have been some clear assertions (along with their rationale) from Jason and Bret that it does not make sense for sightings to have IDs but also some good clear arguments from John, Terry and others for why unique and persistent IDs are relevant for consumers to be able to reference, correlate and analyze diverse sightings from diverse sighters.

Again, putting on my expert hat rather than my co-chair hat, I wanted to offer some thoughts on this which are primarily just stating agreement with the arguments made by John, Terry and others.

I do believe that it is important for sightings to have IDs for many of the reasons already expressed on the list.
Specifically, I would also agree with Terry’s assertion that:

"We need an ID solution that:

Includes the domain namespace in the ID so that recipients know where to ask for more information.
The ID stays the same over the lifetime of the object even if it is updated and the content changes.
Recognizes that IDs will be coming from many different companies and many different sources and that we need a way of easily understanding who produced the data."

On the sub-sub-topic ( :-) ) of Alternative_ID for Sightings,

I think that Alternative_ID does make sense for Sightings. It would allow the capture and reference of things like alert IDs issued by particular detection tools. The sightings would still need a STIX ID for effective referencing within STIX content but the external ID would help support the potential for seeking out more detailed information where appropriate.

sean

cti-stix message