Appliance · Rollout

Splunk Cloud und Splunk on-prem unterscheiden sich in jedem der drei Endpunkte — Hostname, Port und die Frage, wer den Index anlegt. Klär zuerst, welche Plattform das Team bekommt, und übernimm die Werte dann aus der passenden Spalte. Beim Rollout am 2026-09-09 gemessen — genau diese drei Punkte waren die Ursache für die roten Felder:

• <stack>.splunkcloud.com:8088 läuft in einen Timeout. Der HEC liegt bei Splunk Cloud nicht auf dem Splunk-Hostname, sondern auf einem eigenen http-inputs-…-Hostname auf 443.
• <instance>.soar.splunkcloud.com:8443 antwortet nicht; auf 443 antwortet /rest/version. Der Port aus der on-prem-Welt ist in der Cloud falsch.
• Ohne :8089 landet die Search-URL auf Splunk Web, das eine HTML-Seite zurückgibt. Der Check meldet dann „Erreichbar, aber Pfad falsch.“ — das ist ein fehlender Port, kein Token-Problem.
• On-prem hinter einem Load Balancer waren 8088 und 8089 offen, der HEC antwortete in rund einer halben Sekunde.

Alle drei URLs trägst du später im Admin-Panel unter Appliance · Rollout → Server erfassen ein; „Alle Endpunkte testen“ prüft sie, bevor ein Team daran hängt.

Der Game-Server pusht alle Events per HEC in den Index cta; der Name steht im Server fest und ist nicht konfigurierbar. Der Index muss vor dem HEC-Token existieren — beim Anlegen des Tokens wählst du die erlaubten Indizes aus, und was es noch nicht gibt, kannst du nicht auswählen. In der falschen Reihenfolge antwortet der HEC später mit HTTP 400 Incorrect index, und das Token muss neu angelegt werden.

• Splunk Cloud — von Hand anlegen, verlass dich hier nicht auf die App: Splunk Web → Settings → Indexes → New Index → im Dialog Add new index unter Name exakt cta eintragen → Save. Alternativ über die Admin-Config-Service-API: POST https://admin.splunk.com/<stack>/adminconfig/v2/indexes mit dem Body {"name": "cta"}.
• Splunk on-prem — die cta-ops.spl bringt den Index mit (indexes.conf mit $SPLUNK_DB-Pfaden). Nach der Installation der App unter Settings → Indexes kurz prüfen, dass cta da ist.

Der Name muss exakt cta lauten, klein geschrieben — ein abweichender Name funktioniert nicht.

Lade oben die drei Pakete herunter und installiere sie in SOAR unter Apps → Install App nacheinander: cta-referee.tgz (meldet gelöste Aufgaben an den Game-Server zurück), cta-enrichment.tgz (Reputation / AV / Sandbox / WHOIS / GeoIP) und cta-response.tgz (Firewall / Identity / EDR / ITSM). Nach dem Upload erscheint jede App unter Apps und lässt sich per Configure New Asset einrichten (Schritt 2). Die Apps rechnen rein deterministisch (kein Outbound) — dieselbe Eingabe ergibt immer dieselbe Bewertung.

Je Team unter Apps → <App> → Configure New Asset anlegen:

• CTA Referee → 1 Asset cta_referee: nur team_id (Team-ID) und team_token (Team-Bearer-Token) setzen, verify_ssl je nach Umgebung. Die game_server_url musst du nicht eintragen — der Game-Server trägt seine eigene Adresse selbst vor (überschreibbar über die Umgebungsvariable CTA_GAME_SERVER_URL, z. B. hinter Proxy oder airgapped). (dieses Asset ist pro Team unterschiedlich)
• CTA Enrichment → 7 Assets, Asset-Name = source_id: cta-reputation, cta-av1, cta-av2, cta-av3, cta-sandbox, cta-whois, cta-geoip. Der source_id ist der Determinismus-Schlüssel, den die Aufgaben referenzieren — genau so benennen.
• CTA Response → 1 Asset cta-identity mit source_id=cta-identity.

Jede Team-Liste ist deterministisch je Event + Team (40 IPs, Spalte ip). Lade unten in der Rollout-Tabelle die CSV des jeweiligen Teams herunter und importiere sie in SOAR unter Administration → Custom Lists als Liste cta_threat_ips (neu anlegen bzw. Inhalt ersetzen). Aufgaben wie die IP-Reputation lesen diese Liste im Playbook per list get.

Statt die Assets und die Liste von Hand anzulegen, kann der Game-Server sie planen und schreiben: POST /admin/teams/{team_id}/provision liefert im Dry-Run (Default) den geplanten REST-Plan (Assets + cta_threat_ips) — ohne etwas zu schreiben, sodass du ihn prüfen kannst. Erst mit dry_run=false + execute_soar=true wird gegen das Team-eigene SOAR (aus team_env) geschrieben. unverifiziert auf 8.5 — die Asset-/Decided-List-/App-Install-REST-Aufrufe sind gegen die Live-8.5 noch nicht bestätigt; die Apps installierst du daher manuell (Schritt 1).

