What Is the Splunk Common Information Model?
The Splunk Common Information Model (CIM) is a standardized framework that defines a common set of field names and event categories for normalizing data from disparate sources. Instead of every firewall, endpoint, and cloud service using different field names for the same concept (like source IP being src_ip, SrcAddr, source_address, or clientip), CIM provides a universal schema that maps them all to a consistent set of fields.
Think of CIM as the Rosetta Stone for your Splunk deployment. Once your data conforms to CIM, every search, dashboard, and correlation rule works across all data sources without modification.
Why CIM Matters
- Write once, search everywhere — A single search works across firewalls, endpoints, cloud, and more.
- Powers Enterprise Security (ES) — Splunk ES is entirely CIM-dependent. If your data isn’t CIM-compliant, ES can’t use it.
- Compliance acceleration — NIST 800-53, M-21-31, and other frameworks require log correlation across sources. CIM makes this possible.
- Scales your team — Analysts don’t need to memorize field names for every sourcetype.
CIM Data Models
CIM organizes data into predefined data models — logical groupings of related event types. Each data model defines the required and optional fields for that category.
Key CIM Data Models for Security
| Data Model | Covers | Key Fields |
|---|---|---|
| Authentication | Login/logout events | action, app, src, dest, user |
| Network Traffic | Firewall, flow, IDS/IPS | action, src_ip, dest_ip, dest_port, bytes, transport |
| Endpoint | Process, file, registry, service | action, dest, process_name, user, file_name |
| Malware | AV/EDR detections | action, signature, dest, file_name, user |
| Web | Proxy, WAF, web access | action, url, src, dest, http_method, status |
| Vulnerability | Scan results | dest, severity, signature, cvss, vendor_product |
| Change | Configuration changes | action, object, object_category, user, dest |
| Email gateway logs | action, src_user, recipient, subject |
How CIM Mapping Works
CIM mapping involves two steps: (1) tagging events with the correct event type, and (2) mapping source-specific field names to CIM field names.
Step 1: Event Type Tags
Tags tell Splunk which data model a set of events belongs to. For example, for Palo Alto firewall logs to appear in the Network Traffic data model:
# In eventtypes.conf
[paloalto_traffic]
search = sourcetype=pan:traffic
# In tags.conf
[eventtype=paloalto_traffic]
network = enabled
communicate = enabled
Step 2: Field Aliases
Field aliases map vendor-specific field names to CIM-standard names:
# In props.conf
[pan:traffic]
FIELDALIAS-src = src_addr AS src_ip
FIELDALIAS-dest = dst_addr AS dest_ip
FIELDALIAS-dest_port = dst_port AS dest_port
FIELDALIAS-action = action AS action
Step 3: Calculated Fields (Optional)
Sometimes CIM fields need to be derived from multiple source fields:
# In props.conf
[pan:traffic]
EVAL-bytes = bytes_sent + bytes_received
EVAL-direction = case(direction=="inbound", "inbound", direction=="outbound", "outbound", 1==1, "unknown")
Using CIM in Searches
Once your data is CIM-compliant, you can search across all sources using the datamodel command or tstats:
Using the datamodel Command
| datamodel Authentication Authentication search
| stats count BY Authentication.user Authentication.action Authentication.src
Using tstats for Accelerated Data Models
The tstats command queries accelerated data model summaries — dramatically faster than raw searches:
| tstats count FROM datamodel=Authentication WHERE Authentication.action=failure BY Authentication.user Authentication.src
| rename Authentication.* AS *
| where count > 20
Network Traffic Analysis Across All Sources
| tstats sum(All_Traffic.bytes) AS total_bytes FROM datamodel=Network_Traffic BY All_Traffic.src_ip All_Traffic.dest_ip
| rename All_Traffic.* AS *
| sort - total_bytes
Data Model Acceleration
Acceleration pre-computes data model summaries using TSIDX files, enabling tstats queries to return results in seconds instead of minutes.
Enabling Acceleration
- Navigate to Settings → Data Models
- Click the data model you want to accelerate
- Click Edit → Edit Acceleration
- Check “Accelerate” and set the summary range (e.g., 30 days)
Acceleration Best Practices
- Only accelerate data models you actively query via
tstats - Monitor acceleration status via the DMC (Distributed Management Console)
- Acceleration consumes disk space — plan for approximately 1-3% of raw data size
- Set summary ranges that match your reporting needs (7 days for SOC, 90 days for compliance)
CIM for Compliance
NIST 800-53 Audit and Accountability (AU Controls)
CIM’s Authentication and Change data models map directly to NIST AU controls:
# AU-3: Content of Audit Records
| tstats count FROM datamodel=Authentication BY Authentication.user Authentication.src Authentication.dest Authentication.action _time
# AU-6: Audit Record Review
| tstats count FROM datamodel=Authentication WHERE Authentication.action=failure BY Authentication.user _time span=1d
M-21-31 Logging Maturity
OMB M-21-31 requires organizations to reach specific logging maturity levels. CIM enables cross-source correlation required at Event Logging Tier 2 and above:
# Cross-source user activity correlation
| tstats count FROM datamodel=Authentication BY Authentication.user | rename Authentication.user AS user
| append [| tstats count FROM datamodel=Web BY Web.user | rename Web.user AS user]
| append [| tstats count FROM datamodel=Email BY Email.src_user | rename Email.src_user AS user]
| stats sum(count) AS total_events dc(source) AS data_sources BY user
The Splunk CIM Add-On
The Splunk Common Information Model (CIM) Add-On (available on Splunkbase) provides the data model definitions, tags, and field aliases out of the box. Install it as the foundation of any CIM-compliant deployment:
- Download from Splunkbase:
Splunk Common Information Model - Install on your search heads
- Install Technology Add-ons (TAs) for your data sources — most Splunk TAs include CIM mapping
Validating CIM Compliance
Check if your data is CIM-compliant using the CIM Validation dashboard or manual checks:
# Check if Authentication model is populated
| tstats count FROM datamodel=Authentication BY sourcetype
# Verify specific fields exist
index=security sourcetype=WinEventLog:Security EventCode=4624
| head 10
| table action src dest user app
Common CIM Mapping Pitfalls
- Missing tags — Fields are aliased but events aren’t tagged, so they don’t appear in data models.
- Conflicting field aliases — Multiple TAs aliasing different source fields to the same CIM field.
- Not installing the CIM add-on — Data model definitions live in the CIM add-on, not in Splunk core.
- Forgetting to accelerate — Without acceleration,
tstatswon’t return results (or falls back to slow searches).
Best Practices Summary
- Install the CIM add-on first — Before any other configuration.
- Use vendor TAs — Splunk’s Technology Add-ons handle CIM mapping for most common sources.
- Validate after every new data source — Check that new sources appear in the expected data models.
- Accelerate for production — SOC dashboards and ES correlations depend on accelerated data models.
- Document your custom mappings — Any manual field aliases or eval fields should be documented for your team.
- Plan for scale — CIM acceleration adds disk overhead. Factor this into your Splunk sizing.
Explore the full Rhombic SPL Command Series on our blog.