Compreender o Sophos Next-Gen SIEM e planear a retenção

Sophos Next-Gen SIEM é um complemento opcional para Sophos XDR Powered by Secureworks e Sophos MDR. Antes da utilização, a conta tem de ter sido atualizada para o Sophos Fusion. A ajuda técnica de administração descreve 13 meses de conservação de dados como padrão e a possibilidade de extensão até 10 anos. Acrescentam-se telemetria de ameaças e de conformidade e integrações personalizadas além das integrações XDR/MDR pré-configuradas. Este enquadramento foi verificado em 28 de outubro de 2026; a indicação divergente de um ano na página do produto é contextualizada abaixo para a aquisição.

Para tomar a decisão, deve começar-se por registar as fontes de dados e os períodos de conservação necessários. Depois, solicita-se a confirmação do âmbito concreto do complemento para o tenant e verifica-se, com uma pequena fonte piloto, se os eventos previstos são efetivamente ingeridos e podem ser encontrados novamente. Uma licença XDR ou MDR existente, por si só, não comprova que o complemento opcional esteja ativado.

Quando o Next-Gen SIEM se adequa à tarefa

SIEM significa Security Information and Event Management: os dados de eventos são recolhidos centralmente e disponibilizados para análise. O Next-Gen SIEM complementa a arquitetura de dados comum ao XDR/MDR para uma conservação mais longa e análises de conformidade. Vale sobretudo a pena avaliá-lo quando são necessários eventos históricos de períodos mais longos ou quando se pretende incorporar uma fonte através de uma integração própria.

Se a tarefa inicial for configurar uma integração de produto existente, começa-se pelas integrações MDR e XDR no Sophos Fusion. Esse artigo explica o fluxo de dados e as verificações operacionais. A ligação syslog do Sophos Firewall aborda o transporte de registos do firewall para um recetor. Não determina qual o âmbito do Next-Gen SIEM adquirido ou ativado para uma fonte.

A plataforma principal para deteção, investigação, resposta e automatização continua a ser o Sophos XDR. O Next-Gen SIEM complementa estes fluxos de trabalho com recolha de dados orientada para a conformidade, evidências históricas e conservação mais longa. Por isso, o complemento SIEM não é um requisito geral para funções de deteção ou resposta XDR já licenciadas; inversamente, o XDR por si só não ativa os serviços SIEM adicionais.

A Avanet recomenda que o complemento não seja escolhido apenas para obter a retenção mais longa possível. Retenção significa aqui conservação de dados. O que importa é saber quais os eventos que serão necessários mais tarde, para responder a que perguntas, quem os vai analisar e durante quanto tempo devem estar disponíveis. Guardar dados durante mais tempo ajuda pouco se a categoria de eventos necessária não for fornecida ou se faltarem campos importantes.

A Sophos também descreve dashboards de conformidade pré-configurados. Estas análises apoiam a recolha de evidências, mas não substituem a verificação da cobertura dos dados, uma avaliação jurídica ou uma certificação. O complemento não permite concluir que a conformidade é cumprida automaticamente.

Esclarecer o tenant e a oferta antes da implementação

Antes da aquisição, documentam-se o tenant correto, o produto XDR/MDR utilizado e o estado real da atualização para o Fusion. Um anúncio ou uma data prevista de atualização não bastam para autorizar a utilização operacional. Em seguida, solicita-se ao parceiro Sophos que confirme se o Next-Gen SIEM está disponível para essa conta e que conservação e serviços de integração inclui a oferta concreta.

A Sophos descreve um modelo de preços baseado em utilizadores e servidores, sem taxas de ingestão, ou seja, sem uma taxa em função do volume de dados incorporados. Trata-se de uma descrição do modelo de preços, não de uma proposta comercial nem de uma promessa de capacidade técnica ilimitada. Antes da encomenda, têm de ser esclarecidos o método de contagem, a duração do contrato, a extensão de retenção pretendida, o âmbito das integrações e os possíveis requisitos do produto de terceiros. Em particular, esta descrição não permite deduzir licenças gratuitas de terceiros nem limites garantidos de débito ou de eventos.

Para as integrações personalizadas, está confirmada a possibilidade de criar integrações de dados próprias. Isso não comprova ainda um procedimento de configuração para todas as fontes. Antes do piloto, é por isso necessária uma descrição adequada à fonte concreta, que abranja transmissão, autenticação, formato dos eventos, mapeamento de campos e análises suportadas. Os menus ou consultas de conectores existentes não devem ser transpostos para uma integração personalizada sem verificação. O acesso ao dashboard é descrito abaixo; daí não se deduz um procedimento de configuração universal para todas as fontes personalizadas.

Confirmar expressamente a quantidade de licenças e o percurso do Collector

O Next-Gen SIEM não pode ser adquirido como produto autónomo. O número das suas subscrições tem de corresponder ao número total de utilizadores e servidores licenciados de XDR e MDR; os servidores não podem ser omitidos da contagem. Compare o inventário concreto e a oferta com o parceiro, em vez de utilizar apenas um grupo-piloto ou o volume de dados como quantidade de licenças. Além dos 13 meses padrão, as extensões de retenção para três, cinco, sete ou 10 anos são opções que podem ser adquiridas, não uma ativação automática proporcionada por uma licença XDR/MDR existente. Não recuperam retroativamente histórico cujo prazo tenha expirado nem comprovam conformidade legal.

As diretrizes de licenciamento em vigor desde 16 de outubro de 2026 indicam ainda um limite de utilização de 1 GB de dados brutos ingeridos por dia, agregado entre todas as fontes. A tabela licencia por utilizadores e servidores, mas a frase sobre volume não esclarece se a quantidade se aplica por subscription ou ao tenant. Assim, não calcular 1 GB × utilizadores e servidores nem assumir um limite fixo de 1 GB por tenant. Antes do dimensionamento ou encomenda, obter confirmação vinculativa da unidade de referência, agregação e comportamento em caso de excesso. Um preço sem custos de ingestion dependentes do volume não significa utilização ilimitada.

O número de subscriptions Retention Add-on também deve corresponder ao total de subscriptions NG-SIEM. Não se deduz daí retenção prolongada para um subconjunto escolhido livremente ou uma única fonte.

Nas integrações Syslog, os antigos Sophos Log Collectors não suportam o âmbito completo de retenção do Next-Gen SIEM. Para esse efeito, a Sophos recomenda a mudança para XDR Data Collectors; o runbook existente de migração de Collectors explica o provisionamento, a implementação, a mudança das fontes e a aceitação. As integrações API existentes não precisam de reconfiguração apenas devido a esta mudança de Collector. Numa SVA partilhada, o NDR continua a ser uma carga de trabalho separada e não pode ser desligado inadvertidamente durante a transição Syslog. O novo Collector não substitui a verificação do direito de utilização do complemento, do formato da fonte e da retenção efetiva.

O hub SIEM organiza os guias existentes por planeamento, recolha de fontes, transporte e verificação do parser. O exemplo prático de HTTP e parser liga estas etapas a uma fonte sintética de laboratório; a sua validação prática no tenant continua pendente.

Dados personalizados: distinguir transporte, normalização e deteção

Uma Custom Integration transporta dados de uma fonte não otimizada pela Sophos para o XDR. Isto não confirma ainda a normalização, a pesquisa ou a deteção para essa fonte. Os Custom Parsers mapeiam os campos dos registos para os esquemas de eventos XDR normalizados e suportados. Só depois é possível verificar se estão presentes os campos necessários para a pesquisa pretendida, um Detector ou uma Custom Detection Rule.

Os Custom Parsers exigem uma subscrição Next-Gen SIEM. As funções Admin e Super Admin podem geri-los; as outras funções só podem consultar a lista de parsers configurados. As mensagens que não correspondem a nenhum parser utilizam o esquema generic como alternativa. Podem fornecer contexto para Cases e Custom Rules, mas só aparecem nos resultados de pesquisa com parâmetros de pesquisa avançados. Por isso, uma pesquisa simples sem resultados não comprova que os dados não tenham sido ingeridos.

Mesmo os dados corretamente normalizados não ativam automaticamente todos os Detectors compatíveis com o esquema. A Sophos indica determinados percursos de deteção suportados e os respetivos campos obrigatórios; outros Detectors não são garantidos. A deteção pretendida é, por isso, validada separadamente com eventos de teste adequados. O apoio de IA anunciado não substitui esta verificação.

Um Custom Parser recém-criado está desligado por predefinição. É testado repetidamente com diferentes mensagens de exemplo, guardado e só depois ativado separadamente. As alterações a um parser já ativo, pelo contrário, entram em vigor imediatamente ao guardar; por isso, é necessário testar cuidadosamente antes de guardar. Confirm Strings sobrepostas podem atribuir mensagens ao parser errado; por isso, o extractor path efetivamente utilizado faz parte da verificação.

A Sophos não mantém nem atualiza os Custom Parsers. O operador responsável tem de voltar a verificar o mapeamento de campos, os carimbos temporais e os resultados de pesquisa ou deteção após alterações ao formato da fonte ou ao parser. No piloto, documentam-se a ingestão, a normalização e a análise pretendida como três resultados separados; um estado de transporte verde não basta.

A configuração prática é descrita em Custom HTTP Ingest, nas variantes S3, em Azure Event Hubs e Storage e no runbook Custom Parser. Para cada variante, transporte, esquema e análise pretendida permanecem resultados de aceitação separados.

Abrir o dashboard NG-SIEM para verificar evidências

Com o complemento ativado, a vista disponibilizada pode ser adicionada à lista pessoal de dashboards:

Abrir Dashboards > Manage dashboards.
Selecionar Find dashboards e adicionar NG-SIEM à lista.
Abrir o dashboard a partir da lista e comparar os dados apresentados com o inventário de fontes, o período e os eventos esperados.

O dashboard NG-SIEM inclui widgets sobre controlo de acesso, segurança de rede e eventos de auditoria. A Sophos descreve ainda um exemplo de dashboard ISO 27001 que reúne autenticação, alterações, eventos de rede e firewall, atividade de e-mail e ficheiros, bem como fluxos de deteção e Cases. As informações efetivamente disponíveis para comprovação dependem das fontes ligadas e da qualidade dos respetivos dados; a apresentação não constitui uma certificação ISO nem uma confirmação automática de conformidade.

O guia geral de dashboards explica as listas pessoais, as vistas disponíveis e a exportação PDF. Se NG-SIEM não aparecer, verificam-se primeiro o tenant, o complemento e as permissões; uma vista vazia é analisada em relação à origem dos dados e ao período. Nem os widgets em falta nem os widgets verdes substituem a verificação dos eventos subjacentes.

A ajuda NG-SIEM específica do produto de 1 de outubro de 2026 descreve este acesso. A ajuda comum de dashboards mais antiga, de 17 de setembro, ainda refere apenas o dashboard TAC. A vista e os limites efetivos devem ser confirmados no tenant. Se a entrada não existir apesar de uma proposta correspondente, esclarecer o provisionamento real; não criar uma segunda integração por suspeita.

Distinguir retenção, janelas de pesquisa e dados brutos

13 meses na ajuda de administração, um ano na página do produto

A visão geral técnica de 1 de outubro de 2026 indica 13 meses de retenção padrão. Em contrapartida, a página pública do produto, verificada em 28 de outubro, indica um ano. Ambas referem extensões para três, cinco, sete ou dez anos. A diferença não é interpretada como uma alteração confirmada do produto nem como um simples arredondamento; falta uma explicação inequívoca da Sophos para isso.

Para o enquadramento técnico deste artigo, a referência são os 13 meses da ajuda de administração específica do produto. Ainda assim, antes de encomendar ou de assumir um compromisso vinculativo de conservação, confirma-se o período aplicável ao tenant concreto, aos tipos de dados e à proposta. A confirmação fica registada no inventário de fontes. Se a operação precisar, por exemplo, de mais de doze meses de histórico, não se deve presumir o período adicional apenas com base na publicidade geral do produto. O inventário de retenção e a validação abaixo verificam o âmbito acordado; não resolvem o conflito entre fontes através de um prazo presumido.

Período de pesquisa e acesso aos dados brutos

Uma retenção longa não permite uma consulta arbitrariamente grande numa única execução. A ajuda atual de esquemas admite no máximo 31 dias por consulta para Events normalizados, com qualquer início dentro dos dados realmente conservados. Dividir investigações mais longas em janelas adequadas. A pesquisa de detections é separada.

Para @raw e original_data, o guia SQL-QL mais recente, de 15 de setembro de 2026, indica um limite de acesso separado de 20 dias. Um pedido fora desse âmbito é rejeitado, não encurtado silenciosamente para o intervalo permitido. A ajuda Query Language anterior também menciona incrementos de 20 dias; isto não garante dados brutos mais antigos. Dividir pedidos não torna esses dados automaticamente acessíveis. Este limite não prova eliminação física após 20 dias nem uma redução geral da retenção normalizada.

Data Lake Search e exportação explica escolha de esquema, limites de consulta, janelas históricas e prova de exportação completa. A operação das regras distingue uma pesquisa bem-sucedida de uma regra de detection ou suppression avaliada continuamente.

Criar um inventário de retenção por fonte

O inventário faz parte da documentação operacional, não apenas da oferta. Registam-se os seguintes dados para cada fonte; diferentes categorias de eventos da mesma aplicação podem exigir entradas próprias:

Sistema de origem, tenant de origem, categorias de eventos e pessoa responsável.
Objetivo da ingestão e pergunta concreta a que uma futura pesquisa ou evidência deverá responder.
Campos necessários, por exemplo, data e hora do evento com fuso horário, ação, resultado e uma identidade adequada à investigação.
Classificação dos dados, conteúdo permitido e autorização para transmissão e acesso.
Conservação pretendida com a respetiva justificação e âmbito confirmado que se aplica efetivamente.
Método de integração, permissões necessárias e responsável pelas credenciais, sem copiar segredos para o inventário.
Início da ingestão, atraso de processamento esperado e um evento de teste reproduzível.
Método de pesquisa verificado, registo mais antigo encontrado, última verificação bem-sucedida e próxima data de revisão.
Procedimento em caso de falha, mudança de fonte, alteração da conservação e desativação da integração.

A indicação do produto 13 meses, extensíveis até 10 anos não é registada automaticamente como prazo efetivo para todos os registos existentes. Para a própria fonte, têm de ser esclarecidos o âmbito, o início e o acesso aos dados históricos. Também não se deve pressupor uma importação retroativa de dados antigos nem a recuperação de dados cujo prazo já tenha expirado.

Exemplo de uma fonte piloto

O exemplo seguinte é um registo de planeamento, não uma configuração Sophos nem um conector verificado. Os valores são requisitos escolhidos livremente para uma organização fictícia:

Fonte: aplicação empresarial interna, ambiente de teste
Eventos: início de sessão bem-sucedido e alteração administrativa de função
Objetivo: identificar quem alterou uma permissão
Campos obrigatórios: data e hora do evento com fuso horário, conta de teste, ação, resultado
Conservação pretendida: 24 meses
Justificação: período de investigação aprovado internamente
Âmbito confirmado: ainda por esclarecer antes da encomenda e do piloto
Ligação e método de pesquisa: ainda por confirmar para esta fonte personalizada
Teste: alteração autorizada de função numa conta dedicada ao teste
Reversão: repor a função inicial e verificar a alteração
Equipas responsáveis: equipa da aplicação em conjunto com a equipa de operações de segurança

Os 24 meses são aqui um requisito interno, não um prazo legal geral nem um padrão do produto. Excedem a retenção padrão descrita; por isso, tem de ser confirmada uma extensão adequada antes da aprovação. As contas e os eventos são substituídos pelos próprios dados de teste autorizados. Não se alteram permissões de produção para este teste.

Validar separadamente a ingestão e a conservação

Para o piloto, registam-se o estado inicial e o início da ingestão. Os percursos de registo existentes mantêm-se até à aceitação da nova fonte. Depois gera-se um evento inofensivo e autorizado que pertença à categoria prevista. No exemplo, altera-se a função da conta de teste e, em seguida, repõe-se o valor inicial documentado.

Após o tempo de processamento esperado, verifica-se o seguinte através do método de pesquisa ou análise confirmado para essa fonte:

O evento de teste exato está presente no tenant correto?
O sistema de origem, a data e hora do evento, a ação e o resultado coincidem com a evidência da fonte?
Os campos necessários estão mapeados de forma compreensível, em vez de surgirem apenas como texto bruto inutilizável?
É possível acompanhar outros eventos esperados ao longo do período piloto?

Um registo recém-encontrado comprova a ingestão deste teste, não uma conservação de vários anos. Para aceitar a retenção, compara-se também o âmbito confirmado com a configuração efetiva ou com uma confirmação específica do tenant. Os dados históricos já existentes são verificados num intervalo de tempo definido; registam-se o registo mais antigo encontrado e as lacunas conhecidas. Para uma fonte nova sem histórico, documenta-se que a conservação a longo prazo ainda não foi comprovada pelo tempo decorrido e planeiam-se verificações posteriores.

A verificação da ingestão não exige um alerta de segurança. Um evento de auditoria normal pode ser necessário como registo sem dar origem a um incidente. Data Collection e Live Discover explica as consultas XDR existentes; daí não resulta, porém, uma consulta universal para uma nova fonte personalizada.

Isolar falhas e reverter alterações em segurança

Se o complemento ou uma função estiver em falta, verificam-se primeiro o tenant, o estado real da atualização para o Fusion e o âmbito confirmado do complemento. Não se cria uma segunda integração por tentativa nem se altera uma política de proteção de endpoints para resolver uma suposta falta de licença.

Se faltarem eventos recentes, compara-se primeiro a evidência da fonte com o início da ingestão, a categoria de eventos, a autenticação, o formato e o atraso de processamento acordado. Se existirem registos, mas forem inutilizáveis, verificam-se o mapeamento de campos e as referências temporais. Se faltarem apenas eventos mais antigos, investigam-se separadamente o início da ingestão, as lacunas de dados, a retenção efetiva e o intervalo de pesquisa. Uma extensão posterior da retenção não é uma solução garantida para dados que já estão em falta.

Antes de reduzir a conservação ou desativar a integração, esclarece-se com os responsáveis quais os dados ainda necessários e como os preservar, quando suportado e necessário. Não se deve assumir que voltar mais tarde ao valor anterior recuperará o histórico perdido. Do mesmo modo, remover uma integração não comprova a eliminação dos dados já ingeridos.

Se o piloto falhar, reverte-se apenas a alteração documentada na fonte piloto, através do procedimento de reversão confirmado para essa fonte. As credenciais partilhadas, os coletores e as outras fontes mantêm-se intactos. Depois verificam-se o estado reposto da fonte e o percurso de registo anterior que continua a ser necessário. A eliminação de dados e o cancelamento do complemento são esclarecidos separadamente com o parceiro ou os responsáveis; este artigo não promete um interruptor universal para essas operações.

Para a passagem à operação, têm de estar disponíveis o inventário de fontes, o âmbito confirmado, as evidências do piloto, as lacunas históricas em aberto, a responsabilidade em caso de falha e a data de revisão. Se o formato dos dados, o método de pesquisa ou a retenção de uma fonte necessária continuarem por esclarecer, essa fonte ainda não foi aceite. Para escalar o caso, bastam inicialmente a identificação do tenant, o intervalo de tempo, a categoria de eventos e evidências de erro expurgadas; segredos e dados pessoais brutos desnecessários não devem constar do pedido.