RE: [cti-stix] Proposal to establish Sightings (#306) and Relationships (#291) as our official issue topics under active consideration for STIX v2.0

["Jason Keirstead" <Jason.Keirstead@ca.ibm.com>]

I know historically I have been pushing for an RFC-Compliant UUID as mandatory component of this - now i am going to backtrack on my previous argument :)

I actually think that having a UUID be mandatory is not workable, and here is why: For many (most?) products looking to produce observable and sightings, there is no system-wide "ID" in their product that could be used to represent something like an observable. Similarly, STIX producers like embedded devices and endpoints, do not have the resources or processing capacity to start storing these relationships. As such, said producers have two options for generating sightings:

a) Have a randomly-generated UUID (which is of no use to anyone in the end because it will remove all traceability and create rampant data duplication)

b) Have an algorithmically derived ID based on the data (IE, any time I issue an observable for Equals 1.2.3.4, the same ID will be derived)

(b) Is really the only workable ID mechanism for most products. 

I have recently started to run into this in practice in my own product work, so I know it is a real problem that is going to hit a lot of people if we start mandating IDs and UUIDs. 

Here is an assertion - why is ID even a mandatory field for a sighting? I am not sure why it is useful. If a STIX repository needs an ID for an internal record, it can generate its own in any way it wants. I am not sure why a producer needs to specify an ID.

-
Jason Keirstead
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

Terry MacDonald ---2015/10/29 06:51:35 PM---Mark, That should change with the top-level relationship object. It will be quite possible to send j

From:        Terry MacDonald <terry@soltra.com>
To:        "Davidson II, Mark S" <mdavidson@mitre.org>, "Jordan, Bret" <bret.jordan@bluecoat.com>, "Barnum, Sean D." <sbarnum@mitre.org>
Cc:        Jerome Athias <athiasjerome@gmail.com>, "Taylor, Marlon" <Marlon.Taylor@hq.dhs.gov>, "Wunder, John A." <jwunder@mitre.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Date:        2015/10/29 06:51 PM
Subject:        RE: [cti-stix] Proposal to establish Sightings (#306) and Relationships (#291) as our official issue topics under active consideration for STIX v2.0
Sent by:        <cti-stix@lists.oasis-open.org>

---

Mark,
 
That should change with the top-level relationship object. It will be quite possible to send just a relationship object in a package. This will mean that the consumer will need the ability to contact the original producer of the reference STIX data object to ask if they are allowed the full object rather than just the reference to it. Having the ability to find the TAXII server from just the STIX object ID is critical to allow this to happen.
 
This functionality also allows more secretive providers to ‘hide’ their data, such that consumers can understand that relationships exist, but that only a small subset of approved consumers will have access to the actual STIX object data. It gives the ability to hide stuff.
 
Cheers
 
Terry MacDonald
Senior STIX Subject Matter Expert
SOLTRA | An FS-ISAC and DTCC Company
+61 (407) 203 206 | terry@soltra.com 
 
 
From: Davidson II, Mark S [mailto:mdavidson@mitre.org] 
Sent: Friday, 30 October 2015 5:05 AM
To: Jordan, Bret <bret.jordan@bluecoat.com>; Barnum, Sean D. <sbarnum@mitre.org>
Cc: Jerome Athias <athiasjerome@gmail.com>; Terry MacDonald <terry@soltra.com>; Taylor, Marlon <Marlon.Taylor@hq.dhs.gov>; Wunder, John A. <jwunder@mitre.org>; cti-stix@lists.oasis-open.org
Subject: RE: [cti-stix] Proposal to establish Sightings (#306) and Relationships (#291) as our official issue topics under active consideration for STIX v2.0
 
If want the ability to dereference arbitrary STIX IDs (for use in accessing some kind of repository, let’s say), then I think requiring a rule whereby STIX IDs can be turned into a URL could be a good requirement (Note: URLs as IDs would satisfy this requirement). While there is a concept for idref today, I personally haven’t seen an implementation that dereferences STIX IDs outside of the document containing the idref.
 
Thank you.
-Mark
 
PS, a notional example: <stix:Indicator idref=”https://example.org/stix121/indicators/123”/>

From: cti-stix@lists.oasis-open.org [mailto:cti-stix@lists.oasis-open.org] On Behalf Of Jordan, Bret
Sent: Thursday, October 29, 2015 1:03 PM
To: Barnum, Sean D. <sbarnum@mitre.org>
Cc: Jerome Athias <athiasjerome@gmail.com>; Terry MacDonald <terry@soltra.com>; Taylor, Marlon <Marlon.Taylor@hq.dhs.gov>; Wunder, John A. <jwunder@mitre.org>; cti-stix@lists.oasis-open.org
Subject: Re: [cti-stix] Proposal to establish Sightings (#306) and Relationships (#291) as our official issue topics under active consideration for STIX v2.0

Let's just make sure we do not build an ID system that is so vast that it can enumerate every atom in the known universe.

Bret

Sent from my Commodore 64

STIX SC Co-chair