Workflow updates in Splunk Enterprise Security 8.4 Essentials

Simplified ad-hoc investigation and finding creation

In ES 8.4 Essentials, analysts can create an investigation without first having to select a finding. To create an ad-hoc investigation, click the + button in the top right corner of the analyst queue and select Create new investigation. Creating an investigation only requires you to enter a title and investigation type, then other information can be added as the investigation proceeds.

ES still has the option to create a new finding under the + button, but a new Start an investigation with this finding checkbox has been added to the Create new finding modal. In ES 8.4, the number of required fields for creating a finding has been reduced to entering a title and security domain. This helps reduce the number of required steps to open a case immediately and lets you populate details as they become known.

For more information, see Create a simple finding or investigation.

Team-based work queues

The analyst queue can now be separated into team-based queues to organize findings and investigations into "mini-queues" that reflect each SOC team's focus and responsibilities. Filters can be configured for each queue. The main analyst queue is still visible to all users and contains findings not filtered into a team-based queue.

Administrators can configure team-based queues under Configure > Findings and investigations > Team queues. Configuration includes a name and description of the queue and the roles of the users that are members of the queue. Administrators create roles in the Splunk platform and assign users to those roles, then assign the roles to the queue. After the team-based queue is created and roles assigned, administrators create the conditions for specific fields and values that control which findings are filtered into the queue. It is important to note that access to individual findings and investigations is not restricted, so anyone in your organization with a link to the queue can view all the items it contains.

In the queue configuration, there is a checkbox labeled Allow users to move items to other queues. By default, analysts cannot move findings or investigations between queues. However, when this option is configured, analysts can move a finding or investigation to another queue using the Move to new queue button at the top of the queue.

A new Queues menu displays on the left side of the analyst queue. It displays the queues that a user is a member of, along with the main queue. Users can create custom views per queue (including the main queue). Default views like Owned by me, Unassigned, and Risk score are available in each queue.

For more information, see Analyst and team-based queues.

Adding events to an investigation

Analysts can add raw events from the Splunk platform to an investigation using the Event Actions menu and selecting Copy event to investigation. This action replaces the add_events macro. Events added are available under the Events tab in the investigation.

To add multiple events to an open investigation, analysts can use the copy_events macro with the investigation ID. For example, copy_events <ES-00002>.

For more information, see Add or copy events to an investigation.

Integrated Cisco Talos intelligence (Splunk Cloud Platform-only where available)

As part of the integration of Threat Intelligence Management (TIM) into ES Essentials, Cisco Talos intelligence is now incorporated into the Intelligence tab of investigations in ES Essentials cloud-only deployments where available. This premium threat intelligence enriches findings to accelerate triage and quickly detect indicators of suspicious activity. Cisco Talos provides threat classifications and contextual intelligence for observables such as IP addresses, URLs, and domain names, helping analysts validate threats and make faster, more confident response decisions.

For more information, see Overview of threat intelligence in Splunk Enterprise Security.

Threat Intelligence Management (TIM) UI simplification (cloud-only)

The ES Essentials 8.4 on-premises solution continues to use the traditional ES Threat Intelligence Framework (TIF) and configuration menus. However, the 8.4 cloud-only deployment incorporates Threat Intelligence Management (TIM), which merges TIF and TIM menus into one simple Configure > Threat intelligence menu. The updated Intelligence menu has a single set of data sources, threat lists, safelists, proxy and parser settings, and threat matching details.

For more information, see Configure threat intelligence sources.

Importing and exporting response plans

To ease the use of response plans in ES 8.4, administrators can now export response plans from one ES instance to another. For example, response plans can be created and tested in a dev environment, then copied to a production environment.

Response plans are exported and imported through the Security content > Response plans menu. Each response plan has an Export option under the vertical ellipsis menu, and there is an Import button on the Response plans page. Response plans are downloaded and uploaded as JSON files.

For more information, see Creating and managing response plans.

Detection Studio (AWS cloud-only)

The new Detection Studio is available in ES Essentials 8.4 cloud-only deployments. Detection Studio enables ES administrators to evaluate, tune, and maintain detections, so they perform effectively within their specific data and security environment. By analyzing detection health and coverage, detection engineers can improve search accuracy, reduce unnecessary alert volume, and ensure detections are operating as designed.

Using Detection Studio, you can assess the overall quality and operational status of ES and ESCU detections to identify gaps caused by issues such as misconfigured or incomplete data ingestion. This includes validating that required log sources are properly collecting and indexing data from endpoints, networks, and cloud services, and that detections have the data they need to run reliably.

Detection Studio also helps confirm that detection logic is functioning correctly. You can identify detections that generate excessive false positives or uncover silent false negatives.

In addition, Detection Studio provides visibility into detection coverage across MITRE ATT&CK tactics and techniques, allowing administrators to confirm that deployed detections align with the current threat landscape and organizational risk priorities.

Monitoring detection health and coverage also validates the operational readiness of the environment by highlighting issues related to outdated, missing, or nonfunctional data sources and security tooling.

By using Detection Studio to continuously assess and improve detection health, ES administrators can maintain a resilient detection environment, reduce operational friction, and ensure security teams can confidently detect, investigate, and respond to threats while strengthening overall security posture.

Detection Studio includes these dashboards to assist in maintaining effective and healthy detections:

• Launchpad – shows a high-level overview of detection coverage and health over time.
• Detection library – contains a table with all detections that can be filtered, for example by data model, data set, or author. Selecting a detection displays a preview panel which provides details on the detection and the search logic.
• MITRE ATT&CK matrix – displays the MITRE ATT&CK matrix that can be toggled to show either coverage or gaps in your security posture. Clicking a technique shows how many detections are deployed and how many are available for that technique.

For more information, see Identify optimal detections for your security environment using Detection Studio.

Allow skew for detection scheduling and timing

The new Allow skew configuration improves detection performance and reliability by offsetting a detection's start time based on scheduler load rather than a fixed cron timestamp. This helps distribute search execution more evenly across time and reduces contention on search heads and indexers. Allow skew is available for event-based and finding-based detections.

When many detections are scheduled to run simultaneously, system resources can become constrained, leading to skipped searches, delayed execution, or missed findings. Relying solely on fixed cron schedules increases the risk of performance degradation during peak load periods, especially in environments with a large number of enabled detections.

Using Allow skew enables detection engineers to improve search accuracy, prevent missed detections caused by skipped execution windows, and scale detection coverage while maintaining a stable and performant environment—supporting a stronger overall security posture.

Allow skew can be configured for each detection in the time range section in the detection editor by toggling the Allow skew button or using the Configure > General settings > Allow skew page in ES. The Allow skew page lists the detections that can be changed to "skewable". After allow skew has been enabled, a new version is created for the detection.

For more information, see Skew the scheduled start time to run detections.

Event-based detection editor changes

Editing event-based detections in Splunk Enterprise Security has been significantly improved to give ES administrators greater flexibility and control when defining detection logic and outputs.

The detection editor now allows findings and intermediate findings to be configured in separate, dedicated sections, each with its own required fields. This separation makes it easier to design complex detection workflows while ensuring that each output type is clearly defined and validated.

Common configuration elements—such as threat objects, drill-down searches, drill-down dashboards, and annotations—are now centralized in the analyst queue section of the detection editor. These settings are shared across both findings and intermediate findings and are organized into collapsible panels, improving usability and reducing duplication during detection configuration.

Risk scoring is now more flexible. Risk scores are optional for findings and can be left empty when risk-based alerting is not required. In addition, entities are no longer required for a finding, and risk messages are not required for entities associated with a finding. This enables administrators to create findings that support analyst workflows without forcing unnecessary risk attribution.

When configuring an intermediate finding, at least one entity is required. This ensures that intermediate findings continue to provide meaningful context for downstream detections and correlation logic.

These improvements streamline detection authoring, reduce configuration overhead, and give ES administrators greater precision when designing event-based detections that align with their security operations and risk strategy.

For more information, see Create event-based detections.

Finding-based detection editor changes

As of ES 8.4, Finding-based detections (FBDs) are fully supported and are no longer a beta feature.

Creating finding-based detections has been significantly improved to simplify detection creation and align configuration with risk-based alerting best practices. ES 8.4 provides easy-to-use finding group templates in the Content management list. Finding group templates allow detection engineers to quickly deploy and adapt detections without starting from scratch. Using templates reduces complexity while preserving alignment with proven security use cases. Detection engineers still have the ability to create FBDs using custom searches and fields.

In addition, panels previously used to group findings by entity type have been deprecated, simplifying the editor layout and reducing visual clutter. This change helps administrators focus on detection logic and risk outcomes rather than rigid structural groupings.

These improvements make finding-based detections easier to author, faster to maintain, and better aligned with modern risk-based alerting workflows—helping ES detection engineers scale detection coverage while maintaining consistency and operational efficiency.

For more information, see Create a finding-based detection.