Descripción de las reglas de directiva y las reglas de archivo de App Control for Business
Nota
Algunas funcionalidades de App Control para empresas solo están disponibles en versiones específicas de Windows. Obtenga más información sobre la disponibilidad de características de App Control.
App Control for Business puede controlar lo que se ejecuta en los dispositivos Windows estableciendo directivas que especifican si un controlador o aplicación es de confianza. Una directiva incluye reglas de directiva que controlan opciones como el modo de auditoría y reglas de archivo (o niveles de reglas de archivo) que especifican cómo identificar las aplicaciones en las que confía su organización.
Reglas de directivas de Control de aplicaciones para empresas
Para modificar las opciones de regla de directiva de un XML de directiva de Control de aplicaciones existente, use el Asistente para directivas de control de aplicaciones o el cmdlet de PowerShell Set-RuleOption .
Puede establecer varias opciones de regla dentro de una directiva de App Control. En la tabla 1 se describe cada opción de regla y si las directivas complementarias pueden establecerlas. Algunas opciones de regla se reservan para el trabajo futuro o no se admiten.
Nota
Se recomienda usar Enabled:Audit Mode inicialmente porque permite probar nuevas directivas de App Control antes de aplicarlas. Con el modo de auditoría, las aplicaciones se ejecutan normalmente, pero App Control registra eventos cada vez que se ejecuta un archivo que no está permitido por la directiva. Para permitir estos archivos, puede capturar la información de directiva del registro de eventos y, a continuación, combinar esa información en la directiva existente. Cuando se elimina el modo Enabled:Audit , la directiva se ejecuta en modo aplicado.
Algunas aplicaciones pueden comportarse de manera diferente incluso cuando la directiva está en modo de auditoría. Cuando una opción puede cambiar los comportamientos en modo de auditoría, esto se indica en la tabla 1. Siempre debe probar las aplicaciones exhaustivamente al implementar actualizaciones significativas en las directivas de App Control.
Tabla 1. Directiva de Control de aplicaciones para empresas: opciones de regla de directiva
| Opción de regla | Descripción | Opción complementaria válida |
|---|---|---|
| 0 Enabled:UMCI | Las directivas de Control de aplicaciones restringen los archivos binarios en modo kernel y modo usuario. De manera predeterminada, solo se restringen los archivos binarios en modo kernel. Al habilitar esta opción de regla, se validan los scripts y los ejecutables del modo de usuario. | No |
| 1 Enabled:Boot Menu Protection | Esta opción no se admite actualmente. | No |
| 2 Required:WHQL | De forma predeterminada, los controladores de kernel que no están firmados en Windows Hardware Quality Labs (WHQL) pueden ejecutarse. La habilitación de esta regla requiere que cada controlador esté firmado por WHQL y quite la compatibilidad con controladores heredados. Los controladores de kernel creados para Windows 10 deben estar certificados con WHQL. | No |
| 3 Enabled:Audit Mode (Default) | Indica a App Control que registre información sobre aplicaciones, archivos binarios y scripts que se habrían bloqueado si se aplicara la directiva. Puede usar esta opción para identificar el posible impacto de la directiva de App Control y usar los eventos de auditoría para refinar la directiva antes de la aplicación. Para aplicar una directiva de Control de aplicaciones, elimine esta opción. | No |
| 4 Disabled:Flight Signing | Si está habilitado, los archivos binarios de las compilaciones de Windows Insider no son de confianza. Esta opción es útil para las organizaciones que solo quieren ejecutar archivos binarios publicados, no versiones preliminares de compilaciones de Windows. | No |
| 5 Enabled:Inherit Default Policy | Esta opción está reservada para su uso futuro y actualmente no tiene ningún efecto. | Sí |
| 6 Enabled:Unsigned System Integrity Policy (Default) | Permite que la directiva permanezca sin firmar. Cuando se quita esta opción, se debe firmar la directiva y también se deben firmar las directivas complementarias. Los certificados de confianza para futuras actualizaciones de directivas deben identificarse en la sección UpdatePolicySigners. Los certificados de confianza para las directivas complementarias deben identificarse en la sección SupplementalPolicySigners. | Sí |
| 7 Allowed:Debug Policy Augmented | Esta opción no se admite actualmente. | Sí |
| 8 Required:EV Signers | Esta opción no se admite actualmente. | No |
| 9 Enabled:Advanced Boot Options Menu | El menú de inicio previo F8 está deshabilitado de forma predeterminada para todas las directivas de Control de aplicaciones. Al activar esta opción, se permite que aparezca el menú de F8 ante los usuarios presentes físicamente. | No |
| 10 Enabled:Boot Audit on Failure | Se usa cuando la directiva de Control de aplicaciones está en modo de cumplimiento. Cuando se produce un error en un controlador crítico para el arranque durante el inicio, la directiva de Control de aplicaciones se coloca en modo de auditoría para que Windows se cargue. Los administradores pueden validar el motivo del error en el registro de eventos CodeIntegrity. | No |
| 11 Cumplimiento de Disabled:Script | Esta opción deshabilita las opciones de cumplimiento de scripts, que abarcan PowerShell, Host de script basado en Windows (wscript.exe), Host de script basado en consola de Windows (cscript.exe), archivos HTA ejecutados en microsoft HTML Application Host (mshta.exe) y MSXML. Algunos hosts de script pueden comportarse de manera diferente incluso cuando la directiva está en modo de auditoría. Para obtener más información sobre la aplicación de scripts, consulte Aplicación de scripts con App Control. NOTA: Esta opción no se admite en Windows Server 2016 o Windows 10 1607 LTSB y no se debe usar en esos sistemas operativos. |
No |
| 12 Aplicaciones de Store Required:Enforce | Si esta opción de regla está habilitada, las directivas de Control de aplicaciones también se aplican a las aplicaciones universales de Windows. | No |
| 13 Instalador de Enabled:Managed | Use esta opción para permitir automáticamente las aplicaciones instaladas por un instalador administrado. Para obtener más información, consulte Autorización de aplicaciones implementadas con un instalador administrado de App Control. | Sí |
| 14 Autorización de gráficos de seguridad Enabled:Intelligent | Use esta opción para permitir automáticamente aplicaciones con una reputación "conocida buena" según lo definido por Intelligent Security Graph (ISG) de Microsoft. | Sí |
| 15 EA en reinicio Enabled:Invalidate | Cuando se usa la opción Intelligent Security Graph (14), App Control establece un atributo de archivo extendido que indica que el archivo estaba autorizado para ejecutarse. Esta opción hace que App Control revalide periódicamente la reputación de los archivos autorizados previamente por el ISG. | No |
| 16 Directiva sin reinicio Enabled:Update | Use esta opción para permitir que se apliquen futuras actualizaciones de directivas de App Control sin necesidad de reiniciar el sistema. NOTA: Esta opción solo se admite en Windows 10, versión 1709 y posteriores o Windows Server 2019 y versiones posteriores. |
No |
| 17 Habilitado:Permitir directivas complementarias | Use esta opción en una directiva base para permitir que las directivas complementarias la expandan. NOTA: Esta opción solo se admite en Windows 10, versión 1903 y posteriores o Windows Server 2022 y versiones posteriores. |
No |
| 18 Disabled:Runtime FilePath Rule Protection | Esta opción deshabilita la comprobación en tiempo de ejecución predeterminada que solo permite reglas de FilePath para rutas de acceso que solo un administrador puede escribir. NOTA: Esta opción solo se admite en Windows 10, versión 1903 y posteriores o Windows Server 2022 y versiones posteriores. |
Sí |
| 19 Enabled:Dynamic Code Security | Habilita la aplicación de directivas para aplicaciones .NET y bibliotecas cargadas dinámicamente. NOTA: Esta opción solo se admite en Windows 10, versión 1803 y posteriores o Windows Server 2019 y versiones posteriores. NOTA: Esta opción siempre se aplica si alguna directiva UMCI de Control de aplicaciones lo habilita. No hay ningún modo de auditoría para la protección de la seguridad de código dinámico de .NET. |
No |
| 20 Enabled:Revoked Expired as Unsigned (20 Habilitado:Revocado expirado como sin firmar) | Use esta opción para tratar los archivos binarios firmados con certificados revocados o certificados expirados con el EKU de firma de duración en la firma, como "archivos binarios sin firmar" para procesos o componentes en modo de usuario, en escenarios de firma empresarial. | No |
| Enabled:Developer Mode Dynamic Code Trust | Usa esta opción para confiar en las aplicaciones para UWP que se depuran en Visual Studio o se implementan a través del portal de dispositivos cuando el modo de desarrollador está habilitado en el sistema. | No |
Niveles de regla de archivo de Control de aplicaciones para empresas
Los niveles de reglas de archivo permiten a los administradores especificar el nivel en el que quieran confiar en las aplicaciones. Este nivel de confianza podría ser tan granular como el hash de cada binario o tan general como un certificado de entidad de certificación. Especifique los niveles de regla de archivo al usar el Asistente para control de aplicaciones o los cmdlets de PowerShell de Control de aplicaciones para crear y modificar directivas.
Cada nivel de regla de archivo tiene ventajas y desventajas. Use la tabla 2 para seleccionar el nivel de protección adecuado para los recursos administrativos disponibles y el escenario de implementación de App Control.
Nota
Las reglas basadas en firmante de App Control solo funcionan con criptografía RSA con una longitud de clave máxima de 4096 bits. No se admiten algoritmos ECC, como ECDSA. Si intenta permitir archivos por firma basados en firmas ECC, verá VerificationError = 23 en los eventos de información de firma 3089 correspondientes. Los archivos se pueden permitir en su lugar mediante reglas hash o de atributo de archivo, o mediante otras reglas de firmante si el archivo también está firmado con firmas mediante RSA.
Tabla 2. Directiva de Control de aplicaciones para empresas: niveles de regla de archivo
| Nivel de regla | Descripción |
|---|---|
| Hash | Especifica valores hash de imagen authenticode/PE individuales para cada binario detectado. Este nivel es el nivel más específico y requiere más esfuerzo para mantener los valores hash de las versiones de producto actuales. Cada vez que se actualiza un binario, el valor de hash cambia, por lo que es necesario actualizar la directiva. |
| FileName | Especifica el nombre de archivo original de cada binario. Aunque los valores de hash de una aplicación se modifican al actualizarse, los nombres de los archivos no suelen hacerlo. Este nivel ofrece una seguridad menos específica que el nivel hash, pero normalmente no requiere una actualización de directiva cuando se modifica cualquier binario. De forma predeterminada, este nivel usa el atributo OriginalFileName del encabezado de recurso del archivo. Use -SpecificFileNameLevel para elegir un atributo alternativo, como ProductName. |
| FilePath | A partir de Windows 10 versión 1903, este nivel permite que los archivos binarios se ejecuten desde ubicaciones de ruta de acceso de archivo específicas. Las reglas de FilePath solo se aplican a los archivos binarios en modo de usuario y no se pueden usar para permitir controladores de modo kernel. Puede encontrar más información sobre las reglas de nivel de FilePath más adelante en este artículo. |
| SignedVersion | Este nivel combina la regla del publicador con un número de versión. Permite que cualquier cosa se ejecute desde el publicador especificado con una versión en o por encima del número de versión especificado. |
| Publicador | Este nivel combina el nivel PcaCertificate (normalmente un certificado debajo de la raíz) y el nombre común (CN) del certificado hoja. Puede usar este nivel de regla para confiar en un certificado emitido por una ca determinada y emitido a una empresa específica en la que confíe (como Intel, para controladores de dispositivos). |
| FilePublisher | Este nivel combina el atributo "FileName" del archivo firmado, más "Publisher" (certificado PCA con CN de hoja), además de un número de versión mínimo. Esta opción confía en archivos concretos del editor especificado (con una versión de archivo igual o superior al número de versión especificado). De forma predeterminada, este nivel usa el atributo OriginalFileName del encabezado de recurso del archivo. Use -SpecificFileNameLevel para elegir un atributo alternativo, como ProductName. |
| LeafCertificate | Agrega firmantes de confianza al nivel de certificado de firma individual. La ventaja de usar este nivel frente al nivel hash individual es que las nuevas versiones del producto tienen valores hash diferentes, pero normalmente el mismo certificado de firma. Cuando se usa este nivel, no se necesitaría ninguna actualización de directiva para ejecutar la nueva versión de la aplicación. Sin embargo, los certificados hoja suelen tener períodos de validez más cortos que otros niveles de certificado, por lo que la directiva de Control de aplicaciones debe actualizarse siempre que estos certificados cambien. |
| PcaCertificate | Agrega el certificado disponible más elevado en la cadena de certificados proporcionada a los firmantes. Este nivel suele ser un certificado debajo de la raíz porque el examen no resuelve la cadena de certificados completa a través de los almacenes raíz locales o con una comprobación en línea. |
| RootCertificate | No se admite. |
| WHQL | Solo confía en los archivos binarios enviados a Microsoft y firmados por el Laboratorio de calificación de hardware (WHQL) de Windows. Este nivel se aplica principalmente a los archivos binarios del kernel. |
| WHQLPublisher | Este nivel combina el nivel WHQL y el CN en el certificado hoja, y es principalmente para los archivos binarios del kernel. |
| WHQLFilePublisher | Este nivel combina el atributo "FileName" del archivo firmado, más "WHQLPublisher", además de un número de versión mínimo. Este nivel se aplica principalmente a los archivos binarios del kernel. De forma predeterminada, este nivel usa el atributo OriginalFileName del encabezado de recurso del archivo. Use -SpecificFileNameLevel para elegir un atributo alternativo, como ProductName. |
Nota
Al crear directivas de App Control con New-CIPolicy, puede especificar un nivel de regla de archivo principal, incluyendo el parámetro -Level . Para los archivos binarios detectados en los que no se pueda confiar según los criterios de la regla de archivo principal, usa el parámetro -Fallback . Por ejemplo, si el nivel de regla de archivo principal es PCACertificate, pero también quiere confiar en las aplicaciones sin firmar, el uso del nivel de regla hash como reserva agrega los valores hash de los archivos binarios que no tenían un certificado de firma.
Nota
Cuando corresponda, se hace referencia a los números de versión mínimo y máximo de una regla de archivo como MinimumFileVersion y MaximumFileVersion, respectivamente, en el XML de directiva.
- Se especifican MinimumFileVersion y MaximumFileVersion: para las reglas Allow, se permite el archivo con una versión mayor o igual que MinimumFileVersion y menor o igual que MaximumFileVersion. En el caso de las reglas Deny, se deniega el archivo con una versión mayor o igual que MinimumFileVersion y menor o igual que MaximumFileVersion.
- MinimumFileVersion especificado sin MaximumFileVersion: para las reglas Allow, el archivo con una versión mayor o igual que la versión especificada puede ejecutarse. En el caso de las reglas deny, se bloquea el archivo con una versión menor o igual que la versión especificada.
- MaximumFileVersion especificado sin MinimumFileVersion: para las reglas Allow, el archivo con una versión menor o igual que la versión especificada puede ejecutarse. En el caso de las reglas deny, se bloquea el archivo con una versión mayor o igual que la versión especificada.
Ejemplo de los niveles de regla de archivo en uso
Por ejemplo, considere la posibilidad de un profesional de TI en un departamento que ejecuta muchos servidores. Solo quieren ejecutar software firmado por las empresas que proporcionan su hardware, sistema operativo, antivirus y otro software importante. Saben que sus servidores también ejecutan una aplicación escrita internamente que no está firmada y que rara vez se actualiza. Ellos permiten que esta aplicación se ejecute.
Para crear la directiva de Control de aplicaciones, crean un servidor de referencia en su hardware estándar e instalan todo el software que se sabe que ejecutan sus servidores. A continuación, ejecutan New-CIPolicy con -Level Publisher (para permitir que se ejecute el software de sus proveedores de software, los "editores") y -Fallback Hash (para permitir la aplicación interna y sin firmar). Implementan la directiva en modo de auditoría para determinar el posible impacto de la aplicación de la directiva. Con la ayuda de los datos de auditoría, actualizan sus directivas de Control de aplicaciones para incluir cualquier otro software que quieran ejecutar. A continuación, habilitan la directiva de Control de aplicaciones en modo aplicado para sus servidores.
Como parte de las operaciones normales, finalmente instalarán actualizaciones de software o quizás agregarán software de los mismos proveedores de software. Dado que el "publicador" sigue siendo el mismo en esas actualizaciones y software, no es necesario actualizar su directiva de App Control. Si se actualiza la aplicación interna sin signo, también debe actualizar la directiva de Control de aplicaciones para permitir la nueva versión.
Orden de precedencia de la regla de archivo
App Control tiene una lógica de conflicto de reglas de archivo integrada que se traduce en orden de precedencia. Primero procesa todas las reglas de denegación explícitas que encuentra. A continuación, procesa las reglas de permiso explícitas. Si no existe ninguna regla de denegación o de permiso, App Control busca una notificación del instalador administrado si la directiva lo permite. Por último, App Control vuelve al ISG si lo permite la directiva.
Nota
Para que sea más fácil razonar sobre las directivas de App Control, se recomienda mantener directivas ALLOW y DENY independientes en versiones de Windows que admitan varias directivas de App Control.
Usar -SpecificFileNameLevel con reglas de nivel FileName, FilePublisher o WHQLFilePublisher
De forma predeterminada, los niveles de regla FileName, FilePublisher y WHQLFilePublisher usan el atributo OriginalFileName del encabezado de recurso del archivo. Puede usar un atributo de encabezado de recurso alternativo para las reglas estableciendo -SpecificFileNameLevel. Por ejemplo, un desarrollador de software podría usar el mismo ProductName para todos los archivos binarios que forman parte de una aplicación. Con -SpecificFileNameLevel, puede crear una sola regla para cubrir todos esos archivos binarios de la directiva en lugar de reglas individuales para cada archivo.
En la tabla 3 se describen las opciones de atributo de encabezado de recurso disponibles que puede establecer con -SpecificFileNameLevel.
Tabla 3. Opciones de -SpecificFileNameLevel
| Valor specificFileNameLevel | Descripción |
|---|---|
| FileDescription | Especifica la descripción del archivo proporcionada por el desarrollador del archivo binario. |
| InternalName | Especifica el nombre interno del binario. |
| OriginalFileName | Especifica el nombre de archivo original, o el nombre con el que se creó por primera vez el archivo, del binario. |
| PackageFamilyName | Especifica el nombre de familia del paquete binario. El nombre de la familia del paquete consta de dos partes: el nombre del archivo y el identificador del publicador. |
| ProductName | Especifica el nombre del producto con el que se envía el binario. |
| Ruta de archivo | Especifica la ruta de acceso del archivo binario. |
Más información sobre las reglas de ruta de archivo
Las reglas de ruta de archivo no proporcionan las mismas garantías de seguridad que las reglas de firmante explícitas, ya que se basan en permisos de acceso mutables. Las reglas de ruta de archivo son más adecuadas para entornos en los que la mayoría de los usuarios se ejecutan como estándar en lugar de como administrador. Las reglas de ruta de acceso son más adecuadas para permitir rutas de acceso que espera que solo se puedan escribir mediante el administrador. Es posible que quiera evitar reglas de ruta de acceso para directorios en los que los usuarios estándar pueden modificar las ACL en la carpeta.
Rutas de archivo que se pueden escribir por el usuario
De forma predeterminada, App Control realiza una comprobación de escritura del usuario en tiempo de ejecución que garantiza que los permisos actuales en la ruta de acceso de archivo especificada solo permiten el acceso de escritura para los usuarios administradores.
Hay una lista definida de SID que App Control reconoce como administradores. Si una ruta de acceso de archivo permite permisos de escritura para cualquier SID que no esté en esta lista, se considera que la ruta de archivo puede escribirse por el usuario, incluso si el SID está asociado a un usuario administrador personalizado. Para controlar estos casos especiales, puede invalidar la comprobación de escritura del administrador en tiempo de ejecución de App Control con la opción Disabled:Runtime FilePath Rule Protection descrita anteriormente.
La lista de sids de administración conocidos de App Control son:
S-1-3-0; S-1-5-18; S-1-5-19; S-1-5-20; S-1-5-32-544; S-1-5-32-549; S-1-5-32-550; S-1-5-32-551; S-1-5-32-577; S-1-5-32-559; S-1-5-32-568; S-1-15-2-143048594-2639229838-973813799-439329657-1197984847-4069167804-127792394; S-1-15-2-95739096-486727260-2033287795-3853587803-1685597119-444378811-2746676523.
Cuando se generan reglas de ruta de archivo mediante New-CIPolicy, se genera una regla de ruta de acceso única y completa para cada archivo detectado en las rutas de acceso examinadas. Para crear reglas que permitan en su lugar todos los archivos de una ruta de acceso de carpeta especificada, use New-CIPolicyRule para definir reglas que contengan caracteres comodín mediante el modificador -FilePathRules .
Uso de caracteres comodín en reglas de ruta de archivo de Control de aplicaciones
Los siguientes caracteres comodín se pueden usar en las reglas de ruta de archivo de Control de aplicaciones:
| Carácter comodín | Significado | Sistemas operativos compatibles |
|---|---|---|
* |
Coincide con cero o más caracteres. | Windows 11, Windows 10 y Windows Server 2022 |
? |
Coincide con un solo carácter. | solo Windows 11 |
También puede usar las macros siguientes cuando el volumen exacto puede variar: %OSDRIVE%, %WINDIR%, %SYSTEM32%. Estas macros se pueden usar en combinación con los caracteres comodín anteriores.
Nota
En Windows 11, puede usar uno o varios caracteres comodín en cualquier lugar dentro de una regla de ruta de archivo.
En todas las demás versiones de Windows y Windows Server, solo se permite un carácter comodín por regla de ruta de acceso y debe estar al principio o al final de una regla de ruta de acceso.
Reglas de ruta de archivo de ejemplo con caracteres comodín
| Ejemplos | Descripción | Sistemas operativos compatibles |
|---|---|---|
|
C:\Windows\* D:\EnterpriseApps\MyApp\* %OSDRIVE%\Windows\* |
Los caracteres comodín colocados al final de una ruta de acceso autorizan todos los archivos de la ruta de acceso inmediata y sus subdirectorios de forma recursiva. | Windows 11, Windows 10 y Windows Server 2022 |
| *\bar.exe | Los caracteres comodín colocados al principio de una ruta de acceso permiten el nombre de archivo especificado exacto en cualquier ubicación. | Windows 11, Windows 10 y Windows Server 2022 |
|
C:\*\CCMCACHE\*\7z???? -x64.exe %OSDRIVE%\*\CCMCACHE\*\7z???? -x64.exe |
Los caracteres comodín usados en medio de una ruta de acceso permiten todos los archivos que coinciden con ese patrón. Considere detenidamente todas las coincidencias posibles, especialmente si la directiva deshabilita la comprobación que se puede escribir por el administrador con la opción Disabled:Runtime FilePath Rule Protection . En este ejemplo, ambas rutas de acceso hipotéticas coincidirían:C:\WINDOWS\CCMCACHE\12345\7zabcd-x64.exe C:\USERS\AppControlUSER\Downloads\Malware\CCMCACHE\Pwned\7zhaha-x64.exe |
solo Windows 11 |
Sin un carácter comodín, la regla de ruta de archivo solo permite un archivo específico (por ejemplo, C:\foo\bar.exe).
Nota
Al crear directivas de Control de aplicaciones con Configuration Manager, hay una opción para crear reglas para archivos y carpetas especificados. Estas reglas no son reglas de ruta de acceso de archivo de Control de aplicaciones. En su lugar, Configuration Manager realiza un examen único de los archivos y carpetas especificados y compila reglas para los archivos binarios que se encuentran en esas ubicaciones en el momento de ese examen. Los cambios de archivos en esos archivos y carpetas especificados después de ese examen no se permitirán a menos que se vuelva a aplicar la directiva de Configuration Manager.
Más información sobre los hashes
App Control usa el algoritmo hash de imagen Authenticode/PE al calcular el hash de un archivo. A diferencia del hash de archivo plano más conocido, el cálculo hash authenticode omite la suma de comprobación del archivo, la tabla de certificados y la tabla de certificados de atributo. Por lo tanto, el hash Authenticode de un archivo no cambia cuando se modifican las firmas y marcas de tiempo del archivo o cuando se quita una firma digital del archivo. Con la ayuda del hash Authenticode, App Control proporciona seguridad adicional y menos sobrecarga de administración, por lo que los clientes no necesitan revisar las reglas hash de directiva cuando se actualiza la firma digital en el archivo.
El hash de imagen Authenticode/PE se puede calcular para los archivos firmados digitalmente y sin signo.
¿Por qué el examen crea cuatro reglas hash por archivo XML?
El cmdlet de PowerShell genera un hash Authenticode Sha1, hash Sha256, hash de página Sha1, hash de página Sha256. Durante la validación, App Control selecciona qué hashes se calculan en función de cómo se firma el archivo y del escenario en el que se usa el archivo. Por ejemplo, si el archivo está firmado con hash de página, App Control valida cada página del archivo y evita cargar todo el archivo en memoria para calcular el hash de autenticación sha256 completo.
En los cmdlets, en lugar de intentar predecir qué hash se usará, precalculamos y usamos los cuatro hashes (sha1/sha2 authenticode y sha1/sha2 de la primera página). Este método también es resistente a los cambios en la forma en que se firma el archivo, ya que la directiva de Control de aplicaciones ya tiene más de un hash disponible para el archivo.
¿Por qué el examen crea ocho reglas hash para determinados archivos?
Se crean reglas independientes para UMCI y KMCI. Si los cmdlets no pueden determinar que un archivo solo se ejecuta en modo de usuario o en el kernel, se crean reglas para ambos escenarios de firma con mucha precaución. Si sabe que un archivo determinado solo se carga en modo de usuario o kernel, puede quitar de forma segura las reglas adicionales.
¿Cuándo usa App Control el valor hash de archivo plano?
Hay algunos casos poco frecuentes en los que el formato de un archivo no se ajusta a la especificación authenticode, por lo que App Control vuelve a usar el hash de archivo plano. Este comportamiento puede producirse por muchos motivos, como si se realizan cambios en la versión en memoria del archivo en tiempo de ejecución. En tales casos, verá que el hash que se muestra en el evento de información de firma 3089 correlacionado coincide con el hash de archivo plano del evento de bloque 3076/3077. Para crear reglas para archivos con un formato no válido, puede agregar reglas hash a la directiva para el hash de archivo plano mediante el Asistente para control de aplicaciones o editando directamente el XML de directiva.