Entender Sophos Next-Gen SIEM y planificar la retención

Sophos Next-Gen SIEM es un complemento opcional para Sophos XDR Powered by Secureworks y Sophos MDR. Antes de utilizarlo, la cuenta debe haberse actualizado a Sophos Fusion. La documentación técnica de administración describe 13 meses de conservación de datos como estándar y la posibilidad de ampliarlos hasta 10 años. Se añaden telemetría de amenazas y de cumplimiento, e integraciones personalizadas adicionales a las integraciones preconfiguradas de XDR/MDR. Esta valoración tiene fecha de revisión del 28 de octubre de 2026; más abajo se explica, para la contratación, la indicación diferente de un año en la página del producto.

Para tomar la decisión, conviene registrar primero las fuentes de datos y los plazos de conservación necesarios. Después se solicita la confirmación del alcance concreto del complemento para el tenant y se comprueba, con una pequeña fuente piloto, si los eventos previstos se ingieren realmente y pueden encontrarse de nuevo. Disponer de una licencia de XDR o MDR no demuestra por sí solo que el complemento opcional esté habilitado.

Cuándo encaja Next-Gen SIEM con la tarea

SIEM significa Security Information and Event Management: los datos de eventos se recopilan de forma centralizada y se ponen a disposición para su análisis. Next-Gen SIEM amplía la arquitectura de datos compartida de XDR/MDR para ofrecer una conservación más prolongada y análisis de cumplimiento. Merece la pena evaluarlo especialmente cuando se necesitan eventos históricos de periodos más largos o se quiere incorporar una fuente mediante una integración propia.

Si la primera tarea es configurar una integración de producto existente, se empieza por integraciones de MDR y XDR en Sophos Fusion. Ese artículo explica su flujo de datos y las comprobaciones operativas. La conexión de Sophos Firewall a syslog trata el transporte de los registros del firewall a un receptor. No determina qué alcance de Next-Gen SIEM se ha contratado o activado para una fuente.

Sophos XDR sigue siendo la plataforma principal para la detección, la investigación, la respuesta y la automatización. Next-Gen SIEM amplía estos flujos de trabajo con recopilación de datos orientada al cumplimiento, evidencias históricas y una conservación más prolongada. Por tanto, el complemento SIEM no es un requisito general para las funciones de detección o respuesta de XDR que ya estén licenciadas; a su vez, XDR por sí solo no habilita los servicios adicionales de SIEM.

Avanet recomienda no elegir el complemento únicamente por disponer de la mayor retención posible. Aquí, retención significa conservación de datos. Lo decisivo es qué eventos se necesitarán después, para responder a qué preguntas, quién los analizará y durante cuánto tiempo deberán estar disponibles. Almacenarlos más tiempo sirve de poco si no se entrega la categoría de eventos necesaria o faltan campos importantes.

Sophos también describe paneles de cumplimiento preconfigurados. Estos análisis ayudan a reunir evidencias, pero no sustituyen la comprobación de la cobertura de datos, una valoración jurídica ni una certificación. El complemento no implica que el cumplimiento se alcance automáticamente.

Aclarar el tenant y la oferta antes de la implantación

Antes de la compra, se documentan el tenant correcto, el producto XDR/MDR utilizado y el estado real de la actualización a Fusion. Un anuncio o una fecha prevista de actualización no bastan para autorizar su uso operativo. A continuación, se solicita al partner de Sophos que confirme si Next-Gen SIEM está disponible para esa cuenta y qué conservación y servicios de integración incluye la oferta concreta.

Sophos describe un modelo de precios basado en usuarios y servidores, sin cargos de ingesta, es decir, sin una tarifa por el volumen de datos incorporado. Es una descripción del modelo de precios, no una oferta económica ni una promesa de capacidad técnica ilimitada. Antes de realizar el pedido, deben aclararse el método de cómputo, la duración del contrato, la ampliación de retención deseada, el alcance de las integraciones y los posibles requisitos del producto de terceros. En particular, esta descripción no permite deducir licencias gratuitas de terceros ni límites garantizados de rendimiento o eventos.

Para las integraciones personalizadas está confirmada la posibilidad de crear integraciones de datos propias. Esto no acredita todavía un procedimiento de configuración para cualquier fuente. Por ello, antes del piloto se necesita una descripción adecuada para la fuente concreta de la transmisión, la autenticación, el formato de los eventos, la asignación de campos y el análisis admitido. Los menús o consultas de conectores existentes no deben trasladarse a una integración personalizada sin verificarlos. La ruta de acceso al dashboard se describe más adelante; no se deduce de ella un procedimiento universal de configuración para cualquier fuente personalizada.

Confirmar expresamente la cantidad de licencias y la ruta del Collector

Next-Gen SIEM no puede comprarse como producto independiente. Su número de suscripciones debe corresponder al número total de usuarios y servidores con licencia XDR y MDR; los servidores no deben omitirse en el cómputo. Coteje el inventario concreto y la oferta con el partner, en lugar de utilizar únicamente un grupo piloto o el volumen de datos como cantidad de licencias. Además de los 13 meses estándar, las ampliaciones de retención a tres, cinco, siete o 10 años son opciones que pueden comprarse, no una habilitación automática por disponer de una licencia XDR/MDR. No recuperan retroactivamente el historial cuyo plazo de conservación haya vencido ni acreditan el cumplimiento legal.

Las directrices de licencia vigentes desde el 16 de octubre de 2026 también indican un límite de uso de 1 GB de ingestión de datos sin procesar al día, agregado entre todas las fuentes. La tabla licencia por usuarios y servidores, pero la frase sobre volumen no precisa si esa cantidad corresponde a cada subscription o al tenant. Por ello, no calcular 1 GB × usuarios y servidores ni asumir un límite fijo de 1 GB por tenant. Antes de dimensionar o pedir, obtener confirmación vinculante de la unidad de referencia, agregación y comportamiento al superar el límite. Un precio sin cargos de ingestión por volumen no significa uso ilimitado.

El número de subscriptions Retention Add-on también debe coincidir con el total de subscriptions NG-SIEM. No se deduce una retención ampliada para un subconjunto elegido libremente o una sola fuente.

En las integraciones Syslog, los antiguos Log Collectors de Sophos no admiten todo el alcance de retención de Next-Gen SIEM. Para ello, Sophos recomienda pasar a XDR Data Collectors; el runbook de migración del Collector existente explica el aprovisionamiento, el despliegue, el cambio de las fuentes y la aceptación. Las integraciones de API existentes no necesitan reconfigurarse únicamente por este cambio de Collector. En una SVA compartida, NDR sigue siendo una carga de trabajo independiente y no debe desactivarse accidentalmente durante la transición de Syslog. El nuevo Collector no sustituye la comprobación del derecho de uso del complemento, el formato de origen y la conservación efectiva.

El hub de SIEM organiza las guías existentes por planificación, incorporación de fuentes, transporte y comprobación de parsers. El ejemplo práctico de HTTP y parser conecta estos pasos con una fuente sintética de laboratorio; su validación práctica en un tenant sigue pendiente.

Datos personalizados: separar transporte, normalización y detección

Una Custom Integration transporta a XDR datos de una fuente que Sophos no ha optimizado. Esto no confirma todavía que se admitan la normalización, la búsqueda o la detección para esa fuente. Los Custom Parsers asignan los campos de los logs a los esquemas de eventos XDR estandarizados compatibles. Solo después se puede comprobar si están presentes los campos necesarios para la búsqueda, el Detector o la Custom Detection Rule previstos.

Los Custom Parsers requieren una suscripción a Next-Gen SIEM. Pueden administrarlos Admin y Super Admin; los demás roles solo pueden consultar la lista de parsers configurados. Los mensajes que no coinciden con ningún parser utilizan el esquema generic. Pueden aportar contexto a Cases y Custom Rules, pero solo aparecen en los resultados de búsqueda con parámetros de búsqueda avanzados. Por tanto, que una búsqueda sencilla no devuelva resultados no demuestra que no se hayan incorporado datos.

Incluso los datos correctamente normalizados no activan automáticamente todos los Detectors que correspondan al esquema. Sophos identifica determinadas vías de Detector compatibles con campos obligatorios; no garantiza los demás Detectors. Por ello, la detección deseada se valida por separado con eventos de prueba adecuados. La asistencia de IA anunciada no sustituye esta comprobación.

Un Custom Parser nuevo está desactivado de forma predeterminada. Se prueba repetidamente con distintos mensajes de ejemplo, se guarda y solo después se activa por separado. En cambio, los cambios en un parser que ya está activo surten efecto inmediatamente al guardarlos; por tanto, hay que probarlos cuidadosamente antes de guardar. Los Confirm Strings que se solapan pueden asignar mensajes al parser equivocado; por tanto, la comprobación incluye el extractor path realmente utilizado.

Sophos no mantiene ni actualiza los Custom Parsers. Un responsable operativo debe volver a comprobar la asignación de campos, las marcas de tiempo y los resultados de búsqueda o detección después de modificar el formato de origen o el parser. En el piloto, la ingesta, la normalización y el análisis deseado se documentan como tres resultados separados; un estado de transporte verde no basta.

La configuración práctica se describe en Custom HTTP Ingest, las variantes S3, Azure Event Hubs y Storage y el runbook Custom Parser. En cada variante, transporte, esquema y análisis deseado siguen siendo resultados de aceptación separados.

Abrir el dashboard NG-SIEM para revisar evidencias

Con el complemento habilitado, la vista proporcionada puede añadirse a la lista personal de dashboards de la siguiente manera:

1. Abrir Dashboards > Manage dashboards.
2. Seleccionar Find dashboards y añadir NG-SIEM a la lista.
3. Abrir el dashboard desde la lista y comparar los datos mostrados con el inventario de fuentes, el periodo y los eventos esperados.

El dashboard NG-SIEM contiene widgets sobre control de acceso, seguridad de red y eventos de auditoría. Sophos también describe un ejemplo de dashboard ISO 27001 que reúne autenticación, cambios, eventos de red y firewall, actividad de correo electrónico y archivos, y flujos de detección y Cases. La información realmente disponible para las evidencias propias depende de las fuentes conectadas y de la calidad de sus datos; la vista no constituye una certificación ISO ni una confirmación automática de cumplimiento.

La guía general de dashboards explica las listas personales, las vistas disponibles y la exportación a PDF. Si falta NG-SIEM, primero se comprueban el tenant, el complemento y los permisos; una vista vacía se investiga cotejándola con el origen de los datos y el periodo. Ni la ausencia de widgets ni unos widgets verdes sustituyen la comprobación de los eventos subyacentes.

La ayuda NG-SIEM específica del producto del 1 de octubre de 2026 describe este acceso. La ayuda general de dashboards anterior, del 17 de septiembre, todavía menciona solo TAC. Es una diferencia documental, no una garantía sobre una vista de tenant sin verificar. Si falta la entrada pese a una oferta correspondiente, aclarar el aprovisionamiento real; no crear una segunda integración por intuición.

Distinguir retención, ventanas de búsqueda y datos sin procesar

13 meses en la documentación de administración, un año en la página del producto

La descripción técnica del 1 de octubre de 2026 indica 13 meses de conservación estándar. En cambio, la página pública del producto, revisada el 28 de octubre, indica un año. Ambas mencionan ampliaciones a tres, cinco, siete o diez años. La diferencia no se interpreta como un cambio de producto confirmado ni como un simple redondeo distinto; falta una explicación inequívoca de Sophos.

Para la explicación técnica de este artículo, la referencia son los 13 meses de la documentación de administración específica del producto. No obstante, antes de realizar un pedido o comprometer un plazo de conservación, se confirma el periodo aplicable al tenant concreto, a los tipos de datos y a la oferta. Esa confirmación se incorpora al inventario de fuentes. Si, por ejemplo, se necesitan más de doce meses de historial, no debe darse por supuesto el tiempo adicional basándose solo en la publicidad general del producto. El inventario de retención y la validación siguientes comprueban el alcance acordado; no resuelven la contradicción entre fuentes mediante un plazo supuesto.

Periodo de búsqueda y acceso a datos sin procesar

Una retención larga no permite consultas de tamaño arbitrario en una sola ejecución. La ayuda actual de esquemas admite como máximo 31 días por consulta para Events normalizados, con cualquier fecha inicial dentro de los datos realmente conservados. Dividir investigaciones largas en ventanas adecuadas. La búsqueda de detections es independiente.

Para @raw y original_data, la guía SQL-QL más reciente del 15 de septiembre de 2026 indica un límite de acceso separado de 20 días. Una solicitud fuera de ese alcance se rechaza, no se recorta silenciosamente al intervalo permitido. La ayuda Query Language anterior también habla de incrementos de 20 días; no garantiza datos sin procesar más antiguos. Dividir consultas no los hace accesibles automáticamente. Este límite no demuestra borrado físico después de 20 días ni reducción general de la retención normalizada.

Data Lake Search y exportación explica elección del esquema, límites, ventanas históricas y pruebas de exportación completa. La operación de reglas distingue una búsqueda correcta de una regla de detection o suppression evaluada continuamente.

Crear un inventario de retención por fuente

El inventario forma parte de la documentación operativa, no solo de la oferta. Para cada fuente se registran los siguientes datos; las distintas categorías de eventos de una misma aplicación pueden necesitar entradas independientes:

• Sistema de origen, tenant de origen, categorías de eventos y persona responsable.
• Objetivo de la ingesta y pregunta concreta que deberá responder una futura búsqueda o evidencia.
• Campos necesarios, por ejemplo, fecha y hora del evento con zona horaria, acción, resultado y una identidad adecuada para la investigación.
• Clasificación de los datos, contenido permitido y autorización para la transmisión y el acceso.
• Conservación deseada con su justificación y alcance confirmado que se aplica realmente.
• Método de integración, permisos necesarios y responsable de las credenciales, sin copiar secretos al inventario.
• Inicio de la ingesta, retraso de procesamiento esperado y evento de prueba reproducible.
• Método de búsqueda verificado, registro más antiguo encontrado, última comprobación satisfactoria y próxima fecha de revisión.
• Procedimiento ante fallos, cambios de fuente, modificaciones de la conservación y retirada de la integración.

La especificación del producto 13 meses, ampliables hasta 10 años no se registra automáticamente como plazo efectivo para todos los registros existentes. Para la fuente propia deben aclararse el alcance, el inicio y el acceso a datos históricos. Tampoco debe darse por supuesta la incorporación retroactiva de datos antiguos ni la recuperación de datos cuyo plazo ya haya vencido.

Ejemplo de una fuente piloto

El siguiente ejemplo es una ficha de planificación, no una configuración de Sophos ni un conector verificado. Los valores son requisitos elegidos libremente para una organización ficticia:

Fuente: aplicación empresarial interna, entorno de pruebas
Eventos: inicio de sesión satisfactorio y cambio administrativo de rol
Objetivo: identificar quién ha modificado un permiso
Campos obligatorios: fecha y hora del evento con zona horaria, cuenta de prueba, acción, resultado
Conservación deseada: 24 meses
Justificación: periodo de investigación aprobado internamente
Alcance confirmado: pendiente de aclarar antes del pedido y del piloto
Conexión y método de búsqueda: pendientes de confirmar para esta fuente personalizada
Prueba: cambio de rol autorizado en una cuenta de prueba dedicada
Reversión: restablecer el rol inicial y comprobar el cambio
Equipos responsables: equipo de la aplicación junto con el equipo de operaciones de seguridad

Los 24 meses son aquí un requisito interno, no un plazo legal general ni un valor estándar del producto. Superan la retención estándar descrita, por lo que debe confirmarse una ampliación adecuada antes de la aprobación. Las cuentas y los eventos se sustituyen por los datos de prueba propios que estén autorizados. No se modifican permisos de producción para esta prueba.

Validar por separado la ingesta y la conservación

Para el piloto se registran el estado inicial y el inicio de la ingesta. Se mantienen las rutas de registro existentes hasta que se haya aceptado la nueva fuente. Después se genera un evento inocuo y autorizado que pertenezca a la categoría prevista. En el ejemplo, se cambia el rol de la cuenta de prueba y luego se restablece su valor inicial documentado.

Una vez transcurrido el tiempo de procesamiento esperado, se comprueba lo siguiente mediante el método de búsqueda o análisis confirmado para esa fuente:

1. ¿Está exactamente el evento de prueba en el tenant correcto?
2. ¿Coinciden el sistema de origen, la fecha y hora del evento, la acción y el resultado con la evidencia de origen?
3. ¿Están los campos necesarios asignados de forma comprensible, en lugar de aparecer únicamente como texto sin procesar que no resulta utilizable?
4. ¿Pueden seguirse otros eventos esperados a lo largo del periodo piloto?

Un registro recién encontrado demuestra la ingesta de esa prueba, no una conservación de varios años. Para aceptar la retención, se compara además el alcance confirmado con la configuración efectiva o con una confirmación específica del tenant. Los datos históricos existentes se comprueban mediante un intervalo de tiempo concreto; se anotan el registro más antiguo encontrado y las lagunas conocidas. Para una fuente nueva sin historial, se documenta que la conservación a largo plazo aún no se ha demostrado por el tiempo transcurrido y se programan comprobaciones posteriores.

La prueba de ingesta no exige una alerta de seguridad. Puede necesitarse un evento de auditoría ordinario como registro sin que genere un incidente. Data Collection y Live Discover explica las consultas XDR existentes; de ahí no se obtiene una consulta universal para una nueva fuente personalizada.

Acotar los fallos y revertir los cambios de forma segura

Si falta el complemento o una función, primero se comprueban el tenant, el estado real de la actualización a Fusion y el alcance confirmado del complemento. No se crea una segunda integración por conjetura ni se modifica una política de protección de endpoints para resolver una supuesta carencia de licencia.

Si faltan eventos recientes, primero se compara la evidencia de origen con el inicio de la ingesta, la categoría de eventos, la autenticación, el formato y el retraso de procesamiento acordado. Si hay registros pero no son utilizables, se comprueban la asignación de campos y la referencia temporal. Si solo faltan eventos antiguos, se investigan por separado el inicio de la ingesta, las lagunas de datos, la retención efectiva y el intervalo de búsqueda. Ampliar posteriormente la retención no es una solución garantizada para los datos que ya faltan.

Antes de reducir la conservación o retirar la integración, se aclara con los responsables qué datos siguen siendo necesarios y cómo pueden preservarse, cuando esté admitido y sea necesario. No debe suponerse que volver más adelante al valor anterior recuperará el historial perdido. Del mismo modo, eliminar una integración no demuestra que se hayan borrado los datos ya incorporados.

Si falla el piloto, solo se revierte el cambio documentado en la fuente piloto mediante el procedimiento de reversión confirmado para ella. No se tocan las credenciales compartidas, los colectores ni otras fuentes. Después se verifican el estado restablecido de la fuente y la ruta de registro anterior que siga siendo necesaria. El borrado de datos y la cancelación del complemento se aclaran por separado con el partner o los responsables; este artículo no promete un interruptor universal para ello.

Para el traspaso a operaciones deben estar disponibles el inventario de fuentes, el alcance confirmado, las evidencias del piloto, las lagunas históricas pendientes, la responsabilidad ante fallos y la fecha de revisión. Si siguen sin aclararse el formato de datos, el método de búsqueda o la retención de una fuente necesaria, esa fuente aún no está aceptada. Para escalar el caso bastan inicialmente la identificación del tenant, el intervalo de tiempo, la categoría de eventos y evidencias de error depuradas; no deben incluirse secretos ni datos personales sin procesar innecesarios en la solicitud.