Complete Splunk Printable Course
Page 1 of 105
Page 1
Complete Splunk Learning Roadmap
How to study from SIEM fundamentals to advanced administration
1. SIEM Foundations
SIEM concepts
Splunk platform
Install + configure
Onboard data
Search + visualize
Admin + scale
Enterprise Security
Recommended learning method
  • read one page, then reproduce the example in a lab
  • keep a small test index so experiments do not affect production data
  • verify every input with a search before building dashboards or alerts
  • save working SPL and configuration files with clear comments
Page 2
Complete Splunk Learning Roadmap
How to study from SIEM fundamentals to advanced administration — continued
1. SIEM Foundations
Suggested lab machines
RolePurposeExample
Splunk serversearch, index, administrationsplunk-lab
Linux sourcesystem and application logslinux01
Windows sourceevent logs and Sysmonwin01
Version note: The built-in course follows current Splunk Enterprise 10.4 concepts and Splunk Enterprise Security 8.6 terminology. Always confirm requirements for the exact version you install.
Page 3
SIEM Fundamentals
Security information and event management in plain language
1. SIEM Foundations
What a SIEM does
A SIEM centralizes security telemetry, normalizes it, searches it, correlates related activity, and helps analysts investigate and respond. It is not a replacement for firewalls, endpoint protection, identity controls, or backups.
collect
normalize
detect
triage
investigate
respond
improve
Page 4
SIEM Fundamentals
Security information and event management in plain language — continued
1. SIEM Foundations
Core SIEM capabilities
CapabilityQuestion answered
CollectionWhat happened across our systems?
DetectionWhich activity matches risky behaviour?
InvestigationWhat led to the event and what was affected?
ReportingCan we prove monitoring and control effectiveness?
Example: Ten failed logins from one source may be noise. Ten failed logins followed by a successful privileged login is a stronger investigation signal.
Page 5
Security Telemetry Sources
The data a SIEM needs for useful detections
1. SIEM Foundations
High-value sources
SourceUseful events
Identitysign-ins, MFA, account changes, group membership
Endpointprocess creation, file activity, malware alerts
Networkfirewall, DNS, proxy, VPN, IDS/IPS
Cloudcontrol-plane audit, storage access, workload logs
Applicationsauthentication, errors, administrative actions
Page 6
Security Telemetry Sources
The data a SIEM needs for useful detections — continued
1. SIEM Foundations
Onboarding order
  • start with identity, endpoint, firewall, DNS, and critical applications
  • confirm timestamps, host names, user names, and action fields
  • document owner, retention, expected daily volume, and parsing rules
  • map each source to detection and compliance use cases
Quality rule: More logs do not automatically create better security. Correct time, source type, field extraction, and context matter more than raw volume.
Page 7
SOC Workflow and Incident Lifecycle
How analysts use SIEM results
1. SIEM Foundations
alert or finding
validate
scope
contain
eradicate
recover
lessons learned
Typical SOC roles
RoleMain focus
Tier 1 analysttriage and evidence collection
Tier 2 analystdeeper investigation and scoping
Detection engineercontent, tuning, testing, data quality
Incident respondercontainment, eradication, recovery
Page 8
SOC Workflow and Incident Lifecycle
How analysts use SIEM results — continued
1. SIEM Foundations
Triage questions
  • is the activity expected for this user, host, application, and time?
  • is the data complete and trustworthy?
  • what assets or identities are affected?
  • what other events happened before and after?
Page 9
Detection Engineering Basics
Turning risk scenarios into reliable searches
1. SIEM Foundations
Detection design
StepExample
Threat behaviourpassword spraying
Required dataauthentication failures and successes
Logicmany users targeted from one source
Contextapproved scanners, VPN ranges, service accounts
Responsereview source, users, successful logins
Page 10
Detection Engineering Basics
Turning risk scenarios into reliable searches — continued
1. SIEM Foundations
Simple failed-login baseline
index=security action=failure | stats count dc(user) as users values(user) as user_list by src | where count >= 20 AND users >= 5
Tune carefully: Thresholds are starting points, not universal truths. Compare against normal behaviour and document exclusions.
Page 11
What Is Splunk?
From raw machine data to searchable events
2. Splunk Foundation
Platform idea
Splunk Enterprise collects data from files, systems, network feeds, APIs, and applications. It processes the data into events, stores searchable index structures, and lets users search, analyze, visualize, alert, and report.
data source
input
parse
index
search
visualize
act
Page 12
What Is Splunk?
From raw machine data to searchable events — continued
2. Splunk Foundation
Common uses
AreaExample
Securitydetect suspicious authentication
IT operationsfind the cause of an outage
Application supporttrace errors across services
Business analyticsmeasure machine-generated transactions
Page 13
Splunk Products and Deployment Choices
Enterprise, Cloud Platform, Universal Forwarder, and Enterprise Security
2. Splunk Foundation
Product map
ProductMain role
Splunk Enterpriseself-managed platform on your infrastructure
Splunk Cloud PlatformSplunk-managed SaaS platform
Universal Forwarderlightweight collection agent
Enterprise Securitypremium threat detection and investigation solution
SOARsecurity orchestration and automated response
Page 14
Splunk Products and Deployment Choices
Enterprise, Cloud Platform, Universal Forwarder, and Enterprise Security — continued
2. Splunk Foundation
Choose based on
  • data location and regulatory requirements
  • administration skills and staffing
  • scale, availability, and recovery requirements
  • network connectivity and integration needs
Page 15
Events, Fields, and Metadata
The basic language of Splunk data
2. Splunk Foundation
Key terms
TermMeaning
eventone searchable record
fieldname-value information extracted from an event
hostoriginating host value
sourceinput path, stream, or origin
sourcetypeformat and processing rules
indexlogical data store and retention boundary
Inspect metadata
index=main earliest=-15m | table _time host source sourcetype _raw
Page 16
Events, Fields, and Metadata
The basic language of Splunk data — continued
2. Splunk Foundation
Important: The _time field represents event time. The _indextime field represents when Splunk indexed the event. Large differences can indicate delay or timestamp problems.
Page 17
Splunk Architecture Overview
The three main processing tiers
2. Splunk Foundation
data input tier
indexing tier
search management tier
Tier responsibilities
TierTypical componentsWork
InputUniversal or heavy forwarderscollect and forward
Indexingindexersparse when needed, index, store, search
Searchsearch headscoordinate searches and knowledge objects
Page 18
Splunk Architecture Overview
The three main processing tiers — continued
2. Splunk Foundation
Simple distributed architecture
1
Sources
files • APIs • endpoints
2
Forwarders
collect and route
3
Indexers
store and search
4
Search Head
SPL • dashboards • alerts
Page 19
Splunk Component Roles
Forwarders, indexers, search heads, and management nodes
2. Splunk Foundation
Core components
ComponentPurposeKey point
Universal Forwarderlightweight collectionminimal parsing
Heavy Forwardercollection plus parsing/routingfull Splunk instance
Indexerindex, store, and search dataowns buckets
Search Headsearch interface and coordinationholds knowledge objects
Deployment Serverdistribute apps/configurationnot for clustered member bundles
Cluster Managermanage indexer clustercoordinates peers
Page 20
The Splunk Data Pipeline
Input, parsing, indexing, and search
2. Splunk Foundation
input
parsing
indexing
search
What happens
  • input reads data from a monitored source
  • parsing finds event boundaries, timestamps, encoding, and metadata
  • indexing builds searchable structures and writes raw data to buckets
  • search retrieves events and applies search-time knowledge
Forwarder difference: A heavy forwarder can perform substantial parsing before forwarding. A universal forwarder performs minimal parsing, so receiving indexers normally handle the main parsing work.
Page 21
Standalone and Distributed Deployments
How architecture changes as requirements grow
2. Splunk Foundation
Deployment patterns
PatternGood forLimit
Standalonetraining and small proof of conceptsingle failure and scale boundary
Distributedseparate search and indexing rolesmore planning and administration
Indexer clusterdata availability and searchabilityadditional nodes and replication cost
Search head clustersearch tier availability and scalerequires deployer and cluster design
standalone lab
distributed search
indexer cluster
search head cluster
Page 22
Standalone and Distributed Deployments
How architecture changes as requirements grow — continued
2. Splunk Foundation
Design principle: Do not add clustering only because it is advanced. Add it when availability, recovery, scale, or maintenance requirements justify the complexity.
Page 23
Lab Topology and Prerequisites
A safe environment for learning the full platform
3. Planning and Installation
Example lab
HostRoleExample address
splunk01Splunk Enterprise standalone10.10.10.10
linux01Universal Forwarder + sample logs10.10.10.21
win01Universal Forwarder + Windows logs10.10.10.22
Before installing
  • use static addresses or reliable DNS names
  • synchronize time with NTP or the domain time service
  • confirm disk space, file permissions, and firewall paths
  • record the service account and intended data directories
Page 24
Lab Topology and Prerequisites
A safe environment for learning the full platform — continued
3. Planning and Installation
Lab safety: Use synthetic logs or systems you are authorized to monitor. Never point a learning lab at confidential production data.
Page 25
Hardware, Storage, and Filesystem Planning
CPU, memory, IOPS, capacity, and mount points
3. Planning and Installation
Plan for workload
  • daily ingest volume and retention period
  • search concurrency and scheduled searches
  • replication and search factors if clustering
  • storage throughput, latency, and free-space monitoring
Example Linux layout
PathPurpose
/opt/splunksoftware and configuration
/splunkdata/hotwarmactive index buckets
/splunkdata/coldolder searchable buckets
/backup/splunkconfiguration backups
Page 26
Hardware, Storage, and Filesystem Planning
CPU, memory, IOPS, capacity, and mount points — continued
3. Planning and Installation
Basic host checks
df -h lsblk free -h ulimit -n hostname -f timedatectl
Do not guess sizing: Use current Splunk capacity guidance and workload testing for production. A training lab can be small, but production sizing is workload-dependent.
Page 27
Install Splunk Enterprise on Linux
Package or archive installation workflow
3. Planning and Installation
High-level procedure
  • download the correct package for the supported operating system
  • create or use a dedicated non-root service account
  • install under the chosen SPLUNK_HOME path
  • start Splunk, accept the license, and create the administrator account
  • configure boot start and verify Splunk Web
Common TAR workflow
sudo tar -xzf splunk-<version>-Linux-x86_64.tgz -C /opt sudo chown -R splunk:splunk /opt/splunk sudo -u splunk /opt/splunk/bin/splunk start --accept-license sudo /opt/splunk/bin/splunk enable boot-start -user splunk
Use placeholders: Replace package names and paths with the exact values for your approved version. Confirm current supported operating systems before production installation.
Page 28
Install Splunk Enterprise on Windows
MSI installation and service-account decisions
3. Planning and Installation
Installation choices
  • interactive MSI or command-line MSI deployment
  • Local System or a managed service account
  • installation folder and data location
  • administrator credentials and service startup
