Passer au contenu principal

​
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).

Ingestion entrante

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).

Synchronisation sortante

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

​
Prérequis

1

Accès à Splunk

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.
2

Sortie réseau

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).
3

Rôle d'administrateur CaseBender

Vous devez pouvoir créer et gérer des intégrations dans Paramètres → Intégrations.

​
Partie A — Préparer Splunk

1

Créer un jeton HEC (pour le transfert sortant)

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.
2

Créer un jeton d'authentification (pour les fonctions REST)

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

1

Ouvrir le catalogue d'intégrations

Allez dans Paramètres → Intégrations → Créer, puis choisissez Splunk dans la catégorie SIEM.
2

Choisir un objectif

Définissez purpose sur Inbound, Outbound ou Bidirectional pour afficher les cartes de configuration pertinentes.
3

Configurer le webhook entrant (push)

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 <API_KEY>.
4

Configurer la connexion REST Enterprise Security (facultatif)

Dans la carte Enterprise Security REST API, saisissez l’URL de gestion (p. ex. https://splunk:8089) et les identifiants :Cette connexion alimente à la fois le sondage et la clôture des notables.
5

Activer le sondage automatique (facultatif)

Dans la carte Automatic polling, activez Enable automatic polling et définissez :Voir Sondage automatique pour son fonctionnement.
6

Configurer la sortie (HEC + clôture des notables)

Dans la carte Outbound, saisissez l’URL, le jeton et l’index HEC, puis activez :
7

Tester la connexion

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

1

Recherche planifiée

À chaque intervalle (pollingIntervalMinutes), CaseBender exécute searchQuery sur la fenêtre depuis le dernier curseur via le point de terminaison d’export en streaming :
À 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.
2

Curseur + déduplication

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.
3

Normalisation

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

Les requêtes sont authentifiées avec une clé API d’intégration passée dans Authorization: Bearer <key> (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 :
Une requête réussie renvoie HTTP 202 Accepted :

​
Pipeline de traitement

1

Proxy d'ingestion

/api/v1/ingest/splunk valide la source et transmet la requête au service d’ingestion (POST /v1/sources/splunk).
2

Publication en file

Le service d’ingestion authentifie la clé API, valide la charge utile et publie l’enregistrement dans la file de traitement.
3

Normalisation

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) : Extraction d’observables / actifs : 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:<security_domain> et app:<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 : 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 :
  • status vaut par défaut 5 (Clôturé) et est configurable via notableStatusOnClose.
  • comment est : Case <id> closed in CaseBender with resolution: <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