Migración de reglas de detección de ArcSight a Microsoft Sentinel
En este artículo se explica cómo identificar, comparar y migrar las reglas de detección de ArcSight a 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 sobre los que se puede actuar; algunas de las detecciones que ya tiene pueden ser redundantes en Microsoft Sentinel. Por tanto, no migre todas las reglas de detección y análisis a ciegas. Revise estas consideraciones cuando identifique las reglas de detección existentes.
- Asegúrese de seleccionar los casos de uso que justifican la migración de reglas, teniendo en cuenta la prioridad empresarial y la eficacia.
- Asegúrese de entender los tipos de reglas de Microsoft Sentinel.
- Asegúrese de entender la terminología de las reglas.
- Revise las reglas que no hayan desencadenado ninguna alerta en los últimos 6 a 12 meses y determine si siguen siendo pertinentes.
- Elimine las amenazas o alertas de bajo nivel que omite 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. Como Microsoft Sentinel usa análisis de aprendizaje automático para generar incidentes procesables y muy fiables, 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 revisar las conversaciones de recopilación de datos para garantizar la profundidad y la amplitud de los datos en todos los casos de uso que piensa detectar.
- Explore los recursos de la comunidad, como SOC Prime Threat Detection Marketplace, para comprobar si las reglas están disponibles.
- Piense si un convertidor de consultas en línea, como Uncoder.io, podría funcionar en las reglas.
- Si las reglas no están disponibles o no se pueden convertir, se deben crear manualmente mediante una consulta de KQL. Revise la asignación de reglas para crear 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:
Compruebe que cuenta con un sistema de pruebas para cada regla que quiere migrar.
Prepare un proceso de validación para las reglas migradas, incluidos escenarios y scripts de prueba completos.
Asegúrese de que el equipo tiene recursos útiles para probar las reglas migradas.
Confirme que tiene los orígenes de datos necesarios conectados y revise los métodos de conexión de datos.
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 propia área de trabajo.
En Microsoft Sentinel, vaya a la pestaña Configuración > Análisis > Plantillas de reglas y cree y actualice cada regla de análisis pertinente.
Para 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 un convertidor de consultas en línea, como Uncoder.io, para convertir las consultas a 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 reglas integradas ni un convertidor de reglas en línea son suficientes, deberá crear la regla manualmente. En tal caso, siga estos pasos para empezar a crear la regla:
Identifique los orígenes de datos que desea usar en la regla. Querrá crear una tabla de asignación entre los orígenes de datos y las tablas de datos de Microsoft Sentinel para identificar las tablas que quiere consultar.
Identifique los atributos, campos o entidades en los datos que desea usar en las reglas.
Identifique los criterios y la lógica de la regla. En esta fase, puede que desee usar plantillas de regla como ejemplos para construir las consultas KQL.
Considere la posibilidad de usar filtros, reglas de correlación, listas activas, conjuntos de referencias, listas de control, anomalías de detección, agregaciones, etcétera. Puede usar las referencias proporcionadas por la solución de SIEM heredada para entender cómo asignar mejor la sintaxis de consulta.
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.
Pruebe la regla con cada uno de los casos de uso pertinentes. Si no consigue los resultados esperados, es posible que quiera revisar la consulta de KQL y probarla de nuevo.
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, vea Automatización de la respuesta a amenazas con cuadernos de estrategias en Microsoft Sentinel.
Obtenga más información sobre las reglas de análisis:
- Reglas de análisis programados en Microsoft Sentinel. Use la agrupación de alertas para reducir el exceso de alertas agrupando las que se producen en 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 intuitivo que puede ayudar a reducir el tiempo y el esfuerzo.
- Investigación de incidentes con datos de UEBA a modo de ejemplo de cómo usar evidencias para mostrar 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 otras servicios Microsoft, como Microsoft Defender para punto de conexión y Application Insights.
Comparación de la terminología de las reglas
Esta tabla ayuda a aclarar el concepto de una regla en Microsoft Sentinel en comparación con ArcSight.
ArcSight | Microsoft Sentinel | |
---|---|---|
Tipo de regla | • Regla de filtro • Regla de unión • Regla de lista activa • Y más |
• Consulta programada • Fusión • Seguridad de Microsoft • Análisis de comportamiento de Machine Learning (ML) |
Criterios | Definir en condiciones de regla | Definir en KQL |
Condición desencadenadora | • Definir en acción • Definir en agregación (en agregación de eventos) |
Umbral: número de resultados de la consulta |
Acción | • Establecer campo de evento • Enviar notificación • Crear nuevo caso • Agregar a lista activa • Y más |
• Crear alerta o incidente • Integrar con Logic Apps |
Asignación y comparación de ejemplos de reglas
Use estos ejemplos para comparar y asignar reglas de ArcSight a Microsoft Sentinel en distintos escenarios.
Regla | Descripción | Regla de detección de ejemplo (ArcSight) | Consulta de KQL de ejemplo | Recursos |
---|---|---|---|---|
Filtro (AND ) |
Una regla de ejemplo con condiciones AND . El evento debe cumplir todas las condiciones. |
Ejemplo de filtro (AND) | Ejemplo de filtro (AND) | Filtro de cadena: • Operadores de cadena Filtro numérico: • Operadores numéricos Filtro de fecha y hora: • ago • Datetime • between • now Análisis: • parse • extract • parse_json • parse_csv • parse_path • parse_url |
Filtro (OR ) |
Una regla de ejemplo con condiciones OR . El evento puede cumplir cualquiera de las condiciones. |
Ejemplo de filtro (OR) | Ejemplo de filtro (OR) | • Operadores de cadena • in |
Filtro anidado | Una regla de ejemplo con condiciones de filtrado anidadas. La regla incluye la instrucción MatchesFilter , que también incluye condiciones de filtrado. |
Ejemplo de filtro anidado | Ejemplo de filtro anidado | • Función de KQL de ejemplo • Función de parámetros de ejemplo • join • where |
Lista activa (búsqueda) | Una regla de búsqueda de ejemplo que usa la instrucción InActiveList . |
Ejemplo de lista activa (búsqueda) | Ejemplo de lista activa (búsqueda) | • Una lista de reproducción es el equivalente a la característica de lista activa. Obtenga más información sobre listas de reproducción. • Otras formas de implementar búsquedas |
Correlación (coincidencia) | Una regla de ejemplo que define una condición en un conjunto de eventos base mediante la instrucción Matching Event . |
Ejemplo de correlación (coincidencia) | Ejemplo de correlación (coincidencia) | Operador de unión: • join • unión en una franja de tiempo • shuffle • unión de difusión • Union Instrucción de definición: • let Agregación: • make_set • make_list • make_bag • bag_pack |
Correlación (franja de tiempo) | Una regla de ejemplo que define una condición en un conjunto de eventos base mediante la instrucción Matching Event y que usa la condición de filtro Wait time . |
Ejemplo de correlación (franja de tiempo) | Ejemplo de correlación (franja de tiempo) | • join • Reglas de Microsoft Sentinel e instrucción de unión |
Ejemplo de filtro (AND): ArcSight
Esta es una regla de filtro de ejemplo con condiciones AND
de ArcSight.
Ejemplo de filtro (AND): KQL
Esta es la regla de filtro con condiciones AND
de 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 SecurityEvent de Microsoft Sentinel.
Tenga en cuenta estas recomendaciones:
- Para optimizar las consultas, evite operadores que no distingan mayúsculas de minúsculas en la medida de lo posible:
=~
. - Use
==
si el valor no distingue mayúsculas de minúsculas. - Ordene los filtros empezando por la instrucción
where
, que filtra la mayoría de los datos.
Ejemplo de filtro (OR): ArcSight
Esta es una regla de filtro de ejemplo con condiciones OR
de ArcSight.
Ejemplo de filtro (OR): KQL
Estas son algunas maneras de escribir la regla de filtro con condiciones OR
en KQL.
Como primera opción, use la instrucción in
:
SecurityEvent
| where SubjectUserName in
("Adm1","ServiceAccount1","AutomationServices")
Como segunda opción, use la instrucción or
:
SecurityEvent
| where SubjectUserName == "Adm1" or
SubjectUserName == "ServiceAccount1" or
SubjectUserName == "AutomationServices"
Aunque el rendimiento de ambas opciones es idéntico, 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 de ArcSight.
Esta es una regla para el filtro /All Filters/Soc Filters/Exclude Valid Users
.
Ejemplo de filtro anidado: KQL
Estas son algunas maneras de escribir la regla de filtro con condiciones OR
en KQL.
Como primera opción, use un filtro directo con una instrucción where
:
SecurityEvent
| where EventID == 4728
| where isnotempty(SubjectDomainName) or
isnotempty(TargetDomainName)
| where SubjectUserName !~ "AutoMatedService"
Como segunda opción, use una función de KQL:
Guarde la siguiente consulta como una función de KQL con el alias
ExcludeValidUsers
.SecurityEvent | where EventID == 4728 | where isnotempty(SubjectDomainName) | where SubjectUserName =~ "AutoMatedService" | project SubjectUserName
Use la siguiente consulta para filtrar el alias
ExcludeValidUsers
.SecurityEvent | where EventID == 4728 | where isnotempty(SubjectDomainName) or isnotempty(TargetDomainName) | where SubjectUserName !in (ExcludeValidUsers)
Como tercera opción, use una función de parámetros:
Cree una función de parámetros con
ExcludeValidUsers
como nombre y alias.Defina los parámetros de la función. Por ejemplo:
Tbl: (TimeGenerated:datetime, Computer:string, EventID:string, SubjectDomainName:string, TargetDomainName:string, SubjectUserName:string)
La función
parameter
tiene la siguiente consulta:Tbl | where SubjectUserName !~ "AutoMatedService"
Ejecute la siguiente consulta para invocar a la función de parámetros:
let Events = ( SecurityEvent | where EventID == 4728 ); ExcludeValidUsers(Events)
Como cuarta opción, use la función join
:
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 instrucción
where
(primera opción) debido a su simplicidad. Para optimizar el rendimiento, evite usarjoin
(cuarta opción). - Para optimizar las consultas, evite los operadores que no distinguen mayúsculas de minúsculas
=~
y!~
en la medida de lo 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) de ArcSight.
Ejemplo de lista activa (búsqueda): KQL
Esta regla da por hecho que la lista de reproducción de cuentas de excepciones 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 instrucción where
, que filtra la mayoría de los datos.
Ejemplo de correlación (coincidencia): ArcSight
Esta es una regla de ejemplo de ArcSight que define una condición en un conjunto de eventos base mediante la instrucción Matching Event
.
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 se encuentre en el lado izquierdo de la función
join
. - Si el lado izquierdo de la tabla es relativamente pequeño (hasta 100 000 registros), agregue
hint.strategy=broadcast
para mejorar el rendimiento.
Ejemplo de correlación (franja de tiempo): ArcSight
Esta es una regla de ejemplo de ArcSight que define una condición en un conjunto de eventos base mediante la instrucción Matching Event
y que usa la condición de filtro Wait time
.
Ejemplo de correlación (franja 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 ejemplo de ArcSight con configuración de agregación: tres coincidencias en diez 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.