Splunk Security

Splunk Security

by Publications
Network Insight · Security Engineering Guide

Splunk Security: From Telemetry to Detection, Investigation and Automated Response

Modern security operations depend on evidence from many parts of the environment: identity systems, endpoints, networks, cloud platforms, SaaS applications and security controls. The challenge is not simply collecting more events. It is turning fragmented telemetry into context, detecting meaningful patterns, reconstructing what happened, and responding with the right level of automation.

Collect

Bring identity, endpoint, network, cloud, application and security-control telemetry into a common evidence layer.

Correlate

Combine events with identity, asset, threat-intelligence and behavioural context to increase detection confidence.

Investigate

Connect findings to users, devices, applications and timelines so analysts can determine scope and sequence.

Engineering principle: A security event is not automatically a security incident. Useful security intelligence comes from context, correlation, evidence quality and confidence.
Security operations path Telemetry → Detection → Risk → Investigation → Response
01

Security Telemetry: Building the Evidence Layer

Security analytics begins with visibility. This section examines how identity, endpoint, network, cloud, SaaS and application telemetry become a usable evidence layer.

02

Detection and Risk: Turning Events Into Security Findings

Individual events are often weak signals. Detection, enrichment, correlation and risk accumulation help turn those signals into findings that deserve investigation.

03

Security Investigation: Connecting Identity, Endpoint and Network Evidence

Investigation is about reconstructing the story. Analysts connect entities, events and timelines to establish what happened, how far it spread and what evidence is still missing.

04

Security Response: SOAR, Playbooks and Controlled Automation

Response should be proportional to confidence and impact. Orchestration and playbooks can accelerate containment while retaining approvals, guardrails and evidence capture.

Security Operations Architecture

Modern Splunk Security Architecture

A modern security operations workflow can be understood as a continuous pipeline: security telemetry is collected and normalised, detections generate signals, risk is accumulated across entities, analysts investigate the resulting findings, and response actions are coordinated.

The Security Operations Flow — click a stage
→
→
→
→
→
Security Telemetry Sources
Splunk security operations become more useful when signals from different control planes can be correlated around the same entity, asset or incident.
ID
Identity Authentication, privilege and account activity.
ED
Endpoint Processes, malware, devices and host activity.
NW
Network Flows, DNS, firewall and network behaviour.
CL
Cloud Cloud infrastructure, workloads and control-plane events.
SA
SaaS Application and cloud-service activity.
AP
Applications Application logs, transactions and security events.
TI
Threat Intel Indicators, reputation and external intelligence.
SE
Security Tools Firewalls, EDR, IAM and other security controls.
Architecture Stage

Telemetry

Security telemetry provides the evidence used by downstream detection and investigation workflows. The important engineering concept is not simply collecting logs, but connecting signals from different sources so that activity can be interpreted in context.

Identity Endpoint Network Cloud
Engineer's Mental Model
Think of the platform as a security decision pipeline: Telemetry → Detection → Risk → Investigation → Response. A single event may be weak evidence. Multiple related signals associated with the same identity, device, asset or application can provide the context needed to create a higher-confidence security finding.
Security Engineering Guide
Explore the Security Operations Pipeline

Follow the engineering path from raw security telemetry through detection, investigation and controlled response.

01 →
Security Telemetry: Building the Evidence Layer Identity, endpoint, network, cloud, SaaS and application evidence.
02 →
Detection and Risk: Turning Events Into Security Findings Detection, enrichment, correlation and risk accumulation.
03 →
Security Investigation: Connecting Identity, Endpoint and Network Evidence Reconstruct the timeline and determine scope, confidence and impact.
04 →
Security Response: SOAR, Playbooks and Controlled Automation Orchestration, approvals, containment and verification.
TELEMETRY
DETECTION
INVESTIGATION
RESPONSE
01

Security Telemetry: Building the Evidence Layer

A security analytics platform is only as useful as the evidence available to it. Modern environments generate telemetry across identities, endpoints, networks, cloud platforms and applications. The engineering challenge is to make those events searchable, attributable and useful for correlation.

Evidence sources

Identity
Endpoint
Network
Cloud
SaaS
Applications
Security Controls
Engineering principle Raw events become useful security evidence when they can be connected to a time, an entity and meaningful context.
01

Security Telemetry: Building the Evidence Layer

