Telemetría de seguridad: la capa de datos sobre la que se basa cada detección

La telemetría de seguridad consiste en la recopilación y transmisión continuas y automatizadas de datos relevantes para la seguridad (registros, eventos, métricas, rastros, flujos y metadatos) desde los terminales, las redes, cloud , las identidades y las aplicaciones hasta los sistemas que los analizan. Es la materia prima sobre la que se basa toda detección, búsqueda, investigación y reconstrucción forense.

Esa capa de datos se ha convertido en un problema de diseño de primer orden. Los volúmenes no dejan de aumentar, los atacantes se centran deliberadamente en las brechas y los organismos reguladores están redefiniendo qué datos deben recopilarse y conservarse. Esta guía explica los tipos y las fuentes de la telemetría de seguridad, cómo funcionan la recopilación y la normalización, de dónde proceden los puntos ciegos, cuál es el coste de conservar los datos y cómo los marcos normativos, desde MITRE ATT&CK hasta la norma OMB M-26-14, definen los requisitos.

¿Qué es la telemetría de seguridad?

La telemetría de seguridad es más un resultado que un producto: el flujo de señales que emiten los terminales, los sensores de red, cloud , los proveedores de identidad y las aplicaciones mientras funcionan. Una vez recopilado y correlacionado, ese flujo se convierte en la base de pruebas para la detección de amenazas y constituye el pilar fundamental de todo lo que viene a continuación, ya que lo que nunca se ha recopilado nunca se puede consultar. Las disciplinas de consulta e investigación que se desarrollan sobre esta capa de datos, incluida la observabilidad de la seguridad, se tratan en sus propias páginas.

¿Por qué es importante la telemetría de seguridad?

Porque las intrusiones modernas traspasan los dominios y las pruebas rara vez se encuentran en un solo lugar. Un atacante puede suplantar una identidad, desplazarse por la red y almacenar datos en un cloud en el transcurso de un único incidente. La telemetría de un solo dominio resulta estructuralmente insuficiente para esa realidad, y las cifras indican que los casos multidominio son ahora la norma.

La prueba más sólida es el Informe de Investigaciones sobre Fugas de Datos (DBIR) de Verizon de 2026, que abarca los incidentes ocurridos entre el 1 de noviembre de 2024 y el 31 de octubre de 2025. La 19.ª edición se publicó el 19 de mayo de 2026 (comunicado de prensa del DBIR de 2026) y se basa en más de 31 000 incidentes y más de 22 000 filtraciones confirmadas en 145 países (resumen ejecutivo del DBIR de 2026).

Dentro de ese conjunto de datos, el patrón de «intrusión en el sistema» en varias fases apareció en el 61 % de las infracciones, frente al 53 % y el 36 % de las dos ediciones anteriores, y el ransomware alcanzó el 48 % de las infracciones, frente al 44 % (resumen ejecutivo del DBIR de 2026). Los ataques que afectan a varios dominios dejan sus rastros en varias fuentes de telemetría, o bien no dejan rastro alguno. Ese es el argumento principal para tratar la telemetría como un conjunto de fuentes, en lugar de como una única fuente.

¿Cuál es la diferencia entre telemetría, registro de datos, supervisión y observabilidad?

Empecemos por el aspecto sobre el que los expertos discrepan realmente. Algunas fuentes consideran la telemetría como un flujo en tiempo real y el registro como un mantenimiento de registros a posteriori, dos conceptos relacionados pero distintos. Otras consideran los registros como una de las múltiples formas que puede adoptar la telemetría. La tendencia en este campo se inclina hacia esta segunda interpretación, más amplia: la telemetría abarca métricas, eventos, registros y trazas, y el registro es la práctica que genera una de esas formas. Esta página sigue esta interpretación más amplia y señala el debate allí donde es relevante.

La supervisión y la observabilidad se sitúan por encima de los datos, en lugar de dentro de ellos. La supervisión de la seguridad consiste en la práctica continua de vigilar señales conocidas para detectar condiciones de ataque y fallo conocidas, y la supervisión de la ciberseguridad amplía esa práctica a todo el entorno. La observabilidad describe lo que un equipo puede hacer con la capa de datos: plantear nuevas preguntas sin necesidad de implementar primero nuevos instrumentos de medición. La telemetría es la materia prima que consumen las tres, tal y como se resume en la tabla siguiente.

