I think a relationship object is about relating one object with multiple other objects but it does not really mean you have seen it. It just means you have done research on it and you think this "thing" is related to this other "thing" and that other "thing".
A sighting object is a different kind of assertion, basically saying that the object has been seen. So something as simple as:
ID: Sighting GUID Marking_ID: The ID to a Marking structure. (optional) Object_ID: The object that was seen Producer: The person that is claiming they saw it. Timestamp: Time stamp that it was seen
While a lot of the fields are similar, I feel like they are two different things. Playing devils advocate, one could argue that from the data model perspective, an indicator is really just a subset of fields from the incident object. So an indicator is just an incident with not all of the fields filled out... If you do not believe me, list out all of the fields side by side and see how they relate. Some of the fields are called different things, but the data they hold is the same.
From a sighting object standpoint I can see hundreds of millions of these messages flowing around on any given day. Relationship objects will be orders of magnitude less, IMO.
Thanks,
Bret Bret Jordan CISSPDirector 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."
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-😊.png>
Aharon Chernin
CTO
SOLTRA | An FS-ISAC & DTCC Company 18301 Bermuda green Dr Tampa, fl 33647
One thing to keep in mind is that we want the objects as small and simple as possible. Some times to make them more broad you have to add a lot of extra fields. This should be avoided. We want them to be as atomic as possible. Also, if they are separate then they can grow and evolve independently.
This is one of the many things I do not like about how STIX and CybOX is done today. The excessive use of object oriented reuse makes it nearly impossible to fix or change certain things as that would have adverse effects on other areas that can not take those changes.
Object reuse is not always a good thing.
Thanks,
Bret Bret Jordan CISSPDirector 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."
Great discussion topic! The conversation seemed (to me) to settle on the idea that there were three concepts that are related in some way: 1. Relationships – A link between objects (e.g., this TTP is related to that Indicator) 2. Assertions – The +1/-1 concept 3. Sightings – “I saw that, too!” It seems that the structures are similar across the three concepts (e.g., id, from, to, assertion, source/confidence/rationale) and that the larger open question is whether humans are benefitted by these things being variations of the same concept or three different concepts (or something else). I personally think there is a single set of common properties that can do Relationships, Assertions, and Sightings, and that it looks roughly like what Aharon posted. However, there was a counter-point that this combining of concepts makes it more difficult to understand. I’ll leave the group with these questions: 1. Is there a single set of properties that makes sense for Relationships, Assertions, and Sightings? 2. If there is a single set of properties, does it make sense to combine them, as Aharon has mentioned? 3. What clarifying questions, if any, do you have that will help you answer #1 or #2? a. Note that this might be the most important of the three questions! Thank you. - Mark This should be "sightings object rethought". While coming up with a proposal, I spotted a different way of thinking about Sightings. In my opinion, the most important thing is determining which STIX object is being sighted. However, there is some other bits of information that is useful: sightings producer and date/time of sighting. Now take a look at the recent relationship object discussions: Relationship Object Discussion: ID [1]: The ID of the relationship, a simple random GUID Marking[1]: The ID of the marking object that you should reference
Version [1]: The version of the relationship; a simple number to be used with the ID for version control
Type [1]: The “type” of relationship being expressed. (Not sure of how this works yet)
Description [1]: A single simple and short description
Source [1] : The ID of one or more source entities in the relationship as a URI (not QName)
Targets [1..N]: The ID of one or more targets in the relationship as a URI (not QName)
Start [1]: A timestamp in UTC stating when the relationship between the objects started, or the text 'unknown'.
End [1]: A timestamp in UTC stating when the relationship between the objects ended, or the text 'ongoing', or the text 'unknown'.
Reliability/Confidence [1]: A measure of confidence in the relationship using the Information Reliability scale.
Producer [1]: A simple producer object like what John calls out Timestamp [1]: A timestamp in UTC stating when the relationship object was created. Could a sighting be a type of Relationship? Relationship Object Discussion: Marking[1]: TLP Green
Version [1]: 1
Type [1]: Sighting
Description [1]: Soltra Edge reported Sighting
Source [1] : Soltra
Targets [1..N]: soltra:indicator-<GUID>
Start [1]:
End [1]:
Reliability/Confidence [1]:
Producer [1]: Soltra Timestamp [1]: <timestamp> Or is there more meta data we need to collect regarding sightings that a sighting deserves it's own object? SOLTRA | An FS-ISAC & DTCC Company
|