Closed StephenOTT closed 5 years ago
jordan2175
commented
5 years ago It does not include the relationship_type property as it would always be the same, there would never be a different type of sighting relationship. The Sighting relationship also allows one-armed relationships, something that the standard relationship object does not allow.
If the relationship_type property was included, what would you suggest or be looking for, to be included in the value of that property?
StephenOTT
commented
5 years ago @jordan2175 the way I see it from a implementation point of view (based on the style of the SDOs), a Sighting is just a Relationship with custom properties. From a implementation standpoint it might be that the wrapper/lib is generating many relationships (source/target) based on the custom fields (such as whereSightedRefs property).
I see the confusion from the implementation standpoint because relationships are defined as a Source/Target (edges for the nodes). But then there is a "additional" relationship which does not have a "source" because the Source is itself a Node (thus making it very similar to a SDO from a implementation standpoint).
see: https://github.com/StephenOTT/charon-stix/tree/master/src/main/java/io/digitalstate/stix/relationshipobjects as a example.
From a library standpoint, The way I saw relationships was that the object of a "relationship" is a generic construct, but each SDO is defining their style of validation.
and for the Common relationships: https://github.com/StephenOTT/charon-stix/blob/master/src/main/java/io/digitalstate/stix/domainobjects/properties/CommonProperties.java#L421-L564
Basically for sanity of abstractions and Type Checking during development you end up with Per SDO validations such as: https://github.com/StephenOTT/charon-stix/blob/master/src/main/java/io/digitalstate/stix/domainobjects/properties/AttackPatternProperties.java#L77-L82, But they are all "Relationships" and can be structured as needed in a "CustomRelationship" if needed: https://github.com/StephenOTT/charon-stix/blob/master/src/main/java/io/digitalstate/stix/domainobjects/properties/CommonProperties.java#L213-L216
I guess more of my question would be: "Why was a new type of relationship object class created" rather than using a "custom relationship"?
STIX also allows relationships from any SDO to any SDO that have not been defined in this specification. These relationships MAY use the related-to relationship type or MAY use a custom relationship type. As an example, a user might want to link malware directly to a tool. They can do so using related-to to say that the Malware is related to the Tool but not describe how, or they could use delivered-by (a custom name they determined) to indicate more detail.
A Sighting seems to be a "custom relationship type" with custom fields. The spec does not outline custom fields explicitly for a SRO, but it seems to fit with: http://docs.oasis-open.org/cti/stix/v2.0/cs01/part1-stix-core/stix-v2.0-cs01-part1-stix-core.html#_Toc496709309
jordan2175
commented
5 years ago A Sighting Relationship is not a custom relationship, nor does it have custom properties. A Sighting Relationship is a relationship object just like the Generic Relationship object. Remember STIX is not necessarily a data model for the storage of threat intelligence, but rather a data model for the transmission of threat intelligence.
A generic relationship object can only contain a single edge in the graph. Further, a generic relationships MUST define both vertices of the graph that the edge connects.
A sighting relationship is an operational efficiency relationship object for transmitting "sightings", "+1s", "thumps up" type information. It is special in that it can convey a one-armed relationship like "hey I saw your indicator, but I can not tell you what I actually saw or where I saw it, but I saw it". It can also contain multiple edges in the same structure. So instead of having to send multiple relationship objects to say, your indicator of 1,000 bad IPs, I saw these 10 at these 50 different locations. With the Sighting relationship object, you can transmit all of that information in a single JSON blob.
On the consumption and storage side it is expected that most people will pull the data out and store the data in an actual graph database.
It is also important to note that the TC may create more special relationship objects over time, depending on the needs and requirements of sharing threat intelligence. Sighting was just the easy one, as I wanted a way to mimic the Facebook / Twitter / Instagram "+1" functionality in an active threat intelligence eco-system.
StephenOTT
commented
5 years ago A sighting relationship is an operational efficiency relationship object for transmitting "sightings", "+1s", "thumps up" type information. It is special in that it can convey a one-armed relationship like "hey I saw your indicator, but I can not tell you what I actually saw or where I saw it, but I saw it". It can also contain multiple edges in the same structure. So instead of having to send multiple relationship objects to say, your indicator of 1,000 bad IPs, I saw these 10 at these 50 different locations. With the Sighting relationship object, you can transmit all of that information in a single JSON blob.
Thats a great explanation. Thank you for that.
as I wanted a way to mimic the Facebook / Twitter / Instagram "+1" functionality in an active threat intelligence eco-system. 👍
That explanation makes it very clear for its original intent and why its designed the way it is!
Remember STIX is not necessarily a data model for the storage of threat intelligence, but rather a data model for the transmission of threat intelligence.
agreed. But at some-point its being converted into a model that can consume, enrich, process, etc the data. I think what creates the confusion from a implementation point is that the Sighting is very close in concept to a SDO. Once you factor in the additional fields of a Sighting (count, last seen, first seen, data refs, etc) it is VERY close to a SDO, and from a data model perspective they align very closely together:
A Sighting Relationship is not a custom relationship, nor does it have custom properties. A Sighting Relationship is a relationship object just like the Generic Relationship object
I think this variation is in how you worded this is important to extra clarify from a implementation standpoint: The way i read this is you expect that there is a common concept of a "Relationship" and that Sightings and the "Generic Relationship" as two implementations of that common concept of a Relationship. This may be very clear on paper / in our heads. But when you implement it gets very confusing with the overlapping terminology and very common fields names between the two implemented Relationships, and the SDO and how they have "relationships"
StephenOTT
commented
5 years ago @StephenOTT i have implemented the changes to my structure: https://github.com/StephenOTT/charon-stix/tree/master/src/main/java/io/digitalstate/stix/relationshipobjects
landed on:
If you have other insights, would be happy to implement! thanks!
As per http://docs.oasis-open.org/cti/stix/v2.0/cs01/part2-stix-objects/stix-v2.0-cs01-part2-stix-objects.html#_Toc496714342
But it is not just "additional fields", as the relationship_type field appears to be omitted.
This is a implementation annoyance because there are "common properties" found across Relationships, but they omit a single field. This creates the need to handle overrides and other variations.