What Are Data Models?

Data models are structured representations of your Splunk data. They define a hierarchy of objects and fields that map to your raw events, making it possible to use accelerated searches with tstats — which is dramatically faster than searching raw data.

If you’re running Splunk Enterprise Security or building dashboards that need to perform at scale, data models are how you get there. They’re also the backbone of the Common Information Model (CIM), which standardizes field names across different data sources so your searches work regardless of vendor.

Referencing Data Models

The following are some useful tools for referencing data models to help you get your data CIM compliant.

View Structure

View the data model structure. Expand objectNameList to see its array values. Useful for recalling objects or fields during searches.

1
| datamodel Authentication

List All Data Models

1
2
| rest /services/data/models
| table title description acceleration

Exploring Data

Use the following to check if the data model currently contains any data.

1
| from datamodel:Authentication.Authentication

To drill deeper into a data model object:

1
| from datamodel:Authentication.Failed_Authentication

Take it a step further and filter on a specific user:

1
2
| from datamodel:Authentication.Failed_Authentication
| search user=username

Using tstats

tstats is the main reason data models matter. It searches accelerated data model summaries instead of raw events, which makes it orders of magnitude faster — especially over large time ranges.

Basic tstats Query

Count failed authentications by user:

1
| tstats count from datamodel=Authentication where Authentication.action=failure by Authentication.user

tstats with Time

Failed authentications over time, broken into hourly buckets:

1
| tstats count from datamodel=Authentication where Authentication.action=failure by _time Authentication.user span=1h

tstats with Multiple Fields

Show source and destination for network traffic:

1
| tstats count from datamodel=Network_Traffic by All_Traffic.src All_Traffic.dest All_Traffic.dest_port

tstats with summariesonly

Force the search to only use accelerated data (faster, but won’t include non-accelerated events):

1
| tstats summariesonly=true count from datamodel=Authentication by Authentication.user Authentication.action

Data Model Acceleration

Acceleration is what makes tstats fast. When you accelerate a data model, Splunk pre-builds summary data in the background that tstats can query directly.

Check Acceleration Status

1
2
3
4
| rest /services/admin/summarization by_tstats=t
| table eai:acl.app datamodel_name summary.access_time summary.is_inprogress summary.size summary.complete summary.buckets_size
| rename eai:acl.app as app datamodel_name as datamodel
| sort - summary.size

Enable Acceleration

You can enable acceleration through Settings → Data Models → Edit → Acceleration, or via the REST API:

1
2
3
curl -k -u admin:password https://localhost:8089/servicesNS/nobody/<app>/data/models/<model_name> \
  -d acceleration=true \
  -d acceleration.earliest_time=-1y

Troubleshooting Acceleration

If acceleration seems stuck or incomplete:

1
2
3
| rest /services/admin/summarization by_tstats=t
| search datamodel_name="Authentication"
| table summary.is_inprogress summary.complete summary.last_error

Common issues: - Acceleration not building: Check that the data model’s search constraint matches your data. No matching events = nothing to accelerate. - Slow acceleration: Large time ranges or complex constraints slow it down. Start with a shorter acceleration.earliest_time. - Disk space: Accelerated summaries take disk space. Monitor with summary.size from the REST endpoint above.

CIM Compliance

The Common Information Model (CIM) is a set of standard field names that Splunk apps (like ES) expect. If your data uses src_ip but the CIM expects src, your data won’t show up in data model searches.

Check If Your Data Is CIM Compliant

1
2
| datamodel Authentication Authentication search
| head 10

If fields are empty or missing, your data needs field aliases, eventtypes, or tags to map correctly.

Map Your Data to a Data Model

Three things need to line up:

  1. Tags and Eventtypes — Data models use tags to find matching events. For example, the Authentication data model looks for events tagged with authentication. Create an eventtype that matches your data, then tag it: - Settings → Event Types → New → define your search constraint - Settings → Tags → tag your eventtype with the required tags (e.g., authentication, default)

  2. Field Aliases — If your data has source_user but the CIM expects user, create a field alias: - Settings → Fields → Field Aliases → New

  3. Calculated Fields — For fields that need transformation, use eval-based calculated fields: - Settings → Fields → Calculated Fields → New

Validate CIM Mapping

After mapping, verify your data shows up:

1
2
3
| from datamodel:Authentication.Authentication
| head 10
| table _time user action app src dest

The Data Models

The CIM ships with a broad set of data models. Each one defines a standard schema — objects, fields, and tags — that normalize data from different vendors into a common structure. Below is a breakdown of each data model, what it covers, and how to query it.

Alerts

The Alerts data model captures notable events and alerts generated by security tools, SIEM correlation rules, or any system that produces alert-level output. This is where your triggered alerts land when properly tagged.

