Explicación de la observabilidad de la seguridad: de los «desconocidos conocidos» de la monitorización a las consultas de alta cardinalidad

La observabilidad de la seguridad es la disciplina que consiste en equipar a los sistemas con herramientas de monitorización para que los equipos de seguridad puedan responder a preguntas arbitrarias e imprevistas a partir de datos de telemetría detallados y de alta cardinalidad, sacando a la luz lo «desconocido-desconocido» que las reglas predefinidas nunca habían previsto. Mientras que la monitorización se limita a detectar señales conocidas, la observabilidad permite preguntarse «por qué» y plantear preguntas para las que ningún panel de control ha sido diseñado.

Esa distinción es importante porque los atacantes rara vez se comportan como esperan las detecciones predefinidas. Combinan credenciales legítimas, herramientas novedosas y movimientos en varias etapas que ningún umbral por sí solo es capaz de detectar. La capacidad de analizar la telemetría existente —de plantear una pregunta que solo se te ha ocurrido tras recibir una alerta— es lo que convierte un «hemos recibido una alerta» en un «podemos reconstruir exactamente lo que hizo el atacante». Esta guía explica qué es la observabilidad de la seguridad, en qué se diferencia de la supervisión, la visibilidad y el SIEM, los pilares de telemetría en los que se basa, la arquitectura de datos moderna que la sustenta y hacia dónde se dirige esta disciplina con la detección como código y la observabilidad mediante agentes de IA. Se basa en el marco más amplio de supervisión de la seguridad que ya utilizan la mayoría de los SOC.

¿Qué es la observabilidad de la seguridad?

La observabilidad de la seguridad es la disciplina que consiste en equipar a los sistemas con instrumentos que permitan responder a preguntas relevantes para la seguridad —ya sean arbitrarias o imprevistas— a partir de datos de telemetría detallados y de alta cardinalidad —sacando a la luz lo «desconocido-desconocido»—, en lugar de basarse únicamente en las señales, los paneles de control y las alertas predefinidas de la supervisión, que responden a lo «conocido-desconocido».

El término tiene raíces tanto académicas como operativas. Los investigadores han definido la observabilidad como una forma de reforzar la arquitectura de seguridad de los ecosistemas digitales complejos, considerando las preguntas que se pueden plantear sobre un sistema como un indicador de su capacidad de defensa (arXiv). En la práctica, la disciplina toma prestados conceptos de la ingeniería de fiabilidad de sistemas, donde la observabilidad describe hasta qué punto se puede comprender el estado interno de un sistema a partir de los datos que este emite. La observabilidad en ciberseguridad aplica esa misma propiedad a las cuestiones de seguridad: ¿con qué grado de exhaustividad y flexibilidad se puede analizar la telemetría para comprender qué ha hecho un adversario?

La diferencia con respecto a la monitorización es precisamente la clave. La monitorización responde a las «incógnitas conocidas»: aquellas preguntas que ya habías previsto y para las que habías configurado alertas con antelación. La observabilidad responde a las «incógnitas desconocidas»: aquellas preguntas que no se te ocurrió plantear hasta que un incidente te obligó a hacerlo. Un sistema de monitorización solo es tan bueno como las reglas que alguien escribió ayer; un sistema observable sigue siendo útil para las preguntas que se te ocurran mañana.

Por qué es importante la observabilidad en la ciberseguridad

La monitorización se basa en preguntas que ya sabes que debes plantear. Tú defines un umbral —intentos fallidos de inicio de sesión por minuto, bytes salientes por host, un malware conocido— y el sistema te avisa cuando se supera ese umbral. Esto funciona bien para los «desconocidos conocidos»: problemas que has anticipado y para los que te has preparado de antemano. El problema es que una alerta solo te indica que algo ha ocurrido, no por qué ha ocurrido ni qué más ha afectado el mismo actor.