Der Game-Server pusht Events per HEC nach Splunk → daraus wird ein ES-Finding → die ES-Automation triggert das SOAR-Playbook → das Referee-Asset meldet das Ergebnis an den Game-Server zurück, der es wertet und aufs Scoreboard schreibt.

Das Setup fragt nach drei Tokens. So besorgst du jeden:

• 1) ES-HEC Token (Splunk — zum Event-Push):
  • Splunk Web → Einstellungen (Settings) → Dateneingaben (Data inputs) → HTTP Event Collector.
  • Oben rechts „Global Settings“ → sicherstellen: All Tokens = Enabled, Port notieren (Standard 8088), SSL nach Umgebung. Nur on-prem — auf Splunk Cloud ist der HEC ab Werk aktiv, dort gibt es diesen Dialog nicht.
  • „New Token“ → Name z. B. cta-hec → weiter → bei Input Settings als erlaubten Index cta wählen (der Index cta muss dafür schon existieren — siehe Schritt 0: on-prem bringt ihn die cta-ops.spl mit, auf Splunk Cloud legst du ihn vorher von Hand unter Settings → Indexes → New Index an) → Review → Submit.
  • Der angezeigte Token Value ist das ES-HEC Token. Format: GUID — 36 Zeichen mit Bindestrichen. Die Protokoll-Detailansicht muss dazu GUID-Format melden; steht dort kein GUID-Format, liegt das falsche Token im Feld.
  • HEC-URL: on-prem https://<host>:8088, Splunk Cloud https://http-inputs-<stack>.splunkcloud.com auf Port 443 — siehe Plattform-Matrix. Den Pfad /services/collector hängt der Game-Server selbst an; eingetragen wird nur die Basis-URL.
  • Die erlaubten Indizes stehen im Steuerelement Select Allowed Indexes (Auswahlliste Available Indexes) — dort muss cta hinüber.
  • Fehlt cta in der Freigabe des Tokens, antwortet Splunk mit HTTP 400 und dem Text Incorrect index (HEC-Statuscode 7). Im Protokoll erscheint davon nur HTTP 400 — den Splunk-Text zeigt die Detailansicht nicht an. Abhilfe: Index anlegen (Schritt 0), danach das Token neu erstellen.
• 2) ES-Search Token (Splunk — optionaler REST-Such-Zugriff):
  • Splunk Web → Einstellungen → Tokens (Authentication Tokens). Ist „Token Authentication“ aus, zuerst aktivieren.
  • „New Token“ → User wählen, Audience/Expiration setzen → erstellen. Der Token wird nur einmal angezeigt → kopieren.
  • Format: JWT — mehrere hundert Zeichen in drei durch Punkte getrennten Segmenten, kein GUID. Die Detailansicht muss dazu kein GUID-Format melden; steht dort GUID-Format, ist das HEC-Token ins Search-Feld geraten.
  • Das ist das ES-Search Token (für REST-Suchen auf Management-Port 8089). Optional — nur nötig, wenn Such-Zugriff genutzt wird. Der Port gehört in die URL, bei Cloud wie on-prem — siehe Plattform-Matrix.
• 3) SOAR Token (Splunk SOAR 8.5 — Automation-Token):
  • SOAR → Administration (Zahnrad) → User Management → Users.
  • „+ User“ → User Type: Automation → eine Rolle mit REST-Rechten zuweisen → Create. (Oder einen bestehenden Automation-User nehmen.)
  • Soll der Game-Server die Apps auch installieren statt du sie von Hand hochzuladen, braucht die Rolle zusätzlich die Berechtigung Apps = Edit (Edit erlaubt Hinzufügen, Löschen und Ändern von Apps; View reicht dafür nicht).
  • Allowed IPs im Anlegen-Dialog ausfüllen: Automation-Tokens sind an diese IP gebunden. Trag die Egress-IP des Game-Servers ein (einzelne IP, CIDR-Bereich oder any für unbeschränkt). Passt die Herkunft nicht, scheitert der Aufruf trotz gültigem Token — im Protokoll sieht das aus wie ein Rechteproblem.
  • Den Automation-User öffnen → im Feld Authentication Configuration for REST API steht der Automation-/REST-Token (ph-auth-token) → kopieren.
  • Format: rund 44 Zeichen, kein GUID. Die Detailansicht meldet dazu kein GUID-Format.
  • Das ist das SOAR Token (für das cta_referee-Asset bzw. das Provisioning). Nie im Klartext teilen. Die passende SOAR-URL steht in der Plattform-Matrix — in der Cloud ohne :8443.

HEC-Token ist Pflicht (sonst kommen keine Alerts an); ES-Search- und SOAR-Token je nach genutztem Feature.

„Alle Endpunkte testen“ im Admin-Panel schreibt je Endpunkt eine Protokollzeile (Protokoll ▾). Die linke Spalte ist genau der Text, der dort steht. Bleibt eine Zeile rot, obwohl URL, Port und Token stimmen: beim SOAR-Token die im Automation-User hinterlegte IP-Bindung prüfen — sie ist von außen nicht von einem Rechteproblem zu unterscheiden.