Trusted Ownership: cómo Ivanti Application Control escala más allá de las listas de permitidos

El control de aplicaciones es uno de esos temas de seguridad sobre los que muchas personas siguen teniendo ideas preconcebidas. Las listas de permitidos tradicionales parecen seguras, pero se convierten rápidamente en una carga de mantenimiento. Las listas de bloqueados resultan reactivas e incompletas. Y, aunque herramientas como Microsoft AppLocker llevaron a muchos a pensar que las listas de permitidos estrictas eran el estándar de referencia, los ataques modernos han demostrado lo contrario. Los atacantes recurren cada vez más a herramientas legítimas y firmadas —utilizadas en el contexto incorrecto— para eludir por completo los controles basados en listas.

Por eso, cuando las organizaciones evalúan Ivanti Application Control o Ivanti Neurons for App Control y se encuentran con Trusted Ownership, al principio puede parecerse a las listas de bloqueados porque permite bloqueos explícitos. En realidad, Trusted Ownership es un modelo de aplicación de políticas basado en la procedencia mucho más amplio y mucho más ligero desde el punto de vista operativo, que controla la ejecución en función del origen, no solo de la identidad.

En lugar de gestionar listas cada vez más extensas, aplica la seguridad en función de quién ha colocado el software en el sistema, alineándose de forma clara con las prácticas modernas de distribución de software y los principios de zero trust. La mejor forma de entenderlo no es como otro mecanismo de listas, sino como un modelo de aplicación de políticas basado en la procedencia que controla la ejecución en función del origen, no solo de la identidad.

Ese cambio de enfoque conduce a una pregunta más adecuada para el control de aplicaciones moderno: no solo qué es un archivo, sino cómo ha llegado hasta ahí.

Más allá de las listas: por qué el control de procedencia es ahora importante

La pregunta de cómo llegó un archivo al sistema está en el centro del control de procedencia. En lugar de confiar en los archivos basándose únicamente en el editor, la ruta o el hash, el control de procedencia evalúa el origen y el proceso que los introdujeron. ¿Quién escribió el archivo en el disco? ¿A través de qué mecanismo? ¿La instalación siguió un flujo de trabajo de TI controlado? Esta evaluación desplaza el control de aplicaciones de la confianza en el objeto a la confianza en el proceso, creando un límite de seguridad mucho más sólido.

En Ivanti Application Control, el control de procedencia se implementa como Trusted Ownership. Se permite cualquier archivo colocado por un propietario de confianza; todo lo introducido por un usuario se deniega de forma predeterminada. Esto se aplica de forma coherente a ejecutables, DLL, instaladores y scripts. Como identidades como SYSTEM, TrustedInstaller y Administrators son de confianza de forma predeterminada, el software entregado a través de canales de implementación estándar como MS Intune, MECM, Ivanti Endpoint Manager (EPM) u otras herramientas empresariales se ejecuta de inmediato sin mantenimiento de reglas ni excepciones.

Esto marca una ruptura fundamental con las listas de permitidos clásicas. Las reglas de AppLocker dependen por completo de definiciones exactas de editor, ruta o hash. No evalúa el origen de la instalación ni confía automáticamente en sus mecanismos de implementación. El software entregado por Intune sigue requiriendo una regla de permiso preexistente, a menudo basada en valores predeterminados amplios que permiten los directorios Program Files o Windows.

Esa distinción es importante porque los ataques modernos convierten cada vez más herramientas legítimas en armas en contextos inadecuados. El control de procedencia neutraliza gran parte de ese riesgo al exigir confianza en cómo llega el software, no solo en qué es. Se alinea con los principios de zero trust, reduce la exposición de la cadena de suministro y limita drásticamente, de forma predeterminada, las oportunidades de abuso mediante Living off the Land (LotL).

Una vez que se comprende la importancia del origen, la siguiente pregunta es: ¿cómo se aplica a escala?

La respuesta: aplicar la procedencia de forma coherente a todas las formas en que el software se ejecuta y se entrega.

Más allá de las listas de bloqueados: cobertura amplia diseñada para la implementación moderna de software

El control de procedencia desplaza la seguridad de las aplicaciones de la gestión de listas interminables a la validación del proceso por el que el software llega al sistema. Una vez adoptada esta perspectiva, queda claro que Trusted Ownership no es un enfoque de listas de bloqueados. Es un límite de confianza basado en el origen que se comporta de forma muy distinta a las listas de permitidos tradicionales.

Un error habitual es pensar que Trusted Ownership se parece a las listas de bloqueados porque los administradores a veces añaden reglas de denegación específicas para herramientas conocidas de Windows. En la práctica, estas reglas de denegación son medidas de refuerzo defensivo frente a técnicas Living off the Land. Todo método serio de control de aplicaciones utiliza este tipo de restricciones específicas. El núcleo de Trusted Ownership es lo contrario de las listas de bloqueados. El software entregado mediante un proceso controlado y de confianza se permite de forma predeterminada, mientras que el contenido introducido por el usuario se deniega de forma predeterminada.

Un diferenciador más importante es la cobertura. Muchas organizaciones que dependen de listas de permitidos clásicas acaban centrándose casi exclusivamente en archivos ejecutables. A menudo evitan aplicar el mismo cumplimiento a DLL, scripts y paquetes MSI porque estos tipos de archivo complican mucho más el mantenimiento de reglas. Esto crea brechas que los atacantes modernos explotan con frecuencia.

Trusted Ownership evita estas brechas aplicando el mismo cumplimiento basado en el origen a toda la cadena de ejecución. Ejecutables, DLL, scripts, instaladores MSI y componentes relacionados se evalúan mediante el mismo modelo de confianza. Como la confianza viene determinada por quién introdujo el archivo, no hacen falta políticas independientes para cada tipo de archivo. Un script en la carpeta Descargas, una DLL creada en un directorio de compilación temporal o un EXE ejecutado desde un perfil de usuario reciben el mismo tratamiento de denegación predeterminada cuando se originan fuera de un proceso de instalación controlado.

Este modelo de confianza también se alinea de forma natural con la manera en que las plataformas modernas de gestión de endpoints entregan software. Soluciones como Intune, MECM, Ivanti Neurons for MDM, Ivanti Endpoint Manager y sistemas similares suelen instalar aplicaciones utilizando la identidad SYSTEM u otra cuenta de servicio de confianza.

Como estas identidades ya son propietarios de confianza, el software implementado a través de estos canales se ejecuta de inmediato sin crear reglas de permiso, mantener rutas de archivo ni actualizar políticas. Solo cuando se utilizan de forma intencionada cuentas de instalación alternativas, como agentes DevOps personalizados o instalaciones mediante scripts en contexto de usuario, es necesario identificar esa identidad como propietario de confianza.

El resultado es un modelo con una cobertura amplia y coherente en todos los tipos de archivo relevantes. Funciona sin fisuras con las distribuciones modernas de software y evita la sobrecarga operativa asociada a las listas de permitidos clásicas, que se centran principalmente en archivos ejecutables.

Trusted Ownership deposita la confianza no en objetos individuales, sino en los procesos controlados mediante los que se entrega el software, creando un enfoque más escalable y más seguro para el control de aplicaciones.

Dónde encaja WDAC (App Control for Business)

Microsoft mantiene dos tecnologías de control de aplicaciones: AppLocker y App Control for Business (anteriormente WDAC). Aunque ambas siguen existiendo, Microsoft es clara sobre sus funciones. AppLocker ayuda a impedir que los usuarios ejecuten aplicaciones no aprobadas, pero no cumple los criterios de mantenimiento de las características de seguridad modernas y, por tanto, se clasifica como un mecanismo de defensa en profundidad, no como un control de seguridad estratégico.

La vía de futuro de Microsoft para el control de aplicaciones es App Control for Business, y la compañía indica explícitamente que AppLocker tiene las funciones completas y ya no está en desarrollo activo, más allá de las actualizaciones de seguridad esenciales. Esto significa que todas las nuevas capacidades se entregan solo en WDAC y no en AppLocker.

App Control for Business introduce el concepto de Managed Installer. Esto permite que Windows confíe automáticamente en las aplicaciones instaladas a través de plataformas de implementación designadas, como Intune o MECM. La confianza se deriva del canal de distribución y no de archivos individuales, lo que reduce significativamente el mantenimiento de reglas.

Esto se alinea estrechamente con el modelo Trusted Ownership de Ivanti Application Control. Ambos enfoques confían en el software en función del proceso controlado que lo instaló, en lugar de basarse en atributos de archivo discretos. Sin embargo, Trusted Ownership aplica este concepto de una forma más sencilla y accesible desde el punto de vista operativo. Ivanti confía en identidades como SYSTEM y cuentas de servicio designadas sin requerir capas de políticas complejas, definiciones XML ni conocimientos profundos de WDAC.

Ivanti escucha a muchas organizaciones que tienen dificultades para poner WDAC en funcionamiento. Las políticas de WDAC requieren un diseño cuidadoso, pruebas prolongadas en modo auditoría, gestión de excepciones de controladores y kernel, y mantenimiento continuo de varios conjuntos de políticas. Esto suele llevar a las organizaciones a combinar WDAC con AppLocker para cubrir tanto el cumplimiento de bajo nivel como el control cotidiano del espacio de usuario, lo que termina generando sobrecarga administrativa.

Ivanti Application Control ofrece una alternativa unificada. Mediante Trusted Ownership, Trusted Vendors y la validación de firmas digitales, proporciona un modelo de denegación predeterminada basado en la procedencia, con cobertura coherente en ejecutables, DLL, scripts y paquetes MSI.

En lugar de mantener dos planos de control de Microsoft con ámbitos diferentes, las organizaciones gestionan una única política simplificada que aplica la confianza en función de cómo se introduce el software en el sistema. Esto proporciona muchos de los objetivos prácticos que los clientes intentan lograr con una implementación combinada de WDAC y AppLocker, pero con menor complejidad operativa y un único modelo de confianza cohesionado.

LOLBins y control a nivel de argumentos

Con una cobertura amplia ya establecida, la cuestión pasa a ser cómo gestionar las herramientas legítimas que ya están en todos los equipos y de las que los atacantes suelen abusar.

Los atacantes modernos a menudo evitan utilizar malware tradicional y, en su lugar, recurren a las herramientas ya presentes en todos los dispositivos Windows. Estas herramientas Living off the Land (LOLBins) son legítimas y necesarias para las operaciones normales, lo que dificulta bloquearlas sin afectar a la productividad. Las listas de permitidos tradicionales tienen dificultades en este punto porque un bloqueo amplio interrumpe los flujos de trabajo, mientras que una permisividad amplia deja brechas peligrosas.

Un modelo basado en la procedencia como Trusted Ownership cambia esta dinámica. Incluso si un atacante intenta utilizar una herramienta integrada, el contenido que trata de ejecutar normalmente no procede de un proceso de instalación de confianza. Como Ivanti evalúa el origen de ese contenido, la mayoría de los intentos de uso indebido fallan automáticamente. La herramienta puede ser legítima, pero el contenido que se le pide ejecutar no lo es, y Trusted Ownership lo detiene antes de que se ejecute.

También es importante entender no solo qué herramientas se ejecutan, sino qué se les pide que hagan. Muchos intérpretes y entornos de ejecución, como PowerShell, Python o Java, pueden ser perfectamente seguros en un contexto y arriesgados en otro. Una aplicación empresarial puede depender de Java para iniciar un proceso específico y aprobado, mientras que un archivo JAR descargado por un usuario es un escenario totalmente distinto.

Ivanti aborda esto mediante un enfoque por capas. Un archivo JAR se evalúa primero con Trusted Ownership, que lo bloquea de inmediato si lo introdujo un usuario y no un proceso de implementación controlado. Además, los administradores pueden crear reglas de permiso sencillas que especifiquen exactamente qué comandos de Java están permitidos, garantizando que solo se ejecuten aplicaciones legítimas basadas en Java, mientras que los intentos de iniciar archivos JAR no aprobados se deniegan de forma silenciosa.

El mismo principio se aplica también a otras herramientas. Las políticas pueden aprobar el comportamiento exacto que necesita su organización y bloquear las actividades que quedan fuera de esos límites. Esto evita reglas amplias y frágiles, y mantiene el trabajo diario funcionando sin interrupciones.

El resultado es un enfoque equilibrado y moderno. Trusted Ownership detiene por defecto el contenido que no es de confianza. El refuerzo específico se alinea con las mejores prácticas gubernamentales y de la comunidad para reducir el abuso de técnicas Living off the Land, y los controles sensibles a la intención garantizan que los procesos legítimos sigan funcionando sin abrir puertas a los atacantes.

Este enfoque se alinea estrechamente con las guías actuales de la comunidad y de organismos públicos sobre la mitigación de técnicas Living off the Land. Agencias como CISA, NSA, FBI y el Australian Cyber Security Centre hacen hincapié en reducir las oportunidades de los atacantes para utilizar herramientas integradas, controlando cómo se usan y restringiendo el contenido no confiable sobre el que actúan. Sus guías conjuntas destacan que los ataques LOTL dependen del abuso de herramientas nativas e insisten en la necesidad de controles que limiten ese uso indebido sin bloquear procesos legítimos del sistema.

El modelo de Ivanti refleja estas guías. Trusted Ownership bloquea automáticamente el contenido no confiable del que dependen los atacantes, mientras que un pequeño número de restricciones específicas aborda el reducido conjunto de herramientas que requieren atención adicional.

Trusted Ownership en acción: escenarios reales

Estos son algunos ejemplos operativos de cómo funcionan Ivanti Application Control y Trusted Ownership en la práctica.

1. Se copia una aplicación portátil en el perfil de usuario. Ivanti la bloquea porque es propiedad del usuario. AppLocker solo la bloquea si existen reglas coincidentes. Sin las reglas de ruta o editor adecuadas, el comportamiento puede variar.
2. Un adjunto de correo electrónico inicia un script de PowerShell desde Descargas. Ivanti lo deniega debido a la propiedad del usuario. AppLocker depende de las reglas de script y, en eventos de bloqueo, fuerza PowerShell al modo Constrained Language Mode, que seguirá ejecutando el script.
3. Abuso de herramientas del sistema operativo como rundll32 o mshta. Ambos modelos necesitan refuerzo de denegación específico. Ivanti lo combina con el control de procedencia, que por lo general reduce el número de excepciones necesarias. AppLocker depende de conjuntos de denegación seleccionados y requiere ajustes periódicos.
4. Una actualización de proveedor entrega nuevos archivos firmados. Ivanti permite la actualización cuando llega a través del canal de implementación de confianza gracias a Trusted Ownership. AppLocker puede adaptarse a esto con reglas de editor, pero la reutilización de firmas en varios productos o las rutas de instalación poco habituales suelen generar mantenimiento adicional y una confianza más amplia de lo previsto.
5. Un usuario descarga un JAR e intenta ejecutarlo con Java. Ivanti bloquea el intento porque el JAR ha sido introducido por el usuario y no supera Trusted Ownership. Si es necesario, los administradores pueden permitir solo la invocación aprobada exacta haciendo coincidir la línea de comandos completa. AppLocker no puede comparar argumentos y depende de reglas de editor, ruta o hash.

Conclusión

El control de procedencia desplaza el control de aplicaciones de un problema de gestión a un modelo de confianza. En lugar de confiar en archivos individuales, confía en el proceso por el que el software llega a un sistema, lo que hace que la seguridad sea escalable y viable.

Trusted Ownership encaja plenamente en este enfoque. No es una lista de bloqueados ni una lista de permitidos clásica, sino un modelo en el que el software que llega mediante un proceso de TI controlado se permite de forma predeterminada, mientras que todo lo que queda fuera de ese proceso se deniega de forma predeterminada. Al aplicar el control sobre el origen y la propiedad, en lugar de sobre archivos ad hoc, Ivanti Application Control e Ivanti Neurons for App Control se alinean mucho mejor con las técnicas de ataque modernas y con la distribución de software actual.

Si se sigue tratando el control de aplicaciones como un ejercicio de gestión de listas, se notará la carga administrativa. Si se trata como un límite de confianza, se obtiene escalabilidad, seguridad y viabilidad operativa.