Example silent-install pattern
msiexec.exe /i splunk-<version>-x64-release.msi AGREETOLICENSE=Yes /quiet
Page 29
Install Splunk Enterprise on Windows
MSI installation and service-account decisions — continued
3. Planning and Installation
After installation
CheckExpected
ServiceSplunkd Service is running
Webhttp://localhost:8000 opens
CLI%SPLUNK_HOME%\bin\splunk.exe status
Logs%SPLUNK_HOME%\var\log\splunk
Permissions: The Windows service identity needs permission to read every file, registry object, or event channel that you configure as an input.
Page 30
First Start, CLI, and Service Control
Essential commands for daily administration
3. Planning and Installation
Common commands
TaskCommand
Status$SPLUNK_HOME/bin/splunk status
Start$SPLUNK_HOME/bin/splunk start
Stop$SPLUNK_HOME/bin/splunk stop
Restart$SPLUNK_HOME/bin/splunk restart
Version$SPLUNK_HOME/bin/splunk version
Validate config$SPLUNK_HOME/bin/splunk btool check
Inspect effective configuration
$SPLUNK_HOME/bin/splunk btool inputs list --debug $SPLUNK_HOME/bin/splunk btool outputs list --debug
Page 31
First Start, CLI, and Service Control
Essential commands for daily administration — continued
3. Planning and Installation
Why btool matters: btool shows merged configuration and the file that supplied each value. It is one of the best tools for resolving precedence problems.
Page 32
Splunk Filesystem and Directory Structure
Where binaries, configuration, apps, logs, and indexes live
3. Planning and Installation
Important paths
Path under SPLUNK_HOMEContains
binCLI and executables
etc/systemsystem-wide configuration
etc/appsapps and app-scoped configuration
etc/deployment-appsdeployment server content
var/log/splunkinternal Splunk logs
var/lib/splunkdefault index storage
var/run/splunkruntime files
Useful filesystem checks
du -sh $SPLUNK_HOME/var/lib/splunk/* find $SPLUNK_HOME/etc -name "*.conf" tail -f $SPLUNK_HOME/var/log/splunk/splunkd.log
Page 33
Splunk Filesystem and Directory Structure
Where binaries, configuration, apps, logs, and indexes live — continued
3. Planning and Installation
Windows path: On Windows, SPLUNK_HOME is commonly C:\Program Files\Splunk unless another path was selected.
Page 34
Configuration Files and Precedence
Default, local, and app layering
3. Planning and Installation
system/default
app/default
app/local
system/local
Rules to remember
  • never edit files in system/default
  • place durable changes in a local directory
  • define only the settings you need to override
  • use btool with --debug to see the winning value and source file
Example local file
$SPLUNK_HOME/etc/apps/my_inputs/local/inputs.conf [monitor:///var/log/myapp/app.log] index = app sourcetype = myapp:log
Page 35
Configuration Files and Precedence
Default, local, and app layering — continued
3. Planning and Installation
App organization: Use purpose-built apps to package related inputs, parsing rules, indexes, and knowledge objects instead of placing everything in system/local.
Page 36
Important Splunk .conf Files
A practical configuration map
3. Planning and Installation
Configuration map
FilePurpose
inputs.confdefine monitored data inputs
outputs.confforward data and load-balance targets
props.confsource type, timestamps, line breaking, search-time rules
transforms.confregex transforms, routing, field extraction
indexes.confindexes, paths, retention
server.confinstance and server behaviour
web.confSplunk Web settings
limits.confsearch and platform limits
authentication.confauthentication configuration
Page 37
Important Splunk .conf Files
A practical configuration map — continued
3. Planning and Installation
Restart or reload?: Some settings reload dynamically; others require a restart. Check the configuration reference for each setting and use controlled change procedures.
Page 38
Splunk Ports and Firewall Matrix
Default and conventional component communication
3. Planning and Installation
Core ports
PortProtocolPurpose
8000TCPSplunk Web
8089TCPmanagement and REST API
9997TCPforwarder-to-receiver data
8088TCPHTTP Event Collector
8065 / 8191TCPsearch-head app server and KV Store
8081 / 9887 / 8181TCPsearch head cluster communication
8080 / 9887TCPindexer cluster communication
Page 39
Splunk Ports and Firewall Matrix
Default and conventional component communication — continued
3. Planning and Installation
Infrastructure dependencies
  • 53 DNS, 123 NTP, and directory-service ports as required
  • 443 for approved HTTPS services and downloads
  • 514 is commonly used for syslog, but low ports need special OS privileges
Firewall rule design: Document source, destination, port, protocol, encryption, owner, and business purpose. Open only the paths required by your topology.
Page 40
Secure Base Configuration
Time, DNS, TLS, service accounts, and least privilege
3. Planning and Installation
Baseline controls
  • use accurate DNS and synchronized time
  • run services with dedicated least-privilege accounts
  • replace default certificates and protect private keys
  • restrict management interfaces to administrative networks
  • use role-based access and separate human from service identities
  • send Splunk audit and health events to protected monitoring
Time and identity checks
hostname -f timedatectl status id splunk ss -lntp | grep -E "8000|8089|9997|8088"
Encryption: Use TLS 1.2 or higher where supported and follow your organization’s certificate lifecycle and secret-management standards.
Page 41
Indexes, Buckets, and Retention
How Splunk stores searchable data
4. Data Storage and Onboarding
hot
warm
cold
frozen
deleted or archived
Bucket states
StateTypical characteristic
Hotactively written
Warmread-only and frequently searched
Coldolder searchable data
Frozenaged out; delete or archive policy
Thawedmanually restored archived data
Page 42
Indexes, Buckets, and Retention
How Splunk stores searchable data — continued
4. Data Storage and Onboarding
Example indexes.conf
[security] homePath = $SPLUNK_DB/security/db coldPath = $SPLUNK_DB/security/colddb thawedPath = $SPLUNK_DB/security/thaweddb frozenTimePeriodInSecs = 7776000
Retention: Retention can be limited by time or storage. Monitor both so data does not expire earlier than expected.
Page 43
Data Input Methods
Files, forwarders, APIs, HEC, network inputs, and add-ons
4. Data Storage and Onboarding
Choose the right input
MethodGood use
File monitorlocal or mounted log files
Universal Forwarderendpoint and server collection
HTTP Event Collectorapplications and structured HTTP events
TCP/UDP inputnetwork streams and syslog relays
API/modular inputcloud and SaaS data
Technology Add-onsupported collection and field normalization
Preferred pattern: For syslog, use a resilient syslog service to receive and write files, then monitor those files with a forwarder. This separates network reception from Splunk restarts.
Page 44
Universal Forwarder on Linux
Install, monitor a file, and connect to a receiver
4. Data Storage and Onboarding
Install and start
sudo tar -xzf splunkforwarder-<version>-Linux-x86_64.tgz -C /opt sudo chown -R splunkfwd:splunkfwd /opt/splunkforwarder sudo -u splunkfwd /opt/splunkforwarder/bin/splunk start --accept-license
Add a monitored file
/opt/splunkforwarder/bin/splunk add monitor /var/log/auth.log \ -index security -sourcetype linux_secure
Add receiving target
/opt/splunkforwarder/bin/splunk add forward-server splunk01:9997
Verify: Search for the host and sourcetype, then inspect splunkd.log and metrics.log if events do not arrive.
Page 45
Universal Forwarder on Windows
Collect Windows Event Logs and application files
4. Data Storage and Onboarding
Example inputs.conf
[WinEventLog://Security] disabled = 0 index = security renderXml = true [monitor://C:\Apps\MyApp\logs\*.log] disabled = 0 index = app sourcetype = myapp:log
Check permissions
  • service identity can read requested event channels
  • service identity can read application folders
  • Windows Firewall allows outbound receiver and management paths
  • host time and domain identity are correct
Page 46
Configure Receiving and Forwarding
Receiver port, outputs.conf, and load balancing
4. Data Storage and Onboarding
Enable receiver
$SPLUNK_HOME/bin/splunk enable listen 9997
Example outputs.conf
[tcpout] defaultGroup = primary_indexers [tcpout:primary_indexers] server = idx01:9997, idx02:9997 autoLBFrequency = 30 [tcpout-server://idx01:9997]
forwarder
idx01:9997
or
idx02:9997
Production: Configure TLS, certificate validation, and appropriate acknowledgement or queue settings according to your reliability design.
Page 47
Deployment Server and Server Classes
Centrally distribute forwarder apps
4. Data Storage and Onboarding
deployment app
server class
deployment client
app installed
Concepts
ObjectMeaning
Deployment appconfiguration bundle stored on the server
Server classrules that select clients and assign apps
Deployment clientinstance that phones home for updates
Phone-homeperiodic configuration check
Client target example
$SPLUNK_HOME/bin/splunk set deploy-poll ds01:8089
Page 48
Deployment Server and Server Classes
Centrally distribute forwarder apps — continued
4. Data Storage and Onboarding
Cluster warning: Do not use deployment server to push configuration directly to indexer-cluster peers or search-head-cluster members. Use the cluster manager bundle or search-head deployer.
Page 49
Host, Source, Sourcetype, and Index
Four metadata choices that control usability
4. Data Storage and Onboarding
Metadata design
FieldQuestion
hostWhich system produced the event?
sourceWhich file, stream, or input produced it?
sourcetypeHow should this format be interpreted?
indexWhere is it stored and how is access/retention managed?
Quality summary
index=* earliest=-24h | stats count min(_time) as first max(_time) as last by index sourcetype host | convert ctime(first) ctime(last)
Page 50
Host, Source, Sourcetype, and Index
Four metadata choices that control usability — continued
4. Data Storage and Onboarding
Sourcetype rule: Reuse a source type only when data has the same structure and processing requirements. Do not create a unique source type for every individual host.
Page 51
Event Breaking and Timestamp Parsing
Make one real-world event equal one Splunk event
4. Data Storage and Onboarding
Example props.conf
[myapp:multiline] SHOULD_LINEMERGE = false LINE_BREAKER = ([\r\n]+)(?=\d{4}-\d{2}-\d{2}) TIME_PREFIX = ^ TIME_FORMAT = %Y-%m-%d %H:%M:%S MAX_TIMESTAMP_LOOKAHEAD = 19
Validate
  • one event begins and ends at the correct location
  • _time matches the timestamp inside the event
  • timezone is correct and consistent
  • large or malformed events are not truncated
Delay check
index=myindex earliest=-24h | eval delay=_indextime-_time | stats perc50(delay) perc95(delay) max(delay) by sourcetype
Page 52
props.conf and transforms.conf
Parsing, routing, masking, and field extraction
4. Data Storage and Onboarding
Route matching events
props.conf [myapp:log] TRANSFORMS-route = route_errors transforms.conf [route_errors] REGEX = level=ERROR DEST_KEY = _MetaData:Index FORMAT = app_errors
Page 53
props.conf and transforms.conf
Parsing, routing, masking, and field extraction — continued
4. Data Storage and Onboarding
Search-time extraction
props.conf [myapp:log] REPORT-myfields = myapp_fields transforms.conf [myapp_fields] REGEX = user=(\S+) action=(\S+) FORMAT = user::$1 action::$2
Test before deployment: Apply parsing changes to sample data first. Incorrect index-time rules can require re-ingestion to correct historical events.
Page 54
HTTP Event Collector
Token-based HTTP ingestion for applications
4. Data Storage and Onboarding
application
HTTPS request
HEC :8088
indexer or heavy forwarder
index
Example request
curl -k https://splunk01:8088/services/collector/event \ -H "Authorization: Splunk <HEC_TOKEN>" \ -d '{"event":{"action":"login","status":"success"}, "sourcetype":"app:json","index":"app"}'
Production checklist
  • use HTTPS and validate certificates
  • protect and rotate tokens
  • limit token indexes and source types
  • monitor HEC health, queues, and rejected events
Page 55
Syslog and Network Inputs
Reliable collection of firewall, network, and appliance events
4. Data Storage and Onboarding
device
syslog relay
rotated files
forwarder
Splunk
Monitor relay files
[monitor:///var/log/remote/firewall/*.log] index = network sourcetype = vendor:firewall host_segment = 4
Reliability controls
  • use TCP or encrypted syslog when supported
  • write to disk before forwarding
  • separate vendors or formats into predictable paths
  • configure rotation so files are not lost or reread
Page 56
Windows Data Sources
Event Logs, Active Directory, PowerShell, and Sysmon
4. Data Storage and Onboarding
Useful channels
Channel/sourceUse
Securityauthentication and account activity
Systemservice and operating system events
PowerShell Operationalscript and engine activity
Sysmonenhanced process, network, and file telemetry
Active Directorydirectory changes where configured
Quick source check
index=security host=win01 earliest=-1h | stats count by source sourcetype EventCode | sort - count
Page 57
Windows Data Sources
Event Logs, Active Directory, PowerShell, and Sysmon — continued
4. Data Storage and Onboarding
Volume: Enable only the channels and audit policies required by your use cases, then measure event volume and detection value.
Page 58
Linux and Application Data Sources
System logs, audit data, web logs, and custom applications
4. Data Storage and Onboarding
Common paths
DataExample path
Authentication/var/log/auth.log or /var/log/secure
System/var/log/syslog or /var/log/messages
Audit/var/log/audit/audit.log
Web/var/log/nginx/access.log
Application/opt/myapp/logs/app.log
Search by source
index=linux earliest=-30m | stats count values(sourcetype) by host source | sort host source
Page 59
Linux and Application Data Sources
System logs, audit data, web logs, and custom applications — continued
4. Data Storage and Onboarding
Permissions: Grant the forwarder service the minimum read permissions required. Do not run as root only to avoid designing proper access.
Page 60
Data Quality Validation
Prove that ingestion is complete, timely, and searchable
4. Data Storage and Onboarding
Quality dimensions
DimensionTest
Completenessexpected hosts and sources are present
Timeliness_indextime minus _time is acceptable
Parsingevent boundaries and timestamps are correct
Consistencyfields use stable names and values
Volumecounts match source expectations
Page 61
Data Quality Validation
Prove that ingestion is complete, timely, and searchable — continued
4. Data Storage and Onboarding
Host heartbeat search
index=security earliest=-15m | stats latest(_time) as last count by host sourcetype | eval age=now()-last | where age > 600 | convert ctime(last)
Acceptance record: For every new source, save sample events, expected volume, owners, field checks, and the searches used to validate it.
Page 62
SPL Search Fundamentals
Search terms, pipes, commands, and result transformation
5. Search Processing Language
Basic pattern
index=security action=failure | stats count by user | sort - count
Read left to right
  • the base search retrieves matching events
  • each pipe sends results to the next command
  • commands filter, calculate, format, enrich, or visualize
  • start narrow with index, source type, time, and meaningful terms
Performance habit: Filter early, request only needed time ranges, and avoid searching every index unless the task truly requires it.
Page 63
Time, Boolean Logic, and Wildcards
Control when and what Splunk searches
5. Search Processing Language
Examples
index=web earliest=-60m latest=now status>=500 index=security (action=failure OR action=blocked) NOT user="healthcheck" index=app host=web* source="*/access.log"
Time examples
ModifierMeaning
earliest=-15mlast fifteen minutes
earliest=@dfrom start of today
earliest=-7d@dfrom start of day seven days ago
latest=@hup to start of current hour
Page 64
Fields, table, fields, sort, and dedup
Shape event results for investigation
5. Search Processing Language
Investigation view
index=security action=failure | table _time user src dest action reason | sort 0 - _time
Latest event per user
index=security | sort 0 - _time | dedup user | fields _time user src action
Command roles
  • table creates an ordered result table
  • fields includes or removes fields
  • sort controls order; 0 prevents a small default limit
  • dedup retains selected unique combinations
Page 65
stats, chart, timechart, top, and rare
Transform events into useful summaries
5. Search Processing Language
Counts by action
index=security | stats count dc(user) as users by action
Trend over time
index=web status>=500 | timechart span=5m count by status limit=10
Most common sources
index=security | top limit=10 src
Choose the output: Use stats for flexible tables, chart for categorical matrices, and timechart when time is the horizontal dimension.
Page 66
eval, where, case, and coalesce
Create fields and express decision logic
5. Search Processing Language
Risk band example
index=security | stats count as failures dc(user) as users by src | eval risk_score=failures + (users*5) | eval risk_band=case(risk_score>=100,"high", risk_score>=50,"medium", true(),"low") | where risk_score>=50
Normalize a user field
... | eval user=coalesce(user, user_name, account, src_user)
Difference: eval creates or changes fields. where filters using expressions and field-to-field comparisons.
Page 67
rex, regex, and spath
Extract and filter structured or semi-structured data
5. Search Processing Language
Regex extraction
index=app sourcetype=myapp:log | rex field=_raw "user=(?<user>\S+) action=(?<action>\S+)" | stats count by user action
JSON extraction
index=app sourcetype=app:json | spath | table _time user.name request.path response.status
Regex filter
... | regex process_name="(?i)(powershell|pwsh)\.exe$"
Page 68
Lookups and Enrichment
Add asset, identity, ownership, and allow-list context
5. Search Processing Language
Asset enrichment
index=security | lookup assets.csv host OUTPUT owner criticality environment | table _time host owner criticality action
Create a small lookup
| inputlookup approved_scanners.csv | table src description owner
Page 69
Lookups and Enrichment
Add asset, identity, ownership, and allow-list context — continued
5. Search Processing Language
Good lookup fields
ContextExamples
Assetowner, criticality, environment
Identitydepartment, manager, privilege
Networksite, zone, approved scanner
Threat intelindicator, type, confidence, expiry
Page 70
Subsearches, append, and Safer Alternatives
Combine datasets without unnecessary cost
5. Search Processing Language
Subsearch example
index=security action=success [ search index=security action=failure earliest=-30m | stats count by user | where count>10 | fields user ]
Append totals
index=web status>=500 | stats count by host | append [ search index=web status>=400 status<500 | stats count by host ]
Performance: Subsearches have result and time limits. Prefer stats, eventstats, lookups, or data models when they can solve the problem more directly.
Page 71
eventstats, streamstats, and transaction
Context across related events
5. Search Processing Language
Compare to user average
index=auth | eventstats avg(duration) as user_avg by user | eval ratio=duration/user_avg | where ratio>3
Running count
index=auth action=failure | sort 0 user _time | streamstats count as running_failures by user
Transaction example
index=app (action=start OR action=end) | transaction session_id startswith="action=start" endswith="action=end"
Use transaction carefully: transaction is convenient but can be expensive. stats is often more scalable for grouping related events.
Page 72
Knowledge Objects
Reusable meaning added at search time
5. Search Processing Language
Objects
ObjectPurpose
Field extractionderive searchable fields
Event typename a reusable search condition
Tagattach common semantic labels
Lookupenrich events with external context
Macroreuse SPL fragments
Calculated fieldcreate a reusable eval expression
Workflow actionlink results to another action
Ownership: Document app, owner, sharing, permissions, naming convention, and dependencies for production knowledge objects.
Page 73
CIM and Data Models
Normalize different vendors into common security concepts
5. Search Processing Language
Why normalization matters
The Common Information Model provides shared field and dataset conventions so searches and security content can work across multiple technologies.
Example normalization
Vendor fieldCIM-style field
source_ipsrc
destination_ipdest
usernameuser
resultaction
bytes_sentbytes_out
Page 74
CIM and Data Models
Normalize different vendors into common security concepts — continued
5. Search Processing Language
Check normalized fields
index=security tag=authentication | stats count by action user src dest
Acceleration: Accelerated data models improve certain searches but consume compute and storage. Accelerate only models needed by your use cases.
Page 75
Reports, Dashboards, and Alerts
Turn searches into reusable operational content
5. Search Processing Language
validated SPL
saved report
dashboard panel
scheduled alert
response
Choose the object
NeedUse
repeatable analysisreport
visual statusdashboard
notify on a conditionalert
summarized reusable datasetsummary index or data model
Page 76
Reports, Dashboards, and Alerts
Turn searches into reusable operational content — continued
5. Search Processing Language
Alert quality
  • clear owner and response procedure
  • reasonable schedule and time window
  • suppression or grouping to prevent duplicates
  • severity based on asset, identity, and behaviour context
