Partilhar via

Desenvolver analisadores ASIM (Advanced Security Information Model) (visualização pública)

  • Artigo

Os usuários do ASIM (Advanced Security Information Model) usam analisadores unificadores em vez de nomes de tabelas em suas consultas, para exibir dados em um formato normalizado e incluir todos os dados relevantes para o esquema na consulta. Os analisadores unificadores, por sua vez, usam analisadores específicos da fonte para lidar com os detalhes específicos de cada fonte.

O Microsoft Sentinel fornece analisadores internos específicos da fonte para muitas fontes de dados. Você pode querer modificar ou desenvolver esses analisadores específicos da fonte nas seguintes situações:

  • Quando seu dispositivo fornece eventos que se ajustam a um esquema ASIM, mas um analisador específico de origem para seu dispositivo e o esquema relevante não está disponível no Microsoft Sentinel.

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

    • Seu dispositivo de origem pode ser configurado para enviar eventos de forma não padrã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 entender como os analisadores se encaixam na arquitetura ASIM, consulte o diagrama de arquitetura ASIM.

Importante

ASIM está atualmente em pré-visualização. Os Termos Suplementares do Azure Preview incluem termos legais adicionais que se aplicam a funcionalidades do Azure que estão em versão beta, pré-visualização ou ainda não disponibilizadas para disponibilidade geral.

Processo de desenvolvimento do analisador ASIM personalizado

O fluxo de trabalho a seguir descreve as etapas de alto nível no desenvolvimento de um analisador ASIM, específico da origem:

  1. Colete logs de amostras.

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

  3. Mapeie os campos de evento de origem para o(s) esquema(s) identificado(s).

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

  5. Teste o analisador.

  6. Implante os analisadores em seus espaços de trabalho do Microsoft Sentinel.

  7. Atualize o analisador unificador ASIM relevante para fazer referência ao novo analisador personalizado. Para obter mais informações, consulte Gerenciando analisadores ASIM.

  8. Você também pode querer contribuir com seus analisadores para a distribuição ASIM primária. 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.

Gorjeta

Assista também ao Deep Dive Webinar sobre Analisadores de Normalização e Conteúdo Normalizado do Microsoft Sentinel ou revise o conjunto de slides relacionado. Para obter mais informações, veja Passos seguintes.

Coletar logs de amostra

Para criar analisadores ASIM eficazes, você precisa de um conjunto representativo de logs, o que, na maioria dos casos, exigirá a configuração do sistema de origem e conectá-lo ao Microsoft Sentinel. Se não tiver o dispositivo de origem disponível, os serviços pré-pagos na nuvem permitem-lhe implementar muitos dispositivos para desenvolvimento e teste.

Além disso, encontrar a documentação do fornecedor e amostras para os logs pode ajudar a acelerar o desenvolvimento e reduzir erros, garantindo uma ampla cobertura do formato de log.

Um conjunto representativo de logs deve incluir:

  • Eventos com diferentes resultados de eventos.
  • Eventos com diferentes ações de resposta.
  • Diferentes formatos para nome de usuário, nome de host e IDs e outros campos que exigem normalização de valor.

Gorjeta

Inicie um novo analisador personalizado usando um analisador existente para o mesmo esquema. O uso de um analisador existente é especialmente importante para filtrar analisadores para garantir que eles aceitem todos os parâmetros exigidos pelo esquema.

Mapeamento de planejamento

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

  • Mapeie todos os campos obrigatórios e, de preferência, também os campos recomendados.
  • Tente mapear qualquer informação disponível da fonte 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 valores para campos na origem para os valores normalizados permitidos pelo ASIM. O valor original é armazenado em um campo separado, como EventOriginalResultDetails.

Desenvolvimento de 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>campos Preparar

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 pode se ajustar a vários esquemas.

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

A filtragem no KQL é feita usando o where operador. Por exemplo, o evento 1 do Sysmon relata a criação do processo e, portanto, é normalizado para o esquema ProcessEvent . O evento Sysmon evento 1 faz parte da Event tabela, portanto, você usaria o seguinte filtro:

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

Importante

Um analisador não deve filtrar por tempo. A consulta que usa o analisador aplicará um intervalo de tempo.

