> ## 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 > Integración bidireccional entre CaseBender y Splunk (Enterprise Security) para la ingesta de notables/alertas, el reenvío de auditoría por HEC y la sincronización de cierre de notables. ## Descripción general La integración de Splunk (**INT-001**) proporciona sincronización **bidireccional** entre CaseBender y Splunk, incluidos los eventos notables de **Splunk Enterprise Security (ES)**. Los notables y alertas de Splunk se ingieren en CaseBender, ya sea **extraídos automáticamente** de forma programada mediante la API REST de búsqueda de ES, o **enviados** desde una acción de alerta / webhook de Splunk; luego se normalizan, se enriquecen con observables y se convierten en alertas (o casos). Los eventos del ciclo de vida del caso se reenvían a un índice de Splunk mediante **HEC**, y cuando se cierra un caso vinculado, CaseBender puede **cerrar el notable de ES original** a través de la API REST con un comentario de auditoría. **Dos vías de entrada.** Use **acción de alerta / webhook (push)** si ya crea alertas en Splunk, o **sondeo automático (pull)** si prefiere que CaseBender ejecute una búsqueda guardada de forma programada. El sondeo requiere la conexión REST de Enterprise Security; la vía de webhook no. El HEC saliente utiliza el **HTTP Event Collector** (por defecto `/services/collector/event`, normalmente el puerto `8088`). La extracción y el cierre de notables usan la **API REST de administración** (normalmente el puerto `8089`). Splunk on-premise suele usar **certificados autofirmados** en ambos: desactive **Verify SSL** si es necesario (véase más abajo). ## Capacidades | Capacidad | Dirección | Descripción | | ------------------------------- | --------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Sondeo de notables (pull)** | Entrante | CaseBender ejecuta su SPL de forma programada mediante la API REST de búsqueda de ES e ingiere los resultados automáticamente, sin configuración del lado de Splunk | | Ingesta de alertas (push) | Entrante | Las acciones de alerta / webhooks de Splunk envían cargas que se normalizan en alertas de CaseBender | | Extracción de observables | Entrante | Los campos `src`/`dest`/`user` (y `*_ip`) se convierten en observables de IP / hostname / usuario | | Extracción de activos | Entrante | `host` (y `dest` no IP) se convierten en activos de host | | Creación automática de casos | Entrante | Los registros ingeridos pueden promoverse a casos automáticamente (deduplicados por ID de notable) | | Reenvío de auditoría por HEC | Saliente | La creación/actualización/cierre de casos y la promoción de alertas se registran en un índice de Splunk | | Cierre de notables (write-back) | Saliente | Al cerrar el caso, el notable de ES original se marca como Cerrado con un comentario mediante `notable_update` | | Prueba de conexión | Saliente | Envía un evento de prueba al endpoint HEC | ## Requisitos previos Una implementación de Splunk. Para la extracción/cierre de notables necesita **Splunk Enterprise Security** y un rol con la capacidad `edit_notable_events`. Para el reenvío por HEC necesita un token de **HTTP Event Collector**. La implementación de CaseBender (y el servicio de sondeo en segundo plano, para el sondeo) debe poder alcanzar su endpoint **HEC** de Splunk (p. ej. `:8088`) y, para las funciones REST, el endpoint de **administración** (p. ej. `:8089`). Debe poder crear y administrar integraciones en **Configuración → Integraciones**. ## Parte A — Preparar Splunk En Splunk, vaya a **Settings → Data inputs → HTTP Event Collector → New Token**. Habilite HEC globalmente si aún no lo está, elija (o cree) un índice de destino y copie el valor del token. Para el **sondeo** y el **cierre** de notables, cree un **token de autenticación** de Splunk en **Settings → Tokens** (o use una cuenta de servicio para autenticación básica). El rol asociado necesita `edit_notable_events` para cerrar notables y acceso de búsqueda a su índice de notables. ## Parte B — Configurar la integración en CaseBender Vaya a **Configuración → Integraciones → Crear** y elija **Splunk** en la categoría **SIEM**. Configure `purpose` como **Inbound**, **Outbound** o **Bidirectional** para mostrar las tarjetas de configuración correspondientes. Copie la **URL del webhook** y genere una **clave de API** (con prefijo `sk_splunk_`). En Splunk, agregue una acción de alerta **Webhook** que publique en la URL con el encabezado `Authorization: Bearer `. En la tarjeta **Enterprise Security REST API**, ingrese la URL de administración (p. ej. `https://splunk:8089`) y las credenciales: | Campo | Descripción | | ------------------------------- | --------------------------------------------------------- | | `restUrl` | URI de administración de Splunk (normalmente puerto 8089) | | `restAuthType` | `token` (bearer) o `basic` (usuario/contraseña) | | `restToken` | Token de autenticación de Splunk (bearer) | | `restUsername` / `restPassword` | Credenciales de autenticación básica | Esta conexión habilita tanto el **sondeo** como el **cierre** de notables. En la tarjeta **Automatic polling**, active **Enable automatic polling** y configure: | Opción | Efecto | | ----------------------------- | -------------------------------------------------------------------------------------------------- | | `pollingEnabled` | Activa la extracción programada de resultados de Splunk | | `searchQuery` | SPL ejecutado en cada intervalo, p. ej. `` search `notable` `` (debe comenzar con `search` o `\|`) | | `pollingIntervalMinutes` | Frecuencia de sondeo (por defecto `5`, rango 1–1440) | | `pollingInitialLookbackHours` | En la primera ejecución, importa resultados dentro de esta ventana (por defecto `24`, rango 1–168) | Consulte [Sondeo automático](#entrante-sondeo-automatico) para saber cómo funciona. En la tarjeta **Outbound**, ingrese la URL, el token y el índice de HEC, luego habilite: | Opción | Efecto | | ------------------------- | ----------------------------------------------------------------------------------------- | | `syncCaseUpdates` | Reenvía los eventos de auditoría `case_created` / `case_updated` / `alert_promoted` a HEC | | `syncCaseClose` | Reenvía un evento de auditoría `case_closed` a HEC | | `closeNotableOnCaseClose` | Cierra el **notable** de ES original mediante REST cuando se cierra un caso vinculado | | `autoCreateCases` | Promueve cada registro de Splunk ingerido a un **caso** automáticamente | Use **Test Connection** para enviar un evento de prueba al endpoint HEC. Si su Splunk usa un certificado autofirmado, desactive **Verify SSL**. ## Entrante (sondeo automático) Con el **sondeo automático** habilitado, CaseBender ejecuta periódicamente su SPL a través de la API REST de búsqueda de Enterprise Security e ingiere los resultados por sí mismo, **sin que se requiera ninguna acción de alerta ni webhook del lado de Splunk**. ### Cómo funciona En cada intervalo (`pollingIntervalMinutes`), CaseBender ejecuta `searchQuery` sobre la ventana desde el último cursor mediante el endpoint de exportación en streaming: ``` POST https://:8089/services/search/jobs/export search=&earliest_time=&latest_time=now&output_mode=json ``` En la primera ejecución no hay cursor, por lo que se importan los resultados dentro de `pollingInitialLookbackHours`. CaseBender avanza un cursor por integración hasta el `_time` de resultado más reciente que ha visto, de modo que cada ejecución solo obtiene actividad nueva. Los resultados también se **deduplican por el `event_id` del notable** (con respaldo en el `sid` de la búsqueda), por lo que un notable nunca se ingiere dos veces, incluso si la ventana de sondeo se solapa. Cada fila de resultado se normaliza en una alerta de CaseBender: se mapea la gravedad desde `urgency`, se construye el título/descripción y se extraen observables y activos de host. El `event_id` del notable se estampa en la alerta para que el cierre saliente pueda encontrarlo más tarde. Con **`autoCreateCases` habilitado**, cada notable sondeado se convierte automáticamente en un **caso** (deduplicado por ID de notable): esto coincide con el flujo "extraer notable → trabajarlo como caso". Con esta opción deshabilitada, los resultados llegan a la bandeja de **Alertas** para su promoción manual. En cualquier caso, el vínculo con Splunk se conserva para que al cerrar el caso se pueda cerrar el notable. El sondeo se ejecuta en el servicio de sondeo en segundo plano de CaseBender. Asegúrese de que ese servicio pueda alcanzar su endpoint de administración de Splunk (directamente o a través del proxy configurado). Los hosts internos de Splunk deben incluirse en `NO_PROXY` en redes de solo proxy. ## Entrante (webhook / push) Como alternativa (o además) al sondeo, una **acción de alerta** de Splunk (o cualquier emisor de webhook) puede enviar los resultados de la búsqueda al endpoint de ingesta de CaseBender. ### Endpoint ``` POST https:///api/v1/ingest/splunk ``` Las solicitudes se autentican con una **clave de API** de la integración pasada como `Authorization: Bearer ` (también se acepta el encabezado `x-api-key`). Las claves de API de webhook de Splunk tienen el prefijo `sk_splunk_`. ### Ejemplo de carga La acción de alerta de webhook de Splunk publica un objeto `result` más metadatos de la búsqueda: ```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 solicitud exitosa devuelve HTTP `202 Accepted`: ```json theme={null} { "success": true, "messageId": "..." } ``` ### Flujo de procesamiento `/api/v1/ingest/splunk` valida la fuente y reenvía la solicitud al servicio de ingesta (`POST /v1/sources/splunk`). El servicio de ingesta autentica la clave de API, valida la carga y publica el registro en la cola de procesamiento. El procesador de Splunk normaliza el registro en una alerta de CaseBender: mapea la gravedad, construye el título/descripción y extrae observables y activos de host. ### Referencia de mapeo de datos **Mapeo de gravedad** (`urgency` de Splunk → CaseBender 1–4): | urgency de Splunk | Gravedad de CaseBender | | ----------------------- | ---------------------- | | `critical` | 4 | | `high` | 3 | | `medium` | 2 | | `low` / `informational` | 1 | **Extracción de observables / activos:** | Campo de Splunk | Observable / activo | | ------------------ | ------------------------------------- | | `src` / `src_ip` | observable de `ip` o `hostname` (IOC) | | `dest` / `dest_ip` | observable de `ip` o `hostname` | | `user` | observable de `user` | | `host` | activo de host | El **título** se construye a partir de `rule_title` → `search_name` → `alert_name` → `signature` → `message`. Las **etiquetas** aplicadas en la ingesta incluyen `splunk`, `siem`, `notable` (para notables de ES), `domain:` y `app:`. Los registros ingeridos usan por defecto **TLP:2** y **PAP:2**. ## Saliente: reenvío de auditoría por HEC Cuando se habilita con `syncCaseUpdates` / `syncCaseClose`, CaseBender publica eventos de auditoría en formato JSON en su endpoint HEC para que la actividad del caso se pueda buscar en Splunk: | Evento | `action` de HEC | Condición | | ---------------- | ------------------------ | ----------------- | | Caso creado | `case_created` | `syncCaseUpdates` | | Caso actualizado | `case_updated` | `syncCaseUpdates` | | Alerta promovida | `alert_promoted_to_case` | `syncCaseUpdates` | | Caso cerrado | `case_closed` | `syncCaseClose` | Los eventos se envían con `source: casebender:case` (o `casebender:alert`) y `sourcetype: _json` al índice configurado. ## Saliente: cerrar el notable de Splunk (write-back) Cuando se cierra un caso en CaseBender, el evento `case_closed` se envía al controlador de Splunk. Si el caso está vinculado a un notable de Splunk **y** `closeNotableOnCaseClose` está activado, CaseBender cierra el notable mediante la API REST de ES. ### Cómo se resuelve el notable vinculado El flujo de ingesta estampa `splunkEventId` (el `event_id` del notable) y el ID de la integración que lo ingirió en los `customFields` de cada alerta de Splunk. Al cerrar el caso, el controlador recopila esos ID de evento de las alertas vinculadas al caso, de modo que un caso promovido desde un notable sondeado o de webhook se resuelve automáticamente, sin importar cómo se creó. ### Qué se envía CaseBender llama al endpoint `notable_update` de ES: ``` POST https://:8089/services/notable_update ruleUIDs=["", ...]&status=&comment=&output_mode=json ``` * `status` es por defecto **5 (Cerrado)** y se puede configurar mediante `notableStatusOnClose`. * `comment` es: `Case closed in CaseBender with resolution: `. El resultado (notables cerrados, o un error) se escribe en la línea de tiempo del caso para que los analistas puedan confirmar la sincronización. `syncCaseClose` (evento de auditoría por HEC) y `closeNotableOnCaseClose` (write-back del notable por REST) son conmutadores independientes por integración. El write-back del notable requiere la conexión REST de Enterprise Security y un rol con la capacidad `edit_notable_events`. ## Consideraciones de seguridad * **Gestión de tokens** — los tokens HEC y los tokens/contraseñas REST se almacenan en la configuración de la integración; rótelos según la programación de su organización y actualice la integración cuando lo haga. * **Privilegio mínimo** — el rol REST solo necesita acceso de búsqueda a su índice de notables y `edit_notable_events`. Los tokens HEC deberían apuntar a un índice dedicado. * **Claves de webhook** — trate la clave de API `sk_splunk_` como un secreto. Rótela si se expone y actualice la acción de alerta de Splunk. * **TLS** — prefiera certificados de confianza. Si debe usar certificados autofirmados (común on-premise), puede desactivar **Verify SSL**; la conexión sigue cifrada, pero el certificado no se valida. Restrinja la salida a sus endpoints HEC y de administración de Splunk. ## Solución de problemas Confirme la URL y el token de HEC, que HEC esté habilitado y que CaseBender pueda alcanzar el puerto HEC (normalmente `8088`). Si Splunk usa un certificado autofirmado, desactive **Verify SSL**; de lo contrario, la solicitud falla con un error de certificado. Falta el encabezado `Authorization: Bearer` (o `x-api-key`) o no es válido. Confirme que está enviando la clave `sk_splunk_` que coincide con la clave de API de webhook configurada en la integración. Confirme que **Enable automatic polling** está activado, que la conexión **ES REST** está completa y que hay una **consulta de búsqueda** definida. Verifique que el rol pueda ejecutar la búsqueda y alcanzar el puerto de administración (normalmente `8089`), y que haya resultados más recientes que el cursor. En la primera ejecución solo se importan resultados dentro de `pollingInitialLookbackHours`. Revise el último estado de sincronización de la integración para ver el error específico. Asegúrese de que `closeNotableOnCaseClose` esté activado y de que la conexión **ES REST** esté configurada con un rol que tenga `edit_notable_events`. El caso debe estar vinculado a un notable de Splunk; al cerrar un caso promovido desde un notable sondeado/de webhook, el vínculo se resuelve automáticamente. Revise la línea de tiempo del caso para ver el resultado de la sincronización. Un `403` significa que el rol REST carece de la capacidad `edit_notable_events`. Un `404` normalmente significa que la URL no es el endpoint de administración de Enterprise Security; confirme que `restUrl` apunta al puerto de administración de Splunk con ES instalado. En redes de solo proxy, agregue su host interno de Splunk a `NO_PROXY` para que la conexión sea directa y desactive **Verify SSL** si el certificado es autofirmado. ## Documentación relacionada * [Descripción general de integraciones](./introduction.mdx) * [Splunk HTTP Event Collector](https://docs.splunk.com/Documentation/Splunk/latest/Data/UsetheHTTPEventCollector) * [Acciones de eventos notables de Splunk ES](https://docs.splunk.com/Documentation/ES/latest/User/Triagenotableevents)