Vai al contenuto principale

​
Panoramica

L’integrazione Splunk (INT-001) fornisce una sincronizzazione bidirezionale tra CaseBender e Splunk, inclusi gli eventi notable di Splunk Enterprise Security (ES).

Ingestione in entrata

I notable e gli avvisi di Splunk vengono ingeriti in CaseBender — estratti automaticamente in modo pianificato tramite l’API REST di ricerca di ES, oppure inviati da un’azione di avviso / webhook di Splunk — quindi normalizzati, arricchiti con osservabili e trasformati in avvisi (o casi).

Sincronizzazione in uscita

Gli eventi del ciclo di vita del caso vengono inoltrati a un indice Splunk tramite HEC, e quando un caso collegato viene chiuso, CaseBender può chiudere il notable ES originale tramite l’API REST con un commento di audit.
Due percorsi in entrata. Usa l’azione di avviso / webhook (push) se crei già avvisi in Splunk, oppure il polling automatico (pull) se preferisci che CaseBender esegua una ricerca salvata in modo pianificato. Il polling richiede la connessione REST di Enterprise Security; il percorso webhook no.
L’HEC in uscita usa l’HTTP Event Collector (predefinito /services/collector/event, di solito la porta 8088). L’estrazione e la chiusura dei notable usano l’API REST di gestione (di solito la porta 8089). Gli Splunk on-premise usano spesso certificati autofirmati su entrambi: disattiva Verify SSL se necessario (vedi sotto).

​
Funzionalità

​
Prerequisiti

1

Accesso a Splunk

Un’installazione di Splunk. Per l’estrazione/chiusura dei notable è necessario Splunk Enterprise Security e un ruolo con la capacità edit_notable_events. Per l’inoltro HEC è necessario un token HTTP Event Collector.
2

Uscita di rete

L’installazione di CaseBender (e il servizio di polling in background, per il polling) deve poter raggiungere l’endpoint HEC di Splunk (es. :8088) e, per le funzioni REST, l’endpoint di gestione (es. :8089).
3

Ruolo di amministratore CaseBender

Devi poter creare e gestire integrazioni in Impostazioni → Integrazioni.

​
Parte A — Preparare Splunk

1

