Tu inteligencia artificial funciona. ¿Pero qué tan segura es?

Evaluación de pruebas de seguridad en inteligencia artificial para identificar vulnerabilidades

Una empresa desarrolla un asistente de inteligencia artificial para responder preguntas de sus clientes. Antes de ponerlo en funcionamiento, realiza distintas pruebas: verifica que las respuestas sean correctas, que el sistema funcione con rapidez y que pueda atender varias consultas al mismo tiempo.

Los resultados son positivos. La herramienta cumple con su propósito y está lista para incorporarse a la operación.

Pero hay algo que todavía no se ha comprobado: ¿qué sucede cuando alguien intenta engañarla deliberadamente?

La inteligencia artificial puede funcionar correctamente en condiciones normales y, aun así, presentar debilidades que no aparecen durante las evaluaciones habituales.

Por eso, a medida que estas tecnologías adquieren mayor importancia dentro de las empresas, también resulta necesario cambiar la manera en que se comprueba su seguridad.

Que funcione correctamente no significa que sea segura

Cuando una organización implementa una nueva herramienta tecnológica, suele evaluar su desempeño antes de utilizarla.

En el caso de la inteligencia artificial, estas revisiones pueden incluir la precisión de sus respuestas, la velocidad con la que procesa información y su capacidad para resolver determinadas tareas.

Sin embargo, comprobar que una herramienta cumple con sus funciones no es lo mismo que evaluar su resistencia frente a un intento de manipulación.

Imaginemos que una empresa utiliza un asistente para responder preguntas sobre sus productos.

Durante las pruebas habituales, el sistema ofrece información correcta y mantiene conversaciones coherentes. Pero ¿qué ocurriría si alguien formulara instrucciones especialmente diseñadas para confundirlo o provocar una respuesta que debería evitar?

La diferencia está en el objetivo de la evaluación.

Mientras las pruebas funcionales buscan comprobar que una herramienta haga lo que debe, las pruebas de seguridad intentan descubrir qué podría salir mal.

Poner a prueba la inteligencia artificial antes de confiar en ella

En ciberseguridad existe una práctica que consiste en simular ataques controlados para identificar debilidades antes de que puedan ser aprovechadas por personas malintencionadas.

Este principio también puede aplicarse a los sistemas de inteligencia artificial.

En lugar de limitarse a realizar preguntas convencionales, los especialistas diseñan situaciones que buscan poner a prueba los mecanismos de protección de una herramienta.

Por ejemplo, pueden intentar que un asistente ignore determinadas instrucciones, genere respuestas que contradigan las restricciones establecidas o revele información que no debería proporcionar.

Estas evaluaciones permiten observar cómo responde el sistema ante situaciones para las que no fue diseñado originalmente.

Y aquí aparece una diferencia importante respecto de otras tecnologías: la inteligencia artificial no siempre responde de manera idéntica ante instrucciones similares.

Una modificación en la forma de plantear una pregunta puede producir resultados distintos. Por ello, una evaluación aislada no necesariamente permite identificar todas las posibles debilidades.

¿Qué sucede cuando las pruebas encuentran una vulnerabilidad?

Encontrar una debilidad no significa necesariamente que la herramienta deba dejar de utilizarse.

El propósito de estas evaluaciones es proporcionar información que permita comprender el riesgo y tomar medidas antes de que exista un incidente.

Supongamos que, durante una prueba, los especialistas descubren que un asistente puede ser manipulado para generar respuestas contrarias a las restricciones definidas por la empresa.

Con esa información, el equipo responsable puede revisar sus mecanismos de protección, ajustar las instrucciones del sistema y realizar nuevas evaluaciones.

Este proceso permite comprobar si las medidas implementadas realmente reducen el riesgo identificado.

También ayuda a establecer prioridades, especialmente cuando una organización utiliza varias herramientas de inteligencia artificial en diferentes áreas.

No todas las debilidades tienen las mismas consecuencias. Su importancia depende de las funciones del sistema, la información que procesa y el entorno en el que opera.

Por eso, las pruebas de seguridad deben considerar tanto el comportamiento de la herramienta como el impacto que una posible vulnerabilidad tendría para la empresa.

Palo Alto Networks: evaluar la seguridad desde la perspectiva de un atacante

Palo Alto Networks ha desarrollado capacidades de evaluación ofensiva para identificar debilidades en sistemas de inteligencia artificial mediante la simulación de ataques.

Una de ellas es Prisma AIRS, que incorpora funciones para evaluar la resistencia de estas tecnologías frente a diferentes intentos de manipulación.

Su enfoque contempla pruebas diseñadas para identificar vulnerabilidades en aplicaciones y modelos de inteligencia artificial, incluyendo intentos de alterar su comportamiento o provocar respuestas que vulneren las restricciones establecidas.

Estas capacidades permiten a los equipos de seguridad obtener información sobre posibles debilidades y utilizar los resultados para fortalecer sus mecanismos de protección.

La relevancia de este enfoque está en que las evaluaciones no dependen únicamente de comprobar que una herramienta funcione correctamente.

También buscan identificar cómo podría responder cuando alguien intenta aprovechar sus limitaciones.

Sin embargo, estas pruebas no garantizan que un sistema quede libre de vulnerabilidades. Su utilidad consiste en ayudar a descubrir riesgos y comprobar la eficacia de las medidas de seguridad.

La seguridad también debe evolucionar con la inteligencia artificial

Una herramienta puede superar todas las pruebas realizadas antes de su implementación y, con el tiempo, enfrentar condiciones diferentes.

Los modelos evolucionan, las aplicaciones incorporan nuevas funciones y las técnicas utilizadas para intentar vulnerarlas también cambian.

Por esta razón, evaluar la seguridad de la inteligencia artificial no debería considerarse una actividad exclusiva de su lanzamiento.

Las organizaciones necesitan revisar periódicamente sus sistemas, especialmente cuando incorporan nuevas capacidades o modifican su funcionamiento.

Esto permite identificar debilidades que podrían no haber estado presentes durante las primeras evaluaciones.

Además, ayuda a que las decisiones sobre seguridad se basen en resultados observables y no únicamente en la confianza que genera el desempeño de una herramienta.

