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

En este artículo se describe cómo identificar, comparar y migrar las reglas de detección de ArcSight a Microsoft Sentinel reglas de análisis.

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 migre todas las 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.
• Explore los recursos de la comunidad, como SOC Prime Threat Detection Marketplace , para comprobar si las reglas están disponibles.
• Considere si un convertidor de consultas en línea, como Uncoder.io, puede funcionar para las reglas.
• Si las reglas no están disponibles o no se pueden convertir, deben crearse manualmente mediante una consulta KQL. Revise la asignació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 Microsoft Sentinel:

   • Si las reglas integradas son suficientes, use plantillas de reglas integradas para crear reglas para su propio área de trabajo.

     En Microsoft Sentinel, vaya a la pestaña Plantillas de regla de Configuration > Analytics > y cree y actualice cada regla de análisis pertinente.

     Para obtener más información, consulte Creación de reglas de análisis programadas a partir de plantillas.

   • Si tiene detecciones que no están cubiertas por las reglas integradas de Microsoft Sentinel, 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 no basta con las reglas integradas ni con un convertidor de reglas en línea, deberá crearla 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. Querrá crear una tabla de asignación entre orígenes de datos y tablas de datos en 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 desee usar plantillas de regla como ejemplos para construir las consultas de 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 usar las referencias proporcionadas por el SIEM heredado para comprender cómo asignar mejor la sintaxis de consulta.

     4. Identifique la condición del desencadenador y la acción de regla y, a continuación, construya 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.

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

• Reglas de análisis programadas en Microsoft Sentinel. 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.
• Asigne campos de datos a entidades de Microsoft Sentinel para permitir que los ingenieros de SOC definan entidades como parte de la evidencia que se va a realizar durante una investigación. La asignación de entidades también permite a los analistas de SOC aprovechar un gráfico de investigación 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

Esta tabla le ayuda a aclarar el concepto de una regla en Microsoft Sentinel en comparación con ArcSight.

Asignación y comparación de ejemplos de reglas

Use estos ejemplos para comparar y asignar reglas de ArcSight a Microsoft Sentinel en varios escenarios.

Ejemplo de filtro (AND): ArcSight

Esta es una regla de filtro de ejemplo con AND condiciones en ArcSight.

Ejemplo de filtro (AND): KQL

Esta es la regla de filtro con AND condiciones en KQL.

SecurityEvent
| where EventID == 4728
| where SubjectUserName =~ "AutoMatedService"
| where isnotempty(SubjectDomainName)

En esta regla se supone que el agente de supervisión de Azure (AMA) recopila los eventos de Seguridad de Windows. Por lo tanto, la regla usa la tabla Microsoft Sentinel SecurityEvent.

Tenga en cuenta estos procedimientos recomendados:

• Para optimizar las consultas, evite operadores que no distinguen mayúsculas de minúsculas cuando sea posible: =~.
• Use == si el valor no distingue mayúsculas de minúsculas.
• Ordene los filtros empezando por la where instrucción , que filtra la mayoría de los datos.

Ejemplo de filtro (OR): ArcSight

Esta es una regla de filtro de ejemplo con OR condiciones en ArcSight.

Ejemplo de filtro (OR): KQL

Estas son algunas maneras de escribir la regla de filtro con OR condiciones en KQL.

Como primera opción, use la in instrucción :

SecurityEvent
| where SubjectUserName in
 ("Adm1","ServiceAccount1","AutomationServices")

Como segunda opción, use la or instrucción :

SecurityEvent
| where SubjectUserName == "Adm1" or 
SubjectUserName == "ServiceAccount1" or 
SubjectUserName == "AutomationServices"

Aunque ambas opciones son idénticas en el rendimiento, se recomienda la primera opción, que es más fácil de leer.

Ejemplo de filtro anidado: ArcSight

Esta es una regla de filtro anidada de ejemplo en ArcSight.

Esta es una regla para el /All Filters/Soc Filters/Exclude Valid Users filtro.

Ejemplo de filtro anidado: KQL

Estas son algunas maneras de escribir la regla de filtro con OR condiciones en KQL.

Como primera opción, use un filtro directo con una where instrucción :

SecurityEvent
| where EventID == 4728 
| where isnotempty(SubjectDomainName) or 
isnotempty(TargetDomainName) 
| where SubjectUserName !~ "AutoMatedService"

Como segunda opción, use una función KQL:

1. Guarde la consulta siguiente como una función KQL con el ExcludeValidUsers alias .

       SecurityEvent
       | where EventID == 4728
       | where isnotempty(SubjectDomainName)
       | where SubjectUserName =~ "AutoMatedService"
       | project SubjectUserName
   

2. Use la siguiente consulta para filtrar el ExcludeValidUsers alias.

       SecurityEvent    
       | where EventID == 4728
       | where isnotempty(SubjectDomainName) or 
       isnotempty(TargetDomainName)
       | where SubjectUserName !in (ExcludeValidUsers)
   

Como tercera opción, use una función de parámetro:

1. Cree una función de parámetro con ExcludeValidUsers como nombre y alias.

2. Defina los parámetros de la función. Por ejemplo:

       Tbl: (TimeGenerated:datetime, Computer:string, 
       EventID:string, SubjectDomainName:string, 
       TargetDomainName:string, SubjectUserName:string)
   

3. La parameter función tiene la siguiente consulta:

       Tbl
       | where SubjectUserName !~ "AutoMatedService"
   

4. Ejecute la consulta siguiente para invocar la función de parámetro:

       let Events = (
       SecurityEvent 
       | where EventID == 4728
       );
       ExcludeValidUsers(Events)
   

Como cuarta opción, use la join función :

let events = (
SecurityEvent
| where EventID == 4728
| where isnotempty(SubjectDomainName) 
or isnotempty(TargetDomainName)
);
let ExcludeValidUsers = (
SecurityEvent
| where EventID == 4728
| where isnotempty(SubjectDomainName)
| where SubjectUserName =~ "AutoMatedService"
);
events
| join kind=leftanti ExcludeValidUsers on 
$left.SubjectUserName == $right.SubjectUserName

Consideraciones:

• Se recomienda usar un filtro directo con una where instrucción (primera opción) debido a su simplicidad. Para optimizar el rendimiento, evite usar join (cuarta opción).
• Para optimizar las consultas, evite los =~ operadores que no distinguen mayúsculas de minúsculas y !~ cuando sea posible. Use los == operadores y != si el valor no distingue mayúsculas de minúsculas.

Ejemplo de lista activa (búsqueda): ArcSight

Esta es una regla de lista activa (búsqueda) en ArcSight.

Ejemplo de lista activa (búsqueda): KQL

En esta regla se da por supuesto que la lista de seguimiento cuentas de excepción de Cyber-Ark existe en Microsoft Sentinel con un campo Cuenta.

let Activelist=(
_GetWatchlist('Cyber-Ark Exception Accounts')
| project Account );
CommonSecurityLog
| where DestinationUserName in (Activelist)
| where DeviceVendor == "Cyber-Ark"
| where DeviceAction == "Get File Request"
| where DeviceCustomNumber1 != ""
| project DeviceAction, DestinationUserName, 
TimeGenerated,SourceHostName, 
SourceUserName, DeviceEventClassID

Ordene los filtros empezando por la where instrucción que filtra la mayoría de los datos.

Ejemplo de correlación (coincidencia): ArcSight

Esta es una regla de ArcSight de ejemplo que define una condición en un conjunto de eventos base mediante la Matching Event instrucción .

Ejemplo de correlación (coincidencia): KQL

let event1 =(
SecurityEvent
| where EventID == 4728
);
let event2 =(
SecurityEvent
| where EventID == 4729
);
event1
| join kind=inner event2 
on $left.TargetUserName==$right.TargetUserName

Procedimientos recomendados:

• Para optimizar la consulta, asegúrese de que la tabla más pequeña está en el lado izquierdo de la join función.
• Si el lado izquierdo de la tabla es relativamente pequeño (hasta 100 K registros), agregue hint.strategy=broadcast para mejorar el rendimiento.

Ejemplo de correlación (ventana de tiempo): ArcSight

Esta es una regla de ArcSight de ejemplo que define una condición para un conjunto de eventos base, mediante la Matching Event instrucción , y usa la condición de Wait time filtro.

Ejemplo de correlación (período de tiempo): KQL

let waittime = 10m;
let lookback = 1d;
let event1 = (
SecurityEvent
| where TimeGenerated > ago(waittime+lookback)
| where EventID == 4728
| project event1_time = TimeGenerated, 
event1_ID = EventID, event1_Activity= Activity, 
event1_Host = Computer, TargetUserName, 
event1_UPN=UserPrincipalName, 
AccountUsedToAdd = SubjectUserName 
);
let event2 = (
SecurityEvent
| where TimeGenerated > ago(waittime)
| where EventID == 4729
| project event2_time = TimeGenerated, 
event2_ID = EventID, event2_Activity= Activity, 
event2_Host= Computer, TargetUserName, 
event2_UPN=UserPrincipalName,
 AccountUsedToRemove = SubjectUserName 
);
 event1
| join kind=inner event2 on TargetUserName
| where event2_time - event1_time < lookback
| where tolong(event2_time - event1_time ) >=0
| project delta_time = event2_time - event1_time,
 event1_time, event2_time,
 event1_ID,event2_ID,event1_Activity,
 event2_Activity, TargetUserName, AccountUsedToAdd,
 AccountUsedToRemove,event1_Host,event2_Host, 
 event1_UPN,event2_UPN

Ejemplo de agregación: ArcSight

Esta es una regla de ArcSight de ejemplo con la configuración de agregación: tres coincidencias en un plazo de 10 minutos.

Ejemplo de agregación: KQL

SecurityEvent
| summarize Count = count() by SubjectUserName, 
SubjectDomainName
| where Count >3

Pasos siguientes

En este artículo, ha aprendido a asignar las reglas de migración de ArcSight a Microsoft Sentinel.