Page 77
Users, Roles, and RBAC
Least-privilege access to data and capabilities
6. Administration and Scale
Role controls
ControlExample
Indexesallowed and default indexes
Capabilitiesschedule searches or edit inputs
Search limitsconcurrency and workload limits
Inheritancereuse permissions from base roles
Knowledge objectsread, write, or share by app
Good practice
  • integrate approved identity providers where appropriate
  • use roles instead of assigning permissions one user at a time
  • separate administrators, power users, analysts, and viewers
  • review inactive accounts, tokens, and excessive capabilities
Page 78
Monitoring Console and Health
Observe indexing, searching, queues, and component status
6. Administration and Scale
Watch these areas
AreaSignals
Indexingthroughput, blocked queues, bucket activity
Searchconcurrency, skipped searches, runtimes
Forwardersphone-home and data freshness
ResourcesCPU, memory, disk usage, I/O
Platformsplunkd health and component warnings
Internal error trend
index=_internal sourcetype=splunkd log_level=ERROR earliest=-24h | timechart span=15m count by component limit=10
Page 79
Monitoring Console and Health
Observe indexing, searching, queues, and component status — continued
6. Administration and Scale
Baseline: Record normal ingestion, search concurrency, and resource levels before an incident. A baseline makes abnormal behaviour easier to identify.
Page 80
Internal Indexes and Troubleshooting Logs
Where Splunk explains what it is doing
6. Administration and Scale
Useful internal data
Source/indexUse
_internal / splunkd.logservice, input, forwarding, parsing errors
_internal / metrics.logthroughput and queue metrics
_audituser and administrative actions
_introspectionresource and process information
scheduler.logscheduled search execution
Find recent warnings
index=_internal sourcetype=splunkd (log_level=WARN OR log_level=ERROR) | table _time host component log_level message | sort 0 - _time
Page 81
Troubleshooting Data Ingestion
A repeatable end-to-end checklist
6. Administration and Scale
source writes
input reads
queue moves
network connects
receiver accepts
index stores
search finds
Checks
  • confirm the source file or API actually produces events
  • verify permissions and inputs.conf with btool
  • check fishbucket behaviour for monitored files
  • test DNS, route, firewall, and receiver port
  • inspect splunkd.log and metrics.log on sender and receiver
  • search the correct index, host, source type, and time range
Connection check
nc -vz splunk01 9997 $SPLUNK_HOME/bin/splunk list forward-server
Page 82
Licensing, Retention, Backup, and Upgrade
Operational lifecycle essentials
6. Administration and Scale
Area
AreaPlan
Licensedaily ingest or workload entitlement and warning process
Retentiontime, storage, legal, and business requirements
Backupconfiguration, apps, lookup data, cluster metadata
Upgradesupported path, compatibility, test, rollback
Recoveryrestore order, credentials, certificates, validation
Page 83
Licensing, Retention, Backup, and Upgrade
Operational lifecycle essentials — continued
6. Administration and Scale
Before upgrade
  • review release notes and known issues
  • confirm app and add-on compatibility
  • back up configuration and custom content
  • test in non-production and document rollback
  • upgrade distributed components in the supported order
Page 84
Indexer Cluster Architecture
Replication, searchability, and bucket management
6. Administration and Scale
Single-site cluster
1
Cluster Manager
coordinates peers
2
Peer 1
primary + replicated buckets
3
Peer 2
primary + replicated buckets
4
Peer 3
primary + replicated buckets
Cluster terms
TermMeaning
Replication factornumber of bucket copies
Search factornumber of searchable copies
Peer nodeindexer participating in the cluster
Cluster managercoordinates configuration and bucket state
Page 85
Indexer Cluster Architecture
Replication, searchability, and bucket management — continued
6. Administration and Scale
Capacity: Replication increases storage and network requirements. Design factors around failure domains, recovery objectives, and search availability.
Page 86
Search Head Cluster Architecture
Highly available search and knowledge management
6. Administration and Scale
Search tier
1
Deployer
distributes app bundles
2
SH member 1
search + UI
3
SH member 2
search + UI
4
SH member 3
search + UI
5
Load balancer
user access
Key concepts
ConceptPurpose
Captaincoordinates cluster activities
Memberserves users and searches
Deployerdistributes apps and configuration
KV Storereplicated application data where used
Page 87
Search Head Cluster Architecture
Highly available search and knowledge management — continued
6. Administration and Scale
Consistency: Use the deployer for cluster app bundles. Avoid manual configuration changes that create differences between members.
Page 88
Management Components and Configuration Distribution
Use the correct tool for each component
6. Administration and Scale
Component mapping
TargetManagement method
Universal forwardersdeployment server / agent management
Heavy forwardersdeployment server where supported
Indexer cluster peerscluster manager configuration bundle
Search head cluster memberssearch head cluster deployer
Standalone serverlocal app or configuration management
source-controlled app
review
test
approved distributor
target components
validation
Page 89
Management Components and Configuration Distribution
Use the correct tool for each component — continued
6. Administration and Scale
Change control: Store custom apps and configuration in version control. Promote the same tested artifact through environments instead of rebuilding changes manually.
Page 90
Splunk Enterprise Security Fundamentals
Threat detection, investigation, and response on the Splunk platform
7. Enterprise Security and Use Cases
What ES adds
Splunk Enterprise Security builds security workflows on the Splunk platform, combining detection content, findings, investigations, risk, threat intelligence, dashboards, and response integrations.
normalized data
detection
finding
finding group
investigation
response
Page 91
Splunk Enterprise Security Fundamentals
Threat detection, investigation, and response on the Splunk platform — continued
7. Enterprise Security and Use Cases
Foundation
NeedDependency
Reliable detectionscomplete and normalized telemetry
Useful triageasset and identity context
Risk scoringconsistent risk objects and modifiers
Automationtested actions, permissions, and safeguards
Page 92
Mission Control, Findings, and Investigations
The analyst workflow in Enterprise Security
7. Enterprise Security and Use Cases
Analyst workflow
  • review the finding or finding group
  • validate entities, time, detection logic, and supporting events
  • open or update an investigation
  • record evidence, decisions, and response actions
  • close with a clear disposition and tuning feedback
