In the current version of STIX Sightings are defined as Sightings of an Indicator. They are tied very closely to the Indicator, and are most often embedded within the Indicator. This close tie creates some problems which restrict the usefulness of Sightings:
In order to add a Sighting to an Indicator the producer of the original Indicator would need to publish a new version of that Indicator with the new Sightings added.
If a third-party wants to inform the producer that they have a Sighting related to the original Indicator there is no way to do so. The third-party will need to send the original producer a new Indicator with the similar details in it, but under the third-parties namespace, and then attach the Sightings they have to their own Indicator object. The producer of the original Indicator would need to somehow recognize that the Indicator is the similar to the same one that they sent out earlier, and would need to resend a new updated original Indicator with the third-parties Sightings attached.
POTENTIAL ANSWER
This proposal requires the changes suggested within section 5 – “Observables, Observable Patterns and Observable Instances differences aren’t easily discerned”. In that proposal the name of Observable Instances (STIX Observables) would be changed to become STIX ‘Observations’. STIX Observations would be restricted from use within the STIX Indicator object.
Observable Patterns would be re-labeled STIX ‘Patterns’. STIX Patterns would only be allowed to live within the STIX Indicator Object, restricting them to describing what one would need to look for in order for the Indicator to trigger.
This separation of function would make the role of the Indicator and Sighting easier to understand for new users of STIX; The Indicator contains ‘things you should look for’, and the Observation contains ‘things you’ve seen’.
Proposal
Rename Observable Instances to STIX Observations
Rename Observable Patterns to STIX Patterns
The new top-level Relationship Object (mentioned elsewhere in this document) is used to relate that fact a Sighting was detected. The relationship would link the Observation with the Indicator with a relationship type of ‘Sighting_of’ or something similar.
Observable patterns aren’t used within an Observation object, and instead live within an Indicator.
The Indicator object is also restricted to only containing STIX Patterns, and loses the ability to contain Observations.
Deprecate embedded indicator sightings.
This effectively creates a nice separation between 'things we need to look for' (Indicators+ Patterns) and 'things we have found' (Observations).
PROBLEM
In the current version of STIX Sightings are defined as Sightings of an Indicator. They are tied very closely to the Indicator, and are most often embedded within the Indicator. This close tie creates some problems which restrict the usefulness of Sightings:
POTENTIAL ANSWER
This proposal requires the changes suggested within section 5 – “Observables, Observable Patterns and Observable Instances differences aren’t easily discerned”. In that proposal the name of Observable Instances (STIX Observables) would be changed to become STIX ‘Observations’. STIX Observations would be restricted from use within the STIX Indicator object.
Observable Patterns would be re-labeled STIX ‘Patterns’. STIX Patterns would only be allowed to live within the STIX Indicator Object, restricting them to describing what one would need to look for in order for the Indicator to trigger.
This separation of function would make the role of the Indicator and Sighting easier to understand for new users of STIX; The Indicator contains ‘things you should look for’, and the Observation contains ‘things you’ve seen’.
Proposal
This effectively creates a nice separation between 'things we need to look for' (Indicators+ Patterns) and 'things we have found' (Observations).