El problema es que los ataques sofisticados son, casi por definición, aquello que no se había previsto. Una técnica novedosa de «living-off-the-land», una ruta de varios pasos que parece inofensiva en cada etapa individual, o un patrón de uso indebido de credenciales en el que ninguna señal aislada eludirá las reglas predefinidas. Este es el argumento fundamental a favor de la observabilidad de la seguridad: cuando la telemetría es lo suficientemente rica y consultable, un analista puede plantear una pregunta totalmente nueva —«muéstrame todos los procesos que escribieron en este directorio y luego establecieron una conexión saliente hacia una nueva región»— sin haber creado previamente una regla para ello. Esa capacidad de indagar en lo desconocido es lo que permite a la observabilidad detectar ataques novedosos y de múltiples pasos a lo largo de una superficie de ataque cada vez más extensa.

Hay una segunda ventaja: la rapidez y la certeza durante la investigación. Cuando todas las señales relevantes se pueden consultar en un solo lugar, un analista puede pasar de un único indicador a conocer el panorama completo en cuestión de minutos, en lugar de días, confirmando el alcance, descartando pistas falsas y reconstruyendo la cronología de los hechos. Esa es la diferencia entre saber que se ha activado una alerta y saber exactamente qué ha hecho un atacante, razón por la cual la observabilidad se ha convertido en una capacidad definitoria del centro de operaciones de seguridad moderno.

Es fundamental señalar que la observabilidad de la seguridad es una disciplina genérica, no una característica propia de un único proveedor. La definición anterior se mantiene deliberadamente independiente de cualquier proveedor: se refiere a una propiedad del sistema y a las prácticas que adopta un equipo, no a una categoría de productos.

Observabilidad de la seguridad frente a supervisión, visibilidad y SIEM

La monitorización te indica que algo va mal; la observabilidad te permite preguntarte por qué, y plantear preguntas que ninguna regla había previsto. Estos términos suelen utilizarse de forma imprecisa, por lo que conviene analizar cada contraste con rigor, ya que las distinciones determinan las decisiones reales sobre arquitectura y dotación de personal. La observabilidad no compite con la monitorización de seguridad, sino que la amplía.

Una analogía útil nos la ofrece la medicina. La monitorización es como un monitor de constantes vitales que emite un pitido cuando un valor se sale del rango de seguridad: te indica que un paciente se encuentra en peligro. La observabilidad es el proceso de diagnóstico que permite al médico investigar el motivo, siguiendo los síntomas allá donde le lleven, incluso por caminos que nadie había previsto. Ambas cosas son importantes; ninguna sustituye a la otra.

Las diferencias se pueden clasificar en cuatro ámbitos: alcance (señales predefinidas frente a preguntas arbitrarias), análisis (umbrales frente a exploración), conocimiento del problema (lo que se sabe que se desconoce frente a lo que se desconoce que se desconoce) y profundidad de la capacidad (alertas frente a investigación). La tabla siguiente resume la relación entre la supervisión, la observabilidad y la visibilidad.

Tabla: En qué se diferencian la monitorización, la observabilidad y la visibilidad: la monitorización supervisa señales conocidas, la observabilidad lo analiza todo y la visibilidad proporciona los datos subyacentes.

¿Es la monitorización un subconjunto de la observabilidad?

Una forma más clara de plantearlo es considerar que se trata de propiedades complementarias, en lugar de que una sea un subconjunto estricto de la otra. La monitorización es la capa de señales predefinidas: el acto de observar métricas específicas. La observabilidad es la propiedad de un sistema que permite responder a preguntas arbitrarias. Los programas maduros utilizan ambas: la monitorización detecta rápidamente lo conocido, y la observabilidad se encarga de todo lo que la monitorización no puede anticipar. La observabilidad no sustituye a la monitorización; amplía lo que un equipo puede preguntarse, por lo que la pregunta correcta rara vez es «cuál de las dos», sino «cómo se refuerzan mutuamente».

Observabilidad frente a visibilidad

La visibilidad es la capa de fuentes de datos: los datos que realmente se pueden ver y recopilar de un dominio determinado, como la red. La visibilidad de la red, por ejemplo, es una fuente de datos; la observabilidad es la disciplina analítica que la consulta junto con cualquier otro flujo de telemetría. En pocas palabras, la visibilidad proporciona los datos de entrada, y la observabilidad es lo que se hace con ellos. Los mecanismos de recopilación de paquetes, TAP, SPAN y de tráfico este-oeste que generan datos de red forman parte de la visibilidad de red; la observabilidad consume esos datos como una de las entradas, junto con los registros, las métricas, los rastros, la identidad y cloud . No se puede lograr una observabilidad significativa sin visibilidad de los datos subyacentes, pero la visibilidad por sí sola, sin la capacidad de realizar consultas sobre ellos, deja sin respuesta las preguntas difíciles.

Observabilidad frente a SIEM

Los sistemas de gestión de información y eventos de seguridad (SIEM) centralizan y correlacionan los datos de seguridad con reglas de detección predefinidas. La observabilidad es una disciplina más amplia que consiste en plantear preguntas arbitrarias a datos de telemetría de alta cardinalidad. En lugar de un veredicto del tipo «el ganador se lo lleva todo», la relación se entiende mejor como un espectro: la observabilidad puede complementar un SIEM, desacoplar el almacenamiento económico de la capa analítica del SIEM o —en algunos casos cloud— sustituir por completo a un SIEM heredado. Que la observabilidad de seguridad sea una alternativa viable al SIEM depende de cloud de la organización, sus necesidades de retención y su modelo de costes, y no de una respuesta única válida para todos los casos. Muchos equipos se sitúan en un término medio: mantienen el SIEM como capa de consulta y correlación, al tiempo que trasladan el almacenamiento masivo a un nivel más barato y desacoplado, de modo que pueden conservar y analizar muchos más datos de telemetría de los que permitiría la indexación basada en el precio de la ingesta.

Los pilares de la observabilidad de la seguridad

Los tres pilares —registros, métricas y trazas— se amplían, en el ámbito de la seguridad, a eventos, detecciones, flujos de red, identidad y cloud . El modelo canónico del mundo más amplio de la observabilidad consta precisamente de tres elementos: los registros recogen lo que ha ocurrido, las métricas cuantifican la magnitud y la frecuencia, y las trazas muestran cómo se ha desplazado una solicitud a través de un sistema distribuido.

En materia de seguridad, ese modelo suele ampliarse a MELT —métricas, eventos, registros y trazas—, que trata los eventos como elementos de primera clase. Los tres pilares siguen siendo canónicos; MELT es la extensión orientada a la seguridad, ya que los eventos de seguridad discretos —como la activación de una detección, un cambio de política o la concesión de privilegios— merecen un estatus de primera clase en lugar de quedar ocultos en los registros generales. Una crítica más reciente, la de los «eventos amplios», sostiene que los registros de eventos ricos y de alta cardinalidad pueden ser más importantes que la rígida división en tres pilares; se trata de un debate que merece la pena seguir, pero los pilares siguen siendo una vía de acceso útil para los equipos que se inician en la disciplina.

El verdadero valor para los equipos de seguridad radica en ampliar cada pilar genérico a su contexto de seguridad, de modo que las señales de seguridad se conviertan en datos de observabilidad de primer orden, en lugar de elementos secundarios. Un registro no es solo un mensaje de una aplicación, sino un registro de auditoría; una métrica no es solo una cifra de latencia, sino una tasa de intentos fallidos de inicio de sesión; un rastro no es solo un mapa de rendimiento, sino un registro del tráfico este-oeste que un atacante podría aprovechar. La tabla siguiente relaciona cada pilar con su extensión de seguridad, junto con un ejemplo de señal.

Tabla: Los tres pilares de la observabilidad ampliados a la seguridad, con una señal de ejemplo para cada uno.

¿Qué fuentes de datos alimentan la observabilidad de la seguridad?

En la práctica, las fuentes de información son muy variadas. Los registros de aplicaciones y sistemas proporcionan el registro bruto de la actividad; los eventos de seguridad y las detecciones añaden los sucesos concretos que más importan; la telemetría de red y de flujos capta cómo se comunican los hosts y los servicios; los registros de identidad y auditoría muestran quién hizo qué; y cloud de terminales y cloud completan el panorama en todas las cargas de trabajo. Las señales de comportamiento —la base de la detección de anomalías en la red — son especialmente valiosas porque describen cómo se comportan realmente las entidades, en lugar de limitarse a comparar con una lista de elementos conocidos como maliciosos, lo que las hace eficaces frente a técnicas novedosas. La característica definitoria de todas estas fuentes de datos es que se tratan como telemetría consultable, no como flujos de alertas aislados, de modo que un analista puede establecer correlaciones entre ellas bajo demanda, en lugar de tener que alternar entre consolas inconexas. El objetivo es disponer de un único conjunto lógico de datos de telemetría al que pueda acceder cualquier consulta, independientemente de la herramienta que haya generado originalmente los datos.

