Saltar para o conteudo
Avanet
Iniciar sessao

Sophos Endpoint Data Collection e Live Discover

Data Collection and Investigation Policy controla duas funções independentes: Live Response Connections e upload de Endpoint Telemetry para o Sophos Data Lake. Live Discover usa dados atuais do dispositivo ou dados históricos do Data Lake.

As funções exigem Sophos EDR, XDR ou MDR. Live Response possui permissões próprias e é descrito no artigo Response.

Procedimento rápido para Classic: Em Threat Analysis Center > Live Discover, selecione primeiro a Data source adequada e, em seguida, Query category e Query. Numa Endpoint Query, limite deliberadamente os dispositivos de destino em Devices e selecione depois Run Query. O resultado só é fiável quando as linhas de resultados e Telemetry correspondem à origem, ao período e aos dispositivos esperados.

Antes da consulta, verificar se o tenant utiliza Threat Analysis Center ou Security Operations. Threat Analysis Center continua disponível como Classic view. Security Operations separa Data Lake Search, para dados históricos, de Live Endpoint Search, para consultas em dispositivos ligados. Os passos de Live Discover, exemplos SQL, indicações de agendamento e limites da interface abaixo descrevem Classic, salvo referência expressa a outra interface. Uma atualização do tenant não os invalida nem os traduz automaticamente para QL.

Em Security Operations > Data Lake Search, é possível pesquisar as Detections e os eventos do tenant através de três métodos. Esta interface utiliza Advanced Search query language, ou QL; o SQL de Data Lake de Classic não deve ser copiado para ela sem alterações.

  • AI Search traduz uma pergunta em linguagem natural numa consulta. Introduza a pergunta ou um prompt preparado, selecione Search e verifique a consulta gerada juntamente com os resultados. Browse Prompts ou View All abre os prompts; Sophos Only, os filtros de categoria e um termo de pesquisa limitam a seleção. Se necessário, refine o prompt e pesquise novamente.
  • Query Builder constrói visualmente a consulta a partir de campos e operadores. Defina a data e o período antes de Search ou Shift + Enter. Para uma primeira verificação, utilize um período curto com um evento conhecido e confirme se a origem e os filtros realmente o incluem.
  • Query Editor permite escrever consultas QL próprias. Basics apresenta os fundamentos da sintaxe e exemplos; Cheat Sheet, os operadores e as funções. Search Help fornece ajuda contextual Build With Me para esquemas e campos. Aqui também deve definir a data e o período antes de Search ou Shift + Enter. Os exemplos SQL das secções Classic posteriores não são modelos QL.

O botão de fixação junto ao nome do método define o método de pesquisa preferido. Cada pesquisa executada é adicionada automaticamente ao histórico de pesquisas do tenant; por isso, não é apenas um rascunho local. Limite os prompts e as consultas à pergunta de investigação e não introduza segredos. Uma tabela vazia só é significativa depois de verificar o período, a origem e os filtros; não prova a ausência de um incidente.

Para guardar em AI Search e Query Editor, selecione Save Query; em Query Builder, selecione primeiro Save Search. Introduza um nome e uma categoria, adicione opcionalmente uma descrição e Bookmark this Query, e conclua com Save Query. Volte a abrir e verifique a consulta guardada em Saved Queries. Um marcador também a coloca em My Bookmarked Queries.

Full Screen amplia a vista dos resultados. O menu do cabeçalho da coluna oferece Pin, Autosize, Reset, Filter e opções para mostrar ou ocultar colunas; arraste os cabeçalhos para alterar a ordem. Em Actions, acima da tabela, pode exportar todos os resultados ou um subconjunto selecionado. Verifique depois o estado da exportação e a transferência em Data Exports. Não documente uma vista filtrada ou uma exportação parcial como o âmbito completo da investigação.

Distinguir Live Endpoint Search das API de dados históricos

Live Endpoint Search continua a executar consultas SQL do tipo osquery em endpoints atuais e ligados. A migração de Live Discover de REST para GraphQL diz respeito a esta via em tempo real, não às consultas históricas do Data Lake. O facto de o catálogo LES poder listar consultas guardadas com a origem dataLake não comprova a execução de consultas Data Lake através de LES. Por isso, uma integração existente de API de dados históricos não deve ser migrada apenas com base neste guia.

Desde 12 de outubro de 2026 está publicada a Search GraphQL API v1 para pesquisas QL históricas no Data Lake do Fusion. O processo inclui início, verificação de estado e obtenção paginada de resultados; é distinto do LES e do seu SQL em tempo real do tipo osquery. O runbook Search GraphQL explica pedidos, Search-URN, resultados parciais, cursores, expiração e comparação de um cliente SQL existente. Data Lake Search continua a ser a via interativa e a XDR Query API permanece disponível. Nem esta publicação nem o guia de migração LES traduz automaticamente SQL Classic para QL ou exige uma transição imediata de API.

Clientes REST existentes e uma transição opcional para LES

Live Discover REST está expressamente excluído do anúncio de descontinuação das Classic Cases/Detections APIs. Um cliente existente não tem de ser alterado apenas devido a este anúncio. Para um novo cliente Live Endpoint ou uma mudança deliberadamente planeada, LES é avaliado separadamente; a XDR Query API de dados históricos e as consultas SQL Classic preservadas acima continuam a ser distintas.

LES associa os dispositivos de destino a uma sessão antes de iniciar a Query: execute primeiro createLiveDiscoverSession, guarde o nome de sessão devolvido e atribua depois os dispositivos selecionados à sessão com endpointSessions. Só depois inicie runLiveDiscoverQuery com esse nome como sessionId e com o ainda obrigatório matchEndpoints: { all: false }. Não utilize filtros diretos em matchEndpoints como atalho, mesmo que o esquema os permita: o guia de migração indica apenas o procedimento baseado em sessões como método de integração suportado. Comece com um único dispositivo-piloto aprovado e uma consulta SQL de leitura com âmbito muito limitado; compare a atribuição dos destinos, o estado da execução, as linhas de resultados e Telemetry.

Antes da transição, verifica-se a portabilidade dos IDs de Queries e categorias guardados; o guia não confirma a sua transferência sem alterações. Também é necessário esclarecer com o responsável pela API a retenção dos resultados, a disponibilidade posterior das execuções concluídas e uma alternativa à gestão anterior de Enrichment Pivots. LES aceita apenas um grupo de filtros por chamada de seleção; não se deve determinar por suposição o significado de vários grupos de filtros REST anteriores. tamperProtectionEnabled passa a tamperProtection como lista, e os filtros livres de strings/JSON exigem uma verificação própria dos valores.

A paginação das execuções, do catálogo e dos resultados é implementada separadamente para cada um. Os resultados contêm as colunas de saída SQL como uma string codificada em JSON em additionalColumns; metadata.columns descreve os nomes e tipos. Para as páginas seguintes, devolva o pages.nextKey fornecido, sem alterações, como params.pageFromKey. HTTP 200 não basta: verifique também o array GraphQL errors e o estado real da execução e dos endpoints. LES partilha o limite de 1'000 execuções por dia e 10 por minuto com as Queries agendadas; a API REST indica, em contrapartida, 500 execuções por dia e 10 por minuto. Estes valores específicos de cada API não substituem indiscriminadamente os limites da interface Classic descritos mais abaixo. O volume de dados, o watchdog do dispositivo e os limites de resultados continuam a ter de ser considerados no piloto.

Live Endpoint ou Data Lake

FonteCaracterística
Live Endpointestado atual, apenas dispositivos online selecionados
Data Laketelemetria histórica de todos os dispositivos, incluindo offline

Live Endpoint Queries baseiam-se em osquery e executam-se nos dispositivos. Data Lake Queries usam telemetria enviada, podem ser agendadas e abrangem até 30 ou 90 dias conforme a licença.

