> ## 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 > Intégration bidirectionnelle entre CaseBender et Splunk (Enterprise Security) pour l'ingestion des notables/alertes, le transfert d'audit via HEC et la synchronisation de clôture des notables. ## Présentation L'intégration Splunk (**INT-001**) fournit une synchronisation **bidirectionnelle** entre CaseBender et Splunk, y compris les événements notables de **Splunk Enterprise Security (ES)**. Les notables et alertes Splunk sont ingérés dans CaseBender — soit **récupérés automatiquement** de façon planifiée via l'API REST de recherche d'ES, soit **poussés** depuis une action d'alerte / un webhook Splunk — puis normalisés, enrichis d'observables et transformés en alertes (ou cas). Les événements du cycle de vie du cas sont transférés vers un index Splunk via **HEC**, et lorsqu'un cas lié est clôturé, CaseBender peut **clôturer le notable ES d'origine** via l'API REST avec un commentaire d'audit. **Deux voies d'entrée.** Utilisez l'**action d'alerte / webhook (push)** si vous créez déjà des alertes Splunk, ou le **sondage automatique (pull)** si vous préférez que CaseBender exécute une recherche enregistrée de façon planifiée. Le sondage nécessite la connexion REST Enterprise Security ; la voie webhook non. Le HEC sortant utilise le **HTTP Event Collector** (par défaut `/services/collector/event`, généralement le port `8088`). La récupération et la clôture des notables utilisent l'**API REST de gestion** (généralement le port `8089`). Les déploiements Splunk sur site utilisent souvent des **certificats auto-signés** sur les deux : désactivez **Verify SSL** si nécessaire (voir ci-dessous). ## Fonctionnalités | Fonctionnalité | Direction | Description | | --------------------------------- | --------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Sondage des notables (pull)** | Entrant | CaseBender exécute votre SPL de façon planifiée via l'API REST de recherche d'ES et ingère les résultats automatiquement, sans configuration côté Splunk | | Ingestion d'alertes (push) | Entrant | Les actions d'alerte / webhooks Splunk envoient des charges utiles normalisées en alertes CaseBender | | Extraction d'observables | Entrant | Les champs `src`/`dest`/`user` (et `*_ip`) deviennent des observables IP / hostname / utilisateur | | Extraction d'actifs | Entrant | `host` (et `dest` non-IP) deviennent des actifs hôtes | | Création automatique de cas | Entrant | Les enregistrements ingérés peuvent être promus en cas automatiquement (dédupliqués par ID de notable) | | Transfert d'audit via HEC | Sortant | La création/mise à jour/clôture de cas et la promotion d'alertes sont journalisées dans un index Splunk | | Clôture des notables (write-back) | Sortant | À la clôture du cas, le notable ES d'origine est marqué Clôturé avec un commentaire via `notable_update` | | Test de connexion | Sortant | Envoie un événement de test au point de terminaison HEC | ## Prérequis Un déploiement Splunk. Pour la récupération/clôture des notables, vous avez besoin de **Splunk Enterprise Security** et d'un rôle disposant de la capacité `edit_notable_events`. Pour le transfert HEC, vous avez besoin d'un jeton **HTTP Event Collector**. Le déploiement CaseBender (et le service de sondage en arrière-plan, pour le sondage) doit pouvoir atteindre votre point de terminaison **HEC** Splunk (p. ex. `:8088`) et, pour les fonctions REST, le point de terminaison de **gestion** (p. ex. `:8089`). Vous devez pouvoir créer et gérer des intégrations dans **Paramètres → Intégrations**. ## Partie A — Préparer Splunk Dans Splunk, allez dans **Settings → Data inputs → HTTP Event Collector → New Token**. Activez HEC globalement s'il ne l'est pas déjà, choisissez (ou créez) un index cible et copiez la valeur du jeton. Pour le **sondage** et la **clôture** des notables, créez un **jeton d'authentification** Splunk sous **Settings → Tokens** (ou utilisez un compte de service pour l'authentification Basic). Le rôle associé a besoin de `edit_notable_events` pour clôturer les notables et d'un accès de recherche à votre index de notables. ## Partie B — Configurer l'intégration dans CaseBender Allez dans **Paramètres → Intégrations → Créer**, puis choisissez **Splunk** dans la catégorie **SIEM**. Définissez `purpose` sur **Inbound**, **Outbound** ou **Bidirectional** pour afficher les cartes de configuration pertinentes. Copiez l'**URL du webhook** et générez une **clé API** (préfixée `sk_splunk_`). Dans Splunk, ajoutez une action d'alerte **Webhook** qui publie vers l'URL avec l'en-tête `Authorization: Bearer `. Dans la carte **Enterprise Security REST API**, saisissez l'URL de gestion (p. ex. `https://splunk:8089`) et les identifiants : | Champ | Description | | ------------------------------- | ------------------------------------------------------ | | `restUrl` | URI de gestion Splunk (généralement port 8089) | | `restAuthType` | `token` (bearer) ou `basic` (utilisateur/mot de passe) | | `restToken` | Jeton d'authentification Splunk (bearer) | | `restUsername` / `restPassword` | Identifiants d'authentification Basic | Cette connexion alimente à la fois le **sondage** et la **clôture** des notables. Dans la carte **Automatic polling**, activez **Enable automatic polling** et définissez : | Option | Effet | | ----------------------------- | ---------------------------------------------------------------------------------------------------- | | `pollingEnabled` | Active la récupération planifiée des résultats Splunk | | `searchQuery` | SPL exécuté à chaque intervalle, p. ex. `` search `notable` `` (doit commencer par `search` ou `\|`) | | `pollingIntervalMinutes` | Fréquence du sondage (par défaut `5`, plage 1–1440) | | `pollingInitialLookbackHours` | À la première exécution, importe les résultats de cette fenêtre (par défaut `24`, plage 1–168) | Voir [Sondage automatique](#entrant-sondage-automatique) pour son fonctionnement. Dans la carte **Outbound**, saisissez l'URL, le jeton et l'index HEC, puis activez : | Option | Effet | | ------------------------- | -------------------------------------------------------------------------------------------- | | `syncCaseUpdates` | Transfère les événements d'audit `case_created` / `case_updated` / `alert_promoted` vers HEC | | `syncCaseClose` | Transfère un événement d'audit `case_closed` vers HEC | | `closeNotableOnCaseClose` | Clôture le **notable** ES d'origine via REST à la clôture d'un cas lié | | `autoCreateCases` | Promeut automatiquement chaque enregistrement Splunk ingéré en **cas** | Utilisez **Test Connection** pour envoyer un événement de test au point de terminaison HEC. Si votre Splunk utilise un certificat auto-signé, désactivez **Verify SSL**. ## Entrant (sondage automatique) Avec le **sondage automatique** activé, CaseBender exécute périodiquement votre SPL via l'API REST de recherche d'Enterprise Security et ingère les résultats de lui-même — **sans aucune action d'alerte ni webhook côté Splunk**. ### Fonctionnement À chaque intervalle (`pollingIntervalMinutes`), CaseBender exécute `searchQuery` sur la fenêtre depuis le dernier curseur via le point de terminaison d'export en streaming : ``` POST https://:8089/services/search/jobs/export search=&earliest_time=&latest_time=now&output_mode=json ``` À la toute première exécution, il n'y a pas de curseur ; les résultats de la fenêtre `pollingInitialLookbackHours` sont donc importés. CaseBender fait avancer un curseur par intégration jusqu'au `_time` de résultat le plus récent vu, de sorte que chaque exécution ne récupère que l'activité nouvelle. Les résultats sont également **dédupliqués par `event_id` du notable** (avec repli sur le `sid` de la recherche), de sorte qu'un notable n'est jamais ingéré deux fois — même si la fenêtre de sondage se chevauche. Chaque ligne de résultat est normalisée en une alerte CaseBender — mappage de la gravité depuis `urgency`, construction du titre/description et extraction des observables et actifs hôtes. Le `event_id` du notable est estampillé sur l'alerte pour que la clôture sortante puisse le retrouver ultérieurement. Avec **`autoCreateCases` activé**, chaque notable sondé devient automatiquement un **cas** (dédupliqué par ID de notable) — cela correspond au flux « récupérer le notable → le traiter comme un cas ». Désactivé, les résultats arrivent dans la boîte de réception **Alertes** pour une promotion manuelle. Dans les deux cas, le lien Splunk est conservé afin que la clôture du cas puisse clôturer le notable. Le sondage s'exécute dans le service de sondage en arrière-plan de CaseBender. Assurez-vous que ce service peut atteindre votre point de terminaison de gestion Splunk (directement ou via votre proxy configuré). Les hôtes Splunk internes doivent figurer dans `NO_PROXY` sur les réseaux à proxy uniquement. ## Entrant (webhook / push) En alternative (ou en complément) au sondage, une **action d'alerte** Splunk (ou tout émetteur de webhook) peut envoyer les résultats de recherche au point de terminaison d'ingestion de CaseBender. ### Point de terminaison ``` POST https:///api/v1/ingest/splunk ``` Les requêtes sont authentifiées avec une **clé API** d'intégration passée dans `Authorization: Bearer ` (l'en-tête `x-api-key` est également accepté). Les clés API de webhook Splunk sont préfixées par `sk_splunk_`. ### Exemple de charge utile L'action d'alerte webhook de Splunk publie un objet `result` ainsi que des métadonnées de recherche : ```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" } }' ``` Une requête réussie renvoie HTTP `202 Accepted` : ```json theme={null} { "success": true, "messageId": "..." } ``` ### Pipeline de traitement `/api/v1/ingest/splunk` valide la source et transmet la requête au service d'ingestion (`POST /v1/sources/splunk`). Le service d'ingestion authentifie la clé API, valide la charge utile et publie l'enregistrement dans la file de traitement. Le processeur Splunk normalise l'enregistrement en une alerte CaseBender — mappage de la gravité, construction du titre/description et extraction des observables et actifs hôtes. ### Référence de mappage des données **Mappage de gravité** (`urgency` Splunk → CaseBender 1–4) : | urgency Splunk | Gravité CaseBender | | ----------------------- | ------------------ | | `critical` | 4 | | `high` | 3 | | `medium` | 2 | | `low` / `informational` | 1 | **Extraction d'observables / actifs :** | Champ Splunk | Observable / actif | | ------------------ | ----------------------------------- | | `src` / `src_ip` | observable `ip` ou `hostname` (IOC) | | `dest` / `dest_ip` | observable `ip` ou `hostname` | | `user` | observable `user` | | `host` | actif hôte | Le **titre** est construit à partir de `rule_title` → `search_name` → `alert_name` → `signature` → `message`. Les **tags** appliqués à l'ingestion incluent `splunk`, `siem`, `notable` (pour les notables ES), `domain:` et `app:`. Les enregistrements ingérés utilisent par défaut **TLP:2** et **PAP:2**. ## Sortant : transfert d'audit via HEC Lorsqu'il est activé avec `syncCaseUpdates` / `syncCaseClose`, CaseBender publie des événements d'audit JSON vers votre point de terminaison HEC afin que l'activité des cas soit consultable dans Splunk : | Événement | `action` HEC | Condition | | -------------- | ------------------------ | ----------------- | | Cas créé | `case_created` | `syncCaseUpdates` | | Cas mis à jour | `case_updated` | `syncCaseUpdates` | | Alerte promue | `alert_promoted_to_case` | `syncCaseUpdates` | | Cas clôturé | `case_closed` | `syncCaseClose` | Les événements sont envoyés avec `source: casebender:case` (ou `casebender:alert`) et `sourcetype: _json` vers l'index configuré. ## Sortant : clôturer le notable Splunk (write-back) Lorsqu'un cas est clôturé dans CaseBender, l'événement `case_closed` est distribué au gestionnaire Splunk. Si le cas est lié à un notable Splunk **et** que `closeNotableOnCaseClose` est activé, CaseBender clôture le notable via l'API REST d'ES. ### Comment le notable lié est résolu Le pipeline d'ingestion estampille `splunkEventId` (le `event_id` du notable) et l'ID de l'intégration d'ingestion sur les `customFields` de chaque alerte Splunk. À la clôture du cas, le gestionnaire collecte ces ID d'événement depuis les alertes liées au cas ; ainsi un cas promu à partir d'un notable sondé ou de webhook est résolu automatiquement, quelle que soit sa méthode de création. ### Ce qui est envoyé CaseBender appelle le point de terminaison `notable_update` d'ES : ``` POST https://:8089/services/notable_update ruleUIDs=["", ...]&status=&comment=&output_mode=json ``` * `status` vaut par défaut **5 (Clôturé)** et est configurable via `notableStatusOnClose`. * `comment` est : `Case closed in CaseBender with resolution: `. Le résultat (notables clôturés, ou une erreur) est écrit dans la chronologie du cas afin que les analystes puissent confirmer la synchronisation. `syncCaseClose` (événement d'audit HEC) et `closeNotableOnCaseClose` (write-back du notable via REST) sont des bascules indépendantes par intégration. Le write-back du notable nécessite la connexion REST Enterprise Security et un rôle disposant de la capacité `edit_notable_events`. ## Considérations de sécurité * **Gestion des jetons** — les jetons HEC et les jetons/mots de passe REST sont stockés dans les paramètres de l'intégration ; faites-les tourner selon le calendrier de votre organisation et mettez à jour l'intégration en conséquence. * **Moindre privilège** — le rôle REST n'a besoin que d'un accès de recherche à votre index de notables et de `edit_notable_events`. Les jetons HEC devraient cibler un index dédié. * **Clés de webhook** — traitez la clé API `sk_splunk_` comme un secret. Faites-la tourner en cas d'exposition et mettez à jour l'action d'alerte Splunk. * **TLS** — préférez des certificats de confiance. Si vous devez utiliser des certificats auto-signés (courant sur site), **Verify SSL** peut être désactivé ; la connexion reste chiffrée mais le certificat n'est pas validé. Restreignez la sortie à vos points de terminaison HEC et de gestion Splunk. ## Dépannage Vérifiez l'URL et le jeton HEC, que HEC est activé et que CaseBender peut atteindre le port HEC (généralement `8088`). Si Splunk utilise un certificat auto-signé, désactivez **Verify SSL** — sinon la requête échoue avec une erreur de certificat. L'en-tête `Authorization: Bearer` (ou `x-api-key`) est manquant ou invalide. Vérifiez que vous envoyez la clé `sk_splunk_` qui correspond à la clé API de webhook configurée dans l'intégration. Vérifiez que **Enable automatic polling** est activé, que la connexion **ES REST** est renseignée et qu'une **requête de recherche** est définie. Vérifiez que le rôle peut exécuter la recherche et atteindre le port de gestion (généralement `8089`), et qu'il existe des résultats plus récents que le curseur. À la première exécution, seuls les résultats de la fenêtre `pollingInitialLookbackHours` sont importés. Consultez le dernier statut de synchronisation de l'intégration pour l'erreur précise. Assurez-vous que `closeNotableOnCaseClose` est activé et que la connexion **ES REST** est configurée avec un rôle disposant de `edit_notable_events`. Le cas doit être lié à un notable Splunk — la clôture d'un cas promu à partir d'un notable sondé/de webhook résout le lien automatiquement. Consultez la chronologie du cas pour le résultat de la synchronisation. Un `403` signifie que le rôle REST ne dispose pas de la capacité `edit_notable_events`. Un `404` signifie généralement que l'URL n'est pas le point de terminaison de gestion Enterprise Security — vérifiez que `restUrl` pointe vers le port de gestion Splunk avec ES installé. Sur les réseaux à proxy uniquement, ajoutez votre hôte Splunk interne à `NO_PROXY` pour que la connexion soit directe, et désactivez **Verify SSL** si le certificat est auto-signé. ## Documentation connexe * [Présentation des intégrations](./introduction.mdx) * [Splunk HTTP Event Collector](https://docs.splunk.com/Documentation/Splunk/latest/Data/UsetheHTTPEventCollector) * [Actions sur les événements notables Splunk ES](https://docs.splunk.com/Documentation/ES/latest/User/Triagenotableevents)