Examinar los datos locales de la NDR en la consola de investigación

NDR Investigation Console proporciona datos locales de los sensores NDR asignados, no solo los datos transferidos a Sophos Data Lake. Este runbook parte de una hipótesis en Dashboard > Overview y conduce a una consulta ClickHouse específica en Query. Todas las consultas descritas aquí son de solo lectura.

Investigation Console no sustituye a las siguientes rutas de consulta:

Un resultado de Investigation Console no confirma por sí solo un incidente. Escale los hallazgos sospechosos mediante el proceso SOC, XDR o MDR aplicable. Las acciones de respuesta no forman parte de este runbook.

Acceso, funciones y mandato de investigación

Utilice una cuenta personal con los permisos necesarios para la investigación. La cuenta local de Investigation Console es independiente de los roles de Sophos Fusion. Si falta Query, un esquema necesario o algún botón, pida al administrador responsable que compruebe la cuenta local y la consola seleccionada. Si falta el punto de entrada de Sophos Fusion o una opción posterior para pivotar a la nube, compruebe por separado la licencia, el rol de Fusion y el ámbito de producto de cualquier rol personalizado. No amplíe un rol de forma especulativa.

Establecer lo siguiente antes de la investigación:

• una hipótesis concreta, por ejemplo, comunicación con un IP objetivo aprobado sobre protocolos inesperados;
• los sensores o el área de la red afectados y los sistemas de fuente o de destino previstos;
• el inicio, el final y la zona horaria del evento;
• un billete o un caso para las notas y la persona que se apoderará de un hallazgo sospechoso;
• permite el manejo de direcciones IP, nombres de host y resultados exportados.

La consola debe estar accesible y recibir datos de al menos un NDR Integration Appliance. El acceso correcto por sí solo no demuestra que los datos del sensor estén actualizados ni que la cobertura de replicación sea completa.

1. Limite el período de tiempo y los sensores afectados en el panel de control

Después de iniciar sesión, la consola abre Dashboard > Overview. La página muestra Total Indicators, Network Traffic, Total Indicators By Severity, Total Indicators By Type, Geolocation Map y Recent flow detections. Back vuelve a Sophos Fusion. This Appliance muestra detalles del sistema y no es necesario para esta investigación.

1. Bajo Filters, abra Time Range primero. El estándar es Last 1 hour.
2. Para un incidente conocido, seleccione Absolute time range e introduzca el inicio y el final con contexto suficiente antes y después del evento. Para una primera visión general puede bastar un quick range como Last 7 days. Confirme con Apply time range.
3. Tenga en cuenta el límite de datos: la consola solo ofrece los últimos 30 días. Un intervalo más amplio no aporta datos locales anteriores. Por tanto, la ausencia de una coincidencia más antigua no constituye una confirmación negativa.
4. Bajo Filters, seleccione una columna de base de datos disponible, el operador apropiado y un valor. Sophos da MasterProtocol, Equals y HTTP como ejemplo. Las columnas numéricas ofrecen operadores como =, <, o >=.
5. Agregue sólo criterios que pertenecen a la hipótesis. Después de cada criterio configurado, haga clic en Add primero para incluirlo en el filtro, y luego Apply. Compruebe que las tablas y tabla ahora reflejan el período de tiempo seleccionado y los filtros.
6. Utilice Save As sólo para un filtro estable y comprensiblemente llamado. El icono de ahorro sobrescribe un filtro existente. Con Clear se elimina la configuración de filtro actual.

Grabar los filtros y el periodo de tiempo y la zona horaria. Luego compare al menos dos presentaciones independientes:

• Total Indicators muestra IoCs de tipos DGA, IDS, EPA y SRA. Hacer clic en un tipo lo mueve en el gráfico de la barra. Pasar por encima de una barra muestra el tiempo y el valor.
• Network Traffic muestra la tasa de datos en Mbit/s, paquetes por segundo y flujos por segundo. Si se mueve el cursor sobre el gráfico, verá el volumen de datos enviados y recibidos en gigabytes.
• Total Indicators By Severity está agrupado por Critical, High, Medium, Low y Info. Total Indicators By Type muestra los mismos tipos de IoC como un diagrama de donut.
• Geolocation Map está basado en agrupaciones IP. Una región proporciona un punto de partida para la investigación, pero no prueba la ubicación real de un anfitrión ni que es malicioso.
• Recent flow detections muestra flujos de red sospechosos. Compruebe los detalles de flujo existentes y confirme los nombres de campo y significados contra el esquema actual en lugar de simplemente adoptar una punta de gráfico.

Si el panel y la tabla no coinciden para el mismo periodo, reduzca la franja horaria y compruebe los filtros activos. Solo entonces debe iniciar una consulta personalizada.

2. Comience con una consulta preparada

Abra Query y permanezca en la pestaña Library primero. Para este runbook, use sólo consultas individuales, sólo lectura SELECT. Para consultas personalizadas o propias, se requiere conocimiento de ClickHouse SQL. Quedan excluidos los comandos que cambian datos, tablas, esquemas, usuarios, permisos o configuración del servidor.

Comience con una consulta preconfigurada que se ajuste a su hipótesis:

1. En Library, abra la categoría adecuada y abra la consulta.
2. Lee el texto completo. Verifique tablas, campos, condiciones de tiempo, agrupación, clasificación y un límite de resultados existente basado en su hipótesis.
3. Cambia a Schema. Despliega el nombre del esquema y confirma los nombres de campo y los tipos de campo para cada tabla utilizada. No tome nombres de campo de los ejemplos de Data Lake o Appliance Manager.
4. Basado en el esquema actual, limite el SELECT al período de tiempo requerido y, si es posible, un solo indicador, host, fuente o destino IP o protocolo. Cambiar una condición de tiempo preconfigurada sólo si campo y sintaxis ClickHouse son únicos.
5. Haga clic una vez en Run. Los resultados aparecen debajo de la consulta. El clic repetido no acelera la ejecución y hace difícil asignar a History.
6. Extender el alcance sólo cuando la primera ejecución sea exitosa y el resultado es plausible y manejable.

Use variables y ejemplos de manera segura

Si una consulta preparada contiene una variable como @DestIp, aparece un campo de entrada a la izquierda. Protocols For Destination IP es un ejemplo documentado. Utilice este campo y no cambie simultáneamente la lógica de sustitución variable, tabla y filtro.

Para una verificación de sincronización o flujo de trabajo, use sólo una dirección aprobada para ese propósito. 192.0.2.10 viene de una red reservada para documentación y se utiliza aquí sólo como un ejemplo de formato. No necesariamente devolverá los resultados y no es un indicador de producción. Las direcciones IP reales, dominios y nombres de host deben provenir del ticket autorizado, no de ejemplos arbitrarios.

Al guardar, la consola puede transferir el valor variable al texto de consulta. @DestIp se convierte, por ejemplo, en la dirección utilizada. Revisa el texto antes de la siguiente ejecución. Guardar una variante personalizada sobre Save As bajo un nombre que describe el propósito y el alcance, y no sobreescribir la consulta inicial preconfigurada. Debido a que las consultas almacenadas pueden contener indicadores confidenciales, se aplica la clasificación de datos locales.

Para crear su propia categoría, haga clic en el icono Plus en la parte superior derecha de Library, escriba el nombre y la descripción y confirme con Create. Para una nueva consulta, introduzca el texto SELECT probado a la derecha, pruebe con Run y seleccione Save As. Seleccione la categoría, escriba un nombre y confirme con Create. Guardar sólo reutilizables, pruebas de consultas.

La consola comparte recursos con almacenamiento y visualización de datos locales. Por lo tanto, filtrar temprano por tiempo y un campo selectivo. Limite los resultados usando un método ya utilizado en Library y probado para ClickHouse; no retire ningún límite existente en la primera prueba. Antes de JOIN, sub-queries, agrupaciones amplias o clasificaciones, compruebe el Schema actual y prueba con una pequeña ventana de tiempo. No copie una consulta Data Lake SQL a la consola. Lea las consultas de entradas, chats o ejemplos públicos antes de ser ejecutados y compáralos con Schema.

3. Resultados validados

Una consulta ejecutada correctamente no es automáticamente correcta en el contenido. Compruebe el resultado en este orden:

1. Ámbito de la investigación: ¿La ventana de tiempo, la zona horaria, los sensores afectados y los filtros coinciden con la asignación exactamente? ¿Está disponible el evento dentro de los 30 días localmente?
2. Esquema: ¿Qué tipos de campo y significado coinciden con Schema? En particular, compruebe si las direcciones IP, los valores de tiempo y los números se interpretan correctamente.
3. Control match: Buscar un flujo conocido y esperado en el mismo período de tiempo estrecho. Si eso también está ausente, un resultado vacío no es confiable.
4. Comparación con el dashboard: ¿El orden de magnitud y cronología coincide con Network Traffic, IoCs o Recent flow detections? Los agregados de tablero de instrumentos y las filas individuales no necesitan ser idénticos, pero las contradicciones requieren una explicación.
5. Cross-check: Quitar exactamente un filtro estrecho o cambiar la ventana del tiempo de una manera controlada. Una diferencia plausible muestra que la condición está funcionando. Nunca cambies varias condiciones a la vez.
6. Documentación: Recordar el nombre de consulta o texto, variables, periodo de tiempo con zona horaria, tiempo de ejecución, cuenta de resultados y filas relevantes en el ticket. Tratar los resultados como datos de red potencialmente sensibles.

Entonces abre History. Allí, la consola muestra el tipo de usuario, fecha y hora, el número de resultados, y successful o failed. Asignar la entrada de su ejecución. History demuestra la ejecución, pero ni la integridad ni corrección de la consulta.

Limite los errores y regrese de forma segura

El tablero está vacío

Compruebe Time Range, Saved Filters activo y Filters. Seleccione un breve período de tráfico de red esperado y retire los filtros con Clear. Si Network Traffic también permanece vacío, el problema no se debe a una consulta gratuita. Compruebe si la consola correcta está abierta y si el sensor esperado o el dispositivo pertinente proporciona datos. Un estado de aplicabilidad verde no prueba la cobertura completa del espejo. Tiempo de transferencia, flujo esperado, consola y sensor afectado al proceso de operación o soporte, en lugar de prolongar el período de tiempo durante 30 días.

La consulta devuelve cero filas

Confirme el período de tiempo y la zona horaria. En Schema, compruebe si la tabla, el nombre y el tipo de campo son actuales. Luego, retírese el filtro técnico más estrecho y vuelva a ejecutar la consulta. También, prueba un valor esperado conocido en la misma ventana del tiempo. Si una consulta preconfigurada no cambia no proporciona datos esperados, compruebe la ruta de datos y los sensores afectados. El resultado vacío no prueba que la actividad se esté perdiendo.

Query es failed

Encuentre la entrada adecuada en History y estado de documento, consulta texto y tiempo de ejecución en sus notas de trabajo. Compruebe la sintaxis, nombres de campo y tipos de campo utilizando Schema. Abra la última consulta sin cambios, que funcionaba previamente desde Library, limite su SELECT al período de tiempo más pequeño y configura sólo un valor variable validado. Comienza una nueva ejecución. Si la consulta preconfigurada todavía muestra failed, documenta el error y lo escala. No lo desvíes con comandos de escritura, cambios de esquema o configuración del servidor.

La consulta se ejecuta inusualmente larga o carga la consola

No haga clic en Run de nuevo. Recordar el tiempo de inicio, usuario y el nombre de la consulta. No empieces otra consulta. Después de la finalización, consulte History si la ejecución fue successful o failed y cuántos resultados se obtuvieron. Si la interfaz sigue siendo lenta, termine el trabajo de consulta y pase la observación a la operación de la consola. Un reinicio o cierre no es parte de este runbook.

Regresar a una consulta en funcionamiento

1. Deja de correr la misma variante. No lanzar registros rápidos ni otra consulta de control amplio.
2. Si la interfaz es sensible, copiar el texto de consulta y el tiempo de inicio de documentos, filtros, variables y la entrada History asociada. No guarde la variante defectuosa como una nueva consulta estándar.
3. Abra la consulta preconfigurada original de nuevo desde Library. Compruebe que no se han adoptado valores variables insertados o cambios no almacenados.
4. Limite el SELECT a un corto período de tiempo, un valor validado y un pequeño conjunto de resultados basado en el esquema confirmado. Verifique tablas y campos de nuevo bajo Schema.
5. Realice una prueba de lectura de un solo, ya ejecutada con éxito. Compruebe los resultados y History.
6. Si este examen también falla o la consola sigue siendo afectada, ponga fin a la investigación y se intensifique con la información asegurada. No utilice los comandos de reparación, eliminación o desgarro de bases de datos.

Cierra y deja de lado

Finalmente, documente la hipótesis, la consola utilizada, los sensores afectados, la ventana de tiempo con zona horaria, los filtros de panel, la consulta ejecutada, variables, estado History y número de resultados. Desactivar los resultados positivos a través del proceso SOC, XDR o MDR existente. Un resultado negativo significa que nada se encontró dentro del ámbito de investigación local documentado. No prueba que la actividad esté ausente de toda la red.

Eliminar los valores de muestra sensibles de una definición de consulta que sólo es necesaria temporalmente o aclarar su retención permitida con la persona responsable de Library.

Preguntas frecuentes