Modificación del contenido para usar el modelo de información de seguridad avanzada (ASIM)

El contenido de seguridad normalizado de Microsoft Sentinel incluye reglas de análisis, consultas de búsqueda y libros que funcionan con analizadores de normalización unificadores.

Puede encontrar contenido normalizado y de fábrica en Microsoft Sentinel galerías y soluciones, crear su propio contenido normalizado o modificar contenido personalizado existente para usar datos normalizados.

En este artículo se explica cómo convertir reglas de análisis de Microsoft Sentinel existentes para usar datos normalizados con el modelo de información de seguridad avanzada (ASIM).

Para comprender cómo se ajusta el contenido normalizado dentro de la arquitectura de ASIM, consulte el diagrama de arquitectura de ASIM.

Modificación del contenido personalizado para usar la normalización

Para permitir que el contenido de Microsoft Sentinel personalizado use la normalización:

Normalización de ejemplo para reglas de análisis

Por ejemplo, tenga en cuenta el cliente poco frecuente observado con una regla de análisis dns de recuento de búsquedas inversas elevadas , que funciona en eventos DNS enviados por servidores DNS de Infoblox:

let threshold = 200;
InfobloxNIOS
| where ProcessName =~ "named" and Log_Type =~ "client"
| where isnotempty(ResponseCode)
| where ResponseCode =~ "NXDOMAIN"
| summarize count() by Client_IP, bin(TimeGenerated,15m)
| where count_ > threshold
| join kind=inner (InfobloxNIOS
    | where ProcessName =~ "named" and Log_Type =~ "client"
    | where isnotempty(ResponseCode)
    | where ResponseCode =~ "NXDOMAIN"
    ) on Client_IP
| extend timestamp = TimeGenerated, IPCustomEntity = Client_IP

El código siguiente es la versión independiente del origen, que usa la normalización para proporcionar la misma detección para cualquier origen que proporcione eventos de consulta DNS. En el ejemplo siguiente se usan analizadores de ASIM integrados:

_Im_Dns(responsecodename='NXDOMAIN')
| summarize count() by SrcIpAddr, bin(TimeGenerated,15m)
| where count_ > threshold
| join kind=inner (imDns(responsecodename='NXDOMAIN')) on SrcIpAddr
| extend timestamp = TimeGenerated, IPCustomEntity = SrcIpAddr

La versión normalizada independiente del origen tiene las siguientes diferencias:

  • Los _Im_Dns analizadores normalizados o imDnsse usan en lugar del analizador infoblox.

  • Los analizadores normalizados capturan solo los eventos de consulta DNS, por where ProcessName =~ "named" and Log_Type =~ "client" lo que no es necesario comprobar el tipo de evento, tal como se realiza en la versión de Infoblox.

  • El SrcIpAddr campo se usa en lugar de Client_IP.

  • El filtrado de parámetros del analizador se usa para ResponseCodeName, lo que elimina la necesidad de una cláusula explícita where .

Nota:

Además de admitir cualquier origen DNS normalizado, la versión normalizada es más corta y fácil de entender.

Si el esquema o los analizadores no admiten parámetros de filtrado, los cambios son similares, salvo que las condiciones de filtrado se mantienen de la consulta original. Por ejemplo:

let threshold = 200;
imDns
| where isnotempty(ResponseCodeName)
| where ResponseCodeName =~ "NXDOMAIN"
| summarize count() by SrcIpAddr, bin(TimeGenerated,15m)
| where count_ > threshold
| join kind=inner (imDns
    | where isnotempty(ResponseCodeName)
    | where ResponseCodeName =~ "NXDOMAIN"
    ) on SrcIpAddr
| extend timestamp = TimeGenerated, IPCustomEntity = SrcIpAddr

Vea más información sobre los siguientes elementos usados en los ejemplos anteriores, en la documentación de Kusto:

Para obtener más información sobre KQL, consulte introducción a Lenguaje de consulta Kusto (KQL).

Otros recursos:

Pasos siguientes

En este artículo se describe el contenido del modelo de información de seguridad avanzada (ASIM).

Para más información, vea: