logo nova
Search
logo nova

Etiqueta: ciberseguridad

Publicado en

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

Publicado en

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

Publicado en

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

Publicado en

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

Publicado en

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

Publicado en

Higiene de TI 2026: de inventario a reducción continua de exposición

Escucha este artículo aquí:

Si en 2022 hablábamos de higiene de TI como la disciplina de “conocer lo que tienes” y mantenerlo bien administrado, hoy la conversación evolucionó. El inventario sigue siendo el punto de partida, pero ya no es el objetivo final. La higiene de TI, en 2026, se parece más a esto: reducir exposición de forma continua, con evidencia, prioridades claras y un ciclo operativo que no dependa de “fotos” mensuales del entorno

No es un cambio de terminología; es un cambio de realidad. Los activos se mueven todo el tiempo, los endpoints entran y salen con el trabajo híbrido, las configuraciones cambian por releases y urgencias operativas, y la superficie de ataque se ensancha sin pedir permiso. En ese contexto, un inventario desactualizado no es solo un dato incompleto: es una decisión de riesgo tomada a ciegas. Esa es la lógica detrás de la higiene de TI que Nova ya venía planteando desde hace años: “no puedes proteger lo que no conoces” y la necesidad de información actualizada sobre inventario y descubrimiento de activos.

La pregunta hoy es: una vez que lo conoces, ¿cómo lo mantienes bajo control sin ahogar a TI y seguridad en alertas y tareas interminables?

De inventario a exposición: el verdadero salto de madurez

El inventario responde preguntas esenciales: ¿qué tenemos?, ¿dónde está?, ¿qué software corre?, ¿cómo se relaciona con el negocio? Esa base sigue siendo irremplazable, y de hecho el enfoque clásico de higiene de TI nace de ahí.

Pero el paso que hoy diferencia a las organizaciones que “administran TI” de las que “operan riesgo” es este: no basta con saber qué existe; hay que saber qué está expuesto y qué importa primero.

Aquí entra el concepto moderno de exposure management: monitoreo continuo, “score” de riesgo en tiempo real, priorización y remediación integrada. En la narrativa actual de Tanium, el enfoque de Exposure Management está descrito justamente como fortalecer resiliencia con monitoreo continuo de vulnerabilidades, puntuación y priorización en tiempo real, y remediación integrada.

En palabras simples: higiene de TI 2026 no es solo “tener la lista”, es mantener baja la exposición mientras el entorno cambia.

Visibilidad en tiempo real: dejar de operar con “fotografías”

Muchas organizaciones todavía viven con un modelo de visibilidad por cortes: reportes semanales, escaneos programados, inventarios que se actualizan por ventanas. Funciona… hasta que deja de funcionar.

El reto es que el riesgo no espera a tu siguiente reporte. Un endpoint que se sale de política hoy, una app que aparece sin gobierno mañana, o una configuración que se degrada por urgencia operativa, puede abrir una puerta que nadie verá hasta días después. Y en seguridad, días pueden ser demasiados.

La higiene moderna se sostiene en visibilidad continua, porque la operación moderna es continua. Y cuando TI y seguridad comparten la misma verdad (activos, postura, cambios), la conversación se vuelve más fácil: se discute lo que está pasando, no lo que “creemos” que pasa.

Priorizar por impacto: menos ruido, más decisiones

Aquí suele venir la objeción más honesta: “Ok, veo más cosas… ¿y ahora qué hago con todo eso?”

La higiene de TI se rompe cuando se convierte en una lista interminable de tareas. En especial con vulnerabilidades: si todo es crítico, nada es crítico. Por eso el punto no es acumular hallazgos, sino priorizar por impacto.

Priorizar por impacto significa, por ejemplo, entender qué exposición toca procesos críticos, qué vulnerabilidad está realmente presente en activos relevantes y qué remediación reduce riesgo de forma tangible. Cuando la priorización se alinea a negocio, baja la fatiga operativa y sube la efectividad: se trabaja en lo que mueve la aguja.

Remediar y verificar: cerrar el ciclo, no solo “atender tickets”

La higiene de TI no se demuestra con “acciones realizadas”, sino con “riesgo reducido”. Y esa diferencia es enorme.

Hay organizaciones que parchán mucho y, aun así, siguen expuestas porque el ciclo está abierto: se ejecuta una acción, pero no se verifica consistentemente si el riesgo bajó, si el control quedó bien aplicado o si el cambio fue revertido por una urgencia.

Cerrar el ciclo significa que la higiene se vuelve una rutina medible: ver, priorizar, remediar, verificar… y repetir. La remediación integrada es parte de ese enfoque moderno: no como automatización por automatización, sino como una forma de sostener el ritmo de la operación sin depender de heroicidades.

Dos escenarios muy reales (antes y después)

Pensemos en un escenario típico: una organización con miles de endpoints, equipos remotos y aplicaciones que cambian semanalmente. En el modelo “fotografía”, el inventario llega tarde y la priorización se define por volumen de alertas. TI corre para “apagar incendios”, seguridad corre para “cerrar hallazgos” y el negocio solo ve fricción.

En un modelo de higiene 2026, la conversación cambia. Lo importante no es cuántas vulnerabilidades existen, sino cuáles representan exposición real y cuáles, al resolverlas, disminuyen riesgo para sistemas críticos. El resultado práctico es menos ruido, mejor foco y más consistencia.

Otro escenario: un área de operaciones detecta degradación de rendimiento en endpoints; seguridad sospecha de actividad anómala; TI está saturado de tickets. Sin una vista común, cada equipo opera su propia versión de la realidad. Con una higiene basada en visibilidad y contexto, el diagnóstico y la acción se coordinan con más precisión: se identifican cambios relevantes, se valida postura y se actúa con prioridades compartidas.

Higiene en entornos híbridos y OT: donde el riesgo se vuelve operativo

La higiene de TI se vuelve todavía más importante cuando el entorno no es solo “corporativo”. La mezcla de nube, on-prem, trabajo remoto y, en muchos casos, OT/IoT, amplía el impacto potencial: aquí los incidentes no solo afectan correo o laptops, pueden afectar operación, logística o servicios críticos.

Por eso la higiene no debe verse como “un proyecto del área de TI”, sino como una práctica de resiliencia operativa.

Cómo encaja en un CROC: la higiene como motor de evidencia continua

Si el CROC es la idea de operar el riesgo cibernético de forma continua, entonces la higiene de TI es una de sus fuentes más importantes de evidencia. El CROC necesita datos confiables y actualizados sobre activos, postura y exposición para priorizar, decidir y medir reducción de riesgo. En otras palabras: sin higiene moderna, el riesgo se discute con suposiciones.

Por eso esta serie no es “higiene por higiene”. Es higiene como fundamento de una estrategia de riesgo continua, donde TI, seguridad y negocio pueden sostener una conversación más madura: qué está expuesto, qué importa y qué está bajando realmente.

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

Publicado en

visibilidad o control: el nuevo dilema de los AI crawlers

gestión de AI crawlers y riesgo digital

Escucha este artículo aquí:

Durante años, las organizaciones entendieron el tráfico automatizado con una lógica relativamente simple: bots buenos y bots malos. Los primeros indexaban contenido para buscadores; los segundos intentaban robar credenciales, hacer scraping o degradar servicios. Esa claridad ya no existe.

La irrupción de los AI crawlers —agentes que recorren sitios para alimentar motores de IA, generar respuestas o entrenar modelos— está cambiando la forma en que el contenido digital se consume, se monetiza y, sobre todo, se expone. Y con ello aparece un nuevo dilema estratégico: bloquearlos significa desaparecer de los nuevos canales de descubrimiento; permitirlos sin control implica ceder recursos, datos y ventaja competitiva.

El problema no es técnico, es de negocio

Hoy una parte creciente de la interacción digital ya no comienza en un buscador tradicional, sino en plataformas de IA que sintetizan respuestas completas para el usuario. Quedar fuera de esos resultados implica quedar fuera de los momentos de descubrimiento. Según Radware, los motores de búsqueda basados en IA ya son la fuente preferida de información para una parte significativa de los usuarios, lo que convierte la visibilidad en estos entornos en un tema estratégico.

Pero el otro extremo es igual de complejo. Permitir acceso sin control significa consumir ancho de banda, afectar el rendimiento de aplicaciones y exponer contenido propietario que puede ser reutilizado para fines comerciales sin atribución ni contexto.

En otras palabras, la discusión dejó de ser “seguridad vs acceso” para convertirse en “modelo de negocio vs exposición al riesgo”.

No todos los crawlers son iguales

Uno de los errores más comunes es tratar todo el tráfico automatizado como si tuviera el mismo valor. Algunos agentes citan y dirigen tráfico hacia la fuente original; otros extraen información para entrenar modelos sin generar retorno alguno.

