updating detection

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,9 +60,8 @@ tags:
   - Alerts.id
   - Alerts.vendor
   - sourcetype
-  risk_score: 25
+  risk_score: 50
   security_domain: endpoint
-  manual_test: 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. Since integration tests compare these values created in the risk index and the set risk score in the yaml, we are setting this to manual test since it otherwise fails integration test.
 tests:
 - name: True Positive Test
   attack_data: