ExamFinch.com My Study

Study guide

4.3 Checking Index Data Integrity

Practice this exam

Splunk Enterprise Certified Admin SPLK-1003

Track your progress as you read

Finished sections get a check mark.

1 Introduction

About the Splunk Enterprise Certified Admin Exam

2 Chapter 1: Splunk Admin Basics

1.1 Splunk Enterprise Architecture & Core Components

3 Chapter 2: License Management

2.1 License Types, Stacks, Pools & Licensing Architecture 2.2 License Violations, Rolling Window Warnings & Troubleshooting

4 Chapter 3: Splunk Configuration Files

3.1 Splunk Configuration Directory Structure 3.2 Configuration Layering, Precedence & Resolution Rules 3.3 Using btool to Inspect & Debug Configurations

5 Chapter 4: Splunk Indexes

4.1 Index Structure: Directories, Buckets & Bucket Files 4.2 Bucket Types & the Hot-Warm-Cold-Frozen-Thawed Lifecycle 4.3 Checking Index Data Integrity 4.4 indexes.conf Options: Paths, Bucket Sizing & Volumes 4.5 The Fishbucket: File Tracking, CRC Collisions & Re-reading Files 4.6 Applying a Data Retention Policy

6 Chapter 5: Splunk User Management

5.1 Splunk Roles, Capabilities & Custom Role Design 5.2 User Account Administration, Search Restrictions & Limits

7 Chapter 6: Splunk Authentication Management

6.1 Integrating Splunk with LDAP 6.2 Other Authentication Options & Enabling Multifactor Authentication

8 Chapter 7: Getting Data In

7.1 CLI Administration & Basic Data Onboarding Workflows 7.2 Forwarder Types: Universal Forwarder vs. Heavy Forwarder

9 Chapter 8: Distributed Search

8.1 How Distributed Search Works 8.2 Roles of the Search Head and Search Peers 8.3 Configuring Search Peers & Distributed Search Groups 8.4 Search Head Scaling & Search Head Clustering (SHC)

10 Chapter 9: Getting Data In – Staging

9.1 Ingestion Pipeline Stages: Input, Parsing, Merging, Typing & Indexing 9.2 Pipeline Component Placement & Queue Management 9.3 Splunk Input Options

11 Chapter 10: Configuring Forwarders

10.1 Forwarder Setup & outputs.conf Load Balancing 10.2 Indexer Acknowledgment, Data Cloning & Forwarder Routing

12 Chapter 11: Forwarder Management

11.1 Deployment Management & the Deployment Server 11.2 Deployment Apps & Deployment Clients 11.3 Server Classes, Client Grouping & App Deployment Strategies 11.4 Forwarder Management Monitoring & Troubleshooting

13 Chapter 12: Monitor Inputs

12.1 File & Directory Monitoring Mechanics 12.2 Monitor Input Tuning: Whitelists, Blacklists & CRC Settings 12.3 Deploying a Remote Monitor Input, Network Shares & Archives

14 Chapter 13: Network and Scripted Inputs

13.1 Creating Network Inputs: TCP & UDP 13.2 Optional Settings for Network Inputs 13.3 Scripted Inputs & PowerShell Data Collection

15 Chapter 14: Agentless Inputs

14.1 Windows Management Instrumentation (WMI) Inputs 14.2 HTTP Event Collector (HEC) Architecture & Administration

16 Chapter 15: Fine Tuning Inputs

15.1 Input-Phase Processing & Default Metadata Assignment 15.2 Character Set Encoding & Handling Binary Data

17 Chapter 16: Parsing Phase and Data

16.1 Line Breaking & Event Segmentation 16.2 Timestamp Extraction, Time Zones & Clock Skew Handling 16.3 Validating Event Parsing with Data Preview

18 Chapter 17: Manipulating Raw Data

17.1 Transformation Mechanics: props.conf & transforms.conf 17.2 Data Masking, Redaction & SEDCMD 17.3 Event Routing, Dynamic Index Assignment & Filtering to nullQueue

4.3 Checking Index Data Integrity

Key Takeaways Explain This Topic AI

Data integrity control is enabled per index with enableDataIntegrityControl = true in indexes.conf (default false) and works only on local, non-SmartStore indexes.

Splunk computes a SHA-256 hash for every slice of newly indexed raw data (128 KB by default) and writes it to an l1Hashes file.

When a bucket rolls from hot to warm, Splunk hashes the l1Hashes contents into an l2Hash file; both files live in the bucket's rawdata directory.

Verify with splunk check-integrity -index <name> or -bucketPath <path>; regenerate lost hash files with splunk generate-hash-files.

Integrity control covers only data indexed after it is enabled and only data at rest; protect forwarder traffic with SSL/TLS.

Last updated: September 2026

Data Integrity Control

Blueprint objective 4.3 asks you to check index data integrity . Splunk's tool for this is data integrity control: hashes recorded at index time and verified on demand.

Data Integrity Control Architecture

Regulated environments must be able to prove that log data has not been altered since it was indexed. Splunk Enterprise provides data integrity control , which records hashes of the raw data as it is indexed so that the data can be verified later.

Turning It On

Data integrity control is enabled per index in indexes.conf on the indexers. The default is false : [security_audit]

  • homePath = $SPLUNK_DB/security_audit/db
  • coldPath = $SPLUNK_DB/security_audit/colddb
  • thawedPath = $SPLUNK_DB/security_audit/thaweddb
  • enableDataIntegrityControl = true

It applies only to local indexes. SmartStore (remote storage) indexes do not support it, and Splunk Cloud Platform does not use it.

How It Works

Slices: As raw data is indexed, the journal is written in slices. By default a slice, and therefore a hash, covers 128 KB of raw data ( rawChunkSizeBytes = 131072 ).

Level-1 hashes: Splunk computes a SHA-256 hash of every slice of newly indexed raw data and writes it to an l1Hashes file.

Level-2 hash: When the bucket rolls from hot to warm , Splunk computes a hash of the contents of the l1Hashes file and stores it in l2Hash .

Location: Both hash files are stored in the bucket's rawdata directory . journal (rawdata) ──► slice 1 ─► SHA-256 ┐

  • slice 2 ─► SHA-256 ├─► l1Hashes file ──(hot→warm roll)──► SHA-256 ─► l2Hash
  • slice n ─► SHA-256 ┘

Only the rawdata is hashed. The tsidx and metadata files are not covered, because they can be rebuilt from rawdata at any time.

Verifying Data Integrity via the CLI

Checks are run on demand with splunk check-integrity , either for one bucket or for a whole index: # Verify one bucket

$SPLUNK_HOME/bin/splunk check-integrity -bucketPath $SPLUNK_DB/security_audit/db/db_1695427200_1695340800_12 -verbose

  • # Verify every bucket in an index
  • $SPLUNK_HOME/bin/splunk check-integrity -index security_audit -verbose

The command recomputes hashes from the journal and compares them with the stored hash files. A mismatch means the rawdata changed after it was indexed, whether through tampering or corruption.

Regenerating Lost Hash Files

If the hash files for a bucket are lost, Splunk can recreate them from the hashes stored in the journal: $SPLUNK_HOME/bin/splunk generate-hash-files -index security_audit

$SPLUNK_HOME/bin/splunk generate-hash-files -bucketPath <bucket_path>

For stronger protection, Splunk suggests you can also copy hash files to storage outside the indexer, in separate directories to avoid name conflicts. An attacker who controls the indexer then cannot quietly change both the data and its hashes.

An Integrity Check Workflow

A typical audit request ("prove these security events have not been altered") works like this:

Confirm coverage. Check with splunk btool indexes list <index> --debug | grep enableDataIntegrityControl that the index had the setting enabled for the whole audit period. Buckets created before it was enabled carry no hashes.

Run the check on each indexer that holds the index: splunk check-integrity -index <index> . On an indexer cluster, run it on the peers, which hold the bucket copies.

Review the result for each bucket. A bucket whose recomputed hashes match l1Hashes / l2Hash passes. A mismatch identifies the bucket whose rawdata no longer matches what was indexed, and -verbose prints more detail.

Keep evidence. Save the command output with the audit record. If you copied hash files to separate storage, compare them as well, so that a change to both data and hashes on the indexer would still be detected.

What Integrity Control Does Not Cover

Missing buckets: deleting a whole bucket leaves nothing to check. Track bucket inventories, and control who can reach the index directories.

Frozen or archived data: once a bucket is frozen, its protection depends on how and where you archive it.

Data before indexing: hashes describe the rawdata as it was written, after any masking with SEDCMD or transforms. They say nothing about the original source file.

Index files: .tsidx files and metadata are not hashed. They can be rebuilt from rawdata.

Operational Notes

  • Point What to remember
  • Scope Per index, local indexes only (no SmartStore)
  • Default enableDataIntegrityControl = false
  • Slice size 128 KB by default ( rawChunkSizeBytes )
  • Hash files l1Hashes (per slice) and l2Hash (at hot→warm roll), in rawdata/
  • Verify splunk check-integrity -index <name> or -bucketPath <path>
  • Clusters The cluster manager and all peers must run 6.3 or later for accurate replication of hashed buckets
  • In transit Integrity control covers data at rest. Protect forwarder traffic with SSL/TLS

Integrity control also records hashes only for data indexed after you enable it, so turn it on before the audit period you need to defend.