> What you don’t necessarily see is that idref is also allowed per the STIX schema, allowing an object that looks like this: <Indicator id=”1234” idref=”5678”/> and
that doesn’t really make sense.
I agree, this stinks and doesn't make sense.
> As I understand it, the idea is not to preclude an object with an ID from referencing other objects (e.g., an indicator referencing observable(s)). That would
still be valid.
Thats' not how I read it.
Aharon Chernin
CTO
SOLTRA
An FS-ISAC & DTCC Company
18301 Bermuda green Dr
Tampa, fl 33647
813.470.2173
www.soltra.com
From: Davidson II, Mark S <>
Sent: Thursday, August 20, 2015 2:00 PM
To: Jonathan Bush (DTCC); 'Jordan, Bret'; Wunder, John A.
Cc: Aharon Chernin;
Subject: RE: [cti-stix] STIX 2.0 - Sightings object
In STIX today, you see things like: <Indicator id=”1234”/>
What you don’t necessarily see is that idref is also allowed per the STIX schema, allowing an object that looks like this: <Indicator id=”1234” idref=”5678”/> and that doesn’t really
make sense.
I think the underlying thought is that you want an id OR an idref, and that having both on the same object doesn’t make sense.
As I understand it, the idea is not to preclude an object with an ID from referencing other objects (e.g., an indicator referencing observable(s)). That would still be valid.
Did the STIX community think about changing the id/idref thing at some time in the past? I feel like we did, but my memory is a bit hazy.
Thank you.
-Mark
From:
[mailto:]
On Behalf Of Bush, Jonathan
Sent: Thursday, August 20, 2015 1:36 PM
To: 'Jordan, Bret' <>; Wunder, John A. <>
Cc: Aharon Chernin <>; Davidson II, Mark S <>;
Subject: RE: [cti-stix] STIX 2.0 - Sightings object
Bret – Can you explain this a little?
Going from a database design perspective, wouldn’t you have objects that have primary keys and also foreign keys that relate it to other objects? What am I missing?
From:
[ mailto: ]
On Behalf Of Jordan, Bret
Sent: Thursday, August 20, 2015 12:36 PM
To: Wunder, John A.
Cc: Aharon Chernin; Davidson II, Mark S;
Subject: Re: [cti-stix] STIX 2.0 - Sightings object
And my hope is that in in STIX 2.0 we can get rid of the idea of having both ID and IDREF in the same object. It is either one or the other. It is either a container of data, thus having an ID. Or it is an object like Report that just contains IDREFs.
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 Aug 20, 2015, at 10:27, Wunder, John A. <
> wrote:
As a place to start, how about in the current STIX model anything that extends from Related___Type is a relationship object, anything with a normal @idref is not?
Sighting wasn’t top-level before so we get to make it up.
On Aug 20, 2015, at 12:19 PM, Aharon Chernin <
> wrote:
We need to make sure it's very clear where the relationship object starts and ends. If I am not forced to use the relationship object for a sighting relationship, then I go back to supporting
an atomic sighting object.
Aharon
Sent using OWA for iPhone
From:
Wunder, John A. <
>
Sent: Thursday, August 20, 2015 12:07:08 PM
To: Aharon Chernin
Cc: Jordan, Bret; Davidson II, Mark S;
Subject: Re: [cti-stix] STIX 2.0 - Sightings object
Are you actually forced to use the relationship object to have sighting work there? I see that as a separate use case from relationships, and in cases like this we can still have the target_id
field directly there without the need for a new object. Same thing for an indicator pattern, for example.
While those are references between top-level constructs they seem different than the normal type of relationships we’ve been discussing.
John
BTW: Any thoughts on setting up a slack channel for STIX dev discussions? Sometimes I think that would be more conducive to these questions than e-mail.
On Aug 20, 2015, at 11:58 AM, Aharon Chernin <
> wrote:
Bret, I almost always prefer atomic objects.
If we do both a relationship object and a Sightings atomic object together, it just seems... well weird.... (not very scientific I know)
Example Sightings Object -
ID: Sighting GUID
Marking: Sighting TLP
Producer: Who made the sighting
Timestamp:
Target_ID: Replaced by Relationship Object
Now I am going to be forced to use the relationship object to make the Sighting work. I am also going to be forced to make a potentially large number of new Sighting Objects (since there is a timestamp). Also,
a sighting by itself, without the looking into the Relationship object is kind of useless.
We can eliminate this extra complexity by eliminating the atomic Sightings object and replacing it with a relationship type.
Just debating <OutlookEmoji-
