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

Tu infraestructura cambió. ¿Tu CMDB ya se enteró?

CMDB actualizada | Tanium Atlas

Una Base de Datos de Gestión de Configuración (CMDB) permite a una organización mantener un registro de los componentes que forman parte de su entorno tecnológico y de las relaciones que existen entre ellos.

En términos prácticos, funciona como una referencia para saber qué dispositivos, aplicaciones y otros recursos forman parte de la infraestructura.

Pero esa infraestructura no permanece igual durante mucho tiempo.

Se incorporan dispositivos, se instala o elimina software, cambian configuraciones y algunos equipos dejan de formar parte de la operación. Cada modificación puede parecer pequeña, pero en organizaciones con cientos o miles de endpoints, mantener una imagen precisa del entorno se vuelve cada vez más complejo.

Y ahí aparece el verdadero desafío: ¿qué sucede cuando la infraestructura cambia más rápido que la información registrada en la CMDB?

Una fotografía que puede perder vigencia

Imaginemos que durante la mañana se instala una nueva aplicación en varios equipos. Más tarde se incorpora un dispositivo y, antes de terminar el día, otro cambia de configuración.

La infraestructura ya es diferente.

Si esos movimientos todavía no aparecen reflejados en la CMDB, comienza a existir una distancia entre lo que realmente forma parte del entorno y la información disponible para administrarlo.

Esa diferencia puede trasladarse a distintos procesos. Un equipo podría aparecer con software que ya no tiene instalado, un dispositivo recién incorporado podría tardar en formar parte de determinados registros o una configuración podría haber cambiado sin que otros sistemas todavía lo reflejen.

Por eso, mantener una CMDB actualizada no consiste únicamente en almacenar información. Su utilidad también depende de qué tan cerca se encuentra esa información de la realidad tecnológica que pretende representar.

Cuando actualizar también significa identificar qué cambió

Una forma de mantener estos registros consiste en realizar sincronizaciones periódicas del inventario.

Sin embargo, conforme aumenta el número de endpoints, aparece otra cuestión: si desde la última actualización únicamente cambiaron algunos elementos, ¿es necesario volver a procesar toda la información?

Tanium presentó recientemente dos nuevos Service Graph Connectors para Tanium Atlas y ServiceNow que incorporan una capacidad denominada delta sync o sincronización de cambios.

Su funcionamiento parte de una lógica sencilla: identificar qué cambió desde la sincronización anterior. En lugar de volver a transferir todo el inventario, se envían los endpoints nuevos y las modificaciones detectadas en información como hardware o software.

De esta manera, la actualización se concentra en aquello que realmente necesita incorporarse o modificarse.

Aunque pueda parecer una mejora exclusivamente técnica, detrás existe una cuestión importante para la operación: reducir el tiempo que separa un cambio en el entorno de su representación en los sistemas que dependen de esa información.

Una CMDB es tan útil como los datos que recibe

Tener miles de registros no garantiza por sí mismo una visión precisa de la infraestructura.

Una CMDB puede estar correctamente estructurada y, aun así, perder utilidad si parte de sus datos dejó de representar el estado actual de los dispositivos.

Esto importa porque su información puede utilizarse como referencia para diferentes procesos de Tecnologías de la Información (TI). Gestión de activos, cambios, investigación de incidentes y otras actividades operativas necesitan conocer qué recursos existen y cuál es su situación.

Los nuevos conectores de Tanium buscan mantener esa relación entre los datos obtenidos de los endpoints y ServiceNow. También contemplan dispositivos administrados mediante Microsoft Intune y Tanium Device Management para incorporarlos a esa visión del entorno.

Así, la pregunta deja de ser solamente “¿tenemos registrado este activo?”.

También debemos preguntarnos: “¿qué tan reciente es lo que sabemos sobre él?”

La infraestructura cambia, aunque nuestros registros no lo hagan

Un inventario tecnológico siempre representa un momento determinado.

Después pueden aparecer nuevas aplicaciones, modificaciones de hardware, dispositivos adicionales o configuraciones distintas. Por eso, uno de los retos no está únicamente en descubrir los activos una vez, sino en mantener su información conforme evolucionan.

La incorporación de delta sync en los Service Graph Connectors de Tanium muestra precisamente esa dirección: acercar los cambios observados en los endpoints a los sistemas utilizados para administrar el entorno, sin tener que reconstruir toda la fotografía cada vez.

No se trata de actualizar por actualizar.

Se trata de que las decisiones operativas puedan partir de información suficientemente reciente para representar lo que realmente existe.

Porque una CMDB puede contener miles de dispositivos, aplicaciones y relaciones perfectamente organizadas.

Pero su verdadero valor comienza cuando podemos confiar en que esa información todavía representa la infraestructura que tenemos 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