Study guide
10.2 CIM Knowledge Objects, Data Models & Schemas
Splunk Core Certified Power User Exam
Track your progress as you read
Finished sections get a check mark.
1 Introduction & Exam Overview
0.1 Exam Facts, Logistics & Test-Taking Strategy 0.2 Splunk Knowledge Objects & Search Pipeline Architecture
2 Chapter 1: Transforming Commands for Visualizations
1.1 The chart Command & Multi-Dimensional Aggregations 1.2 The timechart Command & Time-Series Visualizations 1.3 Transforming Options: limit, useother, usenull, and Split-By Clauses
3 Chapter 2: Filtering and Formatting Results
2.1 The eval Command & Core Evaluation Functions 2.2 Filtering Data: search vs. where Commands 2.3 Handling Missing Data with fillnull
4 Chapter 3: Correlating Events & Transactions
3.1 Understanding Transactions & Event Grouping Concepts 3.2 Configuring transaction Constraints: maxspan, maxpause, startswith, endswith 3.3 Analyzing Transaction Output Fields: duration & eventcount 3.4 transaction vs. stats: Performance & Architectural Trade-offs
5 Chapter 4: Creating and Managing Fields
4.1 Regular Expression Extractions with Field Extractor 4.2 Delimiter-Based Extractions with Field Extractor 4.3 Field Extraction Management, Permissions & Search-Time Precedence
6 Chapter 5: Field Aliases and Calculated Fields
5.1 Creating and Using Field Aliases 5.2 Creating and Configuring Calculated Fields 5.3 Aliases vs. Calculated Fields in the Search Execution Pipeline
7 Chapter 6: Tags and Event Types
6.1 Creating and Using Event Types 6.2 Creating and Managing Tags 6.3 Combining Tags and Event Types for Data Classification
8 Chapter 7: Creating and Using Search Macros
7.1 Creating Basic Search Macros & Backtick Syntax 7.2 Macro Arguments, Validation & Evaluation Functions 7.3 Macro Scoping, Permissions & Troubleshooting
9 Chapter 8: Creating and Using Workflow Actions
8.1 Workflow Action Architecture & Field/Event Context 8.2 Creating GET and POST Workflow Actions 8.3 Creating Search Workflow Actions & Dynamic Secondary Searches
10 Chapter 9: Data Models and Pivot
9.1 Data Model Architecture & The Pivot Tool 9.2 Creating and Structuring Datasets & Hierarchies 9.3 Accelerating Data Models & TSIDX Acceleration
11 Chapter 10: Common Information Model (CIM)
10.1 The Splunk Common Information Model (CIM) & Normalization 10.2 CIM Knowledge Objects, Data Models & Schemas 10.3 Normalizing & Validating Data with the CIM App / datamodel command
10.2 CIM Knowledge Objects, Data Models & Schemas
Key Takeaways Explain This Topic AI
CIM structures enterprise data across domain-specific Data Models—including Authentication, Network Traffic, Web, Change, Alerts, Endpoint, Malware, Network Resolution (DNS), Email, Databases, and Inventory.
A CIM Data Model schema specifies root dataset tag constraints, required fields, optional contextual attributes, and hierarchical child datasets.
Root dataset constraints enforce strict boolean tag combinations, such as tag=authentication for logins, tag=network AND tag=communicate for network traffic, and tag=malware AND tag=attack for endpoint threat detections.
Hierarchical child datasets inherit all parent attributes and constraints, applying specialized filters (e.g., Authentication > Failed_Authentication filtering on action=failure).
Technology Add-ons (TAs) implement CIM compliance through a 6-tier search-time execution pipeline: Field Extractions -> Field Aliases -> Lookups -> Calculated Fields (EVAL) -> Event Types -> Tags.
Last updated: August 2026
10.2 CIM Knowledge Objects, Data Models & Schemas
Quick Summary: The Splunk Common Information Model organizes enterprise machine data into domain-specific Data Models . Each data model acts as an architectural contract: it defines an expected set of Event Tags that determine dataset membership, alongside a comprehensive dictionary of CIM Attributes (Fields) that must be populated from raw event streams. To achieve CIM compliance, Splunk power users and Technology Add-on developers configure a coordinated pipeline of search-time knowledge objects across props.conf , transforms.conf , eventtypes.conf , and tags.conf . Understanding these data model schemas, multi-tag constraints, and configuration mechanics is essential for the Power User certification.
1. Core CIM Data Model Domains
The CIM Add-on provides pre-built data models representing the foundational technologies deployed across enterprise IT and security environments:
Authentication: Captures user authentication, logins, logouts, credential validations, MFA sessions, and privilege escalations across operating systems, cloud identity providers (IdPs), VPN concentrators, and SaaS applications.
Network Traffic ( Network_Traffic ): Captures Layer 3/4 network flows, perimeter firewall connections, router Access Control Lists (ACLs), NetFlow/IPFIX streams, and load balancer traffic.
Web: Captures HTTP/HTTPS web server access logs (Apache, Nginx, IIS), Content Delivery Networks (Cloudflare, Akamai), and Forward/Reverse Web Proxies (Squid, Zscaler, Blue Coat).
Change: Audits configuration modifications, user account creations, group membership updates, filesystem permission alterations, network infrastructure changes, and audit log state shifts.
Alerts: Structures security detections, IDS/IPS alerts, operational threshold breaches, and infrastructure monitoring notifications.
Endpoint: Captures endpoint operating system telemetry, divided into specialized child datasets for Processes , Services , Filesystem , Registry , and Ports .
Malware: Captures malicious software detections, endpoint antivirus quarantines, sandbox detonations, and EDR threat remediation actions.
Network Resolution ( Network_Resolution / DNS): Captures DNS queries, responses, record types ( A , AAAA , PTR , CNAME , TXT ), and DNS server lookup performance.
Email: Captures message transmission, sender/recipient addresses, subject lines, message headers, attachment metadata, and email gateway filtering decisions.
Databases ( Databases ): Captures database query logs, user connections, SQL execution errors, table schema modifications, and administrative audit trails across relational and NoSQL engines.
Inventory: Tracks physical and virtual computing assets, operating system versions, installed software packages, CPU/memory capacities, and network interface allocations.
2. Comprehensive CIM Schema Reference Table
The table below outlines the core CIM data model schemas, their mandatory root tag constraints, core required fields, and primary child datasets:
CIM Data Model Mandatory Root Tag Constraints Core Required Fields Primary Child Datasets Key Use Cases
Authentication tag=authentication user , src , dest , action ( success | failure ), app Successful_Authentication , Failed_Authentication , Privileged_Authentication Brute force detection, credential stuffing, privileged login tracking
Network_Traffic tag=network AND tag=communicate src_ip , dest_ip , dest_port , transport , action ( allowed | blocked ), bytes All_Traffic > Traffic_By_Action > Allowed_Traffic / Blocked_Traffic Firewall monitoring, port scan detection, bandwidth utilization
Web tag=web (and optionally tag=proxy ) src , dest , http_method , status , url , uri_path , http_user_agent , bytes HTTP , Proxy Web traffic analysis, URI vulnerability scanning, proxy tracking
Change tag=change AND ( tag=account | audit | endpoint | network ) user , src , dest , object , object_category , action , status Account_Management , Auditing , Endpoint_Changes , Network_Changes Unauthorized user creation, policy changes, configuration drift
Endpoint tag=endpoint dest , user , process_name , process_id , file_name , file_path Processes , Services , Filesystem , Registry , Ports Threat hunting, process tree analysis, persistence detection
Malware tag=malware AND tag=attack dest , file_name , file_hash , signature , action ( blocked | quarantined | allowed ) Malware_Attacks , Malware_Operations Infection tracking, virus outbreaks, ransomware containment
Network_Resolution tag=network AND tag=resolution src , dest , query , record_type , response_code DNS DNS tunneling, DGA detection, malicious domain lookups
Alerts tag=alert app , description , severity , signature , src , dest , user Alerts Centralized alert aggregation, triage dashboards
Email tag=email src_user , recipient , subject , message_size , action Delivery , Content Phishing analysis, spam filtering, data exfiltration audits
Databases tag=database user , dest , query , duration , action , response_code Instance_Stats , Session_Info , Query SQL injection detection, database latency monitoring
3. Anatomy of a CIM Data Model Schema
A CIM Data Model schema is a structured specification composed of four core architectural elements: +-----------------------------------------------------------------------------------------+
- | ANATOMY OF A CIM DATA MODEL SCHEMA |
- | |
- | [ ROOT DATASET ] |
- | - Root Search Constraints: Base tag requirements (e.g., tag=network tag=communicate) |
- | - Required Fields: Attributes that MUST exist for basic compliance (src, dest, action) |
- | - Optional Fields: Contextual enrichment attributes (duration, rule, packets, bytes) |
- | |
- | │ |
- | └─── [ CHILD DATASETS (Hierarchical Inheritance) ] |
- | - Inherit: All parent constraints and attributes |
- | - Extended Constraints: Additional filters (e.g., action="blocked") |
- | - Specialized Attributes: Child-specific fields |
- +-----------------------------------------------------------------------------------------+
- 1. Required vs. Optional Fields
Required Fields: Core attributes that define the semantic meaning of the event. For example, in the Authentication schema, user , src , dest , and action are required. If an event matches tag=authentication but lacks a user or action , correlation searches will produce null outputs or false positives.
Optional Fields: Supplementary attributes that enrich the event when available from the vendor source (e.g., duration , rule , http_referrer , vendor_product , user_agent ).
2. Multi-Tag Root Constraints
CIM Data Models use Splunk Tags in their root dataset constraints to filter which indexed events enter the model. Many schemas require multi-tag boolean constraints to prevent false categorization:
The Network_Traffic data model requires tag=network AND tag=communicate . An event tagged only with tag=network (such as a router CPU metric) is excluded.
The Malware data model requires tag=malware AND tag=attack .
The Network_Resolution data model requires tag=network AND tag=resolution .
3. Hierarchical Child Datasets & Object Inheritance
CIM data models leverage object-oriented hierarchical inheritance. Child datasets inherit all attributes and search constraints from their parent datasets while appending more granular filtering conditions: +-----------------------------------------------------------------------------------------+
- | AUTHENTICATION DATA MODEL DATASET HIERARCHY |
- | |
- | Root Dataset: Authentication (Constraint: tag=authentication) |
- | │ Inherited Fields: user, src, dest, action, app, signature, vendor_product |
- | │ |
- | ├── Child Dataset: Successful_Authentication (Constraint: action="success") |
- | │ Inherits: all Authentication fields + applies action="success" filter |
- | │ |
- | ├── Child Dataset: Failed_Authentication (Constraint: action="failure") |
- | │ Inherits: all Authentication fields + applies action="failure" filter |
- | │ |
- | └── Child Dataset: Privileged_Authentication (Constraint: tag=privileged) |
- | Inherits: all Authentication fields + requires tag=privileged |
- +-----------------------------------------------------------------------------------------+
When you query a child dataset (e.g., Authentication.Failed_Authentication ), Splunk automatically combines the parent constraint with the child constraint: (tag=authentication) AND (action="failure") .
4. How Technology Add-ons (TAs) Implement CIM Compliance
Technology Add-ons (TAs) are modular configuration packages that normalize specific vendor data sources to the CIM. TAs achieve compliance using a 6-tier search-time knowledge object pipeline. +-----------------------------------------------------------------------------------------+
- | THE 6-TIER SEARCH-TIME NORMALIZATION PIPELINE |
- | |
- | [1] Field Extraction --> Extract vendor-native tokens from _raw |
- | (props.conf / transforms.conf: EXTRACT-*, REPORT-*) |
- | |
- | [2] Field Aliasing --> Map vendor fields directly to standard CIM field names |
- | (props.conf: FIELDALIAS-<class> = vendor_field AS cim_field) |
- | |
- | [3] Lookup Tables --> Enrich events and map proprietary codes to standard text |
- | (props.conf: LOOKUP-<class> / transforms.conf) |
- | |
- | [4] Calculated Fields --> Compute composite metrics & evaluate conditional logic |
- | (props.conf: EVAL-<field> = case(...), if(...), coalesce(...)) |
- | |
- | [5] Event Types --> Group event signatures into semantic categories |
- | (eventtypes.conf: [eventtype_name] search = criteria) |
- | |
- | [6] Tags --> Apply standardized CIM category tags to event types |
- | (tags.conf: [eventtype=eventtype_name] tag_name = enabled) |
- +-----------------------------------------------------------------------------------------+
- Detailed Configuration File Mechanics
- 1. Field Extractions ( props.conf / transforms.conf )
Extracts proprietary strings from raw event text using regular expressions with named capture groups: # props.conf
[paloalto:traffic]
EXTRACT-pan_traffic = ^[^,]+,[^,]+,[^,]+,(?<pan_type>[^,]+),[^,]+,[^,]+,(?<pan_src_ip>[^,]+),(?<pan_dest_ip>[^,]+),(?<pan_sport>\d+),(?<pan_dport>\d+)
2. Field Aliases ( props.conf FIELDALIAS-<class> )
Maps the extracted vendor field name to the official CIM standard name. Both field names remain accessible in search: # props.conf
[paloalto:traffic]
FIELDALIAS-pan_src_dest = pan_src_ip AS src_ip pan_src_ip AS src pan_dest_ip AS dest_ip pan_dest_ip AS dest pan_sport AS src_port pan_dport AS dest_port
3. Calculated Fields ( props.conf EVAL-<field> )
Uses eval expressions to calculate composite fields, convert units, and normalize action verbs into standard lowercase strings: # props.conf
- [paloalto:traffic]
- # Normalize vendor action strings (allow/deny/drop/reset) to CIM (allowed/blocked)
EVAL-action = case(pan_action=="allow", "allowed", match(pan_action, "deny|drop|reset"), "blocked", true(), "unknown")
- EVAL-bytes = coalesce(bytes_in, 0) + coalesce(bytes_out, 0)
- EVAL-vendor_product = "Palo Alto Networks PAN-OS"
- 4. Event Types ( eventtypes.conf )
- Classifies events matching specific search patterns into named categories: # eventtypes.conf
- [paloalto_traffic_event]
- search = sourcetype="paloalto:traffic" pan_type="TRAFFIC"
- [paloalto_threat_event]
- search = sourcetype="paloalto:threat" pan_type="THREAT"
- 5. Tags ( tags.conf )
- Attaches mandatory CIM tags to the event types, ensuring they satisfy data model root constraints: # tags.conf
- [eventtype=paloalto_traffic_event]
- network = enabled
- communicate = enabled
- [eventtype=paloalto_threat_event]
- ids = enabled
- attack = enabled
Warning
Execution Order & Chaining Rules: In Splunk's search-time execution pipeline, Field Aliases (Stage 2) execute before Calculated Fields (Stage 3). Consequently, you cannot create a field alias on an EVAL- field. Conversely, Event Types (Step 5) and Tags (Step 6) evaluate after Field Extractions, Aliases, Lookups, and Calculated Fields, meaning event type search strings can reference both original vendor fields and aliased CIM fields.