cti-stix — archive
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
— [Date Index]
| [Thread Index]
| [Month Index]
| [List Home]
STIX 2.0 - Sightings object
Sorry my bad.....
I am hoping we can get rid of the idea of things like the report object having either embedded data or referenced data. I think it should be one or the other, and I would lean to the idea of the report object just using referenced data.
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 11:36, Bush, Jonathan < [email protected]
> wrote:
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-
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
— [Date Index]
| [Thread Index]
| [Month Index]
| [List Home]