OCSF doesn`t provide information on the event original threat value/score

[Noafr]

Problem Users may want to query for the threat score of the event as given by the ref (original) source. Vectra (AI-driven threat detection and response for hybrid and multi-cloud enterprises), for example, sends the $threat field which is a value between 0 to 80. Analysts that are used to working with Vectra may want to query for something like ref_severity = 67 which is more specific than our current normalized range for the severity column (values between 1-6).

Suggestion ref_severity (suggested field name) should be added to the base event to reflect the threat score/severity given by the source. The field should be of type string as different vendors might send this data differently (for example, Okta sends a Severity field as type string (DEBUG, INFO, WARN, ERROR etc.))

[floydtree]

The current severity field addresses your concern.

---

I would qualify this line by stating that how we handle such pairs (severity/severity_id, status/status_id et al) across OCSF is still under debate and consideration. You are welcome to join the discussion here on slack.

[Noafr]

Thank you - I've been told the "severity" column is just a reflection of the severity id (e.g. "Low", "Critical" etc.).

[rroupski]

Perhaps, we can add score or raw_score attribute to Malware object?. Will that help?

[Noafr]

Why Malware object? Not all events are classified as malware. Why not add the raw_score (I`d vote for ref_score) to the base event?

[Aniak5]

We are proposing a general purpose solution for all reference attributes to the original data.

[pagbabian-splunk]

reference to original data has the naming convention of ref_. I can see it maybe could be used outside of Malware however if we are considering it to be a "threat score" rather than an arbitrary score, then Base Event may be too general of a location. Do we have knowledge of where we want to apply threat scores such that we can consider where it should reside?

[Aniak5]

This issue has been addressed within this PR.