Key fields: severity, app, description, type, id

Tags: alert

1
| tstats count from datamodel=Alerts by Alerts.severity Alerts.app Alerts.type

Authentication

The Authentication data model covers login events — successes, failures, privilege escalations, and account lockouts. This is one of the most commonly used data models in ES and security monitoring.

Key fields: user, action, app, src, dest, authentication_method

Tags: authentication, default

Objects: Authentication, Failed_Authentication, Successful_Authentication

1
| tstats count from datamodel=Authentication where Authentication.action=failure by Authentication.user Authentication.src

Certificates

The Certificates data model tracks SSL/TLS certificate events — issuance, expiration, validation failures, and certificate details observed in network traffic or endpoint logs.

Key fields: ssl_subject, ssl_issuer, ssl_end_time, ssl_serial, ssl_version

Tags: certificate, ssl

1
| tstats count from datamodel=Certificates by All_Certificates.SSL.ssl_subject All_Certificates.SSL.ssl_end_time All_Certificates.SSL.ssl_issuer

Change

The Change data model captures configuration changes, system changes, and audit events — anything where something was modified, created, or deleted. Critical for change management and compliance.

Key fields: action, change_type, command, object, object_path, user, result

Tags: change

Objects: All_Changes, Account_Management, Auditing_Changes, Endpoint_Changes, Instance_Changes, Network_Changes

1
| tstats count from datamodel=Change by All_Changes.action All_Changes.object All_Changes.user

Data Access

The Data Access data model tracks file and data access events — reads, writes, deletes, permission changes. Useful for DLP, insider threat, and compliance monitoring.

Key fields: action, object_path, user, src, object

Tags: data, access

1
| tstats count from datamodel=Data_Access by Data_Access.action Data_Access.object_path Data_Access.user

Databases

The Databases data model covers database activity — queries, connections, modifications, errors. Maps data from Oracle, MySQL, MSSQL, PostgreSQL, and other database audit logs.

Key fields: query, object, user, dest, instance_name, vendor_product

Tags: database

1
| tstats count from datamodel=Databases by All_Databases.dest All_Databases.object All_Databases.user

Email

The Email data model normalizes email events from mail servers, gateways, and security appliances — delivery, filtering, phishing detection, and DLP actions.

Key fields: src_user, recipient, subject, action, file_name, internal_message_id

Tags: email

Objects: All_Email, Delivery, Content, Filtering

1
| tstats count from datamodel=Email by All_Email.action All_Email.src_user All_Email.recipient

Endpoint

The Endpoint data model is broad — it covers process execution, services, filesystem changes, registry modifications, and listening ports on endpoints. This is the backbone for EDR and host-based monitoring.

Key fields: process_name, process, user, dest, parent_process, action

Tags: process, report, listening, port, service, endpoint, filesystem

Objects: Processes, Services, Filesystem, Registry, Ports

1
| tstats count from datamodel=Endpoint.Processes by Processes.process_name Processes.user Processes.dest

Event Signatures

The Event Signatures data model captures signature-based detection events — pattern matches from IDS, antivirus, WAFs, and other signature-driven security tools.

Key fields: signature, signature_id, vendor_product, dest

Tags: track_event_signatures

1
| tstats count from datamodel=Event_Signatures.Signatures by Signatures.signature Signatures.signature_id Signatures.vendor_product

Intrusion Detection

The Intrusion Detection data model covers IDS/IPS events — attacks detected, blocked, or allowed through network and host-based intrusion detection systems.

Key fields: action, category, severity, signature, src, dest, dvc

Tags: ids, attack

1
| tstats count from datamodel=Intrusion_Detection by IDS_Attacks.action IDS_Attacks.severity IDS_Attacks.signature

Inventory

The Inventory data model tracks asset and identity information — hardware inventory, installed software, network interfaces, and system details. Powers the ES asset framework. Note that its internal name is still Compute_Inventory, so that’s what goes in datamodel=.

Key fields: dest, os, vendor_product, version, mac, ip, serial

Tags: inventory, cpu, memory, network, storage, system, version, user, virtual

Objects: All_Inventory, CPU, Memory, Network, Storage, OS, User, Virtual_OS

1
| tstats count from datamodel=Compute_Inventory by All_Inventory.OS.os All_Inventory.vendor_product All_Inventory.dest

Malware

The Malware data model captures antivirus and anti-malware events — detections, quarantines, cleaning actions, and infection details.

Key fields: action, file_name, file_path, signature, dest, user

Tags: malware, attack

Objects: Malware_Attacks, Malware_Operations

1
| tstats count from datamodel=Malware.Malware_Attacks by Malware_Attacks.action Malware_Attacks.signature Malware_Attacks.dest