Filtrando por tipo de fonte usando uma Lista de observação

Em alguns casos, o evento em si não contém informações que permitam a filtragem para tipos de fonte específicos.

Por exemplo, os eventos DNS do Infoblox são enviados como mensagens Syslog e são difíceis de distinguir das mensagens Syslog enviadas de outras fontes. Nesses casos, o analisador se baseia em uma lista de fontes que define os eventos relevantes. Esta lista é mantida na Sources_by_SourceType watchlist.

Para usar a lista de observação ASimSourceType em seus analisadores, use a _ASIM_GetSourceBySourceType função na seção de filtragem do analisador. Por exemplo, o analisador DNS Infoblox inclui o seguinte na seção de filtragem:

  | where Computer in (_ASIM_GetSourceBySourceType('InfobloxNIOS'))

Para usar este exemplo em seu analisador:

  • Substitua Computer pelo nome do campo que inclui as informações de origem da sua fonte. Você pode manter isso como Computer para qualquer analisador baseado no Syslog.

  • Substitua o InfobloxNIOS token por um valor de sua escolha para o analisador. Informe aos usuários do analisador que eles devem atualizar a ASimSourceType lista de observação usando o valor selecionado, bem como a lista de fontes que enviam eventos desse tipo.

Filtragem baseada em parâmetros do 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. Usar um analisador existente como ponto de partida garante que o analisador inclua a assinatura de função correta. Na maioria dos casos, o código de filtragem real também é semelhante para filtrar analisadores para o mesmo esquema.

Ao filtrar, certifique-se de que:

  • Filtre 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, consulte Otimização de filtragem.
  • Não filtre se o parâmetro não estiver definido e ainda tiver o valor padrão.

Os exemplos a seguir mostram como implementar a filtragem para um parâmetro string, onde o valor padrão é geralmente '*', e para um parâmetro list, onde 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)

Otimização de filtragem

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

  • Filtre sempre em campos internos em vez de analisados. Embora às vezes seja mais fácil filtrar usando campos analisados, isso afeta drasticamente o desempenho.
  • Use operadores que fornecem desempenho otimizado. Em particular, ==, has, e startswith. O uso de operadores, como contains ou matches regex também, afeta drasticamente o desempenho.

As recomendações de filtragem para o desempenho nem sempre podem ser fáceis de seguir. Por exemplo, usar has é menos preciso do que contains. Em outros casos, a correspondência do campo interno, como SyslogMessage, é menos precisa do que a comparação de um campo extraído, como DvcAction. Nesses casos, recomendamos que você ainda pré-filtre usando um operador de otimização de desempenho em um campo interno e repita o filtro usando condições mais precisas após a análise.

Para obter um exemplo, consulte o seguinte trecho do analisador DNS Infoblox. O analisador primeiro verifica se o campo has SyslogMessage a palavra client. No entanto, o termo pode ser usado em um lugar diferente na mensagem, portanto, depois de analisar o Log_Type campo, 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"

Nota

Os analisadores não devem filtrar por tempo, pois a consulta usando o analisador já filtra por tempo.

A Analisar

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

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

Operator Description
split Analise uma cadeia de valores delimitados.
parse_csv Analise uma cadeia de valores formatada como uma linha CSV (valores separados por vírgula).
Analisar-KV Extrai informações estruturadas de uma expressão de cadeia de caracteres e representa as informações em um formulário de chave/valor.
analisar Analise vários valores de uma cadeia de caracteres arbitrária usando um padrão, que pode ser um padrão simplificado com melhor desempenho ou uma expressão regular.
extract_all Analise valores únicos de uma cadeia de caracteres arbitrária usando uma expressão regular. extract_all tem um desempenho semelhante ao parse de se este último usar uma expressão regular.
extrato Extraia um único valor de uma cadeia de caracteres arbitrária usando uma expressão regular.

O uso extract fornece um desempenho melhor do que parse ou extract_all se um único valor for necessário. No entanto, o uso de várias ativações da mesma cadeia de caracteres de extract origem é menos eficiente do que uma única parse ou e extract_all deve ser evitado.
parse_json Analise os valores em uma cadeia de caracteres formatada como JSON. Se apenas alguns valores forem necessários do JSON, usar parse, extractou extract_all fornecer melhor desempenho.
parse_xml Analise os valores em uma cadeia de caracteres formatada como XML. Se apenas alguns valores forem necessários do XML, usar parse, extractou extract_all fornecer melhor desempenho.

Normalização

Mapeando nomes de campos

A forma mais simples de normalização é renomear um campo original para seu nome normalizado. Use o operador project-rename para isso. O uso de project-rename garante que o campo ainda seja gerenciado como um campo físico e que a manipulação do campo tenha mais desempenho. Por exemplo:

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

Normalizando o formato e o tipo de 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 fonte pode enviar um endereço MAC delimitado por hífen. O operador primário para a transformação de valores é extend, ao lado de um amplo conjunto 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 data e 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 inteiro, mas o ASIM exige que o valor seja uma cadeia de caracteres, para garantir ampla compatibilidade entre fontes de dados. Portanto, ao atribuir o campo de origem, use extend e tostring em vez de project-rename:

  | extend EventOriginalUid = tostring(ReportId),

Campos e valores derivados

O valor do campo de origem, uma vez extraído, pode precisar ser mapeado para o conjunto de valores especificado para o campo de esquema de destino. As funções iff, casee lookup podem ser úteis para mapear os dados disponíveis para os valores de destino.

Por exemplo, o analisador de DNS da Microsoft atribui o EventResult campo com base na ID do Evento e no Código de Resposta usando uma iff instrução, da seguinte maneira:

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

Para mapear vários valores, defina o mapeamento usando o datatable operador e use lookup para executar o mapeamento. Por exemplo, algumas fontes relatam códigos de resposta DNS numéricos e o protocolo de rede, enquanto o esquema exige a representação de rótulos de texto mais comuns para ambos. O exemplo a seguir demonstra como derivar os valores necessários usando datatable e lookup:

   let NetworkProtocolLookup = datatable(Proto:real, NetworkProtocol:string)[
        6, 'TCP',
        17, 'UDP'
   ];
    let DnsResponseCodeLookup=datatable(DnsResponseCode:int,DnsResponseCodeName:string)[
      0,'NOERROR',
      1,'FORMERR',
      2,'SERVFAIL',
      3,'NXDOMAIN',
      ...
   ];
   ...
   | lookup DnsResponseCodeLookup on DnsResponseCode
   | lookup NetworkProtocolLookup on Proto

Observe que a pesquisa é útil e eficiente também quando o mapeamento tem apenas dois valores possíveis.

Quando as condições de mapeamento são mais complexas, combine iff, case, e lookup. O exemplo abaixo mostra como combinar lookup e case. O lookup exemplo acima retorna um valor vazio no campo DnsResponseCodeName se o valor de pesquisa não for encontrado. O case exemplo abaixo o aumenta usando o resultado da lookup operação, se disponível, e especificando condições adicionais de outra forma.

   | extend DnsResponseCodeName = 
      case (
        DnsResponseCodeName != "", DnsResponseCodeName,
        DnsResponseCode between (3841 .. 4095), 'Reserved for Private Use',
        'Unassigned'
      )

O Microsoft Sentinel fornece funções úteis para valores de pesquisa comuns. Por exemplo, a DnsResponseCodeName pesquisa acima, pode ser implementada usando uma das seguintes funções:


| extend DnsResponseCodeName = _ASIM_LookupDnsResponseCode(DnsResponseCode)

| invoke _ASIM_ResolveDnsResponseCode('DnsResponseCode')

A primeira opção aceita como parâmetro o valor a pesquisar e permite que você escolha o campo de saída e, portanto, útil como uma função de pesquisa geral. A segunda opção é mais voltada para analisadores, toma como entrada o nome do campo de origem e atualiza o campo ASIM necessário, neste caso DnsResponseCodeName.

Para obter uma lista completa das funções de ajuda do ASIM, consulte as funções do ASIM

Campos de enriquecimento

Além dos campos disponíveis na fonte, um evento ASIM resultante inclui campos de enriquecimento que o analisador deve gerar. Em muitos casos, os analisadores podem atribuir um valor constante aos campos, 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 campos de tipo, que designam o tipo do valor armazenado em um campo relacionado. Por exemplo, o SrcUsernameType campo designa o tipo de valor armazenado no SrcUsername campo. Você pode encontrar mais informações sobre campos de tipo na descrição das entidades.

Na maioria dos casos, os tipos também recebem um valor constante. No entanto, em alguns casos, o tipo tem de ser determinado com base no valor real, por exemplo:

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

O Microsoft Sentinel fornece funções úteis para lidar com o enriquecimento. Por exemplo, use a seguinte função para atribuir automaticamente os campos SrcHostname, SrcDomainSrcDomainType e SrcFQDN com base no valor no campo Computer.

  | invoke _ASIM_ResolveSrcFQDN('Computer')

Esta função definirá os campos da seguinte forma:

Campo do computador Campos de saída
server1 SrcHostname: servidor1
SrcDomain, SrcDomainType, SrcFQDN todos vazios
server1.microsoft.com SrcHostname: servidor1
SrcDomain: microsoft.com
SrcDomainType: FQDN
SrcFQDN:server1.microsoft.com

As funções _ASIM_ResolveDstFQDN e _ASIM_ResolveDvcFQDN executar uma tarefa semelhante preenchendo os campos e Dvc relacionadosDst. Para obter uma lista completa das funções de ajuda do ASIM, consulte as funções do ASIM

Selecionar campos no conjunto de resultados

O analisador pode, opcionalmente, selecionar campos no conjunto de resultados. A remoção de campos desnecessários pode melhorar o desempenho e adicionar clareza, evitando a confusão entre campos normalizados e campos de origem restantes.

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

Operator Description Quando usar em um analisador
projeto-fora Remove campos. Use project-away para campos específicos que você deseja remover do conjunto de resultados. Recomendamos não remover os campos originais que não estão normalizados do conjunto de resultados, a menos que criem confusão ou sejam muito grandes e possam ter implicações no desempenho.
projeto Seleciona campos que existiam antes ou foram criados como parte da instrução e remove todos os outros campos. Não recomendado para uso em um analisador, pois o analisador não deve remover nenhum outro campo que não esteja normalizado.

Se você precisar remover campos específicos, como valores temporários usados durante a análise, use project-away para removê-los dos resultados.

Por exemplo, ao analisar uma tabela de log personalizada, use o seguinte para remover os campos originais restantes que ainda têm um descritor de tipo:

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

Manipular variantes de análise

Importante

As diferentes variantes representam diferentes tipos de eventos, comumente mapeados para esquemas diferentes, desenvolvem analisadores separados

Em muitos casos, os eventos em um fluxo de eventos incluem variantes que exigem lógica de análise diferente. Para analisar diferentes variantes em um único analisador, use instruções condicionais como iff e , caseou use uma estrutura de união.

Para usar union para lidar com várias variantes, crie uma função separada para cada variante e use a instrução union para combinar os resultados:

let AzureFirewallNetworkRuleLogs = AzureDiagnostics
    | where Category == "AzureFirewallNetworkRule"
    | where isnotempty(msg_s);
let parseLogs = AzureFirewallNetworkRuleLogs
    | where msg_s has_any("TCP", "UDP")
    | parse-where
        msg_s with           networkProtocol:string 
        " request from "     srcIpAddr:string
        ":"                  srcPortNumber:int
    …
    | project-away msg_s;
let parseLogsWithUrls = AzureFirewallNetworkRuleLogs
    | where msg_s has_all ("Url:","ThreatIntel:")
    | parse-where
        msg_s with           networkProtocol:string 
        " request from "     srcIpAddr:string
        " to "               dstIpAddr:string
    ...
union parseLogs,  parseLogsWithUrls…

Para evitar eventos duplicados e processamento excessivo, certifique-se de que cada função comece filtrando, usando campos nativos, apenas os eventos que se destina a analisar. Além disso, se necessário, use o projeto-away em cada filial, antes do sindicato.

Implantar analisadores

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

Para implantar um grande número de analisadores, recomendamos o uso de modelos ARM do analisador, da seguinte maneira:

  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. Use o conversor de modelo ASIM Yaml para ARM para converter seu arquivo YAML em um modelo ARM.

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

  4. Implante seu modelo usando 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

Gorjeta

Os modelos ARM podem combinar diferentes recursos, para que os analisadores possam ser implantados ao lado de conectores, regras analíticas ou listas de observação, para citar algumas opções úteis. Por exemplo, seu analisador pode fazer referência a uma lista de observação implantada ao lado dele.

Analisadores de teste

Esta seção descreve as ferramentas de teste fornecidas pelo ASIM que permitem testar seus analisadores. Dito isso, os analisadores são códigos, às vezes complexos, e práticas padrão de garantia de qualidade, como revisões de código, são recomendadas, além de testes automatizados.

Instalar ferramentas de teste ASIM

Para testar o ASIM, implante a ferramenta de teste ASIM em um espaço de trabalho do Microsoft Sentinel onde:

  • Seu analisador é 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.

Validar o esquema de saída

Para certificar-se de que o analisador produz um esquema válido, use o testador de esquema ASIM executando a seguinte consulta na página Logs do Microsoft Sentinel:

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

Manipule os resultados da seguinte maneira:

Erro Ação
Campo obrigatório em falta [<Campo>] Adicione o campo ao analisador. Em muitos casos, este seria um valor derivado ou um valor constante, e não um campo já disponível na fonte.
O campo em falta [<Campo>] é obrigatório quando existe uma coluna obrigatória [<Campo>] Adicione o campo ao analisador. Em muitos casos, este campo indica os tipos da coluna existente a que se refere.
O campo em falta [<Campo>] é obrigatório quando existe a coluna [<Campo>] Adicione o campo ao analisador. Em muitos casos, este campo indica os tipos da coluna existente a que se refere.
Alias obrigatório ausente [<Campo>] aliasing coluna existente [<Campo>] Adicione o alias ao analisador
Alias recomendado ausente [<Campo>] aliasing coluna existente [<Campo>] Adicione o alias ao analisador
Alias opcional ausente [<Campo>] aliasing coluna existente [<Campo>] Adicione o alias ao analisador
Alias obrigatório ausente [<Campo>] aliasing ausente coluna [<Campo>] Este erro acompanha um erro semelhante para o campo com alias. Corrija o erro de campo com alias e adicione esse alias ao analisador.
Digite incompatibilidade para o campo [<Campo>]. Atualmente é [<Tipo>] e deve ser [<Tipo>] Certifique-se de que o tipo de campo normalizado está correto, geralmente usando uma função de conversão como tostring.
Informações Ação
Campo recomendado em falta [<Campo>] Considere adicionar este campo ao seu analisador.
Informações Ação
Alias recomendado ausente [<Campo>] aliasing coluna inexistente [<Campo>] Se você adicionar o campo aliased ao analisador, certifique-se de adicionar esse alias também.
Alias opcional ausente [<Campo>] aliasing coluna inexistente [<Campo>] Se você adicionar o campo aliased ao analisador, certifique-se de adicionar esse alias também.
Campo opcional em falta [<Campo>] Embora os campos opcionais estejam frequentemente ausentes, vale a pena rever a lista para determinar se algum dos campos opcionais pode ser mapeado a partir da fonte.
Campo extra não normalizado [<Campo>] Embora os campos não normalizados sejam válidos, vale a pena revisar a lista para determinar se algum dos valores não normalizados pode ser mapeado para um campo opcional.

Nota

Os erros impedirão que o conteúdo que usa o analisador funcione corretamente. Os avisos não impedirão que o conteúdo funcione, mas podem reduzir a qualidade dos resultados.

Validar os valores de saída

Para certificar-se de que o analisador produz valores válidos, use o testador de dados ASIM executando a seguinte consulta na página Logs do Microsoft Sentinel:

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

Especificar um esquema é opcional. Se um esquema não for especificado, o EventSchema campo será usado para identificar o esquema ao qual o evento deve aderir. Ig um evento não inclui um EventSchema campo, apenas 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 EventSchema campo.

Nota

Mesmo quando um esquema não é especificado, parênteses vazios são necessários após o nome da função.

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 atingirá o tempo limite ou defina o intervalo de tempo para a consulta usando o seletor de intervalo de tempo.

Manipule os resultados da seguinte maneira:

Mensagem Ação
(0) Erro: tipo incompatibilidade para a coluna [<Campo>]. Atualmente é [<Tipo>] e deve ser [<Tipo>] Certifique-se de que o tipo de campo normalizado está correto, geralmente usando uma função de conversão como tostring.
(0) Erro: Valor(es) inválido(s) (até 10 listados) para o campo [<Campo>] do tipo [<Tipo lógico>] Certifique-se de que o analisador mapeie o campo de origem correto para o campo de saída. Se mapeado corretamente, atualize o analisador para transformar o valor de origem para o tipo, valor ou formato correto. Consulte a lista de tipos lógicos para obter mais informações sobre os valores e formatos corretos para cada tipo lógico.

Observe que a ferramenta de teste lista apenas uma amostra de 10 valores inválidos.
(1) Aviso: Valor vazio no campo obrigatório [<Campo>] Os campos obrigatórios devem ser preenchidos, não apenas definidos. Verifique se o campo pode ser preenchido a partir de outras fontes para registros para os quais a fonte atual está vazia.
(2) Info: Valor vazio no campo recomendado [<Campo>] Os campos recomendados geralmente devem ser preenchidos. Verifique se o campo pode ser preenchido a partir de outras fontes para registros para os quais a fonte atual está vazia.
(2) Info: Valor vazio no campo opcional [<Campo>] Verifique se o campo com alias é obrigatório ou recomendado e, em caso afirmativo, se pode ser preenchido a partir de outras fontes.

Muitas das mensagens também relatam o número de registros que geraram a mensagem e sua porcentagem da amostra total. Esta percentagem é um bom indicador da importância da questão. Por exemplo, para um campo recomendado:

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

Nota

Os erros impedirão que o conteúdo que usa o analisador funcione corretamente. Os avisos não impedirão que o conteúdo funcione, mas podem reduzir a qualidade dos resultados.

Contribua com analisadores

Você pode contribuir com o analisador para a distribuição ASIM primária. Se aceitos, os analisadores estarão disponíveis para todos os clientes como analisadores integrados da 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 em Implantando analisadores acima.
  • Certifique-se de que seus analisadores passam em todos os testes sem erros. Se algum aviso for deixado, documente-o no arquivo YAML do analisador.
  • Crie uma solicitação pull no repositório GitHub do Microsoft Sentinel, incluindo:
    • Seus arquivos YAML analisadores nas pastas do analisador ASIM (/Parsers/ASim<schema>/Parsers)
    • Dados representativos da amostra de acordo com as diretrizes de apresentação de amostras.
    • Resultados de testes de acordo com as diretrizes de submissão de resultados de testes.

Documentação das advertências aceites

Se os 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, conforme mostrado no exemplo abaixo.

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 curta da mensagem de aviso identificando exclusivamente. O valor é usado para corresponder mensagens de aviso ao executar testes automatizados e ignorá-los.

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 enviados 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 evento e variações, como eventos que representam atividades bem-sucedidas e com falha. Certifique-se também de que as variações nos formatos de valor são representadas. Por exemplo, se um nome de host pode ser representado como um FQDN ou um nome de host simples, os eventos de exemplo devem incluir ambos os formatos.

Para enviar os exemplos de eventos, use as seguintes etapas:

  • Logs Na tela, execute uma consulta que extrairá da tabela de origem apenas os eventos selecionados pelo analisador. Por exemplo, para o analisador DNS Infoblox, use a seguinte consulta:
    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, EventProducte EventSchema são os valores atribuídos pelo analisador a esses campos.

  • Logs Na tela, execute uma consulta que produzirá o esquema ou a tabela de entrada do analisador. Por exemplo, para o mesmo analisador DNS 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 usada pelo analisador.

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

Diretrizes para a submissão dos resultados dos testes

Os resultados do teste são importantes para verificar a correção do analisador e entender qualquer exceção relatada.

Para enviar os resultados do teste, use as seguintes etapas:

  • Execute os testes do analisador e descritos na seção de testes.

  • 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 em seu PR na pasta /Parsers/ASim<schema>/Tests.

Próximos passos

Este artigo discute o desenvolvimento de analisadores ASIM.

Saiba mais sobre os analisadores do ASIM:

Saiba mais sobre o ASIM em geral: