SABSA Security Operating Model

Splunk Core & Enterprise Security — Stakeholder Operating Model

A SABSA-aligned view of how the Splunk platform delivers security outcomes: who uses what, for which use cases, and how data flows in and out of each platform. Layered by SABSA, navigated by stakeholder.

Framework: SABSA (Sherwood Applied Business Security Architecture) Platforms: Splunk Core (data & search) · Splunk Enterprise Security (security analytics) Stakeholders: SOC · IR/Forensics · CISO · IT Ops/Eng/Compliance

Live data & information flows

Telemetry enters via forwarders, is normalised in Splunk Core, enriched and correlated in Enterprise Security, then drives action for each stakeholder — with intelligence and response looping back. Click any node to isolate its flows and read its role; toggle the animation to see data move.

Highlight stakeholder Animate flow
Data Sources Splunk Core Enterprise Security Stakeholders & Action
i

Click a node to inspect

Select any source, platform component, or stakeholder to isolate the flows it participates in and read how it fits the operating model.

Tip: use the stakeholder chips above to trace one audience end-to-end. Toggle off animation to reduce motion.

SABSA layer model mapped to Splunk

Each SABSA layer answers a different question and serves a different audience. Below, every layer is expressed concretely in Splunk Core and Enterprise Security terms.

SABSA Layer Splunk Core expression Enterprise Security expression

Stakeholder operating model

What each audience owns, the questions they ask, and the platform surface they live in day to day.

Use case catalogue

Filter by stakeholder to see the use cases each audience runs, and which platform delivers them.

Filter

Where Core ends and ES begins

A clean platform boundary prevents overlap and tool sprawl. Core is the data and search foundation; ES is the security analytics and workflow layer that sits on top of it.

Splunk Core — the foundation
  • Data onboarding & ingest — forwarders, HEC, TAs/add-ons, sourcetype & CIM normalisation.
  • Indexing & retention — hot/warm/cold/frozen tiers, role-based index access, data lifecycle.
  • Search & SPL — ad-hoc investigation, statistics, lookups, KV store, data models.
  • Dashboards & reports — custom operational and security dashboards, scheduled reports.
  • Base alerting — saved-search alerts, thresholds, custom triggers for any team.
  • Platform RBAC & audit — users, roles, capabilities, _audit / _internal monitoring.
Enterprise Security — the security layer
  • Correlation searches — curated, content-managed detections producing notable events.
  • Risk-Based Alerting (RBA) — risk index, risk modifiers, risk incident rules to cut noise.
  • Incident Review & workflow — triage, ownership, status, disposition of notables.
  • Investigation workbench — timelines, artifacts, collaboration for IR.
  • Threat Intelligence framework — feed ingestion, normalisation, indicator matching.
  • Assets & Identities — context enrichment, criticality, identity resolution.
  • Frameworks & posture — MITRE ATT&CK mapping, security posture & executive dashboards.

Operating principle: if it concerns getting data in, storing it, or asking arbitrary questions of it, it belongs to Core. If it concerns detecting, prioritising, investigating, or reporting on security risk, it belongs to ES. ES consumes Core; it never replaces it.

SABSA operating model · Splunk Core & Enterprise Security · Generated as an interactive reference. SABSA layers: Contextual · Conceptual · Logical · Physical · Component · Operational (Service Management).