-
Notifications
You must be signed in to change notification settings - Fork 360
6.1 ‐ How are risk score calculated for RBA
Each ESCU detection now comes with an attached risk_score value, this value is derived from a simple formula risk_score=(impact * confidence)/100. Where impact and confidence are 0-100 number values based on the detection author's judgment. Impact captures the effect the attack will have on an organization and confidence in how accurate the analytics is at catching said threat. This is also documented under each detections in research.splunk.com see: https://research.splunk.com/endpoint/attempted_credential_dump_from_registry_via_reg_exe/#rba
Impact: This refers to the potential severity or consequences of the threat or activity that the detection rule is designed to identify. Impact measures how significant a threat is in terms of potential damage or risk to the organization's assets, data, or operations. For example, a rule detecting a potential data breach would have a high impact due to the severe consequences of data loss or exposure.
Confidence: This is a measure of how accurately a detection rule identifies genuine threats without generating false positives. A rule with high confidence can reliably distinguish between actual malicious activity and benign actions that might appear suspicious. Confidence is crucial for ensuring that security teams are alerted to real threats without being overwhelmed by false alarms. Impact and Confidence today are somewhat arbitrary base on the detection author.
The rule of thumb we use is:
- 0-25 low
- 25-50 medium
- 50-80 high
- 80-100 critical / ** extremely high **
-
Low Impact: These are threats that have minimal consequences for the organization. They might represent minor policy violations or low-level security risks that don't significantly compromise data, systems, or operations. Actions triggered by low impact rules often don't require immediate response but may need monitoring or periodic review.
-
Medium Impact: This category includes threats that could potentially cause moderate harm to the organization's assets, reputation, or operations. They might not be immediately critical but could escalate if not addressed. Medium impact rules typically warrant timely investigation to assess and mitigate potential risks.
-
High Impact: High impact threats pose a significant risk to the organization. They could lead to substantial data loss, service disruption, financial loss, or other serious consequences. Detection rules with high impact require immediate attention and action to prevent or limit damage.
-
Critical Impact: This highest level is reserved for the most severe threats, which pose an imminent and critical risk to the organization’s core operations, data security, or existence. These might include advanced persistent threats (APTs), major data breaches, or other catastrophic events. Critical impact rules necessitate an urgent and comprehensive response, often involving multiple layers of the organization, including top management.
-
Low Confidence: Detection rules with low confidence are likely to generate a higher number of false positives. These rules might be based on less reliable indicators of compromise or vague behavioral patterns. They require more validation and are typically used for initial flagging rather than immediate action.
-
Medium Confidence: Medium confidence rules strike a balance between accuracy and sensitivity. They are more reliable than low confidence rules but still have a moderate risk of false positives. These rules might require correlation with additional data or context to ascertain the legitimacy of the alert.
-
High Confidence: High confidence rules are expected to accurately detect threats with minimal false positives. They are based on well-corroborated indicators or behaviors strongly associated with malicious activity. Alerts generated by these rules are often taken seriously and may trigger immediate investigation.
-
Extremely High Confidence: Rules at this level have the highest degree of reliability and are based on definitive, proven indicators of compromise or attack patterns. Critical confidence implies that an alert almost certainly indicates a real threat. Responses to these alerts are prioritized, and immediate action is often required to address the detected issue.
credits to: Ryan Long
The risk and threat objects are created with the following logic:
-
When the observable
type
is'User', 'Username', 'Email Address'
:- The
risk_object_type
isuser
in savedsearches.conf - The
risk_object_field
is thename
of the observable in the detection.yml
- The
-
When the observable
type
is'Device', 'Endpoint', 'Hostname', 'IP Address'
:- The
risk_object_type
issystem
in savedsearches.conf - The
risk_object_field
is thename
of the observable in the detection.yml
- The
-
When the observable
type
is NOT matching the above list:- The
risk_object_type
isother
in savedsearches.conf - The
risk_object_field
is thename
of the observable in the detection.yml
- The
-
When the observable
role
isAttacker
:- The
threat_object_type
is thetype
of the observable in the detection.yml - The
threat_object_field
is thename
of the observable in the detection.yml
- The
- Role:(Choose one or many of the following)
` "Other"
"Unknown"
"Attacker
"Victim"
- Types: (Choose one)
"Hostname"
"IP Address"
"Email Address"
"URL String"
"File Name"
"File Hash"
"Process Name"
"Endpoint"
"User"
"Email"
"File"
"Process"
"Registry Key"
"Registry Value"
"Other"