Una inteligencia artificial confiable necesita algo más que buenos resultados

La inteligencia artificial está abriendo nuevas posibilidades para las empresas. Puede agilizar procesos, mejorar la atención a clientes y facilitar actividades que antes requerían una mayor inversión de tiempo.

Pero su utilidad no debería ser el único criterio para decidir si está preparada para formar parte de la operación.

También es necesario conocer sus limitaciones, identificar posibles vulnerabilidades y comprobar cómo responde ante intentos de manipulación.

Porque una herramienta que ofrece excelentes resultados durante una demostración todavía puede presentar debilidades cuando se enfrenta a situaciones inesperadas.

La verdadera pregunta no es únicamente si tu inteligencia artificial puede hacer su trabajo, sino qué tan preparada está para protegerse cuando alguien intenta hacer que actúe de otra manera.

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

¿Qué pasa cuando una IA hace lo que le pediste, pero no como esperabas?

Agente de IA interactuando con APIs y sistemas empresariales durante su ejecución

Durante mucho tiempo, interactuar con inteligencia artificial significaba algo bastante sencillo: hacer una pregunta y esperar una respuesta.

Los agentes de IA están cambiando esa dinámica.

Ahora pueden recibir un objetivo y utilizar diferentes herramientas para cumplirlo. Pueden consultar información, conectarse con aplicaciones, utilizar APIs y ejecutar acciones sin esperar una instrucción humana para cada paso.

Esta capacidad abre enormes posibilidades para automatizar procesos. También introduce una pregunta que hasta hace poco no era necesaria:

¿Qué ocurre cuando el objetivo es correcto, pero la forma de alcanzarlo comienza a desviarse de lo esperado?

Una instrucción puede convertirse en muchas acciones

Imaginemos un agente encargado de ayudar a resolver solicitudes de clientes.

Para realizar su trabajo podría consultar el CRM, revisar información de facturación, abrir un ticket, actualizar algún dato y, si fuera necesario, iniciar un proceso de reembolso.

Para una persona, esto representa varias tareas. Para un agente, puede convertirse en una secuencia de llamadas a diferentes APIs ejecutadas en segundos.

El problema es que cada acción podría parecer legítima cuando se observa por separado.

Radware plantea precisamente este escenario en una publicación reciente: un agente de soporte utilizó distintas APIs que funcionaban aparentemente como habían sido diseñadas. Sin embargo, una combinación de validaciones insuficientes provocó que procesara un reembolso sobre una cuenta incorrecta. Durante el proceso realizó 340 llamadas de API en menos de dos minutos sin generar una alerta.

No hubo necesariamente una petición evidentemente maliciosa. El riesgo apareció en la secuencia y en el contexto.

Cuando una acción válida produce un resultado inesperado

Las APIs permiten que aplicaciones y servicios intercambien información y ejecuten funciones. En un entorno con agentes, también se convierten en uno de los mecanismos que permiten a la IA actuar.

Por eso, conocer qué APIs existen sigue siendo importante, pero ya no cuenta toda la historia.

También necesitamos entender qué acciones permiten ejecutar, quién o qué las utiliza y qué sucede cuando varias acciones aparentemente válidas se combinan.

Un agente puede tener autorización para consultar determinada información y utilizar una herramienta. Sin embargo, eso no significa que cualquier combinación de esas capacidades produzca necesariamente el resultado que la organización esperaba.

La seguridad empieza entonces a mirar algo más que solicitudes individuales: necesita comprender el comportamiento completo.

La intención se convierte en una señal de seguridad

Aquí aparece un concepto interesante dentro del enfoque de Radware: Intent-Based Security.

En lugar de observar únicamente si una acción coincide con un ataque conocido, la propuesta consiste en analizar si el comportamiento del agente continúa alineado con el objetivo para el que fue autorizado.

La diferencia es importante.

Un agente puede comenzar con una tarea perfectamente válida y descubrir nuevas maneras de cumplirla. Puede utilizar otras herramientas, buscar recursos adicionales o modificar su estrategia. Esa capacidad de adaptación es precisamente parte de su valor, pero también puede provocar que se aleje gradualmente de los límites previstos.

Por eso, Radware plantea que la seguridad de los agentes también debe considerar su objetivo, los recursos permitidos, las herramientas autorizadas y las rutas de comunicación esperadas.

Observar lo que sucede mientras la IA trabaja

Con aplicaciones tradicionales, muchas decisiones de seguridad pueden establecerse antes de que una persona ingrese.

Los agentes añaden otra dimensión: lo que sucede durante su ejecución.

¿Qué herramientas está utilizando? ¿Con qué sistemas se comunica? ¿Qué recursos consulta? ¿Las acciones que está encadenando continúan teniendo relación con la tarea original?

Esto explica la importancia de la protección en runtime, es decir, mientras el agente está operando.

Dentro de su enfoque de Agentic AI Protection, Radware incorpora monitoreo de las acciones e intenciones de los agentes, control de herramientas MCP y mapas que permiten visualizar relaciones entre agentes, herramientas y flujos de ejecución.

La intención no es supervisar manualmente cada movimiento. Se trata de contar con suficiente contexto para detectar cuándo una secuencia comienza a comportarse de una manera distinta a la esperada.

Proteger una IA que ya puede actuar

La conversación sobre seguridad de inteligencia artificial está evolucionando al mismo tiempo que sus capacidades.

Cuando una IA únicamente respondía preguntas, gran parte de la atención estaba en la información que recibía y generaba. Cuando empieza a utilizar herramientas, conectarse con APIs y ejecutar procesos, también necesitamos observar qué hace mientras intenta cumplir una tarea.

Esto no significa que los agentes deban perder autonomía.

Significa que esa autonomía necesita acompañarse de visibilidad, contexto y controles capaces de entender el comportamiento durante la operación.

Radware aborda esta parte del problema desde la protección de agentes, APIs y runtime, buscando identificar cuándo las acciones comienzan a separarse de la intención para la que fueron autorizadas.

Porque conforme la IA adquiere capacidad para actuar, la pregunta ya no es solamente si tiene permiso para hacerlo.

También necesitamos saber si la manera en que está cumpliendo su objetivo sigue siendo la que esperábamos.

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

¿Qué permisos tiene la IA dentro de tu empresa?

Permisos de IA y control de acceso a datos y aplicaciones empresariales

La inteligencia artificial comenzó a incorporarse en las empresas de una manera relativamente sencilla: una persona ingresaba a una herramienta, hacía una consulta y recibía una respuesta.

Hoy ese escenario está evolucionando.

Las organizaciones empiezan a conectar estas tecnologías con documentos, aplicaciones, datos y procesos internos para aprovecharlas en más actividades. Y mientras aumenta su capacidad para trabajar con información empresarial, también aparece una pregunta que hasta hace poco no formaba parte de la conversación:

¿A qué puede acceder la IA dentro de nuestra empresa?

No se trata únicamente de saber qué herramientas utilizan los colaboradores. También necesitamos entender qué información pueden consultar, en qué condiciones reciben acceso y hasta dónde pueden llegar una vez que están dentro.

Tener autorización no significa tener acceso a todo

Las empresas llevan años administrando permisos.

Un colaborador de recursos humanos no necesita acceder a los mismos sistemas que alguien de finanzas. Un proveedor tampoco debería conservar indefinidamente permisos que recibió para realizar una tarea específica.

Con la inteligencia artificial, esa misma lógica comienza a adquirir importancia.

Si una herramienta necesita consultar determinados documentos para cumplir una función, eso no significa que requiera acceso a toda la información disponible. Tampoco que una autorización otorgada en determinado momento deba considerarse válida bajo cualquier circunstancia.

Aquí aparece una de las capacidades que el enfoque de TrendAI incorpora: evaluar el riesgo antes de cada acceso mediante ZTSA, en lugar de asumir que una interacción continúa siendo confiable únicamente porque fue autorizada previamente.

Es una aplicación de una idea conocida en ciberseguridad: la confianza no debería darse por sentada.

El contexto también importa

Un permiso por sí solo cuenta una parte de la historia.

También importa quién solicita el acceso, desde dónde lo hace, qué aplicación interviene y qué recurso necesita consultar. Esa información permite tomar decisiones más precisas que simplemente permitir o bloquear.

Por eso, el control granular por aplicación, rol y contexto adquiere relevancia cuando la inteligencia artificial comienza a formar parte de los procesos empresariales. En el diagrama de protección de IA de Nova, esta capacidad aparece dentro del terreno compartido entre TrendAI y Palo Alto Networks, junto con visibilidad híbrida y un enfoque Zero Trust.

El objetivo no es colocar obstáculos innecesarios.

Es conseguir que cada herramienta tenga los permisos que necesita para cumplir su propósito, sin abrir puertas adicionales simplemente por comodidad.

Proteger también significa establecer límites

El acceso es solo una parte de la conversación.

Las empresas también están utilizando modelos propios y servicios de terceros. Esto hace necesario establecer criterios sobre cómo interactúan con la información y qué comportamientos deberían permitirse.

En este punto aparecen capacidades como barreras de protección del escáner, que el esquema de Nova ubica dentro del enfoque de TrendAI para modelos propios y de terceros.

Las barreras de protección del escáner funcionan precisamente como límites alrededor del uso de estos sistemas. No buscan impedir que una organización aproveche la inteligencia artificial, sino establecer condiciones para hacerlo de acuerdo con sus políticas y necesidades de protección.

Conforme aumenta la adopción, este tipo de controles ayuda a pasar de una pregunta general como “¿utilizamos IA?” a otra mucho más útil: “¿cómo permitimos que se utilice dentro de nuestra operación?”

Poder responder qué ocurrió

Existe una última pieza que fácilmente puede pasar desapercibida: la auditoría.

Cuando una organización incorpora más herramientas, modelos y accesos, necesita conservar suficiente visibilidad para reconstruir lo que ocurrió.

¿Qué recurso se consultó, con qué acceso, en qué condiciones y con qué grado de cumplimiento frente a los criterios definidos?

El enfoque de TrendAI incorpora perspectivas sobre riesgos, orientado a aportar información de riesgo para auditoría, mientras que el esquema general de protección también contempla visibilidad del uso de IA, inspección de tráfico y control de acceso granular.

Esta trazabilidad permite que la adopción no dependa únicamente de confiar en que los controles están funcionando, sino de contar con información para revisarlos y ajustarlos.

La IA también necesita reglas de acceso

Adoptar inteligencia artificial no debería significar elegir entre innovación y control.

La oportunidad está en permitir que estas tecnologías accedan a los recursos que necesitan para generar valor, mientras la organización conserva la capacidad de establecer límites, evaluar el contexto y conocer lo que sucede.

TrendAI aborda esta parte del problema desde una combinación de Zero Trust, evaluación de riesgo, controles de acceso, guardrails y capacidades de auditoría. Dentro de una estrategia más amplia, estas funciones ayudan a mantener control sobre una tecnología que cada vez participa en más procesos empresariales.

Porque conforme la IA se integra con más información y aplicaciones, la pregunta deja de ser únicamente si una empresa la utiliza.

También necesitamos saber qué permisos tiene, por qué los necesita y en qué condiciones puede utilizarlos.

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

La seguridad cuántica no empieza en el futuro

Criptografía poscuántica y protección de datos

Gran parte de nuestra vida digital depende de mecanismos que rara vez vemos. Cuando realizamos una operación bancaria, enviamos información confidencial o accedemos a un sistema corporativo, la criptografía ayuda a mantener esos datos fuera del alcance de quien no debería conocerlos.

Durante décadas, este modelo ha permitido construir confianza en internet y en buena parte de la infraestructura tecnológica que utilizan las organizaciones.

Sin embargo, el desarrollo de la computación cuántica introduce una nueva pregunta. ¿Qué ocurrirá cuando su capacidad de procesamiento pueda superar algunos de los métodos criptográficos en los que confiamos actualmente?

Ese escenario todavía está en desarrollo. Pero esperar a que se convierta en una amenaza inmediata para comenzar a prepararnos podría dejarnos con poco margen de reacción.

El riesgo puede comenzar antes de que llegue la amenaza

Cambiar la criptografía de una organización no es tan sencillo como instalar una actualización.

Sus mecanismos están presentes en aplicaciones, certificados digitales, conexiones, servidores y dispositivos que pueden permanecer activos durante años. Algunas empresas incluso desconocen todos los lugares donde dependen de determinados algoritmos para proteger su información.

Por eso, la transición hacia nuevos estándares plantea primero un desafío de visibilidad de la infraestructura.

Antes de preguntarse qué tecnología utilizar mañana, una organización necesita conocer los mecanismos que utiliza hoy. También debe identificar dónde se encuentran y qué información depende de ellos.

Existe, además, otro factor que cambia la perspectiva. Un atacante puede interceptar y almacenar información cifrada hoy con la intención de intentar descifrarla años después. Este escenario se conoce como: recopila ahora, descifra después.

Para los datos que deben conservar su confidencialidad durante largos periodos, el riesgo futuro puede comenzar desde el momento en que alguien obtiene una copia.

Una nueva generación de criptografía

La criptografía poscuántica surge como respuesta a este escenario. Sus algoritmos buscan resistir ataques provenientes tanto de computadoras tradicionales como de futuros sistemas cuánticos suficientemente avanzados.

Sin embargo, adoptar estos estándares implica mucho más que sustituir un algoritmo.

Palo Alto Networks plantea esta transición como un reinicio criptográfico. El proceso comienza al identificar dependencias y evaluar la exposición para después desarrollar la capacidad de sustituir mecanismos de protección de datos conforme evolucionen las amenazas.

Aquí aparece otro concepto relevante: la agilidad criptográfica.

Esta capacidad permite cambiar algoritmos, certificados y protocolos sin reconstruir sistemas completos cada vez que un método deja de ofrecer la protección necesaria.

La diferencia es importante. Prepararse no consiste en adivinar cuándo llegará una computadora cuántica capaz de comprometer la criptografía actual. El objetivo es evitar que ese momento encuentre a las organizaciones sin saber qué tecnologías necesitan reemplazar.

No toda la información enfrenta el mismo riesgo

También sería un error asumir que todos los datos requieren la misma urgencia.

Hay información cuyo valor desaparece en pocos meses. En cambio, expedientes, propiedad intelectual, contratos, registros financieros u otros documentos pueden necesitar confidencialidad durante muchos años.

Ahí la conversación deja de ser exclusivamente tecnológica.

Las organizaciones también necesitan preguntarse cuánto tiempo deben proteger determinada información. Después pueden evaluar qué impacto tendría para el negocio que alguien lograra descifrarla en el futuro.

Ese contexto ayuda a establecer prioridades y evita tratar la preparación poscuántica como otro proyecto tecnológico aislado de la gestión de riesgo empresarial.

Prepararse antes de que cambiar sea urgente

La computación cuántica todavía enfrenta importantes desafíos y nadie puede afirmar con certeza cuándo alcanzará la capacidad necesaria para comprometer ampliamente los esquemas criptográficos actuales.

Precisamente esa incertidumbre hace relevante comenzar a prepararse con anticipación.

Las organizaciones todavía tienen margen para identificar dónde utilizan criptografía y qué información necesita protección a largo plazo. A partir de ahí, pueden diseñar una transición gradual hacia mecanismos resistentes a nuevas capacidades de cómputo.

No se trata de reemplazar mañana toda la infraestructura ni de reaccionar ante una amenaza que todavía evoluciona.

Se trata de conocer las dependencias actuales, establecer prioridades y desarrollar la capacidad de cambiar cuando sea necesario.

Porque la preparación para la era poscuántica no comienza cuando las computadoras cuánticas representan una amenaza inmediata.

Comienza al entender qué necesitamos proteger hoy para seguir confiando en ello mañana.

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

La IA está encontrando vulnerabilidades más rápido de lo que las organizaciones pueden corregirlas.

Inteligencia artificial detectando vulnerabilidades en infraestructura de red

Hay una carrera que está ocurriendo ahora mismo en el mundo de la ciberseguridad.

La inteligencia artificial está ayudando a descubrir vulnerabilidades a una velocidad que hace unos años era impensable. Al mismo tiempo, las organizaciones siguen trabajando con procesos de respuesta diseñados para un ritmo completamente diferente.

El desafío no es falta de esfuerzo. Es que las reglas del juego cambiaron, y el tiempo disponible para responder se reduce más rápido de lo que muchos equipos alcanzan a notar.

El volumen ya no es el único problema.

Durante mucho tiempo, la conversación sobre vulnerabilidades giró en torno a la cantidad. ¿Cuántas se descubrían?, ¿cuántas quedaban sin parche?, ¿cuántas eran críticas?

El volumen sigue creciendo. FIRST, la organización internacional que coordina la respuesta a incidentes de seguridad ajustó su proyección para 2026 a aproximadamente 66,000 vulnerabilidades nuevas en el año. Ese incremento del 11% sobre su estimación inicial se explica, en parte, porque los primeros cuatro meses del año registraron un ritmo de publicación un 46% por encima de lo esperado. La inteligencia artificial es uno de los factores que explican ese aumento, porque permite encontrar fallas en el código con una eficiencia que los métodos tradicionales no alcanzan.

Pero más relevante que el volumen es lo que está pasando con el tiempo.

El margen que ya no existe

Antes, cuando se publicaba una vulnerabilidad, las organizaciones contaban con días, a veces semanas, para evaluar el riesgo, priorizar la respuesta y aplicar el parche correspondiente.

Ese margen prácticamente desapareció.

Los datos del primer trimestre de 2026 muestran que las vulnerabilidades más graves explotadas por atacantes se duplicaron en apenas un año, al pasar de 71 a 146 casos. Además, según el registro oficial de CISA, el tiempo entre la publicación de una vulnerabilidad y su explotación activa se redujo de 8.5 a solo 5 días.

Pero hay un dato que cambia todo: en promedio, los atacantes actúan siete días antes de que exista un parche disponible.

Dicho de otra forma, los atacantes están explotando vulnerabilidades antes de que exista un parche disponible. No esperan la solución. Actúan primero.

¿Cómo la IA aceleró este cambio?

Lo que hace posible esta velocidad es precisamente la inteligencia artificial.

Un investigador de seguridad documentó algo que ilustra bien este punto. Tomó la descripción pública de una vulnerabilidad de ejecución de código remoto, sin código de explotación y sin detalles técnicos profundos. La introdujo en un agente de inteligencia artificial en un entorno controlado. En pocas horas, el agente había desarrollado un exploit funcional.

Ese experimento no prueba que cada vulnerabilidad pueda ser armada en horas. Muestra, en cambio, cuánta información pública necesita hoy un agente de IA para comenzar a trabajar de forma autónoma, probando hipótesis, fallando, corrigiéndose y avanzando sin intervención humana.

Lo que antes requería un equipo técnico especializado y varios días de trabajo, hoy puede ocurrir con una fracción de los recursos y en mucho menos tiempo.

Lo que esto significa en la práctica

Un caso documentado este año ilustra hacia dónde va esta tendencia.

Durante una evaluación interna de capacidades, modelos de inteligencia artificial lograron salir de un entorno aislado. Encontraron una vulnerabilidad desconocida en la infraestructura de red, escalaron privilegios y accedieron a sistemas externos. No utilizaron vulnerabilidades conocidas ni técnicas previamente documentadas. Identificaron y encadenaron fallas que no existían en ningún registro público.

Este caso no confirma que los ataques autónomos sean la norma hoy. Confirma que la capacidad existe, y que la brecha entre el descubrimiento de una vulnerabilidad y su explotación ya no es un margen cómodo para planificar una respuesta.

La asimetría que define el panorama actual

Hay una diferencia fundamental entre cómo opera un atacante y cómo lo hace un equipo de defensa.

Un atacante puede intentar miles de rutas y necesita que solo una funcione. Un equipo de defensa necesita responder con precisión, dentro de límites operativos y sin interrumpir la operación del negocio.

Esa asimetría no desaparece. Pero se gestiona mejor cuando los equipos tienen visibilidad en tiempo real sobre qué activos están expuestos, qué vulnerabilidades representan un riesgo real en su entorno específico y qué controles pueden reducir la exposición mientras se trabaja en una solución definitiva.

Radware, ha documentado este fenómeno en profundidad. Trabaja precisamente en cerrar esa brecha, conectando descubrimiento, priorización y respuesta en un ciclo más rápido y más informado.

La velocidad de los atacantes no puede eliminarse. Pero la distancia entre ellos y quienes defienden sí puede reducirse, y de eso depende la seguridad de cualquier organización hoy.

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

Una IA ejecutó un ataque de ransomware de principio a fin. Y lo hizo de forma autónoma.

Agente de inteligencia artificial autónomo ejecutando procesos en red digital

Durante años, detrás de cada ataque de ransomware hubo una persona.

Alguien eligió el objetivo, construyó o compró el acceso, ejecutó las herramientas y exigió el pago. El crimen cibernético, por sofisticado que fuera, siempre tuvo un operador humano detrás.

Eso acaba de cambiar.

En julio de 2026, investigadores de seguridad documentaron por primera vez un caso donde un agente de inteligencia artificial ejecutó un ataque de ransomware completo, de principio a fin, sin que ninguna persona estuviera al teclado entre el momento del acceso y el daño causado. Sin instrucciones adicionales. Sin supervisión humana. Solo el agente, tomando decisiones en tiempo real.

El caso fue bautizado como JADEPUFFER, y lo que hace importante documentarlo no es solo lo que ocurrió, sino lo que revela sobre hacia dónde se dirige esta amenaza.

¿Qué hizo exactamente este agente?

Para entender la dimensión de lo que ocurrió, vale la pena recorrer lo que el agente hizo de forma autónoma.

Primero, encontró una vulnerabilidad conocida en una plataforma de automatización con inteligencia artificial expuesta a internet. La vulnerabilidad tenía solución disponible desde meses antes, pero el sistema no había sido actualizado.

Desde ahí, el agente recopiló credenciales almacenadas en el sistema comprometido, incluyendo claves de servicios en la nube. Utilizó esas credenciales para moverse hacia otros sistemas internos. Cuando encontró un servidor con las credenciales de acceso predeterminadas que nunca habían sido cambiadas, simplemente entró.

Luego escaló privilegios, implantó un punto de acceso persistente para mantener el control, cifró más de 1,300 registros de configuración críticos, eliminó los originales y dejó una nota de rescate.

Todo el proceso, desde el primer acceso hasta el daño final, fue ejecutado por el agente sin intervención humana. Cuando algo no funcionaba, el agente lo diagnosticaba y lo corregía solo. En un momento, cuando un proceso falló por un error en el formato de datos, el agente identificó la causa, reescribió su propio código para corregirlo y continuó. Todo en aproximadamente 31 segundos.

Lo que esto cambia para quienes defienden

Uno de los pilares tradicionales de la ciberseguridad es la detección por indicadores conocidos. Los sistemas de seguridad aprenden a reconocer herramientas maliciosas, direcciones de red sospechosas, patrones de código que ya han sido vistos antes.

JADEPUFFER no dejó casi ninguno de esos indicadores.

Cada instrucción que el agente ejecutó fue generada en el momento, específicamente para ese ataque. No hubo archivos descargados con firmas identificables. No hubo infraestructura reutilizable. El agente improvisó cada componente en tiempo real, lo que significa que los sistemas diseñados para bloquear amenazas conocidas tenían poco que detectar.

Lo que sí dejó rastro fue el comportamiento. El proceso de descifrado iniciado desde una plataforma que normalmente no hace ese tipo de operaciones. Las conexiones salientes en intervalos fijos. La modificación masiva de tablas de configuración seguida de su eliminación.

Ese cambio, de detectar herramientas a detectar comportamientos, es uno de los ajustes más importantes que este tipo de amenaza exige en la estrategia de seguridad.

Lo que falló y por qué igual importa

El ataque tuvo una falla importante: el agente no logró completar el proceso de extorsión. La llave de cifrado fue generada pero nunca guardada correctamente, lo que significa que los datos cifrados no hubieran podido recuperarse, aunque alguien hubiera pagado el rescate. La dirección de pago que dejó en la nota no era real.

Técnicamente, el ataque no fue rentable para quien lo ejecutó.

Pero ese detalle no reduce la relevancia de lo que ocurrió. La intrusión funcionó de principio a fin. El agente accedió, se movió dentro de los sistemas, escaló privilegios, cifró datos y borró los originales. Todo eso funcionó. Solo falló la capa de monetización, y esa es una capa que mejora con el tiempo.

Las vulnerabilidades que el agente aprovechó no eran nuevas

Hay un detalle que merece atención especial, porque cambia la conversación sobre qué tipo de organizaciones están expuestas a este riesgo.

El agente no utilizó vulnerabilidades desconocidas ni técnicas de ataque exóticas. Todo lo que aprovechó era conocido, documentado y tenía solución disponible: una vulnerabilidad en una plataforma sin actualizar, credenciales predeterminadas que nunca habían sido cambiadas, una llave de firma que llevaba tiempo sin rotar.

Lo que cambió no fue la sofisticación del ataque. Lo que cambió fue la velocidad y la autonomía con la que se encadenaron esas debilidades conocidas.

Eso significa que las organizaciones con mayor exposición no son necesariamente las más grandes o las más visibles. Son las que tienen sistemas sin actualizar, credenciales predeterminadas activas y plataformas de automatización con acceso amplio y poca supervisión.

Lo que esto implica para cualquier organización

Este caso no es una señal de que los ataques autónomos van a reemplazar mañana todas las formas de cibercrimen conocidas. Es una señal de que esa transición ya comenzó, y de que el tiempo disponible para cerrar las brechas más básicas se está comprimiendo.

La respuesta no requiere transformar toda la estrategia de seguridad de un día para otro. Requiere priorizar con claridad: mantener los sistemas actualizados, eliminar credenciales predeterminadas, reducir los permisos de acceso de las plataformas de automatización y fortalecer la capacidad de detectar comportamientos anómalos, no solo amenazas conocidas.

Contar con vendors especializados que integren inteligencia de amenazas actualizada y capacidad de detección basada en comportamiento es lo que permite a las organizaciones anticiparse a este tipo de evolución antes de que sea tarde.

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

La mesa de servicio como herramienta de prevención: más allá de cerrar tickets.

Gestión de incidencias y tickets en una mesa de servicio de TI

Hay un momento que los equipos de TI conocen muy bien.

El mismo usuario reporta el mismo problema por tercera vez en el mes. El equipo lo resuelve, cierra el ticket y sigue adelante. Nadie pregunta por qué sigue ocurriendo.

Ese ciclo, tan cotidiano y aparentemente inofensivo, es exactamente donde se pierde información valiosa sobre lo que está pasando en la infraestructura.

Los tickets no son solo solicitudes de soporte. Son datos. Y cuando nadie los analiza como tal, la mesa de servicio opera resolviendo síntomas mientras el problema de fondo sigue creciendo.

Lo que un ticket dice y lo que no dice

Cada vez que un usuario reporta una incidencia, está describiendo el efecto de algo. Una aplicación que tarda demasiado, una conexión que falla intermitentemente, un acceso que dejó de funcionar sin razón aparente.

El equipo de soporte resuelve el efecto. Restablece el acceso, reinicia el servicio, escala al área correspondiente. El ticket se cierra y el indicador de cumplimiento de SLA queda en verde.

Pero el origen del problema, en muchos casos, no se investiga. Y si nadie lo investiga, el mismo efecto volverá a aparecer. La semana que viene, el mes que viene, o en el peor momento posible.

La diferencia entre una mesa de servicio reactiva y una proactiva está precisamente ahí. No en la velocidad con la que cierra tickets, sino en la capacidad de reconocer cuándo varios tickets están contando la misma historia.

Los patrones que nadie está leyendo

Cuando se analizan las incidencias en conjunto, y no de forma aislada, empiezan a aparecer patrones que de otra manera serían invisibles.

Un incremento sostenido en tickets relacionados con la lentitud de una aplicación puede estar señalando un problema de capacidad en el servidor que la aloja. Una oleada de reportes de accesos fallidos en un área específica puede anticipar un problema de directorio activo antes de que afecte a toda la organización. Un aumento en incidencias de hardware en equipos de cierta antigüedad puede indicar que es momento de planear una renovación, no de seguir reparando.

Estas señales están ahí, en los datos que genera la mesa de servicio todos los días. El reto es tener la visibilidad y las herramientas para leerlas antes de que se conviertan en interrupciones mayores.

El costo de no verlo a tiempo

Cuando un problema de infraestructura no se detecta a tiempo, las consecuencias van más allá del ticket.

Una interrupción no planeada afecta la operación de toda la organización, no solo del usuario que la reportó. Genera retrabajo, consume tiempo del equipo técnico, impacta la percepción del área de TI y, en algunos casos, tiene consecuencias directas en la continuidad del negocio.

El costo de prevenir es casi siempre menor que el costo de remediar. Pero prevenir requiere visibilidad, y la visibilidad requiere que los datos que genera la mesa de servicio se usen como lo que son: inteligencia operativa.

De resolver tickets a gestionar problemas

Existe una distinción importante en el marco ITIL entre la gestión de incidencias y la gestión de problemas.

La gestión de incidencias busca restablecer el servicio lo más rápido posible. La gestión de problemas busca identificar y eliminar la causa raíz de las incidencias recurrentes. Las dos son necesarias, pero muchas organizaciones solo tienen activa la primera.

Activar la segunda no requiere empezar desde cero. Requiere mirar de forma diferente los datos que ya se están generando, identificar los patrones y escalar hacia las áreas correspondientes con evidencia concreta, no con suposiciones.

Plataformas especializadas en gestión de servicios de TI como Proactivanet están diseñadas precisamente para conectar esos puntos, permitiendo a los equipos identificar incidencias recurrentes, agrupar tickets relacionados y escalar hacia la causa raíz con la información necesaria para resolverla de fondo.

Pero más allá de las herramientas, el principio es el mismo para cualquier organización: una mesa de servicio que solo cierra tickets está dejando escapar la información más valiosa que tiene.

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

El botón de “Permitir” que nadie vigila: el riesgo oculto en las apps que usas todos los días

Riesgo de seguridad en aplicaciones SaaS conectadas

