Cada herramienta ve su propia parte de la infraestructura y genera sus propias señales. Un ataque, en cambio, atraviesa varios sistemas y se desarrolla en el tiempo: a menudo de noche, a menudo con credenciales válidas y herramientas legítimas, a menudo sin dejar rastros evidentes en un único dispositivo. Para detectarlo hace falta alguien que vigile de forma continua, que sepa unir señales procedentes de fuentes distintas y que, cuando algo sucede, sepa decir con claridad qué hay que hacer.

Es el trabajo de un Security Operations Center. En los últimos años, sin embargo, la oferta de SOC gestionados se ha multiplicado y los mensajes se parecen todos: monitorización 24/7, detección avanzada y ahora, inevitablemente, inteligencia artificial. Para quien tiene que elegir —un CISO, un responsable de TI, un partner que debe proponer el servicio a sus propios clientes— resulta difícil entender dónde están las diferencias reales.

Este artículo intenta hacerlas explícitas. Describe qué es Orizon Oversight y cómo funciona; lo compara con los dos modelos que el mercado propone con más frecuencia, el SOC construido en torno a un EDR y el llamado «AI SOC»; explica por qué, en Oversight, la inteligencia artificial es una herramienta en manos de los analistas y no su sustituto; y se detiene en el punto que, en nuestra opinión, más pesa en la vida real de un cliente: el momento posterior a la notificación de un incidente, cuando no basta con saber que hay un problema, sino que hace falta saber cómo resolverlo.

La cadena de detección se articula en varios pasos, cada uno con una función precisa:

1. Recogida. Los datos llegan de endpoints y EDR, firewalls y dispositivos de red, servidores Windows y Linux, proveedores de identidad y directorios, entornos cloud y SaaS (por ejemplo Microsoft 365, Google Workspace, AWS, Azure) y aplicaciones de negocio. El envío se realiza mediante collectors y mecanismos estándar —syslog, API— sin necesidad de rediseñar la red. La plataforma integra actualmente más de 500 vendors diferentes.
2. Normalización. Eventos heterogéneos se adaptan al esquema abierto OCSF (Open Cybersecurity Schema Framework), de modo que un inicio de sesión en un firewall, un proceso en un endpoint y un acceso a Microsoft 365 puedan compararse en el mismo lenguaje.
3. Security Data Lake. Los datos se conservan y siguen siendo consultables, tanto para la operativa diaria como para el threat hunting retrospectivo.
4. Correlación y detección. Motores de correlación potenciados por IA y machine learning, con reglas mapeadas en el framework MITRE ATT&CK y enriquecimiento con threat intelligence, hacen emerger las señales relevantes entre el ruido.
5. Validación e investigación. Lo que la IA detecta y correlaciona es verificado por los analistas, que lo confirman, lo descartan o lo profundizan. Solo entonces se convierte en una attack story: la reconstrucción coherente de un ataque, desde el primer rastro hasta el último paso observado.
6. Entrega y respuesta. El cliente —o el partner que lo atiende— recibe la investigación con las evidencias y las recomendaciones de mitigación y remediación. Los playbooks automáticos (SOAR) apoyan el enriquecimiento y la escalada; las acciones de contención sobre las tecnologías integradas, como el EDR, se ejecutan según lo acordado con el cliente.

Hasta aquí, la descripción podría aplicarse a más de un servicio del mercado. Las diferencias se hacen evidentes al comparar Oversight con los dos modelos de SOC que el cliente encuentra hoy con más frecuencia.

El límite no está en la calidad del EDR, sino en su perímetro. Un SOC basado en EDR ve donde está el agente. Y un ataque rara vez vive solo en el endpoint; a menudo se desarrolla en otro lugar, o pasa por otro lugar antes de llegar a él:

• la identidad: un acceso VPN o a Microsoft 365 con credenciales válidas robadas, o con una cookie de sesión sustraída por un infostealer, no genera necesariamente ningún evento sospechoso en un endpoint gestionado;
• el correo electrónico: reglas de reenvío creadas en un buzón comprometido, mensajes de phishing internos enviados desde una cuenta legítima;
• el perímetro: la explotación de una vulnerabilidad en un firewall o en un gateway VPN se produce en un dispositivo en el que, normalmente, no se puede instalar un agente EDR;
• el cloud y las aplicaciones: cambios de permisos en un tenant cloud, accesos anómalos a una aplicación de negocio;
• los dispositivos no gestionados: servidores heredados, sistemas OT, appliances, equipos de terceros.

Hay además un segundo aspecto, menos técnico pero relevante: el SOC pasa a depender de ese producto. Cambiar de EDR significa, a menudo, cambiar también de proveedor de SOC.