Cómo funciona la observabilidad de la seguridad: la arquitectura de datos moderna

La observabilidad de la seguridad moderna recopila datos con OpenTelemetry, los normaliza con OCSF, los almacena en un lago de datos desacoplado y, a continuación, los consulta bajo demanda. Comprender este proceso es lo que distingue un término de moda de una capacidad real, y es la capa que diferencia más claramente la observabilidad de las disciplinas de monitorización y visibilidad que la rodean.

Las etapas funcionan de la siguiente manera:

• Recopilación. OpenTelemetry (OTel) es el estándar abierto para la recopilación de datos de telemetría —registros, métricas y trazas— en sistemas heterogéneos. Se graduó de la Cloud Computing Foundation (CNCF) el 21 de mayo de 2026 y ha crecido hasta contar con más de 12 000 colaboradores de más de 2 800 empresas, lo que ha consolidado su estatus como el estándar de observabilidad de código abierto de facto (CNCF, documentación de seguridad de OpenTelemetry). El Extended Berkeley Packet Filter (eBPF) es un mecanismo complementario a nivel del núcleo que captura una amplia telemetría del sistema y de la red con una baja sobrecarga, y que a menudo alimenta el mismo canal de procesamiento.
• Normalización. El Marco de Esquemas Abiertos de Ciberseguridad (OCSF) integra la telemetría de numerosos proveedores en un único esquema independiente del proveedor, de modo que un evento de inicio de sesión tiene el mismo significado independientemente de su origen (OCSF). OCSF lanzó la versión 1.8.0 (registro de cambios con fecha del 16 de marzo de 2026), en la que se añadió un ai_operación perfil para modelar cargas de trabajo de IA como telemetría de seguridad de primer orden (Registro de lanzamientos de OCSF). La norma también recibió el apoyo de los Estados miembros de la Unión Internacional de Telecomunicaciones (UIT) en diciembre de 2025, con vistas a su ratificación como norma internacional en junio de 2026 (Blog de código abierto de AWS).
• Almacenamiento. Las arquitecturas modernas separan el almacenamiento del análisis, almacenando los datos de telemetría sin procesar en un «data lake» de seguridad basado en un almacén de objetos de bajo coste, en lugar de en un índice cuya ingestión tiene un coste elevado. Un «data lake» de seguridad almacena datos de alta cardinalidad de forma económica y a gran escala, y el motor de análisis actúa como una capa de consulta sobre él (Guía de mercado de Software Analyst).
• Consultas y análisis. Una vez normalizados y almacenados los datos, los analistas y los ingenieros de detección realizan consultas arbitrarias, lo que constituye el núcleo de la observabilidad.
• Detección como código. Las detecciones se expresan entonces como código sujeto a control de versiones y que se puede probar, y se implementan a través del mismo proceso de integración.

Esquema en lectura y almacenamiento desacoplado

El cambio que hace que esto funcione es el «esquema en lectura» (schema-on-read). Los SIEM tradicionales aplican el «esquema en escritura» (schema-on-write): estructuran e indexan los datos en el momento de la ingesta, lo cual resulta rígido y costoso. Por el contrario, el «esquema en lectura» aplica la estructura en el momento de la consulta, de modo que los equipos pueden almacenar telemetría sin procesar y de alta cardinalidad de forma económica e interpretarla con flexibilidad más adelante. Esta es la única perspectiva de costes que nos ocupa aquí: en lugar de la disyuntiva económica entre «desarrollar o comprar» que se aborda en los modelos de implementación de la monitorización de la ciberseguridad, la cuestión de los costes de la observabilidad radica en la disyuntiva entre almacenamiento y análisis, así como en la retención de datos. Una plataforma de canalización de datos de seguridad se sitúa entre la recopilación y el almacenamiento para enrutar, enriquecer y reducir la telemetría antes de que llegue a su destino.

Reducir los puntos cloud

Los entornos Cloud —contenedores efímeros, cargas de trabajo de Kubernetes, identidades de corta duración— generan precisamente ese tipo de telemetría de alta cardinalidad y rápida evolución con la que la monitorización por umbrales tiene dificultades. Aquí es donde la observabilidad demuestra su utilidad, y se vincula directamente con cloud . Las barreras son reales: en la encuesta «SANS 2025 Detection & Response Survey», el 58 % de los encuestados citó cloud limitada cloud y el 53 % mencionó la complejidad del entorno multicloud como cloud principales cloud (cobertura de la encuesta de SANS). Dado que cloud es, por naturaleza, de alta cardinalidad y efímera, la observabilidad reduce los puntos ciegos al mantener esos datos consultables una vez que la carga de trabajo ha desaparecido. Cabe señalar que el panorama de los flujos de datos de seguridad y las convenciones de IA generativa de OpenTelemetry evolucionan rápidamente, por lo que las decisiones de arquitectura deben revisarse periódicamente.

Detección como código y análisis de alta cardinalidad

La «detección como código» gestiona las detecciones mediante control de versiones, al igual que el software; las consultas de alta cardinalidad sacan a la luz los ataques que las reglas predefinidas nunca habían previsto. Juntas, conectan la disciplina de la observabilidad con el flujo de trabajo diario de los profesionales.

La «detección como código» aplica la filosofía de la «infraestructura como código» a las detecciones. En lugar de introducir reglas en una consola, los equipos escriben las detecciones en forma de código que:

• Con control de versiones, por lo que se realiza un seguimiento de cada cambio y se puede revisar.
• Se implementa mediante CI/CD, por lo que las detecciones se envían a través de un proceso probado.
• Comprobable, es decir, la detección se valida con muestras conocidas antes de pasar a producción.
• Es portátil, por lo que la lógica no queda limitada al formato propio de una sola herramienta.

Esta es la columna vertebral de la ingeniería de detección moderna, y se complementa de forma natural con la búsqueda de amenazas, en la que los analistas utilizan consultas exploratorias para detectar lo que ninguna regla ha captado todavía. Ambas contribuyen a obtener resultados más amplios en la detección de amenazas.

¿Qué son los datos de alta cardinalidad?

Los datos de alta cardinalidad son datos de telemetría con muchos valores únicos: ID de usuario, ID de contenedor, tokens de sesión, direcciones IP de origen. La alta cardinalidad es lo que hace posible realizar consultas arbitrarias: cuando puedes segmentar los datos de telemetría según cualquiera de los miles de atributos únicos, puedes plantear una pregunta que se te acaba de ocurrir. Los «eventos amplios» —registros detallados que contienen muchos atributos por evento— son el formato que permite responder a preguntas de alta cardinalidad. Así es precisamente como la observabilidad ayuda a detectar amenazas desconocidas: la capacidad de consulta permite a los analistas plantear preguntas que no están codificadas en ninguna regla predefinida.

Por qué las detecciones predefinidas son, por naturaleza, incompletas

Los argumentos a favor de la observabilidad exploratoria se basan en datos concretos. Los sistemas SIEM empresariales cubren aproximadamente el 21 % de MITRE ATT&CK , dejando sin detectar el 79 % restante, a pesar de contar con una infraestructura que, en teoría, podría detectar más del 90 % de las técnicas (CardinalOps, junio de 2025; Reportaje de Help Net Security). El mismo estudio reveló que, de media, el 13 % de las reglas de detección se incumplen, lo que supone un descenso del 5 % con respecto a 2024. La conclusión no es que «tu sistema de monitorización esté fallando», sino que las detecciones predefinidas son estructuralmente incompletas, por lo que necesitas una observabilidad de alta cardinalidad para plantear las preguntas que las reglas nunca previeron. MITRE ATT&CK el punto de referencia en este caso: el valor de la observabilidad radica en realizar consultas que abarquen técnicas como el «Descubrimiento» (0007) y la detección de servicios de red (T1046) que las coberturas predefinidas no incluyen (MITRE ATT&CK).

Dos ejemplos ilustrativos de uso

La vulnerabilidad Log4Shell (CVE-2021-44228) es un ejemplo concreto de cómo los datos de observabilidad pueden servir como fuente de investigación. Los analistas que detectaron procesos secundarios sospechosos de Java pudieron reconstruir la ruta del exploit utilizando registros de supervisión del rendimiento de la aplicación —un servicio de backend que aparecía brevemente en el mapa de servicios— junto con los registros de la aplicación, que mostraban cargas útiles codificadas en base64 en los encabezados de las solicitudes, lo que confirmó la existencia de bibliotecas vulnerables (CISA AA21-356A). Este caso es un ejemplo de metodología de 2021, no una estadística actual, pero la lección sigue siendo válida: la telemetría unificada convierte una alerta en una reconstrucción completa.

Un patrón más habitual hoy en día es el movimiento lateral cloud a partir de una credencial filtrada. Una sola señal —un intento fallido de inicio de sesión, una conexión de red— puede parecer insignificante. La observabilidad saca a la luz la brecha de seguridad al correlacionar el intento fallido de inicio de sesión, el tráfico de red inusual, los patrones de acceso a archivos y las lecturas procedentes de una región inusual en una única consulta de alta cardinalidad. Esa correlación es la forma en que la observabilidad mejora los tiempos de respuesta ante incidentes y facilita la detección proactiva de amenazas: detecta ataques de varios pasos que el seguimiento basado en umbrales de una sola señal pasaría por alto. Un análisis de respuesta a incidentes de 2026, realizado por el equipo de investigación de Unit 42 sobre más de 750 incidentes, llega a la misma conclusión: los investigadores a menudo tenían que recopilar datos de fuentes inconexas, lo que ralentizaba la detección, y el informe relacionó el 90 % de las brechas con configuraciones erróneas o lagunas de seguridad (PR Newswire).

IA y observabilidad de los agentes

La observabilidad en el ámbito de la IA amplía sus pilares a las instrucciones, las llamadas a herramientas y los rastros, ya que el 48 % de los agentes de IA se ejecutan sin supervisión. Se trata de la ampliación más reciente de esta disciplina, y está avanzando a gran velocidad.

La observabilidad de los agentes de IA consiste en ampliar los pilares de la observabilidad para incluir señales propias de la IA: indicaciones, llamadas a herramientas, procedencia de la recuperación de información, métricas de tokens y turnos, los permisos vigentes durante una acción y los rastros de extremo a extremo del razonamiento y las acciones de un agente. La observabilidad de los sistemas de IA es el mismo concepto aplicado a cualquier componente de IA probabilística, no solo a los agentes autónomos.

La razón por la que se necesita una nueva telemetría es que los sistemas de IA probabilística rompen los supuestos deterministas en los que se basa la supervisión. Un ataque contra un agente de IA puede tener éxito de forma silenciosa —manipulando al agente para que realice una acción perjudicial— sin que se active en ningún momento una métrica de error estándar ni un umbral de latencia. Solo la telemetría nativa de IA permite determinar qué hizo el agente, por qué lo hizo y qué herramientas y permisos intervinieron, de modo que un defensor pueda reconstruir el incidente posteriormente.

La exposición es considerable. Aproximadamente el 80 % de las empresas de la lista Fortune 500 utilizaban agentes de IA activos en febrero de 2026. Sin embargo, la cobertura media de supervisión de los agentes de IA se situaba en tan solo el 52 %, lo que deja un 48 % de los agentes funcionando sin protección (Gravitee, 2026). Para equipar un agente de IA con herramientas de observabilidad, los equipos suelen recopilar:

• Mensajes y respuestas, incluidos los mensajes del sistema.
• Llamadas a herramientas y funciones, con argumentos y resultados.
• Procedencia de la recuperación: qué documentos o datos han servido de base para una respuesta.
• Métricas de tokens y turnos a lo largo de una conversación.
• La identidad y los permisos vigentes para cada acción.

Las normas y la normativa se están poniendo al día. La OCSF... ai_operación Profile (v1.8.0, marzo de 2026) ofrece a las cargas de trabajo de IA una cobertura de esquemas de primera clase (Registro de lanzamientos de OCSF). El NIST puso en marcha su Iniciativa sobre Normas para Agentes de IA el 17 de febrero de 2026, que incluye investigación sobre la seguridad y la identidad de los agentes de IA (NIST), y el proyecto COSAiS del NIST, relacionado con este, está desarrollando superestructuras de control según la norma SP 800-53 para garantizar la seguridad de los sistemas de IA de un solo agente y de múltiples agentes (NIST COSAiS). Dado que estas cifras y normas están evolucionando rápidamente, es de esperar que cambien en un plazo aproximado de seis meses, por lo que conviene indicar la fecha en cualquier afirmación que se vuelva a utilizar.

Enfoques modernos de la observabilidad de la seguridad

La observabilidad de la seguridad, en su fase madura, pasa de la simple supervisión a la detección correlacionada, de alta cardinalidad y asistida por IA, integrándose con la pila existente, en lugar de sustituirla. Saber hacia dónde se dirige esta disciplina ayuda a los equipos a planificar una estrategia realista.

Los retos habituales de implementación son siempre los mismos: la facturación basada en la ingesta encarece la recopilación a gran escala, los entornos cloud crean puntos ciegos y la sobrecarga de falsos positivos abruma a los analistas; el 73 % de los profesionales citó los falsos positivos como su principal reto de detección en la encuesta de SANS de 2025 (cobertura de la encuesta de SANS). Las mejores prácticas, independientes del proveedor, que abordan estos retos son igualmente constantes: empezar con una estrategia deliberada de recopilación de datos y unas bases de referencia claras antes de buscar herramientas; prepararse para una alta cardinalidad, de modo que las preguntas arbitrarias sigan teniendo respuesta; e integrar con el SIEM y la pila de terminales existentes en lugar de sustituir todo por completo, tratando la observabilidad como la capa analítica sobre la telemetría unificada. Si la siguiente pregunta del lector se refiere a la economía de la implementación o a la postura de seguridad, estas cuestiones pertenecen a disciplinas adyacentes: la gestión de la postura de seguridad en el caso de la postura, y los modelos de implementación en el caso de la disyuntiva entre «construir» o «comprar».

En materia de cumplimiento normativo, el registro exhaustivo y la detección se ajustan perfectamente a los marcos reconocidos: las funciones del Marco de Ciberseguridad del NIST 2.0 (NIST CSF 2.0), entre las que se incluyen DETECT (DE.CM: supervisión continua y DE.AE: análisis de incidentes adversos), RESPOND e IDENTIFY, mientras que el RGPD, la HIPAA, la norma PCI DSS, la ley SOX y la NIS2 establecen los requisitos de registro y conservación de registros de auditoría (Marco de Ciberseguridad del NIST). Se trata de una referencia, no de un catálogo: la taxonomía completa del marco se encuentra en la sección de marcos de seguridad.

Una escala de madurez de la observabilidad de la seguridad

Los equipos pueden situarse en una sencilla escala de cinco niveles, que sirve también para medir los avances en materia de observabilidad de la seguridad:

1. Supervisión: alertas predefinidas sobre señales conocidas.
2. Registro centralizado: telemetría agregada en un único lugar.
3. Telemetría correlacionada: señales combinadas procedentes de distintas fuentes de datos.
4. Observabilidad exploratoria de alta cardinalidad: consultas arbitrarias a gran escala.
5. Observabilidad basada en la detección como código y asistida por IA: detección automatizada con control de versiones.

Cómo Vectra AI la observabilidad de la seguridad

Vectra AI la observabilidad es la base de la resiliencia: la combinación de observabilidad, señal y acción. Esto implica una cobertura de toda la superficie de ataque moderna, de modo que la actividad de los atacantes no tenga dónde esconderse; una señal basada en la inteligencia artificial que priorice los ataques reales frente al ruido; y una acción fundamentada que convierta los hallazgos en una respuesta. Se hace hincapié en la metodología, no en las herramientas: una telemetría exhaustiva solo genera resiliencia cuando la señal que produce es lo suficientemente clara como para actuar con confianza.