Security operations begin with visibility, but visibility is more than collecting logs. A modern environment produces evidence across identity platforms, endpoints, network devices, cloud services, SaaS applications and security controls. The first engineering task is to bring those signals together in a form that can be searched, correlated and attributed to the correct user, device, application or asset.

What belongs in the telemetry layer?

  • Authentication and identity activity
  • Endpoint processes, files and security events
  • Network connections, DNS and firewall activity
  • Cloud control-plane and workload activity
  • SaaS application access and administrative events
  • Application and infrastructure logs
  • Security-control and detection events

From raw event to usable evidence

Event → Timestamp → Entity → Context → Evidence
Why this matters: telemetry from different systems often describes the same activity from different perspectives. An authentication event may identify the user, endpoint telemetry may show what happened next, and network telemetry may reveal where the endpoint connected. The value comes from being able to connect those observations.
Engineering principle The objective is not maximum log volume. The objective is reliable, attributable and sufficiently contextualised evidence that can support a security decision.
Splunk Security / Detection & Risk Lab

From Security Signals to a Defensible Finding

Step through a realistic security investigation and watch separate telemetry signals become enriched, correlated and accumulated into an entity risk score before an analyst makes a decision.
Ready
Security Analytics Pipeline
0 / 8
◉
Telemetry
Raw events
→
◌
Detect
Analytics
→
✦
Enrich
Context
→
◇
Risk
Entity score
→
◎
Correlate
Related evidence
→
◆
Finding
Analyst ready
Identity
New login from unusual location
Endpoint
New device activity detected
Network
Suspicious outbound connection
Threat Intel
Destination matches known IOC
Engineering principle: an individual event is only a signal. Confidence increases when multiple sources can be associated with the same entity and timeline.
Entity Risk
User + device
0
Current risk
Low
No correlated security evidence yet.
User alex.morgan
Device WKSTN-447
Source IP 185.71.24.18
Destination 203.0.113.72
Security Evidence
Correlated
Unusual authentication
Identity analytics
New endpoint behaviour
Endpoint telemetry
Suspicious network activity
Network telemetry
Threat intelligence match
IOC enrichment
Investigation Timeline
Identity → Endpoint → Network
09:41
IDENTITY
Successful authentication from an unusual source location.
09:43
ENDPOINT
User activity appears on a device not previously associated with the account.
09:44
NETWORK
Endpoint establishes an outbound connection to an unusual destination.
09:45
INTEL
Destination is associated with a known threat intelligence indicator.
09:46
RISK
Related evidence accumulates against the user and device entities.
09:47
CORRELATE
Identity, endpoint and network signals are associated into one investigation.
09:48
FINDING
Risk crosses the investigation threshold and a security finding is created.
09:50
ANALYST
Analyst reviews evidence, scope and confidence before selecting a response.
Analyst Readout
Live interpretation
Current Event
Press Step Forward to begin
Investigation Progress
Analyst Decision
Engineering takeaway: security analytics is most useful when it preserves the relationship between events, entities, time and context.
02

Detection and Risk: Turning Events Into Security Findings

Detection begins when telemetry is evaluated against known patterns, behavioural expectations or threat intelligence. The goal is not to treat every event as an incident, but to combine related signals until the evidence supports a meaningful security finding.

Event ↓
Detection ↓
Enrichment ↓
Risk ↓
Correlation ↓
Finding ✓
Engineering principle: A single weak signal may be harmless. Multiple related signals around the same user, device or asset can produce a much stronger security finding.
02

Detection and Risk: Turning Events Into Security Findings

Once telemetry is available, the next challenge is deciding which activity deserves attention. Detection engineering applies rules, analytics, behavioural patterns and threat intelligence to identify suspicious activity. Risk and correlation then add context so that multiple related signals can be evaluated together instead of treating every event as an independent alert.

Detection sources

Rules
Known malicious or policy-violating patterns.
Behaviour
Activity that deviates from an expected baseline.
Threat Intelligence
Indicators and external security context.
Correlation
Multiple related signals forming a stronger pattern.

Risk changes the question

Instead of asking whether one event is suspicious, a risk-oriented model asks whether several observations collectively increase the likelihood that an entity is involved in malicious activity.

