Splunk Certified Cybersecurity Defense Analyst cheat sheet

SIEM core functions: collect and normalize logs, retain them for investigation, correlate events into alerts, and provide search/reporting across all sources.

SOC escalation model: Tier 1 = monitor and triage notables, Tier 2 = full investigation and scoping, Tier 3 = threat hunting, detection engineering, and incident response.

Splunk indexing pipeline order: inputs (universal/heavy forwarders, HEC, scripted inputs) -> parsing (props.conf, transforms.conf) -> indexing (indexes.conf) -> search-time knowledge objects.

Default (indexed) fields available without parsing: host, source, sourcetype, index, _time, _indextime, _raw, linecount, splunk_server.

CIM normalization relies on field aliases, calculated fields, event types, and tags so that one correlation search matches multiple vendor sourcetypes.

In Splunk ES a correlation search that fires writes a notable event to the notable index with fields including rule_name, urgency, severity, status, owner, and _time.

Detection coverage is described by mapping enabled correlation searches to MITRE ATT&CK tactics and techniques; gaps appear as techniques with no mapped rule.

Key SOC metrics: MTTD (alert _time minus earliest relevant event _time) and MTTR (containment time minus detection time); both are computed from notable and incident timestamps.

RBA formula: each detection contributes an independent risk event with risk_score points; an alert fires only when the summed score for a risk_object crosses the risk threshold within the scoring window.

Risk event required fields: risk_object (the entity at risk), risk_object_type (user, system, or other), risk_score, and a search_name/rule attribution field.

Splunk ES stores risk events in the risk index and generated risk notables in the risk_notable index; both are separate from the notable index used by classic correlation searches.

Risk factors multiply the contribution of a detection: effective score = base risk_score * risk factor priority for that asset or identity, letting high-value entities hit thresholds sooner.

Threat objects are indicators (IP, domain, hash, user) carried in the threat_object field; their accumulated score is compared against a separate threat_object threshold instead of the risk threshold.

Risk objects with no resolvable entity are anonymized into a shared placeholder (for example 'other' or 'unknown'), which aggregates low-fidelity detections into a single trackable object.

A risk notable suppresses the individual contributing risk events from generating separate notables, so analysts review one grouped record with the contributing events attached.

Risk scores decay in relevance because only scores inside the configured risk window are summed; an object below threshold drops out of the aggregation as older risk events age out.

The hunting loop: form a hypothesis -> identify required data sources -> execute search -> validate or refute -> convert findings into a detection, a tuning change, or a documented negative result.

Hypothesis sources: MITRE ATT&CK technique gaps, new threat intelligence, anomaly output from UEBA, newly onboarded data sources, and findings from prior incident response.

Threat hunting is hypothesis-driven and proactive; it is not triggered by an existing alert, which distinguishes it from triage and investigation work.

tstats with summariesonly=true queries accelerated data model summaries and returns results orders of magnitude faster than raw search: | tstats summariesonly=t count from datamodel=Endpoint.Processes by Processes.process_name.

Baseline comparison uses the same search over two windows (or the timewrap command) and compares current counts against historical averages to surface deviation rather than absolute volume.

Event sequencing detects multi-step behavior with streamstats (running count/window) or transaction (grouping by a shared key with maxspan) instead of single-event thresholds.

Rare-value hunting uses the rare command or a not-seen-before check against a lookup to find first-occurrence values such as a new parent process or a never-seen DNS domain.

Data coverage is verified before hunting with | tstats count where index=* by index, sourcetype or | metadata type=hosts, because an absent data source produces a false negative, not a clean result.

Detection types in Splunk ES: threshold, statistical (standard deviation or probability), correlated/sequenced multi-search, anomaly via MLTK, and TTP-based rules mapped to ATT&CK.

Correlation search scheduling uses cron expressions plus a configurable time window; the window must cover the schedule interval or events between runs are never evaluated.

Throttling suppresses repeat notables for the same field-value combination within a defined time span; suppression is applied per rule and does not delete the underlying events.

False positive tuning decision order: raise the threshold, narrow the time window, add a lookup-based exclusion (asset/identity allow list), then lower risk contribution instead of disabling the rule.

Sysmon event IDs used most in detection: 1 process create, 3 network connection, 7 image loaded, 8 CreateRemoteThread, 11 file create, 22 DNS query.

Windows Security event IDs: 4624 successful logon, 4625 failed logon, 4672 special privileges assigned, 4688 process creation, 4720 user account created, 4768 TGT and 4769 TGS requests.

Investigation pivot chain: notable -> contributing events via the search_name/rule field -> entity pivot on risk_object using Asset and Identity Investigator -> raw event timeline for scope and dwell time.

Incident Review workflow states for a notable: New -> In Progress -> Pending -> Resolved -> Closed, with owner, urgency, severity, and comment history recorded on each transition.

Sequence-based attack detection (for example brute force followed by success) requires joining on the entity key (src or user) and comparing the count of 4625 events with a subsequent 4624 within the same window.