La telemetría es la capa de datos, el registro de datos constituye una de sus manifestaciones, y la supervisión y la observabilidad son prácticas que se basan en ella.

Tipos y fuentes de telemetría de seguridad

La telemetría de seguridad adopta cuatro formas habituales y procede de al menos cinco ámbitos. Ninguna forma ni ámbito por sí solo permite vislumbrar un ataque en su totalidad, por lo que la planificación de la cobertura comienza con un mapa de lo que cada fuente puede y no puede mostrar.

La taxonomía MELT

El acrónimo que se utiliza en el sector para referirse a los tipos de datos de telemetría es MELT: métricas, eventos, registros y trazas.

• Las métricas son mediciones numéricas obtenidas a lo largo del tiempo, como los fallos de autenticación por minuto en un concentrador de VPN. Son compactas y su almacenamiento resulta económico, lo que las hace idóneas para establecer valores de referencia y detectar tendencias.
• Los eventos son registros independientes de algo que ocurre en un momento determinado, como el inicio de un proceso o el bloqueo de una conexión por parte de un cortafuegos. La mayor parte de la lógica de detección se basa en los eventos.
• Los registros son entradas con marca de tiempo generadas por los sistemas operativos, las aplicaciones y los servicios, desde los registros de eventos de Windows hasta los registros cloud . Contienen el contexto más completo y suponen el mayor gasto en almacenamiento.
• Los rastros siguen el recorrido de una única solicitud o transacción a través de servicios distribuidos. En el ámbito de la seguridad, ayudan a reconstruir cómo se propagó una acción a través de los sistemas conectados.

Telemetría por dominio

• Telemetría de terminales y EDR. Inicio de procesos, cambios en archivos y en el registro, carga de módulos y actividad de scripts captados por los agentes del host. Se trata de la visión más completa del comportamiento en el host, y solo está disponible cuando hay un agente instalado y en ejecución.
• Telemetría de red. Registros de flujo, como NetFlow e IPFIX, consultas DNS y atributos del protocolo de enlace TLS, que suelen extraerse como metadatos en lugar de paquetes completos. Dado que los sensores se instalan en puntos de derivación y puertos de duplicación en lugar de en los propios hosts, el análisis del tráfico de red detecta dispositivos no gestionados y transitorios que las herramientas basadas en agentes no pueden detectar.
• Cloud . Registros de auditoría del plano de control, registros de flujos y señales de cargas de trabajo procedentes de la infraestructura y las plataformas SaaS. Se trata del sistema de registro para cloud , con una salvedad que se explicará más adelante: los proveedores filtran o muestrean algunos tipos de registros de forma predeterminada.
• Telemetría de identidades. Registros de inicio de sesión y de auditoría procedentes de directorios, proveedores de identidades, aplicaciones SaaS, gestión de accesos privilegiados y servicios de federación. La cobertura debe extenderse a las identidades no humanas, incluidas las cuentas de servicio, las claves API y los agentes de IA, ya que constituyen la base de datos sobre la que se asienta la detección y respuesta ante amenazas relacionadas con las identidades.
• Telemetría XDR y MDR. Las plataformas XDR correlacionan la telemetría de varios dominios para generar detecciones unificadas, mientras que los proveedores de MDR ejecutan su servicio de detección a partir de cualquier tipo de telemetría que genere el entorno del cliente. Ambos utilizan los dominios mencionados anteriormente, en lugar de añadir uno nuevo.

Los datos de alertas e inspecciones completan el panorama. Los cortafuegos y los sistemas de detección y prevención de intrusiones emiten sus propios veredictos y detecciones, y siguen siendo fuentes fundamentales para la seguridad de la red, aunque se limiten a observar el comportamiento en lugar de reconstruirlo.

Hay un aspecto que es realmente nuevo. El DBIR de 2026 reveló que el 45 % de los empleados utilizan habitualmente la IA en los dispositivos de la empresa, lo que supone un aumento respecto al 15 % del año anterior (resumen ejecutivo del DBIR de 2026). Como consecuencia, los datos de uso de navegadores y herramientas de IA se están convirtiendo en una fuente de información de primer orden, ya que el uso no autorizado de la IA se concentra precisamente donde los agentes tradicionales prestan menos atención.

Cinco ámbitos de telemetría, lo que revela cada uno de forma específica y las lagunas de cobertura que deja cada uno cuando se utiliza por separado.

Cómo funciona la telemetría de seguridad

Las señales sin procesar se convierten en datos de telemetría utilizables a través de un proceso que incluye las siguientes etapas: recopilación, transmisión, normalización, enrutamiento, almacenamiento y análisis. Cada etapa supone una decisión de diseño, y varias de ellas constituyen por sí mismas superficies de ataque.

La recopilación se lleva a cabo a través de agentes en los hosts, sensores en puntos de conexión de red y puertos espejo, consultas mediante API a plataformas cloud SaaS, y exportadores de streaming integrados en el software moderno. La recopilación basada en puntos de conexión destaca por ser pasiva: un sensor que observa un puerto espejo no necesita que se instale nada en el terminal, lo que proporciona a los defensores un canal al que los atacantes no pueden acceder fácilmente desde un host comprometido. A continuación, la transmisión envía los datos hacia el análisis mediante procesamiento por lotes, almacenamiento en búfer y contrapresión, de modo que los picos de tráfico no provoquen la pérdida silenciosa de eventos.

En su totalidad, el proceso es el siguiente:

1. Fuentes de instrumentos con agentes, sensores, exportadores e integraciones de API.
2. Recopila eventos, métricas, registros y rastros de forma continua.
3. Transmisión con controles de procesamiento por lotes, almacenamiento en búfer y contrapresión.
4. Normaliza todo en un único esquema compartido.
5. Dirige cada flujo hacia el análisis, el almacenamiento o ambos.
6. Guárdalos por niveles: muy caliente, caliente y frío.
7. Analizar con fines de detección, investigación y búsqueda.

‍

La normalización es lo que permite combinar los datos de telemetría de diferentes proveedores. El Open Cybersecurity Schema Framework (OCSF) proporciona a los eventos de seguridad una estructura compartida e independiente del proveedor. OpenTelemetry estandariza la forma en que se instrumenta el software y cómo se exportan sus métricas, registros y trazas, y el proyecto ofrece directrices de seguridad específicas para reforzar la seguridad de sus componentes de recopilación. El Elastic Common Schema (ECS) y el Common Information Model (CIM) persiguen el mismo objetivo dentro de sus propios ecosistemas. Los cuatro son características del aspecto que adoptan los datos una vez normalizados, no herramientas de análisis.

Desde allí, los datos llegan a un nivel de análisis. Un SIEM correlaciona la telemetría normalizada con reglas y modelos de comportamiento para generar alertas, y esta página se detiene justo en su puerta de entrada. La práctica de consultas e investigaciones abiertas que se lleva a cabo en la misma capa de datos pertenece a la disciplina de la observabilidad, que es la responsable de esa labor.

La propia medición de la telemetría garantiza la fiabilidad del proceso. Hay cuatro indicadores clave: la cobertura, es decir, qué técnicas del marco de detección pueden demostrar tus fuentes; el volumen de datos procesados y su coste; la latencia desde la generación del evento hasta su análisis; y la integridad, es decir, que los flujos de datos lleguen sin lagunas ni pérdidas silenciosas. Unos resultados deficientes en cualquiera de estos cuatro indicadores se manifestarán más adelante como puntos ciegos. Haz un seguimiento de ellos por fuente, no como una media global.

La telemetría de seguridad en la práctica

Tres casos, repartidos a lo largo de 13 años, ilustran la diferencia entre que la telemetría exista, que sea completa y que se actúe en consecuencia. Cada uno de ellos muestra también por qué los analistas consideran la telemetría como una prueba: debe existir, abarcar el ámbito adecuado y llegar a alguien o algo que actúe.

• Hugging Face (2026): se actuó en base a los datos de telemetría. La empresa informó de que su «proceso de detección de anomalías utiliza una clasificación basada en modelos de lenguaje grande (LLM) sobre los datos de telemetría de seguridad para separar las señales reales del ruido diario, y fue la correlación de esas señales lo que alertó de la intrusión» (comunicado de Hugging Face). El informe ha sido facilitado por la propia parte afectada y no especifica la cronología de la intrusión. Se dio a conocer el 16 de julio de 2026 y recibió una amplia cobertura neutral el 20 de julio (Help Net Security). Los informes confirmaron el impacto en conjuntos de datos internos y credenciales (TechCrunch).
• SolarWinds SUNBURST (2020): telemetría incompleta. El implante en la cadena de suministro, revelado públicamente el 13 de diciembre de 2020, camufló su tráfico de comando y control como telemetría legítima del producto y eludió los controles de los terminales (análisis de Mandiant sobre SUNBURST). La telemetría limitada a los terminales puede pasar por alto la actividad que se transmite a través de canales de confianza.
• Target (2013): se ignoró la telemetría. Un informe del personal de la Comisión de Comercio del Senado de EE. UU., con fecha del 26 de marzo de 2014, reveló que Target parece no haber respondido a múltiples alertas automáticas del software antiintrusión de la empresa mientras los atacantes instalaban malware, antes de que los datos salieran de la red (análisis «Kill Chain» del Senado). La capacidad de detección sin clasificación no es detección.

El tiempo de permanencia mide la repercusión, y está evolucionando en la dirección equivocada. El informe «M-Trends 2026», que abarca el año natural 2025 y más de 500 000 horas dedicadas a la respuesta a incidentes, reveló que la mediana mundial del tiempo de permanencia aumentó de 11 a 14 días, mientras que los incidentes relacionados con el ciberespionaje y los trabajadores de TI norcoreanos registraron una mediana de 122 días (M-Trends 2026). La edición anterior, M-Trends 2025, que abarca el año natural 2024, es la fuente de esa referencia de 11 días. Para reducir esta diferencia, no se trata tanto de disponer de más datos brutos como de contar con una cobertura que alimente la búsqueda de amenazas entre alertas y una disciplina de triaje que convierta las señales en una respuesta a incidentes antes de que el tiempo de permanencia se agrave.

Los puntos ciegos de la telemetría y cómo los aprovechan los atacantes

No se puede detectar lo que nunca se ha registrado. Los puntos ciegos se presentan en dos modos de fallo categóricamente diferentes: las lagunas de cobertura, en las que el evento nunca se produce, y la manipulación, en la que se produce y luego se suprime. Ambos factores agravan la sobrecarga de alertas: los equipos del SOC reciben más alertas de las que pueden clasificar, y la fatiga por alertas oculta las escasas señales de los atacantes bajo un volumen mucho mayor que describe las operaciones normales. El DBIR de 2026 muestra el coste de una resolución lenta: el tiempo medio hasta la resolución completa alcanzó los 43 días, y solo el 26 % de las vulnerabilidades críticas de la lista de «Vulnerabilidades explotadas conocidas» de la CISA se corrigieron por completo, lo que supone un descenso respecto al 38 % (resumen ejecutivo del DBIR de 2026).

Lagunas en la cobertura: nunca se elaboran los datos

Los dispositivos no gestionados, de perímetro, de IoT y de tecnología operativa (OT) no ejecutan agentes, por lo que no existe telemetría de host procedente de ellos. El DBIR de 2026, que abarca los incidentes hasta octubre de 2025, reveló que el aprovechamiento de vulnerabilidades aumentó hasta el 31 % de las infracciones, lo que lo convierte en el vector de acceso inicial más común (resumen ejecutivo del DBIR de 2026). El DBIR de 2025 ya había atribuido el 22 % de las acciones de explotación de vulnerabilidades a dispositivos periféricos y VPN (DBIR de 2025). El filtrado y el muestreo por parte de los proveedores crean el mismo tipo de laguna en cloud .

La telemetría de identidad también falla de forma silenciosa. Una investigación sobre amenazas realizada por un proveedor y publicada en julio de 2026 describió la suplantación de la identificación de cliente OAuth en entornos de Entra ID: una identificación de cliente suplantada deja en blanco el campo del nombre de la aplicación, por lo que los sistemas de detección configurados para una aplicación concreta pueden pasar por alto por completo dicha actividad (Help Net Security). Una campaña rastreada desde diciembre de 2025 utilizó más de 3,7 millones de identificadores de aplicación falsificados contra más de dos millones de cuentas de usuario, comprobando la validez de las credenciales «sin generar un evento de inicio de sesión satisfactorio» (The Hacker News). Ningún identificador de técnica de ATT&CK cubre este comportamiento: se trata de una laguna de cobertura, no de una manipulación, ya que nunca se documentó nada al respecto.

Manipulación: los datos se generan y, a continuación, se ocultan

Cuando se genera telemetría, los atacantes la ocultan. El catálogo MITRE ATT&CK lo clasifica como T1685 Desactivar o modificar herramientas en el marco de la táctica de «Deterioro de la defensa» (TA0112): los adversarios desactivan o modifican el propio software defensivo, incluidas las herramientas EDR, los sistemas de detección de intrusiones (IDS), los antivirus y los agentes y sensores de registro; la carrera armamentística contemplada en Elusión del EDR. Las seis subtécnicas se centran en el registro o en la visión que tiene el analista del mismo: desactivar o modificar el registro de eventos de Windows, cloud o el registro del sistema de auditoría de Linux; modificar o falsificar la interfaz de usuario de una herramienta; y borrar los registros de eventos de Windows o los registros del sistema de Linux y Mac.

La presión es real. Un informe sobre amenazas del sector correspondiente a 2025 reveló que aproximadamente el 82 % de las detecciones malware contenían malware, y que la incursión más rápida registrada duró unos 27 segundos. Los intrusos que actúan con esa rapidez utilizando credenciales y herramientas legítimas tienen todos los motivos para silenciar la telemetría del host.

La capa de recopilación es, en sí misma, un programa informático

La capa de recopilación también es software. Dos vulnerabilidades de OpenTelemetry de 2026, CVE-2026-40182, una respuesta sin límites detectada en la implementación de .NET que puede agotar la memoria (NIST CVSS 5.9), y CVE-2026-45287, una fuga de descriptores de archivos en OpenTelemetry-Go que puede provocar una denegación de servicio, son problemas tanto de disponibilidad como de agotamiento de recursos. Un colector que se bloquea bloquea todo el flujo posterior. Las puntuaciones de este segundo caso también muestran por qué la clasificación basada en una única puntuación es poco fiable: el NIST le otorgó una puntuación de 5,5 según el CVSS 3.1, mientras que la Autoridad de Numeración CVE le otorgó una puntuación de 2,1 según el CVSS 4.0, por lo que el mismo fallo se interpreta de forma muy diferente según la fuente de información.

Todas las fuentes de compensación que figuran en la tabla siguiente comparten una característica: su independencia respecto al host afectado. Cuando los agentes están ausentes, desactivados o mienten, la telemetría de red procedente de los puntos de escucha y los espejos constituye el registro que los intrusos no pueden silenciar, lo que constituye el argumento fundamental a favor de la visibilidad de la red y de los sistemas de detección y respuesta.

Cinco puntos ciegos habituales en la telemetría, el modo de fallo que se esconde tras cada uno de ellos y la fuente de compensación que restaura la visibilidad.

Los aspectos económicos de la telemetría de seguridad

El crecimiento de la telemetría se ha convertido en una partida presupuestaria con consecuencias para la seguridad. El informe «Telemetry Trends» de Cribl reveló que los datos básicos (syslog, TCP y TCP JSON) se incrementaron en más de un 60 % interanual durante el periodo comprendido entre abril de 2024 y abril de 2025 (Cribl Telemetry Trends). Los precios de los servicios de análisis suelen fijarse por gigabyte procesado, por lo que este crecimiento repercute directamente en el presupuesto operativo del SOC. La presión de los costes se convierte entonces en un problema de seguridad encubierto: los equipos que eliminan fuentes de forma indiscriminada para ahorrar dinero están creando un punto ciego, no un ahorro.

La respuesta que está surgiendo es una capa de canalización de telemetría. La Guía de mercado de Gartner sobre canalizaciones de telemetría, publicada el 2 de septiembre de 2025, prevé que «para 2027, el 40 % de toda la telemetría de registros se procesará a través de un producto de canalización de telemetría, frente a menos del 20 % en 2024» (Guía de mercado de Gartner sobre canalizaciones de telemetría). Un canal se sitúa entre los productores y los destinos para ingestar, procesar y enrutar: filtrando el ruido, enriqueciendo los registros, remodelando los esquemas y clasificando cada flujo antes de que nada llegue al nivel de análisis.

Ese nivel de análisis suele ser un SIEM, y la ingesta de datos del SIEM por gigabyte es la partida presupuestaria que las canalizaciones deben proteger. A modo de contexto orientativo del mercado, el análisis de mercado sobre SIEM realizado por el agregador sindicado Mordor Intelligence estima que el mercado alcanzará los 12 060 millones de dólares en 2026 y los 20 780 millones de dólares en 2031, con una tasa de crecimiento anual compuesta del 11,50 %. El mismo análisis afirma, basándose en su propia evaluación y sin datos primarios independientes, que las organizaciones con más de 10 000 empleados ingieren más de 10 terabytes de datos de registro cada día. Ambos datos deben considerarse más bien como indicaciones orientativas que como medidas precisas.

La clasificación por niveles de retención es la otra mitad del control de costes. Mantén los datos de detección en tiempo real en el nivel «caliente», los de investigación en el nivel «tibio» y los de cumplimiento normativo en el nivel «frío», y separa el almacenamiento del motor de análisis para que se pueda seguir consultando el historial sin tener que pagar las tarifas del nivel «caliente».

La retención por niveles asigna a cada uso de telemetría una clase de almacenamiento, de modo que se mantiene la cobertura sin tener que aplicar las tarifas del nivel «hot» a todo.

La estrategia que lo aglutina todo es el registro con un objetivo claro: definir primero los objetivos de detección, asignarlos a la telemetría que requieren dichas detecciones y, a continuación, reducir o eliminar todo lo demás. Las orientaciones prácticas, como la guía de estrategia de telemetría de Security Blue Team, enmarcan esta misma disciplina: cada decisión de recopilación debe estar vinculada a un objetivo de detección o investigación, y no a una mera costumbre.

Telemetría de seguridad, marcos de trabajo y cumplimiento normativo

Los requisitos de telemetría provienen cada vez más de los marcos normativos y los organismos reguladores, y el año 2026 marca un nuevo punto de referencia en dos aspectos clave.

Correspondencia de los datos de telemetría con el modelo MITRE ATT&CK

Mapeo de telemetría en el interior MITRE ATT&CK cambió dos veces en seis meses. La versión 18, lanzada el 28 de octubre de 2025, dejó de utilizar el componente heredado «Fuentes de datos» para sustituirlo por las estrategias de detección (DET) y el análisis (AN) (Notas de la versión de MITRE ATT&CK de 2025). La versión 19, publicada el 28 de abril de 2026, dividió «Evasión de defensa» en «Sigilo» (TA0005) y «Deterioro de la defensa» (TA0112) (Notas de la versión de MITRE ATT&CK de 2026). Identificadores de fuentes de datos heredadas, como DS0029, DS0038y DS0002 siguen apareciendo en los contenidos destinados a los profesionales, pero se trata de identificadores históricos de un modelo obsoleto, no de directrices actuales. Para ingeniería de detección En los equipos, la elaboración de mapas de cobertura comienza ahora por las estrategias de detección y los análisis que las componen, cada uno de los cuales especifica la telemetría que necesita.

La norma M-26-14 de la OMB y el reajuste federal de la tala para 2026

