Make all Telemetry Objects into SCO's

[brettforbes]

The OS Threat aim is to blend the OCA extensions, with the existing Stix Incident Management extensions and Identity Contact extensions we currently support.

We think its a perfect match, the Stix Incident Management extensions are focused on providing a single layer, at the Sightings Level, where, provenance for each of the 8 different types of evidence can be gathered, thus evidence can be weighted and the decision process semi-automated (e.g. Assessment of Competing Hypotheses), all in Stix. Stix 21 Evidence Model v8.pptx

Behaviours are just a 9th type of evidence, with a well -defined provenance and much higher weighting. They are the next step up from a basic Sighting Analytic, or OCSF Alert in terms of signal quality and weighting, as they are based on a series of deductions made on telemetry, either a prior-discovered pattern or perhaps as the result of a Hunt. Behaviours are less likely to be a false positive and should be able to generate a call to a CACAO server, to run a CACAO workflow from the library (easy if they are using our OS Threat app).

On the other hand, I can't help but feel that the specificity of the Behaviour SDO, and some of the other great ones (x-oca-detection, x-oca-detector, x-coa-playbook etc.) is diminished by being associated with objects with clearly ambiguous meanings which are purely derived from fixed rules and telemetry. They are observables and should be taken in context:

• x-ibm-finding Is this simply the summary OCSF record? An SCO, with refs to other SCO's? Is this observed based on rules?
• x-ibm-tagging Should this be weighted as highly or differently to the assignment of a TTP by a human?
• x-oca-event, how can this be similar to the Event SDO in Incident Stix extension?? Human decision vs telemetry?
• x-oca-geo Is the telemetered location of the same or different value to a human-assigned location??

We found these objects inside the examples I edited, inside an Observed Data object, so they are clearly telemetry.

In our view:

• Observables contained within an Observed Data object must form a DAG (Directed Acyclic Graph) -> Stix Best Practices
• In the original examples, the above objects are each connected to other SCO's in a DAG, perfect for a single observation (i.e. a simple decomposition process for a composite OCSF object)
• Telemetry is fundamentally different to externally assigned evidence.
• The report from the inside is different to the external derived report, and the data they hold is often different, although with overlaps (e.g. where would the Asset Registry ID be found, vs the CPU ID? Telemetry Asset SCO, or Asset SDO?
• SCO's seem the best objects for holding telemetry, SDO's seem best for human-assigned objects, stored patterns (Behaviours), or known facts (e.g. the current asset list, SBOM's, installed defences (D3FEND), user identities etc)

You guys are the first to innovate by integrating live telemetry into Stix (i.e. Stix-Shifter, Kestrel, Behaviours), and thus you guys are the cutting edge for integration of Stix with OCSF, 3rd-party detection tools and Kestrel hunts.

Thus we are in new territory and need to set the rules.. We believe the basic rule should be that since telemetry is observed, then all telemetry must be SCO's, even when it is a summary object, such as x-ibm-finding, If they are made into SDO's, then it is not clear which data is automatically generated versus, setup through human observation, rules or patterns

[DerekRushton]

At the moment STIX-Shifter is already using many of those fields as SCO's, but if there are changes it makes sense to post an issue on https://github.com/opencybersecurityalliance/stix-shifter/issues so it can be known that there may be differences.

[brettforbes]

Counter Argument that Says the 4 Objects Should Remain SDO's, and Sightings are Required

The above argument relies on the assertion that the core defining feature of an Observable is the source of the object, So if it is actually observed via telemetry, then one must classify it as an Observable, and it can be contained within the `object_refs' field of an Observed Data object.

But is this conclusion correct? Is the object type classification dependent solely on the object source? Is this the best plan for an Alert, that everything in the Alert is an SCO? IT certainly makes it easier since that is how the code is written presently.

An alternative view might say that Observables are defined as non-temporal objects that exist without a timestamp, whereas an Alert is a temporal object, and thereby x-oca-ibm-finding is a machine-driven SDO, as is x-oce-event. What matters most in the definition of an Observable is the type of thing being observed being time-independent, and the temporal aspects of an Alert must be handled as SDO's, and Alert telemetry must be modelled as a machine-driven Sighting.

Summary

The key question is how best to classify all of the objects in an Alert, and this has important implications on how to integrate Stix Behaviours and Incidents with OCSF alerting system.

A secondary question is how to distinguish between a traditional Alert generated by a rule system, with many false positives versus a directed Hunt, with far fewer false positives.

There are two answers, and each one has merit.

What is your opinion?

[brettforbes]

Conclusions - All Telemetry Objects are SCO

After some thought, my conclusion is that:

1. If there is no clear rule established, or there seems to be conflict in the rules, then we should try to find the strongest and most clearly delineated logic to apply
2. The simplest logic appears to be, all telemetry is observable, so all telemetry objects must be SCO's
3. The logic that all data derived from telemetry must become an SCO, also sharply delineates the group, there is no ambiguity in the definition
4. Making those Stix-Shifter objects SCO's makes it simple for everyone, including that the existing system does not need to change, keep sending everything from Stix shifter as an SCO in an Observed Data object
5. It has the advantage of dealing formally with these new, more complex observable objects that may be summary records, or describe concepts not currently in Stix
6. It enhances the reasoning power over the data as the provenance of stix objects is more clearly defined, which is very important
7. It enables the telemetry SCO's, such as x-oca-asset to connect to a pre-defined SDO Asset from Inventory, or x-oca-event to connect to an SDO Event input by an Incident Manager as evidence

In my simple, non expert viewpoint the picture looks like the below image, and everything delivered from Stix-Shifter should then be an SCO. Consider this simple image about an Alert.

If that image is realistic, then my conclusion is that all of those objects should be SCO's, not just the current list