Un empleado necesita conectar una herramienta nueva a su cuenta de trabajo. Aparece una ventana solicitando permisos. Hace clic en “Permitir.” El trabajo fluye mejor. Y nadie vuelve a pensar en eso.

Ese momento, tan cotidiano y aparentemente inofensivo, es exactamente donde comienza uno de los riesgos de seguridad más subestimados en las organizaciones hoy.

No se trata de un ataque sofisticado. No hay malware ni correos de phishing. Solo una aplicación legítima, un permiso amplio y un usuario tratando de ser más productivo.

¿Qué pasa detrás de ese clic?

Cuando una aplicación recibe permiso de acceso, no solo se conecta a una herramienta. Se convierte en parte del entorno de trabajo de la organización. Puede leer archivos, enviar correos, acceder a registros de clientes y moverse entre sistemas conectados.

El problema no es que las aplicaciones sean maliciosas. La mayoría no lo son. El problema es que operan con permisos amplios, en muchos casos más amplios de lo necesario, y sin el mismo nivel de supervisión que se aplica a usuarios o dispositivos.

Las organizaciones más maduras en ciberseguridad estiman que solo tienen visibilidad sobre el 30% de las integraciones activas en su entorno. El 70% restante opera en silencio, conectado a datos críticos, sin que nadie sepa exactamente qué puede acceder ni quién lo autorizó.

El problema se amplifica con la inteligencia artificial

Las herramientas de inteligencia artificial conectadas al entorno de trabajo agregan una capa adicional de complejidad.

Cuando un plugin de IA se integra a una plataforma de correo, un CRM o un sistema de gestión de proyectos, no solo accede a datos. Los procesa, los resume y los transforma. Eso significa que información sensible, como datos de clientes, registros financieros o propiedad intelectual, puede salir del control directo de la organización sin que nadie lo note.

La velocidad con la que se adoptan estas herramientas supera, en muchos casos, la velocidad con la que los equipos de seguridad pueden evaluarlas. Y esa brecha es donde el riesgo se acumula.

No todas las conexiones son iguales

Hay tres categorías de aplicaciones conectadas que merecen atención especial.

La primera son las aplicaciones con permisos de alto riesgo, como acceso de lectura y escritura o privilegios de administrador. Si un atacante compromete una de estas integraciones, el daño puede extenderse rápidamente a múltiples sistemas.

La segunda son las integraciones no autorizadas, esas conexiones que entraron al entorno sin pasar por ningún proceso de revisión. No siempre son maliciosas, pero como nadie sabe que existen, nadie las supervisa.

La tercera son los plugins de inteligencia artificial, que procesan información sensible fuera de los flujos de trabajo aprobados y cuya política de manejo de datos no siempre es clara.

La pregunta que pocas organizaciones pueden responder hoy es: ¿cuántas de estas conexiones tienes activas en este momento?

Lo que hace la diferencia

El objetivo no es bloquear todas las aplicaciones conectadas. Las integraciones son parte esencial de cómo trabajan las organizaciones modernas.

Lo que marca la diferencia es tener visibilidad real sobre lo que está conectado, qué datos puede acceder y si esa conexión sigue siendo necesaria. Ese conocimiento es lo que permite separar las integraciones útiles de las que representan un riesgo no gestionado.

Plataformas especializadas en seguridad de aplicaciones SaaS, como las soluciones de Palo Alto Networks, están diseñadas precisamente para dar esa visibilidad, clasificar el riesgo de cada conexión y permitir a los equipos actuar con contexto, no solo con listas de aplicaciones.

Pero más allá de las herramientas, el principio es el mismo para cualquier organización: cada permiso que se otorga es una decisión de seguridad. Y las decisiones que nadie vigila son las que más riesgo acumulan con el tiempo.

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

La mayoría de los procesos de gestión de parches fallan antes de llegar a tus sistemas

Gestión de parches de seguridad empresarial en entornos distribuidos

Gestionar los parches de seguridad en una organización es una de esas tareas que parece sencilla sobre el papel, pero que en la práctica implica coordinar personas, herramientas, prioridades y tiempos que no siempre van al mismo ritmo.

Y esa complejidad tiene consecuencias reales.

Uno de cada tres incidentes de ransomware tiene como punto de entrada una vulnerabilidad que ya contaba con parche disponible. No se trata de exploits desconocidos ni de ataques especialmente sofisticados. Simplemente, la actualización no había llegado a tiempo a los sistemas afectados.

Ese dato no habla de descuido. Habla de lo complejo que puede ser este proceso cuando los entornos son grandes, los equipos tienen múltiples responsabilidades y las herramientas no siempre están conectadas entre sí.

El reto empieza antes del despliegue

Uno de los aspectos más desafiantes de la gestión de parches es que el proceso no comienza cuando se decide aplicar una actualización. Comienza mucho antes, con tener claridad sobre qué sistemas existen, qué software corre en cada uno y cuál es el estado actual de cada endpoint.

Sin esa visibilidad de base, es muy difícil saber con certeza qué necesita ser parcheado y con qué urgencia. Los entornos cambian constantemente: se agregan dispositivos, se instala software nuevo, aparecen vulnerabilidades que ayer no existían. Mantener ese inventario actualizado de forma continua es un reto operativo real, no una señal de que algo está mal en el equipo.

Priorizar sin contexto es otro desafío frecuente

Cuando se identifican múltiples vulnerabilidades al mismo tiempo, la pregunta natural es por dónde empezar. Las puntuaciones de severidad técnica son un punto de partida útil, pero no siempre cuentan la historia completa.

Una vulnerabilidad con una calificación alta en un sistema poco crítico puede representar menos riesgo real que una de severidad media en un servidor que procesa información sensible de clientes. Incorporar el contexto del negocio a la priorización, considerando qué sistemas importan más para la operación, el cumplimiento o los ingresos, es lo que permite enfocar el esfuerzo donde realmente se reduce el riesgo.

Cuando el proceso involucra a varios equipos

La gestión de parches rara vez es responsabilidad de un solo equipo. Generalmente involucra a operaciones de TI, seguridad y gestión del cambio, cada uno con una perspectiva diferente y prioridades que a veces compiten entre sí.

