cti-stix — archive

STIX 2.0 - Sightings object

From: Aharon Chernin <[email protected]>
To: [email protected]
Date: Thu, 20 Aug 2015 18:04:00 -0000

> 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 [email protected] www.soltra.com From: Davidson II, Mark S <[email protected]> Sent: Thursday, August 20, 2015 2:00 PM To: Jonathan Bush (DTCC); 'Jordan, Bret'; Wunder, John A. Cc: Aharon Chernin; [email protected] 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: [email protected] [mailto:[email protected]] On Behalf Of Bush, Jonathan Sent: Thursday, August 20, 2015 1:36 PM To: 'Jordan, Bret' <[email protected]>; Wunder, John A. <[email protected]> Cc: Aharon Chernin <[email protected]>; Davidson II, Mark S <[email protected]>; [email protected] 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: [email protected] [ mailto:[email protected] ] On Behalf Of Jordan, Bret Sent: Thursday, August 20, 2015 12:36 PM To: Wunder, John A. Cc: Aharon Chernin; Davidson II, Mark S; [email protected] 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. < [email protected] > 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 < [email protected] > 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. < [email protected] > Sent: Thursday, August 20, 2015 12:07:08 PM To: Aharon Chernin Cc: Jordan, Bret; Davidson II, Mark S; [email protected] 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 < [email protected] > 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-