Sophos SIEM: escolher transporte e configurar HTTP Ingest

HTTP Ingest recebe mensagens de registo através de um endpoint HTTPS fornecido pela Sophos. A origem deve suportar HTTP POST para webhook ou endpoint HTTP com autenticação por token Bearer. É necessária uma subscrição Sophos Next-Gen SIEM; uma licença XDR existente não basta.

São três tarefas distintas: escolher transporte, ligar origem e verificar os eventos reais. Criar o conector não comprova normalização ou deteção corretas. Antes do piloto, consultar os fundamentos SIEM e a verificação de licenças.

Que transporte se adequa à origem?

Custom destina-se a origens sem integração Sophos otimizada adequada. Verificar primeiro no Marketplace a integração do produto e as categorias efetivas. Um fornecedor conhecido não significa suporte para todos os seus registos.

Existem seis opções:

• HTTP Ingest: HTTPS POST direto com Bearer, sem infraestrutura cloud própria a operar.
• Customer-Managed S3: registos num bucket da própria conta AWS, encaminhados pela configuração Lambda/CloudFormation fornecida.
• S3 Ingest – Sophos-Managed (with token): destino gerido pela Sophos com prova de propriedade exigida pelo fornecedor.
• S3 Ingest – Sophos-Managed (without token): mesmo modelo sem essa verificação.
• Azure Event Hubs: fluxo de eventos num hub acessível.
• Azure Storage Account: ficheiros em Blob Storage, encaminhados por Azure Function.

O guia S3 distingue os três buckets; o guia Azure separa Event Hubs de Storage/Function. Um dispositivo syslog pode precisar de um XDR Data Collector; o seu IP não substitui o endpoint HTTP Ingest.

Preparar piloto e credenciais

Registar tenant, direito SIEM, origem, categoria e responsável. A configuração geral exige função Admin ou Super Admin adequada e acesso à exportação da origem. A documentação desta deve explicar URL, Bearer, formato e comportamento de transmissão; não se pressupõe JSON universal.

Escolher origem de teste autorizada e evento inofensivo identificável. Anotar hora/fuso, identificador e campos esperados. Manter os percursos existentes até à aceitação; o envio adicional não deve criar duplicados involuntários nem transferir dados pessoais não autorizados.

Integration Key e URL são apresentadas apenas uma vez. Preparar previamente o cofre de segredos aprovado. Não deixar chaves em capturas, pedidos de suporte, repositórios públicos ou comandos guardados no histórico da shell. Documentar proprietário e rotação controlada. O Integration Credential Manager suporta tipos específicos, não qualquer chave de ingestão.

Criar HTTP Ingest no Sophos Fusion

1. Abrir Security Operations > Integrations > Marketplace > Custom.
2. Em HTTP Ingest, selecionar Set Up.
3. Introduzir nome único, por exemplo Aplicacao-Teste-HTTP, e Done. É uma etiqueta livre para identificar origem e ambiente.
4. Guardar imediatamente Integration Key e URL no cofre; não voltarão a ser apresentadas. Sem cópia segura, suspender a ligação e esclarecer a substituição suportada; não se promete recuperação posterior.
5. Configurar a exportação HTTPS documentada com esses valores exatos. Verificar Bearer, formato e eventuais tentativas/buffering pela documentação da origem. Não usar payload inventado ou modelo de outra API.
6. Localizar a ligação em Configured integrations da página Custom, enviar o evento e verificar a ingestão separadamente.

O exemplo prático de HTTP e parser descreve uma fonte sintética própria com modelo completo de parser e consultas. Distingue expressamente resultados esperados do teste prático no tenant ainda pendente.

Validar transporte, normalização e análise

Uma Custom Integration assegura inicialmente transporte para XDR. Tipos suportados usam a normalização existente; formatos próprios ou não suportados podem chegar a generic. O modelo de parsers no guia SIEM explica a eventual necessidade de parser personalizado e campos obrigatórios.

Para a aceitação, abrir Security Operations > Integrations > Configured Data Sources e selecionar a própria origem. Nos detalhes da origem, Advanced Search apresenta uma pesquisa preparada para o respetivo ID de sensor nas últimas 24 horas. Restringir o intervalo ao momento do teste e comparar tenant, identificador da origem, hora do evento, ação e campos necessários com o evento enviado. Validar integrações explica o ponto de entrada e Data Lake Search o refinamento da pesquisa.

Verde indica ligação, não dados completos ou esquema correto. Texto bruto generic não comprova que um detector pretendido o consiga usar. Ausência de resultados na pesquisa simples não exclui dados generic.

Aprovar o piloto só com transporte, mapeamento utilizável e pesquisa comprovados separadamente. Testar deteção apenas quando existir lógica adequada e suportada para a origem. Um evento comum de auditoria ou início de sessão não tem de gerar alerta.

Erros e remoção controlada

Se faltarem dados, verificar primeiro envio real, endpoint e uso da chave como Bearer. Depois erros da origem, rede, intervalo e estado. Sucesso HTTP não substitui prova do evento. Se os dados chegam mal associados, analisar formato/parser em vez de criar preventivamente outro conector.

Para pausa, parar a exportação pelo procedimento documentado da origem. Antes de remover, esclarecer dependências, provas históricas e conservação. Parar apenas este encaminhamento e verificar o percurso anterior necessário. Eliminar integração, revogar chave e apagar histórico são operações distintas, sem botão universal prometido. Em caso de perda/comprometimento, esclarecer com Sophos substituição/revogação suportadas, sem improvisar rotação não testada.