El Memorándum M-26-14 de la OMB, con fecha del 22 de mayo de 2026, establece: «Con efecto inmediato, queda derogado el Memorándum M-21-31 de la OMB». La priorización basada en el riesgo sustituye al registro de todo, y se articula en torno a dos objetivos: la supervisión continua de eventos (CEM) y la búsqueda de amenazas, la investigación, la respuesta y el análisis forense (THIRF). El modelo de madurez cuenta con cinco niveles, desde el Nivel 0 (Ineficaz) hasta el Nivel 4 (Óptimo), y el propio memorándum denomina el Nivel 1 de forma inconsistente: «Básico» en su tabla de plazos de cumplimiento e «Inicial» en el Apéndice C. El ámbito de aplicación abarca los sistemas civiles federales de EE. UU., incluyendo explícitamente el IoT y la OT, y excluye los sistemas de seguridad nacional, del Departamento de Defensa y de la comunidad de inteligencia.

El memorándum encarga a la CISA la elaboración de una Arquitectura de Referencia de Registro (LRA) que, a fecha de 20 de julio de 2026, aún no se ha publicado. La página de recursos de la CISA es un espacio reservado con fecha del 26 de mayo de 2026, en el que se indica que se actualizará cuando la LRA esté terminada y que el plazo de 90 días expire alrededor del 20 de agosto de 2026.

‍

Normas y factores que influyen en la retención

La norma NIST SP 800-92, la guía fundamental sobre gestión de registros, data de septiembre de 2006, y el borrador de su Revisión 1 cerró el plazo de comentarios públicos el 29 de noviembre de 2023 sin llegar a formalizarse, por lo que la versión original de 2006 sigue siendo la referencia oficial. El NIST CSF 2.0 enmarca la telemetría en su función «Detectar», dentro de la categoría «Supervisión continua» (DE.CM). OWASP renombró la norma A09:2021 «Fallos en el registro y la supervisión de seguridad» como A09:2025 «Fallos en el registro y las alertas de seguridad», manteniéndola en el puesto n.º 9. El Modelo Zero Trust de la CISA señala la «Visibilidad y el análisis» como una de sus capacidades transversales.

Las obligaciones de conservación se derivan de un conjunto más amplio de normas. Las normas PCI DSS, RGPD, NIS2, HIPAA y SOC 2 determinan el periodo durante el que se conservan los datos de telemetría, y la elaboración de informes de cumplimiento agota los niveles de archivo, lo que nos recuerda que la norma M-26-14 es una política federal de EE. UU., mientras que estas normas tienen alcance mundial.

Cómo se hace referencia a la telemetría de seguridad en los principales marcos normativos y reglamentos, con la versión o el estado de cada uno de ellos a fecha de julio de 2026.

Enfoques modernos de la telemetría de seguridad

La tendencia es contar con menos señales, pero de mayor calidad, procedentes de una cobertura más amplia. Cuatro medidas definen el enfoque moderno: arquitecturas que dan prioridad a los canales de datos y que filtran y redirigen la información antes de llegar al nivel de análisis; esquemas de normalización abiertos que permiten combinar y transferir los datos; almacenamiento desacoplado que mantiene el historial a un coste asequible; y una clasificación asistida por IA que trabaja directamente con la telemetría en lugar de añadir otro flujo de alertas. Para los equipos de operaciones del SOC, la prueba de eficacia de cualquiera de ellas es si se reduce la distancia entre la señal sin procesar y una decisión fiable.

El nuevo ámbito de la telemetría es la propia IA. El DBIR de 2026 clasificó el uso de la «IA en la sombra» como la tercera acción interna no maliciosa más habitual en su conjunto de datos sobre prevención de pérdida de datos (resumen ejecutivo del DBIR de 2026), y los agentes de IA y otras identidades no humanas se están convirtiendo en productores y consumidores de telemetría de primer orden. Los planes de cobertura que se limitan a los usuarios humanos y a los hosts gestionados ya se han quedado obsoletos.

Cómo Vectra AI la telemetría de seguridad

Vectra AI de la premisa de que la seguridad está comprometida: los atacantes con los medios necesarios lograrán colarse, por lo que la cuestión fundamental es con qué rapidez su comportamiento se refleja en los datos. La amplitud de la telemetría en las redes modernas —que abarca el campus, el centro de datos, cloud y la identidad— es necesaria, pero no suficiente. Lo que realmente importa es convertir esa amplitud en un número reducido de señales de ataque de alta fidelidad sobre las que un analista pueda actuar con confianza.

‍