Update the Security Finding class with attributes from the Splunk Detection Report extension class (Part 2)

[pagbabian-splunk]

Refer to Discussion/Proposal #490 for Part 1 and set 1 of the attributes. This proposal considers set 2.

All attributes are Optional or Recommended (non-breaking additions).

Add the following attributes to the Security Finding class:

Set 2:

(Note: confidence is present as a Base Event attribute: "The confidence of the reported event severity as a percentage: 0%-100%." It is the sibling in this proposal for the new confidence_id with the same specific usage.)

Additional New attributes:

confidence_id enum [Unknown, Low, Medium, High, Other]
impact integer [0-100] -- integer sibling, ascending numeric range from Low to Fatal
impact_id enum [Unknown, Low, Medium, High, Critical, Other]
data_sources array of Strings -- which products or sources contributed to the finding
evidence JSON -- the data the Finding exposes to the analyst
analytic Analytic -- the rule, statistic, behavioral or ML algorithm used (new object, subsumes Rule)

Additional standard attributes:

risk_level_id enum [Unknown, Low, Medium, High, Critical, Other]
risk_level String sibling -
-- rule Rule object subsumed by the new Analytic object based on Rule

Per further discussion below 2/28/2023, the following modifications to the proposal:

The impact_id enum in the Splunk extension included a Fatal value. Removed for this core class proposal to match risk_level_id. (The Splunk extension can override to add Fatal). However, the cutoff points in the range cannot be standardized (i.e. some vendors may use probabilistic quantiles that are not equally spaced for the numeric range mappings).

I will add a separate proposal to consider the addition of an Analytic object, and associated attribute for the class, in addition to Rule. Along with that, a discriminator enum that calls out whether the Finding was due to a rule or the analytic (e.g. anomaly detection, behavioral, ML etc.). The combination of the two in the class with a discriminator enum captures the Detection concept without adding another level (and is more compatible with the Splunk extension).

In this way, the current proposal does not need to be re-voted.

[floydtree]

confidence_id - Okay
data_sources - What would this field mean in context of a finding? This feels a little ambiguous, perhaps leave it as a Splunk extension to this class.
evidence - This one appears to be implementation specific too, same recommendation - good for Splunk Extension.
impact/impact_id - Okay
risk_level/risk_level_id - Okay, so now we have severity, risk_level and impact. 3 tightly related attributes.
rule - Okay

[irakledibm]

agree with all

[pagbabian-splunk]

I did remove data_sources and evidence already in the edited proposal and vote. @irakledibm if you want those too we can discuss on the call this morning.

[JasonKeirstead]

Can I suggest instead of the field being called "rule", it be called "analytic" or perhaps "detection", as it makes this change more flexible to be able to encode references to detection methods that are not rule-based, such as behavioural detections or ML detections.

[irakledibm]

Rule is an object in OCSF. I would probably add detection_type property with an choices { rule/policy, ml/ai, ...}, make Rule as recommended and maybe add ai_detection or ml_model as a separate properties.

[pagbabian-splunk]

Good suggestion. FYI: the original version of the Splunk extension had used this same approach. We had an enum that also indicated "Conclusion" and "Anomaly" as results of an "Analytic". Let's discuss this morning on the weekly call.

[awhite456]

In this proposal, there are three enumerations, each with a different number of values. I worry that different vendors are going to have different concepts or buckets for these values that will not be compatible. Would it be better to produce a standardized mapping of what level a number between 0-100 is?

[floydtree]

That's a good point.
@pagbabian-splunk - At the very least, although the proposal doesn't highlight this, as we bring these extra fields in, we should ensure we are following our "sibling conventions", currently these fields are not consistent.

i.e. _id fields are normalized int enums & sibling strings are normalized to the caption of the _id value. In the case of 'Other', it is defined by the event source.

To implement this we'll need to define what level a number between 0-100 is as @awhite456 mentioned.

[pagbabian-splunk]

Points taken. I also noticed this - the siblings are numeric rather than String, which is not our convention. I assume you mean for 'what level...' something like 'larger numbers have more impact, etc. We wouldn't be able to assume that 90 => Fatal for example. Or what the cutoff points would be in general. As these came from the Splunk extension, I know that the Splunk detection team uses both attributes with their own internal cutoff points. I don't think they use the numeric field as a normal sibling (i.e. via Other). I need to consider a better way here.

[pagbabian-splunk]

Please re-read the proposal text. -I tried to capture the above concerns. In addition, a separate proposal will be created to add an Analytic attribute to the class, with a discriminator enum, so we keep the proposal intact.