10.2 CIM Knowledge Objects, Data Models & Schemas

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:

1. 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.
2. 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.
3. 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).
4. Change: Audits configuration modifications, user account creations, group membership updates, filesystem permission alterations, network infrastructure changes, and audit log state shifts.
5. Alerts: Structures security detections, IDS/IPS alerts, operational threshold breaches, and infrastructure monitoring notifications.
6. Endpoint: Captures endpoint operating system telemetry, divided into specialized child datasets for Processes, Services, Filesystem, Registry, and Ports.
7. Malware: Captures malicious software detections, endpoint antivirus quarantines, sandbox detonations, and EDR threat remediation actions.
8. Network Resolution (Network_Resolution / DNS): Captures DNS queries, responses, record types (A, AAAA, PTR, CNAME, TXT), and DNS server lookup performance.
9. Email: Captures message transmission, sender/recipient addresses, subject lines, message headers, attachment metadata, and email gateway filtering decisions.
10. Databases (Databases): Captures database query logs, user connections, SQL execution errors, table schema modifications, and administrative audit trails across relational and NoSQL engines.
11. 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:

---

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.