Page 93
Mission Control, Findings, and Investigations
The analyst workflow in Enterprise Security — continued
7. Enterprise Security and Use Cases
Triage context
EntityHelpful context
Userdepartment, privilege, MFA, recent sign-ins
Hostowner, criticality, vulnerability, endpoint status
IPzone, reputation, VPN, approved scanner
Processparent, command line, signer, hash
Page 94
Security Content and Detection Lifecycle
Build, test, deploy, monitor, and tune
7. Enterprise Security and Use Cases
use case
data requirement
SPL
unit test
pilot
production
measure
tune
Detection record
FieldExample
NameMany failed logins across users
Dataauthentication events
Logicone source targets many accounts
Exclusionsapproved scanner and test tenant
Responsereview successes and affected identities
Metricprecision, volume, time to triage
Page 95
Risk-Based Alerting
Combine weaker signals into higher-confidence investigations
7. Enterprise Security and Use Cases
behaviour 1
risk event
behaviour 2
risk event
risk threshold
finding
Conceptual risk summary
index=risk | stats sum(risk_score) as total_risk values(search_name) as reasons by risk_object risk_object_type | where total_risk >= 100 | sort - total_risk
Design rules
  • assign risk to stable objects such as user or system
  • make score reflect severity and confidence
  • use context modifiers for privilege and criticality
  • expire or window risk so old activity does not dominate forever
