> ## Documentation Index
> Fetch the complete documentation index at: https://docs.casebender.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Splunk
> Integrazione bidirezionale tra CaseBender e Splunk (Enterprise Security) per l'ingestione di notable/avvisi, l'inoltro di audit tramite HEC e la sincronizzazione della chiusura dei notable.
## Panoramica
L'integrazione Splunk (**INT-001**) fornisce una sincronizzazione **bidirezionale** tra
CaseBender e Splunk, inclusi gli eventi notable di **Splunk Enterprise Security (ES)**.
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).
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à
| Funzionalità | Direzione | Descrizione |
| --------------------------------- | --------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Polling dei notable (pull)** | Entrata | CaseBender esegue il tuo SPL in modo pianificato tramite l'API REST di ricerca di ES e ingerisce i risultati automaticamente, senza configurazione lato Splunk |
| Ingestione di avvisi (push) | Entrata | Le azioni di avviso / webhook di Splunk inviano payload normalizzati in avvisi CaseBender |
| Estrazione di osservabili | Entrata | I campi `src`/`dest`/`user` (e `*_ip`) diventano osservabili IP / hostname / utente |
| Estrazione di asset | Entrata | `host` (e `dest` non IP) diventano asset host |
| Creazione automatica di casi | Entrata | I record ingeriti possono essere promossi a casi automaticamente (deduplicati per ID notable) |
| Inoltro di audit tramite HEC | Uscita | La creazione/aggiornamento/chiusura dei casi e la promozione degli avvisi vengono registrate in un indice Splunk |
| Chiusura dei notable (write-back) | Uscita | Alla chiusura del caso, il notable ES originale viene impostato su Chiuso con un commento tramite `notable_update` |
| Test di connessione | Uscita | Invia un evento di test all'endpoint HEC |
## Prerequisiti
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**.
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`).
Devi poter creare e gestire integrazioni in **Impostazioni → Integrazioni**.
## Parte A — Preparare Splunk
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.
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
Vai su **Impostazioni → Integrazioni → Crea**, quindi scegli **Splunk** dalla categoria
**SIEM**.
Imposta `purpose` su **Inbound**, **Outbound** o **Bidirectional** per mostrare le schede di
configurazione pertinenti.
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 `.
Nella scheda **Enterprise Security REST API**, inserisci l'URL di gestione (es.
`https://splunk:8089`) e le credenziali:
| Campo | Descrizione |
| ------------------------------- | --------------------------------------------- |
| `restUrl` | URI di gestione Splunk (di solito porta 8089) |
| `restAuthType` | `token` (bearer) o `basic` (utente/password) |
| `restToken` | Token di autenticazione Splunk (bearer) |
| `restUsername` / `restPassword` | Credenziali di autenticazione Basic |
Questa connessione alimenta sia il **polling** sia la **chiusura** dei notable.
Nella scheda **Automatic polling**, attiva **Enable automatic polling** e imposta:
| Opzione | Effetto |
| ----------------------------- | -------------------------------------------------------------------------------------------------- |
| `pollingEnabled` | Attiva l'estrazione pianificata dei risultati di Splunk |
| `searchQuery` | SPL eseguito a ogni intervallo, es. `` search `notable` `` (deve iniziare con `search` o `\|`) |
| `pollingIntervalMinutes` | Frequenza del polling (predefinito `5`, intervallo 1–1440) |
| `pollingInitialLookbackHours` | Alla prima esecuzione, importa i risultati di questa finestra (predefinito `24`, intervallo 1–168) |
Vedi [Polling automatico](#entrata-polling-automatico) per il funzionamento.
Nella scheda **Outbound**, inserisci l'URL, il token e l'indice HEC, quindi abilita:
| Opzione | Effetto |
| ------------------------- | ------------------------------------------------------------------------------------ |
| `syncCaseUpdates` | Inoltra gli eventi di audit `case_created` / `case_updated` / `alert_promoted` a HEC |
| `syncCaseClose` | Inoltra un evento di audit `case_closed` a HEC |
| `closeNotableOnCaseClose` | Chiude il **notable** ES originale tramite REST alla chiusura di un caso collegato |
| `autoCreateCases` | Promuove automaticamente ogni record Splunk ingerito a **caso** |
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
A ogni intervallo (`pollingIntervalMinutes`), CaseBender esegue `searchQuery` sulla finestra
dall'ultimo cursore tramite l'endpoint di esportazione in streaming:
```
POST https://:8089/services/search/jobs/export
search=&earliest_time=&latest_time=now&output_mode=json
```
Alla primissima esecuzione non c'è cursore, quindi vengono importati i risultati della
finestra `pollingInitialLookbackHours`.
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.
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
```
POST https:///api/v1/ingest/splunk
```
Le richieste sono autenticate con una **chiave API** di integrazione passata in
`Authorization: Bearer ` (è 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:
```bash theme={null}
curl -X POST "https:///api/v1/ingest/splunk" \
-H "Authorization: Bearer sk_splunk_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" \
-H "Content-Type: application/json" \
-d '{
"sid": "scheduler__admin__search__RMD5...",
"search_name": "Threat - Brute Force Access - Rule",
"results_link": "https://splunk.example.com/app/search/...",
"app": "SplunkEnterpriseSecuritySuite",
"result": {
"event_id": "A1B2C3D4-...",
"rule_title": "Brute Force Access Behavior Detected",
"urgency": "high",
"security_domain": "access",
"src": "10.0.0.5",
"dest": "10.0.0.20",
"user": "jdoe"
}
}'
```
Una richiesta riuscita restituisce HTTP `202 Accepted`:
```json theme={null}
{ "success": true, "messageId": "..." }
```
### Pipeline di elaborazione
`/api/v1/ingest/splunk` convalida la sorgente e inoltra la richiesta al servizio di ingestione
(`POST /v1/sources/splunk`).
Il servizio di ingestione autentica la chiave API, convalida il payload e pubblica il record
nella coda di elaborazione.
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):
| urgency di Splunk | Gravità CaseBender |
| ----------------------- | ------------------ |
| `critical` | 4 |
| `high` | 3 |
| `medium` | 2 |
| `low` / `informational` | 1 |
**Estrazione di osservabili / asset:**
| Campo Splunk | Osservabile / asset |
| ------------------ | ----------------------------------- |
| `src` / `src_ip` | osservabile `ip` o `hostname` (IOC) |
| `dest` / `dest_ip` | osservabile `ip` o `hostname` |
| `user` | osservabile `user` |
| `host` | asset host |
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:` e `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:
| Evento | `action` HEC | Condizione |
| --------------- | ------------------------ | ----------------- |
| Caso creato | `case_created` | `syncCaseUpdates` |
| Caso aggiornato | `case_updated` | `syncCaseUpdates` |
| Avviso promosso | `alert_promoted_to_case` | `syncCaseUpdates` |
| Caso chiuso | `case_closed` | `syncCaseClose` |
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:
```
POST https://:8089/services/notable_update
ruleUIDs=["", ...]&status=&comment=&output_mode=json
```
* `status` è per impostazione predefinita **5 (Chiuso)** ed è configurabile tramite
`notableStatusOnClose`.
* `comment` è: `Case closed in CaseBender with 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
* [Panoramica delle integrazioni](./introduction.mdx)
* [Splunk HTTP Event Collector](https://docs.splunk.com/Documentation/Splunk/latest/Data/UsetheHTTPEventCollector)
* [Azioni sugli eventi notable di Splunk ES](https://docs.splunk.com/Documentation/ES/latest/User/Triagenotableevents)