Unusual authentication + new endpoint + suspicious network activity + threat-intelligence match = significantly stronger evidence than any individual event.
Engineering principle Detection should increase confidence rather than simply increase alert volume. Correlation and entity-based risk help distinguish isolated noise from activity that warrants investigation.
Security Investigation Lab / Evidence Correlation
Follow the Evidence. Reconstruct the Attack.
Step through a security finding and watch an analyst connect identity, endpoint, network and threat-intelligence evidence into one investigation timeline.
Ready
Investigation workflow
Finding → Evidence → Timeline → Decision
0 / 10
!
Finding
Security signal
ID
Identity
Who?
EP
Endpoint
What device?
NW
Network
Where did it go?
TI
Threat Intel
Known indicator?
Identity
alex.morgan
Endpoint
LAPTOP-042
Network
203.0.113.42
Current finding
Analyst context
UNVALIDATED
Suspicious authentication sequence
Start the investigation to determine whether the finding has enough supporting evidence to escalate.
Evidence pivots
Select evidence sources
Identity Activity
Authentication / account context
Endpoint Activity
Process / device telemetry
Network Activity
Connection / destination context
Threat Intelligence
Indicator reputation / enrichment
Investigation timeline
Sequence reconstruction
09:41
Authentication anomaly detected
Login pattern differs from the user's normal behaviour.
IDENTITY
09:43
Successful authentication
A successful session follows the anomalous attempt.
IDENTITY
09:44
New endpoint context
The account is associated with an unfamiliar device.
ENDPOINT
09:45
Suspicious process activity
Endpoint telemetry reports an unusual process sequence.
ENDPOINT
09:46
Outbound connection observed
The endpoint establishes an unusual external connection.
NETWORK
09:47
Destination enriched
Network evidence is enriched with threat context.
INTEL
09:49
Entity relationship confirmed
Identity, device and network evidence align.
CORRELATE
09:51
Investigation scope expanded
Analyst pivots from the finding to related entities.
SCOPE
09:54
Evidence sequence reconstructed
The timeline provides a coherent chain of activity.
TIMELINE
09:57
Analyst decision
Determine whether to contain, investigate further or monitor.
DECISION
Live analyst readout
What does the evidence mean?
Current interpretation
Begin by examining the identity signal.
A single alert is rarely enough to establish scope or intent. The investigation becomes stronger as independent evidence sources align.
Evidence
1
Confidence
18%
Engineering principle: investigate relationships between events, not isolated alerts.
Interactive model of an evidence-driven SOC investigation workflow.
STEP 1 / 10
03

Security Investigation: Connecting Identity, Endpoint and Network Evidence

Once a finding has enough confidence to investigate, the analyst needs to reconstruct the sequence of events. That means pivoting across identity, endpoint, network, cloud and threat-intelligence evidence rather than investigating each alert in isolation.

09:41
Identity
Authentication occurs from an unusual location or device.
09:43
Endpoint
Unexpected process or endpoint activity appears.
09:44
Network
The endpoint establishes a suspicious external connection.
09:46
Threat Intel
The destination or indicator receives additional context.
09:48
Decision
The analyst determines scope, confidence and response.
Engineering principle: Investigation is a timeline and relationship problem. The objective is to connect evidence into a defensible story rather than simply close individual alerts.
03

Security Investigation: Connecting Identity, Endpoint and Network Evidence

Detection creates a finding; investigation determines what the finding actually means. Analysts need to move from the finding to the entities involved, reconstruct the timeline, identify related activity and determine whether the available evidence supports escalation or containment.

Investigation pivots

  • Who authenticated or performed the activity?
  • Which device or workload was involved?
  • What happened immediately before and after the event?
  • Which network destinations were contacted?
  • Does threat intelligence add supporting context?
  • Are other users, devices or assets affected?
  • What evidence is still missing?

Reconstructing the incident timeline

09:41
Identity
Unusual authentication observed.
09:43
Endpoint
Unexpected endpoint activity follows.
09:44
Network
External connection is established.
09:46
Intel
Indicator receives additional context.
09:48
Decision
Analyst evaluates scope and response.
Investigation outcome The analyst should be able to explain what happened, which entities are involved, what evidence supports the conclusion, how far the activity may have spread, and what action is justified.
SOC Investigation

Splunk Security Investigation Explorer

A security finding is the beginning of an investigation, not the end. Analysts need to connect identity, endpoint, network, cloud and threat intelligence evidence into a timeline before deciding what happened and what response is appropriate.

