I have to admit I am still a fan of a separate Sightings object and Relationship object. The reason is specifically 'graph' based - nodes and edges. As I've said for more than a year now we need to separate the 'data' nodes describing 'things'
from the edge nodes (the assertions that people make). If we conflate these things together as we do currently with the Sightings within the Indicator object, we lose flexibility, and the ability to do some interesting things in the future, such as:
-----
Use Case:
- Company A is being attacked. They wish to find out from their friends in TrustGroupAlpha if anyone else has seen this before.
- CompanyA send out a CompanyA Sighting object containing the IP address (IPAddress X) that the malicious actor used along with a (new theoretical) STIX Query object, with a relationship object joining them together. The broadcast is sent to the TrustGroupAlpha
TAXII channel.
- Company B is listening to the TrustGroupAlpha TAXII channel, and had seen IPAddress X before during a previous attack it had received.
- CompanyB creates a (new theoretical) STIX Response object containing the CompanyB Sighting object that matched the CompanyA Sighting object, along with every STIX object that it thinks CompanyA would benefit from knowing. It adds the the related CompanyB
ThreatActor, the related Indicators (observable patterns only) that helped CompanyB detect this ThreatActor, and all the relationships that map the CompanyB objects together. And finally it adds a relationship object between CompanyB Sighting object and CompanyA
sighting object inferring that it is the same IPAddressX
- CompanyB sends that back to the TrustGroupAlpha TAXII channel.
- CompanyA receives the (new theoretical) STIX Response object and now can add the new information it received into its database if it thinks the information is worth adding.
Company A now has more information about the attacker that is attacking it. It now has additional Indicators that will allow it to check if this is really an attack from that ThreatActor, and if so, CompanyA will be able to send out a STIX Package (broadcast)
out to the TrustGroupAlpha indicating that the CompanyA Incident is related to the CompanyB Incident and that CompanyA thinks it was the same ThreatActor in both cases.
This also allows all organizations listening to the TrustGroupAlpha trust group to keep track of this conversation and compile their own lists of Indicators/Incidents/ThreatActors/etc such that they are better prepared if the ThreatActor targets them.
Keeping relationships completely separate from data objects will allow us to retain flexibility for the future, and will allow producers and consumers to describe relationships that we haven't even thought of yet.
STIX should provide people the building blocks to describe what they are seeing in the real world. Just like Legotm people should be able to build what they want out of those building blocks. We just need to provide enough building
blocks to be useful, and the ability to put those building blocks together (i.e relationships).