How do I model a detection?

[pagbabian-splunk]

There has been some discussion and confusion on how to represent a security detection in OCSF. One obvious approach is to use the Detection Finding class, however it isn't appropriate for all types of detections: it was designed for events representing analytics systems such as SIEMs where in general there are many events, not all themselves detections, behind the finding, and those events may all have different activities. While the evidences array can hold auxiliary information that the detection may have affected, or artifacts that may be causal to the detection, the Detection Finding does not directly give any information about a single activity that signaled the detection. These are usually thought of as security alerts, although we avoid the name alert in the schema as one product's alert output may be another consuming product's event. A detection is more general.

The Security Control profile is intended to augment activities that are monitored by a security product, either a detection point like an IDS, or an enforcement point like a firewall or anti-malware solution. The profile is added directly onto the activity classes, such as the System Activity and Network Activity classes, thereby directly preserving the underlying activities, for example detection of malware when a file is opened, or denial of a connection when opened. The disposition of the event, added by the profile, reflects the outcome of the activity that was monitored by the security control. For example, the file open may be blocked when malware is detected, or the file might be quarantined.

Note that the profile can also be applied to Detection Finding (and Data Security Finding) in the cases where the analytic against the events also produced some type of control action. In the case of a SIEM, it might be running a SOAR playbook or other action.

The issue with having these two approaches is that an analyst wants to know about any detection, regardless of how it was determined. One approach would be to query for the Security Control profile, but not all Detection Findings need the profile, yet they are still detections by their very name.

The solution proposed is simple: add a new attribute, is_detection, to the profile and to the Detection Finding class. When an event or a finding is a detection, it is set to true. In the case of Detection Finding this should always be the case. For most other events that are augmented by the profile, due to the event stemming from a security product control point, is_detection should also be set to true.

A top level query of all events where is_detection = true would return any "alerts" as well as any detection findings.

The Security Control profile can also be used for non-detection oriented controls, such as access control on Application Activity. In this case, is_detection would be set to false.

[mavam]

Thanks for structuring the conversation around this topic, Paul.

it was designed for events representing analytics systems such as SIEMs where in general there are many events, not all themselves detections, behind the finding, and those events may all have different activities.

In this light, a Detection Finding feels like a bundle of individual events (finding_info.related_events) plus the judgement implied by the finding. It reminds me a bit of a STIX bundle in the TI world. While related_events is only optional, recommended is the evidences array. Is the semantic difference, that related events are auxiliary context whereas evidences clear indicators for the finding? It might be hard to draw the line in practice.

Note that the profile can also be applied to Detection Finding (and Data Security Finding) in the cases where the analytic against the events also produced some type of control action.

This requires quite some mental flexibility in order to see a "control action" something like a SOAR dispatch trigger. I actually like the word "action" much better, as it simply signifies that something has acted upon something else. The world "control" feels from a firewall era where inline security measures were the norm. So perhaps we should consider a different name?

More importantly, though, it seems that this profile is currently the only way to "alertify" existing events. By injecting the profile, we obtain the judgement from the thing that worked on the event. Since many detection tools operate by tagging/flagging events, I expect seems that escalating a regular event through profile injection a standard use case. Suricata alerts, for instance, work exactly like this. They basically attach an alert record to a regular event.

In OCSF, it would be nice to have a standard procedure where we can capture the alert details through the injected events. This is currently ill-supported. For example, the alert message would have to put in the Base Event's message field.

I see two options: adding a new profile that is geared towards alertification, or enhancing the Security Control profile.

The solution proposed is simple: add a new attribute, is_detection, to the profile and to the Detection Finding class.

I find this confusing, as it feels like a tautology—at least for the Detection Finding. The name of the event implies that it's a detection. While I see where you are coming from, I would expect newcomers to have a hard time with these semantics. Perhaps we can have an enumeration type, with detection being one of many, e.g., contain, mitigate, observe, block, allow, redirect, quarantine, terminate. We could borrow from STIX, CACAO, and OpenC2.

[pagbabian-splunk]

Good comments Matthias - I will make this a topic for this week's call. To some extent, having is_detection as a true for Detection Finding is a bit of a hack, but it is also a simple way to tie together other types of detections, in particular the 'alertified' existing events as you put it. Security Control is indeed intended to be that thing, and it includes an Action enum although the profile name is not named action - the thinking is that the control point invokes the action, but we could have named it Security Action instead. I hesitate to rename it in 1.x as it would be a breaking change, or it would be a deprecation just for the name change.

As for it being confusing, it might be at first, but a query for any event where is_detection = true would bring back all Detection Finding events and all 'alertified' events via Security Control, rather than to have to construct an OR query, and look into the profiles array to compare with the Security Control string.

[davemcatcisco]

A few thoughts from me on this proposal...

Paul: One obvious approach is to use the Detection Finding class, however it isn't appropriate for all types of detections: it was designed for events representing analytics systems such as SIEMs [...]

This is not the impression given by the description for Detection Finding in the schema. It is very inclusive and simply says that it "describes detections or alerts generated by security products using correlation engines, detection engines or other methodologies."

Paul: While the evidences array can hold auxiliary information that the detection may have affected, or artifacts that may be causal to the detection, the Detection Finding does not directly give any information about a single activity that signaled the detection.

Detections often arise not from a single activity but rather from a sequence of activities. This means that embedding information about a single activity would lack generality anyway. The related_events attribute in a Detection Finding directly points to the activities (plural) that precipitated the detection. I acknowledge that it doesn't directly give any information about the activities, but I think it does provide the information indirectly.