Desde la perspectiva de gestión del riesgo, esto obliga a cambiar el enfoque. Ya no se trata de permitir o bloquear, sino de clasificar por intención y por impacto en el negocio.

Cuando se tiene visibilidad sobre quién accede, cómo lo hace y con qué propósito, la organización puede tomar decisiones alineadas con su estrategia digital: qué contenido se comparte, qué se protege y en qué condiciones.

El impacto operativo que muchas organizaciones no están midiendo

Más allá del debate sobre propiedad intelectual o posicionamiento en la economía de la IA, hay un efecto inmediato que suele pasar desapercibido: la infraestructura.

El tráfico de crawlers consume recursos, distorsiona analítica, afecta tiempos de respuesta y puede alterar la experiencia de usuarios legítimos. Esto no solo es un problema técnico; es un tema de costos, capacidad y continuidad operativa.

Cuando el volumen crece sin control, el resultado es el mismo que en cualquier otro tipo de tráfico automatizado: más inversión en infraestructura para sostener una demanda que no necesariamente genera valor.

De la lógica binaria a la gestión estratégica

El enfoque tradicional de “allow or block” ya no funciona porque el contexto cambió. Gestionar AI crawlers de forma madura implica:

  • entender el valor que aportan para visibilidad y descubrimiento,
  • identificar cuáles representan extracción de valor,
  • aplicar controles dinámicos que equilibren ambas cosas.

Esto transforma la conversación interna. El tema deja de estar únicamente en el equipo de seguridad o en el área digital y pasa a la mesa donde se definen estrategia de contenido, monetización y experiencia de cliente.

Un nuevo frente para la gestión del riesgo digital

Los AI crawlers son un ejemplo claro de cómo el riesgo evoluciona junto con la innovación. No son un ataque en el sentido tradicional, pero sí generan exposición en términos de:

  • rendimiento,
  • costos,
  • propiedad intelectual,
  • posicionamiento digital.

Gestionarlos correctamente significa recuperar control sobre cómo el negocio participa en la economía de la IA.

Qué cambia para la organización

Las organizaciones que entienden este fenómeno dejan de reaccionar a picos de tráfico y comienzan a operar con criterios claros sobre su contenido y su visibilidad.

Esto se traduce en:

  • decisiones conscientes sobre qué compartir y qué proteger,
  • mejor control del uso de infraestructura,
  • analítica más confiable para marketing y negocio,
  • y una postura de riesgo alineada con la estrategia digital.

En un entorno donde la IA redefine la forma en que los usuarios descubren información, la pregunta ya no es si permitir o bloquear crawlers.
La pregunta es cómo gestionarlos sin perder control del negocio.

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

Publicado en

Por qué la ciberseguridad reactiva ya no funciona

ciberseguridad reactiva vs gestión continua del riesgo

Escucha este artículo aquí:

Tabla de contenido

Durante años, el modelo dominante de ciberseguridad ha sido claro: detectar, investigar y responder. Los centros de operaciones de seguridad (SOC) se diseñaron para cumplir con ese objetivo y han sido fundamentales para contener incidentes reales. El problema no está en su existencia, sino en la expectativa que se construyó alrededor de ellos: pensar que reaccionar rápido es lo mismo que reducir riesgo.

Hoy sabemos que no lo es.

Las organizaciones operan en entornos digitales que cambian constantemente. Nuevos activos aparecen todos los días, las configuraciones se modifican, las identidades se mueven entre plataformas y las superficies de ataque crecen sin pausa. En ese contexto, esperar a que una alerta indique que algo está mal significa aceptar que el riesgo ya se materializó en cierta medida. La reacción, por eficiente que sea, siempre llega después.

El falso sentido de control

El enfoque reactivo suele generar una sensación de actividad constante: consolas con eventos en tiempo real, equipos investigando incidentes, reportes de respuesta. Sin embargo, esa intensidad operativa no necesariamente se traduce en una reducción sostenida del riesgo.

Muchas organizaciones pueden responder a incidentes cada vez más rápido y, aun así, mantener la misma exposición estructural durante meses o años. Vulnerabilidades críticas sin remediar, activos desconocidos, configuraciones débiles o privilegios excesivos siguen ahí, fuera del ciclo de las alertas.

Desde la perspectiva del negocio, esto es clave: responder bien no significa estar menos expuesto.

El problema no es la detección, es el momento

La ciberseguridad tradicional se activa cuando algo ya está ocurriendo: un comportamiento anómalo, un intento de explotación, un movimiento lateral. Pero en ese punto el adversario ya encontró una condición favorable.

