notable to finding 2

patel-bhavin · patel-bhavin · commit 6c3e7df1ad79 · 2025-01-24T17:03:47.000-08:00
diff --git a/detections/application/email_attachments_with_lots_of_spaces.yml b/detections/application/email_attachments_with_lots_of_spaces.yml
@@ -29,7 +29,7 @@ how_to_implement: "You need to ingest data from emails. Specifically, the sender
   this detection search. To use this integration, install the Phantom App for Splunk
   `https://splunkbase.splunk.com/app/3411/` and add the correct hostname to the \"\
   Phantom Instance\" field in the Adaptive Response Actions when configuring this
-  detection search. The notable event will be sent to Phantom and the playbook will
+  detection search. The finding based event will be sent to Phantom and the playbook will
   gather further information about the file attachment and its network behaviors.
   If Phantom finds malicious behavior and an analyst approves of the results, the
   email will be deleted from the user's inbox."
diff --git a/detections/application/okta_risk_threshold_exceeded.yml b/detections/application/okta_risk_threshold_exceeded.yml
@@ -28,9 +28,9 @@ search: '| tstats `security_content_summariesonly` values(All_Risk.analyticstori
   |  search mitre_technique_id_count > 5 | `okta_risk_threshold_exceeded_filter`'
 how_to_implement: This search leverages the Risk Framework from Enterprise Security.
   Ensure that "Suspicious Okta Activity", "Okta Account Takeover", and "Okta MFA Exhaustion"
-  analytic stories are enabled. TTPs may be set to Notables for point detections;
-  anomalies should not be notables but rather risk generators. The correlation relies
-  on risk before generating a notable. Modify the value as needed.
+  analytic stories are enabled. TTPs may be set to finding for point detections;
+  anomalies should not be findings but rather intermediate findings. The correlation relies
+  on intermediate findings before generating a findings. Modify the value as needed.
 known_false_positives: False positives will be limited to the number of events generated
   by the analytics tied to the stories. Analytics will need to be tested and tuned,
   and the risk score reduced as needed based on the organization.
diff --git a/detections/application/suspicious_email_attachment_extensions.yml b/detections/application/suspicious_email_attachment_extensions.yml
@@ -26,7 +26,7 @@ how_to_implement: "You need to ingest data from emails. Specifically, the sender
   Delete\" can be configured to run when any results are found by this detection search.
   To use this integration, install the Phantom App for Splunk `https://splunkbase.splunk.com/app/3411/`,
   and add the correct hostname to the \"Phantom Instance\" field in the Adaptive Response
-  Actions when configuring this detection search. The notable event will be sent to
+  Actions when configuring this detection search. The finding event will be sent to
   Phantom and the playbook will gather further information about the file attachment
   and its network behaviors. If Phantom finds malicious behavior and an analyst approves
   of the results, the email will be deleted from the user's inbox.'"
diff --git a/detections/cloud/azure_ad_authentication_failed_during_mfa_challenge.yml b/detections/cloud/azure_ad_authentication_failed_during_mfa_challenge.yml
@@ -34,7 +34,7 @@ how_to_implement: You must install the latest version of Splunk Add-on for Micro
 known_false_positives: "False positives have been minimized by removing attempts that
   result in 'MFA successfully completed messages', which were found to be generated
   when a user opts to use a different MFA method than the default.\nFurther reductions
-  in notable events can be achieved through filtering 'MFA denied; duplicate authentication
+  in finding events can be achieved through filtering 'MFA denied; duplicate authentication
   attempt' messages within the auth_msg field, as they could arguably be considered
   as false positives."
 references:
diff --git a/detections/deprecated/detect_web_traffic_to_dynamic_domain_providers.yml b/detections/deprecated/detect_web_traffic_to_dynamic_domain_providers.yml
@@ -19,13 +19,11 @@ how_to_implement: "This search requires you to be ingesting web-traffic logs. Yo
   which contains a non-exhaustive list of dynamic DNS providers. Consider periodically
   updating this local lookup file with new domains.\nThis search produces fields (`isDynDNS`)
   that are not yet supported by ES Incident Review and therefore cannot be viewed
-  when a notable event is raised. These fields contribute additional context to the
-  notable. To see the additional metadata, add the following fields, if not already
+  when a finding event is raised. These fields contribute additional context to the
+  finding. To see the additional metadata, add the following fields, if not already
   present, to Incident Review - Event Attributes (Configure > Incident Management
   > Incident Review Settings > Add New Entry):\n* **Label:** IsDynamicDNS, **Field:**
