Added the is_alert flag to the dictionary, the security_control profile and detection_finding class

[pagbabian-splunk]

Related Issue: 1177

Description of changes:

Added an attribute, is_alert that indicates that an event is an alertable signal, either determined by a security product monitoring activities, via the Security Control profile, or by an analytic process on one or more events via the Detection Finding class.

Note that not all findings are alertable signals, for example detection_findings have Update and Close activities that likely would not be alertable, while Create activities might be.

In addition, added the confidence and risk family of attributes to the Security Control profile, and a missing risk_details attribute to data_security_finding.

Earlier versions of the PR, and the Issue #1177 were referring to the is_alert attribute as is_detection but the meaning of the two are not the same, in particular state changes in detection_finding while finding events, are not themselves new detections warranting any signaling (unless an incident management system wants to issue update alerts as one example).

[irakledibm]

What is the purpose of this flag? Isn't a security alert a result of the detection?

[pagbabian-splunk]

Yes, it is. However there are two ways to model an 'alert' or detection, yet there was the assumption that there was only Detection Finding (which was added post 1.0). Originally security alerts were modeled by combining Security Control profile with the associated Activity event that was being monitored by the security control product. Those are the typical alerts coming from firewalls and AV products. Findings were the result of known analytics, usually coming from a SIEM or UBA type of product, and often analyzing multipile events.

The purpose of this flag is_detection is to tie the two types of detections together from a query perspective. All Detection Findings are detections, and most but not all Security Control activities are detections. This is because Security Control was expanded to apply to access control activities, starting with its applications to Web Resource Activity. Not all 'Actions' of Allowed or Denied would constitute detections.

This came up via a Slack question, on how to model alerts from Suricata, followed by some assumptions that all alerts (not just network alerts) needed to be Detection Findings (due to the name possibly). I will make this a topic for this week.

[irakledibm]

It could be determined from related_analytics and data_sources, however I guess there is no harm in having a flag.

[irakledibm]

lgfm

[Aniak5]

Great additions!

[floydtree]

I resolved this conversation, in favor of a quick followup PR to update the description of is_alert in detection finding class. Everything else in this PR looks great.