Migración de reglas de detección de Splunk a Microsoft Sentinel

Las reglas de detección de Splunk son componentes de administración de eventos e información de seguridad (SIEM) que se comparan con las reglas de análisis de Microsoft Sentinel. Este artículo describe los conceptos utilizados para identificar, comparar y migrar las reglas de detección de Splunk a Microsoft Sentinel. La mejor manera de migrar las reglas de detección de Splunk a Microsoft Sentinel es empezar con la experiencia de migración de SIEM, que identifica reglas de análisis predefinidas (OOTB) para su traducción automática.

Si desea migrar la implementación de Splunk Observability, obtenga más información sobre cómo migrar de Splunk a Azure Monitor Logs.

Reglas de auditoría

Microsoft Sentinel usa análisis de aprendizaje automático para crear incidentes de alta fidelidad y accionables. Algunas de tus detecciones de Splunk existentes pueden ser redundantes en Microsoft Sentinel, así que no migres todas las detecciones de Splunk a ciegas. Revise las siguientes consideraciones de auditoría de reglas a medida que identifique las reglas de detección existentes.

• Asegúrese de seleccionar casos de uso que justifiquen la migración de reglas, teniendo en cuenta la prioridad empresarial y la eficacia.
• Compruebe que comprende los tipos de regla de Microsoft Sentinel.
• Compruebe que comprende la terminología de la regla.
• Revise las reglas obsoletas que no tienen alertas durante los últimos 6-12 meses y determine si siguen siendo pertinentes.
• Elimine las amenazas o alertas de bajo nivel que se omiten de forma rutinaria.
• Microsoft Sentinel Analytics requieren que el tipo de datos esté presente en el área de trabajo de Log Analytics antes de habilitar una regla. Confirme que los orígenes de datos necesarios están conectados y revise los métodos de conexión de datos. Vuelva a consultar las conversaciones de recopilación de datos para garantizar la profundidad y amplitud de los datos en los casos de uso que tiene previsto detectar. A continuación, utilice la experiencia de migración de SIEM para asegurarse de que las fuentes de datos se asignen correctamente.

Migración de reglas

Después de identificar las detecciones de Splunk que se van a migrar, revise las siguientes consideraciones sobre el proceso de migración:

• Compare la funcionalidad existente de las reglas de análisis de OOTB de Microsoft Sentinel con los casos de uso actuales. Utilice la experiencia de migración de SIEM para ver qué detecciones de Splunk se convierten automáticamente en plantillas OOTB.
• Traduzca las detecciones que no se alinean con las reglas analíticas OOTB. La mejor manera de traducir automáticamente las detecciones de Splunk es mediante la experiencia de migración de SIEM.
• Descubra más algoritmos para los casos de uso mediante la exploración de recursos de la comunidad, como soc Prime Threat Detection Marketplace.
• Traduzca manualmente las detecciones si las reglas integradas no están disponibles o no se traducen automáticamente. Cree las nuevas consultas de KQL y revise la asignación de reglas.

Para obtener más información, consulte procedimientos recomendados para migrar reglas de detección.

Pasos de migración de reglas

Siga estos pasos para validar, traducir y probar cada regla de detección de Splunk durante la migración a Microsoft Sentinel.

1. Compruebe que tiene un sistema de pruebas en su lugar para cada regla que quiera migrar.

   1. Prepare un proceso de validación para las reglas migradas, incluidos los escenarios de prueba completos y los scripts.

   2. Asegúrese de que el equipo tiene recursos útiles para probar las reglas migradas.

   3. Confirme que tiene conectados los orígenes de datos necesarios y revise los métodos de conexión de datos.

2. Compruebe si las detecciones están disponibles como plantillas OOTB en Microsoft Sentinel:

   • Utilice la experiencia de migración de SIEM para automatizar la conversión y la instalación de las plantillas OOTB.

     Para obtener más información, consulte Usar la experiencia de migración de SIEM.

   • Si tiene casos de uso que no se reflejan en las detecciones, cree reglas para su propio área de trabajo con plantillas de regla OOTB.

     En Microsoft Sentinel, vaya al centro de contenido.

     Filtrar el tipo de contenido para las plantillas de reglas de Analytics.

     Busque e instale o actualice cada solución de Content Hub correspondiente o plantilla de regla de análisis independiente.

     Para más información, consulte Detección de amenazas integrada.

   • Si tiene detecciones que no están cubiertas por las reglas OOTB de Microsoft Sentinel, pruebe primero la experiencia de migración SIEM para la traducción automática.

   • Si ni las reglas OOTB ni la migración de SIEM convierten completamente la detección, cree la regla manualmente. Siga estos pasos para crear la regla:

     1. Identifique los orígenes de datos que desea usar en la regla. Identifique las tablas Microsoft Sentinel que desea consultar mediante la creación de una tabla de asignación entre orígenes de datos y tablas de datos.

     2. Identifique los atributos, campos o entidades de los datos que quiera usar en las reglas.

     3. Identifique los criterios y la lógica de la regla. Al identificar los criterios de regla y la lógica, considere la posibilidad de usar plantillas de regla como ejemplos para construir las consultas KQL.

        Considere los filtros, las reglas de correlación, las listas activas, los conjuntos de referencia, las listas de seguimiento, las anomalías de detección, las agregaciones, etc. Puede utilizar las referencias proporcionadas por su SIEM heredado para comprender cómo adaptar mejor la sintaxis de sus consultas.

     4. Identifique la condición de activación y la acción de la regla y, a continuación, cree y revise la consulta KQL. Al revisar la consulta, considere la posibilidad de usar los recursos de guía de optimización de KQL.

3. Pruebe la regla con cada uno de los casos de uso pertinentes. Si no proporciona los resultados esperados, revise y edite el KQL y pruébelo de nuevo.

4. Cuando esté satisfecho, considere que la regla se ha migrado. Cree un cuaderno de estrategias para la acción de regla según sea necesario. Para obtener más información, consulte Automatización de la respuesta a amenazas con cuadernos de estrategias en Microsoft Sentinel.

Más información sobre las reglas de análisis:

