Merge pull request #3187 from splunk/integration_alerts_detection

Alerts- update risk_score

detections/endpoint/detect_critical_alerts_from_security_tools.yml

@@ -8,7 +8,7 @@ type: TTP
 data_source:
 - Windows Defender Alerts
 - MS365 Defender Incident Alerts
-description: The following analytics is to detect high and critical alerts from endpoint security tools such as Microsoft Defender, Carbon Black, and Crowdstrike. This query aggregates and summarizes critical severity alerts from the Alerts data model, providing details such as the alert signature, application, description, source, destination, and timestamps, while applying custom filters and formatting for enhanced analysis in a SIEM environment.This capability allows security teams to efficiently allocate resources and maintain a strong security posture, while also supporting compliance with regulatory requirements by providing a clear record of critical security events. We tested these detections with logs from Microsoft Defender, however this detection should work for any security alerts that are ingested into the alerts data model.
+description: The following analytics is to detect high and critical alerts from endpoint security tools such as Microsoft Defender, Carbon Black, and Crowdstrike. This query aggregates and summarizes critical severity alerts from the Alerts data model, providing details such as the alert signature, application, description, source, destination, and timestamps, while applying custom filters and formatting for enhanced analysis in a SIEM environment.This capability allows security teams to efficiently allocate resources and maintain a strong security posture, while also supporting compliance with regulatory requirements by providing a clear record of critical security events. We tested these detections with logs from Microsoft Defender, however this detection should work for any security alerts that are ingested into the alerts data model. **Note** - We are dynamically creating the risk_score field based on the severity of the alert in the SPL and that supersedes the risk score set in the detection.
 search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime values(Alerts.description) as description values(Alerts.mitre_technique_id) as annotations.mitre_attack.mitre_technique_id values(Alerts.severity) as severity values(Alerts.type) as type values(Alerts.severity_id) as severity_id values(Alerts.signature) as signature values(Alerts.signature_id) as signature_id values(Alerts.dest) as dest from datamodel=Alerts where  Alerts.severity IN ("high","critical") by Alerts.src Alerts.user Alerts.id Alerts.vendor sourcetype | `drop_dm_object_name("Alerts")` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | eval risk_score=case(severity="informational", 2, severity="low", 5, severity="medium", 10, severity="high", 50, severity="critical" , 100) | `detect_critical_alerts_from_security_tools_filter`'
 how_to_implement: In order to properly run this search, you to ingest alerts data from other security products such as Crowdstrike, Microsoft Defender, or Carbon Black using appropriate TAs for that technology. Once ingested, the fields should be mapped to the Alerts data model. Make sure to apply transformation on the data if necessary. The risk_score field is used to calculate the risk score for the alerts and the mitre_technique_id field is used to map the alerts to the MITRE ATT&CK framework is dynamically created by the detection when this is triggered. These fields need not be set in the adaptive response actions.
 known_false_positives: False positives may vary by endpoint protection tool; monitor and filter out the alerts that are not relevant to your environment.
@@ -31,7 +31,7 @@ tags:
   asset_type: Endpoint
   atomic_guid: []
   confidence: 50
-  impact: 50
+  impact: 1
   message: $severity$ alert for $user$ from $sourcetype$ - $signature$
   mitre_attack_id: []
   observable:
@@ -60,7 +60,7 @@ tags:
   - Alerts.id
   - Alerts.vendor
   - sourcetype
-  risk_score: 25
+  risk_score: 50
   security_domain: endpoint
 tests:
 - name: True Positive Test

detections/endpoint/windows_ad_dsrm_password_reset.yml

@@ -8,7 +8,7 @@ status: production
 data_source:
 - Windows Event Log Security 4794
 description: The following analytic detects attempts to reset the Directory Services Restore Mode (DSRM) administrator password on a Domain Controller. It leverages event code 4794 from the Windows Security Event Log, specifically looking for events where the DSRM password reset is attempted. This activity is significant because the DSRM account can be used similarly to a local administrator account, providing potential persistence for an attacker. If confirmed malicious, this could allow an attacker to maintain administrative access to the Domain Controller, posing a severe risk to the domain's security.
-search: '| tstats `security_content_summariesonly` min(_time) as _time from datamodel=Change where All_Changes.result_id="4794" AND All_Changes.result="An attempt was made to set the Directory Services Restore Mode administrator password" by All_Changes.action, All_Changes.dest, All_Changes.src, All_Changes.user | `drop_dm_object_name(All_Changes)` | `windows_ad_dsrm_password_reset_filter`'
+search: '| tstats `security_content_summariesonly` min(_time) as _time from datamodel=Change where All_Changes.result_id="4794" AND All_Changes.result="set the Directory Services Restore Mode administrator password" by All_Changes.action, All_Changes.dest, All_Changes.src, All_Changes.user | `drop_dm_object_name(All_Changes)` | `windows_ad_dsrm_password_reset_filter`'
 how_to_implement: To successfully implement this search, you need to be ingesting eventcode `4794` and  have the Advanced Security Audit policy `Audit User Account Management` within `Account Management` enabled.
 known_false_positives: Resetting the DSRM password for legitamate reasons, i.e. forgot the password. Disaster recovery. Deploying AD backdoor deliberately.
 references: