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

En este artículo se describe cómo identificar, comparar y migrar las reglas de detección de QRadar a las reglas integradas de Microsoft Sentinel. Te guía en el inventario de tus detecciones existentes, comparando la terminología de las reglas entre QRadar y Microsoft Sentinel, y eligiendo la ruta de migración correcta, ya sea adoptando plantillas de analítica integradas desde el Content Hub, convirtiendo consultas con una herramienta online o escribiendo consultas personalizadas para Kusto Query Language (KQL). Al final, tendrás un enfoque estructurado para migrar tus reglas de detección aprovechando las analíticas de aprendizaje automático de Microsoft Sentinel.

Identificación y migración de reglas

Microsoft Sentinel usa análisis de aprendizaje automático para crear incidentes de alta fidelidad y accionables, y algunas de las detecciones existentes pueden ser redundantes en Microsoft Sentinel. Por lo tanto, no migren todas sus reglas de detección y análisis a ciegas. Revise estas consideraciones 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 que no hayan desencadenado ninguna alerta en 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.
• Use la funcionalidad existente y compruebe si las reglas de análisis integradas de Microsoft Sentinel podrían abordar los casos de uso actuales. Dado que Microsoft Sentinel usa análisis de aprendizaje automático para generar incidentes de alta fidelidad y accionables, es probable que algunas de las detecciones existentes ya no sean necesarias.
• Confirme los orígenes de datos 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.
• Consulte los recursos de la comunidad, como SOC Prime Threat Detection Marketplace, para comprobar si sus reglas están disponibles.
• Considere si un convertidor de consultas en línea como Uncoder.io puede servir para sus reglas.
• Si las reglas no están disponibles o no se pueden convertir, deben crearse manualmente mediante una consulta KQL. Consulte la asociación de reglas para crear nuevas consultas.

Obtenga más información sobre los procedimientos recomendados para migrar reglas de detección.

Para migrar las reglas de análisis 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 integradas en el Centro de contenido:

   • Si las reglas integradas son suficientes, instale las soluciones pertinentes y use las plantillas para crear reglas para el área de trabajo.

     1. En Microsoft Sentinel, vaya a Administración de contenido > Centro de contenido.
     2. Busque e instale la regla de análisis pertinente.

     Para obtener más información, consulte Descubrir y administrar el contenido integrado de Microsoft Sentinel y Crear reglas de análisis programadas a partir de plantillas.

   • Si tiene detecciones que no están cubiertas por las reglas integradas disponibles en el Centro de contenido, pruebe con un convertidor de consultas en línea, como Uncoder.io para convertir las consultas en KQL.

     Identifique la condición del desencadenador y la acción de regla y, a continuación, construya y revise la consulta KQL.

   • Si ni las soluciones de Content Hub ni un convertidor de reglas en línea son suficientes, deberá crear la regla manualmente. En tales casos, siga estos pasos para empezar a crear la regla:

     1. Identifique los orígenes de datos que desea usar en la regla. Deberá crear una tabla de correspondencias entre los orígenes de datos y las tablas de Microsoft Sentinel para identificar las tablas que desea consultar.

     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. En esta fase, es posible que quiera usar plantillas de regla como ejemplos para construir las consultas KQL como ejemplos sobre cómo 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, es posible que quiera revisar el KQL y probarlo de nuevo.

4. Cuando esté satisfecho, puede considerar la regla migrada. 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.

Para obtener más información sobre las reglas de análisis de Microsoft Sentinel y KQL, consulte los siguientes recursos:

• Reglas de análisis programadas en Microsoft Sentinel: Utiliza agrupación de alertas para reducir la fatiga de alertas agrupando alertas que ocurren dentro de un plazo determinado.
• Mapear campos de datos a entidades en Microsoft Sentinel: Para permitir que los ingenieros SOC definan entidades como parte de la evidencia a seguir durante una investigación. La asignación de entidades también permite a los analistas del SOC aprovechar un intuitivo grafo de investigación que puede ayudar a reducir el tiempo y el esfuerzo necesarios.
• Investigar incidentes con datos de la UEBA: Como ejemplo de cómo usar pruebas para mostrar eventos, alertas y cualquier marcador asociado a un incidente concreto en el panel de vista previa del incidente.
• Lenguaje de Consulta Kusto (KQL): Que puedes usar para enviar solicitudes de solo lectura a tu base de datos 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

Esta tabla le ayuda a aclarar el concepto de una regla en Microsoft Sentinel en comparación con QRadar. Los tipos de reglas de Microsoft Sentinel incluyen consultas programadas, Fusion (que correlaciona automáticamente alertas de múltiples fuentes de datos con incidentes usando machine learning), Seguridad de Microsoft y Machine Learning (ML) Behavior Analytics.

Relacionar y comparar ejemplos de reglas

Use estos ejemplos para comparar y asignar reglas de QRadar a Microsoft Sentinel en varios escenarios. Las consultas de ejemplo están escritas en el Lenguaje de Consultas Kusto (KQL), el lenguaje de consulta utilizado por Microsoft Sentinel.

Sintaxis común de las pruebas de propiedades

Esta es la sintaxis de QRadar para una regla de pruebas de propiedades comunes.

Pruebas de propiedades comunes: ejemplo de expresión regular (QRadar)

Esta es la sintaxis de una regla de prueba de propiedades comunes de QRadar de ejemplo que usa una expresión regular:

when any of <these properties> match <this regular expression>

Aquí tienes la regla de ejemplo en QRadar:

Pruebas de propiedades comunes: ejemplo de expresión regular (KQL)

Esta es la regla de pruebas de propiedades comunes con una expresión regular en KQL.

CommonSecurityLog
| where tostring(SourcePort) matches regex @"\d{1,5}" or tostring(DestinationPort) matches regex @"\d{1,5}"

Pruebas de propiedades comunes: ejemplo de consulta de filtro de AQL (QRadar)

Aquí tienes la sintaxis de una regla de ejemplo de pruebas de propiedades comunes de QRadar que utiliza una consulta de filtro AQL:

when the event matches <this> AQL filter query

Aquí tienes la regla de ejemplo en QRadar:

Pruebas de propiedades comunes: ejemplo de consulta de filtro de AQL (KQL)

Aquí está la regla común de pruebas de propiedades con una consulta de filtro AQL en KQL:

CommonSecurityLog
| where SourceIP == '10.1.1.10'

Comprobaciones de propiedades comunes: ejemplo de igual/no igual (QRadar)

Aquí tienes la sintaxis de una regla de ejemplo de pruebas de propiedades comunes de QRadar que utiliza el equals operador o not equals :

and when <this property> <equals/not equals> <this property>

Aquí tienes la regla de ejemplo en QRadar:

Comprobaciones de propiedades comunes: ejemplo de igual/no igual (KQL)

Aquí está la regla común de pruebas de propiedad con el equals operador o not equals en KQL:

CommonSecurityLog
| where SourceIP == DestinationIP

Sintaxis de pruebas de fecha y hora

Aquí tienes la sintaxis de QRadar para una regla de pruebas de fecha/hora:

Pruebas de fecha y hora: ejemplo de día seleccionado del mes (QRadar)

Aquí tienes la sintaxis de una regla de ejemplo de pruebas de fecha/hora de QRadar que utiliza un día seleccionado del mes:

and when the event(s) occur <on/after/before> the <selected> day of the month

Aquí tienes la regla de ejemplo en QRadar:

Pruebas de fecha y hora: ejemplo de día seleccionado del mes (KQL)

Aquí tienes la regla de las pruebas de fecha/hora con un día seleccionado del mes en KQL:

SecurityEvent
 | where dayofmonth(TimeGenerated) < 4

Pruebas de fecha y hora: ejemplo de día seleccionado de la semana (QRadar)

Esta es la sintaxis de una regla de prueba de fecha y hora de QRadar de ejemplo que usa un día seleccionado de la semana:

and when the event(s) occur on any of <these days of the week{Monday, Tuesday, Wednesday, Thursday, Friday, Saturday, Sunday}>

Aquí tienes la regla de ejemplo en QRadar:

Pruebas de fecha y hora: ejemplo de día de la semana seleccionado (KQL)

Aquí tienes la regla de las pruebas de fecha/hora con un día de la semana seleccionado en KQL:

SecurityEvent
 | where dayofweek(TimeGenerated) between (3d .. 5d)

Pruebas de fecha y hora: después/antes/en el ejemplo (QRadar)

Aquí tienes la sintaxis de una regla de ejemplo de pruebas de fecha/hora de QRadar que utiliza el after, before, u at operador:

and when the event(s) occur <after/before/at> <this time{12.00AM, 12.05AM, ...11.50PM, 11.55PM}>

Aquí tienes la regla de ejemplo en QRadar:

Pruebas de fecha y hora: ejemplo Después de/antes de/el (KQL)

Aquí está la regla de pruebas de fecha/hora que utiliza el after, before, o at el operador en KQL:

SecurityEvent
| where format_datetime(TimeGenerated,'HH:mm')=="23:55"

TimeGenerated está en UTC/GMT.

Sintaxis de pruebas de propiedades de eventos

Aquí tienes la sintaxis de QRadar para una regla de prueba de propiedades de evento:

Pruebas de propiedades de evento: ejemplo de protocolo IP (QRadar)

Aquí tienes la sintaxis de una regla de ejemplo de pruebas de propiedades de eventos QRadar que utiliza un protocolo IP:

and when the IP protocol is one of the following <protocols>

Aquí tienes la regla de ejemplo en QRadar:

Pruebas de propiedades de evento: ejemplo de protocolo IP (KQL)

Aquí está la regla de pruebas de propiedades de evento con un filtro de protocolo IP en KQL:

CommonSecurityLog
| where Protocol in ("UDP","ICMP")

Pruebas de propiedades de evento: ejemplo de cadena de carga de eventos (QRadar)

Aquí tienes la sintaxis de una regla de ejemplo de pruebas de propiedades de eventos QRadar que utiliza un Event Payload valor de cadena:

and when the Event Payload contains <this string>

Aquí tienes la regla de ejemplo en QRadar:

Pruebas de propiedades de evento: ejemplo de cadena de carga de eventos (KQL)

Aquí está la regla de pruebas de propiedades de evento con una cadena Event Payload en KQL. Para optimizar el rendimiento, evite usar el search comando si ya conoce el nombre de la tabla.

CommonSecurityLog
| where DeviceVendor has "Palo Alto"

search "Palo Alto"

Funciones: sintaxis de los contadores

Aquí está la sintaxis QRadar para una regla de funciones que utiliza contadores:

Contadores: ejemplo de propiedad de evento y hora (QRadar)

Aquí tienes la sintaxis de una regla de ejemplo de funciones QRadar que utiliza un número definido de propiedades de eventos en un número definido de minutos"

and when at least <this many> events are seen with the same <event properties> in <this many> <minutes>

Aquí tienes la regla de ejemplo en QRadar:

Contadores: ejemplo de propiedad de evento y hora (KQL)

Aquí está la regla de los contadores con propiedades de evento y condiciones de tiempo en KQL:

CommonSecurityLog
| summarize Count = count() by SourceIP, DestinationIP
| where Count >= 5

Funciones: sintaxis de condiciones negativas

Aquí está la sintaxis QRadar para una regla de funciones que utiliza condiciones negativas:

Ejemplo de condiciones negativas (QRadar)

Aquí tienes la sintaxis de una regla de ejemplo de funciones QRadar que utiliza condiciones negativas:

and when none of <these rules> match in <this many> <minutes> after <these rules> match with the same <event properties>

Estas son dos reglas definidas en QRadar. Las condiciones negativas se basan en estas reglas:

Aquí tienes un ejemplo de la regla de condiciones negativas basada en las dos reglas QRadar previamente definidas (Test2 y Test6):

Ejemplo de condiciones negativas (KQL)

Aquí está la regla de condiciones negativas con una rightanti unión en KQL:

let spanoftime = 10m;
let Test2 = (
CommonSecurityLog
| where Protocol !in ("UDP","ICMP")
| where TimeGenerated > ago(spanoftime)
);
let Test6 = (
CommonSecurityLog
| where SourceIP == DestinationIP
);
Test2
| join kind=rightanti Test6 on $left. SourceIP == $right. SourceIP and $left. Protocol ==$right. Protocol

Funciones: sintaxis de condiciones sencillas

Aquí está la sintaxis QRadar para una regla de funciones que usa condiciones simples:

Ejemplo de condiciones simples (QRadar)

Aquí tienes la sintaxis de una regla de ejemplo de funciones QRadar que utiliza condiciones simples:

and when an event matches <any|all> of the following <rules>

Aquí tienes la regla de ejemplo en QRadar:

Ejemplo de condiciones simples (KQL)

Aquí tienes la regla de condiciones sencillas en KQL:

CommonSecurityLog
| where Protocol !in ("UDP","ICMP") or SourceIP == DestinationIP

Sintaxis de pruebas de IP o puerto

Aquí tienes la sintaxis QRadar para una regla de pruebas de IP/puerto:

Pruebas ip/puerto: ejemplo de puerto de origen (QRadar)

Aquí tienes la sintaxis de una regla de ejemplo de QRadar que especifica un puerto fuente:

and when the source port is one of the following <ports>

Aquí tienes la regla de ejemplo en QRadar:

Pruebas ip/puerto: ejemplo de puerto de origen (KQL)

Aquí está la regla de pruebas IP/puerto con un filtro de puerto fuente en KQL:

CommonSecurityLog
| where SourcePort == 20

Pruebas de IP o puerto: ejemplo de IP de origen (QRadar)

Aquí tienes la sintaxis de una regla de ejemplo de QRadar que especifica una IP fuente:

and when the source IP is one of the following <IP addresses>

Aquí tienes la regla de ejemplo en QRadar:

Pruebas de IP o puerto: ejemplo de IP de origen (KQL)

Aquí está la regla de pruebas IP/puerto con un filtro IP de origen en KQL:

CommonSecurityLog
| where SourceIP in ("10.1.1.1","10.2.2.2")

Sintaxis de las pruebas del origen del registro

Aquí está la sintaxis QRadar para una regla de pruebas de código fuente de registro:

Ejemplo de origen de registro (QRadar)

Aquí tienes la sintaxis de una regla de ejemplo de QRadar que especifica las fuentes de registro:

and when the event(s) were detected by one or more of these <log source types>

Aquí tienes la regla de ejemplo en QRadar:

Ejemplo de fuente de registro (KQL)

Aquí está la regla de pruebas de fuente de registro en KQL.

OfficeActivity
| where OfficeWorkload == "Exchange"

Paso siguiente