Investigation Scenario
Suspicious authentication followed by unusual endpoint activity
A user account generates an unusual authentication signal. Shortly afterwards, the associated endpoint contacts a suspicious destination. Investigate the evidence before deciding whether containment is required.
Analyst Investigation Path — click each evidence area
→
→
→
→
→
Investigation Evidence
The analyst builds context by pivoting between related entities and evidence sources rather than investigating every event independently.
Identity Activity Authentication from an unusual context followed by successful access. USER / IDENTITY
Endpoint Activity New process activity appears shortly after the authentication event. DEVICE
Network Connection The endpoint establishes communication with a suspicious destination. NETWORK
Threat Intelligence The destination can be compared with available intelligence and reputation data. INTELLIGENCE
Entity Relationship Identity, endpoint and network evidence point toward the same investigation. CORRELATION
Analyst Context The analyst determines whether the evidence supports escalation, containment or continued investigation. DECISION
Investigation View

Start With the Finding

The finding provides the initial investigation scope. The analyst should identify the affected entities and then pivot through the available evidence to determine whether the signals form a coherent sequence of suspicious activity.

Finding Entities Scope
Example Investigation Timeline
09:41:12
Authentication User account authenticates from an unusual context.
09:43:08
Endpoint Activity New process activity appears on the associated device.
09:44:21
Network Connection Endpoint contacts a suspicious external destination.
09:46:03
Finding Updated Correlated evidence increases the investigation context.
Investigation Outcome
Evidence is ready for analyst assessment
The investigation has connected identity, endpoint and network observations into a common timeline. The next step is to determine the appropriate response based on the available evidence.
Security Response Lab / SOAR + Controlled Automation
Automate the Response — Without Losing Control
Select response actions, evaluate their blast radius and step through a controlled security playbook from finding to verification.
Awaiting Decision
Response pipeline
Finding → Decision → Playbook → Control → Verify
0 / 8
!
Finding
Validated
D
Decision
Assess risk
P
Playbook
Select actions
E
Execute
Apply controls
V
Verify
Check outcome
R
Record
Capture evidence
+
Enrich Indicators
Low impact · gather additional context
T
Create Incident
Low impact · preserve workflow
ID
Revoke Session
Medium impact · interrupt access
EP
Isolate Endpoint
High impact · contain host
NW
Block Destination
High impact · affect traffic
!
Notify Analyst
Low impact · request approval
Incident context
Response target
HIGH CONFIDENCE
Suspicious account + endpoint activity
Multiple evidence sources have been correlated. The response should reduce risk while preserving enough evidence for investigation.
Risk model
Response confidence
Current risk
82
Automation guardrail: high-impact controls should depend on confidence, blast radius, approval requirements and the ability to verify the outcome.
Playbook execution
Security automation console
10:02
Finding accepted
Validated evidence enters the response workflow.
INPUT
10:03
Response confidence evaluated
Risk and available evidence are assessed.
DECIDE
10:04
Playbook assembled
Selected actions are ordered by impact and dependency.
PLAYBOOK
10:05
Enrichment executed
Indicators and entities receive additional context.
ACTION
10:06
Containment control applied
Selected high-impact controls are executed.
CONTROL
10:07
Outcome verified
Telemetry confirms whether the control achieved its objective.
VERIFY
10:08
Evidence recorded
Actions, results and analyst context are preserved.
AUDIT
10:09
Response completed
Incident moves into follow-up monitoring and recovery.
DONE
Live decision
Why this response?
Current recommendation
Prepare controlled containment
Start with low-impact enrichment and preserve evidence before applying disruptive controls.
Actions
1
Impact
LOW
Interactive model of controlled SOAR-style security automation.
STEP 1 / 8
04

Security Response: SOAR, Playbooks and Controlled Automation

Response automation can reduce analyst workload and shorten containment time, but automation should not mean removing human judgement. Effective security orchestration combines enrichment, decision points, controlled actions and verification.

Finding
Decision
Enrich
Playbook
Control
Verify
Manual Analyst investigates and executes the response.
Approval Automation prepares the action while an analyst authorises it.
Automated High-confidence, low-risk actions execute automatically.
Engineering principle: Automate according to confidence, blast radius and reversibility. The strongest playbooks accelerate response without removing operational control.
04

Security Response: SOAR, Playbooks and Controlled Automation

Investigation should lead to a controlled response when the evidence supports action. Security orchestration and automation can connect findings to enrichment, ticketing, notifications and containment actions, reducing repetitive work while allowing analysts to retain control over high-impact decisions.

Common response actions

  • Enrich indicators with additional intelligence
  • Create or update an incident record
  • Notify security or infrastructure teams
  • Revoke sessions or authentication tokens
  • Isolate a compromised endpoint
  • Block malicious indicators where appropriate
  • Capture evidence for subsequent investigation

Response orchestration

Finding → Decision → Enrich → Playbook → Control → Verify
Manual Analyst performs the response action.
Approval Automation prepares the action for approval.
Automated High-confidence actions execute automatically.
Engineering principle Automation should be proportional to confidence, blast radius and reversibility. A good playbook does not simply act faster; it makes the response more consistent, auditable and controlled.
Detection Engineering

Splunk Security Detection & Risk Engine

Security operations become more powerful when individual events are connected into meaningful signals. Instead of treating every alert as an isolated event, detection and risk analysis can combine evidence around identities, devices and assets before producing a finding for investigation.

From Security Signal to Finding — click each stage
→
→
→
→
Example Evidence
The following signals demonstrate how apparently separate events can contribute to a common investigation.
Unusual Login User authenticates from a location or context that differs from the established pattern.
IDENTITY SIGNAL
New Device Authentication is associated with an endpoint not previously observed for the identity.
DEVICE SIGNAL
Suspicious Network Activity The endpoint communicates with a destination associated with suspicious behaviour.
NETWORK SIGNAL
Threat Intelligence Match An observed indicator matches external threat intelligence.
INTELLIGENCE
Entity Risk
68
Multiple signals are now associated with the same identity and device context.
Detection Stage

Security Signal

A security event or behavioural observation provides the initial evidence. At this point it may not be sufficient to establish that an incident has occurred.

Event Context Evidence
Pipeline Output
Finding ready for investigation
The next stage is analyst investigation: examine the identity, endpoint, network activity, timeline and supporting intelligence.
Security Operations Lab / End-to-End Control Loop
From Signal to Security Decision
Bring telemetry, detection, investigation and response together. Step through the complete operational loop and see how evidence becomes an actionable security decision.
Incident Active
End-to-end security loop
Telemetry → Detection → Investigation → Response → Verification
1 / 9
T
Telemetry
Collect
D
Detection
Identify
R
Risk
Prioritise
I
Investigate
Correlate
A
Act
Respond
V
Verify
Measure
Identity
Evidence available
Endpoint
Evidence available
Network
Awaiting pivot
Cloud / SaaS
Awaiting context
Priority incident
SOC operating picture
INVESTIGATION ACTIVE
Suspicious identity and endpoint sequence
Multiple signals have been associated with the same identity and endpoint. Continue correlation before applying disruptive controls.
Platform health
Operational visibility
Identity telemetry Healthy
Endpoint telemetry Healthy
Network enrichment Partial
Threat intelligence Healthy
SOC event stream
Operational timeline
09:41
Authentication anomaly ingested
Identity telemetry enters the security analytics pipeline.
INPUT
09:43
Detection condition matched
Behaviour differs from the expected authentication pattern.
DETECT
09:44
Risk associated with identity
Related evidence increases the priority of the entity.
RISK
09:46
Endpoint evidence correlated
Endpoint activity aligns with the identity signal.
CORRELATE
09:48
Network pivot initiated
Analyst follows the endpoint into its network relationships.
PIVOT
09:50
Threat context enriched
External intelligence adds context to the destination.
ENRICH
09:53
Response decision approved
Evidence supports a controlled containment path.
DECIDE
09:55
Containment action executed
Selected control is applied to reduce immediate risk.
ACT
09:58
Outcome verified
New telemetry confirms the response changed the observed state.
VERIFY
Live SOC decision
What should happen next?
Current operating decision
Collect and correlate evidence
Do not treat the first alert as the complete incident. Establish relationships between identity, endpoint and network evidence.
Signals
2
Confidence
24%
State
OPEN
Engineering principle: security operations become more effective when telemetry, analytics and response are connected into one measurable control loop.
Interactive model of an evidence-driven security operations control loop.
STEP 1 / 9
```
☕
Support Network Insight
Help support independent engineering guides, interactive networking tools, and future learning labs.
Support Network Insight ```

Splunk Security