Common Information Model (CIM) Overview

When you collect data from many different systems into Splunk, you run into a big problem: every system names things differently. A firewall might call the person who triggered an event 'source_user', a Windows server might call that same person 'Account_Name', and a web server log might use 'user_agent' or even 'c-username'. If you try to write a single search that counts how many times a particular user logged in across all these systems, you have to remember every different field name. That is tedious, error-prone, and makes it hard to reuse searches or dashboards.

The Common Information Model (CIM) fixes this mess. CIM stands for Common Information Model – it is a set of standardised field names and data structures that Splunk uses to normalise (or 'map') data from different sources into a consistent format. Think of it as a universal translator for your machine data. When you install a Splunk add-on for a specific technology – like the Splunk Add-on for Microsoft Windows or the Splunk Add-on for AWS – those add-ons automatically transform the raw data into the CIM format. This means your firewall events will use fields like 'user', 'action', 'src_ip', and 'dest_ip' in the same way that your web server events do, even though the original logs looked completely different.

The CIM is built around 'data models': pre-defined collections of fields organised into categories like 'Authentication', 'Network Traffic', 'Web', 'Email', and 'Performance'. Each data model focuses on one type of data. For example, the 'Authentication' data model includes fields such as 'user', 'app', 'dest', 'action' (which can be 'success' or 'failure'), and 'src_ip'. The 'Network Traffic' data model includes fields like 'src_ip', 'dest_ip', 'bytes_in', 'bytes_out', and 'protocol'. These data models are hierarchical – they have 'root' objects (like 'Base' which has a few common fields) and then 'child' objects (like 'Authentication' which adds more specific fields).

Why does this matter? Because once your data is CIM-compliant, you can write a search like this: | datamodel Authentication search – and Splunk knows what fields to use, regardless of the original source. You can also use Splunk's predefined dashboards (like the 'Access Control' dashboard or the 'Web Intelligence' dashboard) out of the box, because those dashboards expect data in CIM format. Without the CIM, you would have to build custom searches and dashboards for every single data source, which would be a huge waste of time.

The CIM does not change your raw data – the original logs are still stored exactly as they arrived. Instead, it works by 'tagging' events with a data model name and adding extra fields (called 'temp' fields or 'calculated' fields) that map the original field values to the standard CIM fields. When you run a CIM-based search, Splunk uses these mappings behind the scenes so you see the standard field names.

Here are the key components of the CIM:

When you install a Splunk Technology Add-on (TA) for a specific product, that TA usually includes all the necessary field extractions, tags, and event types to make the data CIM-compliant. For example, the Splunk Add-on for Microsoft Windows includes mappings for Windows Event Log data so that logins, logouts, and account changes are automatically tagged with the 'Authentication' data model.

The CIM is maintained by Splunk and gets updated with new data models over time. You can see which data models are available in your Splunk instance by going to Settings > Data Models (or using the | datamodel command in a search). As a Power User, you need to know how to check if your data is CIM-compliant and how to use the CIM in your searches and dashboards.

An IT professional named Priya works at a company called GreenLeaf Corp, which has 200 servers running Windows and Linux, a Palo Alto firewall, and uses Office 365 for email. Priya has been asked to create a single dashboard that shows all failed login attempts across the entire company for the last 7 days. Without the CIM, Priya would need to understand exactly how each system logs failures – Windows uses Event ID 4625 in the Security log, Linux stores failed SSH attempts in /var/log/auth.log with a format like 'Failed password for root from 10.0.0.1 port 22 ssh2', and the firewall logs authentication failures in its own proprietary format. That is three completely different field names and log formats for the same concept.

Here is what Priya actually does, step by step:

First, she installs the Splunk Technology Add-ons for Windows, Linux, and Palo Alto Networks. These add-ons automatically parse the raw data and map it to the CIM's Authentication data model. She also installs the Splunk Add-on for Microsoft Office 365 to cover the email system.

Second, she checks that the data is being tagged correctly. She runs a search like this: index=* sourcetype=* | datamodel Authentication search. If the data is properly mapped, she will see results. If not, she uses the | datamodel command to look for the 'Authentication' data model and drills down to see which fields are populated.

Third, she opens the 'Access Control' dashboard that comes with Splunk's Enterprise Security app (or uses the out-of-the-box Authentication dashboard from the CIM). This dashboard is pre-built to show failed logins, successful logins, and the most active users. Because all her data is now in CIM format, the dashboard works immediately, showing failed logins from all sources in one unified view.

Fourth, she customises the dashboard slightly. She adds a dropdown filter so the manager can filter by 'app' (like VPN logins vs domain logins). She uses the 'action' field, which is set to 'failure' for every failed login regardless of the source. She adds a column for 'src_ip' so the security team can see the IP address of the attacker.

Fifth, she sets up a scheduled search using the CIM: | datamodel Authentication search | where action = 'failure' | stats count by user, src_ip, app. This search runs every hour and sends an alert to the security team if more than 10 failed logins come from the same IP address. Because the search uses CIM fields, it works across all systems without modification.

Without the CIM, Priya would have had to write three separate searches (one for Windows, one for Linux, one for firewall) and then merge the results manually. Every time the company added a new system (like a VPN), she would need to update all her searches again. With the CIM, adding a new system means just installing its Technology Add-on, and all existing searches and dashboards immediately work with the new data. That is the practical power of the Common Information Model.