• Cree reglas de análisis personalizadas para detectar amenazas. Use la agrupación de alertas para reducir la fatiga de alertas mediante la agrupación de alertas que se producen dentro de un período de tiempo determinado.
• Asignación de campos de datos a entidades en Microsoft Sentinel para permitir que los ingenieros de SOC definan entidades como parte de la evidencia para realizar un seguimiento durante una investigación. La asignación de entidades también permite a los analistas de SOC aprovechar un [gráfico de investigación [investigation graph] (investigate-cases.md#use-the-investigation-graph-to-deep-dive) intuitivo que puede ayudar a reducir el tiempo y el esfuerzo.
• Investigue los incidentes con datos de UEBA, como ejemplo de cómo usar pruebas para exponer eventos, alertas y marcadores asociados a un incidente determinado en el panel de vista previa del incidente.
• Lenguaje de consulta Kusto (KQL), que puede usar para enviar solicitudes de solo lectura a la base de datos de Log Analytics para procesar datos y devolver resultados. KQL también se usa en otros servicios de Microsoft, como Microsoft Defender para punto de conexión y Application Insights.

Comparación de la terminología de reglas

En la tabla de comparación siguiente se aclara cómo una regla basada en KQL en Microsoft Sentinel corresponde a una detección basada en SPL en Splunk.

Relacionar y comparar ejemplos de reglas

Utiliza las tablas de ejemplo de SPL a KQL y ejemplos de esta sección para comparar y mapear las reglas de Splunk a Microsoft Sentinel en varios escenarios.

Compara comandos comunes de búsqueda Splunk con ejemplos de KQL

Esta tabla asigna los comandos comunes de búsqueda SPL a sus equivalentes KQL en Microsoft Sentinel.

lookup comando: ejemplo de KQL

Este ejemplo de KQL se utiliza externaldata para replicar el patrón SPL lookup filtrando a los usuarios contra una fuente de datos externa.

Users 
| where UserID in ((externaldata (UserID:string) [
@"https://storageaccount.blob.core.windows.net/storagecontainer/users.txt" 
h@"?...SAS..." // Secret token to access the blob 
])) | ... 

stats comando: ejemplo de KQL

Este ejemplo de KQL se utiliza summarize para contar transacciones y sumar totales, agrupados por fruta y mes.

Sales 
| summarize NumTransactions=count(), 
Total=sum(UnitPrice * NumUnits) by Fruit, 
StartOfMonth=startofmonth(SellDateTime) 

mstats comando: ejemplo de KQL

Este ejemplo de KQL agrupa los valores métricos en rangos de precios y cuenta los registros de cada rango.

T | summarize count() by price_range=bin(price, 10.0) 

transaction command: ejemplo de SPL

Este ejemplo de SPL agrupa eventos relacionados de inicio y fin en una sola transacción por ID de actividad.

sourcetype=MyLogTable type=Event
| transaction ActivityId startswith="Start" endswith="Stop"
| Rename timestamp as StartTime
| Table City, ActivityId, StartTime, Duration

transaction comando: ejemplo de KQL

Este ejemplo de KQL replica el agrupamiento de transacciones SPL uniendo eventos de inicio y parada en un ID de actividad compartido y calculando la duración.

let Events = MyLogTable | where type=="Event";
Events
| where Name == "Start"
| project Name, City, ActivityId, StartTime=timestamp
| join (Events
| where Name == "Stop"
| project StopTime=timestamp, ActivityId)
on ActivityId
| project City, ActivityId, StartTime, 
Duration = StopTime – StartTime

Use row_window_session() para calcular los valores de inicio de sesión de una columna de un conjunto de filas serializado.

...| extend SessionStarted = row_window_session(
Timestamp, 1h, 5m, ID != prev(ID))

eventstats command: ejemplo de SPL

Este ejemplo de SPL calcula los conteos de eventos por categoría en contenedores de un minuto y luego añade un total por bin de tiempo usando eventstats.

… | bin span=1m _time
|stats count AS count_i by _time, category
| eventstats sum(count_i) as count_total by _time

eventstats comando: ejemplo de KQL

Aquí tienes un ejemplo con la instrucción join:

let binSize = 1h;
let detail = SecurityEvent 
| summarize detail_count = count() by EventID,
tbin = bin(TimeGenerated, binSize);
let summary = SecurityEvent
| summarize sum_count = count() by 
tbin = bin(TimeGenerated, binSize);
detail 
| join kind=leftouter (summary) on tbin 
| project-away tbin1

Aquí tienes un ejemplo con la instrucción make_list:

let binSize = 1m;
SecurityEvent
| where TimeGenerated >= ago(24h)
| summarize TotalEvents = count() by EventID, 
groupBin =bin(TimeGenerated, binSize)
|summarize make_list(EventID), make_list(TotalEvents), 
sum(TotalEvents) by groupBin
| mvexpand list_EventID, list_TotalEvents

anomalydetection command: ejemplo de SPL

Este ejemplo de SPL detecta anomalías en los datos históricos de precios de cierre durante un periodo de 10 años.

sourcetype=nasdaq earliest=-10y
| anomalydetection Close _ Price

anomalydetection comando: ejemplo de KQL

Este ejemplo de KQL utiliza funciones de análisis de series temporales para detectar anomalías en las tendencias de inicio de sesión de cuentas deshabilitadas durante un periodo de retroceso de siete días.

let LookBackPeriod= 7d;
let disableAccountLogon=SignIn
| where ResultType == "50057"
| where ResultDescription has "account is disabled";
disableAccountLogon
| make-series Trend=count() default=0 on TimeGenerated 
in range(startofday(ago(LookBackPeriod)), now(), 1d)
| extend (RSquare,Slope,Variance,RVariance,Interception,
LineFit)=series_fit_line(Trend)
| extend (anomalies,score) = 
series_decompose_anomalies(Trend)

Compara comandos Splunk eval comunes con equivalentes KQL

Esta tabla asigna funciones SPL eval comunes a sus equivalentes KQL en Microsoft Sentinel.

case(X,"Y",…) Ejemplo de SPL

Este ejemplo de SPL devuelve una cadena de mensajes diferente basada en el código de error HTTP.

case(error == 404, "Not found",
error == 500,"Internal Server Error",
error == 200, "OK")

case(X,"Y",…) Ejemplo de KQL

Este ejemplo de KQL se utiliza case() para asignar un mensaje basado en el valor del código de error.

T
| extend Message = case(error == 404, "Not found", 
error == 500,"Internal Server Error", "OK") 

if(X,Y,Z) Ejemplo de KQL

Este ejemplo de KQL se utiliza iif() para indicar si una marca de tiempo corresponde al día actual.

iif(floor(Timestamp, 1d)==floor(now(), 1d), 
"today", "anotherday")

isint(X) Ejemplo de KQL

Este ejemplo de KQL comprueba si X tiene un tipo entero compatible usando gettype y iif.

iif(gettype(X) =="long","TRUE","FALSE")

isstr(X) Ejemplo de KQL

Este ejemplo de KQL comprueba si X es un valor de cadena usando gettype y iif.

iif(gettype(X) =="string","TRUE","FALSE")

like(X,"y") ejemplo

Estos ejemplos de KQL muestran varios operadores de emparejamiento de cadenas que puedes usar para replicar el emparejamiento de patrones SPL like .

… | where field has "addr"

… | where field contains "addr"

… | where field startswith "addr"

… | where field matches regex "^addr.*"

min(X,…) Ejemplo de KQL

Estos ejemplos de KQL muestran diferentes formas de calcular valores mínimos usando min_of, min, y arg_min.

min_of (expr_1, expr_2 ...)

…|summarize min(expr)

…| summarize arg_min(Price,*) by Product

mvfilter(X) Ejemplo de KQL

Este ejemplo de KQL se utiliza mv-apply para filtrar y reducir contenido multivalorado, similar a la función SPL mvfilter .

T | mv-apply Metric to typeof(real) on 
(
 top 2 by Metric desc
)

mvjoin(X,Y) Ejemplo de KQL

Este ejemplo de KQL se utiliza strcat_array para unir elementos de un array en una sola cadena con un separador personalizado.

strcat_array(dynamic([1, 2, 3]), "->")

relative time(X,Y) Ejemplo de KQL

Este ejemplo de KQL convierte un valor de fecha-hora a tiempo de época Unix para cálculos en tiempo relativo.

let toUnixTime = (dt:datetime)
{
(dt - datetime(1970-01-01))/1s 
};

replace(X,Y,Z) Ejemplo de KQL

Este ejemplo de KQL se utiliza replace() con un patrón regex para intercambiar las partes de mes y día de una cadena de fechas.

replace( @'^(\d{1,2})/(\d{1,2})/', @'\2/\1/',date)

strptime(X,Y) Ejemplo de KQL

Este ejemplo de KQL se utiliza format_datetime solo para mostrar las horas y minutos de un valor de fecha-hora.

format_datetime(datetime('2017-08-16 11:25:10'),
'HH:mm')

time() Ejemplo de KQL

Este ejemplo de KQL forma un valor de fecha-hora como una cadena de tiempo que muestra horas, minutos y segundos.

format_datetime(datetime(2015-12-14 02:03:04),
'h:m:s')

tostring(X,Y) descripción

La función SPL tostring(X,Y) convierte valores en cadenas y soporta varias opciones de formato. Devuelve un valor de campo de X como cadena.

• Si el valor de X es un número, X se vuelve a formatear en un valor de cadena.
• Si X es un valor booleano, X se vuelve a formatear en TRUE o FALSE.
• Si X es un número, el segundo argumento Y es opcional y puede ser hex (se convierte X en hexadecimal), commas (formatos con comas X y dos posiciones decimales) o duration (convierte X de un formato de tiempo en segundos a un formato de hora legible: HH:MM:SS).

tostring(X,Y) Ejemplo de SPL

Este tostring ejemplo de SPL devuelve:

foo=615 and foo2=00:10:15:

… | eval foo=615 | eval foo2 = tostring(
foo, "duration")

urldecode(X) Ejemplo de SPL

Este ejemplo de SPL decodifica una cadena codificada por URL para devolverla a su forma original.

urldecode("http%3A%2F%2Fwww.splunk.com%2Fdownload%3Fr%3Dheader")

Compara comandos Splunk stats comunes con equivalentes KQL

Esta tabla asigna funciones comunes de agregación SPL stats a sus equivalentes KQL en Microsoft Sentinel.

Pasos siguientes

Ha aprendido a identificar, comparar y asignar reglas de detección de Splunk a las reglas de análisis de Microsoft Sentinel. Continúe con la migración de su automatización SOAR.