Desenvolver analisadores do Modelo de Informação de Segurança Avançada (ASIM)

Os utilizadores do Modelo de Informação de Segurança Avançada (ASIM) utilizam analisadores unificadores em vez de nomes de tabelas nas suas consultas, para ver dados num formato normalizado e para incluir todos os dados relevantes para o esquema na consulta. Analisadores unificadores, por sua vez, empregam analisadores específicos da fonte para tratar dos detalhes específicos de cada fonte.

Microsoft Sentinel fornece analisadores internos e específicos da origem para muitas fontes de dados. Talvez você queira modificar, ou desenvolver, esses analisadores específicos da fonte nas seguintes situações:

• Quando o dispositivo fornece eventos que se ajustam a um esquema do ASIM, mas um analisador específico da fonte para seu dispositivo e o esquema relevante não estão disponíveis no Microsoft Sentinel.

• Quando os analisadores específicos da fonte do ASIM estão disponíveis para seu dispositivo, mas seu dispositivo envia eventos em um método ou formato diferente do esperado pelos analisadores do ASIM. Por exemplo:

  • Seu dispositivo de origem pode ser configurado para enviar eventos de maneira não padrão.

  • O seu dispositivo pode ter uma versão diferente da suportada pelo analisador ASIM.

  • Os eventos podem ser coletados, modificados e encaminhados por um sistema intermediário.

Para compreender como os analisadores se encaixam na arquitetura ASIM, veja o diagrama de arquitetura ASIM.

Processo de desenvolvimento do analisador ASIM personalizado

O fluxo de trabalho a seguir descreve as etapas gerais para desenvolver um analisador ASIM personalizado e específico da fonte:

1. Coletar logs de exemplo.

2. Identifique o esquema ou esquemas que os eventos enviados da fonte representam. Para obter mais informações, veja Descrição geral do esquema.

3. Mapeie os campos de evento de origem para o esquema ou esquemas identificados.

4. Desenvolva um ou mais analisadores do ASIM para sua fonte. Você precisará desenvolver um analisador de filtragem e um analisador sem parâmetros para cada esquema relevante para a fonte.

5. Teste seu analisador.

6. Implante os analisadores nos workspaces do Microsoft Sentinel.

7. Atualize o analisador de unificação relevante do ASIM para que ele referencie o novo analisador personalizado. Para obter mais informações, consulte Gerenciar analisadores do ASIM.

8. Talvez você também queira contribuir com seus analisadores para a distribuição primária do ASIM. Os analisadores contribuídos também podem ser disponibilizados em todos os espaços de trabalho como analisadores integrados.

Este artigo orienta você pelas etapas de desenvolvimento, teste e implantação do processo.

Coletar logs de exemplo

Para criar analisadores ASIM eficazes, você precisa de um conjunto representativo de logs, o que, na maioria das vezes, exigirá configurar o sistema de origem e conectá-lo ao Microsoft Sentinel. Se não tiver o dispositivo de origem disponível, os serviços pay as you go na cloud permitem-lhe implementar muitos dispositivos para desenvolvimento e teste.

Além disso, encontrar a documentação e os exemplos do fornecedor para os registos pode ajudar a acelerar o desenvolvimento e reduzir os erros ao garantir uma ampla cobertura do formato de registo.

Um conjunto representativo de registos deve incluir:

• Eventos com resultados diferentes.
• Eventos com diferentes ações de resposta.
• Formatos diferentes para nome de utilizador, nome de anfitrião e IDs e outros campos que requerem normalização de valor.

Planejamento de mapeamento

Antes de desenvolver um analisador, mapeie as informações disponíveis no evento de origem ou eventos para o esquema que você identificou:

• Mapeie todos os campos obrigatórios e, preferencialmente, também os campos recomendados.
• Tente mapear todas as informações disponíveis da origem para campos normalizados. Se não estiver disponível como parte do esquema selecionado, considere o mapeamento para campos disponíveis em outros esquemas.
• Mapeie os valores dos campos de origem para os valores normalizados permitidos pelo ASIM. O valor original é armazenado num campo separado, como EventOriginalResultDetails.

Desenvolvendo analisadores

Desenvolva uma filtragem e um analisador sem parâmetros para cada esquema relevante.