O intervalo de tempo do Data Lake em Live Discover define o período histórico consultado, não um agendamento de execução. Uma Query individual abrange no máximo 30 dias. Para 90 dias usam-se várias Queries delimitadas.

Selecionar e testar Queries

Em Threat Analysis Center > Live Discover existem Endpoint e Data Lake Queries preparadas. O procedimento separa deliberadamente a origem, a Query e o destino:

  1. Em Data source, selecione Endpoint para consultar o estado atual dos dispositivos ligados ou Data Lake para consultar telemetria histórica já enviada.
  2. Em Query category, selecione uma categoria e, em Query, a consulta pretendida. Nos detalhes da Query, verifique os sistemas operativos suportados e o System Impact indicado pela Sophos.
  3. Numa Endpoint Query, selecione primeiro um único dispositivo-piloto em Devices. Se necessário, utilize Show filters e atualize depois a lista de dispositivos selecionados. Numa Data Lake Query, defina antes um período curto e conhecido.
  4. Selecione Run Query e aguarde o resultado.

Teste primeiro uma Query nova ou alterada num único dispositivo-piloto ou num período curto do Data Lake. As linhas de resultados devem corresponder ao dispositivo ou período escolhido. Em Telemetry, verifique também se o destino respondeu, qual foi o System Impact e que volume de dados foi transferido. Se o resultado continuar vazio, verifique primeiro Data source, o período, o sistema operativo suportado e, no caso de Endpoint Queries, o estado da ligação do dispositivo. Numa Data Lake Query, confirme também se o upload está ativo em My Products > Endpoint > Policies > Data Collection and Investigation ou, para servidores, em My Products > Server.

Designer Mode permite criar Queries osquery ou SQL próprias. Sophos Support apoia as Sophos Queries preparadas e o caminho dos dados, mas não o desenvolvimento especializado de quaisquer Custom Queries. Para esse efeito, estão disponíveis Community e Professional Services.

Query Results oferecem Pivots, Enrichments e Actions. Um SHA-256 suspeito pode passar para outra Query, uma verificação Intelix ou VirusTotal, um Threat Graph ou Live Response.

Para consultar dados de DNS Protection, consulte Analisar relatórios e Live Discover do Sophos DNS Protection para obter a seleção DNS Protection, o respetivo esquema do Data Lake e as verificações específicas de DNS.

Controlar o envio para o Data Lake

O envio está ativo por predefinição para Endpoint Protection. Em My Products > Endpoint > Policies > Data Collection and Investigation pode ser limitado por grupos.

Desativá-lo reduz as deteções disponíveis e a capacidade de investigação histórica. Uma exceção de recolha de eventos só é usada por instrução do Sophos Support, porque reduz a telemetria e, consequentemente, as capacidades de deteção ou investigação.

Após a ativação, o tráfego de rede pode aumentar temporariamente. Em ligações de baixa capacidade ou segmentos sensíveis, a alteração deve ser observada num grupo-piloto.

Event Journals no dispositivo

A Sophos guarda Event Journals localmente em Windows, macOS e Linux. Fornecem dados para Endpoint Queries. Não possuem um período de retenção fixo; este depende da plataforma, da atividade e do armazenamento configurado.

Em Global Settings > Products and Services > Endpoint and Server > Event Journals, define-se entre 300 e 30'000 MB. O padrão é 5'250 MB. Também pode limitar-se a percentagem do disco; se ambos se aplicarem, a Sophos usa o valor inferior.

A configuração central destes limites está disponível apenas com uma licença XDR, MDR ou MDR Plus. Os Event Journals locais continuam a existir em dispositivos Windows, macOS e Linux protegidos, mas sem a licença adequada os seus limites não podem ser ajustados em todo o tenant.

A definição aplica-se a todos os dispositivos abrangidos e não pode variar por dispositivo. Reduzi-la pode descartar dados existentes dos diários e encurtar o período de investigação.

Retenção e limites de armazenamento

