At present it is nearly impossible for third parties to indicate their agreement or disagreement with another Organizations assertion. The ability to indicate agreement is critical for the following useful functions:
The ability to [+1] a relationship to confirm your agreement.
The ability to work out which source to trust
The ability to recognize that an Organization believes something that is not commonly thought
The ability to ignore a particular information source as a source of disinformation.
There is no current way for a third party producer to disagree with content published by another party. For example, if Org A pushed out content that described 8.8.8.8 (Google DNS) as being malicious, we need a way for the community to 'push back' this assertion. A way for the community to say I disagree with this assertion.
In a similar vein, we need the ability for Organizations to agree with assertions that other Organizations make. If Org A sends out content that says www.baaadsite.com is malicious and is part of the Dyre malware family, and Orgs B and C agree, then we need to give them a way for Orgs B and C to share the fact that they [+1] that assertion.
At present the best Orgs B and C can do is to send out their own TTP/Campaign object with references to a combination of their own Indicators with their similar evidence, and references to the Org A Indicators. They then need to hope that other members of the Threat Intelligence sharing community work out the relationship to the Org A TTP/Campaigns themselves.
At present Org B and Org C cannot disagree directly with Org A through STIX, but instead can only produce their own assertion of what happened.
POTENTIAL ANSWER
One way this could be fixed is with the creation of a top-level Opinion Object. This object would provide the ability to explicitly agree/disagree with another object. The opinion object would be allowed to refer to STIX data objects (e.g. Indicator, Observable, TTP, etc) or directly to Relationship objects, allowing producers to either agree/disagree with the data or the relationships between the data
.
The Opinion Object would be small, with basically the following psuedo-structure:
opinion_object {
id: QName # this id of this opinion
timestamp: # just so that this can be updated at a later date ()
version: # the version of this opinion object (e.g. '1')
object_ref: QName, # the id of the referred object.
agreement: ['strongly agree', 'agree', 'undecided', 'disagree', 'strongly disagree', 'unknown'],
description: StructureTextString,
source: InformationSourceType
}
ANOTHER POTENTIAL ANSWER
This could also be fixed by just defining how we use a top-level Relationship object, such that sending a +1 actually results in a producer sending their own relationship object (with an ID in their namespace) that has links between the IDs of the objects they agree/disagree with. Rather than explcitly disagreeing with another Orgs assertion of a relationship, this method would require the consumer to recognize that there are 2 relationships saying there is a relationship and 5 saying there is not a relationship. Then it is up to the recipient to decide who to trust (as it should be).
As an example, imagine that Org A sends out Indicator A, TTP A, and a relationship object Rel A that links the two together to show they are related. Org B disagrees, and sends out a Rel B object which still refers to Indicator A and TTP A, but which asserts there is not a relationship.
The disagreement is not explicit. It is up to the consumer to determine the fact the competing relationship objects are referring to the same Objects.
PROBLEM
At present it is nearly impossible for third parties to indicate their agreement or disagreement with another Organizations assertion. The ability to indicate agreement is critical for the following useful functions:
There is no current way for a third party producer to disagree with content published by another party. For example, if Org A pushed out content that described 8.8.8.8 (Google DNS) as being malicious, we need a way for the community to 'push back' this assertion. A way for the community to say I disagree with this assertion.
In a similar vein, we need the ability for Organizations to agree with assertions that other Organizations make. If Org A sends out content that says www.baaadsite.com is malicious and is part of the Dyre malware family, and Orgs B and C agree, then we need to give them a way for Orgs B and C to share the fact that they [+1] that assertion.
At present the best Orgs B and C can do is to send out their own TTP/Campaign object with references to a combination of their own Indicators with their similar evidence, and references to the Org A Indicators. They then need to hope that other members of the Threat Intelligence sharing community work out the relationship to the Org A TTP/Campaigns themselves.
At present Org B and Org C cannot disagree directly with Org A through STIX, but instead can only produce their own assertion of what happened.
POTENTIAL ANSWER
One way this could be fixed is with the creation of a top-level Opinion Object. This object would provide the ability to explicitly agree/disagree with another object. The opinion object would be allowed to refer to STIX data objects (e.g. Indicator, Observable, TTP, etc) or directly to Relationship objects, allowing producers to either agree/disagree with the data or the relationships between the data . The Opinion Object would be small, with basically the following psuedo-structure:
ANOTHER POTENTIAL ANSWER
This could also be fixed by just defining how we use a top-level Relationship object, such that sending a +1 actually results in a producer sending their own relationship object (with an ID in their namespace) that has links between the IDs of the objects they agree/disagree with. Rather than explcitly disagreeing with another Orgs assertion of a relationship, this method would require the consumer to recognize that there are 2 relationships saying there is a relationship and 5 saying there is not a relationship. Then it is up to the recipient to decide who to trust (as it should be).
As an example, imagine that Org A sends out Indicator A, TTP A, and a relationship object Rel A that links the two together to show they are related. Org B disagrees, and sends out a Rel B object which still refers to Indicator A and TTP A, but which asserts there is not a relationship.
The disagreement is not explicit. It is up to the consumer to determine the fact the competing relationship objects are referring to the same Objects.