I think that the existence of multi-activity detections weakens the case for a "this activity is malicious" flag. An approach based on flagging a single activity cannot describe a multi-activity detection. This could lead to inconsistent and/or overly complex implementations because a vendor might decide to set the is_detection flag to communicate a single activity detection, but to synthesise a distinct Detection Finding event in the case of a multi-activity detection. I think interoperability is maximised when standards avoid offering multiple ways to represent the same thing.

Applying the Security profile to activities to pull in the proposed is_detection flag would also pull in the action_id attribute. This required attribute is not appropriate for a pure EDR product that is focused on non-remediative visibility. Its only permitted values are Allowed and Denied, and both of these imply that the EDR actively took a decision when, in fact, no decision was taken. One possible objection to my argument here is that a visibility-focused product would not be detecting anything. But such products certainly can raise detections. The severity_id attribute in a Detection Finding includes an Info value which indicates no finding of malicious intent. Our product uses this to describe MITRE TTPs that are identified in activity streams.

A final concern about this proposal is that the usefulness of the is_detection attribute seems to be premised on the assumption that heterogeneous events are stored or presented in a table of sparse columns a la Splunk. In other words, there's an assumption that a consumer of OCSF events can run a search like index="foo" is_detection=true. I very much doubt that this assumption will hold true in all OCSF implementations. I suspect many implementations will have each event class living in its own "table" (for want of a non-RDBMS word). If this assumption doesn't hold true, the value of a common is_detection attribtue is diminished.

[pagbabian-splunk]

Good thoughts Dave, thanks. Yes, this approach isn't perfect - however, note thqt this came about because Matthias found that Detection Finding could not model the outputs of Suricata, he needed the activity data of source, destination, ports etc. that the Network Activity classes offer. The Security Control profile was designed for this purpose, and when I pointed this out to him, it solved his initial problem. Before we had profiles, we had sibling 'Alert' classes for every Activity class in System and Network. Note that originally there was not the action_id with Allowed and Denied as required fields: we added that for access control 'controls' rather than having sibling classes, overloaded classes, or a separate profile.

Similarly, there was a Firewall profile that effectively was the same as Security Control but had a firewall_rule rather than a Malware or Attacks object. Again, we combined them. It was noted in the same thread that firewall_rule can be named detection_rule as it doesn't have to be a firewall policy.

EDR activities and verdicts and judgements were never inteded to be Security Control profile events - unless they are also acting as control points - i.e. blocking activities. Therefore, I wouldn't discredit the Security Control approach on activities based on EDR - it can and apparently does find Detection Finding sufficient (and it is possible to still apply Security Control).

Hence, tying these different types of detections together. Querying them is simpler if there is something that is common and until now, the original activity overlay approach is lost with Detection Finding (as evidenced by Matthias' inability to use Detection Finding for network alerts). However I should note that Matthias called out the tautology of a Detection Finding having an is_detection attribute - I consider it to be somewhat of a hack myself, needed to tie the two approaches together in the aftermath of this parallel evolution that often happens in early stages of development.

I am not married to this approach, what I am against is using evidences array as a way to carry activity class information indirectly from a control point emitting its verdict on an activity. Security Control also has a fairly comprehensive dispostion_id list common to many control points (and again is available to Detection Finding - it is possible that having action_id be Required was too stringent, however we document that a disposition_id = No Action with an action_id = Allowed is for monitoring controls that don't do enforcement. The prior 'Alert Activity' family of classes worked well at Symantec for endpoint alerts, and network alerts. Knowledge of the Analytic which is required for Detection Finding was usually unknown in the event itself.

Lastly, Finding in general can be a multi-state event, if you look at the progression of activitiy_id and associated status_id (New, In Progress, Suppressed, Resolved). Findings are so far more akin to workflow items than pure alerts.

In any case, this is a topic for tomorrow's weekly call as it has caused quite a stir - hope you can join.

[davemcatcisco]

Regarding action_id and disposition_id, I wasn't aware of the significance of the No Action value for the latter. That does make the Security profile more suitable for use in non-enforcing contexts. Might it be even clearer though to have an explicit None entry in the action_id enum? It's a little contradictory for the disposition_id to say that No Action has been taken and for the action_id to say that the activity was Allowed.

[pagbabian-splunk]

Yes in fact I was updating the PR to do exactly that, but I haven’t pushed it until we discuss today. Paul (from my mobile device)

…

On Tue, Sep 17, 2024 at 3:47 AM Dave McCormack ***@***.***> wrote: Regarding action_id and disposition_id, I wasn't aware of the significance of the No Action value for the latter. That does make the Security profile more suitable for use in non-enforcing contexts. Might it be even clearer though to have an explicit None entry in the action_id enum? It's a little contradictory for the disposition_id to say that No Action has been taken and for the action_id to say that the activity was Allowed. — Reply to this email directly, view it on GitHub <#1177 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AS5LBZTPD3WKM7Q3QCWJF3TZXACCTAVCNFSM6AAAAABOGETUQKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNJVGI4TENZZGI> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[rstillio]

I recommend producing one or two good concrete scenarios with real world example data, ideally from multiple cross-domain producers, to hang this entire conversation on and demonstrate. Without examples, it's hard for me to follow or provide substantive feedback.

[sunilamin]

I have to be honest, the "alertification" of activities using the Security Control profile is not something I would have expected. In my head, ALL alerts would be represented by Detection Findings that, possibly, point to one or more events using related_events. A "wrapper" if you will. I also never envisioned searching anything other than the Detection Findings table for alerts.

Considering that, no wonder I was struggling to find a spot for alert "details". Across the domains of endpoint, network, email and identity, alone, the possible set of alert details is large but I thought the intent of evidences was present for that exact reason.

I was unable to attend the last Thursday call. Was any consensus reached?