XDR guarda dados do Data Lake até 90 dias e EDR até 30. O pacote opcional Central Data Storage – 1 yr amplia o período para um ano. É um máximo; quando a capacidade de armazenamento se esgota, os dados antigos são removidos mais cedo.

Cada dispositivo pode enviar no máximo 2 GB por dia. Ao atingir o limite, o envio é interrompido até à reposição. No Windows, o limite é reposto à meia-noite, hora local; no Linux, a cada 24 horas após o arranque do agente XDR. Os dados não enviados não são carregados mais tarde, mas continuam disponíveis para uma consulta direta ao endpoint.

A capacidade atribuída aos endpoints corresponde, em média, a 20 MB por licença e dia. Um excesso permanente reduz o histórico efetivamente disponível; um tenant com 90 dias formais pode conter menos dados consultáveis.

Encontrar a causa de um limite diário de envio

O evento Data Lake uploads stopped because the daily limit reached aparece em endpoints Windows e servidores Windows ou Linux. As Hydration Queries agendadas do dispositivo produzem estes envios. XDR e MDR têm um limite diário de 2 GB por dispositivo. Depois de atingido, não são enviados mais dados de Hydration Query até ao dia seguinte; o limite é reposto e as Queries retomam até ao fim do dia ou até novo alcance do limite.

Para encontrar a Hydration Query com o maior volume de upload, inicie sessão no Sophos Fusion (anteriormente Sophos Central) e abra Threat Analysis Center > Live Discover. Ativar Designer Mode, escolher Create a new query, dar um nome e selecionar Data Lake como Source. Em Show variable editor, atribuir nomes descritivos e adicionar os tipos Device Name e Date. Introduzir dispositivo e data YYYY-MM-DD, e executar:

SELECT
  query_name,
  sum(upload_size) / (1000.0 * 1000) AS total_upload_size_bytes_mb
FROM xdr_data
WHERE date_trunc('day', ingestion_timestamp) = date (from_unixtime($$date$$))
  AND meta_hostname = '$$hostname$$'
GROUP BY query_name, date_trunc('day', ingestion_timestamp)
ORDER BY total_upload_size_bytes_mb DESC

Em alternativa, esta Query sem variáveis ordena todos os dispositivos e Queries por dia; substituir a data de exemplo:

SELECT
  query_name,
  meta_hostname,
  date_trunc('day', ingestion_timestamp) AS date,
  sum(upload_size) / (1000.0 * 1000) AS total_upload_size_bytes_mb
FROM xdr_data
WHERE date_trunc('day', ingestion_timestamp) >= date '2021-09-17'
GROUP BY query_name, meta_hostname, date_trunc('day', ingestion_timestamp)
ORDER BY total_upload_size_bytes_mb DESC

O maior resultado identifica a Hydration Query a investigar, não identifica automaticamente um processo que deva ser bloqueado. Verificar no Sophos Data Lake Schema Viewer atual as colunas preenchidas e agrupar por uma coluna útil. Se running_processes_windows_sophos for a maior, separar por caminho:

SELECT
  path,
  sum(upload_size) / (1000.0 * 1000) AS total_upload_size_bytes_mb
FROM xdr_data
WHERE date_trunc('day', ingestion_timestamp) = date '$$date$$'
  AND meta_hostname = '$$hostname$$'
  AND query_name = 'running_processes_windows_sophos'
GROUP BY path, date_trunc('day', ingestion_timestamp)
ORDER BY total_upload_size_bytes_mb DESC

No exemplo Sophos, essa Query gerou cerca de 72 MB e o caminho de um processo iniciado foi responsável por mais de 50 por cento do envio diário; os nomes reais dos processos foram ocultados por serem específicos do ambiente. Adicionar restrições ou analisar Command Line, User Name ou Parent Process para encontrar uma correção que reduza o volume. Investigar a causa, a legitimidade e uma possível configuração incorreta antes de alterar ou bloquear.

Guardrails

