Desenvolver analisadores do Modelo de Informação de Segurança Avançada (ASIM) (Pré-visualização pública)

Os utilizadores do Advanced Security Information Model (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. Os analisadores unificadores, por sua vez, utilizam analisadores específicos da origem para processar os detalhes específicos de cada origem.

O Microsoft Sentinel fornece analisadores incorporados e específicos de origem para muitas origens de dados. Poderá querer modificar ou desenvolver estes analisadores específicos da origem nas seguintes situações:

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

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

  • O dispositivo de origem pode estar configurado para enviar eventos de forma não padrão.

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

  • Os eventos podem ser recolhidos, modificados e reencaminhados por um sistema intermediário.

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

Importante

O ASIM está atualmente em PRÉ-VISUALIZAÇÃO. Os Termos Suplementares da Pré-visualização do Azure incluem termos legais adicionais que se aplicam às funcionalidades do Azure que estão em versão beta, pré-visualização ou que ainda não foram lançadas para disponibilidade geral.

Processo de desenvolvimento de analisador ASIM personalizado

O fluxo de trabalho seguinte descreve os passos de alto nível no desenvolvimento de um analisador asim personalizado, específico da origem:

1. Recolher registos de exemplo.

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

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

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

5. Teste o seu analisador.

6. Implemente os analisadores nas áreas de trabalho do Microsoft Sentinel.

7. Atualize o analisador unificador unificador do ASIM relevante para referenciar o novo analisador personalizado. Para obter mais informações, veja Managing ASIM parsers (Gerir analisadores asim).

8. Também poderá querer contribuir com os seus parsers para a distribuição asim primária. Os parsers com contribuições também podem ser disponibilizados em todas as áreas de trabalho como analisadores incorporados.

Este artigo orienta-o ao longo dos passos de desenvolvimento, teste e implementação do processo.

Dica

Veja também o Webinar deep dive no Microsoft Sentinel Normalizing Parsers and Normalized Content (Normalizar Analisadores e Conteúdo Normalizado ) ou reveja o conjunto de diapositivos relacionado. Para obter mais informações, veja Passos seguintes.

Recolher registos de exemplo

Para criar analisadores ASIM eficazes, precisa de um conjunto representativo de registos, o que, na maioria dos casos, exigirá a configuração do sistema de origem e a ligação 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 de eventos 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.

Dica

Inicie um novo analisador personalizado com um analisador existente para o mesmo esquema. A utilização de um analisador existente é especialmente importante para filtrar analisadores para garantir que aceitam todos os parâmetros necessários para o esquema.

Mapeamento de planeamento

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

• Mapeie todos os campos obrigatórios e, de preferência, 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 mapear para campos disponíveis noutros esquemas.
• Mapear valores para campos na origem para os valores normalizados permitidos pelo ASIM. O valor original é armazenado num campo separado, como EventOriginalResultDetails.

Desenvolver analisadores

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

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

Filtro>> Analisar Preparar campos

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 origens.
• As tabelas personalizadas podem incluir informações de uma única origem que fornece mais do que um tipo de evento e que podem caber em vários esquemas.

Por conseguinte, um analisador deve filtrar primeiro apenas os registos relevantes para o esquema de destino.

A filtragem na KQL é feita com o where operador . Por exemplo, o evento Sysmon 1 comunica a criação do processo e, por conseguinte, é normalizado para o esquema ProcessEvent . O evento Sysmon 1 faz parte da Event tabela, pelo que deve utilizar o seguinte filtro:

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

Importante

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

Filtrar por tipo de origem com uma Lista de Observação

Em alguns casos, o evento em si não contém informações que permitam filtrar tipos de origem 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 origens. Nestes casos, o analisador baseia-se numa lista de origens que define os eventos relevantes. Esta lista é mantida na lista de observação Sources_by_SourceType .

Para utilizar a lista de observação ASimSourceType nos seus analisadores, utilize a _ASIM_GetSourceBySourceType função na secção de filtragem de analisador. Por exemplo, o analisador DNS infoblox inclui o seguinte na secção de filtragem:

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

Para utilizar este exemplo no seu analisador:

• Substitua Computer pelo nome do campo que inclui as informações de origem da sua origem. Pode mantê-lo como Computer para qualquer analisador com base no Syslog.

• Substitua o InfobloxNIOS token por um valor à sua escolha para o seu analisador. Informe os utilizadores do analisador de que têm de atualizar a lista de observação com o ASimSourceType valor selecionado, bem como a lista de origens que enviam eventos deste tipo.

Filtragem com base em parâmetros de analisador

Ao desenvolver analisadores de filtragem, certifique-se de que o seu analisador aceita os parâmetros de filtragem para o esquema relevante, conforme documentado no artigo de referência para esse esquema. Utilizar um analisador existente como ponto de partida garante que o seu analisador inclui 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 com campos físicos. Se os resultados filtrados não forem suficientemente precisos, repita o teste depois de analisar para ajustar os resultados. Para obter mais informações, veja Otimização da filtragem.
• Não filtre se o parâmetro não estiver definido e ainda tiver o valor predefinido.

Os exemplos seguintes mostram como implementar a filtragem para um parâmetro de cadeia, em que o valor predefinido é normalmente "*" e para um parâmetro de lista, em que o valor predefinido é normalmente uma lista vazia.

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

Otimização da filtragem

Para garantir o desempenho do analisador, tenha em atenção as seguintes recomendações de filtragem:

• Filtre sempre por campos incorporados em vez de campos analisados. Embora, por vezes, seja mais fácil filtrar com campos analisados, afeta significativamente o desempenho.
• Utilize operadores que proporcionam um desempenho otimizado. Em particular, ==, hase startswith. A utilização de operadores como contains ou matches regex também afeta significativamente o desempenho.

A filtragem de recomendações de desempenho pode nem sempre ser fácil de seguir. Por exemplo, utilizar has é menos preciso do que contains. Noutros casos, corresponder ao campo incorporado, como SyslogMessage, é menos preciso do que comparar um campo extraído, como DvcAction. Nestes casos, recomendamos que continue a pré-filtrar utilizando um operador de otimização de desempenho num campo incorporado e repita o filtro utilizando condições mais precisas após a análise.

Por exemplo, veja o seguinte fragmento do analisador DNS do Infoblox . O analisador verifica primeiro se o campo has SyslogMessage é a palavra client. No entanto, o termo pode ser utilizado num local diferente na mensagem, pelo que, depois de analisar o Log_Type campo, o analisador verifica novamente se a palavra client era, de facto, 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, uma vez que a consulta que utiliza o analisador já filtra por tempo.

Análise

Assim que a consulta selecionar os registos relevantes, poderá ter de analisá-los. Normalmente, a análise é necessária se vários campos de eventos forem transmitidos num único campo de texto.

Os operadores KQL que efetuam a análise estão listados abaixo, ordenados pela otimização do desempenho. O primeiro fornece o desempenho mais otimizado, enquanto o último proporciona o desempenho menos otimizado.

Operador	Descrição
dividir	Analise uma cadeia de valores delimitados.
parse_csv	Analise uma cadeia de valores formatada como uma linha CSV (valores separados por vírgulas).
parse-kv	Extrai informações estruturadas de uma expressão de cadeia e representa as informações num formulário chave/valor.
parse	Analise múltiplos valores de uma cadeia arbitrária com um padrão, que pode ser um padrão simplificado com melhor desempenho ou uma expressão regular.
extract_all	Analise os valores únicos de uma cadeia arbitrária com uma expressão regular. extract_all tem um desempenho semelhante ao parse de se este utilizar uma expressão regular.
extrair	Extraia um único valor de uma cadeia arbitrária com uma expressão regular. A utilização extract proporciona um melhor desempenho do que parse ou extract_all se é necessário um único valor. No entanto, a utilização de várias ativações através da mesma cadeia de extract origem é menos eficiente do que uma única parse ou extract_all deve ser evitada.
parse_json	Analise os valores numa cadeia formatada como JSON. Se apenas forem necessários alguns valores do JSON, com parse, extractou extract_all proporcionar um melhor desempenho.
parse_xml	Analise os valores numa cadeia formatada como XML. Se forem necessários apenas alguns valores do XML, com parse, extractou extract_all proporcionar um melhor desempenho.

Normalizar

Nomes de campos de mapeamento

A forma mais simples de normalização é mudar o nome de um campo original para o nome normalizado. Utilize o operador project-rename para tal. A utilização do nome do projeto garante que o campo ainda é gerido como um campo físico e o processamento do campo é mais eficaz. Por exemplo:

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

Normalizar o formato e o tipo dos campos

Em muitos casos, o valor original extraído tem de ser normalizado. Por exemplo, no ASIM, um endereço MAC utiliza 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 de KQL, numéricas e de data.

Além disso, garantir que os campos de saída do analisador correspondem ao tipo definido no esquema é fundamental para que os analisadores funcionem. Por exemplo, poderá ter de converter uma cadeia que representa a data e a hora num 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 origens de dados. Por conseguinte, ao atribuir a utilização extend do campo de origem 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, poderá ter de ser mapeado para o conjunto de valores especificado para o campo de esquema de destino. As funções iff, e caselookup podem ser úteis para mapear dados disponíveis para valores de destino.

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

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

Para mapear vários valores, defina o mapeamento com o datatable operador e utilize lookup para efetuar o mapeamento. Por exemplo, algumas origens reportam códigos de resposta DNS numéricos e o protocolo de rede, enquanto o esquema determina a representação de etiquetas de texto mais comum para ambos. O exemplo seguinte demonstra como derivar os valores necessários com 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

Tenha em atenção que a pesquisa também é útil e eficiente quando o mapeamento tem apenas dois valores possíveis.

Quando as condições de mapeamento forem mais complexas, combine iff, casee lookup. O exemplo abaixo mostra como combinar lookup e case. O lookup exemplo acima devolve um valor vazio no campo DnsResponseCodeName se o valor de pesquisa não for encontrado. O case exemplo abaixo aumenta-o ao utilizar o resultado da lookup operação, se disponível, e especificar 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 comuns de pesquisa. Por exemplo, a DnsResponseCodeName pesquisa acima pode ser implementada com uma das seguintes funções:

| extend DnsResponseCodeName = _ASIM_LookupDnsResponseCode(DnsResponseCode)

| invoke _ASIM_ResolveDnsResponseCode('DnsResponseCode')

A primeira opção aceita como um parâmetro o valor a procurar e permite-lhe escolher o campo de saída e, por conseguinte, útil como uma função de pesquisa geral. A segunda opção é mais orientada para parsers, utiliza 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, veja funções ASIM

Campos de melhoramento

Além dos campos disponíveis na origem, um evento ASIM resultante inclui campos de melhoramento 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 melhoramento que os seus analisadores devem definir são os campos de tipo, que designam o tipo do valor armazenado num campo relacionado. Por exemplo, o SrcUsernameType campo designa o tipo de valor armazenado no SrcUsername campo. Pode encontrar mais informações sobre campos de tipo na descrição das entidades.

Na maioria dos casos, também é atribuído um valor constante aos tipos. 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 processar o melhoramento. Por exemplo, utilize 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 computador	Campos de saída
server1	SrcHostname: server1 SrcDomain, SrcDomainType, SrcFQDN vazios
server1.microsoft.com	SrcHostname: server1 SrcDomain: microsoft.com SrcDomainType: FQDN SrcFQDN:server1.microsoft.com

As funções _ASIM_ResolveDstFQDN e executam _ASIM_ResolveDvcFQDN uma tarefa semelhante preenchendo os campos e Dvc relacionadosDst. 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 confundir entre campos normalizados e campos de origem restantes.

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

Operador	Descrição	Quando utilizar num analisador
project-away	Remove campos.	Utilize project-away para campos específicos que pretende remover do conjunto de resultados. Recomendamos que não remova 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 de desempenho.
projeto	Seleciona os campos que existiam antes ou que foram criados como parte da instrução e remove todos os outros campos.	Não recomendado para utilização num analisador, uma vez que o analisador não deve remover outros campos que não estejam normalizados. Se precisar de remover campos específicos, como valores temporários utilizados durante a análise, utilize project-away para os remover dos resultados.

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

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

Processar variantes de análise

Importante

As diferentes variantes representam diferentes tipos de eventos, geralmente mapeados para esquemas diferentes, desenvolvem parsers separados

Em muitos casos, os eventos num fluxo de eventos incluem variantes que requerem lógica de análise diferente. Para analisar diferentes variantes num único analisador, utilize instruções condicionais, como iff e case, ou utilize uma estrutura união.

Para utilizar union para processar múltiplas variantes, crie uma função separada para cada variante e utilize a instrução união 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 começa por filtrar, utilizando campos nativos, apenas os eventos que se destina a analisar. Além disso, se necessário, utilize o project-away em cada ramo, antes da união.

Implementar analisadores

Implemente os analisadores manualmente ao copiá-los para a página Registo do Azure Monitor e ao guardar a consulta como uma função. Este método é útil para testes. Para obter mais informações, veja Criar uma função.

Para implementar um grande número de parsers, recomendamos a utilização de modelos arm de analisador, da seguinte forma:

1. Crie um ficheiro YAML com base no modelo relevante para cada esquema e inclua a consulta no mesmo. Comece com o modelo YAML relevante para o seu tipo de esquema e 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 implementar uma atualização, elimine versões mais antigas das funções com o portal ou a ferramenta de eliminação de funções do PowerShell.

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

Também pode combinar vários modelos num único processo de implementação com modelos ligados

Dica

Os modelos do ARM podem combinar recursos diferentes, para que os analisadores possam ser implementados juntamente com conectores, regras analíticas ou listas de observação, para dar um nome a algumas opções úteis. Por exemplo, o seu analisador pode referenciar uma lista de observação implementada juntamente com a mesma.

Analisadores de teste

Esta secção descreve que as ferramentas de teste ASIM fornecem que lhe permitem testar os seus parsers. Dito isto, os analisadores são práticas de código, por vezes complexas e padrão de garantia de qualidade, como revisões de código, para além dos testes automatizados.

Instalar ferramentas de teste ASIM

Para testar o ASIM, implemente a ferramenta de teste ASIM numa área de trabalho do Microsoft Sentinel onde:

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

Validar o esquema de saída

Para se certificar de que o seu analisador produz um esquema válido, utilize o testador de esquema ASIM ao executar a seguinte consulta na página Registos do Microsoft Sentinel:

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

Processe os resultados da seguinte forma:

Erro	Ação
Campo obrigatório em falta [<Campo>]	Adicione o campo ao seu analisador. Em muitos casos, este seria um valor derivado ou um valor constante e não um campo já disponível a partir da origem.
Campo em falta [<Campo>] é obrigatório quando a coluna obrigatória [<Campo>] existe	Adicione o campo ao seu analisador. Em muitos casos, este campo indica os tipos da coluna existente a que se refere.
Campo em falta [<Campo>] é obrigatório quando a coluna [<Campo>] existe	Adicione o campo ao seu analisador. Em muitos casos, este campo indica os tipos da coluna existente a que se refere.
Alias obrigatório em falta [<Campo>] aliasing coluna existente [<Campo>]	Adicionar o alias ao seu analisador
Alias recomendado em falta [<Campo>] aliasing coluna existente [<Campo>]	Adicionar o alias ao seu analisador
Alias opcional em falta [<Campo>] aliasing coluna existente [<Campo>]	Adicionar o alias ao seu analisador
Alias obrigatório em falta [<Campo>] aliasing coluna em falta [<Campo>]	Este erro acompanha um erro semelhante para o campo aliased. Corrija o erro de campo aliased e adicione este alias ao seu analisador.
Escreva erro de correspondência para o campo [<Campo>]. Atualmente é [<Tipo>] e deve ser [<Tipo>]	Certifique-se de que o tipo de campo normalizado está correto, normalmente através de 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 em falta [<Campo>] aliasing non-existnt column [<Field>]	Se adicionar o campo aliased ao analisador, certifique-se de que também adiciona este alias.
Alias opcional em falta [<Campo>] aliasing non-existnt column [<Field>]	Se adicionar o campo aliased ao analisador, certifique-se de que também adiciona este alias.
Campo opcional em falta [<Campo>]	Embora os campos opcionais estejam muitas vezes em falta, vale a pena rever a lista para determinar se algum dos campos opcionais pode ser mapeado a partir da origem.
Campo extra não normalizado [<Campo>]	Embora os campos não normalizados sejam válidos, vale a pena rever 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 utiliza 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 se certificar de que o seu analisador produz valores válidos, utilize o testador de dados ASIM ao executar a seguinte consulta na página Registos do Microsoft Sentinel:

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

Especificar um esquema é opcional. Se não for especificado um esquema, o EventSchema campo é utilizado para identificar o esquema ao qual o evento deve cumprir. Se um evento não incluir um EventSchema campo, apenas os campos comuns serão verificados. Se um esquema for especificado como um parâmetro, este esquema será utilizado para testar todos os registos. Isto é útil para parsers mais antigos que não definem o EventSchema campo.

Nota

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

Este teste é intensivo em 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 excederá o tempo limite ou defina o intervalo de tempo para a consulta com o seletor de intervalo de tempo.

Processe os resultados da seguinte forma:

Mensagem	Ação
(0) Erro: escreva erro de correspondência para a coluna [<Campo>]. Atualmente é [<Tipo>] e deve ser [<Tipo>]	Certifique-se de que o tipo de campo normalizado está correto, normalmente através de uma função de conversão como tostring.
(0) Erro: valores inválidos (até 10 listados) para o campo [<Campo>] do tipo [<Tipo> Lógico]	Certifique-se de que o analisador mapeia o campo de origem correto para o campo de saída. Se mapeado corretamente, atualize o analisador para transformar o valor de origem no tipo, valor ou formato corretos. Veja a lista de tipos lógicos para obter mais informações sobre os valores e formatos corretos para cada tipo lógico. Tenha em atenção 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 e não apenas definidos. Verifique se o campo pode ser preenchido a partir de outras origens de registos para os quais a origem atual está vazia.
(2) Informações: Valor vazio no campo recomendado [<Campo>]	Normalmente, os campos recomendados devem ser preenchidos. Verifique se o campo pode ser preenchido a partir de outras origens de registos para os quais a origem atual está vazia.
(2) Informações: Valor vazio no campo opcional [<Campo>]	Verifique se o campo aliased é obrigatório ou recomendado e, em caso afirmativo, se pode ser preenchido a partir de outras origens.

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

• Os valores 90% vazios podem indicar um problema de análise geral.
• 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.

Nota

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

Parsers de contribuição

Poderá querer contribuir com o analisador para a distribuição ASIM primária. Se forem aceites, os analisadores estarão disponíveis para todos os clientes como parsers incorporados do ASIM.

Para contribuir com os seus parsers:

• Desenvolva um analisador de filtragem e um analisador sem parâmetros.
• Crie um ficheiro YAML para o analisador, conforme descrito em Implementar Parsers acima.
• Certifique-se de que os seus analisadores passam todos os testes sem erros. Se existirem avisos restantes, documente-os no ficheiro YAML do analisador.
• Crie um pedido Pull no repositório do GitHub do Microsoft Sentinel, incluindo:
  • Os seus ficheiros YAML de analisador nas pastas de analisador ASIM (/Parsers/ASim<schema>/Parsers)
  • Dados de exemplo representativos de acordo com as diretrizes de submissão de exemplos.
  • Resultados dos testes de acordo com as diretrizes de submissão dos resultados do teste.

Documentar avisos aceites

Se os avisos listados pelas ferramentas de teste ASIM forem considerados válidos para um analisador, documente os avisos aceites no ficheiro YAML do analisador com a secçã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 ficheiro YAML deve ser uma forma curta da mensagem de aviso que identifica exclusivamente. O valor é utilizado para corresponder às mensagens de aviso ao realizar testes automatizados e ignorá-los.

Diretrizes de submissão de exemplos

Os dados de exemplo são necessários para resolver problemas do analisador e para garantir que as atualizações futuras ao analisador estão em conformidade com os exemplos mais antigos. 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, tais como eventos que representam uma atividade com êxito e com falhas. Certifique-se também de que 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:

• Logs No ecrã, execute uma consulta que irá extrair da tabela de origem apenas os eventos selecionados pelo analisador. Por exemplo, para o analisador DNS do Infoblox, utilize a seguinte consulta:

    Syslog
    | where ProcessName == "named"

• Exporte os resultados com a opção Exportar para CSV para um ficheiro com o nome <EventVendor>_<EventProduct>_<EventSchema>_IngestedLogs.csv, Where EventProduct, EventProducte EventSchema são os valores atribuídos pelo analisador a esses campos.

• Logs No ecrã, execute uma consulta que produza o esquema ou a tabela de entrada do analisador. Por exemplo, para o mesmo analisador DNS do Infoblox, a consulta é:

    Syslog
    | getschema

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

• Inclua ambos os ficheiros no seu PR na pasta /Sample Data/ASIM. Se o ficheiro já existir, adicione a sua alça do GitHub ao nome, por exemplo: <EventVendor>_<EventProduct>_<EventSchema>_SchemaTest_<GitHubHanlde>.csv

Diretrizes de submissão de resultados de 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 de analisador e descrito na secção de testes .

• e exporte os resultados dos testes com a opção Exportar para CSV para ficheiros com o nome <EventVendor>_<EventProduct>_<EventSchema>_SchemaTest.csv e <EventVendor>_<EventProduct>_<EventSchema>_DataTest.csv respetivamente.

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

Passos seguintes

Este artigo aborda o desenvolvimento de parsers ASIM.

Saiba mais sobre os analisadores do ASIM:

• Descrição geral dos analisadores do ASIM
• Utilizar analisadores do ASIM
• Gerir analisadores do ASIM
• A lista de analisadores do ASIM

Saiba mais sobre o ASIM em geral:

• Veja o Webinar deep dive no Microsoft Sentinel Normalizing Parsers and Normalized Content (Normalizar Os Analisadores e o Conteúdo Normalizado ) ou reveja os diapositivos
• Descrição geral do Advanced Security Information Model (ASIM)
• Esquemas do Advanced Security Information Model (ASIM)
• Conteúdo do Advanced Security Information Model (ASIM)