Oversight parte de la premisa opuesta. Es agnóstico respecto a las tecnologías del cliente y no sustituye al EDR: amplía su valor, integrándolo como una de las fuentes —CrowdStrike, SentinelOne, Microsoft Defender, Sophos y otras— y correlacionando su telemetría con la de identidad, correo electrónico, firewalls, cloud y aplicaciones en un único Security Data Lake. El EDR sigue siendo además la herramienta con la que orquestar la contención directamente en el endpoint. Por eso, a la pregunta «ya tenemos un EDR, ¿necesitamos un SOC?», la respuesta más correcta no es «sí, porque el EDR no basta», sino «sí, porque su EDR se vuelve mucho más útil cuando alguien lee sus señales junto con todo lo demás».

Hoy, sin embargo, tener IA ya no es un elemento diferenciador: casi todos la declaran. Lo que cuenta es más bien qué trabajo elimina realmente, y quién sigue siendo responsable de las decisiones. Cuando la IA se sitúa en el centro del SOC, suelen surgir tres problemas.

En Oversight la inteligencia artificial es una herramienta al servicio de los analistas, no su sustituto. Hace lo que sabe hacer mejor y más rápido que una persona: correlaciona grandes volúmenes de eventos, recopila el contexto, reconstruye las secuencias y realiza el trabajo repetitivo de investigación. Pero lo que la IA detecta es validado o verificado por los analistas antes de convertirse en una investigación entregada al cliente, precisamente porque la IA puede equivocarse. La decisión de seguridad queda en manos de una persona que tiene la competencia y la responsabilidad para tomarla.

Los tres modelos comparados

Un resumen necesariamente simplificado: las ofertas del mercado varían, y la comparación debe verificarse siempre en el caso concreto.

En el modelo más extendido, el SOC hace bien su trabajo —detecta, califica, notifica— y después entrega al cliente una alerta o un ticket del tipo: «Detectada actividad sospechosa en el servidor X. Recomendamos aislar la máquina e iniciar una investigación.» A partir de ese momento, el equipo de TI del cliente, o el partner que lo asiste, a menudo está solo: tiene que entender dónde empezó el ataque, hasta dónde llegó, qué cuentas y qué sistemas están implicados y qué hay que corregir para que no se repita. Son justamente las horas en las que escasean las competencias y la presión es máxima.

Oversight está pensado para reducir al mínimo este vacío. Lo que llega al cliente no es otra alerta, sino una investigación ya instruida: la attack story, construida con el apoyo de la IA y validada por los analistas, que pone a disposición de quien debe intervenir:

• la cronología del ataque, paso a paso, con cada paso mapeado en las técnicas MITRE ATT&CK;
• las evidencias en las que se basa la reconstrucción, consultables también de forma autónoma con el add-on DX Data Explorer;
• los sistemas implicados: hosts, cuentas, direcciones y servicios afectados, y lo que en cambio resulta ajeno;
• por qué es relevante: la gravedad, el impacto potencial y la fase del ataque en la que se encuentra;
• las recomendaciones de mitigación y remediación: qué hacer de inmediato para contener, qué corregir después, en qué sistemas, en qué orden y cómo verificar que la intervención ha surtido efecto.

La respuesta sigue en manos del partner o del cliente, que mantienen el control de su propio entorno y deciden cómo y cuándo intervenir. Pero no parten de cero: parten de un plan de acción ya planteado.

Un ejemplo

Un caso ilustrativo ayuda a transmitir la diferencia. A las 02:14 una cuenta de usuario se conecta a la VPN corporativa desde una dirección nunca vista antes. Pocos minutos después, desde la misma cuenta, se lanzan consultas masivas a Active Directory; a las 02:31 se ejecuta en un servidor de ficheros un script de PowerShell que crea una tarea programada e intenta detener el servicio de copias de seguridad.

Una notificación tradicional podría limitarse al último evento: ejecución sospechosa de PowerShell en SRV-FILE-02, se recomienda verificación.

La attack story de Oversight, en cambio, une los cuatro pasos en una única secuencia —acceso inicial con credenciales válidas, reconocimiento, ejecución, intento de comprometer la capacidad de recuperación— y, tras la verificación del analista, la acompaña con recomendaciones de este tipo:

• mitigación inmediata: aislar SRV-FILE-02 mediante el EDR integrado, cerrar la sesión VPN activa, bloquear la dirección de origen;
• restablecer las credenciales de la cuenta implicada y revocar las sesiones activas, también en los servicios cloud;
• eliminar la tarea programada creada a las 02:31 y comprobar la existencia de mecanismos de persistencia similares en otros sistemas;
• verificar la integridad de las copias de seguridad antes de cualquier restauración;
• revisar la política de autenticación VPN del grupo al que pertenece la cuenta;
• controles de verificación posteriores, que el cliente también puede ejecutar en DX Data Explorer, si está activo.

Ejemplo ilustrativo, elaborado con fines explicativos: el contenido y el nivel de detalle de las recomendaciones dependen del tipo de incidente y de las fuentes integradas.

Para el cliente significa pasar del «¿qué hacemos ahora?» a un plan de acción claro. Para el partner significa poder intervenir de inmediato, con un alcance de trabajo definido, en lugar de reconstruir el incidente desde cero.

DX Data Explorer: el cliente ve sus propios datos

La objeción es conocida: «si confío la monitorización a terceros, me quedo a oscuras». DX Data Explorer permite al cliente consultar en autoservicio el mismo data lake en el que trabajan los analistas: de la alerta al dato en bruto, con consultas estructuradas, dashboards personalizables y datos exportables, desde el navegador con SSO y MFA.

No sustituye al SOC; lo hace verificable. El cliente puede profundizar en un evento, comprobar las evidencias de una investigación o generar una evidencia para una auditoría sin abrir un ticket y esperar una respuesta. Es el add-on que conviene proponer cuando el cliente tiene un equipo de seguridad interno, o un CISO que no quiere depender de terceros para responder a las preguntas de su propio consejo de administración.

Cold Storage: la memoria a largo plazo de los logs

En este caso la objeción llega más tarde: «cuando hay que reconstruir qué pasó, los logs ya no están». Es un problema estructural, no un descuido. La ventana «caliente» de un SIEM —los datos inmediatamente consultables para la detección y la investigación diaria— es cara de mantener, y por eso se mantiene corta: a menudo en torno a los 90 días. Pero una investigación forense, un requerimiento de una autoridad o una auditoría pueden llegar meses o años después del evento, cuando las evidencias ya no existen.

Cold Storage amplía el ciclo de vida del dato más allá de esa ventana. Los logs, una vez salen de la fase «caliente», se trasladan a un archivo «frío» cifrado, sin sobrecargar —ni encarecer— el entorno de análisis activo. En concreto:

• retención configurable, con horizontes de hasta 36 meses, a definir según los requisitos normativos y contractuales de la organización;
• archivo cifrado y duradero, con controles de integridad integrados;
• restauración y exportación bajo demanda: los conjuntos de datos archivados vuelven a un formato consultable cuando se necesitan para una investigación, o se exportan para una auditoría.

El punto que merece contarse al cliente es precisamente el de la integridad. Un log conservado pero alterable tiene un valor limitado: los controles de integridad son lo que permite demostrar que los registros no han sido modificados, y es eso lo que les confiere valor probatorio ante un auditor, una autoridad o en un litigio.

Es el add-on que conviene proponer a quien tiene obligaciones de conservación de evidencias —ámbito NIS 2 o DORA, sectores regulados, organizaciones sujetas a auditorías periódicas— y a quien, habiendo vivido ya un incidente, sabe lo que cuesta no poder reconstruir lo ocurrido. Funciona bien junto con DX: Cold Storage conserva, DX permite consultar lo que se ha conservado.

Dark Web Intelligence: más allá del MFA

El tercer add-on se refiere a la identidad. Los infostealers sustraen no solo credenciales, sino también cookies de sesión ya autenticadas, que permiten eludir la autenticación multifactor. Dark Web Intelligence monitoriza foros, marketplaces y canales del ecosistema infostealer en busca de credenciales y sesiones vinculadas a la organización, filtrando los resultados sobre las identidades corporativas reales y permitiendo invalidar las sesiones y rotar las credenciales antes de que se utilicen. Está disponible en dos niveles: un escaneo mensual, adecuado para necesidades de cumplimiento y organizaciones de bajo riesgo, y una monitorización continua 24/7 con remediación inmediata.

Oversight lleva las capacidades de un SOC empresarial —monitorización 24/7, correlación multifuente, analistas que validan cada detección— a organizaciones que no pueden construir uno propio. Se distingue de un SOC basado en EDR porque ve más allá del endpoint y amplía su valor en lugar de depender de él. Se distingue de un «AI SOC» porque la inteligencia artificial es una herramienta en manos de los analistas: elimina el trabajo repetitivo, mientras la decisión sigue siendo humana. Y, sobre todo, no se detiene en la alerta: entrega una investigación ya instruida, con las evidencias, los sistemas implicados y las recomendaciones de mitigación y remediación.

Para el partner no es «otro servicio más que vender»: es un servicio recurrente que saca partido de las herramientas ya presentes en el cliente, le deja el control de la respuesta y, en cada incidente, le ofrece un alcance de intervención claro.

Los próximos pasos son concretos: una sesión de cualificación para inventariar activos y fuentes de logs; una demostración de la consola, de una attack story y de una consulta en directo en DX; y la definición del alcance y de los procedimientos de escalada para el onboarding.

Más información: orizon.one/oversight