A Sophos limita Queries para proteger Endpoints e tenant:

  • UI: no máximo 15 Queries por minuto;
  • Consultas agendadas e consultas por API, em conjunto: 1'000 por dia e 10 por minuto;
  • Watchdog: interrupção acima de 30% CPU durante 12 segundos ou 256 MB RAM;
  • no máximo 10 MB de resposta por dispositivo e Query;
  • no máximo 1 MB por linha;
  • no máximo 100'000 linhas de todos os dispositivos.

Um resultado vazio também pode resultar de um tamanho de linha excessivo. Telemetry sob o resultado mostra o estado, o System Impact e o volume de dados por dispositivo.

Delimitar sistematicamente Query cancelled

Query cancelled não é um erro específico de HAFNIUM. No Windows, Memory Watchdog pode terminar uma Live Query. Em SophosLiveQueryService.log identificam-se primeiro o nome da consulta e o erro de recursos efetivo, reduz-se o período, por exemplo de 15 para 7 dias, e testa-se num dispositivo. Persistindo, reduz-se mais ou filtra-se melhor a Query.

Após Downgrade do Sophos Core Agent 2025.2 para versão LTS ou FTS anterior, SophosOsquery.exe pode não iniciar por alteração de File Attestation. O log contém Exception whilst running LiveQueryRunner. Neste caso específico reinicia-se o dispositivo; reescrever a Query não resolve o limite da versão.

Na vista Classic em Threat Analysis Center > AI Search, AI Search gera consultas Data Lake a partir de linguagem natural. As Detections e os dados de endpoints Windows podem ser pesquisados sem escrever sintaxe SQL. A tabela mostra no máximo 1'000 resultados. Não se devem extrapolar estes limites de plataforma e resultados para a nova Data Lake Search descrita acima.

A pesquisa começa com poucas horas ou um dia. Grandes períodos podem ser lentos ou interrompidos. O SQL gerado é verificado antes de o resultado ser considerado completo.

Categorias próprias e Queries agendadas

As Queries reutilizáveis são organizadas em categorias personalizadas com nomes claros. A documentação da Query inclui descrição, sistemas suportados, origem de dados, variáveis e resultado esperado. Uma Query copiada não é considerada fiável apenas porque o SQL é sintaticamente válido. A Sophos está a disponibilizar gradualmente as categorias personalizadas, pelo que a função pode ainda não estar visível em todos os tenants.

As Queries agendadas são adequadas a hipóteses e controlos recorrentes e só estão disponíveis para Queries do Data Lake. A frequência, o dia, a data de fim e o período consultado são definidos conscientemente. Cada administrador pode ter no máximo 100 Queries ou relatórios deste formato ativamente agendados. Queries demasiado amplas ou frequentes também podem atingir os limites gerais e produzir muita telemetria com dados pessoais.

Operação e privacidade

A telemetria do Data Lake e o Live Discover podem conter nomes de processos, linhas de comandos, utilizadores, hashes de ficheiros, endereços IP e outros dados operacionais. Por isso, são documentados os papéis, a finalidade, a retenção e a exportação.

As categorias de consultas organizam as Queries frequentes. Eliminar uma categoria personalizada não elimina as Queries; estas continuam em All Queries ou noutras categorias.

Artigos relacionados

Isolation e Live Response: Isolar Sophos Endpoint e usar Live Response. Sophos Endpoint XDR: Investigation e Threat Graph descreve a avaliação posterior de Detections e Threat Graphs.

Perguntas frequentes

Qual é a diferença entre Live Endpoint e Data Lake?

Live Endpoint consulta dispositivos online selecionados. Data Lake pesquisa telemetria histórica previamente enviada por todos os dispositivos.

Os dados XDR estão sempre disponíveis durante 90 dias?

90 dias é o máximo. Se o Pool dependente da licença for excedido, a Sophos remove dados antigos mais cedo.

Para a interface Security Operations atual, Data Lake Search e exportação explica esquemas, janelas de eventos de 31 dias, limite Raw separado e exportações atuais. Os limites Classic conservados acima não são transferidos para esta interface.