Creare un token HEC (per l'inoltro in uscita)

In Splunk, vai su Settings → Data inputs → HTTP Event Collector → New Token. Abilita HEC globalmente se non lo è già, scegli (o crea) un indice di destinazione e copia il valore del token.
2

Creare un token di autenticazione (per le funzioni REST)

Per il polling e la chiusura dei notable, crea un token di autenticazione Splunk in Settings → Tokens (oppure usa un account di servizio per l’autenticazione Basic). Il ruolo associato necessita di edit_notable_events per chiudere i notable e dell’accesso di ricerca al tuo indice di notable.

​
Parte B — Configurare l’integrazione in CaseBender

1

Aprire il catalogo delle integrazioni

Vai su Impostazioni → Integrazioni → Crea, quindi scegli Splunk dalla categoria SIEM.
2

Scegliere uno scopo

Imposta purpose su Inbound, Outbound o Bidirectional per mostrare le schede di configurazione pertinenti.
3

Configurare il webhook in entrata (push)

Copia l’URL del webhook e genera una chiave API (con prefisso sk_splunk_). In Splunk, aggiungi un’azione di avviso Webhook che invii all’URL con l’intestazione Authorization: Bearer <API_KEY>.
4

Configurare la connessione REST di Enterprise Security (facoltativo)

Nella scheda Enterprise Security REST API, inserisci l’URL di gestione (es. https://splunk:8089) e le credenziali:Questa connessione alimenta sia il polling sia la chiusura dei notable.
5

Abilitare il polling automatico (facoltativo)

Nella scheda Automatic polling, attiva Enable automatic polling e imposta:Vedi Polling automatico per il funzionamento.
6

Configurare l'uscita (HEC + chiusura dei notable)

Nella scheda Outbound, inserisci l’URL, il token e l’indice HEC, quindi abilita:
7

Testare la connessione

Usa Test Connection per inviare un evento di test all’endpoint HEC. Se il tuo Splunk usa un certificato autofirmato, disattiva Verify SSL.

​
Entrata (polling automatico)

Con il polling automatico abilitato, CaseBender esegue periodicamente il tuo SPL tramite l’API REST di ricerca di Enterprise Security e ingerisce i risultati autonomamente — senza alcuna azione di avviso o webhook lato Splunk.

​
Come funziona

1

Ricerca pianificata

A ogni intervallo (pollingIntervalMinutes), CaseBender esegue searchQuery sulla finestra dall’ultimo cursore tramite l’endpoint di esportazione in streaming:
Alla primissima esecuzione non c’è cursore, quindi vengono importati i risultati della finestra pollingInitialLookbackHours.
2

Cursore + deduplicazione

CaseBender fa avanzare un cursore per integrazione fino al _time di risultato più recente visto, così ogni esecuzione recupera solo attività nuova. I risultati vengono anche deduplicati per event_id del notable (con ripiego sul sid della ricerca), così un notable non viene mai ingerito due volte, anche se la finestra di polling si sovrappone.
3

Normalizzazione

Ogni riga di risultato viene normalizzata in un avviso CaseBender — mappando la gravità da urgency, costruendo titolo/descrizione ed estraendo osservabili e asset host. L’event_id del notable viene impresso sull’avviso affinché la chiusura in uscita possa trovarlo in seguito.
Con autoCreateCases abilitato, ogni notable estratto diventa automaticamente un caso (deduplicato per ID notable) — questo corrisponde al flusso “estrai il notable → lavoralo come caso”. Se disabilitato, i risultati arrivano nella casella Avvisi per la promozione manuale. In entrambi i casi il collegamento con Splunk viene conservato affinché la chiusura del caso possa chiudere il notable.
Il polling viene eseguito nel servizio di polling in background di CaseBender. Assicurati che quel servizio possa raggiungere l’endpoint di gestione di Splunk (direttamente o tramite il proxy configurato). Gli host Splunk interni devono essere elencati in NO_PROXY sulle reti solo-proxy.

​
Entrata (webhook / push)

In alternativa (o in aggiunta) al polling, un’azione di avviso Splunk (o qualsiasi mittente webhook) può inviare i risultati della ricerca all’endpoint di ingestione di CaseBender.

​
Endpoint

Le richieste sono autenticate con una chiave API di integrazione passata in Authorization: Bearer <key> (è accettata anche l’intestazione x-api-key). Le chiavi API di webhook di Splunk hanno il prefisso sk_splunk_.

​
Esempio di payload

L’azione di avviso webhook di Splunk invia un oggetto result più i metadati della ricerca:
Una richiesta riuscita restituisce HTTP 202 Accepted:

​
Pipeline di elaborazione

1

Proxy di ingestione

/api/v1/ingest/splunk convalida la sorgente e inoltra la richiesta al servizio di ingestione (POST /v1/sources/splunk).
2

Pubblicazione in coda

Il servizio di ingestione autentica la chiave API, convalida il payload e pubblica il record nella coda di elaborazione.
3

Normalizzazione

Il processore Splunk normalizza il record in un avviso CaseBender — mappando la gravità, costruendo titolo/descrizione ed estraendo osservabili e asset host.

​
Riferimento di mappatura dei dati

Mappatura della gravità (urgency di Splunk → CaseBender 1–4): Estrazione di osservabili / asset: Il titolo viene costruito da rule_title → search_name → alert_name → signature → message. I tag applicati all’ingestione includono splunk, siem, notable (per i notable ES), domain:<security_domain> e app:<app>. I record ingeriti usano per impostazione predefinita TLP:2 e PAP:2.

​
Uscita: inoltro di audit tramite HEC

Quando abilitato con syncCaseUpdates / syncCaseClose, CaseBender pubblica eventi di audit JSON verso il tuo endpoint HEC affinché l’attività dei casi sia ricercabile in Splunk: Gli eventi vengono inviati con source: casebender:case (o casebender:alert) e sourcetype: _json all’indice configurato.

​
Uscita: chiudere il notable di Splunk (write-back)

Quando un caso viene chiuso in CaseBender, l’evento case_closed viene inoltrato all’handler di Splunk. Se il caso è collegato a un notable Splunk e closeNotableOnCaseClose è attivo, CaseBender chiude il notable tramite l’API REST di ES.

​
Come viene risolto il notable collegato

La pipeline di ingestione imprime splunkEventId (l’event_id del notable) e l’ID dell’integrazione che lo ha ingerito nei customFields di ogni avviso Splunk. Alla chiusura del caso, l’handler raccoglie quegli ID evento dagli avvisi collegati al caso, così un caso promosso da un notable estratto o da webhook viene risolto automaticamente, indipendentemente da come è stato creato.

​
Cosa viene inviato

CaseBender chiama l’endpoint notable_update di ES:
  • status è per impostazione predefinita 5 (Chiuso) ed è configurabile tramite notableStatusOnClose.
  • comment è: Case <id> closed in CaseBender with resolution: <resolution>.
L’esito (notable chiusi, o un errore) viene scritto nella cronologia del caso affinché gli analisti possano confermare la sincronizzazione.
syncCaseClose (evento di audit HEC) e closeNotableOnCaseClose (write-back del notable tramite REST) sono interruttori indipendenti per integrazione. Il write-back del notable richiede la connessione REST di Enterprise Security e un ruolo con la capacità edit_notable_events.

​
Considerazioni sulla sicurezza

  • Gestione dei token — i token HEC e i token/password REST sono memorizzati nelle impostazioni dell’integrazione; ruotali secondo la pianificazione della tua organizzazione e aggiorna l’integrazione di conseguenza.
  • Privilegio minimo — il ruolo REST necessita solo dell’accesso di ricerca al tuo indice di notable e di edit_notable_events. I token HEC dovrebbero puntare a un indice dedicato.
  • Chiavi di webhook — tratta la chiave API sk_splunk_ come un segreto. Ruotala se esposta e aggiorna l’azione di avviso di Splunk.
  • TLS — preferisci certificati attendibili. Se devi usare certificati autofirmati (comune on-premise), Verify SSL può essere disattivato; la connessione resta cifrata ma il certificato non viene convalidato. Limita l’uscita ai tuoi endpoint HEC e di gestione di Splunk.

​
Risoluzione dei problemi

Conferma l’URL e il token HEC, che HEC sia abilitato e che CaseBender possa raggiungere la porta HEC (di solito 8088). Se Splunk usa un certificato autofirmato, disattiva Verify SSL — altrimenti la richiesta fallisce con un errore di certificato.
L’intestazione Authorization: Bearer (o x-api-key) è mancante o non valida. Conferma di inviare la chiave sk_splunk_ che corrisponde alla chiave API di webhook configurata nell’integrazione.
Conferma che Enable automatic polling sia attivo, che la connessione ES REST sia compilata e che sia impostata una query di ricerca. Verifica che il ruolo possa eseguire la ricerca e raggiungere la porta di gestione (di solito 8089) e che esistano risultati più recenti del cursore. Alla prima esecuzione vengono importati solo i risultati della finestra pollingInitialLookbackHours. Controlla l’ultimo stato di sincronizzazione dell’integrazione per l’errore specifico.
Assicurati che closeNotableOnCaseClose sia attivo e che la connessione ES REST sia configurata con un ruolo che abbia edit_notable_events. Il caso deve essere collegato a un notable Splunk — la chiusura di un caso promosso da un notable estratto/di webhook risolve il collegamento automaticamente. Controlla la cronologia del caso per l’esito della sincronizzazione.
Un 403 significa che il ruolo REST non dispone della capacità edit_notable_events. Un 404 di solito significa che l’URL non è l’endpoint di gestione di Enterprise Security — conferma che restUrl punti alla porta di gestione di Splunk con ES installato.
Sulle reti solo-proxy, aggiungi il tuo host Splunk interno a NO_PROXY affinché la connessione sia diretta e disattiva Verify SSL se il certificato è autofirmato.

​
Documentazione correlata