terrymacdonald
commented
8 years ago The original diatribe that started this issue:
I’ve been thinking about Aharon’s assertion that you should be able to ‘sight’ anything. It set me to thinking what that relationship is, and how it could work.
What is a Sighting?
The dictionary definition of Sighting is ‘to see, glimpse, notice, or observe’. In this respect Aharon is right, a sighting is effectively saying ‘I’ve seen something that I noticed’. This potentially could be applied to any object that we have in STIX.
If an Organization has identified that the person behind their attacks is likely to the same Threat Actor APT99 they read about in a TrendMicro report, then they could conceivably want to ‘sight’ the fact they think they have a relationship between their Incident and the Threat Actor. We already have a relationship type within STIX for that kind of relationship: RelatedThreatActor. The Organization can create a relationship object that connects the ThreatACtor APT99 with their Incident Object, and send that with their Incident object out to the community. Others then have the ability to recognize that Organizations assertion that the two are related. I believe this can be done without the need for a separate Sighting object; all it needs is a relationship object of the correct type for that relationship connection
i.e. relationship from ThreatActor to TTP should be of type ‘RelatedTTP’ relationship from ExploitTarget to COA should be of type ‘RelatedCOA’
When most people have been talking about sightings, it has been in the context of establishing relationship between and Indicator and an Observable Instance.
Now, just for clarity, I’ll point out I hate the use of Observables as both Instances and Patterns. It confuses the heck out of people. I too would like to only use Observables as Observable Instances, and handle patterns in their own way (as you have mentioned in your Open Questions here: https://github.com/johnwunder/twigs
For the rest of this diatribe I will refer to Observable Instances as Observations.
When people have been discussing Sightings, they have been saying things like ‘this observation is a sighting of this Indicator’, or ‘ we sighted this indicator and this is the observation that matched’. In both cases, I saw the objects and relationships as ‘this observation is a sighting of this Indicator’
i.e. In neo4j Cypher parlance = (observation) –[:sighting]-> (indicator)
In other words, even in a relationship between an Indicator and an Observation I still believe a relationship of the correct type is enough to describe it (i.e. relationship type: sighting).
Maybe what we need is actually to rename the relationship type to something else? Or maybe put it in the other direction? i.e. (observation) –[:matched]-> (indicator) ? (indicator) –[:observed]-> (observation)?
If we used a relationship type that’s not sighting then we bypass the whole ‘whats a sighting’ argument .
We could potentially do it this way: • Rename TWIG Sighting Object to TWIG Observation Object • Use the TWIG Observation object each time an Indicator is matched • Use individual relationships of type ‘Matched’ to link each Observation to the Indicator • The Observation Object would have a timestamp recording when the Observation was made • The related ‘Matched’ relationship Object would have a timestamp recording when the Observation was recognized as a triggering of the Indicator. • The Indicator object could still contain a Observation_count to allow an overview of how common that Indicator has been detected if the consumers don’t need to know the full list of matching Observations.
Other related things
We need a way of: • Saying ‘this thing I have is related to those other things you asserted’ (can be done via relationship object linking two ‘data objects’) • Saying ‘these two things are related’ (can be done via relationship object linking two ‘data objects’) • Saying ‘we think that too’; Agreeing and Disagreeing (can’t be done at the moment)
For this last part, I envisaged we needed a way for a community member to disagree with an assertion that another community member has made. As an example if VendorA says ‘IP 8.8.8.8 is bad with a high confidence’ then we want the community to be able to say ‘no it isn’t’.
In my thinking on the subject I concluded that we needed a way of agreeing and disagreeing two different groups of things:
- Whether an assertion regarding an entity was correct
- Whether an assertion regarding the relationship between two entities was correct.
This was potentially going to be difficult, but with the acceptance of the top-level relationship object it became a whole lot easier. A relationship object will have an Object ID, just like the STIX data objects – meaning that any agree/disagree object would only need to refer to an Object ID in order to apply to it. This prompted the following proposal… the creation of the Opinion Object:
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 } Please note this object is from the suggestion made within the ‘STIX Difficulties v1.4 Final.docx’ and hasn’t been modified at all to work with TWIGS.
This object will help people be able to disagree with relationships and with other ‘data node’ objects that others provide. The idea is that it explicitly applies to particular objects that people share, allowing anyone (except the original producer) to agree or disagree with the information in the original STIX Object. The original producer cannot agree or disagree with what they have already asserted by sending out their STIX Object. They can only modify their assertion by sending out a new replacement object; the producers opinion is always demonstrated through the publishing of the most current ‘version’ of the original object.
When people have been discussing Sightings, they have been saying things like ‘this observation is a sighting of this Indicator’, or ‘ we sighted this indicator and this is the observation that matched’. In both cases, I saw the objects and relationships as ‘this observation is a sighting of this Indicator’
i.e. In neo4j Cypher parlance = (observation) –[:sighting]-> (indicator)
In other words, even in a relationship between an Indicator and an Observation I still believe a relationship of the correct type is enough to describe it (i.e. relationship type: sighting).
John proposed the following: