Las amenazas de la inteligencia artificial se mueven rápido. Tus defensas también deberían hacerlo.

Recientemente, Vincent Danen de Red Hat destacó cómo los modelos de inteligencia artificial detectaron 271 defectos de seguridad reales en Firefox en una sola pasada durante la colaboración de Mozilla con Anthropic. Si la inteligencia artificial puede hacer eso por los defensores, también puede hacer lo mismo por los atacantes. Como dijo Danen: «si tu estrategia de seguridad se basa únicamente en la suposición de que el software estará libre de vulnerabilidades, ya has perdido». 

Las vulnerabilidades en el código son solo el punto de entrada. El daño real se produce después: el movimiento lateral a través de redes mal configuradas, credenciales con privilegios excesivos, secretos sin rotar y servicios que confían ciegamente entre sí. Ningún ciclo de parches puede seguir ese ritmo. Esto subraya la necesidad de una mayor «defensa en profundidad» en todas las empresas; un cambio cultural que asume que inevitablemente se producirá una vulneración y que se centra en reducir el impacto de la propia exposición. 

Esta es la definición de confianza cero. A esta primera oleada de vulnerabilidades de seguridad le siguen una segunda y una tercera, y las organizaciones deben adoptar la confianza cero para pasar de la prevención pura a la contención de las brechas, aplicando el principio del menor privilegio en la identidad, los secretos, la segmentación de red y las políticas en cada capa. Las organizaciones necesitan una aplicación automatizada que se ejecute a la velocidad de estas amenazas impulsadas por la inteligencia artificial. Red Hat Ansible Automation Platform ayuda a que esto sea posible.

El cambio en la superficie de ataque de la inteligencia artificial

Los escáneres de vulnerabilidades tradicionales detectan posibles problemas y los entregan a un humano para su triaje. La inteligencia artificial ha convertido los ciberataques en un producto básico. Las herramientas de inteligencia artificial actuales son básicamente un equipo completo en una sola herramienta, todo al coste de unos tokens. Mientras que las vulneraciones devastadoras como SolarWinds requirieron tiempo, una gran experiencia y suerte, ahora la inteligencia artificial permite a los atacantes motivados encadenar sin esfuerzo vulnerabilidades complejas y multiplataforma.

Estas debilidades, aparentemente pequeñas, se acumulan, y no precisamente en tu beneficio. Por ejemplo:

• Una página de inicio de sesión que te permite volver a intentar introducir contraseñas con demasiada rapidez.
• Una página de configuración que no vuelve a comprobar quién eres.
• Una API que expone brevemente un token de sesión durante el cierre de sesión.

Ninguna de estas es excesivamente peligrosa por sí sola. Individualmente, cada una aparecería en una lista de tareas pendientes como «prioridad baja», pero encadenadas podrían permitir que un atacante fuerce una contraseña por fuerza bruta, robe la sesión antes de que caduque y acceda a la página de configuración como administrador. Tres errores menores y, aun así, consigues un acceso no autorizado funcional.

Estos modelos avanzados de inteligencia artificial escriben, compilan y ejecutan código de explotación, utilizando los resultados de los fallos para perfeccionar y reintentar sus ataques de forma iterativa. Aunque las organizaciones aprovechan esto a su favor para encontrar y corregir vulnerabilidades desconocidas a gran velocidad, la incómoda verdad es que esta capacidad también está al alcance de los atacantes. Como escribió Danen: «las mismas herramientas que ayudan a los defensores a encontrar errores ayudarán inevitablemente a los atacantes a encontrarlos también». El nivel de habilidad necesario para los atacantes acaba de bajar. La aplicación de parches con mayor rapidez es parte de la respuesta, pero buenas defensas deben complementarla. 

La defensa requiere una capa operativa automatizada

Red Hat Enterprise Linux con SELinux y Red Hat OpenShift ya ofrecen fortalecimiento a nivel de plataforma, pero es necesario complementar estas defensas. Por ejemplo, SELinux no decide quién tiene autorización para implementar una aplicación. El aislamiento de contenedores no revoca las credenciales de la base de datos cuando un sistema de gestión de eventos e información de seguridad (SIEM) detecta un ataque de fuerza bruta a las 03:00. La automatización puede desempeñar estas funciones para crear una buena estrategia de defensa. 

Los cambios operativos (implementaciones, parches, reconfiguraciones de red, rotaciones de credenciales) fluyen a través de personas, scripts, pipelines y automatización. Si esas rutas no están reguladas por políticas, el fortalecimiento de la plataforma te protege de un tipo de ataque mientras deja otra categoría totalmente vulnerable. 

NIST SP 800-207 establece el diseño de la arquitectura de confianza cero (ZTA), y su núcleo es el punto de aplicación de políticas (PEP). La mayoría de las personas considera el PEP como un firewall o una puerta de enlace que filtra el tráfico de red. Sin embargo, cuando los equipos implementan aplicaciones, aplican parches en los servidores y cambian las configuraciones de red, esas acciones no pasan por un firewall, sino por la automatización. En última instancia, la confianza cero es una disciplina operativa que requiere implementar la automatización a escala.

Ansible Automation Platform como punto de aplicación de políticas

Cuando Ansible Automation Platform actúa como PEP (punto de aplicación de políticas), cada acción operativa pasa por una plataforma que verifica la identidad, evalúa la política, gestiona los secretos y registra el resultado. Estas no son capacidades avanzadas, sino los controles mínimos viables que la confianza cero exige. El operador nunca accede al sistema de destino de forma directa. El playbook de Ansible realiza esta tarea, y se ejecuta solo después de que la plataforma confirma que el operador tiene autorización.

El beneficio arquitectónico es la aplicación centralizada con una ejecución distribuida. Las decisiones sobre las políticas se toman en un único plano de control, pero el cumplimiento ocurre dondequiera que se ejecute la automatización. No hay conexión directa con los servidores ni ejecución de scripts desde computadoras portátiles, lo que reduce los riesgos de la "ingeniería vaquera" y de las desviaciones de configuración imposibles de rastrear. Esto también soluciona antipatrones como la dispersión de credenciales, la automatización en la sombra o el movimiento lateral sin supervisión.

Esta arquitectura mitiga las vulnerabilidades de seguridad críticas al eliminar las credenciales de producción con altos privilegios en los endpoints locales vulnerables. La plataforma de automatización es el único punto de control, y cada cambio incluye identidad, aprobación de políticas y un registro de auditoría. 

Ansible Automation Platform puede implementar esto mediante un modelo de cumplimiento de doble anillo. El anillo exterior opera a nivel de plataforma. Antes de lanzar una plantilla de trabajo, Ansible Automation Platform consulta al servidor de Open Policy Agent (OPA) mediante la función de cumplimiento de políticas incluida, con el contexto completo de la tarea: quién la lanza, a qué equipo pertenece y qué plantilla está ejecutando. 

Figura 1 Aplicación de políticas en los anillos exterior e interior con Ansible Automation Platform

OPA evalúa la solicitud en función de la política y devuelve allow o deny. El playbook nunca se ejecuta si el anillo exterior lo rechaza. La política de OPA vincula la pertenencia al equipo con las categorías de plantillas permitidas.

package aap.gateway
import rego.v1
default decision := {"allowed": true, "violations": []}
patching_teams := {"Infrastructure", "Security"}
network_teams := {"Infrastructure"}
app_teams := {"Applications", "DevOps"}
user_teams := {name | name := input.created_by.teams[_].name}
decision := {
    "allowed": false,
    "violations": [sprintf(
        "user '%s' is not in an authorised team for patching templates (requires: %v, has: %v)",
        [input.created_by.username, patching_teams, user_teams],
    )],
} if {
    not input.created_by.is_superuser
    is_patching_template
    not team_match(patching_teams)
}

Fig. 2: Ejemplo de política de Rego para la comprobación de Policy as Code

El anillo interno funciona dentro de la propia plantilla o del flujo de trabajo. Para operaciones con un impacto potencialmente alto, como los cambios de VLAN, el playbook obtiene una identidad SPIFFE (una identidad de carga de trabajo criptográfica) y la envía a OPA. OPA evalúa 3 condiciones: 

• El usuario se autoriza mediante su pertenencia a un equipo.
• La carga de trabajo es legítima mediante una identidad verificable de SPIFFE.
• El cambio solicitado se encuentra dentro de un rango aprobado.

Las 3 deben pasar.

Fig. 3: Ejemplo de cumplimiento de varias políticas con Ansible Automation Platform

Esto es importante contra los ataques basados en inteligencia artificial porque la cadena de explotación se interrumpe en el punto de aplicación, no en la vulnerabilidad. Un agente de inteligencia artificial que encadena fallos para acceder a un servidor queda atrapado en el plano de datos, donde las políticas de confianza cero, como la microsegmentación de red y las credenciales de corta duración, le impiden el acceso externo o el movimiento lateral. No puede abusar de tu implementación para distribuir aplicaciones maliciosas, ni puede alterar las políticas de red empresarial sin pasar por Ansible Automation Platform. Al detectar un riesgo local, Event-Driven Ansible, que se incluye en Ansible Automation Platform, puede aislar automáticamente el sistema y proporcionar contexto inmediato a tus equipos de seguridad.

Las credenciales de usuario robadas no pasan la verificación de SPIFFE porque la identidad de la carga de trabajo no coincide. Un nodo de automatización comprometido no pasa la verificación de pertenencia al equipo porque el atacante no controla la sesión de Ansible Automation Platform del usuario. Cada anillo es independiente. No basta con comprometer uno. Esto es defensa en profundidad en acción.

Reducción del impacto potencial con credenciales dinámicas y microsegmentación

Incluso con la aplicación de políticas en la capa de automatización, las credenciales y las rutas de red siguen siendo una superficie de ataque. Si las contraseñas de las bases de datos se rotan mensualmente, un atacante que obtenga acceso tendrá una ventana de un mes. Si las listas de control de acceso (ACL) de la red están permanentemente abiertas entre los niveles de la aplicación y la base de datos, la ruta siempre estará disponible.

Cuando se ejecuta un flujo de trabajo de implementación de aplicaciones, Ansible Automation Platform puede solicitar una credencial de base de datos dinámica de HashiCorp Vault, un rol de PostgresSQL que se ajusta al esquema de la aplicación con un tiempo de vida (TTL) de 5 minutos. La credencial existe solo para la ventana de implementación. Cuando vence el TTL, se elimina el rol. No hay nada que robar porque nada es persistente.

En el mismo flujo de trabajo, Ansible Automation Platform configura la red para abrir una entrada de ACL que permita el tráfico desde la dirección IP de la aplicación hasta el puerto de la base de datos.

Esto cambia el ataque contra las cadenas de amenazas de inteligencia artificial. Las herramientas pueden encadenar errores para llegar a un nivel de base de datos, pero encuentran una credencial que caducó hace 4 minutos. La ventana de vulnerabilidad se reduce desde "hasta que alguien cambie la contraseña" hasta "hasta que finalice la automatización" (minutos, no meses) y, cuando la aplicación se ejecute en producción, el agente de Vault se encargará del ciclo de vida permanente de las credenciales.

Respuesta ante incidentes a la velocidad de la máquina

Si los agentes de inteligencia artificial pueden generar exploits y encadenarlos, contar con un analista en el Centro de operaciones de seguridad (SOC) que reciba notificaciones, inicie sesión, lea la alerta, investigue y revoque las credenciales manualmente implica operar en una escala de tiempo humana frente a una amenaza digital.

Event-Driven Ansible ayuda a cerrar esa brecha. Un SIEM como Splunk detecta un patrón de fuerza bruta en el endpoint de autenticación de una aplicación. Splunk puede activar una alerta en Event-Driven Ansible a través de un flujo de eventos, y Event-Driven Ansible evalúa el evento e inicia un trabajo de automatización para tomar medidas. Este trabajo llama a la API de HashiCorp Vault para revocar todas las concesiones de bases de datos dinámicas activas que tiene la aplicación. La aplicación pierde inmediatamente la conexión con la base de datos.

—  
  name: Splunk Brute-Force credential revocation
  hosts: all
  sources:
    - ansible.eda.webhook:
        host: 0.0.0.0
        port: 5000
  rules:
    - name: Revoke credentials on SSH brute-force detection
      condition: event.payload.search_name is search("SSH Brute Force Detected")
      action:
        run_job_template:
          name: "Emergency: Revoke App Credentials"
          organization: Default

Fig. 4: Ejemplo de rulebook de Event-Driven Ansible para eventos de fuerza bruta de Splunk
 

El ciclo de detección a contención se completa en segundos, lo que reduce el tiempo promedio de resolución de horas a segundos. El impacto potencial se reduce de "el atacante puede tener acceso a la base de datos" a "el atacante tiene acceso a una aplicación que ya no puede acceder a sus datos".

Fig. 5: Ejemplo de respuesta ante incidentes de ataque para una arquitectura de confianza cero con Event-Driven Ansible
 

Esta es una contención automatizada, que puede ir seguida de una restauración manual. Event-Driven Ansible puede revocar las credenciales sin aprobación humana porque la revocación es una medida de seguridad predeterminada: la aplicación deja de proporcionar datos, pero no se destruye nada. La restauración requiere que una persona investigue, confirme que la amenaza se ha resuelto e inicie un flujo de trabajo de restauración que vuelva a implementar la aplicación. El punto de control en la ruta de recuperación existe porque restaurar el acceso tras una vulneración no es algo que debas automatizar sin una investigación humana.

Múltiples capas, una sola defensa

La detección de vulnerabilidades asistida por inteligencia artificial hace que la defensa en profundidad sea innegociable. Sin embargo, la defensa en profundidad sin una capa operativa automatizada deja un vacío que los ataques a la velocidad de las máquinas encontrarán.

Tres capas pueden cerrar esta brecha, cada una de las cuales interrumpe la cadena de explotación de inteligencia artificial en un punto diferente:

• El reforzamiento de la plataforma (indicadores del compilador, SELinux, aislamiento de contenedores y aleatorización del diseño del espacio de direcciones [ASLR]) hace que el error inicial sea más difícil de explotar. Un modelo de inteligencia artificial podría encontrar la vulnerabilidad, pero la plataforma reforzada obliga a realizar una cadena de varios pasos solo para lograr la ejecución del código.
• La aplicación de políticas con Ansible Automation Platform bloquea las rutas operativas no autorizadas. Incluso si la cadena de explotación tiene éxito, el atacante no puede implementar, parchear, reconfigurar ni acceder a los secretos sin pasar por el plano de control de la automatización. Las credenciales robadas por sí solas no son suficientes.
• La respuesta automatizada con Event-Driven Ansible ayuda a contener las brechas de seguridad antes de que comience el movimiento lateral. El tiempo que transcurre entre la detección y la contención en segundos iguala la velocidad de los ataques impulsados por inteligencia artificial de una forma que la respuesta con intervención humana no puede.

Cada capa funciona de forma independiente. El reforzamiento de la plataforma no depende de la aplicación de políticas. La aplicación de políticas no depende de la respuesta automatizada. Si una sola capa falla, las otras dos siguen limitando el daño. Esta independencia permite que los equipos de seguridad dediquen tiempo a la reducción estratégica de riesgos en lugar de perseguir alertas. Además, permite que las organizaciones adopten operaciones asistidas por inteligencia artificial con la confianza de que las protecciones se mantendrán incluso cuando las herramientas evolucionen más rápido que las políticas.

La mayoría de las organizaciones cuentan con reforzamiento de la plataforma. Muchas están adoptando los principios de confianza cero. Pocas han conectado la aplicación de políticas con la automatización a la velocidad que exigen estas amenazas. Esta brecha es donde ocurrirá la próxima vulneración de seguridad. Al combinar las tres capas descritas anteriormente, fortaleces tus defensas contra los efectos de un ataque impulsado por inteligencia artificial.  

Recursos

• Webinar: Implementación de confianza cero con Red Hat Ansible Automation Platform
• Webinar: Automatización de la seguridad. Alineación de ITOps
• E-book: Automatización la seguridad para alinear la TI empresarialPágina disponible en Inglés (Español no está disponible)
• E-book: Red Hat Ansible Automation Platform: guía para principiantes
• Guía interactiva paso a paso: Automatización de la TI, incluida la automatización de la seguridad
• Página web: Automatización de la seguridad