Um analisador personalizado é uma consulta KQL desenvolvida na página Microsoft Sentinel Logs. A consulta do analisador tem três partes:

Filtrar>Analisar>Preparar campos

Mantenha as operações do parser em registro local

Normalize cada registro fonte de forma independente. Um registro fonte pode produzir registros zero após filtragem ou um registro normalizado.

• Leia registros de eventos apenas da tabela de origem declarada. Não realize o enriquecimento de eventos na mesma tabela ou entre tabelas usando uma segunda leitura de tabela, registro de evento join, tabela da área de trabalho ou referência de watchlist, externaldata ou outra fonte tabular externa.
• Preserve a cardinalidade do registro. Não transforme um registro de origem em múltiplos registros normalizados. Se a fonte combinar múltiplos eventos lógicos em um único registro, corrija o formato do conector ou do evento de origem.
• Não use nenhum mv-* operador, incluindo mv-expand e mv-apply.
• Não correlacione, desduplique, agregue ou reagregue registros de eventos com summarize, distinct, arg_min, arg_max, ou uma operação equivalente.

Mapeamentos estáticos locais de consulta criados com datatable e aplicados com lookup são permitidos quando cada chave de consulta é única. Use expressões escalares, acesso direto a valores dinâmicos e valores disponíveis na linha atual. Se um campo não puder ser mapeado sem um padrão proibido, corrija a forma do conector ou do evento de origem, ou deixe um campo não obrigatório sem mapear.

Filtragem

Filtrar os registos relevantes

Em muitos casos, uma tabela no Microsoft Sentinel inclui vários tipos de eventos. Por exemplo:

• A tabela Syslog tem dados de várias fontes.
• As tabelas personalizadas podem incluir informações de uma única fonte que fornece mais de um tipo de evento e podem se ajustar a vários esquemas.

Portanto, um analisador deve primeiro filtrar somente os registros relevantes para o esquema de destino.

A filtragem no KQL é feita usando o operador where. Por exemplo, o evento Sysmon 1 relata a criação do processo e, portanto, deve ser normalizado para o esquema ProcessEvent. O evento Sysmon evento 1 faz parte da Event tabela, então você filtraria apenas para eventos de criação de processos Sysmon usando a seguinte consulta:

Event | where Source == "Microsoft-Windows-Sysmon" and EventID == 1

Filtrar por campos de origem

Use campos físicos no evento atual para identificar o tipo de fonte. Não consulte uma lista de observação ou outra tabela para identificar registros relevantes.

Se o evento não contiver informações suficientes para distinguir sua fonte ou tipo de evento, atualize o conector para incluir um identificador de fonte ou roteie os eventos para uma tabela específica da fonte. Não compense a falta de informação de fonte com enriquecimento de tabelas.

Filtragem com base em parâmetros de analisador

Ao desenvolver analisadores de filtragem, certifique-se de que o analisador aceita os parâmetros de filtragem para o esquema relevante, conforme documentado no artigo de referência para esse esquema. O uso de um analisador existente como ponto de partida garante que seu analisador inclua a assinatura correta de função. Na maioria dos casos, o código de filtragem em si também é semelhante entre analisadores de filtragem para o mesmo esquema.

Ao filtrar, certifique-se de que:

• Filtrar antes de analisar usando campos físicos. Se os resultados filtrados não forem precisos o suficiente, repita o teste após a análise para ajustar os resultados. Para obter mais informações, confira otimização de filtragem.
• Não filtre se o parâmetro não estiver definido e ainda tiver o valor predefinido.

Use predicados condicionais para implementar filtragem opcional de parâmetros do analisador, de modo que o analisador aplique filtros apenas quando os chamadores fornecem valores. Os exemplos a seguir mostram como implementar a filtragem em um parâmetro de cadeia de caracteres, em que o valor padrão é geralmente '*', e em um parâmetro de lista, em que o valor padrão é geralmente uma lista vazia.

srcipaddr=='*' or ClientIP==srcipaddr
array_length(domain_has_any) == 0 or Name has_any (domain_has_any)

Para mais informações sobre a array_length função e o has_any operador, veja a documentação do Kusto:

• função array_length
• operador has_any

Otimização da filtragem

Para garantir o desempenho do analisador, observe as seguintes recomendações de filtragem:

• Sempre filtre por campos integrados em vez de analisados. Embora às vezes seja mais fácil filtrar usando campos analisados, isso afeta drasticamente o desempenho.
• Utilize operadores que proporcionam um desempenho otimizado. Especialmente ==, has e startswith. A utilização de operadores como contains ou matches regex também afeta significativamente o desempenho.

Nem sempre é fácil seguir as recomendações de filtragem para melhorar o desempenho. Por exemplo, utilizar has é menos preciso do que contains. Noutros casos, a correspondência do campo incorporado, como SyslogMessage, é menos precisa do que comparar um campo extraído, como DvcAction. Nesses casos, recomendamos fazer uma filtragem prévia usando um operador de otimização de desempenho em um campo integrado e repetir o filtro usando condições mais precisas após a análise.

Para obter um exemplo, confira o snippet de analisador DNS Infoblox a seguir. O analisador primeiro verifica se o campo SyslogMessage has (tem) a palavra client. No entanto, o termo pode ser usado em um local diferente na mensagem, portanto, depois de analisar o campo Log_Type, o analisador verifica novamente se a palavra client era realmente o valor do campo.

Syslog | where ProcessName == "named" and SyslogMessage has "client"
…
      | extend Log_Type = tostring(Parser[1]),
      | where Log_Type == "client"

Análise

Depois que a consulta seleciona os registros relevantes, talvez seja necessário analisá-los. Normalmente, a análise é necessária se vários campos de evento forem transmitidos num único campo de texto.

Os operadores KQL que executam a análise são listados abaixo, ordenados por otimização de desempenho. O primeiro fornece o desempenho mais otimizado, enquanto o último proporciona o desempenho menos otimizado.

Normalização

Mapeamento de nomes de campo

A forma mais simples de normalização é mudar o nome de um campo original para o nome normalizado. Use o operador project-rename para fazer isso. O uso do recurso 'project-rename' assegura que o campo continue a ser gerenciado como um campo físico e que o gerenciamento do campo ocorra de forma mais eficiente. Por exemplo, a consulta a seguir mapeia os campos da conta fonte para seus nomes normalizados de atores ASIM:

 | project-rename
    ActorUserId = InitiatingProcessAccountSid,
    ActorUserAadId = InitiatingProcessAccountObjectId,
    ActorUserUpn = InitiatingProcessAccountUpn,

Normalizar o formato e o tipo dos campos

Em muitos casos, o valor original extraído precisa ser normalizado. Por exemplo, no ASIM, um endereço MAC usa dois-pontos como separador, enquanto a origem pode enviar um endereço MAC delimitado por hífen. O operador principal para transformar valores é extend, juntamente com um conjunto amplo de funções de cadeia KQL, numéricas e de data.

Além disso, garantir que os campos de saída do analisador correspondam ao tipo definido no esquema é fundamental para que os analisadores funcionem. Por exemplo, talvez seja necessário converter uma cadeia de caracteres que representa a data e a hora em um campo datetime. Funções como todatetime e tohex são úteis nestes casos.

Por exemplo, o ID de evento exclusivo original pode ser enviado como um número inteiro, mas o ASIM requer que o valor seja uma cadeia, para garantir uma ampla compatibilidade entre as origens de dados. Portanto, ao atribuir o campo fonte, converta o valor numérico em uma string usando extend e tostring em vez de project-rename, para que o campo normalizado esteja em conformidade com o requisito de tipo de string do esquema:

  | extend EventOriginalUid = tostring(ReportId),

Campos e valores derivados

O valor do campo fonte, uma vez extraído, pode precisar ser mapeado para o conjunto de valores especificados para o campo do esquema de destino. Use expressões escalares como iff e case, ou um estático datatable local de consulta com lookup, para mapear os dados disponíveis para os valores-alvo.

Por exemplo, o parser DNS da Microsoft deriva um resultado normalizado de sucesso ou falha a partir de códigos de evento e resposta específicos da fonte. O parser atribui o EventResult campo com base no ID do Evento e no Código de Resposta usando uma iff instrução, da seguinte forma:

   extend EventResult = iff(EventId==257 and ResponseCode==0 ,'Success','Failure')

Use case quando um valor fonte pode mapear para vários valores normalizados. Por exemplo:

| extend NetworkProtocol = case(
    Proto == 6, "TCP",
    Proto == 17, "UDP",
    ""
)

Para mapeamentos estáticos maiores, defina uma tabela de dimensão local de consulta e aplique-a com lookup. O lado direito da consulta deve ser uma estática datatablelocalmente definida, não uma tabela de espaço de trabalho, lista de observação ou fonte de dados externa. Defina apenas uma linha para cada chave de consulta para que um único registro de origem não possa produzir múltiplos registros normalizados. Por exemplo:

let NetworkProtocolLookup = datatable(Proto:real, NetworkProtocol:string)
[
    6, "TCP",
    17, "UDP"
];
...
| lookup NetworkProtocolLookup on Proto

Campos de enriquecimento

Além dos campos disponíveis na origem, um evento ASIM resultante inclui campos de enriquecimento que o analisador deve gerar. Esses campos de esquema usam valores da linha atual ou das constantes e não exigem enriquecimento de tabelas. Em muitos casos, os analisadores podem atribuir um valor constante a esses campos. Preenche os campos padrão de enriquecimento para que cada registro analisado inclua metadados consistentes de produto, fornecedor e esquema, por exemplo:

  | extend                  
     EventCount = int(1),
     EventProduct = 'M365 Defender for Endpoint',
     EventVendor = 'Microsoft',
     EventSchemaVersion = '0.1.0',
     EventSchema = 'ProcessEvent'

Outro tipo de campos de enriquecimento que seus analisadores devem definir são os campos de tipo, que designam o tipo do valor armazenado em um campo relacionado. Por exemplo, o campo SrcUsernameType designa o tipo de valor armazenado no campo SrcUsername. Você pode encontrar mais informações sobre campos de tipo na descrição de entidades.

Na maioria dos casos, os tipos também recebem um valor constante. No entanto, em alguns casos, o tipo precisa ser determinado com base no valor real. Por exemplo, determine se o nome de host analisado é um nome de domínio totalmente qualificado (FQDN) verificando se ele contém mais de um segmento:

   DomainType = iif (array_length(SplitHostname) > 1, 'FQDN', '')

Microsoft Sentinel fornece funções úteis para lidar com o enriquecimento. Por exemplo, use a função auxiliar _ASIM_ResolveSrcFQDN para derivar os campos normalizados de nome do host de origem, domínio, tipo de domínio e FQDN da coluna Computer. O trecho a seguir preenche automaticamente os SrcHostnamecampos , SrcDomain, SrcDomainType, e SrcFQDN com base no valor no Computer campo.

  | invoke _ASIM_ResolveSrcFQDN('Computer')

Essa função definirá os campos da seguinte maneira:

As funções _ASIM_ResolveDstFQDN e _ASIM_ResolveDvcFQDN desempenham uma tarefa semelhante, preenchendo os campos relacionados Dst e Dvc. Para obter uma lista completa das funções de ajuda do ASIM, veja Funções ASIM

Selecionar campos no conjunto de resultados

Opcionalmente, o analisador pode selecionar campos no conjunto de resultados. Remover campos desnecessários pode melhorar o desempenho e aumentar a clareza ao evitar confusão entre campos normalizados e campos de origem restantes.

Os seguintes operadores KQL são usados para selecionar campos em seu conjunto de resultados:

Por exemplo, ao analisar uma tabela logarítmica personalizada, remova as colunas tipadas específicas da fonte restantes (como campos com _d, _s, _b, ou _g sufixos) para que a saída do analisador contenha apenas os campos normalizados que você pretende manter:

    | project-away
        *_d, *_s, *_b, *_g

Processar variantes de análise

Se as variantes do mesmo tipo de evento exigirem lógica de análise diferente, use expressões condicionais escalares, como iff e case, preservando um registro de saída para cada registro de origem. Não crie branches tabulares e as recombine com union, porque as branches podem processar ou devolver o mesmo registro de origem mais de uma vez.

Implantar analisadores

Implante os analisadores manualmente copiando-os para a página de log do Azure Monitor e salvando a consulta como uma função. Este método é útil para testes. Para obter mais informações, confira Criar uma função.

Para implantar um grande número de parsers, recomendamos usar modelos ARM de parser, da seguinte forma:

