Seguridad para infraestructura de IA: el nuevo reto que pocas organizaciones tienen resuelto.

Ciberseguridad para inteligencia artificial: el nuevo reto que pocas organizaciones tienen resuelto

Durante años, la inteligencia artificial fue un tema de laboratorio. Algo que las empresas exploraban en proyectos piloto, en entornos controlados, con equipos pequeños y expectativas cautelosas. Ese momento ya pasó.

Hoy la IA opera en producción. Toma decisiones, procesa datos sensibles, interactúa con usuarios, ejecuta tareas de forma autónoma y se conecta con sistemas críticos del negocio. Y con ese salto de la experimentación a la operación industrial, apareció un problema que muchas organizaciones todavía no tienen resuelto: la seguridad para infraestructura de IA no funciona igual que la seguridad tradicional.

Cuando la IA se vuelve infraestructura crítica.

Existe un concepto que está tomando fuerza en la industria tecnológica global: las AI Factories. No son fábricas en el sentido físico, sino infraestructuras de alto rendimiento diseñadas específicamente para producir inteligencia a escala. Procesan enormes volúmenes de datos, entrenan modelos, ejecutan agentes autónomos y sostienen las operaciones de IA de las organizaciones más avanzadas del mundo.

NVIDIA, uno de los líderes globales en infraestructura de cómputo para inteligencia artificial, ha sido uno de los principales impulsores de este concepto. Su arquitectura BlueField, diseñada para procesar y proteger datos directamente desde el hardware, representa un salto importante en cómo se piensa la seguridad para infraestructura de IA desde la capa más profunda del sistema.

Lo relevante para cualquier organización en LATAM no es la escala de esas infraestructuras globales. Es entender qué implica este cambio para la forma en que se debe pensar la seguridad cuando la IA ya no es un proyecto sino parte de la operación.

El problema que la seguridad tradicional no resuelve.

La seguridad tradicional fue diseñada para proteger redes, dispositivos y aplicaciones. Funciona bien en entornos que se pueden definir con claridad, donde los activos son estables y las amenazas siguen patrones conocidos.

La seguridad para infraestructura de IA enfrenta un escenario completamente distinto. Los agentes autónomos toman decisiones sin intervención humana. Los modelos de IA procesan datos que pueden ser manipulados antes de llegar a ellos. Las APIs que conectan sistemas entre sí se multiplican y crean superficies de ataque que crecen más rápido de lo que los equipos de seguridad pueden monitorear.

En ese entorno, los enfoques reactivos no son suficientes. Detectar una amenaza después de que ocurrió dentro de una infraestructura de IA puede significar que un agente ya tomó decisiones incorrectas, que datos sensibles ya fueron comprometidos o que un modelo ya fue manipulado de formas que no son inmediatamente visibles.

La seguridad para infraestructura de IA requiere visibilidad en tiempo real, protección desde el hardware y capacidad de actuar antes de que la amenaza se materialice.

Cinco capas que toda infraestructura de IA necesita proteger.

Cuando se habla de seguridad para infraestructura de IA, el alcance es más amplio de lo que parece a primera vista. No se trata solo de proteger el modelo o la aplicación que el usuario final ve. Se trata de asegurar todo el ciclo de vida de la inteligencia artificial dentro de la organización.

La primera capa es la seguridad del modelo en sí mismo, antes de que entre en producción. Un modelo que fue manipulado durante su entrenamiento puede tomar decisiones incorrectas de forma sistemática sin que nadie lo note.

La segunda es la protección en tiempo de ejecución. Cuando el modelo ya está operando, las amenazas más comunes son la inyección de instrucciones maliciosas, la extracción de datos a través de las respuestas del modelo y el abuso de las capacidades del sistema.

La tercera es la seguridad de los agentes autónomos. A diferencia de las aplicaciones tradicionales, los agentes de IA toman acciones, no solo responden. Eso implica que cada agente necesita una identidad gobernada, permisos precisos y trazabilidad de sus acciones.

La cuarta es la protección de las APIs que conectan los sistemas de IA con el resto de la organización. Cada conexión es una puerta que puede ser explotada si no está bien controlada.

La quinta es la visibilidad sobre toda la infraestructura. Sin datos en tiempo real sobre lo que está ocurriendo en cada capa del sistema, los equipos de seguridad operan a ciegas.

Lo que Palo Alto Networks está haciendo en este espacio.

Recientemente, Palo Alto Networks anunció la integración de su plataforma Cortex XSIAM con el framework NVIDIA DOCA Argus, lo que lleva la seguridad para infraestructura de IA directamente al nivel del hardware. Esto significa que la detección de amenazas ocurre en tiempo real desde la capa más profunda del sistema, sin depender de agentes instalados en el host y sin sacrificar el rendimiento de la infraestructura.

Lo que esto implica para las organizaciones en LATAM.

La mayoría de las organizaciones en la región no están operando AI Factories a la escala de los grandes corporativos globales. Pero sí están adoptando herramientas de IA en su operación, integrando agentes en sus procesos, conectando modelos con sus sistemas de negocio y procesando datos sensibles a través de plataformas de inteligencia artificial.

Ese escenario, aunque más pequeño en escala, presenta los mismos riesgos estructurales. Un agente de IA sin identidad gobernada es una amenaza, independientemente del tamaño de la organización. Una API sin control de acceso es una vulnerabilidad, sin importar si la empresa tiene diez servidores o diez mil.

La pregunta que cualquier CISO debería hacerse hoy es, ¿cuánto de su infraestructura de IA actual tiene visibilidad, control y protección real? No como proyecto futuro, sino como operación presente.

La seguridad para infraestructura de IA no es un tema para el año que viene. Es una conversación que las organizaciones que ya adoptaron IA en producción necesitan tener ahora.

Para mantenerte informado y protegido, sigue las redes sociales de Nova en: Instagram,  Facebook y LinkedIn, donde puedes encontrar más noticias y conocer las soluciones en ciberseguridad que ofrecemos.

#NovaInforma

Ciberseguridad sin claridad: el problema que ninguna herramienta resuelve sola.

Modelo CROC de Nova para gestión de riesgo cibernético en empresas

Hay una conversación que ocurre con frecuencia en las salas de consejo de empresas en América Latina. Alguien pregunta: ¿qué tan expuestos estamos hoy ante un ciberataque? Y la respuesta, casi siempre, es una combinación de datos técnicos, nombres de herramientas y porcentajes que no le dicen nada concreto a quien toma las decisiones.

No es un problema de tecnología. Es un problema de traducción.

Muchas herramientas, poca claridad

La mayoría de las organizaciones medianas y grandes en la región ya tienen inversiones significativas en ciberseguridad. Tienen soluciones de detección, gestión de vulnerabilidades, protección en la nube y monitoreo de red. El problema no es la ausencia de herramientas. Es que todas esas herramientas generan señales que viven en silos, que hablan lenguajes distintos y que no se traducen en una respuesta clara a la pregunta más importante: ¿cuánto riesgo real tiene mi organización hoy?

Cuando un director general o un CFO no puede responder esa pregunta con certeza, la ciberseguridad deja de ser una función estratégica y se convierte en un gasto difícil de justificar. Las inversiones se hacen por intuición, no por evidencia. Las prioridades se definen por urgencia, no por impacto. Y los equipos de seguridad operan en modo reactivo, atendiendo alertas sin contexto, sin saber cuáles realmente importan.

Ese es el problema estructural que CROC resuelve.

De alertas a decisiones: qué es el modelo CROC

El Nova CROC, Cyber Risk Operations Center, es un modelo estratégico desarrollado por Nova para gestionar el riesgo cibernético de forma continua, proactiva y conectada al impacto del negocio. No es una herramienta. No es un software. Es un modelo operativo que cambia la forma en que una organización entiende, mide y actúa sobre su exposición al riesgo.

La diferencia con el enfoque tradicional es de fondo. La ciberseguridad convencional está centrada en alertas e incidentes. CROC está centrado en exposición y decisiones. No se trata de saber cuántos eventos de seguridad ocurrieron esta semana. Se trata de saber qué activos críticos están expuestos hoy, qué tan probable es que sean explotados y cuánto le costaría a la organización si eso ocurriera.

Ese cambio de perspectiva transforma completamente la conversación entre el área de seguridad y la dirección general.

El índice de riesgo cibernético: un número que todos pueden entender

Uno de los elementos más concretos del modelo CROC es el Índice de Riesgo Cibernético, conocido como CRI. Su propósito es simple pero poderoso: traducir información técnica compleja en una métrica comprensible que cualquier tomador de decisiones pueda interpretar y actuar sobre ella.

En lugar de presentar al consejo una lista de vulnerabilidades con códigos CVE y niveles de severidad técnica, el CRI responde una pregunta directa: ¿dónde está concentrado el riesgo real de la organización y cuánto podría costar un incidente hoy?

Eso es lo que permite tomar decisiones de inversión con base en evidencia. Asignar presupuesto donde el impacto es mayor. Priorizar acciones no por lo que genera más ruido, sino por lo que representa mayor exposición al negocio.

Cómo opera en la práctica

CROC funciona sobre cinco principios que se retroalimentan de forma continua. Primero, la contextualización de activos: entender qué existe en el entorno digital de la organización, desde endpoints hasta aplicaciones en la nube, y por qué cada uno es crítico. Segundo, la medición continua del riesgo a través del CRI. Tercero, la mitigación estratégica y proactiva, implementando controles antes de que las amenazas se materialicen. Cuarto, el monitoreo continuo de la postura de seguridad con ajustes basados en impacto real. Y quinto, la mejora constante como ciclo permanente, no como proyecto puntual.

Este modelo se integra con las herramientas que la organización ya tiene, XDR, EDR, gestión de vulnerabilidades, seguridad de nube, SIEM, consolidando sus señales en una visión unificada de riesgo. No reemplaza la inversión existente. La hace más inteligente.

Lo que cambia para la organización

El resultado de operar bajo el modelo CROC no es solo técnico. Es estratégico. Una organización que implementa este modelo conoce su nivel real de exposición, puede priorizar con inteligencia, actúa antes de que ocurra el incidente y convierte la ciberseguridad en una función alineada al negocio.

Eso tiene un impacto directo en cómo el área de seguridad se relaciona con la dirección general, con el consejo y con los reguladores. Ya no se trata de reportar incidentes. Se trata de gestionar riesgo con evidencia, con métricas y con criterio de negocio.

Para los líderes que hoy enfrentan la presión de justificar inversiones en seguridad, de demostrar que sus controles son efectivos y de anticiparse a amenazas que evolucionan constantemente, CROC representa exactamente eso: claridad donde antes había incertidumbre y decisiones donde antes había reactividad.

Si quieres profundizar en cómo CROC evoluciona el modelo tradicional del SOC, puedes leer nuestro artículo Del SOC al CROC: eventos vs exposición real al riesgo.

Para mantenerte informado y protegido, sigue las redes sociales de Nova en: Instagram,  Facebook y LinkedIn, donde puedes encontrar más noticias y conocer las soluciones en ciberseguridad que ofrecemos.

#NovaInforma

Cuando la IA descubre vulnerabilidades más rápido de lo que puedes parchear

gestión de vulnerabilidades con inteligencia artificial

Escucha este artículo aquí:

El modelo de seguridad que la mayoría de las organizaciones conoce —esperar un aviso, aplicar un parche, cerrar el ticket— está a punto de quedar obsoleto. No porque haya fallado históricamente, sino porque el ritmo al que se descubren vulnerabilidades acaba de cambiar de forma estructural.

La iniciativa Glasswing de Anthropic es una señal de eso. Aplicar inteligencia artificial al descubrimiento de vulnerabilidades de software significa que lo que antes tomaba semanas o meses de investigación humana especializada, ahora puede ocurrir en una fracción del tiempo. Más rápido, más volumen, más superficie expuesta.

Para un CISO o un gerente de TI, esto plantea una pregunta muy concreta: si mañana hay diez veces más vulnerabilidades descubiertas, ¿tiene su organización la capacidad de operar ese volumen sin colapsar?

El problema no es el descubrimiento. Es todo lo que viene después.

Encontrar una vulnerabilidad no cierra el riesgo. Lo abre. Desde el momento en que existe un hallazgo hasta que hay un parche disponible, probado e implementado en producción, puede transcurrir semanas. A veces meses. En ese intervalo, los actores maliciosos operan con una ventaja estructural: conocen la exposición antes de que usted pueda cerrarla.

Escalar la detección sin escalar la capacidad de respuesta no mejora la postura de seguridad. La amplía. Es una trampa que muchos equipos están a punto de caer si no reorientan su operación hacia algo más parecido a la gestión continua de exposición que a la gestión reactiva de parches.

TrendAI y el ciclo completo

TrendAI lleva más de tres décadas operando en la vanguardia de la investigación de amenazas. Su programa Zero Day Initiative —el programa de divulgación de vulnerabilidades independiente de proveedores más grande del mundo— no es una respuesta al momento actual. Es una infraestructura construida con anticipación a él.

La lógica es clara: el descubrimiento sin coordinación genera exposición no gestionada. Por eso TrendAI trabaja activamente junto a iniciativas como Glasswing para garantizar que cada vulnerabilidad identificada siga un proceso de divulgación responsable, que los fabricantes tengan el tiempo necesario para desarrollar soluciones y que los atacantes no lleguen primero.

Pero más allá de la divulgación, la propuesta de TrendAI resuelve el problema operativo de fondo.

Cuando se identifica una vulnerabilidad, la organización enfrenta una ventana de exposición antes de que exista un parche oficial. TrendAI cierra esa ventana con protecciones virtuales que pueden activarse hasta 96 días antes de que el fabricante publique una solución. Eso no es un detalle menor: es la diferencia entre estar expuesto durante los días más activos del ciclo de explotación, o no.

De vulnerabilidades a exposición gestionada

El otro problema que escala con el volumen es la priorización. Si antes era difícil decidir qué parchar primero, en un entorno donde la IA multiplica los hallazgos, la dificultad se convierte en parálisis.

La plataforma TrendAI Vision One, a través de su módulo de Cyber Risk Exposure Management, conecta el descubrimiento, la priorización y la remediación en un ciclo continuo. No opera sobre listas de vulnerabilidades. Opera sobre exposición real: qué está activo en el entorno, qué es explotable hoy, qué impacta directamente en los activos críticos del negocio.

Eso es lo que diferencia un inventario de vulnerabilidades de una operación de riesgo. El primero informa. El segundo actúa.

Detrás de todo esto opera AESIR —la plataforma interna de inteligencia de seguridad de TrendAI— que aplica IA y flujos de trabajo basados en agentes para automatizar el análisis, gestionar la divulgación coordinada y habilitar el parcheo virtual cuando es posible. No es una capacidad construida en respuesta a Glasswing. Es la infraestructura que TrendAI lleva años desarrollando para este momento.

Lo que esto implica para su organización

La era del descubrimiento de vulnerabilidades impulsado por IA no está llegando. Ya llegó. Y las organizaciones que la naveguen con éxito no serán necesariamente las que tengan más herramientas, sino las que puedan convertir volumen en claridad y claridad en acción.

Eso requiere tres cosas: un proceso de divulgación coordinada que no genere exposición prematura, capacidad de priorizar por impacto real y no por severidad abstracta, y protección que no dependa de esperar el parche.

Si su equipo ya está al límite gestionando el volumen actual, la pregunta no es si este cambio los afectará. Es cuánto tiempo tienen para reorientar su operación antes de que el volumen los supere.

Para mantenerte informado y protegido, sigue las redes sociales de Nova en: Instagram,  Facebook y LinkedIn, donde puedes encontrar más noticias y conocer las soluciones en ciberseguridad que ofrecemos.

#NovaInforma

frontera de la IA: por qué la defensa del futuro es una operación de riesgo en tiempo real

defensa contra ataques de IA avanzada

Escucha este artículo aquí:

La ciberseguridad siempre ha tenido una ventaja implícita: el tiempo. Detectar, investigar y responder solía ser suficiente para contener la mayoría de los incidentes antes de que escalaran. Esa ventaja se está erosionando.

Con la llegada de modelos de IA avanzados, los atacantes ya no dependen únicamente de habilidades humanas o ciclos manuales. Ahora pueden automatizar la búsqueda de vulnerabilidades, encadenar fallas en sistemas complejos y ejecutar ataques a una velocidad que reduce drásticamente la ventana de reacción de las organizaciones.

El mensaje de fondo de iniciativas como Unit 42 Frontier AI Defense de palo alto networks es claro: el modelo tradicional de defensa ya no escala frente a ataques impulsados por IA.

El cambio clave: de ataques humanos a ataques autónomos

Lo que está cambiando no es solo la velocidad, sino la naturaleza del atacante.

Los ataques ya no son necesariamente lineales ni manuales. Un sistema impulsado por IA puede:

  • explorar superficies de ataque completas en minutos,
  • identificar vulnerabilidades encadenables,
  • y ejecutar secuencias de explotación sin intervención humana constante.

Esto genera un problema estructural: la defensa tradicional está diseñada para interpretar eventos, no para competir contra sistemas que operan en ciclos mucho más cortos.

En ese contexto, el tiempo entre “detección” y “respuesta” deja de ser una métrica operativa… y se convierte en una variable de riesgo.

El verdadero problema no es la IA, es la velocidad compuesta

Cuando los ataques son automatizados, no solo se vuelven más rápidos. También se vuelven iterativos.

Un atacante puede probar múltiples variantes de explotación en paralelo, ajustar rutas de ataque en tiempo real y escalar intentos sin costo marginal relevante. Esto genera lo que se puede entender como “velocidad compuesta”: cada iteración mejora la siguiente.

En ese escenario, la exposición no es estática. Cambia mientras la organización todavía está investigando lo que ocurrió.

Qué propone este nuevo enfoque de defensa

El planteamiento de Unit 42 de palo alto networks va en una dirección interesante: mover la seguridad hacia una lógica de tres capas operativas:

Primero, identificar la exposición antes de que sea explotada, entendiendo qué vulnerabilidades realmente pueden encadenarse en un ataque real.

Segundo, reducir la superficie de ataque de forma estructural, no solo parcheando incidentes aislados.

Tercero, modernizar la operación de seguridad para responder en tiempo real, apoyándose en automatización y analítica avanzada para acortar los ciclos de decisión.

Más allá del nombre de la iniciativa, el concepto clave es este: la defensa ya no puede depender de ciclos humanos tradicionales.

De detección de incidentes a operación del riesgo

Aquí es donde este enfoque conecta directamente con la evolución que hemos venido trabajando en la serie CROC.

Un SOC tradicional está optimizado para detectar y responder eventos. Pero en un entorno donde la IA acelera el ciclo completo del ataque, eso ya no es suficiente.

Lo que empieza a tomar relevancia es otro enfoque: operar la exposición de forma continua.

Eso implica cambiar la pregunta central de seguridad:

  • De “¿qué pasó?”
  • A “¿qué es explotable ahora mismo y qué impacto tendría?”

Ese cambio es sutil, pero profundo. Porque convierte la seguridad en una función que no solo reacciona, sino que gestiona activamente la probabilidad de que un ataque ocurra con éxito.

El rol de la IA en defensa: no es opcional, es estructural

Así como los atacantes están usando IA para escalar su capacidad, la defensa también necesita apoyarse en sistemas inteligentes para analizar exposición, priorizar riesgos y acelerar decisiones.

No se trata de “automatizar el SOC” como un objetivo aislado. Se trata de algo más amplio: reducir el tiempo entre exposición y mitigación por debajo del ciclo del atacante.

En términos simples: si el atacante piensa en minutos, la defensa ya no puede pensar en horas.

Qué cambia para la organización

Este tipo de cambio no es solo tecnológico. Es operativo y estructural.

Para TI, significa que la gestión de vulnerabilidades deja de ser un proceso periódico y se convierte en un flujo continuo.
Para SecOps, implica que la priorización ya no puede basarse solo en severidad, sino en explotabilidad real en contexto.
Para el CISO, cambia la conversación: el foco deja de ser cuántos incidentes se atendieron y pasa a ser cuánto riesgo se redujo frente a un adversario que también evoluciona en tiempo real.

Conexión con CROC: el siguiente nivel de madurez

Este tipo de enfoques encajan naturalmente con la idea de un Cyber Risk Operations Center (CROC).

Porque cuando el adversario opera con IA, la seguridad deja de ser un sistema de alertas y pasa a ser un sistema de gestión continua de exposición.

Un CROC no compite con la velocidad del atacante desde la detección. La compite desde la reducción estructural del riesgo.

Y esa es la verdadera transición que está ocurriendo:
de defender eventos → a operar riesgo en tiempo real.
Para mantenerte informado y protegido, sigue las redes sociales de Nova en: Instagram,  Facebook y LinkedIn, donde puedes encontrar más noticias y conocer las soluciones en ciberseguridad que ofrecemos.

#NovaInforma

visibilidad real: por qué el inventario “mensual” ya no sirve

visibilidad de activos en tiempo real

Escucha este artículo aquí :

Durante mucho tiempo, el inventario de activos fue una de las bases más importantes de la gestión de TI. Saber qué equipos existen, qué software corren y dónde están ubicados era suficiente para construir una postura de seguridad razonable. El problema es que ese modelo nació en un entorno donde los cambios eran más lentos y predecibles.

Hoy ese supuesto ya no existe.

En entornos híbridos, con nube, trabajo remoto, dispositivos móviles, aplicaciones SaaS y despliegues continuos, la infraestructura cambia todos los días. Nuevos activos aparecen sin control centralizado, otros desaparecen, algunos cambian de configuración sin pasar por procesos formales, y muchos ni siquiera están correctamente registrados desde el inicio.

En ese contexto, un inventario mensual deja de ser una herramienta de control y se convierte en una fotografía histórica. Y en ciberseguridad, una fotografía del pasado no reduce el riesgo del presente.

El problema no es el inventario, es su caducidad

El error más común no es hacer inventarios, sino asumir que siguen siendo válidos cuando se consultan semanas después.

Entre un ciclo de inventario y otro pueden ocurrir decenas de cambios relevantes: endpoints que se conectan por primera vez, sistemas expuestos temporalmente a internet, usuarios con privilegios elevados que cambian de rol, o servicios que se levantan sin documentación adecuada.

Cada uno de estos cambios puede modificar la superficie de ataque. El riesgo no se detiene mientras esperamos el siguiente reporte.

En otras palabras: el inventario tradicional describe cómo era el entorno, no cómo es ahora.

Cuando la visibilidad de activos en tiempo real no es continua, el riesgo se mueve más rápido que la defensa

La visibilidad de activos no es solo una cuestión de control operativo, es una condición base para la gestión de riesgo. Si no sabes qué existe en este momento, no puedes evaluar qué está expuesto ni qué debería priorizarse.

El problema se amplifica porque los atacantes no trabajan con inventarios mensuales. Ellos exploran continuamente la superficie real, no la documentada. Cualquier desfase entre lo que existe y lo que se cree que existe se convierte en una ventana de oportunidad.

Este es uno de los puntos más críticos en la higiene de TI moderna: el riesgo se mueve en tiempo real, pero muchas organizaciones siguen operando con visibilidad periódica.

De inventario a visibilidad continua

La evolución natural del inventario no es hacer “mejores inventarios”, sino pasar a un modelo de visibilidad continua.

Esto significa tener una capacidad constante de identificar activos, cambios y relaciones dentro del entorno tecnológico. No como un ejercicio puntual, sino como un flujo operativo que refleja el estado actual del sistema.

Cuando la visibilidad es continua, cambia la forma en que se toman decisiones. Ya no se prioriza con base en lo que “se sabía” hace semanas, sino en lo que realmente está expuesto hoy.

Esto tiene un impacto directo en tres dimensiones:

  • Riesgo: se reduce la incertidumbre sobre la superficie real de ataque.
  • Operación: se eliminan esfuerzos duplicados y trabajo sobre activos inexistentes o irrelevantes.
  • Prioridad: se enfoca la remediación en lo que está activo y es relevante ahora, no en lo que lo fue.

El inventario estático crea falsas zonas de seguridad

Uno de los riesgos menos evidentes del modelo tradicional es la ilusión de control.

Cuando un inventario está actualizado “en papel”, es fácil asumir que la organización tiene visibilidad completa. Sin embargo, esa confianza puede ocultar activos no registrados, entornos temporales o configuraciones que cambiaron después del último corte.

Estas zonas ciegas no siempre son grandes o evidentes. A veces son pequeños desajustes entre realidad y documentación que, acumulados, crean un terreno fértil para exposición no controlada.

En seguridad, el problema no es lo que sabemos que existe, sino lo que creemos que no existe.

La higiene de TI como disciplina de visibilidad dinámica

En una higiene de TI moderna, la visibilidad no es un entregable, es una capacidad operativa.

No se trata de “tener un inventario”, sino de sostener una comprensión actualizada del entorno en todo momento. Esto permite que la organización deje de reaccionar a descubrimientos tardíos y empiece a operar con información viva.

Este enfoque es el que habilita modelos más avanzados de gestión de riesgo, donde la exposición no se calcula una vez al mes, sino de forma continua, alineada con la realidad del negocio y su infraestructura.

Qué cambia para la organización

Adoptar visibilidad continua de activos cambia más de lo que parece a primera vista.

Para TI, reduce el tiempo perdido en reconciliar inventarios desactualizados.
Para seguridad, mejora la precisión en la evaluación de exposición.
Para el negocio, disminuye la probabilidad de incidentes causados por activos desconocidos o mal gestionados.

Pero el cambio más importante es conceptual: la organización deja de confiar en estados estáticos y empieza a operar sobre un entorno dinámico.

Y en un entorno dinámico, la única forma realista de reducir riesgo es tener visibilidad en tiempo real.

Para mantenerte informado y protegido, sigue las redes sociales de Nova en: Instagram,  Facebook y LinkedIn, donde puedes encontrar más noticias y conocer las soluciones en ciberseguridad que ofrecemos.

#NovaInforma

IA agente: cuando la IA deja de “responder” y empieza a actuar

Escucha este artículo aquí:

Durante el último par de años, muchas organizaciones empezaron a convivir con modelos de lenguaje (LLMs) como asistentes: redactan, resumen, responden dudas, ayudan a analizar información. En general, el riesgo se podía encerrar en un marco relativamente claro: lo que la IA “dice” puede ser incorrecto, puede filtrar información, o puede ser manipulada a través de prompts. Todo eso importa, pero tiene un límite: el LLM, por sí solo, no cambia tu realidad. Solo produce contenido.

La IA agente (agentic AI) rompe ese límite.

Radware lo plantea de forma contundente: los LLMs generan texto; la IA agente genera consecuencias. El salto de respuestas predictivas a acciones autónomas cambia por completo la ecuación de riesgo. Un agente acepta objetivos, planifica tareas en varios pasos, usa herramientas, llama APIs, actualiza registros y toma decisiones sin que necesariamente haya un humano aprobando cada movimiento.

Y cuando la IA puede actuar, la seguridad deja de ser un tema de “prompt y respuesta”. Se convierte en un tema de operación.

El “salto de autonomía”: por qué aquí cambia todo

Un LLM puede ayudarte a redactar un correo de atención al cliente. Un agente, en cambio, podría hacer algo como: consultar datos del cliente, validar un caso, emitir un reembolso, actualizar el CRM, y disparar un flujo de seguimiento. Ese ejemplo aparece como analogía directa en el texto de Radware, y es perfecto porque lo vuelve tangible: la IA ya no está en el dominio del contenido; está en el dominio de los procesos.

Ese cambio tiene tres implicaciones enormes para el riesgo:

1) La velocidad del error se comprime.
Entre un input malicioso y un resultado dañino puede pasar muy poco tiempo, porque el sistema está diseñado para ejecutar.

2) El “radio de impacto” crece.
Un mal prompt ya no solo produce una mala respuesta; puede desencadenar movimientos de datos, cambios en sistemas, decisiones operativas o impactos financieros.

3) El riesgo se vuelve sistémico.
El agente no vive aislado: se conecta a herramientas, identidades, memorias, pipelines, sistemas internos. Y eso amplifica cualquier debilidad de gobierno.

Los riesgos no vienen solo de “lo que dice”, sino de “lo que puede hacer”

Cuando el agente puede usar herramientas, hay una pregunta que se vuelve inevitable para TI y seguridad: ¿qué permisos tiene?

En el mundo clásico, el problema era: “¿qué información vio el modelo?”.
En el mundo agentic, el problema es: “¿qué acciones tiene permitido ejecutar el sistema?”.

Radware enfatiza que, una vez que el AI puede actuar, la seguridad debe extenderse más allá de prompts y outputs y entrar en dominios como identidad, herramientas, memoria y gobernanza de runtime.

En lenguaje de negocio, el riesgo no es que la IA “se equivoque” al responder. El riesgo es que la IA se equivoque mientras opera: moviendo datos, generando transacciones, abriendo accesos, automatizando cambios o ejecutando procesos.

El punto ciego más común: confundir automatización con control

Un patrón que estamos viendo en muchas organizaciones es este: se implementan agentes para ganar velocidad, pero el gobierno se queda atrás. Se asume que “si el agente es útil”, entonces “es seguro”.

La realidad es más incómoda: la autonomía no solo multiplica productividad; también multiplica exposición si no existe un marco de control. Y ese marco no se resuelve con “buenas prácticas de prompts” únicamente. Necesita, como mínimo, cuatro pilares:

  • Identidad y privilegios mínimos para lo que el agente puede hacer.
  • Gobierno de herramientas y APIs: qué puede invocar, cuándo y con qué validaciones.
  • Memoria y contexto: qué recuerda, qué conserva y qué puede reusar (y qué no).
  • Monitoreo y enforcement en runtime: visibilidad de acciones, límites, bloqueos, auditoría.

No es un tema de paranoia. Es el equivalente moderno a lo que ya aprendimos con automatización en IT: si automatizas un proceso sin controles, automatizas también el error.

Dos escenarios “antes y después”

Imagina un agente que ayuda a soporte y finanzas a resolver casos en minutos. En el flujo normal, es brillante. Pero un atacante logra manipular el contexto (por ejemplo, inyectando instrucciones en datos que el agente consulta) y el agente ejecuta reembolsos o cambios de cuenta que “parecen” legítimos porque siguen el flujo. El daño no viene de un exploit tradicional; viene de abuso de autonomía: el agente hizo lo que estaba diseñado para hacer, pero bajo un contexto adverso.

Ahora piensa en un agente que “optimiza” procesos: actualiza tickets, crea accesos temporales, reinicia servicios, aplica cambios de configuración con base en diagnósticos. Si el agente tiene permisos amplios y el monitoreo es débil, cualquier error de razonamiento o manipulación de entrada puede convertirse en un cambio real en producción. No necesitas un atacante brillante; basta con una cadena de suposiciones incorrectas ejecutadas a máquina.

En ambos casos, el problema no es que la IA “alucine”. El problema es que la IA puede ejecutar.

Qué cambia para TI, SecOps y el CISO

Para TI, esto introduce una nueva disciplina: no basta con “integrar” un agente; hay que operar su ciclo de vida como un sistema crítico. Permisos, roles, auditabilidad, límites de acción, pruebas de abuso, y observabilidad se vuelven parte del estándar.

Para SecOps, los agentes agregan una nueva superficie de ataque: entradas manipulables, contextos contaminables, herramientas invocables, identidades automatizadas. El monitoreo debe evolucionar para incluir no solo “alertas”, sino trazabilidad de decisiones y acciones.

Para el CISO, el reto principal es de gobierno: el negocio va a pedir agentes por eficiencia. La pregunta es cómo habilitarlos sin crear una deuda de riesgo que explota después. Aquí el lenguaje de riesgo importa: autonomía = mayor productividad, sí, pero también mayor blast radius si no se diseña con controles.

Cómo se conecta con el enfoque CROC

En Nova, cuando hablamos de CROC, hablamos de operar el riesgo como un proceso continuo: ver exposición, priorizar, intervenir y verificar reducción.

La IA agente encaja perfecto como nuevo frente de exposición. No porque sea “mala”, sino porque cruza una línea: pasa de recomendar a ejecutar. Y eso exige un enfoque operativo, no solo políticas.

Un CROC aplicado a este problema significaría: mapear dónde hay agentes, qué sistemas tocan, qué permisos tienen, qué datos consumen, qué acciones ejecutan, qué tan verificables son sus decisiones, y qué guardrails existen en runtime. Es el mismo principio: convertir un riesgo emergente en un proceso manejable y medible.

La idea central

La IA agente no es “un LLM más”. Es un cambio de categoría.

Si tu IA puede actuar, tu seguridad debe proteger no solo lo que el modelo responde, sino lo que el sistema puede ejecutar: identidad, herramientas, memoria y gobierno operativo. Ahí es donde se juega la resiliencia, el cumplimiento y la confianza del negocio en la nueva economía agentic.

Para mantenerte informado y protegido, sigue las redes sociales de Nova en: Instagram,  Facebook y LinkedIn, donde puedes encontrar más noticias y conocer las soluciones en ciberseguridad que ofrecemos.

#NovaInforma

del SOC al CROC: eventos vs exposición real al riesgo

Escucha este artículo aquí:

Durante años, el SOC fue el centro natural de la seguridad. Y con razón: en un mundo de amenazas constantes, tener capacidad de detección y respuesta es esencial. El problema es que muchas organizaciones crecieron pensando que el SOC era “toda” la estrategia de seguridad, cuando en realidad es una parte —muy valiosa— de un rompecabezas más grande.

Hoy, con entornos híbridos, activos que cambian cada semana, aplicaciones que se despliegan a velocidad de nube y adversarios cada vez más automatizados, aparece una distinción que vale la pena decir en voz alta: un SOC opera eventos; un CROC opera exposición al riesgo.

Y esa diferencia no es semántica. Cambia la forma en que priorizas, cómo asignas recursos y cómo explicas seguridad a la alta dirección.

Qué es un “evento” y por qué el SOC es indispensable

Un SOC está diseñado para recibir señales: logs, alertas, telemetría, indicadores. Su trabajo es detectar actividad sospechosa, investigar y responder. En términos prácticos, es el músculo de “lo que está pasando ahora”.

Ese enfoque sigue siendo crítico. Los incidentes ocurren y hay que contenerlos. Pero un evento tiene una característica incómoda: es reactivo por naturaleza. Para que exista evento, algo ya ocurrió: un comportamiento anómalo, una explotación, un intento de movimiento lateral, un patrón que dispara una alerta.

Incluso en los mejores escenarios, un SOC opera con el tiempo en contra. Está optimizado para reducir impacto una vez que el riesgo se empezó a materializar. Y aunque esto es necesario, no necesariamente reduce la exposición estructural que hace posible el siguiente incidente.

La exposición: el “antes” del incidente

La exposición es el conjunto de condiciones que vuelven posible un ataque exitoso: activos desconocidos, configuraciones débiles, vulnerabilidades sin remediar, identidades con privilegios excesivos, rutas de acceso mal gobernadas, APIs sin control, superficies que crecen sin supervisión.

La exposición existe, aunque hoy no haya alertas. Y ese es el punto: la organización puede estar “tranquila” y al mismo tiempo estar altamente expuesta.

Aquí es donde muchas estrategias se rompen. Si todo se mide por eventos, el día sin incidentes se interpreta como “día seguro”. Pero desde una perspectiva de riesgo, un día sin eventos también puede ser un día donde el adversario solo está observando, preparando o esperando el mejor momento.

Por qué los eventos no bastan para priorizar

Otra realidad operativa: el SOC suele vivir bajo presión de volumen. Alertas, falsos positivos, triage, escalaciones. Cuando la prioridad se define por lo que “grita más fuerte”, el enfoque se vuelve táctico. Es comprensible, pero tiene un costo: el equipo vive apagando incendios y pierde capacidad de trabajar en la causa raíz.

En cambio, la exposición permite priorizar con otra lógica: qué condiciones están aumentando el riesgo real de la organización y qué acciones lo reducen de forma tangible. La prioridad deja de ser “qué alerta atendemos” y se convierte en “qué exposición reducimos primero”.

Esto reduce fatiga operativa, porque el trabajo ya no es infinito por ruido, sino dirigido por impacto.

Qué hace un CROC (y por qué no compite con el SOC)

Un CROC —Cyber Risk Operations Center— no reemplaza al SOC. Lo complementa. Si el SOC opera incidentes, el CROC opera la reducción continua del riesgo.

Su foco es establecer un ciclo constante que responda a preguntas como:

¿qué está expuesto hoy y por qué?
¿qué exposición es accesible y explotable en nuestro contexto?
¿qué toca activos críticos para el negocio?
¿qué acción concreta reduce más riesgo en menos tiempo?
¿cómo verificamos que el riesgo bajó y no solo “hicimos algo”?

Este cambio de preguntas cambia todo: cambia las métricas, el tipo de colaboración con TI, la conversación con el negocio y el uso de herramientas. Porque el objetivo no es ver más cosas, sino reducir exposición con evidencia.

Dos escenarios para entenderlo sin teoría

Imagina una organización con un SOC sólido, que responde rápido. Sin embargo, cada trimestre aparece un incidente similar: credenciales comprometidas, abuso de cuentas, movimientos laterales. El SOC atiende cada caso con profesionalismo, pero el patrón se repite.

Eso suele pasar cuando la exposición de fondo no se gestiona: privilegios excesivos, falta de segmentación, endpoints sin postura mínima, políticas débiles en identidades. El SOC está viendo los síntomas; el CROC se enfocaría en la condición que habilita el síntoma.

Otro escenario: el SOC recibe cientos de alertas de vulnerabilidades explotables “en teoría”, pero TI no da abasto. Sin un enfoque de exposición real, todo parece urgente. Con un enfoque CROC, la priorización cambia: primero lo que es accesible, explotable y crítico para procesos de negocio. Y, después de remediar, se verifica que el riesgo realmente bajó.

Qué cambia para la alta dirección

Para el C-level, la pregunta rara vez es “¿cuántas alertas resolviste?”; es “¿estamos más protegidos que el trimestre pasado?” y “¿qué riesgo sigue abierto?”.

Un SOC puede reportar eficiencia operativa (tiempos de respuesta, incidentes contenidos). Un CROC puede reportar algo que el negocio entiende mejor: reducción de exposición y tendencia de riesgo.

Eso permite decisiones más maduras. Presupuesto, prioridades, aceptación de riesgo y continuidad operativa dejan de basarse en percepciones o sustos recientes, y se basan en evidencia continua.

Una transición realista: de eventos a riesgo operativo

No se trata de “cambiar SOC por CROC” de un día a otro. Se trata de evolucionar:

  • Mantener el SOC fuerte para responder a lo inmediato.
  • Construir una operación de riesgo que reduzca la exposición que alimenta futuros incidentes.
  • Conectar TI, seguridad y negocio con un lenguaje común: impacto, prioridad y evidencia.

Ese es el corazón del cambio: dejar de vivir únicamente del evento y empezar a operar el riesgo como un proceso continuo. Porque si el SOC es la línea de defensa cuando el ataque ya empezó, el CROC es la disciplina que busca que ese ataque tenga menos oportunidades de empezar.

Para mantenerte informado y protegido, sigue las redes sociales de Nova en: Instagram,  Facebook y LinkedIn, donde puedes encontrar más noticias y conocer las soluciones en ciberseguridad que ofrecemos.

#NovaInforma

predecir “brotes” de malware: la forma más práctica de volver proactiva la gestión del riesgo

gestión proactiva del riesgo cibernético predictiva

Escucha este artículo aquí:

Hay una idea que se está volviendo incómodamente cierta en muchas organizaciones: la seguridad reacciona bien… pero llega tarde. Detectamos, contenemos, restauramos. Y, aun así, los costos suben: tiempo perdido, equipos saturados, interrupciones operativas y decisiones que se toman bajo presión.

TrendAI plantea un giro interesante: ¿y si empezamos a pensar los ataques como “brotes” (outbreaks), igual que en salud pública? No para dramatizar, sino para usar la analogía correcta. En un brote, lo valioso no es solo atender al paciente; es entender los patrones que aumentan la probabilidad de contagio y actuar antes. En ciberseguridad, esa prevención tiene un nombre más aterrizado: gestión proactiva del riesgo basada en comportamiento y predicción.

El punto de partida: el riesgo no es aleatorio

La investigación de TrendAI parte de una premisa fuerte: el riesgo en endpoints no ocurre “por suerte”. Está influenciado por comportamientos del usuario y por patrones de uso del equipo. Para probarlo, analizaron actividad de endpoints a gran escala (más de 10 millones) y concluyeron que el riesgo es altamente dependiente del contexto.

Esto importa porque cambia la conversación con el negocio. Si el riesgo no es aleatorio, entonces se puede modelar, explicar y reducir con acciones concretas. Ya no es solo “reforzar controles”, sino identificar quiénes y qué máquinas están operando en condiciones de mayor exposición.

Del “alerta-respuesta” a “probabilidad-prevención”

El estudio propone combinar analítica conductual con modelado estadístico para anticipar la exposición a malware. En lugar de esperar una señal de ataque, el objetivo es estimar la probabilidad de futuros “brotes” por endpoint y por tipo de malware, con un enfoque más explicable que la típica caja negra.

La clave aquí es el tipo de señales. No se trata únicamente de indicadores de compromiso; se trata de patrones cotidianos que aumentan la exposición. Por ejemplo, el análisis relaciona ciertas conductas con incrementos medibles de riesgo para clases específicas de malware.

Qué encontraron (y por qué es útil en operación)

TrendAI describe, entre otros hallazgos, asociaciones claras entre comportamiento y riesgo. Algunos ejemplos que ilustran la idea:

  • Tener una cantidad muy alta de aplicaciones instaladas (más de 159) incrementa la probabilidad de encontrarse con software “backdoored” (como troyanos) en un 61%, lo que sugiere ausencia de políticas de control/whitelisting en el entorno.
  • Visitar sitios de apuestas se asoció con mayor exposición a PUAs (+91%), troyanos (+78%) y “hacktools” (+37%), mostrando cómo los criminales adaptan sus modelos de distribución según el tipo de sitio.
  • Usar el endpoint principalmente de noche (85% del tiempo) se asoció con hasta 92% más riesgo de infección por ransomware, interpretado como mayor probabilidad de conductas inseguras en ese horario.

La parte valiosa no es el morbo del ejemplo; es la consecuencia práctica: si puedes detectar estos patrones temprano, puedes intervenir antes con controles y capacitación específicos, en lugar de tratar a toda la organización como si tuviera el mismo perfil de exposición.

Predicción con dos motores: señal + probabilidad

El enfoque se apoya en dos componentes: un motor estadístico que vincula acciones específicas con futuras infecciones por categoría, y un clasificador que estima la probabilidad de varias clases de malware (coinminer, hacktool, PUA, ransomware, trojan y virus) para una máquina en particular.

En el mismo análisis reportan la distribución de riesgo estimado en la muestra (10.7 millones de endpoints, 217 países, 822 organizaciones, durante un mes): alrededor de 31.61% en riesgo bajo (0–20), 57.55% en rangos medios, y proporciones menores en rangos altos (61–80 y 81–100). El mensaje es importante: el riesgo “extremo” es raro, pero la mayoría vive en una zona media vulnerable, donde pequeñas mejoras pueden reducir exposición significativamente.

Qué cambia para el CISO, TI y SecOps

Aquí es donde esto se vuelve “estilo Nova”: el valor no es el modelo, sino lo que habilita.

Para el CISO, significa poder hablar de riesgo como tendencia y probabilidad, no solo como incidentes pasados. Eso habilita decisiones de inversión con lógica preventiva: dónde reforzar políticas, qué segmentos requieren intervención, qué riesgos están creciendo.

Para TI, abre la puerta a políticas más inteligentes: no se trata de bloquear por bloquear, sino de ajustar controles donde el comportamiento muestra mayor exposición (por ejemplo, control de instalación de software, endurecimiento de permisos, segmentación, reglas de navegación).

Para SecOps, reduce el tiempo perdido en lo genérico. En vez de “cazar” a ciegas, se puede focalizar en usuarios y equipos con mayor probabilidad de caer en campañas específicas, fortaleciendo defensas antes de que se materialice el brote.

Dos escenarios típicos (antes y después)

Imagina una organización con picos recurrentes de incidentes “pequeños” que consumen muchas horas: adware, PUAs, troyanos por descargas, y de vez en cuando un ransomware que escala. En el modelo reactivo, el equipo apaga incendios y corre campañas de concientización masivas que, honestamente, se sienten igual para todos.

Con un enfoque predictivo, la estrategia se vuelve quirúrgica: identificas qué perfiles y qué máquinas están en patrones de mayor exposición y aplicas controles y capacitación contextual. No “educas a todos igual”; reduces el riesgo donde de verdad está creciendo.

O piensa en una operación 24/7 donde ciertos equipos se usan predominantemente en turnos nocturnos. En vez de asumir que “es lo mismo”, puedes reforzar controles y monitoreo en esos segmentos con lógica de continuidad operativa, no con paranoia.

Cómo se conecta con el mensaje CROC

Un CROC no se trata de ver más alertas; se trata de operar el riesgo de forma continua: medir exposición, priorizar acciones y comprobar que el riesgo baja.

Este tipo de investigación encaja perfecto con ese enfoque porque transforma la gestión del riesgo en algo accionable: probabilidad + contexto + intervención. Y cuando eso se integra a una operación de riesgo (CROC), el resultado no es “más trabajo”, sino una defensa más estratégica: menos sorpresas, menos brotes y más control sobre la exposición real.
Para mantenerte informado y protegido, sigue las redes sociales de Nova en: Instagram,  Facebook y LinkedIn, donde puedes encontrar más noticias y conocer las soluciones en ciberseguridad que ofrecemos.

#NovaInforma

CTEM: el cambio de enfoque que convierte vulnerabilidades en decisiones de riesgo

Escucha este artículo aquí:

Durante años, muchas organizaciones han vivido una paradoja: tienen más herramientas, más escaneos y más hallazgos que nunca… pero siguen sin poder responder con claridad a la pregunta que realmente importa: ¿qué riesgo es el que puede golpear al negocio primero?

Ahí es donde entra CTEM (Continuous Threat Exposure Management). Gartner lo define como una disciplina programática para evaluar continuamente la exposición a ciberamenazas —en particular la visibilidad, accesibilidad y explotabilidad de activos físicos y digitales— con el objetivo de impulsar una remediación priorizada, validada y alineada al negocio.

Dicho sin vueltas: CTEM propone dejar de perseguir listas interminables de vulnerabilidades “en teoría” y pasar a reducir la exposición “en la vida real”.

Por qué CTEM aparece justo ahora

El entorno cambió. Hoy la superficie de ataque crece y se mueve todos los días: nube híbrida, identidades distribuidas, APIs, aplicaciones SaaS, equipos remotos, terceros, automatizaciones. En ese escenario, los enfoques puntuales —auditorías trimestrales, revisiones anuales, “campañas” de remediación por oleadas— tienden a quedarse cortos, no por falta de esfuerzo, sino por falta de continuidad.

CTEM nace para enfrentar esa realidad: convertir la gestión de exposición en un ciclo constante, no en un proyecto esporádico. Varias guías y fabricantes coinciden en el corazón del enfoque: identificar exposición de manera continua, priorizar por riesgo y validar lo que realmente es explotable.

CTEM vs. el modelo tradicional de vulnerabilidades

El modelo tradicional de vulnerabilidades suele parecerse a esto: escaneo → listado → severidad CVSS → tickets → backlog. Funciona para descubrir, pero se vuelve frágil para priorizar. La severidad por sí sola no responde si algo está realmente expuesto, si es alcanzable desde internet, si existe una ruta de ataque, si el activo es crítico o si el hallazgo aplica a un entorno que ni siquiera está en producción.

CTEM le cambia el centro de gravedad a la conversación. En lugar de “¿cuántas vulnerabilidades tenemos?”, empuja a preguntarse: “¿cuáles exposiciones son accesibles, explotables y relevantes para nuestros procesos críticos?”

Esto importa porque la priorización no es un ejercicio técnico; es una decisión de negocio. Y si la priorización se hace mal, el resultado típico es doble: fatiga en el equipo (mucho que hacer, poco que se puede completar) y exposición sostenida (lo importante se sigue quedando abierto).

Los cinco momentos del ciclo CTEM

CTEM se suele describir como un ciclo en cinco etapas. No es “otra certificación” ni un framework abstracto: es una forma de ordenar el trabajo para que la reducción de riesgo ocurra de verdad.

Alcance (scoping). Se define qué es “crítico” para el negocio y qué superficies entran al ciclo continuo. No es solo infraestructura; también puede incluir entornos cloud, identidades, aplicaciones, repositorios o terceros, dependiendo del modelo operativo.

Descubrimiento (discovery). Se construye una vista completa y actualizada de activos y exposiciones. Aquí aparece una diferencia clave: el descubrimiento no puede ser una foto; tiene que ser un flujo.

Priorización (prioritization). Se ordena el trabajo por impacto real, no por ruido. contexto de negocio, accesibilidad, criticidad del activo y señales de explotación potencial cambian por completo el orden de remediación.

Validación (validation). Se confirma qué exposiciones son realmente explotables o materializables en el entorno. Esta etapa es la que evita invertir semanas en “arreglar lo que no duele” mientras lo crítico sigue abierto.

Movilización (mobilization). Se orquesta la acción: remediación, hardening, cambios de configuración, ajustes de control, y, sobre todo, seguimiento de que el riesgo disminuyó.

La idea no es recorrer esto una vez. La idea es convertirlo en una práctica continua.

Qué cambia para la operación

Cuando CTEM se aplica bien, lo que cambia no es solo el “orden de tickets”. Cambia el tipo de conversación interna.

Para TI, significa que el trabajo deja de ser un backlog infinito y se vuelve un ciclo con prioridad clara: lo que se atiende primero es lo que reduce exposición de forma tangible.

Para SecOps, significa menos ruido y más precisión: en vez de vivir en un mar de hallazgos, se enfoca en exposiciones que realmente conectan con caminos de ataque y con impacto operativo.

Para el CISO y la dirección, significa algo todavía más valioso: se vuelve posible reportar progreso como reducción de riesgo, no como actividad (escaneamos, encontramos, generamos tickets). CTEM facilita hablar de exposición en términos que aterrizan: accesible, explotable, crítico para el negocio, pendiente por resolver.

Dónde encaja Qualys en esta historia

Qualys ha empujado CTEM desde una perspectiva práctica: explicar el enfoque, sus etapas y cómo aterrizarlo sin que se vuelva un programa que “se queda en PowerPoint”.

Desde el ángulo de plataforma, el valor típico que buscan los equipos es poder unir señales (activos, vulnerabilidades, configuración, exposición, contexto) para priorizar y ejecutar remediación con trazabilidad. Es decir: que CTEM no se quede en intención, sino que se convierta en operación.

Y aquí conectamos con un punto que en Nova hemos repetido: lo que no se opera de forma continua, se degrada. CTEM, bien ejecutado, se vuelve un puente natural hacia una operación de riesgo más madura (la lógica CROC): no solo “ver” riesgo, sino reducirlo con un ciclo estable y medible.

Una forma simple de empezar sin rehacerlo todo

CTEM no exige tirar tu programa actual y empezar de cero. La adopción más realista suele iniciar acotando el alcance a lo verdaderamente crítico: un conjunto de aplicaciones, un segmento de infraestructura, un grupo de identidades, un entorno cloud. Se descubre y prioriza ahí, se valida explotabilidad, y se moviliza remediación con seguimiento. Luego se amplía.

Lo importante es no confundir CTEM con “hacer más escaneos”. CTEM es hacer mejores decisiones, con un ciclo continuo que reduzca exposición donde el negocio más lo siente.

Para mantenerte informado y protegido, sigue las redes sociales de Nova en: Instagram,  Facebook y LinkedIn, donde puedes encontrar más noticias y conocer las soluciones en ciberseguridad que ofrecemos.

#NovaInforma

SASE a escala sin dolor: cuando la operación deja de ser el cuello de botella

Escucha este artículo aquí:

Adoptar SASE suele empezar con una intención muy clara: simplificar conectividad y seguridad en un mundo híbrido. El problema es que, cuando la implementación crece —más sedes, más usuarios móviles, más políticas, más aplicaciones— el reto deja de ser tecnológico y se vuelve operativo. De pronto, “SASE” ya no se siente como simplificación; se siente como otra consola, otro flujo y otra carga para equipos que ya traen el día lleno.

Palo Alto Networks lo planteó de forma directa en su anuncio de febrero de 2026: las empresas grandes necesitan seguridad “a velocidad de nube”, pero la complejidad operativa se interpone. Y ese freno, en la práctica, se ve muy tangible: equipos brincando entre dashboards, despliegues que se alargan semanas o meses por configuración manual, y modelos multi-tenant que no escalan si el esfuerzo crece de forma lineal por cada nuevo cliente o unidad de negocio.

El costo invisible: cuando la “silla giratoria” define tu MTTR

Hay un detalle que muchos líderes de TI y seguridad ya viven, pero pocas veces se verbaliza: la seguridad no falla solo por falta de herramientas; también falla por fricción operativa.

Cuando un incidente o degradación aparece, si el proceso requiere ir y venir entre plataformas —identificar en una consola, registrar en otra, escalar en otra más— cada traspaso agrega tiempo, errores y ambigüedad. Ese patrón de “swivel chair operations” (operar con la silla giratoria) incrementa el MTTR y desgasta a los equipos.

En términos de riesgo, esto importa porque el MTTR no es solo una métrica técnica: es una variable de exposición. Entre más tarda una organización en resolver, más tiempo opera con impacto potencial en disponibilidad, productividad y confianza del usuario.

El verdadero cuello de botella: time-to-value

En el mismo anuncio, Palo Alto Networks pone sobre la mesa otro dolor muy real: el “purgatorio” del despliegue. Configuración de infraestructura, conectores, onboarding de usuarios móviles… todo eso puede estirarse por semanas o meses si depende de trabajo manual. Y cada día que pasa sin estabilizar la operación es un día donde el valor prometido por SASE todavía no existe.

En lenguaje de negocio, el time-to-value es el puente entre inversión y resultado. Y en entornos enterprise, ese puente tiene que ser corto, porque la presión por continuidad, cumplimiento y eficiencia no espera.

Automatización como estrategia de riesgo (no como “feature”)

Aquí es donde el anuncio se vuelve interesante para una conversación ejecutiva: no está hablando solo de capacidades de red, sino de automatizar el ciclo operativo de SASE, desde el despliegue hasta la respuesta a incidentes, con una integración directa a Proactivanet o cualquier plataforma ITSM a través de una app de Prisma SASE.

La idea de fondo es simple, pero poderosa: si la operación se ejecuta en el sistema donde ya vive el trabajo diario, reduces fricción, unificas gestión de incidentes y aceleras resolución. Según el post, el enfoque elimina la necesidad de alternar entre consola de SASE, ITSM y portales, manteniendo incidentes sincronizados, reduciendo el trabajo manual y mejorando el MTTR.

Esto, traducido a valor, significa menos desgaste operativo y más consistencia. No es magia: es reducir pasos, eliminar duplicidad y asegurar que la información correcta esté en el lugar donde se toman decisiones.

SASE a escala: cuando multi-tenant deja de ser un dolor

Para proveedores de servicios administrados (MSPs) y también para organizaciones grandes con múltiples unidades, el reto de escala es brutal: si cada “tenant” requiere el mismo esfuerzo humano, el modelo se vuelve insostenible. Palo Alto Networks lo dice explícito: si el overhead crece linealmente por cada nuevo tenant, tarde o temprano el crecimiento se topa con un techo.

La propuesta del artículo es que la app y la automatización unificada permiten escalar sin que la complejidad crezca al mismo ritmo, manteniendo seguridad alineada al crecimiento del negocio.

Qué cambia para la operación (y para el riesgo)

Cuando SASE se gestiona “a escala” de manera madura, lo que cambia no es solo la arquitectura, sino la forma en que la organización respira:

La operación deja de depender de conocimiento tribal y tickets manuales para volverse repetible y automatizable. El tiempo de implementación se acorta y el valor llega antes. La gestión de incidentes se integra al flujo natural del equipo, en lugar de fragmentarse entre portales y consolas. Y, como consecuencia, la organización reduce exposición: menos tiempo en estado degradado, menos errores por handoffs y más control sobre el ciclo completo.

En el fondo, el mensaje es este: SASE no debería aumentar complejidad. Si lo hace, el problema no es el concepto, sino la operación. Y hoy, automatizar esa operación —con integración real al sistema de gestión de servicios— se está convirtiendo en una pieza clave para que SASE cumpla lo que promete.

Para mantenerte informado y protegido, sigue las redes sociales de Nova en: Instagram,  Facebook y LinkedIn, donde puedes encontrar más noticias y conocer las soluciones en ciberseguridad que ofrecemos.

#NovaInforma