Instalador administrado, ISG y directivas complementarias

La guía pilar de App Control for Business termina con una directiva que confía en Windows, en el código firmado por Microsoft y en una instantánea examinada de tu software. Esa directiva es correcta el primer día y errónea el trigésimo, cuando la primera actualización de una aplicación trae un nuevo auxiliar sin firmar o un fabricante renueva su certificado de firma. La mayoría de los proyectos de App Control que fracasan no lo hacen por la seguridad; fracasan porque la lista de permitidos no puede seguir el ritmo de los cambios.

Existen tres funciones para resolverlo: el instalador administrado, que confía en todo lo que instala tu herramienta de despliegue; Intelligent Security Graph (ISG), que confía en los archivos con buena reputación en Microsoft; y las directivas complementarias, que permiten a los responsables de aplicaciones ampliar una directiva base bloqueada sin tocarla. Esta guía explica cómo funciona cada una por dentro, cómo configurarla y dónde debilita tu modelo de seguridad.

Cómo funciona el instalador administrado

Un instalador administrado es un proceso que designas como de confianza para instalar software. Cuando ese proceso, o cualquier proceso hijo que inicie, escribe un archivo ejecutable en el disco, Windows marca el archivo con un atributo extendido del kernel (una «notificación de origen», almacenada como $KERNEL.SMARTLOCKER.ORIGINCLAIM). Cuando el archivo se ejecuta más tarde, App Control ve la notificación y lo permite, siempre que la directiva tenga la opción de regla 13 Enabled:Managed Installer.

Cooperan dos componentes:

• AppLocker designa el instalador. Una colección de reglas especial, ManagedInstaller, nombra los binarios de confianza. El servicio Application Identity (AppIDSvc) y su controlador se encargan del etiquetado.
• App Control respeta las etiquetas en el momento de la ejecución.

Esa separación importa. Si AppIDSvc está detenido, no se etiqueta ningún archivo nuevo, y el software que instale tu herramienta de despliegue a partir de ese momento se bloqueará en los dispositivos con la directiva aplicada.

Paso 1: elegir el instalador

Elige una sola herramienta por dispositivo. Designar varios instaladores multiplica lo que se considera de confianza implícitamente, y cada binario designado se convierte en un objetivo de alto valor: quien consiga que ejecute una carga útil obtiene esa carga útil permitida.

El conmutador de Intune solo se aplica a las aplicaciones Win32 y demás aplicaciones entregadas mediante Intune Management Extension después de activarlo. Las aplicaciones de la Store y todo lo que instale un usuario no están cubiertos.

Paso 2: desplegar manualmente la parte de AppLocker (sin Intune)

Microsoft publica una directiva de instalador administrado de ejemplo en la documentación de App Control; parte de ella en lugar de escribir el XML a mano. Su estructura es una colección de reglas ManagedInstaller con reglas de editor para los binarios de tu instalador, más las colecciones de reglas EXE y DLL en modo AuditOnly con la extensión de servicios activada, para que el etiquetado funcione en los procesos que se ejecutan como servicios.

Si ya usas AppLocker, combina en lugar de sustituir, o sobrescribirás tus reglas existentes:

Set-AppLockerPolicy -XmlPolicy .\ManagedInstaller.xml -Merge
sc.exe config appidsvc start= auto
appidtel.exe start -mionly

appidtel.exe start inicia los componentes de etiquetado de Application Identity; el modificador -mionly activa el etiquetado del instalador administrado sin activar ISG. En un dispositivo que no aplica ya AppLocker, mantén las colecciones EXE y DLL solo en auditoría; el objetivo es el etiquetado, no la aplicación de AppLocker.

Paso 3: activar la opción 13 en la directiva de App Control

La directiva base tiene que habilitarlo:

Set-RuleOption -FilePath .\Base.xml -Option 13      # Enabled:Managed Installer
Set-RuleOption -FilePath .\Base.xml -Option 17      # Enabled:Allow Supplemental Policies
Set-RuleOption -FilePath .\Base.xml -Option 3       # Enabled:Audit Mode, durante el piloto
ConvertFrom-CIPolicy -XmlFilePath .\Base.xml -BinaryFilePath .\Base.cip

Después despliega una aplicación mediante el instalador y comprueba que sus archivos llevan la notificación:

fsutil file queryEA "C:\Program Files\Contoso\Agent\agent.exe"

Un archivo etiquetado muestra un atributo extendido llamado $KERNEL.SMARTLOCKER.ORIGINCLAIM. Si no hay atributo, el archivo no lo escribió el árbol de procesos del instalador, o AppIDSvc no se estaba ejecutando en ese momento.

Paso 4: decidir si usar ISG

La opción 14 Enabled:Intelligent Security Graph Authorization permite los archivos que el servicio de reputación en la nube de Microsoft considera conocidos como buenos. La opción 15 Enabled:Invalidate EAs on Reboot hace que Windows vuelva a comprobar la reputación de los archivos autorizados por ISG tras un reinicio, de modo que un archivo cuya reputación empeora no sigue siendo de confianza para siempre.

ISG permite cosas que nunca has revisado. Eso es precisamente lo que buscas en el portátil de un comercial y el problema en un servidor. Si lo activas, ejecuta también appidtel.exe start sin -mionly, y trátalo como un paso intermedio: recoge de los registros de auditoría lo que ha permitido y sustituye esa confianza con el tiempo por reglas de editor explícitas.

Paso 5: delegar con directivas complementarias

Una directiva complementaria añade reglas de permiso a una directiva base concreta, identificada por su id. de directiva. La base necesita la opción 17 (establecida más arriba). Construye el complemento a partir de la carpeta de instalación de la aplicación:

New-CIPolicy -Level Publisher -Fallback Hash -UserPEs `
  -ScanPath "C:\Program Files\LineOfBusiness" -FilePath .\Supp-LOB.xml
Set-CIPolicyIdInfo -FilePath .\Supp-LOB.xml -PolicyName "Supp - LOB app" `
  -BasePolicyToSupplementPath .\Base.xml
ConvertFrom-CIPolicy -XmlFilePath .\Supp-LOB.xml -BinaryFilePath .\Supp-LOB.cip
CiTool.exe --update-policy .\Supp-LOB.cip

Un modelo operativo viable:

• Seguridad es responsable de la base: directiva de ejemplo de Microsoft, reglas de bloqueo recomendadas, la lista de bloqueo de controladores vulnerables, la opción 13 y las reglas de denegación. Cambia rara vez y, una vez estable, se firma.
• Los equipos de aplicaciones son responsables de los complementos: uno por aplicación o unidad de negocio, revisados mediante un proceso de cambios, solo con reglas de permiso.
• Las reglas se quedan en el nivel de editor siempre que sea posible. Las reglas de hash en un complemento implican un complemento nuevo en cada versión.

Si la directiva base está firmada, los complementos también deben estarlo o no se cargarán. Planifica tu proceso de firma antes de firmar la base.

Qué se rompe

• Aplicaciones que se actualizan solas. Los navegadores, las herramientas de colaboración y los agentes que se actualizan a sí mismos escriben nuevos binarios desde su propio actualizador, no desde el instalador administrado. Los archivos nuevos no llevan notificación de origen. Cubre a estos fabricantes con reglas de editor en un complemento en lugar de depender del instalador.
• Instaladores por usuario. Todo lo que se instala en %LOCALAPPDATA% al margen de tu herramienta de despliegue queda sin etiquetar por diseño. Normalmente es lo que quieres bloquear, pero espera tickets.
• Archivos copiados, no instalados. Las herramientas que un script de inicio de sesión o un administrador copian en su sitio nunca las escribió el árbol de procesos del instalador, así que no tienen notificación de origen. Dales sus propias reglas de editor o de hash.
• El instalador como vía de ataque. Cualquiera que pueda publicar una aplicación en Intune o un paquete en Configuration Manager puede conseguir ahora que se permita código arbitrario en todos los dispositivos con la directiva aplicada. Los roles de administración de tu herramienta de despliegue pasan a formar parte del perímetro de tu control de aplicaciones; trátalos como cuentas privilegiadas.
• AppIDSvc deshabilitado por una línea base o un script de «limpieza». El etiquetado se detiene sin avisar.

Verificarlo

1. Servicios: Get-Service AppIDSvc muestra Running y el tipo de inicio Automatic en todos los dispositivos con la directiva aplicada.
2. Parte de AppLocker: Get-AppLockerPolicy -Effective -Xml contiene una colección de reglas ManagedInstaller que nombra tu instalador.
3. Parte de App Control: CiTool.exe --list-policies muestra la base y cada complemento como activos; el evento 3099 en Microsoft > Windows > CodeIntegrity > Operational confirma que se activó cada directiva.
4. Etiquetado: fsutil file queryEA sobre un binario recién desplegado muestra la notificación de origen.
5. Bloqueos: el evento 3076 (auditoría) o 3077 (aplicado) indica lo que se habría ejecutado o se detuvo. Los eventos de diagnóstico 3090 a 3092 explican cuándo un archivo se permitió o bloqueó por el instalador administrado o por ISG; el 3090 (permitido únicamente por el instalador administrado o ISG) es opcional y requiere reg add HKLM\SYSTEM\CurrentControlSet\Control\CI -v TestFlags -t REG_DWORD -d 0x300 y un reinicio, lo que también activa 3091/3092 donde estén inactivos. Con un instalador administrado, el 3091 puede generar mucho ruido, así que fíltralo antes de que llegue a un almacén de registros de pago.

Lista de comprobación

• Una sola herramienta de despliegue designada como instalador administrado por dispositivo
• Regla ManagedInstaller de AppLocker combinada, sin sobrescribir las reglas de AppLocker existentes
• AppIDSvc en automático y en ejecución; appidtel.exe start ejecutado
• La directiva base tiene las opciones 13 y 17; la opción 14 solo donde ISG sea una elección deliberada
• Notificación de origen confirmada con fsutil file queryEA en el piloto
• Aplicaciones que se actualizan solas cubiertas por reglas de editor en complementos
• Complementos a cargo de los equipos de aplicaciones, solo reglas de permiso, firmados si la base está firmada
• Roles de administración de la herramienta de despliegue tratados como acceso privilegiado
• Eventos 3076, 3077 y 3099 reenviados a tu canalización de registros

Con un instalador administrado y los complementos en marcha, App Control deja de ser un proyecto y se convierte en un proceso. El siguiente paso es cerrar la parte del kernel con la lista de bloqueo de controladores, y el resto del área de control de aplicaciones cubre los controles por usuario con AppLocker.