Gestionar el riesgo de forma moderna implica cambiar la pregunta de
“¿qué está pasando ahora?”
a
“¿qué condiciones existen hoy que podrían convertirse en el próximo incidente?”

Ese cambio de enfoque mueve a la organización de la reacción a la anticipación.

Más herramientas no resuelven el problema

Para compensar este modelo, muchas empresas han sumado nuevas tecnologías. Más visibilidad, más fuentes de datos, más alertas. El resultado suele ser el contrario al esperado: fatiga operativa, prioridades poco claras y equipos enfocados en lo urgente en lugar de lo importante.

El reto no es la falta de información, sino la falta de contexto para entender qué riesgo tiene impacto real en el negocio.

Un modelo moderno no busca generar más eventos, sino reducir de forma medible la exposición.

La brecha entre operación de seguridad y riesgo de negocio

En el enfoque reactivo, los indicadores clave suelen ser técnicos: número de incidentes detectados, tiempo de respuesta, volumen de alertas procesadas. Son métricas valiosas para la operación, pero difíciles de traducir en decisiones estratégicas.

La alta dirección necesita entender otra cosa:
qué tan expuesta está la organización,
qué riesgos afectan procesos críticos,
y qué tan rápido se están reduciendo.

Cuando la seguridad se mide solo en términos de actividad operativa, se vuelve complejo alinear inversiones, prioridades y expectativas de negocio.

Qué cambia cuando el objetivo es reducir riesgo

Un enfoque orientado a la gestión continua del riesgo no reemplaza al SOC ni a la detección. Los pone en contexto.

La diferencia es que la operación deja de girar exclusivamente alrededor de los incidentes y comienza a enfocarse en:

  • identificar condiciones de exposición antes de que sean explotadas,
  • priorizar en función del impacto real en la organización,
  • verificar que las acciones tomadas reduzcan el riesgo de forma tangible.

En lugar de vivir en ciclos de alerta-respuesta, la organización entra en un proceso continuo de mejora de su postura de seguridad.

El impacto en la resiliencia del negocio

Cuando la ciberseguridad deja de ser reactiva, cambia la conversación con el negocio.

Los equipos ya no hablan solo de amenazas detectadas, sino de riesgo reducido.
Las decisiones dejan de basarse en urgencias operativas y se alinean con procesos críticos.
Los recursos se asignan con base en impacto real, no en ruido.

Esto tiene efectos directos en continuidad, cumplimiento y confianza digital.

La seguridad deja de percibirse como un centro de respuesta a crisis y se convierte en una función estratégica que protege la capacidad de la organización para operar.

De la reacción a la operación del riesgo

El reto actual no es responder más rápido, sino necesitar responder menos.

Eso solo ocurre cuando el riesgo se gestiona de forma continua, con visibilidad, priorización y medición real de la reducción de exposición.

Este es el cambio de paradigma que está redefiniendo los modelos de seguridad modernos: pasar de una ciberseguridad basada en eventos a una operación enfocada en riesgo.

Y ese es el terreno donde un enfoque como el de un Cyber Risk Operations Center comienza a tomar sentido.

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

Publicado en

IA y seguridad: cómo innovar sin poner en riesgo tu operación

Escucha este artículo aquí:

La inteligencia artificial (IA) está transformando industrias, acelerando la automatización y potenciando capacidades que antes parecían imposibles. Desde la predicción de tendencias de mercado hasta la personalización de experiencias, las organizaciones están inmersas en una carrera por aprovechar su potencia. Pero esta misma fuerza disruptiva trae consigo un nuevo conjunto de riesgos que, si no se gestionan con visión estratégica, pueden afectar la resiliencia de la operación y los resultados del negocio.

Trend IA, con décadas de trabajo en innovación para la seguridad, aborda este desafío desde dos frentes: proteger el stack de IA y usar IA para fortalecer la ciberseguridad. Esta doble aproximación no solo reduce puntos ciegos, sino que permite a las organizaciones innovar sin comprometer su continuidad operativa.

IA como palanca de innovación y riesgo

La IA está en el centro de las estrategias de transformación digital. Pero a medida que aumenta su adopción, así también lo hace la superficie de riesgo: modelos que podrían manipularse, datos sensibles que podrían exponerse o decisiones automatizadas que podrían ser explotadas por actores maliciosos. Además, la IA está siendo utilizada por cibercriminales para automatizar ataques, adaptar tácticas y evadir defensas tradicionales, lo que cambia radicalmente el panorama de amenazas.

Por otro lado, la IA aplicada de forma responsable dentro de una estrategia de riesgo permite analizar grandes volúmenes de datos, detectar anomalías, anticipar rutas de ataque y disminuir la fatiga de los equipos de seguridad, liberando recursos para tareas de mayor impacto en el negocio.

Seguridad de IA y seguridad con IA: dos caras de una misma moneda

Es importante distinguir entre seguridad de IA y ciberseguridad potenciada con IA. La primera se refiere a proteger los sistemas, modelos y datos que conforman la infraestructura de IA de una organización; la segunda es el uso de IA como herramienta para mejorar la defensa de activos, detectar amenazas y responder en tiempo real.

Una estrategia madura incorpora ambos enfoques: asegurar que los modelos de IA no sean vulnerables a ataques directos o manipulación de datos y, al mismo tiempo, aprovechar capacidades de machine learning para reforzar la detección de amenazas y la respuesta automatizada. Este balance es clave para organizaciones que buscan innovar con IA sin sacrificar la seguridad ni aumentar su exposición al riesgo.

Visibilidad continua y reducción de ambigüedad operativa

Uno de los retos más comunes al adoptar tecnologías de IA es la falta de visibilidad sobre cómo evolucionan los modelos, qué datos consumen o cómo interactúan con otras partes de la infraestructura. Sin esta visibilidad, es difícil evaluar indicadores clave de riesgo, priorizar amenazas o asegurar que los controles sigan siendo efectivos.

Trend IA propone un enfoque integral que combina visibilidad continua de la infraestructura de IA y una plataforma unificada de seguridad, lo que facilita alinear los equipos de desarrollo con los de seguridad y riesgo, eliminando puntos ciegos operativos y mejorando la coordinación entre áreas.

Integrar IA de forma segura: de idea a práctica

Pasar de la intención de usar IA a hacerlo de forma segura implica entender no solo su valor, sino también cómo se gestiona su riesgo en el ciclo de vida completo:

  1. Evaluación de exposición: identificar qué modelos, datos y procesos están sujetos a riesgos asociados con IA y qué impacto potencial tendrían en el negocio.
  2. Priorización de riesgos: no todos los riesgos son iguales; algunos pueden tener impactos críticos en la operación. Priorizar aquellos que afectan continuidad o confianza del cliente es esencial.
  3. Protección y monitoreo continuo: aplicar controles adaptativos que se ajusten a la evolución de la IA, observar anomalías y actualizar la postura de seguridad ante cambios constantes.

Este enfoque transforma la IA de un “proyecto de innovación” a una capa estratégica de resiliencia empresarial, integrando su uso con la gestión de riesgo y la continuidad operativa.

Qué cambia para la organización y para la gestión de riesgo

Adoptar IA de forma segura no solo protege los sistemas frente a amenazas emergentes, sino que:

  • Reduce la fatiga de alertas e impulsa decisiones informadas.
  • Mejora la coordinación entre TI y seguridad al proporcionar visibilidad compartida.
  • Fortalece la postura de riesgo al anticipar y mitigar amenazas antes de que se materialicen.
  • Permite que la innovación digital se alinee con continuidad y cumplimiento, no con silos operativos.

En un mundo donde la IA no solo impulsa competitividad, sino también sofisticación en los ataques, una estrategia de IA que incorpora gestión del riesgo desde el diseño hasta la operación es, hoy, un diferenciador competitivo y un habilitador de resiliencia.

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

Publicado en

Seguridad quantum-safe: por qué importa hoy para la resiliencia de tu negocio

Escucha este artículo aquí:

En la medida en que las organizaciones aceleran su transformación digital, se extiende también su superficie de riesgo: más datos, más interdependencias y más activos críticos que sostienen operaciones cada día. Al mismo tiempo, tecnologías emergentes como la computación cuántica prometen capacidades disruptivas, tanto para habilitar innovación como para desafiar los modelos de seguridad existentes. Ante este panorama, surge un concepto que ya no es opcional para la gestión del riesgo: la seguridad quantum-safe de Palo Alto Networks.

Esta categoría de seguridad no es una moda técnica ni un término futurista: es una respuesta estratégica a la probabilidad creciente de que las técnicas cuánticas puedan romper algoritmos criptográficos tradicionales, poniendo en riesgo la confidencialidad, integridad y disponibilidad de datos críticos. Para líderes de TI, seguridad y negocio, comprender qué es quantum-safe y cómo incorporarlo en la estrategia de riesgo es clave para proteger activos clave en plazos realistas.

