Updating Terminology for ES8+ (#3875)

patel-bhavin · nasbench · web-flow · commit d080ba9f06a6 · 2026-01-22T22:59:29.000+01:00
---------

Co-authored-by: Nasreddine Bencherchali &lt;nasreddineb@splunk.com&gt;
diff --git a/detections/cloud/risk_rule_for_dev_sec_ops_by_repository.yml b/detections/cloud/risk_rule_for_dev_sec_ops_by_repository.yml
@@ -1,12 +1,12 @@
 name: Risk Rule for Dev Sec Ops by Repository
 id: 161bc0ca-4651-4c13-9c27-27770660cf67
-version: 8
-date: '2025-05-02'
+version: 9
+date: '2026-01-22'
 author: Bhavin Patel
 status: production
 type: Correlation
 description: The following analytic identifies high-risk activities within repositories
-  by correlating repository data with risk scores. It leverages risk events from the
+  by correlating repository data with risk scores. It leverages findings and intermediate findings created by detections from the
   Dev Sec Ops analytic stories, summing risk scores and capturing source and user
   information. The detection focuses on high-risk scores above 100 and sources with
   more than three occurrences. This activity is significant as it highlights repositories
@@ -24,7 +24,7 @@ search: '| tstats `security_content_summariesonly` min(_time) as firstTime max(_
   | `drop_dm_object_name(All_Risk)` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`
   | where source_count > 3 and sum_risk_score > 100 | `risk_rule_for_dev_sec_ops_by_repository_filter`'
 how_to_implement: Ensure that all relevant detections in the Dev Sec Ops analytic
-  stories are enabled and are configured to create risk events in Enterprise Security.
+  stories are enabled and are configured to create findings or intermediate findings in Enterprise Security.
 known_false_positives: Unknown
 references: []
 drilldown_searches:
diff --git a/detections/endpoint/common_ransomware_extensions.yml b/detections/endpoint/common_ransomware_extensions.yml
@@ -87,7 +87,7 @@ search: |
 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
+  the detailed documentation on how to create a new field within Mission Control Queue
 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/windows_event_triggered_image_file_execution_options_injection.yml b/detections/endpoint/windows_event_triggered_image_file_execution_options_injection.yml
@@ -1,7 +1,7 @@
 name: Windows Event Triggered Image File Execution Options Injection
 id: f7abfab9-12ea-44e8-8745-475f9ca6e0a4
-version: 5
-date: '2025-05-02'
+version: 6
+date: '2026-01-22'
 author: Michael Haag, Splunk
 status: production
 type: Hunting
@@ -22,7 +22,7 @@ search: '`wineventlog_application` EventCode=3000 | rename param1 AS "Process" p
 how_to_implement: This analytic requires capturing the Windows Event Log Application
   channel in XML.
 known_false_positives: False positives may be present and tuning will be required
-  before turning into a TTP or notable.
+  before turning into a finding or intermediate finding.
 references:
 - https://blog.thinkst.com/2022/09/sensitive-command-token-so-much-offense.html
 - https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/registry-entries-for-silent-process-exit
diff --git a/detections/network/cisco_privileged_account_creation_with_http_command_execution.yml b/detections/network/cisco_privileged_account_creation_with_http_command_execution.yml
@@ -1,7 +1,7 @@
 name: Cisco Privileged Account Creation with HTTP Command Execution
 id: 2c9d4f5a-8b6e-4c7f-9d8e-1a2b3c4d5e6f
-version: 1
-date: '2026-01-06'
+version: 2
+date: '2026-01-22'
 author: Nasreddine Bencherchali, Splunk
 status: production
 type: Correlation
@@ -46,7 +46,7 @@ search: |
   | where source_count >= 2
   | `cisco_privileged_account_creation_with_http_command_execution_filter`
 how_to_implement: |
-  This correlation search requires that the following detections are enabled and generating risk events - "Cisco IOS Suspicious Privileged Account Creation" and "Cisco Secure Firewall - Privileged Command Execution via HTTP". These detections must be configured to generate risk on the same risk object field (the network device IP). The search correlates risk events within a 24-hour time window. Ensure that both Cisco IOS logs (sourcetype "cisco:ios") and Cisco Secure Firewall Threat Defense Intrusion Event logs are being ingested and that the underlying detections are properly configured.
+  This correlation search requires that the following detections are enabled and generating risk events - "Cisco IOS Suspicious Privileged Account Creation" and "Cisco Secure Firewall - Privileged Command Execution via HTTP". These detections must be configured to generate risk on the same entity field (the network device IP). The search correlates risk events within a 24-hour time window. Ensure that both Cisco IOS logs (sourcetype "cisco:ios") and Cisco Secure Firewall Threat Defense Intrusion Event logs are being ingested and that the underlying detections are properly configured.
 known_false_positives: |
   No false positives have been identified yet.
 references:
diff --git a/detections/network/cisco_privileged_account_creation_with_suspicious_ssh_activity.yml b/detections/network/cisco_privileged_account_creation_with_suspicious_ssh_activity.yml
@@ -1,7 +1,7 @@
 name: Cisco Privileged Account Creation with Suspicious SSH Activity
 id: 7f8e2b4c-9a3d-4e1f-8c5b-6d7e8f9a0b1c
-version: 1
-date: '2026-01-06'
+version: 2
+date: '2026-01-22'
 author: Nasreddine Bencherchali, Splunk
 status: production
 type: Correlation
@@ -58,7 +58,7 @@ search: |
   | `security_content_ctime(lastTime)`
   | `cisco_privileged_account_creation_with_suspicious_ssh_activity_filter`
 how_to_implement: |
-  This correlation search requires that the following detections are enabled and generating risk events - "Cisco IOS Suspicious Privileged Account Creation", "Cisco Secure Firewall - SSH Connection to sshd_operns", and "Cisco Secure Firewall - SSH Connection to Non-Standard Port". These detections must be configured to generate risk on the same risk object field (the network device IP). The search correlates risk events within a 24-hour time window. Ensure that both Cisco IOS logs (sourcetype "cisco:ios") and Cisco Secure Firewall Threat Defense Intrusion Event logs are being ingested and that the underlying detections are properly configured.
+  This correlation search requires that the following detections are enabled and generating risk events - "Cisco IOS Suspicious Privileged Account Creation", "Cisco Secure Firewall - SSH Connection to sshd_operns", and "Cisco Secure Firewall - SSH Connection to Non-Standard Port". These detections must be configured to generate risk on the same entity field (the network device IP). The search correlates risk events within a 24-hour time window. Ensure that both Cisco IOS logs (sourcetype "cisco:ios") and Cisco Secure Firewall Threat Defense Intrusion Event logs are being ingested and that the underlying detections are properly configured.
 known_false_positives: |
   No false positives have been identified yet.
 references:
diff --git a/detections/network/detect_hosts_connecting_to_dynamic_domain_providers.yml b/detections/network/detect_hosts_connecting_to_dynamic_domain_providers.yml
@@ -1,7 +1,7 @@
 name: Detect hosts connecting to dynamic domain providers
 id: a1e761ac-1344-4dbd-88b2-3f34c912d359
 version: 10
-date: '2026-01-19'
+date: '2026-01-22'
 author: Bhavin Patel, Splunk
 status: production
 type: TTP
@@ -37,11 +37,11 @@ how_to_implement: "First, you'll need to ingest data from your DNS operations. T
   \ `dynamic_dns_providers_default.csv`, 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\
+  \ fields (query, answer, isDynDNS) that are not yet supported by Mission Control Queue\
   \ 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:**\
+  \ fields, if not already present, to Mission Control Queue. Event Attributes (Configure\
+  \ > Findings and Investigations > Add New field):\n* **Label:**\
   \ DNS Query, **Field:** query\n* **Label:** DNS Answer, **Field:** answer\n* **Label:**\
   \ IsDynamicDNS, **Field:** isDynDNS\n"
 known_false_positives: Some users and applications may leverage Dynamic DNS to reach
diff --git a/detections/network/dns_query_length_outliers___mltk.yml b/detections/network/dns_query_length_outliers___mltk.yml
@@ -1,7 +1,7 @@
 name: DNS Query Length Outliers - MLTK
 id: 85fbcfe8-9718-4911-adf6-7000d077a3a9
-version: 7
-date: '2025-05-02'
+version: 8
+date: '2026-01-22'
 author: Rico Valdez, Splunk
 status: experimental
 type: Anomaly
@@ -30,11 +30,10 @@ how_to_implement: "To successfully implement this search, you will need to ensur
   the associated support search, so that the model created by the support search is
   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 finding event is raised. These fields
+  fields (`query`,`query_length`,`count`) that are not yet supported by Mission Control Queue 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
+  the following fields, if not already present, to Mission Control Queue
+  (Configure > Findings and Investigations > Add New Entry):\n
   * **Label:** DNS Query, **Field:** query\n* **Label:** DNS Query Length, **Field:**
   query_length\n* **Label:** Number of events, **Field:** count\n"
 known_false_positives: If you are seeing more results than desired, you may consider
diff --git a/detections/network/smb_traffic_spike___mltk.yml b/detections/network/smb_traffic_spike___mltk.yml
@@ -1,7 +1,7 @@
 name: SMB Traffic Spike - MLTK
 id: d25773ba-9ad8-48d1-858e-07ad0bbeb828
-version: 8
-date: '2025-05-02'
+version: 9
+date: '2026-01-22'
 author: Rico Valdez, Splunk
 status: experimental
 type: Anomaly
@@ -30,11 +30,10 @@ how_to_implement: "To successfully implement this search, you will need to ensur
   search, so that the model created by the support search is 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 a field (Number of events,count)
-  that are not yet supported by ES Incident Review and therefore cannot be viewed
+  that are not yet supported by Mission Control Analyst Queue and therefore cannot be viewed
   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"
+  to Mission Control Analyst Queue (Configure > Findings and Investigations > Add New Entry):\n* **Label:** Number of events, **Field:** 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/stories/apache_struts_vulnerability.yml b/stories/apache_struts_vulnerability.yml
@@ -1,7 +1,7 @@
 name: Apache Struts Vulnerability
 id: 2dcfd6a2-e7d2-4873-b6ba-adaf819d2a1e
-version: 1
-date: '2018-12-06'
+version: 2
+date: '2026-01-22'
 author: Rico Valdez, Splunk
 status: production
 description: Detect and investigate activities--such as unusually long `Content-Type`
@@ -29,7 +29,7 @@ narrative: 'In March of 2017, a remote code-execution vulnerability in the Jakar
   not generally executed on web servers during the course of day-to-day operation,
   but they may be used when the system is undergoing maintenance or troubleshooting.
 
-  First, it is helpful is to understand how often the notable event is generated,
+  First, it is helpful is to understand how often the finding or intermediate finding is generated,
   as well as the commonalities in some of these events. This may help determine whether
   this is a common occurrence that is of a lesser concern or a rare event that may
   require more extensive investigation. It can also help to understand whether the
diff --git a/stories/brand_monitoring.yml b/stories/brand_monitoring.yml
@@ -1,7 +1,7 @@
 name: Brand Monitoring
 id: 91c676cf-0b23-438d-abee-f6335e1fce78
-version: 1
-date: '2017-12-19'
+version: 2
+date: '2026-01-22'
 author: David Dorsey, Splunk
 status: production
 description: Detect and investigate activity that may indicate that an adversary is
@@ -21,7 +21,7 @@ narrative: 'While you can educate your users and customers about the risks and t
   provide you with early warnings and situational awareness--powerful elements of
   an effective defense.
 
-  Notable events will include IP addresses, URLs, and user data. Drilling down can
+  Findings and intermediate findings will include IP addresses, URLs, and user data. Drilling down can
   provide you with even more actionable intelligence, including likely geographic
   information, contextual searches to help you scope the problem, and investigative
   searches.'
diff --git a/stories/critical_alerts.yml b/stories/critical_alerts.yml
@@ -1,10 +1,10 @@
 name: Critical Alerts
 id: bc7056a5-c2b0-4b83-93ce-5f31739305c8
-version: 1
-date: '2024-06-21'
+version: 2
+date: '2026-01-22'
 author: Gowthamaraj Rajendran, Patrick Bareiss, Splunk
 status: production
-description: This analytic story contains detections that monitor critical alerts data from security tools ingested into Splunk. By correlating these alerts and enriching them with MITRE ATT&CK annotations and other risk events, it offers a nuanced perspective on potential threats and security posture of your organization.
+description: This analytic story contains detections that monitor critical alerts data from security tools ingested into Splunk. By correlating these alerts and enriching them with MITRE ATT&CK annotations and other findings and intermediate findings, it offers a nuanced perspective on potential threats and security posture of your organization.
 narrative: Monitoring alerts from security tools is crucial because they act as an early warning system for potential threats. High and critical alerts signal serious issues that could compromise your systems if not addressed promptly. By keeping an eye on these alerts, you can quickly identify and respond to threats, minimizing damage and protecting sensitive data. This proactive approach not only strengthens your security posture but also ensures you're ready to tackle any compliance requirements by maintaining a detailed record of significant security events. This story has rules that integrates and assesses critical alerts from Endpoint, DLP, and firewall sources in Splunk. By correlating alerts and adding MITRE annotations, it provides a comprehensive view of customer risk. It triggers an alert when critical alerts are detected, preserving the source and assigning risk scores. This helps security analysts understand threats and respond effectively.
 references:
   - https://help.splunk.com/en/splunk-cloud-platform/common-information-model/6.0/data-models/alerts
diff --git a/stories/jboss_vulnerability.yml b/stories/jboss_vulnerability.yml
@@ -1,7 +1,7 @@
 name: JBoss Vulnerability
 id: 1f5294cb-b85f-4c2d-9c58-ffcf248f52bd
-version: 1
-date: '2017-09-14'
+version: 2
+date: '2026-01-22'
 author: Bhavin Patel, Splunk
 status: production
 description: In March of 2016, adversaries were seen using JexBoss--an open-source
@@ -16,7 +16,7 @@ narrative: 'This Analytic Story looks for probing and exploitation attempts targ
   or drive-by attacks more common with ransomware. In this case, vulnerable JBoss
   applications appear to be the target of choice.
 
-  It is helpful to understand how often a notable event generated by this story occurs,
+  It is helpful to understand how often a finding or intermediate finding generated by this story occurs,
   as well as the commonalities between some of these events, both of which may provide
   clues about whether this is a common occurrence of minimal concern or a rare event
   that may require more extensive investigation. It may also help to understand whether
diff --git a/stories/malicious_powershell.yml b/stories/malicious_powershell.yml
@@ -1,15 +1,15 @@
 name: Malicious PowerShell
 id: 2c8ff66e-0b57-42af-8ad7-912438a403fc
-version: 5
-date: '2017-08-23'
+version: 6
+date: '2026-01-22'
 author: David Dorsey, Splunk
 status: production
 description: Attackers are finding stealthy ways "live off the land," leveraging utilities
   and tools that come standard on the endpoint--such as PowerShell--to achieve their
   goals without downloading binary files. These searches can help you detect and investigate
   PowerShell command-line options that may be indicative of malicious intent.
 narrative: 'The searches in this Analytic Story monitor for parameters often used
-  for malicious purposes. It is helpful to understand how often the notable events
+  for malicious purposes. It is helpful to understand how often the findings and intermediate findings
   generated by this story occur, as well as the commonalities between some of these
   events. These factors may provide clues about whether this is a common occurrence
   of minimal concern or a rare event that may require more extensive investigation.
diff --git a/stories/scattered_spider.yml b/stories/scattered_spider.yml
@@ -1,8 +1,8 @@
 name: Scattered Spider
 id: 3df97513-d898-4168-927a-ed3595d6ea41
-version: 1
+version: 2
 status: production
-date: '2025-07-29'
+date: '2026-01-22'
 author: Michael Haag, Splunk
 description: >
   Detects tactics, techniques, and procedures (TTPs) associated with Scattered Spider (UNC3944, Octo Tempest, Storm-0875), 
@@ -18,7 +18,7 @@ description: >
   exploitation. The analytics in this story detect their signature behaviors including MFA bombing attacks, unauthorized remote 
   access tool deployment, cloud API abuse, credential harvesting with tools like Mimikatz, and their unique operational security 
   practices of monitoring victim communications to evade detection. Coverage includes process monitoring, network analytics, 
-  cloud API detection, and behavioral correlation rules designed to identify the subtle indicators that traditional signature-based 
+  cloud API detection, and behavioral detections designed to identify the subtle indicators that traditional signature-based 
   tools miss while providing actionable intelligence for incident response teams.
 
 narrative: >
