Investigar dados NDR locais na Investigation Console

A NDR Investigation Console disponibiliza os dados locais dos sensores NDR atribuídos, e não apenas os dados transferidos para o Sophos Data Lake. Este runbook parte de uma hipótese em Dashboard > Overview e conduz a uma consulta ClickHouse delimitada em Query. Todas as consultas descritas são exclusivamente de leitura.

A Investigation Console não é intercambiável com estes outros caminhos de consulta:

Um resultado da Investigation Console ainda não é um incidente confirmado. Transmita descobertas suspeitas de acordo com o processo SOC, XDR ou MDR aplicável. Medidas de resposta não fazem parte deste runbook.

Acesso, funções e âmbito da investigação

Use uma conta pessoal com os permissões necessárias para a tarefa. A conta local do Investigation Console está separada das funções no Sophos Fusion. Se estiver faltando Query, um esquema necessário ou um botão, faça o administrador responsável verificar a conta local e o consola escolhido. Se já faltar a entrada do Sophos Fusion ou uma mudança posterior para a cloud, verifique separadamente a licença, o função do Fusion e, no caso de Funções Personalizadas, o âmbito do produto. Não expanda nenhum função por suposição.

Antes da investigação, estes pontos devem estar definidos:

• hipótese concreta, por exemplo, a comunicação de um IP alvo autorizado por protocolos inesperados;
• sensor ou área de rede afetada e sistemas de origem ou destino esperados;
• Início, fim e fuso horário do evento;
• Ticket ou caso para anotações e a pessoa que assume um achado suspeito;
• uso permitido de endereços IP, nomes de host e resultados exportados.

O consola deve ser acessível e receber dados de pelo menos um Appliance de Integração NDR. Um autenticação sozinho não comprova dados de sensor atuais nem uma cobertura completa de espelhamento.

1. Delimitar o período e os sensores afetados no dashboard

Após o autenticação, o consola Dashboard > Overview abre. A página mostra Total Indicators, Network Traffic, Total Indicators By Severity, Total Indicators By Type, Geolocation Map e Recent flow detections. Back leva de volta ao Sophos Fusion. This Appliance mostra detalhes do sistema e não é necessário para esta investigação.

1. Abra primeiro Time Range em Filters. O padrão é Last 1 hour.
2. Escolha um incidente conhecido Absolute time range e registre o início e o fim com contexto suficiente antes e depois do evento. Para uma visão geral inicial, um quick range como Last 7 days pode ser suficiente. Confirme com Apply time range.
3. Observe o limite de dados: o consola fornece apenas os últimos 30 dias. Um período mais longo não fornece dados locais adicionais. Uma ausência de registo mais antigo, portanto, não é uma confirmação negativa.
4. Selecione sob Filters uma coluna de base de dados oferecida, o operador apropriado e um valor. A Sophos, por exemplo, menciona MasterProtocol, Equals e HTTP. Para colunas numéricas, estão disponíveis operadores como =, < ou >=.
5. Adicione apenas critérios que pertençam à hipótese. Após configurar cada critério, clique primeiro em Add para adicioná-lo ao filtro e depois em Apply. Verifique se os gráficos e a tabela agora refletem o período selecionado e os filtros.
6. Use Save As apenas para um filtro estável, com nome compreensível. O ícone de guardar sobrescreve um filtro existente. Com Clear você remove as configurações de filtro atuais.

Anote os filtros, assim como o período e o fuso horário. Depois, compare pelo menos duas representações independentes:

• Total Indicators mostra IoCs dos tipos DGA, IDS, EPA e SRA. Um clique em um tipo o exibe ou oculta no gráfico de barras. Quando você passa o cursor do mouse sobre uma barra, aparecem a hora e o valor.
• Network Traffic mostra a taxa de dados em Mbit/s, pacotes por segundo e fluxos por segundo. Quando você move o cursor sobre o gráfico, verá o volume de dados enviados e recebidos em gigabytes.
• Total Indicators By Severity agrupado por Critical, High, Medium, Low e Info. Total Indicators By Type mostra os mesmos tipos de IoC como um gráfico de rosca.
• Geolocation Map baseia-se em agrupamentos de IP. Uma região fornece um ponto de partida para investigação, mas não comprova nem a localização real nem a maliciosidade de um host.
• Recent flow detections mostra fluxos de rede suspeitos. Verifique os detalhes dos fluxos existentes e confirme os nomes e significados dos campos de acordo com o esquema atual, em vez de apenas seguir um ponto do diagrama.

Se o dashboard e a tabela não corresponderem ao mesmo período, reduza o intervalo de tempo e verifique os filtros ativos. Só então inicie uma consulta livre.

2. Começar com uma consulta preparada

Abra Query e permaneça inicialmente no separador Library. Neste runbook, utilize exclusivamente consultas SELECT individuais e só de leitura. As consultas adaptadas ou próprias exigem conhecimentos de ClickHouse SQL. Excluem-se comandos que alterem dados, tabelas, schemas, utilizadores, permissões ou definições do servidor.

Comece com uma consulta pré-configurada que corresponda à sua hipótese:

1. Expanda a categoria apropriada em Library e abra a consulta.
2. Leia o texto completo. Verifique tabelas, campos, condições de tempo, agrupamento, ordenação e um limite de resultados existente com base na sua hipótese.
3. Mude para Schema. Expanda o nome do esquema e confirme para cada tabela utilizada os nomes dos campos e os tipos de campos. Não assuma nomes de campos dos exemplos do Data Lake ou do Appliance Manager.
4. Limite o SELECT com base no esquema atual ao período necessário e, se possível, a um único indicador, host, um IP de origem ou destino ou a um protocolo. Altere uma condição de tempo pré-configurada apenas se o campo e a sintaxe do ClickHouse forem claros.
5. Clique uma vez em Run. Os resultados aparecem por baixo da consulta. Clicar repetidamente não acelera a execução e dificulta a associação em History.
6. Expanda o âmbito da investigação apenas quando a primeira execução for bem-sucedida e o resultado for plausível e manejável.

Usar variáveis e exemplos com segurança

Se uma consulta preparada contiver uma variável como @DestIp, um campo de entrada aparecerá à esquerda. Protocols For Destination IP é um exemplo documentado. Use este campo e não altere ao mesmo tempo a substituição da variável, a tabela e a lógica de filtro.

Use apenas um endereço autorizado para isso para uma verificação de sintaxe ou de fluxo. 192.0.2.10 vem de uma rede reservada para documentação e serve aqui exclusivamente como exemplo de formato. O endereço não fornece necessariamente resultados e não é um indicador produtivo. Endereços IP reais, domínios e nomes de host vêm do ticket autorizado, não de exemplos quaisquer.

Ao guardar, o consola pode incorporar o valor da variável no texto da consulta. Por exemplo, de @DestIp surgirá o endereço inserido. Por isso, verifique o texto antes da próxima execução. Guarde uma variante ajustada via Save As sob um nome que descreva o propósito e o âmbito, e não sobrescreva a consulta inicial pré-configurada. Como consultas salvas podem conter indicadores confidenciais, aplica-se a classificação local de dados.

Para criar uma categoria própria, clique no símbolo de mais no canto superior direito do Library, insira o nome e a descrição e confirme com Create. Para uma nova consulta, insira o texto SELECT verificado à direita, teste-o com Run e selecione Save As. Escolha a categoria, insira um nome e confirme com Create. Guarde apenas consultas verificadas e reutilizáveis.

O consola compartilha recursos com o armazenamento e a exibição de dados locais. Filtre cedo por tempo e por um campo seletivo. Limite os resultados de acordo com um método já usado em Library e testado para ClickHouse; não remova nenhum limite existente no primeiro teste. Antes de JOIN, subconsultas, agrupamentos amplos ou ordenações, verifique o Schema atual e teste com uma janela de tempo pequena. Não copie nenhuma consulta SQL do Data Lake para o consola. Leia completamente as consultas de tickets, chats ou exemplos públicos antes de executá-las e compare-as com Schema.

3. Validar resultados

Uma consulta executada com sucesso não é automaticamente correta em termos de conteúdo. Verifique o resultado nesta ordem:

1. Âmbito da investigação: A janela temporal, o fuso horário, os sensores afetados e os filtros correspondem exatamente à tarefa? O evento está dentro dos 30 dias disponíveis localmente?
2. Schema: Os tipos de campo e significados correspondem aos de Schema? Verifique especialmente se endereços IP, valores de tempo e quantidades estão sendo interpretados corretamente.
3. Ocorrência de controlo: Procure um fluxo conhecido e esperado no mesmo período delimitado. Se este também estiver ausente, um resultado vazio não é conclusivo.
4. Comparação com o dashboard: A ordem de grandeza e a evolução temporal correspondem a Network Traffic, aos IoCs ou a Recent flow detections? Os agregados do dashboard e as linhas individuais não têm de ser idênticos, mas as contradições exigem uma explicação.
5. Contraprova: Remova exatamente um filtro restritivo ou desloque a janela temporal de forma controlada. Uma diferença plausível demonstra que a condição está a funcionar. Nunca altere várias condições ao mesmo tempo.
6. Documentação: Registe no ticket o nome ou texto da consulta, as variáveis, o período com fuso horário, a hora de execução, o número de resultados e as linhas relevantes. Trate os resultados como dados de rede potencialmente sensíveis.

