Create custom dashboards using the AI SOC analyst agent

Use the AI SOC analyst agent to create custom dashboards for triage purposes. You can do this by identifying useful fields and creating starter SPL queries to explore the historical data that is available Splunk Enterprise Security.

Identify data sources in Splunk Enterprise Security

Use the mc_history index to identify data sources that can help to track and monitor events, which occurred over relevant time periods. You can also use the mc_findings_lookup to deconstruct findings and identify the team queue to which it belongs.

Data source Details in the data source How you can use this data
index=mc_history collection=mc_ai_analysis
  • Agent runs
  • Completion status
  • Agent runtime
  • Tools used

  • Findings triaged

  • Turnaround time

  • Tool call reporting
index=mc_history collection=mc_incidents
  • Changes to the agent
  • Suggested disposition
  • Disposition selected by an analyst

  • Agent determination

  • Analyst acceptance

  • Agent versus analyst comparisons
mc_findings_lookup

  • Record of the finding

  • Team queue that includes the finding

  • Status of the finding

  • Urgency of the finding

  • Assignee for the finding

  • Detection that created the finding

  • Disposition of the finding

  • Risk fields from the finding

  • Queue-based access control

  • Filters

  • Drill-downs
Note: The same finding ID appears in each source under a different field name. For example, The finding ID might appear as record.incident_id in AI-analysis history, finding_id or record.notable_id in incident history, and notable_id in the mc_findings_lookup . You can rename or copy that value to a common field such as event_id when combining the sources to create a dashboard for a single, unified view.

Identify the relevant fields from the data sources in Splunk Enterprise Security

Information Field Usage
Finding ID

  • record.incident_id

  • finding_id

  • record.notable_id

 Used to match records for the same finding.
Analysis ID

  • record.id

  • object_id

 Identifies a specific triage run for the agent.
Analysis status

  • change.status

  • record.status

 Indicates status of the analysis such as completed and failed.
Agent runtime

  • change.metadata.agent_time

  • record.metadata.agent_time

 Provides the agent runtime in seconds
Tools used

  • change.tools{}

  • record.tools{}

 Indicates tool usage such as app name, status, retry status, number of retries, and errors.
Agent disposition

  • change.ai_suggested_disposition

  • record.ai_suggested_disposition

 Indicates the disposition suggested for the finding by the agent.
Analyst disposition

  • change.disposition

  • record.disposition

 Indicates the disposition selected for the finding by the analyst.
Queue and finding details

  • queue_id

  • is_investigation

  • name

  • status

  • urgency

  • assignee

  • risk_score

 Provides information on the finding from the mc_findings_lookup.
The following table indicates the disposition values and the labels assigned to them:
Disposition value Label
disposition:1 True positive
disposition:2 Benign positive
disposition:3 or disposition:4 False positive
disposition:6 or an unmapped value Unknown/other

SPL searches to explore data in Splunk Enterprise Security

Following are some sample SPL queries to explore data in Splunk Enterprise Security such as viewing agent runs, viewing changes to the agent and analyst disposition, viewing finding and queue data, add finding details to a history search, and so on.

View agent runs
CODE 
index=mc_history collection="mc_ai_analysis" NOT is_archive_record=true
| eval finding_id=spath(_raw,"record.incident_id"),
analysis_id=coalesce(spath(_raw,"record.id"),object_id),
changed_status=spath(_raw,"change.status"),
current_status=spath(_raw,"record.status"),
agent_time_seconds=coalesce(spath(_raw,"change.metadata.agent_time"),
spath(_raw,"record.metadata.agent_time")),
tools=coalesce(spath(_raw,"change.tools{}"),spath(_raw,"record.tools{}"))
| table _time message finding_id analysis_id changed_status current_status
agent_time_seconds tools
| sort - _time
View changes to the agent and analyst disposition
CODE 
index=mc_history collection="mc_incidents" NOT is_archive_record=true
| eval finding_id=mvindex(coalesce(finding_id,spath(_raw,"record.notable_id")),0),
agent_disposition_change=spath(_raw,"change.ai_suggested_disposition"),
agent_disposition=spath(_raw,"record.ai_suggested_disposition"),
analyst_disposition_change=spath(_raw,"change.disposition"),
analyst_disposition=spath(_raw,"record.disposition")
| where isnotnull(agent_disposition_change) OR isnotnull(analyst_disposition_change)
| table _time finding_id agent_disposition_change agent_disposition
analyst_disposition_change analyst_disposition
| sort - _time
View current finding and queue data
CODE 
| inputlookup mc_findings_lookup
| table notable_id queue_id is_investigation name status urgency assignee
disposition ai_suggested_disposition risk_score
| head 100
Add current finding details to a history search
CODE 
...your mc_history search...
| eval event_id=mvindex(coalesce(spath(_raw,"record.incident_id"),
finding_id,
spath(_raw,"record.notable_id")),0)
| lookup local=true mc_findings_lookup notable_id AS event_id
OUTPUT queue_id is_investigation name status urgency assignee risk_score
Note: The mc_findings_lookup contains the current state of the finding. Use the mc_history index when the dashboard must indicate a change happened or to calculate a metric for a historical time range.

Sample dashboards

Following are some sample dashboard panels that can be created and the metrics that can be used to populate them:
Dashboard Metrics
Findings triaged Tracks the number of distinct findings with completed AI processing.
Agent determination Tracks distinct findings based on the agentʼs suggested disposition.
Analyst applied Tracks distinct findings for which the analyst disposition matches the agent disposition.
Agent versus analyst matrix Groups findings in pairs based on the agent disposition and the analyst disposition.
SOC time returned Calculates the difference between the analyst's baseline and the agent runtime for all accepted findings.
Tool call status Expands the tools array and count tool calls by app_name , status , and retry_status .
Finding breakdowns Groups current findings by queue, urgency, status, assignee, detection name, or risk score using lookups.
Triage lifecycle Tracks the following stages such as Completed Analysis, Agent Verdict, and Analyst-Applied for data sources. Stages such as Reviewed and Eligible stages are not currently supported.

The following table maps the tool statuses to the executed-call states:

Tool status Executed-call state
retried_succeeded Retried
retried_failed Failed
no_retry + successful status Completed
no_retry + failed status Failed
not_executed Omit from executed-call counts

Create a shared dashboard based on role-based access control (RBAC) permissions of a team queue

If a dashboard is used by administrators, SPL searches can be used to query resources since the administrators have access to them. However, for non-admin users or for locked environments, use the REST API endpoint for analyst queue to create a dashboard that limits access to the results for user based on team queue permissions.

Follow these steps to create a shared dashboard based on RBAC permissions of a team queue:

  1. Create a saved search to which add the $queue_filter$ after the finding ID but before an aggregation command such as stats.

  2. Register the saved search in the mc_dashboard_searches.conf file.

  3. Make an API call for the registered search from the Dashboard Studio using the /public/v2/search/dashboards endpoint.

Saved search
CODE 
# my_app/default/savedsearches.conf
[My SOC Agent Dashboard - Findings Triaged]
search = search index="mc_history" collection="mc_ai_analysis" NOT is_archive_record=true \
| eval event_id=spath(_raw,"record.incident_id"), completed=spath(_raw,"change.status") \
| where completed="completed" \
$queue_filter$ \
| where isnotnull(is_investigation) \
| stats dc(event_id) AS findings_triaged
dispatchAs = user
is_visible = false
enableSched = 0
Allowlist entry
CODE 
# my_app/default/mc_dashboard_searches.conf
[my_soc_agent_findings_triaged]
savedsearch_name = My SOC Agent Dashboard - Findings Triaged
allowed_tokens = queue_filter
queue_filter_lookup_fields = is_investigation
Dashboard Studio query
CODE 
| rest splunk_server=local
/servicesNS/nobody/missioncontrol/public/v2/search/dashboards
search_format=true
search_name="my_soc_agent_findings_triaged"
earliest="-30d@d" latest="now"
| fields - splunk_server _span _spandays

Following are some guidelines that you can follow when creating the SPL queries:

  • Place $queue_filter$ before the aggregation so that you can prioritize filtering individual findings.

  • The endpoint matches event_id to mc_findings_lookup.notable_id and filters by queue_id.

  • For these searches, queue_filter_lookup_fields=is_investigation makes is_investigation available after enrichment.

  • The line where isnotnull(is_investigation) confirms that the lookup found the finding does not require is_investigation=true .