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).Ingesta entrante
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).
Sincronización saliente
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.
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
Requisitos previos
1
Acceso a Splunk
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.2
Salida de red
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).3
Rol de administrador de CaseBender
Debe poder crear y administrar integraciones en Configuración → Integraciones.
Parte A — Preparar Splunk
1
Crear un token HEC (para el reenvío saliente)
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.
2
Crear un token de autenticación (para las funciones REST)
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
1
Abrir el catálogo de integraciones
Vaya a Configuración → Integraciones → Crear y elija Splunk en la categoría
SIEM.
2
Elegir un propósito
Configure
purpose como Inbound, Outbound o Bidirectional para mostrar las
tarjetas de configuración correspondientes.3
Configurar el webhook entrante (push)
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 <API_KEY>.4
Configurar la conexión REST de Enterprise Security (opcional)
En la tarjeta Enterprise Security REST API, ingrese la URL de administración (p. ej.
https://splunk:8089) y las credenciales:Esta conexión habilita tanto el sondeo como el cierre de notables.
5
Habilitar el sondeo automático (opcional)
En la tarjeta Automatic polling, active Enable automatic polling y configure:
Consulte Sondeo automático para saber cómo funciona.
6
Configurar la salida (HEC + cierre de notables)
En la tarjeta Outbound, ingrese la URL, el token y el índice de HEC, luego habilite:
7
Probar la conexión
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
1
Búsqueda programada
En cada intervalo (En la primera ejecución no hay cursor, por lo que se importan los resultados dentro de
pollingIntervalMinutes), CaseBender ejecuta searchQuery sobre la
ventana desde el último cursor mediante el endpoint de exportación en streaming:pollingInitialLookbackHours.2
Cursor + deduplicación
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.3
Normalización
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
Authorization: Bearer <key> (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 objetoresult más metadatos de la
búsqueda:
202 Accepted:
Flujo de procesamiento
1
Proxy de ingesta
/api/v1/ingest/splunk valida la fuente y reenvía la solicitud al servicio de ingesta
(POST /v1/sources/splunk).2
Publicación en cola
El servicio de ingesta autentica la clave de API, valida la carga y publica el registro en
la cola de procesamiento.
3
Normalización
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):
Extracción de observables / activos:
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:<security_domain> y app:<app>. Los registros
ingeridos usan por defecto TLP:2 y PAP:2.
Saliente: reenvío de auditoría por HEC
Cuando se habilita consyncCaseUpdates / 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:
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 eventocase_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 estampasplunkEventId (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 endpointnotable_update de ES:
statuses por defecto 5 (Cerrado) y se puede configurar mediantenotableStatusOnClose.commentes:Case <id> closed in CaseBender with resolution: <resolution>.
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
La prueba de conexión falla o expira
La prueba de conexión falla o expira
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.El sondeo está habilitado pero no aparecen notables
El sondeo está habilitado pero no aparecen notables
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.El cierre del caso no cierra el notable de Splunk
El cierre del caso no cierra el notable de Splunk
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.notable_update devuelve 403 o 404
notable_update devuelve 403 o 404
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.Errores de certificado autofirmado detrás de un proxy
Errores de certificado autofirmado detrás de un proxy
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.