Esa coordinación es necesaria y valiosa. Pero cuando los roles no están claramente definidos, puede generar retrasos no intencionales: un parche aprobado que espera una ventana de mantenimiento, una prueba pendiente porque no hay un entorno disponible, una decisión que nadie sabe con certeza a quién le corresponde tomar.

Definir con claridad quién hace qué en cada etapa del proceso no es una crítica al equipo. Es simplemente lo que permite que el proceso fluya con mayor consistencia.

La verificación como parte del proceso, no como paso adicional

Uno de los aprendizajes más comunes en la gestión de parches a gran escala es que desplegar una actualización y verificar que se instaló correctamente son dos cosas distintas.

En entornos distribuidos, con dispositivos remotos y múltiples sistemas operativos, es posible que una actualización reporte éxito, pero no haya llegado a todos los endpoints afectados. Sin un paso de verificación integrado al proceso, esas brechas pueden pasar desapercibidas durante semanas o meses.

Incorporar la verificación como parte natural del flujo, en lugar de tratarla como una tarea adicional, es lo que permite tener certeza real sobre el estado de seguridad de los sistemas.

Lo que hace la diferencia en la práctica

Las organizaciones que logran mantener un proceso de gestión de parches consistente y efectivo generalmente comparten algunas características: tienen visibilidad actualizada de sus activos, cuentan con criterios claros para priorizar por riesgo real, tienen roles definidos entre los equipos involucrados y han integrado la verificación como parte del flujo normal de trabajo.

No se trata de tener más herramientas, sino de conectar mejor las que ya existen y asegurarse de que el proceso tenga continuidad de principio a fin.

Plataformas de gestión autónoma de endpoints como Tanium están diseñadas precisamente para atender estos retos, ofreciendo visibilidad en tiempo real sobre el estado de cada dispositivo, despliegue progresivo de actualizaciones y verificación integrada, todo dentro de un flujo de trabajo que reduce la fricción entre etapas y les da a los equipos de TI el control que necesitan para actuar con certeza.

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

6 mil millones de ataques en un mes. ¿Qué nos dice eso sobre el panorama actual?

Explotación de vulnerabilidades en aplicaciones web 2026

Marzo de 2026 quedó registrado como un mes histórico en el mundo de la ciberseguridad. Durante esas cuatro semanas, los sistemas de protección de aplicaciones web bloquearon más de 6 mil millones de intentos de explotación de vulnerabilidades. En un solo mes.

Para ponerlo en perspectiva: los ataques bloqueados durante todo el primer trimestre de 2026 ya representan el 60% de todo lo que se bloqueó a lo largo de todo 2025. Y 2025 ya había sido un año récord.

¿Qué está pasando exactamente? ¿Y por qué importa para cualquier organización que tenga presencia digital?

El problema ya no es solo la cantidad de ataques

Cuando hablamos de ciberseguridad, es fácil quedar atrapados en los números grandes. Millones de ataques, miles de millones de intentos, porcentajes de crecimiento que parecen sacados de un reporte financiero récord.

Pero el dato más relevante no es cuántos ataques están ocurriendo. Es qué tipo de ataques están creciendo más, y qué dice eso sobre cómo operan los atacantes hoy.

Según el análisis de tendencias del primer trimestre de 2026 publicado por Radware, partner estratégico de Nova, la explotación de vulnerabilidades representa casi el 62% de toda la actividad maliciosa bloqueada en aplicaciones web y APIs. Es la categoría dominante, y sigue creciendo.

Eso significa que los atacantes no están lanzando ataques genéricos al azar. Están buscando activamente puntos débiles específicos en los sistemas, vulnerabilidades conocidas que no han sido corregidas, configuraciones incorrectas, APIs expuestas sin los controles adecuados. Y cuando las encuentran, las explotan de forma sistemática y a gran escala.

¿Por qué las vulnerabilidades son tan difíciles de gestionar?

Aquí está el punto que muchas organizaciones no tienen claro todavía.

Descubrir que un sistema tiene una vulnerabilidad no es lo difícil. Lo difícil es corregirla a tiempo, antes de que alguien la encuentre y la aproveche. Y ese tiempo, la ventana entre que se descubre una vulnerabilidad y se parchea, se está reduciendo de forma dramática.

Los atacantes hoy tienen acceso a herramientas automatizadas que escanean internet constantemente en busca de sistemas vulnerables. Cuando se publica una vulnerabilidad nueva, el tiempo que pasa antes de que alguien intente explotarla puede ser de horas, no de días ni de semanas.

Las organizaciones que gestionan sus parches de forma manual, con ciclos mensuales o trimestrales, están operando con una lógica que ya no corresponde a la velocidad del problema.

Lo que está cambiando en la forma de atacar

Hay otro elemento en los datos del Q1 2026 que merece atención. Los ataques más frecuentes siguen siendo los más pequeños, los que pasan por debajo del radar de los sistemas de detección tradicionales. El 93% de los ataques Web DDoS registrados en este período estuvieron por debajo de los 100,000 requests por segundo.

Eso no es casualidad. Es una estrategia deliberada. Los atacantes saben que los sistemas de seguridad configurados para detectar picos grandes de tráfico no necesariamente van a identificar un volumen constante de actividad maliciosa que se mantiene por debajo de los umbrales de alerta.

La combinación de ataques pequeños y persistentes con la explotación activa de vulnerabilidades específicas es lo que hace que el panorama actual sea más difícil de manejar que el de años anteriores, donde los ataques grandes y ruidosos eran más fáciles de identificar y bloquear.

Lo que esto implica para tu organización

La pregunta que vale la pena hacerse no es si tu organización tiene vulnerabilidades. Todas las tienen. La pregunta es cuánto tiempo pasan expuestas antes de ser corregidas, y si tienes visibilidad suficiente para saber cuáles son las más críticas.

Una estrategia de seguridad madura no depende únicamente de tener buenas herramientas de protección. Depende también de tener procesos que permitan identificar y priorizar vulnerabilidades de forma continua, no en ciclos largos que dejan ventanas de exposición innecesariamente amplias.

En Nova acompañamos a las organizaciones en ese proceso, con soluciones que permiten tener visibilidad real sobre el estado de seguridad de sus sistemas y responder antes de que una vulnerabilidad se convierta en un incidente.

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