Within STIX currently, you can only establish a relationship between a STIX object that you send, and one or more third-party STIX objects. You cannot assert a relationship unless you are also providing one of the objects. This limitation hinders third-parties who specialize in analysis and discovery of threat intelligence. We need to be able to provide them with a mechanism for saying 'we think these three objects from Org A are the same as these three from Org B and are part of Campaign FS-ISAC-X' even if those objects were created by other entities.
POTENTIAL ANSWER
A top level relationship object will enable this independence. It will allow a third-party to assert a relationship between two data objects that it doesn't 'own'. This relaxing of the restriction will allow for greater 'crowdsourcing' of opinions as the options will be able to be given even if the producer doesn't have sightings of their own to contribute. It will enable people with a collection of third-party information to help others establish relationships with objects outside their namespace.
In addition, if we allow relationship objects to be sent independently of STIX data nodes (the STIX objects that describe entities) then Organizations can still match up the fact that there are relationships even if they are not allowed to actually receive the relevant STIX data node. As an example, Org A sends out a new Incident B object to a Threat Sharing group. Gov X realises this Incident is related to Campaign Y they are tracking, but they don't want to send out the details. So they instead just send out a relationship object that ties Incident B to Campaign Y, but they don't send Campaign Y object. Later on Org B sends out details of Incident C along with a relationship object that ties Incident C to Campaign Y, and Org A sees that. Org A now is able to relate Incident C with Incident B via Campaign Y even though they don't have the Campaign Y details. The relationship still provides value.
I suggest the following rules regarding the relationship object:
Make relationships a top-level object. All other STIX objects are considered STIX data nodes
Force relationships to exist ONLY if there is a relationship object linking two STIX data nodes together
Multiple relationships are shown with multiple single relationship objects
Not allow the ##COMMA## notation any longer, but replace with multiple single relationship objects.
Relationships are allowed to be sent independently of the STIX data nodes they refer to.
The reason that I am suggesting 'single' relationship objects is to allow third-parties to [+1] or [-1] each individual relationship. This would allow consumers to evaluate who to trust – if a relationship had only 1 [+1]’s and 45 [-1]’s then you know it’s probably a low confidence relationship and one that shouldn’t be trusted as much as others. See later in this document.
PROBLEM
Within STIX currently, you can only establish a relationship between a STIX object that you send, and one or more third-party STIX objects. You cannot assert a relationship unless you are also providing one of the objects. This limitation hinders third-parties who specialize in analysis and discovery of threat intelligence. We need to be able to provide them with a mechanism for saying 'we think these three objects from Org A are the same as these three from Org B and are part of Campaign FS-ISAC-X' even if those objects were created by other entities.
POTENTIAL ANSWER
A top level relationship object will enable this independence. It will allow a third-party to assert a relationship between two data objects that it doesn't 'own'. This relaxing of the restriction will allow for greater 'crowdsourcing' of opinions as the options will be able to be given even if the producer doesn't have sightings of their own to contribute. It will enable people with a collection of third-party information to help others establish relationships with objects outside their namespace.
In addition, if we allow relationship objects to be sent independently of STIX data nodes (the STIX objects that describe entities) then Organizations can still match up the fact that there are relationships even if they are not allowed to actually receive the relevant STIX data node. As an example, Org A sends out a new Incident B object to a Threat Sharing group. Gov X realises this Incident is related to Campaign Y they are tracking, but they don't want to send out the details. So they instead just send out a relationship object that ties Incident B to Campaign Y, but they don't send Campaign Y object. Later on Org B sends out details of Incident C along with a relationship object that ties Incident C to Campaign Y, and Org A sees that. Org A now is able to relate Incident C with Incident B via Campaign Y even though they don't have the Campaign Y details. The relationship still provides value.
I suggest the following rules regarding the relationship object:
The reason that I am suggesting 'single' relationship objects is to allow third-parties to [+1] or [-1] each individual relationship. This would allow consumers to evaluate who to trust – if a relationship had only 1 [+1]’s and 45 [-1]’s then you know it’s probably a low confidence relationship and one that shouldn’t be trusted as much as others. See later in this document.