Autorizar aplicaciones de confianza con Intelligent Security Graph (ISG)

App Control puede ser difícil de implementar en organizaciones que no implementan y administran aplicaciones a través de un sistema administrado por TI. En estos entornos, los usuarios pueden adquirir las aplicaciones que desean usar para el trabajo, lo que dificulta la creación de una directiva de Control de aplicaciones eficaz.

Para reducir la fricción del usuario final y las llamadas al departamento de soporte técnico, puede establecer App Control para empresas para permitir automáticamente las aplicaciones que Intelligent Security Graph (ISG) de Microsoft reconoce como de buena reputación. La opción ISG ayuda a las organizaciones a empezar a implementar App Control incluso cuando la organización tiene un control limitado sobre su ecosistema de aplicaciones. Para obtener más información sobre el ISG, consulte la sección Seguridad en Servicios y características principales de Microsoft Graph.

¿Cómo funciona App Control con el ISG?

El ISG no es una "lista" de aplicaciones. En cambio, usa la misma vasta inteligencia de seguridad y análisis de aprendizaje automático que impulsan SmartScreen de Microsoft Defender y Antivirus de Microsoft Defender para ayudar a clasificar las aplicaciones como "bien conocidas", "conocidas malas" o "desconocidas". Esta inteligencia artificial basada en la nube se basa en billones de señales recopiladas de los puntos de conexión de Windows y otras fuentes de datos, y se procesa cada 24 horas. Como resultado, la decisión de la nube puede cambiar.

Control de aplicaciones solo comprueba el ISG en busca de archivos binarios que la directiva no permita o deniegue explícitamente, y que no fueron instalados por un instalador administrado. Cuando un archivo binario de este tipo se ejecuta en un sistema con App Control habilitado con la opción ISG, Control de aplicaciones comprobará la reputación del archivo enviando su hash e información de firma a la nube. Si el ISG informa que el archivo tiene una reputación de "buena reputación", se permitirá que el archivo se ejecute. De lo contrario, será bloqueado por Control de aplicaciones.

Si el archivo con buena reputación es un instalador de aplicaciones, la reputación del instalador pasará a cualquier archivo que escriba en el disco. De esta manera, todos los archivos necesarios para instalar y ejecutar una aplicación heredan los datos de reputación positiva del instalador. Los Files autorizados en función de la reputación del instalador tendrán el $KERNEL.SMARTLOCKER.ORIGINCLAIM atributo extendido (EA) del kernel escrito en el archivo.

Control de aplicaciones vuelve a consultar periódicamente los datos de reputación de un archivo. Además, las empresas pueden especificar que los resultados de reputación almacenados en caché se vacíen al reiniciar mediante la opción Enabled:Invalidate EAs on Reboot .

Descripción de las notificaciones de origen

Cuando el instalador administrado o Intelligent Security Graph (ISG) autoriza un archivo, Control de aplicaciones registra por qué es de confianza en ese archivo agregando un atributo extendido (EA) administrado por kernel al archivo. Conocida como su notificación de origen, EA captura la fuente de la reputación del archivo, para que Integridad de código pueda evaluar más tarde el archivo sin volver a verificar su fuente original. La notificación de origen se llama $KERNEL.SMARTLOCKER.ORIGINCLAIM. Una notificación de origen registra qué escribió el archivo, indica que el proceso que escribió el archivo era de confianza como instalador administrado o se basó en su reputación, y si la confianza se heredó de un primario. Puede usar el fsutil comando para ver este EA en un archivo. Para obtener los pasos exactos, consulte Uso de fsutil para consultar atributos extendidos para el instalador administrado (MI).

• Origen del instalador administrado: El archivo se escribió mediante un proceso en el que la directiva confía como un instalador administrado (por ejemplo, una herramienta de implementación como Microsoft Configuration Manager o Microsoft Intune). Esta confianza se basa en cómo llegó el archivo al dispositivo, no en las propiedades, las firmas o el valor hash del archivo. Para obtener más información, consulte Consideraciones de seguridad con el instalador administrado.
• Origen de Intelligent Security Graph (ISG): El archivo recibió una respuesta de reputación favorable o heredó la respuesta de reputación favorable del proceso principal, que fue un instalador que creó el archivo. Estas respuestas de reputación proceden de los servicios de inteligencia de seguridad de Microsoft, denominados Intelligent Security Graph. La reputación está vinculada al archivo específico, por lo que si se modifica el archivo, la reputación ya no se aplica y ya no se respeta la notificación de origen. Si esto ocurre, Control de aplicaciones vuelve a evaluar el archivo la próxima vez que se ejecute. Para obtener más información, consulte Autorización de aplicaciones de confianza con Intelligent Security Graph (ISG).

Las notificaciones de origen se propagan hacia abajo en un árbol de procesos. Cuando se ejecuta un instalador administrado, o cuando un instalador recibe una respuesta de reputación de instalador de confianza del ISG, pasa una confianza equivalente a los archivos que escribe y a los procesos secundarios que inicia. Esa confianza continúa fluyendo por el árbol de procesos activos a través de los procesos secundarios, sus elementos secundarios y las generaciones posteriores, de modo que todos los archivos que un instalador necesita para instalar y ejecutar una aplicación están autorizados.

La propagación no es ilimitada. Finaliza cuando se interrumpe el árbol de procesos de confianza, incluidos estos casos:

• Finaliza el proceso del instalador original. El ámbito de la confianza se limita a la duración del árbol de procesos de confianza. Un archivo creado después de que salga el instalador administrado original o el proceso de instalador de confianza de ISG no hereda su notificación de origen. En los datos de atributo extendido, este tipo de archivo se marca como "elemento secundario de un elemento secundario" y no está autorizado para ejecutarse por sí mismo: debe permitirse por otros medios, como una regla explícita, un origen de instalador administrado o una reputación de ISG.
• Un proceso cruza un límite de seguridad. Si un proceso se genera en un contexto de seguridad o usuario diferente, el proceso principal puede pasar su notificación de origen al proceso secundario. Si no es así, el árbol de procesos se rompe y los archivos creados por el proceso secundario o sus elementos secundarios no se autorizan en función de la notificación de origen del proceso inicial.

Después de que el árbol de procesos se interrumpa por cualquier motivo, los archivos creados deben estar autorizados por otros medios, incluso si se ejecutan como un instalador administrado o reciben una respuesta de reputación de instalador de confianza del ISG.

Configuración de la autorización de ISG para la directiva de Control de aplicaciones

Configurar el ISG es fácil utilizando cualquier solución de gestión que desee. La configuración de la opción ISG implica estos pasos básicos:

• Asegúrese de que la opción de autorización Habilitado:Gráfico de seguridad inteligente está establecida en el XML de la directiva de control de aplicaciones
• Habilite los servicios necesarios para permitir que App Control use el ISG correctamente en el cliente

Asegúrese de que la opción ISG está establecida en el XML de la directiva de control de aplicaciones

Para permitir aplicaciones y archivos binarios basados en Microsoft Intelligent Security Graph, la opción de autorización Enabled:Intelligent Security Graph debe especificarse en la directiva de Control de aplicaciones. Este paso se puede realizar con el Set-RuleOption cmdlet. También debe establecer la opción Enabled:Invalidate EAs on Rebooting para que los resultados de ISG se comprueben de nuevo después de cada reinicio. La opción ISG no se recomienda para dispositivos que no tienen acceso normal a Internet. En el ejemplo siguiente se muestran ambas opciones establecidas.

<Rules>
    <Rule>
      <Option>Enabled:Unsigned System Integrity Policy</Option>
    </Rule>
    <Rule>
      <Option>Enabled:Advanced Boot Options Menu</Option>
    </Rule>
    <Rule>
      <Option>Required:Enforce Store Applications</Option>
    </Rule>
    <Rule>
      <Option>Enabled:UMCI</Option>
    </Rule>
    <Rule>
      <Option>Enabled:Managed Installer</Option>
    </Rule>
    <Rule>
      <Option>Enabled:Intelligent Security Graph Authorization</Option>
    </Rule>
    <Rule>
      <Option>Enabled:Invalidate EAs on Reboot</Option>
    </Rule>
</Rules>

Habilite los servicios necesarios para permitir que App Control use el ISG correctamente en el cliente

