Portabilidad de Reglas de Detección Entre SIEM, EDR y XDR

La portabilidad de reglas de detección es la práctica de escribir y gestionar la lógica de detección de amenazas para que se mueva entre plataformas SIEM, EDR y XDR sin una reescritura completa.

¿Qué pasa con mis reglas de detección cuando migro a una nueva plataforma SIEM?

Las reglas escritas en el lenguaje de consulta nativo de una plataforma no se trasladan. SPL permanece en Splunk. KQL permanece en Microsoft Sentinel. YARA-L permanece en Google SecOps. Cuando migra, esas reglas deben ser reescritas o traducidas para la plataforma de destino.

La fidelidad de la traducción depende del constructo, no del par de idiomas. Dos ejes de degradación deciden lo que sobrevive.

Eje 1: mapeo de campos. Los taxonomías de campos de origen (CIM, ASIM, ECS, OCSF, nativo de Sysmon, nativo del proveedor) se mapean de manera incompleta. Un campo no mapeado o renombrado reduce o rompe silenciosamente la regla.

Eje 2: semántica de constructos. Las semánticas de agregación y ventanas de tiempo, la lógica de secuencia o transacción, el dialecto regex, y las funciones de estilo eval/lookup/join a menudo tienen solo análogos parciales en la plataforma objetivo. Este eje lleva la parte de reescritura.

Sigma las reglas están diseñadas para la traducción. Se redactan una vez y se traducen por backend a través de pySigma, sigma-cli, o Uncoder.

La traducción no es preservación. Cada regla traducida aún requiere validación específica del backend contra los campos analizados del destino antes de que se confíe. Una traducción sintácticamente correcta puede referirse a campos que la nueva plataforma nunca llena.

El enrutamiento de la canalización de telemetría es un mecanismo separado. Rutar una transmisión de registros a un nuevo destino no traslada la lógica de detección que se ejecutaba en ella. SPL permanece como SPL independientemente de dónde aterricen los registros.

¿Cuál es la diferencia entre las reglas de detección específicas de un proveedor y las agnósticas del proveedor?

Una regla específica del proveedor es un activo de la plataforma. Una regla agnóstica del proveedor es un activo del equipo.

Dimensión	SPL (Splunk)	KQL (Microsoft Sentinel)	YARA-L (Google SecOps)	Sigma
Se ejecuta nativamente en	Splunk	Microsoft Sentinel	Google SecOps	Ninguno directamente. Se traduce a los tres más IBM QRadar, Elastic, CrowdStrike y otros.
Moverlo requiere	Reescribir en el idioma de destino	Reescribir en el idioma de destino	Reescribir en el idioma de destino	Traducción mediante pySigma/sigma-cli o Uncoder, luego validación del mapeo de campos
Quién es el propietario	La implementación de Splunk	El espacio de trabajo de Sentinel	El inquilino de SecOps	Tu equipo, en el control de versiones
Costo multiplataforma	Escribir N copias	Escribir N copias	Escribir N copias	Traducir una vez por backend, validar una vez por backend

La diferencia de costo se muestra en la migración y en la operación multiplataforma. La lógica de detección agnóstica del proveedor permanece portátil a través de su pila.

¿Cómo migro el contenido de detección de Splunk a Microsoft Sentinel?

Seis pasos. Este es uno de los pares de idiomas más difíciles porque SPL y KQL difieren en el modelo de datos, el nombrado de campos y la semántica de funciones.

Inventario de reglas SPL. Exportar cada búsqueda guardada, alerta y búsqueda de correlación. Registrar las dependencias del modelo de datos de cada regla (tipo de fuente, índice, nombres de campos).

Clasificar por tipo de constructo. Ordenar reglas en tres cajas: lógica de selección simple (portabilidad limpia), dependiente de mapeo de campos (portabilidad con trabajo de mapeo) y lógica de correlación/estado (esperar una reescritura manual).

Traducir a través de Sigma. Convertir las reglas SPL a Sigma, luego traducir Sigma a KQL usando pySigma con el backend de Microsoft Sentinel, sigma-cli, o Uncoder. Esto maneja la sintaxis. No maneja el mapeo de campos.

Mapear campos contra el esquema de Sentinel. Alinear los nombres de campo de CIM a los equivalentes de ASIM. Microsoft documenta su esquema en learn.microsoft.com. Cada campo en la regla traducida debe resolver a una columna en la tabla de destino.

Probar en tablas de Sentinel. Ejecutar cada regla traducida con datos reales ingeridos. Conservar un evento de prueba por regla para que pueda verificar la coincidencia después de cualquier cambio de esquema.

Cortar con una ventana de ejecución paralela. Ejecutar ambas plataformas en las mismas fuentes de registros. Comparar la salida de alertas. Retirar la versión SPL solo después de que la versión KQL se active en los mismos eventos.

Antes del corte, mapear las reglas implementadas en ambas plataformas a MITRE ATT&CK técnicas y comparar los dos mapas, de modo que una técnica que se pierde en la migración se muestre antes del corte, no después; El de SOC Prime mapea detecciones implementadas y fuentes de datos a ATT&CK como servicio. de SOC Prime mapea detecciones implementadas y fuentes de datos a ATT&CK como servicio.

¿Migrar una biblioteca de reglas? Explora el Prime Architect de SOC Prime para la traducción de reglas multiplataforma, investigación de amenazas y flujos de trabajo de ingeniería de detección.

Contacto Ventas

¿Cuáles son las mejores prácticas para traducir lenguajes de consulta como SPL a KQL?

Traducir lógica, no sintaxis. Un puerto carácter por carácter produce reglas frágiles que hacen referencia a campos que el destino puede no llenar.

Mapear campos contra el esquema de destino. No suponga que los nombres de los campos se trasladan. Splunk CIM y Sentinel ASIM son contratos diferentes. El esfuerzo de migración reside en el mapeo entre ellos.
Mantener un evento de prueba por regla. Un evento conocido como malo emparejado con un evento conocido como benigno. Si la regla traducida no coincide con el malo y rechaza el benigno, algo se rompió en la traducción.
Revisar todo lo que el traductor marque. Los traductores automáticos manejan bien la lógica de selección simple. Las reglas de correlación, funciones propietarias y agregados complejos necesitan revisión humana.
Nombrar sus herramientas. Prime Architect traduce Sigma en 65 lenguajes de detección, migra entre lenguajes de consulta nativos como SPL y KQL, aplica presets de mapeo de campos para el entorno que conecta y despliega desde un repositorio de reglas gobernado en una plataforma objetivo compatible. La versión de código abierto Uncoder IO cubre el paso de la traducción y puede ejecutarse autohospedado (fuente en GitHub). Ninguno de los tres elimina la validación del mapeo de campos.

Ejemplo: una simple regla de creación de procesos que traduce EventCode=4688 y New_Process_Name (Splunk CIM) a EventID == 4688 y NewProcessName (tabla SecurityEvent de Sentinel). Mismo hecho, diferente nombre de campo por contrato de plataforma.

El comodín anclado al final de SPL se convierte en un operador endswith de KQL. Este par funciona porque es una coincidencia de campo de un solo evento. Las reglas de correlación no se traducen tan limpiamente.

¿Cuánto tiempo lleva migrar una biblioteca de reglas y qué lo impulsa?

Tres factores determinan el esfuerzo.

Conteo de reglas. Más reglas, más ciclos de validación. Cada regla traducida necesita una prueba contra los datos ingeridos de destino.

Campos personalizados y dependencias del modelo de datos. Las reglas que hacen referencia a campos específicos del proveedor, extracciones personalizadas o tablas de búsqueda requieren trabajo de mapeo por campo. Cuantas más personalizaciones haya en la fuente, más trabajo manual en la migración.

Esfuerzo de validación. Cada regla traducida debe ser validada contra los campos analizados de la plataforma de destino. Una traducción sintácticamente correcta puede fallar silenciosamente si el esquema de destino no llena el campo referenciado.

El entregable honesto de una evaluación de migración es una clasificación por regla: portabilidad limpia, portabilidad con trabajo de mapeo, o requiere una reescritura manual. Una única estimación de tiempo para toda la biblioteca tergiversa la distribución del esfuerzo.

¿Cómo evitar el bloqueo la próxima vez?

Tres prácticas.

Autor en Sigma. Escriba la lógica de detección agnóstica del proveedor desde el principio. Las reglas Sigma se traducen a todas las plataformas principales SIEM, EDR y XDR. El contenido de detección ya en Sigma, como las reglas Sigma en SOC Prime’s Core, mantiene la biblioteca portátil desde la primera regla.

Mantener la lógica en control de versiones. Almacene sus reglas de detección en Git junto con los mapeos de campos y eventos de prueba para cada backend de destino. Las reglas viajan con el equipo, no con la plataforma.

Traducir al desplegar. Use pySigma, sigma-cli o Uncoder para generar consultas nativas de la plataforma en el momento del despliegue. La fuente permanece portátil. La salida compilada es desechable.

Esta separación significa que una migración de plataforma cambia el objetivo de traducción, no la lógica de detección.

¿El enrutamiento de telemetría a través de una canalización es lo mismo que portar sus detecciones?

No. Una canalización de telemetría (Cribl y herramientas similares) mueve datos. No mueve la lógica de detección.

Rutar una transmisión de registros de Splunk a Microsoft Sentinel a través de una canalización entrega los eventos a un nuevo destino. Las reglas SPL que se ejecutaron en esos eventos en Splunk no se siguen. SPL permanece como SPL. La lógica de detección aún debe ser traducida o reescrita para la plataforma de destino.

La canalización de enrutamiento resuelve el problema de entrega de datos. La portabilidad de detección resuelve el problema de traducción lógica. Son independientes. Un equipo que enruta telemetría a un nuevo SIEM sin portar sus detecciones tiene datos en un nuevo lugar y no tiene reglas para coincidir con ellos.

La excepción es una canalización que ejecuta las detecciones por sí misma: Prime Detect de SOC Prime aplica reglas en Sigma en la capa de la canalización antes del SIEM, y su edición de código abierto está en GitHub.

Donde esto no se cumple

No todo se traduce, incluso con Sigma. Cuatro clases de constructos requieren reescrituras manuales en la plataforma de destino.

Lógica de correlación y estado. Cuenta y valor de agregación, secuencia temporal, correlación de eventos múltiples. Sigma agregó tipos de reglas de correlación en su especificación v2, pero el soporte de backend varía según el backend de pySigma. La programación versus la ejecución en streaming también cambia lo que una regla puede expresar.
Funciones propietarias. Transacción de Splunk, expresiones eval, enriquecimiento impulsado por búsqueda, macros. Los análogos de KQL son parciales.
Algunos patrones de agregación. Los constructos de umbral sobre ventana y estad… por… span= patrones se traducen de manera desigual a través de plataformas.
Referencias de campo contingentes al esquema. La misma regla de creación de procesos Sigma cae en un campo diferente según la canalización. En Sysmon es Image. En Splunk Windows Security es New_Process_Name. La traducción es correcta solo contra el esquema realmente implementado.

Estos constructos son donde la clasificación por regla importa más. Espere que requieran validación manual y, en muchos casos, una reescritura desde cero.

Lista de verificación de preparación para la migración

[ ] Inventario completo de reglas exportadas (búsquedas guardadas, alertas, búsquedas de correlación)

[ ] Cada regla clasificada: portabilidad limpia / portabilidad con mapeo / se requiere reescritura

[ ] Tabla de mapeo de campos construida: esquema de origen a esquema de destino

[ ] Versiones Sigma de reglas portátiles creadas y almacenadas en control de versiones

[ ] Herramientas de traducción seleccionadas (pySigma/sigma-cli, Uncoder, o ambos)

[ ] Pares de eventos de prueba creados por regla (uno conocido como malo, uno conocido como benigno)

[ ] Reglas traducidas validadas contra tablas de destino con datos reales ingeridos

[ ] Reglas de correlación y estado identificadas para reescritura manual

[ ] Funciones propietarias catalogadas (transacción, eval, búsquedas, macros)

[ ] Ventana de ejecución paralela definida: ambas plataformas ingiriendo las mismas fuentes

[ ] Criterios de comparación de salidas de alerta documentados

[ ] Plan de reversión definido: condiciones para volver a la plataforma de origen

FAQ

¿Qué pasa con mis reglas de detección cuando migro a una nueva plataforma SIEM?

Las reglas nativas de la plataforma no se trasladan. SPL, KQL y YARA-L deben ser reescritas o traducidas para la plataforma de destino. Una regla redactada en Sigma se traduce una vez por backend y cada regla traducida aún necesita validación contra los campos analizados del destino. La correlación, la lógica de estado, las funciones propietarias y algunos patrones de agregación no se traducen limpiamente.

¿Cómo migro el contenido de detección de Splunk a Microsoft Sentinel?

Inventaría las reglas SPL, clasifica cada una por tipo de constructo, traduce a través de Sigma con pySigma o Uncoder, mapea campos del esquema de Splunk al de Sentinel, prueba cada regla con datos reales ingeridos en Sentinel, luego realiza el corte con una ventana de ejecución paralela antes de retirar la versión SPL. Microsoft documenta el esquema de Sentinel en learn.microsoft.com.

¿Cuál es la diferencia entre las reglas de detección específicas del proveedor y las reglas agnósticas del proveedor?

Una regla específica del proveedor es un activo de la plataforma en la que se ejecuta. Una regla agnóstica del proveedor redactada en Sigma es un activo del equipo, mantenida en control de versiones y traducida por backend. La diferencia de costo se muestra en la migración y en la operación multiplataforma.

¿El enrutamiento de telemetría a través de una canalización hace que mis detecciones sean portátiles?

No. Una canalización de telemetría mueve datos a un nuevo destino. No mueve la lógica de detección que se ejecutaba en ella. SPL permanece como SPL dondequiera que aterricen los registros, por lo que las reglas aún necesitan traducción o una reescritura.

¿Cuáles son las mejores prácticas para traducir un lenguaje de consulta como SPL a KQL?

Traduce la lógica, no la sintaxis. Mapea cada campo contra el esquema de destino, mantén un evento de prueba conocido como malo y un conocido como benigno por regla, y revisa todo lo que el traductor marque, porque las reglas de correlación y las funciones propietarias necesitan revisión humana. pySigma, sigma-cli y Uncoder manejan la traducción de Sigma, y ninguno de ellos elimina la validación del mapeo de campos.

Evalúe su cobertura actual de SIEM y cree un plan para su transición utilizando Prime Hunt. Prime Hunt revisa todas sus reglas de SIEM, identifica brechas y le traza un recorrido hacia una cobertura completa, trabajo crítico antes de una migración de SIEM.