-  isDynDNS\nDetailed documentation on how to create a new field within Incident Review
-  may be found here: `https://docs.splunk.com/Documentation/ES/5.3.0/Admin/Customizenotables#Add_a_field_to_the_notable_event_details`
-  Deprecated because duplicate."
+  isDynDNS\n Deprecated because duplicate."
 known_false_positives: It is possible that list of dynamic DNS providers is outdated
   and/or that the URL being requested is legitimate.
 references: []
diff --git a/detections/endpoint/batch_file_write_to_system32.yml b/detections/endpoint/batch_file_write_to_system32.yml
@@ -30,7 +30,7 @@ how_to_implement: To successfully implement this search you need to be ingesting
   your endpoints into the `Endpoint` datamodel in the `Processes` node. In addition,
   confirm the latest CIM App 4.20 or higher is installed and the latest TA for the
   endpoint product.
-known_false_positives: It is possible for this search to generate a notable event
+known_false_positives: It is possible for this search to generate a finding event
   for a batch file write to a path that includes the string "system32", but is not
   the actual Windows system directory. As such, you should confirm the path of the
   batch file identified by the search. In addition, a false positive may be generated
diff --git a/detections/endpoint/common_ransomware_extensions.yml b/detections/endpoint/common_ransomware_extensions.yml
@@ -27,8 +27,7 @@ search: '| tstats `security_content_summariesonly` min(_time) as firstTime max(_
 how_to_implement: 'You must be ingesting data that records the filesystem activity
   from your hosts to populate the Endpoint Filesystem data model node. To see the
   additional metadata, add the following fields, if not already present, please review
-  the detailed documentation on how to create a new field within Incident Review may
-  be found here: `https://docs.splunk.com/Documentation/ES/5.3.0/Admin/Customizenotables#Add_a_field_to_the_notable_event_details`'
+  the detailed documentation on how to create a new field within Incident Review'
 known_false_positives: It is possible for a legitimate file with these extensions
   to be created. If this is a true ransomware attack, there will be a large number
   of files created with these extensions.
diff --git a/detections/endpoint/linux_persistence_and_privilege_escalation_risk_behavior.yml b/detections/endpoint/linux_persistence_and_privilege_escalation_risk_behavior.yml
@@ -29,9 +29,9 @@ search: '| tstats `security_content_summariesonly` min(_time) as firstTime max(_
   | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | where
   source_count >= 4 | `linux_persistence_and_privilege_escalation_risk_behavior_filter`'
 how_to_implement: Ensure Linux anomaly and TTP analytics are enabled. TTP may be set
-  to Notables for point detections, anomaly should not be notables but risk generators.
+  to finding  for point detections, anomaly should not be findings but risk generators.
   The correlation relies on more than x amount of distict detection names generated
-  before generating a notable. Modify the value as needed. Default value is set to
+  before generating a finding. Modify the value as needed. Default value is set to
   4. This value may need to be increased based on activity in your environment.
 known_false_positives: False positives will be present based on many factors. Tune
   the correlation as needed to reduce too many triggers.
diff --git a/detections/endpoint/powershell_start_or_stop_service.yml b/detections/endpoint/powershell_start_or_stop_service.yml
@@ -23,7 +23,7 @@ how_to_implement: To successfully implement this analytic, you will need to enab
   https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell.
 known_false_positives: This behavior may be noisy, as these cmdlets are commonly used
   by system administrators or other legitimate users to manage services. Therefore,
-  it is recommended not to enable this analytic as a direct notable or TTP. Instead,
+  it is recommended not to enable this analytic as a direct finding Instead,
   it should be used as part of a broader set of security controls to detect and investigate
   potential threats.
 references:
diff --git a/detections/endpoint/windows_drivers_loaded_by_signature.yml b/detections/endpoint/windows_drivers_loaded_by_signature.yml
@@ -23,8 +23,8 @@ how_to_implement: To successfully implement this search, you need to be ingestin
   endpoints. If you are using Sysmon, you must have the latest version of the Sysmon
   TA. Most EDR products provide the ability to review driver loads, or module loads,
   and using a query as such help with hunting for malicious drivers.
-known_false_positives: This analytic is meant to assist with identifying drivers loaded
-  in the environment and not to be setup for notables off the bat.
+known_false_positives: This analytic is meant to assist with identifying and hunting drivers loaded
+  in the environment. 
 references:
 - https://redcanary.com/blog/tracking-driver-inventory-to-expose-rootkits/
 - https://attack.mitre.org/techniques/T1014/
diff --git a/detections/endpoint/windows_process_injection_with_public_source_path.yml b/detections/endpoint/windows_process_injection_with_public_source_path.yml
@@ -25,7 +25,7 @@ how_to_implement: To successfully implement this search, you must be ingesting d
   in the processes node. If you are using Sysmon, you must have at least version 6.0.4
   of the Sysmon TA.
 known_false_positives: Some security products or third party applications may utilize
-  CreateRemoteThread, filter as needed before enabling as a notable.
+  CreateRemoteThread, filter as needed.
 references:
 - https://unit42.paloaltonetworks.com/brute-ratel-c4-tool/
 tags:
diff --git a/detections/endpoint/windows_raw_access_to_disk_volume_partition.yml b/detections/endpoint/windows_raw_access_to_disk_volume_partition.yml
@@ -23,8 +23,7 @@ how_to_implement: To successfully implement this search, you need to be ingestin
   logs with the raw access read event (like sysmon eventcode 9), process name and
   process guid from your endpoints. If you are using Sysmon, you must have at least
   version 6.0.4 of the Sysmon TA.
-known_false_positives: This event is really notable but we found minimal number of
-  normal application from system32 folder like svchost.exe accessing it too. In this
+known_false_positives: There are som minimal number of normal applications from system32 folder like svchost.exe accessing the MBR. In this
   case we used 'system32' and 'syswow64' path as a filter for this detection.
 references:
 - https://blog.talosintelligence.com/2022/02/threat-advisory-hermeticwiper.html
diff --git a/detections/endpoint/windows_raw_access_to_master_boot_record_drive.yml b/detections/endpoint/windows_raw_access_to_master_boot_record_drive.yml
@@ -23,8 +23,7 @@ how_to_implement: To successfully implement this search, you need to be ingestin
   logs with the raw access read event (like sysmon eventcode 9), process name and
   process guid from your endpoints. If you are using Sysmon, you must have at least
   version 6.0.4 of the Sysmon TA.
-known_false_positives: This event is really notable but we found minimal number of
-  normal application from system32 folder like svchost.exe accessing it too. In this
+known_false_positives: There are som minimal number of normal applications from system32 folder like svchost.exe accessing the MBR. In this
   case we used 'system32' and 'syswow64' path as a filter for this detection.
 references:
 - https://www.splunk.com/en_us/blog/security/threat-advisory-strt-ta02-destructive-software.html
diff --git a/detections/endpoint/windows_runmru_command_execution.yml b/detections/endpoint/windows_runmru_command_execution.yml
@@ -35,7 +35,7 @@ known_false_positives: This detection may generate a few false positives, such a
   legitimate software updates or legitimate system maintenance activities that modify
   the RunMRU key. However, the exclusion of MRUList value changes helps reduce the
   number of false positives by focusing only on actual command entries. Add any specific
-  false positives to the built in filter to reduce notables as needed.
+  false positives to the built in filter to reduce findings as needed.
 references:
 - https://medium.com/@ahmed.moh.farou2/fake-captcha-campaign-on-arabic-pirated-movie-sites-delivers-lumma-stealer-4f203f7adabf
 - https://medium.com/@shaherzakaria8/downloading-trojan-lumma-infostealer-through-capatcha-1f25255a0e71
diff --git a/detections/endpoint/windows_system_file_on_disk.yml b/detections/endpoint/windows_system_file_on_disk.yml
@@ -24,7 +24,7 @@ how_to_implement: To successfully implement this search you need to be ingesting
   In addition, confirm the latest CIM App 4.20 or higher is installed and the latest
   TA for the endpoint product. In addition, filtering may occur by adding NOT (Filesystem.file_path
   IN ("*\\Windows\\*", "*\\Program File*", "*\\systemroot\\*","%SystemRoot%*", "system32\*")).
-  This will level out the noise generated to potentally lead to generating notables.
+  This will level out the noise generated to potentally lead to generating findings.
 known_false_positives: False positives will be present. Filter as needed.
 references:
 - https://redcanary.com/blog/tracking-driver-inventory-to-expose-rootkits/
diff --git a/detections/network/detect_hosts_connecting_to_dynamic_domain_providers.yml b/detections/network/detect_hosts_connecting_to_dynamic_domain_providers.yml
@@ -26,13 +26,12 @@ how_to_implement: "First, you'll need to ingest data from your DNS operations. T
   which contains a non-exhaustive list of Dynamic DNS providers. Please consider updating
   the local lookup periodically by adding new domains to the list of `dynamic_dns_providers_local.csv`.\n
   This search produces fields (query, answer, isDynDNS) that are not yet supported
-  by ES Incident Review and therefore cannot be viewed when a notable event is raised.
-  These fields contribute additional context to the notable event. To see the additional
+  by ES Incident Review and therefore cannot be viewed when a finding is raised.
+  These fields contribute additional context to the finding. To see the additional
   metadata, add the following fields, if not already present, to Incident Review.
   Event Attributes (Configure > Incident Management > Incident Review Settings > Add
   New Entry):\n* **Label:** DNS Query, **Field:** query\n* **Label:** DNS Answer,
-  **Field:** answer\n* **Label:** IsDynamicDNS, **Field:** isDynDNS\nDetailed documentation
-  on how to create a new field within Incident Review may be found here: `https://docs.splunk.com/Documentation/ES/5.3.0/Admin/Customizenotables#Add_a_field_to_the_notable_event_details`"
+  **Field:** answer\n* **Label:** IsDynamicDNS, **Field:** isDynDNS\n"
 known_false_positives: Some users and applications may leverage Dynamic DNS to reach
   out to some domains on the Internet since dynamic DNS by itself is not malicious,
   however this activity must be verified.
diff --git a/detections/network/detect_outbound_smb_traffic.yml b/detections/network/detect_outbound_smb_traffic.yml
@@ -30,7 +30,7 @@ how_to_implement: This search also requires you to be ingesting your network tra
 known_false_positives: It is likely that the outbound Server Message Block (SMB) traffic
   is legitimate, if the company's internal networks are not well-defined in the Assets
   and Identity Framework. Categorize the internal CIDR blocks as `internal` in the
-  lookup file to avoid creating notable events for traffic destined to those CIDR
+  lookup file to avoid creating findings for traffic destined to those CIDR
   blocks. Any other network connection that is going out to the Internet should be
   investigated and blocked. Best practices suggest preventing external communications
   of all SMB versions and related protocols at the network boundary.
diff --git a/detections/network/dns_query_length_outliers___mltk.yml b/detections/network/dns_query_length_outliers___mltk.yml
@@ -31,13 +31,12 @@ how_to_implement: "To successfully implement this search, you will need to ensur
   available for use. You should periodically re-run the support search to rebuild
   the model with the latest data available in your environment.\nThis search produces
   fields (`query`,`query_length`,`count`) that are not yet supported by ES Incident
-  Review and therefore cannot be viewed when a notable event is raised. These fields
-  contribute additional context to the notable. To see the additional metadata, add
+  Review and therefore cannot be viewed when a finding event is raised. These fields
+  contribute additional context to the finding. To see the additional metadata, add
   the following fields, if not already present, to Incident Review - Event Attributes
   (Configure > Incident Management > Incident Review Settings > Add New Entry):\n
   * **Label:** DNS Query, **Field:** query\n* **Label:** DNS Query Length, **Field:**
-  query_length\n* **Label:** Number of events, **Field:** count\nDetailed documentation
-  on how to create a new field within Incident Review may be found here: `https://docs.splunk.com/Documentation/ES/5.3.0/Admin/Customizenotables#Add_a_field_to_the_notable_event_details`"
+  query_length\n* **Label:** Number of events, **Field:** count\n"
 known_false_positives: If you are seeing more results than desired, you may consider
   reducing the value for threshold in the search. You should also periodically re-run
   the support search to re-build the ML model on the latest data.
diff --git a/detections/network/smb_traffic_spike___mltk.yml b/detections/network/smb_traffic_spike___mltk.yml
@@ -31,12 +31,11 @@ how_to_implement: "To successfully implement this search, you will need to ensur
   should periodically re-run the support search to rebuild the model with the latest
   data available in your environment.\nThis search produces a field (Number of events,count)
   that are not yet supported by ES Incident Review and therefore cannot be viewed
-  when a notable event is raised. This field contributes additional context to the
-  notable. To see the additional metadata, add the following field, if not already
+  when a finding is raised. This field contributes additional context to the
+  finding. To see the additional metadata, add the following field, if not already
   present, to Incident Review - Event Attributes (Configure > Incident Management
   > Incident Review Settings > Add New Entry):\n* **Label:** Number of events, **Field:**
-  count\nDetailed documentation on how to create a new field within Incident Review
-  is found here: `https://docs.splunk.com/Documentation/ES/5.3.0/Admin/Customizenotables#Add_a_field_to_the_notable_event_details`"
+  count"
 known_false_positives: If you are seeing more results than desired, you may consider
   reducing the value of the threshold in the search. You should also periodically
   re-run the support search to re-build the ML model on the latest data. Please update
diff --git a/detections/web/exploit_public_facing_application_via_apache_commons_text.yml b/detections/web/exploit_public_facing_application_via_apache_commons_text.yml
@@ -33,7 +33,7 @@ how_to_implement: To implement, one must be collecting network traffic that is n
   and tie to a specific network source type to hunt in. Tune as needed, or remove
   the other_lookups statement.
 known_false_positives: False positives are present when the values are set to 1 for
-  utf and lookup. It's possible to raise this to TTP (direct notable) if removal of
+  utf and lookup. It's possible to raise this to TTP (direct finding) if removal of
   other_lookups occur and Score is raised to 2 (down from 4).
 references:
 - https://sysdig.com/blog/cve-2022-42889-text4shell/