1. Crie um arquivo YAML com base no modelo relevante para cada esquema e inclua sua consulta nele. Comece com o modelo YAML relevante para o seu esquema e tipo de analisador, filtragem ou sem parâmetros.

2. Utilize o conversor de modelos ASIM YAML para ARM para converter o seu ficheiro YAML num modelo do ARM.

3. Se estiver implantando uma atualização, exclua as versões mais antigas das funções usando o portal ou a ferramenta de exclusão de função do PowerShell.

4. Implemente o modelo com o portal do Azure ou o PowerShell.

Você também pode combinar vários modelos em um único processo de implantação usando modelos vinculados

Analisadores de teste

A ASIM oferece ferramentas de teste que você pode usar para validar seus parsers personalizados. Dito isto, os analisadores são código, às vezes complexos, e é recomendado complementar práticas padrão de garantia de qualidade, como revisões de código, com testes automatizados.

Instalar ferramentas de teste do ASIM

Antes de implantar a ferramenta de teste ASIM, certifique-se de ter um espaço de trabalho Microsoft Sentinel onde:

• O analisador está implantado.
• A tabela de origem usada pelo analisador está disponível.
• A tabela de origem usada pelo analisador é preenchida com uma coleção variada de eventos relevantes.

Quando seu espaço de trabalho atender a esses requisitos, implante a ferramenta de teste ASIM nesse espaço.

Validar o esquema de saída

Para garantir que seu parser produza um esquema válido, execute a seguinte consulta de teste de esquema na página de Logs do Microsoft Sentinel. Esse comando verifica se os campos, tipos e aliases de saída do seu parser correspondem ao esquema ASIM esperado:

<parser name> | getschema | invoke ASimSchemaTester('<schema>')

Trate os resultados da seguinte forma:

Validar os valores de saída

Para garantir que seu parser produza valores válidos, use o testador de dados ASIM para validar valores de campo em uma amostra de saída do parser e identificar quaisquer erros ou avisos. Execute a seguinte consulta na página de Logs do Microsoft Sentinel:

<parser name> | limit <X> | invoke ASimDataTester ('<schema>')

A especificação de um esquema é opcional. Se um esquema não for especificado, o campo EventSchema será usado para identificar o esquema ao qual o evento deve aderir. Se um evento não incluir um EventSchema campo, somente campos comuns serão verificados. Se um esquema for especificado como um parâmetro, esse esquema será usado para testar todos os registros. Isso é útil para analisadores mais antigos que não definem o campo EventSchema.

Este teste consome muitos recursos e pode não funcionar em todo o conjunto de dados. Defina X como o maior número para o qual a consulta não expire ou defina o intervalo de tempo da consulta usando o seletor de intervalo de tempo.

Trate os resultados da seguinte forma:

Muitas das mensagens também comunicam o número de registos que geraram a mensagem e a respetiva percentagem da amostra total. Esse percentual é um bom indicador da importância do problema. Por exemplo, para um campo recomendado:

• Os valores vazios de 90% podem indicar um problema geral de análise.
• Os valores vazios de 25% podem indicar uma variante de evento que não foi analisada corretamente.
• Um punhado de valores vazios pode ser um problema insignificante.

Contribuir com analisadores

Talvez você queira contribuir com o parser para a distribuição principal do ASIM. Se forem aceites, os analisadores estarão disponíveis para todos os clientes como analisadores incorporados do ASIM.

Para contribuir com seus analisadores:

• Desenvolva um analisador de filtragem e um analisador sem parâmetros.
• Crie um arquivo YAML para o analisador, conforme descrito na Implantação de Analisadores acima.
• Verifique se os analisadores passam em todos os testes sem erros. Se algum aviso for deixado, documente-o no arquivo YAML do analisador.
• Crie uma solicitação de pull no repositório Microsoft Sentinel GitHub, incluindo:
  • Seus arquivos YAML de analisadores nas pastas do analisador ASIM (/Parsers/ASim<schema>/Parsers)
  • Dados de exemplo representativos de acordo com as diretrizes de submissão de exemplos.
  • Resultados do teste de acordo com as diretrizes de envio dos resultados do teste.

Documentando avisos aceitos

Se avisos listados pelas ferramentas de teste ASIM forem considerados válidos para um analisador, documente os avisos aceitos no arquivo YAML do analisador usando a seção Exceções. O exemplo a seguir do YAML mostra como registrar avisos aceitos de teste de analisador na Exceptions seção da definição do analisador:

Exceptions:
- Field: DnsQuery 
  Warning: Invalid value
  Exception: May have values such as "1164-ms-7.1440-9fdc2aab.3b2bd806-978e-11ec-8bb3-aad815b5cd42" which are not valid domains names. Those are related to TKEY RR requests.
- Field: DnsQuery
  Warning: Empty value in mandatory field
  Exception: May be empty for requests for root servers and for requests for RR type DNSKEY

O aviso especificado no arquivo YAML deve ser uma forma abreviada da mensagem correspondente do testador ASIM, única o suficiente para identificar esse aviso específico. O valor é usado para corresponder às mensagens de aviso do testador ASIM durante testes automatizados e ignorar esses avisos correspondentes.

Diretrizes de envio de amostras

Os dados de amostra são necessários para solucionar problemas do analisador e para garantir que futuras atualizações do analisador estejam em conformidade com amostras mais antigas. Os exemplos que submeter devem incluir qualquer variante de evento suportada pelo analisador. Certifique-se de que os eventos de exemplo incluem todos os tipos de eventos possíveis, formatos de eventos e variações, como eventos que representam atividades com êxito e com falhas. Certifique-se também se as variações nos formatos de valor estão representadas. Por exemplo, se um nome de anfitrião puder ser representado como um FQDN ou um nome de anfitrião simples, os eventos de exemplo devem incluir ambos os formatos.

Para submeter os exemplos de eventos, utilize os seguintes passos:

• Na tela Logs, execute uma consulta que extrairá da tabela de origem apenas os eventos selecionados pelo analisador. Por exemplo, para o parser DNS do Infoblox, use a seguinte consulta para recuperar apenas os registros do Syslog do Infoblox NIOS que o parser gerencia:

    Syslog
    | where ProcessName == "named"

• Exporte os resultados usando a opção Exportar para CSV para um arquivo chamado <EventVendor>_<EventProduct>_<EventSchema>_IngestedLogs.csv, Onde EventProduct, EventProduct e EventSchema são os valores atribuídos pelo analisador a esses campos.

• Na Logs tela, execute getschema na tabela de origem para inspecionar as colunas disponíveis e seus tipos. Exporte essas informações do esquema junto com seus dados de exemplo. Por exemplo, para o analisador DNS do Infoblox, a consulta é:

    Syslog
    | getschema

• Exporte os resultados usando a opção Exportar para CSV para um arquivo chamado <TableName>_schema.csv, onde TableName é o nome da tabela de origem que o analisador usa.

• Inclua ambos os arquivos no seu PR na pasta /Sample Data/ASIM. Se o arquivo já existir, adicione seu identificador de GitHub ao nome, por exemplo: <EventVendor>_<EventProduct>_<EventSchema>_SchemaTest_<GitHubHandle>.csv

Diretrizes de envio de resultados do teste

Os resultados dos testes são importantes para verificar a correção do analisador e compreender qualquer exceção reportada.

Para submeter os resultados do teste, utilize os seguintes passos:

• Execute os testes dos analisadores como descrito em Testar analisadores.

• e exporte os resultados dos testes usando a opção Exportar para CSV para arquivos nomeados <EventVendor>_<EventProduct>_<EventSchema>_SchemaTest.csv e <EventVendor>_<EventProduct>_<EventSchema>_DataTest.csv respectivamente.

• Inclua ambos os arquivos no seu PR na pasta /Parsers/ASim<schema>/Tests.

Conteúdo relacionado

Saiba mais sobre os analisadores do ASIM:

• Visão geral dos analisadores ASIM
• Utilizar analisadores ASIM
• Gerenciar analisadores ASIM
• A lista de analisadores do ASIM

Saiba mais sobre o ASIM em geral:

• Visão geral do ASIM (Modelo de Informações de Segurança Avançado)
• Esquemas do Modelo de Informação de Segurança Avançada (ASIM)
• Conteúdo do Modelo de Informação de Segurança Avançada (ASIM)
• Webinar aprofundado sobre analisadores de normalização e conteúdo normalizado do Microsoft Sentinel