Page 96
Threat Intelligence and Observable Enrichment
Use indicators with confidence, context, and expiry
7. Enterprise Security and Use Cases
Indicator fields
FieldWhy
IndicatorIP, domain, URL, hash, or other observable
Typedetermines matching logic
Confidencehelps prioritize
Sourcesupports trust and review
First/last seenprovides time context
Expiryprevents stale matches
Page 97
Threat Intelligence and Observable Enrichment
Use indicators with confidence, context, and expiry — continued
7. Enterprise Security and Use Cases
Simple lookup match
index=network | lookup threat_intel_ip indicator as dest_ip OUTPUT confidence description | where isnotnull(confidence) | table _time src_ip dest_ip confidence description
Page 98
Use Case: Password Spray
Detect one source failing across many accounts
7. Enterprise Security and Use Cases
Detection search
index=security action=failure earliest=-15m | stats count dc(user) as targeted_users values(user) as users by src | where count>=20 AND targeted_users>=10
Follow-up for successes
index=security src=<SOURCE_IP> action=success earliest=-30m | table _time user src dest app
Triage
  • is the source an approved scanner, proxy, or identity provider?
  • did any targeted account later authenticate successfully?
  • are privileged or high-value accounts included?
  • does the pattern span multiple applications or locations?
Page 99
Use Case: Suspicious PowerShell
Investigate encoded or unusual script execution
7. Enterprise Security and Use Cases
Defensive search example
index=security sourcetype=XmlWinEventLog:* EventCode=4104 | eval script=coalesce(ScriptBlockText, Message) | where match(script,"(?i)(-enc|-encodedcommand|downloadstring|frombase64string)") | table _time host user script
Enrich with
  • process parent and full command line
  • script signer or file hash
  • network destinations and downloaded files
  • user privilege and endpoint criticality
Tune: Administrative tools can use similar strings. Validate expected automation and focus on unusual users, parents, destinations, or unsigned content.
Page 100
Use Case: Web Attack Indicators
Find abnormal error patterns without teaching exploitation
7. Enterprise Security and Use Cases
Error spike
index=web earliest=-30m status>=400 | timechart span=5m count by status limit=10
Repeated targeting
index=web status IN (401,403,404) earliest=-15m | stats count dc(uri_path) as paths values(uri_path) as examples by src_ip | where count>=100 AND paths>=20
Triage
  • compare source reputation and normal traffic patterns
  • review requested paths without executing or visiting suspicious content
  • check WAF, proxy, endpoint, and application events
  • look for successful responses after the failed attempts
Page 101
Use Case: Possible Data Exfiltration
Detect unusual outbound volume with context
7. Enterprise Security and Use Cases
Outbound volume anomaly
index=network action=allowed earliest=-24h | stats sum(bytes_out) as bytes_out dc(dest_ip) as destinations by user src_host | eventstats avg(bytes_out) as avg stdev(bytes_out) as sd | where bytes_out > avg + (3*sd) | sort - bytes_out
Triage
  • convert bytes to readable units and compare to the user baseline
  • identify destination ownership, geography, and business purpose
  • review file, endpoint, proxy, cloud, and identity context
  • confirm approved backup, synchronization, or software distribution activity
Page 102
Capstone Lab: Build a Small SIEM
End-to-end deployment and validation checklist
7. Enterprise Security and Use Cases
Lab phases
PhaseDeliverable
Plantopology, ports, accounts, storage, use cases
InstallSplunk server and two forwarders
OnboardLinux auth, Windows Security, and web sample data
Validatetime, metadata, fields, volume, freshness
Searchthree investigation searches
Visualizeone dashboard and one scheduled report
Detectone tuned failed-login alert
Operatehealth search, backup, and change record
Page 103
Capstone Lab: Build a Small SIEM
End-to-end deployment and validation checklist — continued
7. Enterprise Security and Use Cases
Final evidence
  • architecture and firewall diagram
  • configuration app folders
  • sample events and validation searches
  • screenshots or exports of dashboard and alert
  • troubleshooting notes and lessons learned
Page 104
Splunk Quick Reference
Commands, paths, ports, and verification searches
8. Reference
Daily commands
NeedExample
Service statussplunk status
Effective configsplunk btool <file> list --debug
Forward targetssplunk list forward-server
Recent errorsindex=_internal log_level=ERROR
Ingest by source type| tstats count where index=* by index sourcetype
Data freshness| stats latest(_time) by host sourcetype
Page 105
Splunk Quick Reference
Commands, paths, ports, and verification searches — continued
8. Reference
Core ports
PortUse
8000Web
8089Management / REST
9997Forwarded data
8088HEC
8191KV Store
9887Cluster replication
Study finish: Rebuild the capstone from an empty lab without copying commands blindly. Explain why each component, port, configuration file, and search is required.