Modificar conteúdo para utilizar o Modelo de Informações de Segurança Avançada (ASIM)

O conteúdo de segurança normalizado no Microsoft Sentinel inclui regras analíticas, consultas de pesquisa e livros de trabalho que funcionam com parsers de normalização unificadores.

Pode encontrar conteúdos normalizados e prontos a usar em galerias Microsoft Sentinel e catálogos de soluções Microsoft Sentinel, criar o seu próprio conteúdo normalizado ou modificar conteúdos existentes e personalizados para usar dados normalizados.

Este artigo explica como converter as regras de análise existentes do Microsoft Sentinel para utilizar dados normalizados ASIM com o Modelo Avançado de Informação de Segurança (ASIM).

Para compreender como os conteúdos normalizados se enquadram na arquitetura ASIM, veja o diagrama de arquitetura ASIM.

Modificar conteúdo personalizado para utilizar a normalização

Para ativar o conteúdo Microsoft Sentinel personalizado para utilizar a normalização:

Normalização de amostras para regras de analítica

Por exemplo, considere a regra analítica de DNS Cliente raro observado com uma contagem elevada de consultas DNS inversas, que funciona com base em eventos DNS enviados por servidores DNS da 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

O código seguinte é a versão agnóstica de origem, que utiliza a normalização para fornecer a mesma deteção para qualquer origem que forneça eventos de consulta DNS. O exemplo seguinte utiliza analisadores ASIM incorporados:

_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

A versão normalizada e agnóstica de origem tem as seguintes diferenças:

  • O _Im_Dns ou o imDnsparser normalizado é utilizado em vez do Parser Infoblox.

  • Os analisadores normalizados obtêm apenas eventos de consulta DNS, pelo que não é necessário verificar o tipo de evento, conforme realizado pelo where ProcessName =~ "named" and Log_Type =~ "client" na versão do Infoblox.

  • O SrcIpAddr campo é utilizado em vez de Client_IP.

  • A filtragem dos parâmetros do analisador é utilizada para o ResponseCodeName, eliminando a necessidade de cláusulas where explícitas.

Nota

Além de suportar qualquer origem de DNS normalizada, a versão normalizada é mais curta e fácil de compreender.

Se o esquema ou os analisadores não suportarem parâmetros de filtragem, as alterações necessárias para normalizar a regra são semelhantes, exceto que as condições de filtragem são mantidas da consulta original. Por exemplo:

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

Veja mais informações sobre os seguintes elementos KQL usados nos exemplos de normalização de consultas DNS, na documentação Kusto:

Para obter mais informações sobre o KQL, veja Descrição geral do Linguagem de Pesquisa Kusto (KQL).

Outros recursos:

Conteúdos relacionados

Para obter mais informações, consulte os seguintes recursos:

  • Last updated on