Para que la heurística usada por el ISG funcione correctamente, otros componentes de Windows deben estar habilitados. Puedes configurar estos componentes ejecutando el ejecutable de appidtel en c:\windows\system32.

appidtel start

Este paso no es necesario para las directivas de Control de aplicaciones implementadas a través de MDM, ya que el CSP habilitará los componentes necesarios. Este paso tampoco es necesario cuando el ISG se configura mediante la integración de Control de aplicaciones de Administrador de configuración.

Consideraciones de seguridad con la opción ISG

Dado que el ISG es un mecanismo basado en heurística, no proporciona las mismas garantías de seguridad que las reglas explícitas de permiso o denegación. Es más adecuado cuando los usuarios operan con derechos de usuario estándar y donde se usa una solución de supervisión de seguridad como Microsoft Defender para punto de conexión.

Prioridad de regla con ISG

Cuando se combina la opción ISG con reglas explícitas de permiso o denegación, Control de aplicaciones evalúa las reglas explícitas antes de usar la reputación. Una regla de denegación explícita siempre tiene prioridad sobre la reputación de ISG, por lo que Control de aplicaciones bloquea un archivo denegado independientemente de su reputación. Una regla de permiso explícito también tiene prioridad sobre la reputación. El ISG solo influye en los archivos que ninguna regla explícita de permiso o denegación cubre.

Puede crear cualquier regla estática en la directiva que pueda autorizar de forma confiable archivos binarios críticos para el arranque, ya que la integridad de código lo evalúa localmente desde la directiva durante el arranque sin ninguna dependencia disponible de la nube o del tiempo de ejecución. Esto incluye las reglas AllowAll, las reglas comodín FileName='*' , las reglas de firmante, las reglas de atributo de archivo y las reglas hash. Nunca confíe en el ISG o en un instalador administrado para autorizar archivos críticos de arranque: sus decisiones dependen de la reputación de la nube o de los atributos extendidos del kernel que no siempre están disponibles al principio de la ruta de acceso de arranque, lo que puede bloquear esos archivos o provocar tiempos de espera de arranque o de inicio del servicio.

Si usa una plantilla AllowAll con reglas de denegación explícitas, las reglas de denegación explícitas seguirán teniendo prioridad. Para obtener más información, consulte Crear una directiva de control de aplicaciones para bloquear controladores o aplicaciones. Para obtener más información acerca del instalador administrado y el comportamiento de ISG, consulte la guía de solución de problemas y referencia técnica del instalador administrado e ISG.

Los procesos que se ejecutan con privilegios de kernel pueden eludir el Control de aplicaciones estableciendo el atributo de archivo extendido ISG para hacer que un binario parezca tener buena reputación.

Además, dado que la opción ISG pasa la reputación de los instaladores de aplicaciones a los archivos binarios que escriben en el disco, puede autorizar archivos en exceso en algunos casos. Por ejemplo, si el instalador inicia la aplicación al finalizar, Control de aplicaciones también permite cualquier archivo que la aplicación escriba durante la primera ejecución.

Limitaciones conocidas con el uso del ISG

Dado que el ISG solo permite archivos binarios que son "buenos conocidos", hay casos en los que es posible que el ISG no pueda predecir si es seguro ejecutar software legítimo. En este caso, Control de aplicaciones bloqueará el software. En este caso, debe permitir el software con una regla en la directiva de App Control, implementar un catálogo firmado por un certificado de confianza en la directiva de Control de aplicaciones o instalar el software desde un instalador administrado de Control de aplicaciones. Los instaladores o aplicaciones que crean binarias dinámicamente en tiempo de ejecución y las aplicaciones que se actualizan automáticamente pueden presentar este síntoma.

Las aplicaciones empaquetadas no son compatibles con ISG y tendrán que autorizarse por separado en la directiva de Control de aplicaciones. Dado que las aplicaciones empaquetadas tienen una identidad de aplicación segura y deben estar firmadas, es sencillo autorizar aplicaciones empaquetadas con la directiva de Control de aplicaciones.

El ISG no autoriza los controladores de modo kernel. La directiva de App Control debe tener reglas que permitan ejecutar los controladores necesarios.