Criar, testar e operar Custom Parsers do Sophos SIEM

Um Custom Parser associa os campos de uma mensagem de log aos schemas de eventos normalizados do Sophos XDR. É útil quando uma origem integrada não é normalizada corretamente. O trabalho realiza-se em Security Operations > Integrations > Custom Parsers: criar o parser, testar diferentes mensagens individuais, verificar o mapeamento efetivo e só depois ativar. São necessários uma subscrição Next-Gen SIEM e o papel Admin ou Super Admin; os restantes papéis apenas podem consultar a lista de parsers configurados.

O parser não configura o transporte dos logs. Primeiro, a origem tem de fornecer dados; a explicação do SIEM distingue ingestão, normalização e deteção. Numa integração já suportada, deve primeiro estabelecer-se o formato de origem esperado, em vez de substituir prematuramente a lógica do parser global.

Preparar a origem, o schema e a reversão

Antes de começar, registar produto de origem, formato, tipos de evento, referência temporal e análise pretendida. A Sophos suporta CEF, LEEF, JSON, XML e mensagens não estruturadas. Cada variante relevante exige um exemplo anonimizado: por exemplo, autenticações bem-sucedidas e falhadas, campos opcionais em falta e valores diferentes de utilizador ou endereço. Remover segredos, preservando a estrutura necessária ao parsing.

O schema de destino descreve o tipo de evento. Uma autenticação pode corresponder a Auth, uma ligação de rede a Netflow e uma consulta DNS a DNS. Os Custom Parsers suportam apenas parte dos schemas XDR. Em Data Lake Search > Schema Library, verificar os schemas e campos pesquisáveis; a referência de normalização também apresenta os campos do parser e os tipos de dados correspondentes. A existência de um nome de campo não prova que a origem forneça o respetivo valor.

Documentar na alteração nome do parser, responsável, formato de origem, campos de destino pretendidos, mensagens de teste e processamento anterior. Num parser existente, guardar o script anterior numa localização com acesso restrito. A reversão deve dispensar a eliminação: manter novos parsers inicialmente desativados, voltar a desativá-los em caso de problemas ou restaurar controladamente o script guardado. A Sophos não mantém nem atualiza Custom Parsers; essa responsabilidade pertence ao operador.

Escolher Standalone, Parent ou Child

• Standalone adequa-se a uma origem com exatamente um tipo de mensagem e um schema de destino.
• Parent identifica a origem e prepara valores comuns. A Sophos recomenda scwx.generic como schema de destino. Os Child Parsers associados normalizam os tipos de evento individuais.
• Child necessita de um Parent e do schema final adequado. As variáveis e campos do Parent ficam disponíveis para o Child.

Uma firewall pode fornecer autenticações, ligações de rede e eventos HTTP. Um Parent reconhece o formato comum; três Children tratam os diferentes conteúdos. Os Child Parsers personalizados não podem ter outros Child Parsers. Uma única origem simples não exige automaticamente esta divisão.

Criar o parser e identificar a origem sem ambiguidades

1. Abrir Security Operations > Integrations > Custom Parsers e escolher Add Custom Parser.
2. Definir um nome descritivo, como EXAMPLE_APP_JSON_AUTH. É um exemplo livre; produto, formato e finalidade devem ser reconhecíveis.
3. Escolher Parent, Child ou Standalone. Para Child, selecionar o Parent correto e definir depois formato e schema de destino.
4. Abrir o editor com Create. O código-base gerado inclui a função de separação adequada ao formato escolhido.

A Confirm String determina se uma mensagem corresponde ao parser. !CONFIRMWITH=PATTERN seleciona uma expressão regular compatível com Go; !CONFIRMWITH=EXPRESSION seleciona uma condição que devolve verdadeiro ou falso. Em ambos os casos, a expressão propriamente dita fica em !CONFIRMSTRING, no bloco de declarações do script. Deve identificar com precisão suficiente a origem e, quando aplicável, o tipo de evento. Uma palavra genérica como «network» é geralmente demasiado abrangente. O modelo completo no exemplo prático de HTTP/parser ligado abaixo mostra o modo e o matcher em conjunto; o seu formato de laboratório restrito não é intercambiável com o excerto example-auth seguinte.