Em seguida, abra History. Lá, o consola mostra o tipo de utilizador, data e hora, a quantidade de resultados, bem como successful ou failed. Associe a entrada à sua execução. History confirma a execução, mas não a completude nem a correção da consulta.

Delimitar o erro e retornar com segurança

Dashboard está vazio

Verifique Time Range, ativos Saved Filters e Filters. Escolha um curto período com tráfego de rede esperado e remova os filtros com Clear. Se Network Traffic também estiver vazio, o problema não é uma consulta disponível. Verifique se o consola correto está aberto e se o sensor esperado ou o appliance responsável está fornecendo dados. Um estado de appliance verde não prova cobertura completa do espelho. Transfira o período, o fluxo esperado, o consola e o sensor afetado para o processo operacional ou de suporte, em vez de estender o período para mais de 30 dias.

A consulta retorna linhas nulas

Confirme o período e o fuso horário. Verifique em Schema se a tabela, o nome do campo e o tipo estão atualizados. Em seguida, remova exatamente o filtro técnico mais restrito e execute a consulta novamente uma vez. Teste também um valor esperado conhecido na mesma janela de tempo. Se uma consulta pré-configurada não modificada também não fornecer os dados esperados, verifique o caminho dos dados e os sensores afetados. O resultado vazio não prova que a atividade está ausente.

A consulta é failed

Procure a entrada correspondente em History e documente o estado, o texto da consulta e a hora de execução nas suas notas de trabalho. Verifique a sintaxe, os nomes dos campos e os tipos de campo com base em Schema. Abra a última consulta inalterada que funcionava anteriormente em Library, limite seu SELECT para o menor período significativo e defina apenas um valor de variável validado. Inicie exatamente uma nova execução. Se a consulta pré-configurada failed permanecer, documente o erro e o escale. Não o contorne com comandos de escrita, alterações de esquema ou configurações do servidor.

A consulta está demorando incomumente ou sobrecarregando o consola

Não clique novamente em Run. Registe a hora de início, o utilizador e o nome da consulta. Não inicie outra consulta abrangente. Após a conclusão, verifique em History se a execução foi successful ou failed e quantos resultados foram gerados. Se a interface continuar lenta, termine o trabalho de consulta e encaminhe a observação para a equipa que opera a consola. Um reinício ou encerramento não faz parte deste runbook.

Retornar a uma consulta funcionando

1. Pare com outras execuções da mesma variante. Não inicie repetições apressadas nem outra verificação ampla de controle.
2. Copie, se a interface reagir, o texto da consulta e documente a hora de início, filtros, variáveis e o registo History correspondente. Não guarde a variante com erro como nova consulta padrão.
3. Abra novamente a consulta pré-configurada original de Library. Verifique se nenhum valor de variável aplicado ou alteração não salva foi incorporado.
4. Limite o SELECT com base no esquema confirmado para um curto período, um valor validado e uma pequena quantidade de resultados. Verifique tabelas e campos novamente sob Schema.
5. Realize um único teste de leitura já executado com sucesso. Verifique o resultado e History.
6. Se este teste também falhar ou o consola continuar comprometido, encerre a investigação e escale com as informações recolhidas. Não use comandos de reparo, eliminação ou desmontagem do base de dados.

Conclusão e Entrega

Documente ao final a hipótese, o consola utilizado, os sensores afetados, a janela de tempo com fuso horário, os filtros do dashboard, a consulta executada, variáveis, o estado History e o quantidade de resultados. Transmita achados positivos sobre o processo SOC, XDR ou MDR existente. Um resultado negativo significa apenas que nada foi encontrado no âmbito de investigação local documentado. Isso não prova que a atividade está ausente em toda a rede.

Remova valores de exemplo sensíveis de uma definição de consulta necessária apenas temporariamente ou esclareça o armazenamento permitido com a pessoa responsável pelo Library.

Perguntas Frequentes