Network Resolution

The Network Resolution data model covers DNS events — queries, responses, and resolution failures. Essential for detecting C2 communication, DNS tunneling, and domain generation algorithms.

Key fields: query, query_type, answer, reply_code, src, dest

Tags: network, resolution, dns

1
| tstats count from datamodel=Network_Resolution by DNS.query DNS.reply_code DNS.src

Network Sessions

The Network Sessions data model tracks DHCP, VPN, and other network session events — IP assignments, session starts/stops, and session metadata.

Key fields: action, dest_ip, src_mac, signature, user, vendor_product

Tags: network, session, dhcp, vpn

Objects: All_Sessions, Session_Start, Session_End, DHCP, VPN

1
| tstats count from datamodel=Network_Sessions by All_Sessions.action All_Sessions.user All_Sessions.vendor_product

Network Traffic

The Network Traffic data model is one of the heaviest — it covers firewall logs, proxy traffic, netflow, and any connection-level network data.

Key fields: src, dest, dest_port, action, transport, bytes_in, bytes_out, app

Tags: network, communicate

Objects: All_Traffic, Allowed_Traffic, Blocked_Traffic

1
| tstats sum(All_Traffic.bytes) from datamodel=Network_Traffic by All_Traffic.src All_Traffic.dest All_Traffic.dest_port

Performance

The Performance data model tracks system performance metrics — CPU, memory, disk, network utilization, and uptime. Useful for capacity planning and correlating security events with system health.

Key fields: cpu_load_percent, mem_used, storage_used, dest, uptime

Tags: performance, cpu, memory, storage, network, uptime

Objects: All_Performance, CPU, Facilities, Memory, Storage, Network, OS, Uptime, Timesync

1
| tstats avg(All_Performance.CPU.cpu_load_percent) from datamodel=Performance where nodename=All_Performance.CPU by _time All_Performance.dest span=1h

Splunk Audit Logs

The Splunk Audit Logs data model tracks internal Splunk activity — search history, configuration changes, user access, and system events within the Splunk platform itself.

Key fields: info, user, search, search_type, savedsearch_name, total_run_time

Tags: modaction, invocation (most datasets here are constrained by index, e.g. index=_audit, rather than tags)

Objects: Search_Activity, Scheduler_Activity, View_Activity, Datamodel_Acceleration, Modular_Actions, Web_Service_Errors

1
| tstats count from datamodel=Splunk_Audit.Search_Activity by Search_Activity.search_type Search_Activity.user Search_Activity.info

Ticket Management

The Ticket Management data model normalizes ticketing system events — creation, updates, closures, and assignments from ServiceNow, Jira, or other ITSM platforms.

Key fields: ticket_id, status, priority, severity, user, description

Tags: ticketing, change

1
| tstats count from datamodel=Ticket_Management by All_Ticket_Management.status All_Ticket_Management.priority All_Ticket_Management.user

Updates

The Updates data model tracks patch and update events — what was installed, what failed, and what’s still pending. Key for vulnerability management and compliance.

Key fields: status, signature, dest, vendor_product

Tags: update, status

1
| tstats count from datamodel=Updates by Updates.status Updates.signature Updates.dest

Vulnerabilities

The Vulnerabilities data model captures vulnerability scan results — findings from Nessus, Qualys, Rapid7, and other scanners.

Key fields: signature, severity, dest, cve, vendor_product, bugtraq

Tags: vulnerability, report

1
| tstats count from datamodel=Vulnerabilities by Vulnerabilities.severity Vulnerabilities.signature Vulnerabilities.dest

Web

The Web data model covers HTTP/HTTPS traffic — proxy logs, web server access logs, WAF events, and URL filtering. One of the most commonly accelerated models alongside Network Traffic and Authentication.

Key fields: url, status, http_method, src, dest, action, bytes, http_user_agent

Tags: web

Objects: Web, Proxy

1
| tstats count from datamodel=Web by Web.url Web.status Web.src Web.http_method

Tips

  • Always use tstats over from datamodel when possible — it’s significantly faster
  • Use summariesonly=true in dashboards for performance, but know it won’t include events that haven’t been accelerated yet
  • Check acceleration regularly — if it falls behind, your dashboards will show stale data
  • Field names in tstats must be fully qualified — use Authentication.user not just user. The prefix is the root dataset name, not the data model name (All_Traffic.src for Network_Traffic, All_Changes.user for Change), and fields that live on a child dataset need the full path (All_Performance.CPU.cpu_load_percent)
  • The CIM Add-on (Splunk_SA_CIM) contains all the data model definitions — install it and read through them to understand what fields and tags each model expects

Further Reading