Mesmo um parser sintaticamente válido pode captar mensagens de outras origens. A Sophos não garante uma ordem fixa para todas as possíveis colisões de parsers. Testar também pelo menos uma mensagem semelhante que não deva corresponder ao novo parser. Mais tarde, verificar no extractor path quais o Parent e o Child efetivamente utilizados.

Mapear campos e verificar timestamps

O script distingue variáveis locais de campos do parser terminados em $. Só são normalizados campos correspondentes ao schema de destino; um nome arbitrário terminado em $ não cria um novo campo no schema. Os campos do schema usam frequentemente snake_case, enquanto os do parser usam camelCase. Confirmar a grafia exata no schema escolhido.

Este JSON fictício é um pequeno ponto de partida para um mapeamento Auth:

{"product":"example-auth","user":"pilot-user","src_ip":"192.0.2.25","time":"2026-10-27T10:15:00Z","result":"success"}

192.0.2.25 é um endereço de documentação, não um destino de produção. Um excerto de script JSON pode extrair utilizador e endereço de origem assim:

json = JSON(originalData$)
sourceUserName$ = json["$.user"]
sourceAddress$ = json["$.src_ip"]

O exemplo prático de HTTP e parser contém um modelo completo para um formato sintético estritamente definido, com timestamp, associação de Enums e validação por pesquisa.

O excerto ainda não é uma definição completa de parser. Faltam deliberadamente Confirm String, schema, timestamp, ação de autenticação e resultado; devem corresponder ao formato real. Em particular, não copiar o texto success sem validação para um campo enum numérico. O schema Auth define, por exemplo, SUCCESS e FAILED para action_result; verificar explicitamente a respetiva associação no parser.

Comparar valor original, fuso horário e event_time_usec normalizado. A função DATETIME() usa modelos de formato temporal Go. Um timestamp com fuso incorreto pode gerar uma análise tecnicamente bem-sucedida, mas temporalmente errada. Confirmar também os valores comuns extraídos pelo Root Parser face à origem.

Campos repetidos, como vários anexos, indicadores ou registos de metadados, exigem listas de objetos adequadas ao schema. Uma string separada por vírgulas não substitui essa estrutura. ADDFIELD() pode combinar arrays em objetos repetidos; nos arrays JSON devem manter-se alinhadas as posições correspondentes. Valores em falta não podem, por exemplo, associar um hash ao tipo de ficheiro errado.

Testar mensagens individuais e ler os resultados

Se a origem já envia dados, procurar mensagens originais adequadas em Data Lake Search com FROM generic WHERE sensor_id='[my data source]'. Substituir o placeholder pelo identificador de origem verificado nos eventos reais. Nos detalhes do evento, escolher Original Data > Copy Original Data e colar em Sample Message no editor. Em alternativa, usar uma única linha de log anonimizada, não um ficheiro completo.

1. Verificar primeiro a separação com Parse Message. Parsed Source Message mostra pares chave/valor de formatos estruturados ou partes indexadas de mensagens não estruturadas.
2. Em Source Destination Mapping, verificar que valores da origem chegam a cada campo do schema. Comparar individualmente utilizador, endereços de origem/destino, hora, ação e resultado com a mensagem original.
3. Verificar o extractor path. Deve mostrar o caminho previsto. Um aviso sobre outro parser não é meramente cosmético.
4. Acrescentar mais mensagens representativas e exemplos deliberadamente sem correspondência. Em Parent/Child, testar tanto a identificação comum como a seleção do Child.
5. Executar Run Test para todos os exemplos guardados e comparar schema, valores e caminho. A Sophos recomenda testes repetidos, cerca de 12 a 15 execuções, para detetar associações incorretas intermitentes. Um número específico não garante o processamento correto de todas as mensagens futuras.

As ferramentas de teste analisam o conteúdo atual do editor, mas não o guardam. Um parser inválido desativado pode ser guardado; guardar não constitui por si só uma aceitação funcional. Se faltarem campos, verificar primeiro conteúdo da origem, tipo de dados, nomes exatos dos campos e eventual separação da mensagem.

Guardar e ativar de forma controlada

Num parser novo, Save and Continue guarda o rascunho. Novos parsers estão desativados por predefinição. Depois dos testes, sair do editor com Exit, escolher o ícone Play em Actions na lista e confirmar com Enable. Em Parent/Child, ativar primeiro o Parent e depois os Children.

Depois de ativar, gerar um evento de origem inofensivo e autorizado ou correlacionar inequivocamente um evento já esperado. Procurar os resultados normalizados por origem, hora, schema e campos pretendidos. A Sophos indica, por exemplo, WHERE sensor_type=[your_sensor_type]; o placeholder representa o tipo real e não é uma query completa pronta a copiar.

O processamento para schemas adicionais ocorre juntamente com os eventos genéricos. Um resultado de pesquisa comprova inicialmente apenas a normalização verificada. Não são garantidos detetores automáticos para todas as origens personalizadas. Os caminhos documentados incluem DGA e Domain Watchlist através de DNS query_name, e IP Watchlist através de endereços de origem/destino em NIDS ou Netflow. Validar separadamente a deteção pretendida; um evento de teste normal não tem de gerar um alerta.

Respeitar as regras do cliente e a responsabilidade MDR

is_custom_alert, ou vendor_alert_details.is_custom_alert em Email, identifica a origem da regra de alerta. Segundo a ajuda dos schemas, deteções assim marcadas como Custom Alert com true são entregues diretamente ao tenant para tratamento próprio e não entram na fila do serviço MDR; a gravidade não muda. Não definir a marcação de modo a fazer um alerta do cliente parecer uma deteção inalterada do fornecedor.

Isto não significa que toda a mensagem normalizada por um Custom Parser pertença automaticamente à mesma exclusão. Evento de origem, deteção resultante e responsabilidade pelo caso são questões distintas. O artigo sobre Cases e Rules explica a fronteira existente para Self-managed Cases criados a partir de regras do cliente.

Resolver falhas e reverter em segurança

Parser errado no extractor path: Comparar as Confirm Strings envolvidas. Numa colisão com um parser global, pedir ao Sophos Support que reveja a especificidade, em vez de sobrepor outros overrides abrangentes.

Mensagem apenas em generic: Verificar transporte e mensagem original; depois Confirm String, parser ativo e schema escolhido. A ausência de um resultado normalizado não prova, isoladamente, uma falha de transporte.

Script válido, valores errados: Comparar mensagem e mapeamento campo a campo, sobretudo hora e enums. Num parser ativo, restaurar controladamente a versão guardada após uma alteração incorreta e voltar a verificar.

Desativar um novo parser incorreto através do ícone Pause e Disable. Numa hierarquia, todos os Children devem estar desativados ou eliminados antes de desativar o Parent. A normalização adicional para schemas termina imediatamente; continuam a ser criados eventos genéricos. Esta reversão não corrige automaticamente dados históricos anteriormente mal normalizados nem deteções daí resultantes.

Eliminar através do ícone do caixote do lixo e Delete é irreversível. Para uma primeira reversão basta normalmente desativar. Decidir a remoção definitiva só depois de preservar a configuração, esclarecer dependências e concluir a aceitação.

Os parsers globais não podem ser editados diretamente. Um Override substitui o seu processamento para o caso concreto; uma Extension acrescenta tipos de evento ainda não normalizados. Ambos exigem a associação correta ao Parent global e manutenção própria. Sem nome inequívoco e mapeamento verificado, preservar o caminho global existente; não corrigir em produção um fuso horário ou novo formato com um Override não testado.