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 las reglas de análisis 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 las consideraciones siguientes 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.
• Revisa cualquier norma que no haya activado ninguna alerta en los últimos seis a doce meses y determina si siguen siendo relevantes.
• 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 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 Configuración > Análisis > Plantillas de reglas y cree y actualice cada regla analítica pertinente.

     Para aprender a crear reglas a partir de plantillas integradas, consulta Crear 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. 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 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. Podrías usar referencias proporcionadas por tu SIEM heredado para mapear la sintaxis de consultas de ArcSight a KQL.

     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 crear y usar playbooks para acciones de reglas, consulta Automatizar la respuesta a amenazas con playbooks en Microsoft Sentinel.

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

• 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): Puedes usar KQL para enviar solicitudes de solo lectura a tu 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.

Relacionar y comparar ejemplos de reglas

Utilice los siguientes ejemplos para comparar las reglas de detección de ArcSight con consultas equivalentes de Microsoft Sentinel escritas en el Lenguaje de Consultas Kusto (KQL).

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

Aquí tienes un ejemplo de regla de filtro anidada 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

Considerations

• 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

La siguiente consulta KQL utiliza la lista de seguimiento de Cyber-Ark Cuentas de Excepción para filtrar los resultados de la búsqueda.

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

A continuación se muestra una regla de ejemplo de ArcSight que define una condición para un conjunto de eventos base mediante la instrucción Matching Event.

Ejemplo de correlación (coincidencia): KQL

En el ejemplo de KQL siguiente se muestra cómo implementar la regla de correlación de coincidencias de ArcSight en Microsoft Sentinel.

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

En el ejemplo de KQL siguiente se implementa una regla de correlación con un período de tiempo equivalente al ejemplo de ArcSight.

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

La siguiente consulta KQL muestra cómo detectar tres o más coincidencias mediante la agregación.

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

Paso siguiente