Sophos SIEM: verificar HTTP Ingest e parser com um exemplo

Este exemplo liga uma fonte JSON sintética a HTTP Ingest, a um Custom Parser para o schema Auth e a uma pesquisa específica. Mostra o percurso entre os guias de HTTP Ingest e de Custom Parsers. Comunica apenas logins fictícios de laboratório; não autentica utilizadores reais nem verifica credenciais.

Preparar o laboratório e definir o sucesso

São necessários um tenant de teste com subscrição Next-Gen SIEM, uma função Admin ou Super Admin autorizada e um computador aprovado com Python 3 e acesso HTTPS ao endpoint de ingestão atribuído. O planeamento SIEM explica os limites de licença e retenção. Um acesso XDR existente, por si só, não basta para transporte personalizado e Custom Parsers.

O contrato do laboratório é deliberadamente restrito: uma mensagem JSON por POST, o formato de campos apresentado abaixo e a fonte fixa avanet-lab-source. A ajuda HTTP descreve HTTPS-POST com token Bearer, mas não define aí um corpo de resposta, código de estado ou invólucro de payload universal para todas as fontes. Antes do envio, verificar o endpoint efetivamente disponibilizado e os seus requisitos atuais. Se a implementação concreta exigir outra estrutura do corpo, adaptá-la primeiro segundo a documentação correspondente; este modelo não é uma especificação universal da API de ingestão.

Antes de começar, documentar tenant, responsável, nome da integração, nome do parser e hora do teste. O resultado esperado consiste em três provas separadas:

1. A fonte de laboratório aprovada enviou exatamente a mensagem pretendida.
2. O parser associa corretamente os valores fictícios da origem ao schema Auth.
3. A mensagem é encontrada no tenant correto com hora, fonte e identificador de teste adequados.

Um sucesso HTTP, um conector verde ou um script sintaticamente válido não bastam para esta validação. Não se espera uma deteção nem tratamento MDR deste evento de laboratório.

Formato de teste e modelo completo de parser

A fonte de laboratório utiliza esta linha JSON única:

{"product":"avanet-siem-lab","schema_version":1,"event_type":"logon","sensor_id":"avanet-lab-source","user":"pilot-user","src_ip":"192.0.2.25","session_id":"avanet-lab-20261029T101500Z","time":"2026-10-29T10:15:00Z","result":"success"}

192.0.2.25 é um endereço de documentação. pilot-user não é um utilizador do tenant. session_id identifica esta execução fictícia de laboratório, não uma sessão de autenticação real. No envio posterior, o script gera a hora UTC atual e um identificador novo; a hora fixa do exemplo destina-se apenas ao editor do parser.

Em Security Operations > Integrations > Custom Parsers > Add Custom Parser, criar um parser novo chamado AVANET_LAB_JSON_AUTH. Selecionar Standalone, formato de origem JSON e schema de destino Auth. Não substituir nem ampliar parsers globais existentes. O modelo completo seguinte descreve exclusivamente o formato deste laboratório:

!SCHEMA=scwx.auth
!CONFIRMWITH=PATTERN
!CONFIRMSTRING=^\{"product":"avanet-siem-lab","schema_version":1,"event_type":"logon","sensor_id":"avanet-lab-source","user":"[^"]+","src_ip":"[^"]+","session_id":"[^"]+","time":"[^"]+","result":"(success|failure)"\}$
!TRIMALLOFF
!SAMPLE={"product":"avanet-siem-lab","schema_version":1,"event_type":"logon","sensor_id":"avanet-lab-source","user":"pilot-user","src_ip":"192.0.2.25","session_id":"avanet-lab-20261029T101500Z","time":"2026-10-29T10:15:00Z","result":"success"}

json = JSON(originalData$)
sensorType$ = "AVANET_SIEM_LAB"
sensorId$ = json["$.sensor_id"]
sourceUserName$ = json["$.user"]
sourceAddress$ = json["$.src_ip"]
sessionId$ = json["$.session_id"]
authSystem$ = json["$.product"]
eventTimeUsec$ = DATETIME(json["$.time"], "2006-01-02T15:04:05Z07:00")
authCategory$ = 10
action$ = IF json["$.result"] == "failure" THEN 8 ELSE 1
actionResult$ = IF json["$.result"] == "success" THEN 10 ELSE 20

A Confirm String limita-se deliberadamente a esta serialização compacta exata com ordem fixa dos campos. JSON formatado com indentação ou com outra ordem não corresponde. Para uma fonte real, redesenhar o padrão de reconhecimento a partir de mensagens originais representativas; uma pesquisa ampla apenas por «logon» não é uma alternativa equivalente.

Neste laboratório, os campos Auth utilizados e os seus valores enum fixos são mapeados da seguinte forma:

Os números são Enums do schema, não gravidades escolhidas livremente. O modelo de formato temporal Go em DATETIME() preserva o indicador UTC ou um offset de fuso ISO-8601. Comparar no editor o valor original e o tempo normalizado em microssegundos. O modelo não define tenantId$ nem resourceId$; não substituir estes valores por identificadores de tenant ou evento inventados.

Verificar no editor sem ativar

Inserir a linha de exemplo em Sample Message. Abrir Parse Message e depois Source Destination Mapping. Comparar schema, utilizador, endereço, hora, resultado e extractor path com a tabela. Esclarecer qualquer aviso relativo a outro parser antes de ativar.

Guardar depois várias mensagens individuais como contraprovas:

• Alterar result para failure: esperam-se action=8 e action_result=20.
• Alterar product para other-lab: a mensagem não deve ser atribuída a este parser.
• Alterar result para unknown ou remover user: a mensagem não deve ser normalizada como login bem-sucedido; a Confirm String restrita deve excluí-la.
• Inserir uma hora inválida: um erro ou a ausência de uma hora correta impede a aprovação. Não aceitar a hora de importação como sucesso aparente.

Run Test verifica o esquema e os Extractor Paths de todas as amostras introduzidas. A Sophos recomenda amostras diferentes e 12–15 execuções de teste; controlar o percurso do parser realmente utilizado. Parse Message apresenta a Parsed Source Message e o Source Destination Mapping para verificação individual. Um teste não guarda o parser; Save e Deploy são passos separados. Guardar não constitui prova de teste. Manter inicialmente desativado um parser novo. Num parser já ativo, as alterações teriam efeito imediato ao guardar; por isso, este laboratório utiliza um parser próprio novo. O runbook de parsers explica a ativação e o percurso de reversão.

Preparar um único envio HTTP

Após aprovação no tenant de teste, criar uma integração separada AVANET-LAB-HTTP em Security Operations > Integrations > Marketplace > Custom > HTTP Ingest > Set Up. Guardar imediatamente Integration Key e URL no Secret Store aprovado; a Sophos mostra-os apenas uma vez. Não mudar ainda nenhuma fonte existente.

O exemplo Python seguinte envia exatamente uma mensagem gerada pelo próprio script. URL e chave são solicitados com entrada oculta, sem ficarem como argumentos da linha de comandos, variáveis da shell ou parte do código-fonte. A verificação normal do certificado TLS mantém-se ativa; os redirecionamentos HTTP não são seguidos para não enviar a chave Bearer a outro destino. O script não inclui repetições automáticas, que poderiam criar eventos duplicados sem comportamento confirmado.

import datetime
import getpass
import json
import urllib.error
import urllib.parse
import urllib.request
import uuid

class NoRedirect(urllib.request.HTTPRedirectHandler):
    def redirect_request(self, req, fp, code, msg, headers, newurl):
        return None

url = getpass.getpass("Integration URL: ").strip()
key = getpass.getpass("Integration Key: ")
parsed = urllib.parse.urlsplit(url)
if parsed.scheme != "https" or not parsed.hostname or parsed.username or parsed.password or parsed.fragment:
    raise SystemExit("Nur die freigegebene HTTPS-URL ohne eingebettete Zugangsdaten verwenden.")

now = datetime.datetime.now(datetime.timezone.utc)
time_text = now.strftime("%Y-%m-%dT%H:%M:%SZ")
run_id = "avanet-lab-" + now.strftime("%Y%m%dT%H%M%SZ") + "-" + uuid.uuid4().hex[:8]
event = {
    "product": "avanet-siem-lab",
    "schema_version": 1,
    "event_type": "logon",
    "sensor_id": "avanet-lab-source",
    "user": "pilot-user",
    "src_ip": "192.0.2.25",
    "session_id": run_id,
    "time": time_text,
    "result": "success",
}
request = urllib.request.Request(
    url,
    data=json.dumps(event, separators=(",", ":")).encode("utf-8"),
    headers={"Authorization": "Bearer " + key, "Content-Type": "application/json"},
    method="POST",
)
print("Testkennung:", run_id, "UTC:", time_text)
try:
    with urllib.request.build_opener(NoRedirect()).open(request, timeout=15) as response:
        print("HTTP-Status:", response.status)
except urllib.error.HTTPError as error:
    print("HTTP-Fehler:", error.code, "— nicht automatisch erneut senden.")
except urllib.error.URLError:
    print("Verbindungs- oder TLS-Fehler — URL, Vertrauenskette und Netzwerkweg prüfen.")

Guardar o código num ficheiro de laboratório local sem segredos e executá-lo com Python 3. O URL tem de provir exatamente da integração de laboratório aprovada; o código não verifica a titularidade de um host HTTPS arbitrário. Não incluir chave nem URL em gravações públicas da consola ou tickets. O script não gera dados de clientes, palavras-passe ou sessões de produção.

Mesmo após uma resposta HTTP, não se afirma que a ingestão tenha sido bem-sucedida. Após um timeout, pode ser incerto se o servidor já aceitou a mensagem. Antes de repetir, pesquisar pelo identificador de teste registado. Perante 401/403, esclarecer credenciais atribuídas e aprovação, sem ampliar permissões por tentativa. Perante 4xx devido ao corpo, verificar o requisito concreto de ingestão em vez de experimentar invólucros JSON ao acaso.

Pesquisar a mensagem original e o evento normalizado

Verificar primeiro o transporte separadamente. Em Data Lake Search > Query Editor, pesquisar numa janela curta pelo identificador de teste apresentado:

FROM generic WHERE original_data CONTAINS 'avanet-lab-20261029T101500Z' earliest=-1h

Substituir o exemplo pelo identificador realmente apresentado. Em Original Data, produto, identificador da fonte, utilizador, hora e resultado devem corresponder à linha enviada. sensor_id no evento genérico pode ser determinado pelo percurso de ingestão. O nome de apresentação da integração não é automaticamente o identificador correto para pesquisa. Se for necessário filtrar também por sensor_id, utilizar primeiro o valor efetivamente existente.

Depois de os testes no editor passarem, ativar deliberadamente o novo parser de laboratório e enviar uma mensagem de teste nova. Não pressupor que isto volta a normalizar retroativamente os dados originais já recebidos. Pesquisar o evento Auth esperado pelos campos definidos do laboratório:

FROM auth WHERE sensor_id = 'avanet-lab-source' AND session_id = 'avanet-lab-20261029T101500Z' earliest=-1h

Substituir também aqui o identificador. No resultado, verificar Normalized Data: source_user_name=pilot-user, source_address=192.0.2.25, hora correspondente à origem, action=1, auth_category=10 e action_result=10, ou os nomes Enum apresentados na interface. O extractor path deve pertencer ao parser de laboratório. Utilizar esta lista para a aceitação do laboratório.

Para a tentativa falhada controlada, alterar apenas result para failure no gerador próprio, gerar um identificador novo e enviar novamente uma única vez. O schema deve então mostrar action=8 e action_result=20. Um resultado adicional de normalização bem-sucedida para unknown ou para outro identificador de produto seria, pelo contrário, motivo para parar.

Diagnosticar erros e desativar o laboratório

Sem mensagem original: Verificar hora de envio, identificador, resposta do transporte, tenant, janela temporal e fonte corretos. A ausência de resultados não prova isoladamente uma falha do transporte; a pesquisa genérica requer os parâmetros avançados e o acesso a original_data é limitado no tempo.

Mensagem original presente, sem resultado Auth: Verificar estado do parser, serialização exata, Confirm String, schema e percurso do parser. Não alargar parsers de produção apenas para capturar o evento de laboratório.

Resultado Auth com resultado ou hora incorretos: Comparar separadamente origem e mapeamento. Desativar o parser e corrigir a versão guardada do script; não preencher com valores predefinidos inventados.

Após a validação, terminar o emissor próprio e desativar apenas o parser de laboratório recém-criado através de Disable. Isto termina a sua normalização adicional; dados genéricos e eventos já guardados não são considerados eliminados. Remover a integração de laboratório só depois de esclarecer a substituição/revogação da chave e obter aprovação. A desativação não pode alterar uma integração partilhada ou outra fonte.

A manutenção seguinte acompanha o procedimento SIEM: documentar em conjunto formato de origem e versão do parser, voltar a validar após alterações e planear separadamente retenção e tratamento de alertas.