De qué hablamos cuando hablamos de “quantum-safe”

La seguridad tradicional se apoya en algoritmos criptográficos —como RSA o ECC— para proteger comunicaciones, identidades y transacciones. Estos algoritmos han sido robustos durante décadas, pero están diseñados bajo supuestos de capacidad computacional clásica. La llegada de ordenadores cuánticos escalables supondría una potencia de cálculo capaz de socavar esos supuestos, debilitando la protección de algoritmos que hoy sostienen transacciones seguras en internet, VPN, cifrado de datos y más.

La seguridad quantum-safe implica el uso de algoritmos y esquemas criptográficos que resisten ataques cuánticos, manteniendo la protección incluso cuando la potencia computacional crece de forma exponencial. Esta transición no es trivial: requiere evaluar, planear e implementar cambios en infraestructura criptográfica que soportan identidad, canales cifrados y firmas digitales que la organización ya usa a diario.

Por qué importa hoy, no mañana

Un error común al hablar de seguridad cuántica es pensar que solo será relevante cuando existan ordenadores cuánticos plenamente funcionales. Aunque ese hito pueda demorarse, el riesgo asociado a la futura ruptura de algoritmos clásicos ya está presente hoy por dos razones:

Primero, el fenómeno del “harvest now, decrypt later”, donde adversarios almacenan datos cifrados hoy con la expectativa de descifrarlos en el futuro con capacidades cuánticas, representa una amenaza para información que debe mantenerse confidencial por largos periodos (p. ej., propiedad intelectual, datos de clientes, transacciones reguladas).

Segundo, la transición a algoritmos quantum-safe no es instantánea. Requiere planificación, pruebas, migración y verificación. Si se deja para último momento, la organización puede quedar expuesta por años durante el periodo de transición.

Desde una perspectiva de gestión del riesgo, esto significa que cuanto antes se evalúe la exposición actual y se planifique la mitigación futura, menor será el impacto potencial a largo plazo.

Seguridad quantum-safe como parte del panorama de riesgo

Incorporar seguridad quantum-safe no implica dejar de lado las prioridades inmediatas —como parches, defensa de endpoints o gestión de identidades— sino considerar una capa más de resiliencia futura. Dicho de otra forma, no se trata de reemplazar las prioridades existentes, sino de ampliar el horizonte temporal de la gestión del riesgo para que incluya vulnerabilidades que pueden tener impacto dentro de años, no solo horas o días.

Esto es especialmente relevante para organizaciones que manejan datos sensibles con requisitos de conservación a largo plazo o que participan en sectores regulados (finanzas, salud, energía), donde la exposición futura podría traducirse en obligaciones legales o pérdidas estratégicas.

Del concepto a la operación: cómo empezar

Gestionar el riesgo con Palo Alto Networks quantum-safe implica tres pasos operativos claros:

Primero, evaluación de exposición. Identificar qué sistemas y datos dependen de criptografía vulnerable y entender qué tanto impacto tendría su ruptura futura.

Segundo, priorización basada en negocio. No todos los criptosistemas ni todos los datos son iguales. Determinar qué debe migrarse primero en función del valor de negocio y del riesgo de exposición prolongada.

Tercero, estrategia de transición. Planear la adopción de algoritmos y esquemas resistentes al cuántico, integrando pruebas, despliegues progresivos y monitoreo continuo para asegurar que la operación no se interrumpe.

Este enfoque transforma la seguridad quantum-safe de una idea “lejana” a una estrategia práctica de gestión del riesgo a largo plazo.

Qué cambia para la organización

Adoptar una visión quantum-safe cambia dos cosas importantes:

Una, extiende el horizonte de la gestión del riesgo. La seguridad deja de ser solo respuesta inmediata y se proyecta hacia amenazas emergentes con impacto estratégico. Esto ayuda a los líderes a preparar presupuestos, talento y arquitecturas que soportan resiliencia no solo hoy, sino mañana.

Dos, favorece una mentalidad más holística de seguridad. Cuando se considera no solo lo que está ocurriendo ahora, sino lo que podría ocurrir de cinco a diez años, las decisiones operativas y tecnológicas se vuelven más robustas, alineadas con continuidad y cumplimiento.

En un mundo digital interconectado donde los datos son el activo más valioso, pensar en la seguridad como un proceso que abarca tanto el presente como el futuro —incluyendo amenazas cuánticas— es una forma madura de gestionar 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