Control de aplicaciones / WDAC Lite: Listado de permitidos práctico para personas normales

Qué significa realmente “WDAC Lite” en la práctica

“WDAC Lite” no es una SKU oficial de Microsoft. Es un término de campo para un enfoque pragmático de Windows Defender Application Control
(WDAC) donde:

• Comienzas en Modo Auditoría, recopilas datos reales de ejecución y solo después aplicas la política.
• Prefieres reglas por editor/firma sobre reglas frágiles por hash.
• Usas Instalador gestionado (cuando sea factible) para que tu canal de distribución de software se convierta en el motor del listado de permitidos.
• Mantienes la superficie de la política pequeña: SO + canales de software aprobados + un mecanismo de escape controlado para emergencias.
• Aceptas que el “listado de permitidos” es un proceso, no una configuración de una sola vez.

La parte “Lite” es filosófica: apuntas al 80% de cobertura que bloquea la mayoría del malware de consumo y herramientas de “drive‑by”,
sin intentar modelar cada script interno extraño, cada caso límite de workstation de desarrollo o cada instalador de un proveedor de 2003.

WDAC es aplicado por la Integridad de código en el SO. Si tu política dice “no”, ahí termina la conversación.
No puedes convencer al kernel con palabras. Esto es bueno. También es la razón por la que necesitas un plan de despliegue que asuma que vas a bloquear algo importante.

Hechos interesantes y breve historia

Algo de contexto hace que las decisiones de diseño parezcan menos magia negra y más tejido cicatricial acumulado.

1. WDAC surgió de Device Guard (era de Windows 10), que buscaba usar seguridad basada en virtualización para endurecer la ejecución de código.
2. AppLocker vino primero y aún se usa mucho, pero WDAC opera a un nivel inferior (Integridad de código), lo que cambia lo que puede eludirlo.
3. El listado de permitidos precede al EDR moderno; los productos empresariales de allow‑listing eran populares porque el antivirus por firmas perdía la partida a escala.
4. La guía de Microsoft cambió con el tiempo: de “bloquéalo todo” a despliegues en fases más prácticos con patrones de auditoría primero.
5. El código firmado no es automáticamente seguro; los ataques a la cadena de suministro abusaron de firmas válidas, por eso la confianza debe tener alcance (editor + producto) cuando sea posible.
6. PowerShell no siempre fue la herramienta administrativa por defecto; al volverse ubicuo, el control de scripts se convirtió en un gran impulsor del control de aplicaciones moderno.
7. Las políticas CI pueden desplegarse de múltiples maneras (MDM/Intune, Group Policy, imagenes, herramientas locales), y el mecanismo de entrega forma parte de tu historia de fiabilidad.
8. Las reglas por hash son históricamente populares porque “simplemente funcionan” en pilotos—hasta que la primera actualización automática te explota el fin de semana.
9. El Instalador gestionado es un control sociotécnico: funciona mejor cuando tu organización realmente usa distribución de software gestionada en lugar de “simplemente ejecutar el EXE.”

Modelo mental: qué se permite, qué se deniega y por qué

WDAC trata decisiones de confianza, no rutas de archivos

Si has vivido controles basados en rutas, has visto la tragedia: “Solo permitir C:\Program Files\” y de repente el malware vive en
C:\Program Files\TotallyLegit\. WDAC está diseñado para usar señales de identidad más fuertes:

• Reglas por editor/firma: “Permitir binarios firmados por este editor (opcionalmente delimitado a producto/versión).”
• Reglas por hash: “Permitir este archivo exacto.” Fiables y frágiles. Como un martillo de cristal.
• Reglas por ruta de archivo: existen, pero deben usarse con moderación y deliberación.
• Instalador gestionado: “Permitir lo que vino a través de este canal de instalación.” Una forma de convertir la herramienta de despliegue en parte de la confianza.

El modo Auditoría no es opcional

El modo Aplicación es donde vas para tener razón. El modo Auditoría es donde vas para aprender. En auditoría, WDAC registra lo que hubiera bloqueado.
Ese es el dato que necesitas para construir una lista de permitidos que coincida con la realidad, no con el diagrama arquitectónico ideal.

Hay dos enemigos: el malware y tu propio entorno

El malware es oportunista. Tu empresa es… creativa. Aplicaciones de negocio con DLLs sin firmar. Controladores de impresora de un proveedor que
piensa que SHA1 sigue siendo aceptable. Una herramienta de administración “temporal” que se volvió permanente hace tres años. WDAC gana cuando estandarizas agresivamente
las rutas de ejecución y la entrega de software.

Una cita para mantener la honestidad

“La esperanza no es una estrategia.” — idea parafraseada frecuentemente en círculos de operaciones, asociada con pensamiento de confiabilidad general.

Con WDAC, “esperanza” se ve como: “Creo que todas las herramientas de helpdesk están firmadas.” O: “Estoy seguro de que el cliente VPN no dejará un binario auxiliar sin firmar.”
No quieres conocer la verdad en modo Aplicación.

Broma #1: El listado de permitidos es como hacer dieta—todo está bien hasta que descubres lo que tus usuarios consideran “un tentempié.”

Construir una política sin odiar tu vida

Empieza con una base que puedas defender

El patrón “Lite” de WDAC que funciona en la mayoría de empresas:

• Permitir componentes de Microsoft Windows (binarios del SO, herramientas incluidas).
• Permitir firmas de Microsoft de plataformas comunes en las que confías (Edge, componentes de Office) según tu entorno.
• Permitir tu canal de software gestionado (agente ConfigMgr/Intune como Instalador gestionado, o una cadena interna de instaladores firmados).
• Permitir editores terceros clave que realmente uses (VPN, EDR, agente de backup, soporte remoto).
• Bloquear ejecución desde ubicaciones modificables por usuarios cuando sea posible (Descargas, Temp) no concediendo confianza allí.
• Mantener un plan de emergencia realista operativamente (procedimiento de intercambio de política, acceso de recuperación).

Prefiere reglas por editor; usa hashes como si te cobraran por hash

Las reglas por editor sobreviven a las actualizaciones. Las reglas por hash no. Aún son útiles para:

• Excepciones de corta duración durante respuesta a incidentes.
• Herramientas internas puntuales que nunca se actualizarán (raro, pero real).
• Parchear de urgencia un fallo crítico mientras negocias una versión firmada con un proveedor.

Instalador gestionado: el superpoder “Lite”

Instalador gestionado es lo más parecido que tiene WDAC a “haz que sea problema de otro (de forma buena).”
Si tu herramienta de despliegue es sensata, puedes decir: “Todo lo instalado por ese agente es confiable.”
Entonces tu listado de permitidos se convierte en un problema de gobernanza de despliegue, que es un problema que las empresas ya saben manejar.

También impone una disciplina útil: si los usuarios instalan EXE aleatorios desde correo, WDAC castigará ese comportamiento.
Bien. Pagas por control; deberías obtener control.

Diseña para cambios continuos, no para un día perfecto

Tu política cambiará. Aparecen nuevas impresoras. Una app crítica se actualiza. Un proveedor rota certificados.
Planea para:

• Una cadencia predecible de actualización de políticas.
• Una forma de recopilar registros de auditoría de forma central.
• Un flujo de trabajo de excepciones claro (quién aprueba, cómo se codifica y cuándo expira).
• Una historia de reversión que no implique re-imagenar endpoints.

Tareas prácticas (comandos, salidas, decisiones)

Estas son cosas que puedes hacer hoy en una máquina Windows para entender qué ocurre, validar suposiciones y desplegar una política más segura.
Los comandos usan PowerShell porque esto es Windows, y el sufrimiento es tradicional.

Tarea 1: Confirmar el estado de la política WDAC/Control de aplicaciones

cr0x@server:~$ powershell -NoProfile -Command "Get-CimInstance -ClassName Win32_DeviceGuard | Select-Object -Property * | Format-List"
SecurityServicesConfigured : {1, 2}
SecurityServicesRunning    : {1, 2}
CodeIntegrityPolicyEnforcementStatus : 1
UsermodeCodeIntegrityPolicyEnforcementStatus : 1
VirtualizationBasedSecurityStatus : 2

Qué significa: Buscas campos de aplicación de la política de Integridad de código. Los valores de estado varían según la compilación, pero “1” típicamente indica que la aplicación está activada para esa dimensión.

Decisión: Si la aplicación está activada, deja de adivinar y ve a los registros de eventos para ver qué se está bloqueando. Si la aplicación está desactivada, estás en auditoría o no desplegado.

Tarea 2: Comprobar si estás en modo Auditoría o Aplicación (desde opciones de política)

cr0x@server:~$ powershell -NoProfile -Command "Get-CimInstance -Namespace root\Microsoft\Windows\CI -ClassName CI_ActivePolicy | Select-Object -ExpandProperty Policy | Format-List"
PolicyID   : {d1f4a6aa-1b6a-4e61-9f47-0e1b0d7c9d2a}
FriendlyName : Corp-WDAC-Base
Mode       : Audit
LastUpdate : 2/5/2026 9:12:44 AM

Qué significa: Esto muestra la política activa y si está en auditoría o en aplicación.

Decisión: Si aún no estás en Auditoría, ponlo ahí antes de ampliar el alcance. Si ya aplicas en un piloto, bien—ahora necesitas monitorización y reversión ajustadas.

Tarea 3: Extraer eventos de auditoría/denegación rápido (registro de Integridad de código)

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -LogName 'Microsoft-Windows-CodeIntegrity/Operational' -MaxEvents 20 | Select-Object TimeCreated,Id,LevelDisplayName,Message | Format-Table -Wrap"
TimeCreated           Id LevelDisplayName Message
-----------           -- ---------------- -------
2/5/2026 9:21:01 AM 3077 Information      Code Integrity determined that a process ... would have been prevented from running ...
2/5/2026 9:20:57 AM 3033 Warning          Code Integrity determined that a process ... did not meet the Store signing level requirements.

Qué significa: Los ID de evento varían, pero buscas “would have been prevented” (auditoría) y “prevented” (aplicación). El mensaje suele incluir la ruta del archivo, información de firma y detalles de la política.

Decisión: Identifica los binarios bloqueados más frecuentes por frecuencia e impacto en el negocio. No empieces por “permitir todo lo que está bloqueado.” Empieza por “¿por qué se está ejecutando esto?”

Tarea 4: Filtrar eventos para un ejecutable bloqueado específico

cr0x@server:~$ powershell -NoProfile -Command "$needle='AcmeUpdater.exe'; Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-CodeIntegrity/Operational'} | Where-Object {$_.Message -like \"*$needle*\"} | Select-Object -First 5 TimeCreated,Id,Message | Format-List"
TimeCreated : 2/5/2026 9:10:11 AM
Id         : 3077
Message    : Code Integrity determined that a process (\Device\HarddiskVolume3\ProgramData\Acme\AcmeUpdater.exe) would have been prevented from running...

Qué significa: Encontraste la traza de eventos para un binario específico y dónde vive (aquí: ProgramData, una ubicación común de “ups”).

Decisión: Si se ejecuta desde ubicaciones modificables por usuarios o aplicaciones, arregla la ruta de instalación o el empaquetado del proveedor. Evita concesiones basadas en rutas que bendigan ProgramData en general.

Tarea 5: Comprobar el estado de la firma de un binario

cr0x@server:~$ powershell -NoProfile -Command "Get-AuthenticodeSignature -FilePath 'C:\Program Files\Acme\AcmeClient.exe' | Format-List Status,StatusMessage,SignerCertificate"
Status        : Valid
StatusMessage : Signature verified.
SignerCertificate : [Subject]
  CN=Acme Software, O=Acme Software, L=Seattle, S=Washington, C=US

Qué significa: “Valid” es lo que buscas. “NotSigned” o “UnknownError” explica la mayoría del dolor con WDAC.

Decisión: Si es válido, prefiere una regla por editor. Si no está firmado, no te apresures a permitir—pregunta por qué y si existe una versión firmada.

Tarea 6: Inspeccionar la cadena de certificados para delimitar reglas por editor con seguridad

cr0x@server:~$ powershell -NoProfile -Command "$sig=Get-AuthenticodeSignature 'C:\Program Files\Acme\AcmeClient.exe'; $sig.SignerCertificate | Select-Object Subject,Issuer,NotBefore,NotAfter,Thumbprint | Format-List"
Subject    : CN=Acme Software, O=Acme Software, L=Seattle, S=Washington, C=US
Issuer     : CN=DigiCert EV Code Signing CA, O=DigiCert Inc, C=US
NotBefore  : 8/1/2025 12:00:00 AM
NotAfter   : 8/1/2027 11:59:59 PM
Thumbprint : 9F1A0C2B4D6E7F8899AABBCCDDEEFF0011223344

Qué significa: La rotación de certificados es real. Los thumbprints expiran, los editores cambian de CA. Acotar por thumbprint es más seguro que “permitir todo lo firmado”, pero más frágil que una regla por editor.

Decisión: Usa el alcance por editor/producto cuando sea posible. Usa thumbprints solo cuando debas restringir a un proveedor con prácticas de firma desordenadas.

Tarea 7: Exportar una política WDAC para inspeccionarla (vista XML)

cr0x@server:~$ powershell -NoProfile -Command "Copy-Item -Path 'C:\Windows\System32\CodeIntegrity\SIPolicy.p7b' -Destination $env:TEMP\ -Force; ConvertFrom-CIPolicy -BinaryFilePath $env:TEMP\SIPolicy.p7b -XmlFilePath $env:TEMP\SIPolicy.xml; Select-String -Path $env:TEMP\SIPolicy.xml -Pattern 'RuleOptions' -Context 0,5"
  <RuleOptions>
    <Option>Enabled:Audit Mode</Option>
    <Option>Enabled:Unsigned System Integrity Policy</Option>

Qué significa: Puedes ver si el Modo Auditoría está activado y otras opciones. (El XML es verboso; solo te importan algunos controles la mayoría de los días.)

Decisión: Confirma que la intención de la política coincida con la realidad del despliegue. Si pensabas que estabas aplicando y estás en auditoría, tu “éxito” es imaginario.

Tarea 8: Crear una política base desde una máquina de referencia (movida inicial)

cr0x@server:~$ powershell -NoProfile -Command "New-CIPolicy -Level Publisher -FilePath C:\Temp\CorpBase.xml -UserPEs -ScanPath 'C:\Program Files','C:\Windows' -Fallback Hash"
Scanning files...
Found 18432 files to be scanned.
Creating policy...
Policy written to C:\Temp\CorpBase.xml

Qué significa: Generaste una política a partir de lo que existe en disco. El nivel Publisher intenta crear reglas por firmante; el fallback por hash captura restos sin firmar.

Decisión: Trata esto como un borrador. Elimina basura, estrecha concesiones amplias y no lances ciegamente lo que un escaneo encontró en una sola máquina.

Tarea 9: Fusionar múltiples políticas (porque la realidad son múltiples imágenes y equipos)

cr0x@server:~$ powershell -NoProfile -Command "Merge-CIPolicy -PolicyPaths C:\Temp\CorpBase.xml,C:\Temp\FinanceApps.xml -OutputFilePath C:\Temp\Merged.xml"
Merging 2 policies...
Merge completed successfully.

Qué significa: Consolidaste fragmentos de política. Esto es útil cuando diferentes responsables de aplicaciones validan diferentes listas de permitidos.

Decisión: Mantén claridad de propiedad: ¿quién puede añadir firmantes? Si todos pueden, accidentalmente permitirás a internet entero vía reglas de editor demasiado amplias.

Tarea 10: Activar explícitamente el Modo Auditoría en una política (antes del despliegue)

cr0x@server:~$ powershell -NoProfile -Command "Set-RuleOption -FilePath C:\Temp\Merged.xml -Option 3"
Updated policy rule options.

Qué significa: Los números de opción dependen de la herramienta/versión, pero esto comúnmente activa el Modo Auditoría en una política CI.

Decisión: Asegura auditoría primero para el despliegue amplio inicial. Aplica solo después de haber reducido los principales hits de auditoría y validado flujos críticos.

Tarea 11: Compilar XML a política binaria (lo que consumen los endpoints)

cr0x@server:~$ powershell -NoProfile -Command "ConvertFrom-CIPolicy -XmlFilePath C:\Temp\Merged.xml -BinaryFilePath C:\Temp\SIPolicy.p7b"
Successfully converted C:\Temp\Merged.xml to C:\Temp\SIPolicy.p7b

Qué significa: La política binaria es la que se despliega en endpoints.

Decisión: Versiona y firma tus artefactos de política (al menos guarda sumas de comprobación). Trátalos como configuración de producción, no como “un archivo en Downloads de alguien”.

Tarea 12: Desplegar la política localmente para un piloto (con cuidado)

cr0x@server:~$ powershell -NoProfile -Command "Copy-Item C:\Temp\SIPolicy.p7b 'C:\Windows\System32\CodeIntegrity\SIPolicy.p7b' -Force; gpupdate /force"
Updating policy...

Computer Policy update has completed successfully.
User Policy update has completed successfully.

Qué significa: Colocaste la política donde Integridad de código la busca y actualizaste la política. En algunos sistemas puede requerirse reinicio para efecto completo.

Decisión: Haz esto solo en máquinas de laboratorio/piloto con acceso de recuperación. Tu plan de reversión debería ser “reemplazar política por conocida‑buena”, no “esperar que el usuario no reinicie”.

Tarea 13: Validar un vector de evasión sospechado: ejecución desde rutas modificables por usuarios

cr0x@server:~$ powershell -NoProfile -Command "Get-Acl $env:USERPROFILE\Downloads | Select-Object -ExpandProperty Access | Select-Object IdentityReference,FileSystemRights,AccessControlType | Format-Table"
IdentityReference     FileSystemRights              AccessControlType
----------------     ----------------              -----------------
BUILTIN\Users        Modify, Synchronize           Allow

Qué significa: Los usuarios pueden modificar Descargas. Si tu política accidentalmente permite ejecución allí (vía una regla de ruta amplia), te habrás auto-saboteado.

Decisión: Evita permisos amplios por ruta en ubicaciones modificables por usuarios. Usa reglas por firmante y confianza de instalador gestionado en su lugar.

Tarea 14: Encontrar los bloqueos de auditoría “más frecuentes” (corte aproximado)

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -LogName 'Microsoft-Windows-CodeIntegrity/Operational' | Where-Object {$_.Id -in 3076,3077,3033} | ForEach-Object { if ($_.Message -match '(\w:.*\.(exe|dll|ps1|msi))') { $matches[1] } } | Group-Object | Sort-Object Count -Descending | Select-Object -First 10 Count,Name | Format-Table -Wrap"
Count Name
----- ----
  112 C:\ProgramData\VendorX\Updater.exe
   87 C:\Windows\Temp\printdriverinstall.exe
   55 C:\Users\jdoe\AppData\Local\Temp\7zS3A2.tmp\setup.exe

Qué significa: Los principales ítems que “hubieran sido bloqueados”. ProgramData y Temp son villanos recurrentes.

Decisión: Atiende estos cambiando despliegue (instalación gestionada), actualizando paquetes de proveedores o eliminando el software. No “simplemente permitir Temp.” Ahí es donde llegan las llamadas de incidentes.

Broma #2: La forma más rápida de descubrir dependencias no documentadas es habilitar la aplicación un viernes. Por favor, no lo hagas.

Guía rápida de diagnóstico

Cuando algo “no se ejecuta” tras cambios en WDAC/Control de aplicaciones, necesitas determinar: ¿es realmente WDAC?, ¿qué se bloqueó exactamente?,
y ¿cuál es la solución más estrecha y segura?

Primero: prueba que es WDAC (no EDR, no AV, no instalador roto)

• Revisa eventos de Integridad de código Operacional para mensajes recientes de “prevented” alrededor del tiempo de la falla.
• Si ves eventos que coinciden con la ruta del binario y la marca temporal, es WDAC. Si no, deja de culpar a WDAC y revisa AppLocker/ASR/EDR.

Segundo: clasifica el bloqueo

• Binario sin firmar: común en herramientas internas, proveedores legacy, DLLs cargadas lateralmente.
• Firmado pero no confiado: falta regla para el firmante, alcance de editor incorrecto, rotación de certificados.
• Relacionado con scripts: PowerShell, WSH, acciones personalizadas de MSI, o un host firmado que carga contenido sin firmar.
• Ubicación incorrecta: ejecutable colocado en Temp/Descargas por un instalador/actualizador.

Tercero: decide la remediación menos peligrosa

1. Prefiere cambiar la ruta de entrega (instala correctamente, deja de ejecutarse desde Temp) antes que ampliar la confianza en la política.
2. Prefiere una regla por editor (delimitada) sobre una regla por hash.
3. Si debes usar un hash, ponle una expiración: hazle seguimiento y elimínalo tras la corrección del proveedor o del empaquetado.
4. Valida en un canario antes de una actualización amplia de la política.

Pistas sobre cuellos de botella (qué te ralentiza)

• Si no tienes recolección centralizada de logs para eventos CI, tu cuello de botella es la visibilidad, no la autoría de políticas.
• Si sigues añadiendo excepciones por hash, tu cuello de botella es la cadena de suministro de software (actualizaciones sin firma predecible).
• Si cada unidad de negocio tiene sus propias costumbres de instalación, tu cuello de botella es la gobernanza. WDAC hará cumplir la verdad que has estado evitando.

Tres micro-historias corporativas desde la trinchera

Micro-historia 1: El outage causado por una suposición errónea

Una empresa mediana pasó WDAC de auditoría a aplicación en un conjunto pequeño de estaciones compartidas “bajo riesgo”. La suposición fue simple:
los quioscos solo ejecutaban un navegador y unas pocas apps de proveedores, y esas eran “definitivamente firmadas.”

A la mañana siguiente, los quioscos estaban arriba, pero la impresión estaba muerta. No “a veces”. Muerta. Llegaron tickets, y el helpdesk hizo lo que hace: reinstalar el paquete de impresora. Eso empeoró las cosas, porque el instalador desempaquetó ejecutables auxiliares en C:\Windows\Temp
y los ejecutó desde allí. Esos auxiliares no estaban firmados.

El equipo tenía logs de auditoría, pero solo habían revisado ejecutables principales. No habían mirado la cola larga: controladores de impresión, procesos auxiliares
y componentes de actualización. Los logs CI fueron contundentes: los archivos bloqueados eran exactamente los que el instalador había puesto en Temp.

La solución no fue “permitir Temp.” La solución fue conseguir un paquete de driver más nuevo que usara componentes firmados y una ubicación de staging sensata, luego añadir una regla por editor para el proveedor.
También actualizaron la checklist del piloto: “impresión y escaneo son flujos de trabajo de primera clase”, porque los usuarios consideran esas funciones “básicas”, no “periféricos opcionales.”

La lección real: las suposiciones más peligrosas son las que suenan aburridas. “Los drivers están firmados” parecía aburrido. También era falso.

Micro-historia 2: La optimización que salió mal

Una gran empresa quería acelerar el despliegue de WDAC. El equipo de seguridad propuso una optimización:
“Permitamos todo el código firmado por cualquier certificado que encadene a una raíz de confianza, y luego bloqueamos lo conocido‑malo después.”
Sonaba eficiente. También reintrodujo silenciosamente el problema que el listado de permitidos pretende resolver.

Durante unas semanas todo parecía perfecto. No hubo fallos. Los dashboards estaban tranquilos. Luego una investigación de respuesta a incidentes encontró una herramienta comercial de acceso remoto
ejecutándose en varios endpoints. La herramienta estaba legítimamente firmada. La cadena de firma era válida. Y porque la política efectivamente había dicho “firmado = confiable,”
se ejecutó sin fricción.

Nadie “había hecho algo mal” en el sentido estrecho. La optimización funcionó según lo diseñado. El diseño fue el problema.
Habían construido un control que bloqueaba mayormente malware aficionado y hacía poco frente al ecosistema de herramientas firmadas y de doble uso.

La recuperación fue dolorosa pero directa: ajustaron a reglas por editor para proveedores conocidos, activaron Instalador gestionado para despliegue sancionado,
y trataron “firmado pero no aprobado” como no confiable por defecto. El error no fue técnico. Fue un error de categoría: confundir autenticidad con autorización.

Micro-historia 3: La práctica aburrida pero correcta que salvó el día

Otra organización ejecutaba WDAC con una disciplina poco glamurosa: todo cambio de política pasaba por un anillo canario, y cada anillo tenía un dueño que podía decir “no”
sin sufrir represalias políticas. También mantenían un artefacto de política conocido‑bueno y un script para intercambiarlo.

Un proveedor lanzó una actualización para un cliente VPN. Los binarios seguían firmados, pero el proveedor había cambiado el certificado de firma y reorganizado el layout de instalación.
Los logs de auditoría se encendieron inmediatamente en el anillo canario: la actualización rompería la aplicación.

Porque el equipo tenía una rutina, la respuesta fue rutinaria: abrir un cambio, añadir una regla por editor acotada para el nuevo firmante, validar en canario y luego avanzar.
No hubo llamada general. No hubo “permitir todo temporalmente.” No hubo revertir.

La parte aburrida fue la disciplina del anillo y la higiene de artefactos. El resultado fue emocionante en el mejor sentido: no pasó nada.
En operaciones, “no pasó nada” es una característica de primer orden.

Errores comunes: síntomas → causa raíz → solución

1) Síntoma: “Una app aleatoria no inicia; sin error evidente”

Causa raíz: WDAC está bloqueando la creación del proceso. La app puede fallar en silencio o mostrar un diálogo genérico de “no puede ejecutarse”.

Solución: Revisa los logs Operacionales de Integridad de código para un evento de bloqueo que coincida en tiempo/ruta. Añade una regla de firmante acotada o corrige el empaquetado. Evita proliferación de hashes.

2) Síntoma: “Todo funciona en auditoría, en aplicación se rompen varias apps”

Causa raíz: Ignoraste el volumen de auditoría o solo revisaste “EXE principales”, no DLLs, auxiliares, controladores y tareas de actualización.

Solución: En auditoría, agrega y ordena eventos por frecuencia y criticidad de negocio. Valida flujos completos (impresión, escaneo, VPN, soporte remoto, complementos de Office).

3) Síntoma: “Un actualizador se ejecuta desde ProgramData/Temp y es bloqueado”

Causa raíz: El instalador del proveedor coloca ejecutables en ubicaciones escribibles; esos archivos no están firmados o no están cubiertos por reglas de permiso.

Solución: Consigue un paquete de proveedor corregido, reempaquétalo o distribúyelo vía Instalador gestionado para que los binarios finales sean confiables. No permitas Temp ampliamente.

4) Síntoma: “Seguimos añadiendo reglas por hash cada martes de parches”

Causa raíz: Estás usando reglas por hash para software que se actualiza con frecuencia, o tu método de generación de políticas por defecto usa hashes debido a componentes sin firmar.

Solución: Pasa a reglas por editor cuando sea posible. Para componentes sin firmar, presiona a proveedores/desarrolladores internos para que firmen. Usa hashes solo como excepciones con fecha.

5) Síntoma: “Una herramienta firmada está bloqueada aunque es legítima”

Causa raíz: Permitiste un alcance de editor distinto al firmante real del binario; rotación de certificados o una línea de producto diferente usa otro certificado.

Solución: Revisa los detalles de la firma Authenticode. Añade una nueva regla de firmante/editor acotada al proveedor/producto que realmente quieres permitir.

6) Síntoma: “La actualización de política no cambió nada en endpoints”

Causa raíz: El mecanismo de despliegue no aplicó (sincronización MDM, GPO que no se actualiza, ubicación de política incorrecta), o compilaste/desplegaste el artefacto equivocado.

Solución: Verifica la política activa vía CIM, confirma que el archivo existe en la ruta CodeIntegrity, confirma la hora de actualización. Trata la política como un release versionado.

7) Síntoma: “Los desarrolladores están furiosos; scripts y herramientas de build fallan”

Causa raíz: Aplicaste una política de workstation a endpoints de desarrollo sin modelar toolchains (compiladores, gestores de paquetes, salidas de build locales).

Solución: Usa anillos/políticas separadas. Para dev, céntrate en bloquear ejecución desde rutas modificables por usuarios mientras permites toolchains firmadas y fuentes de instalación gestionadas. Además: firma tus herramientas internas. Es 2026.

8) Síntoma: “Permitimos ‘Microsoft’ ampliamente y ahora corre una herramienta cuestionable”

Causa raíz: Confianza excesiva en código firmado, combinada con herramientas legítimas pero peligrosas firmadas por editores reputados.

Solución: Ajusta a editores/productos explícitos que pretendas permitir. Usa controles adicionales (reglas ASR, EDR) para herramientas de doble uso. WDAC no es tu único guardarraíl.

Listas de verificación / plan paso a paso

Despliegue paso a paso que no acaba en lágrimas

1. Elige tu objetivo: bloquear binarios no aprobados en espacio de usuario; no intentes resolver cada caso límite de scripts el primer día.
2. Implanta visibilidad de logs: recopila eventos Operacionales de Integridad de código centralmente. Si no puedes ver, no puedes operar.
3. Crea una imagen de referencia: una máquina limpia con el conjunto estándar de apps. Genera una política borrador a partir de ella.
4. Normaliza la entrega de software: decide qué cuenta como “instalación gestionada” en tu organización y hazla cumplir social y técnicamente.
5. Activa Modo Auditoría en toda la flota (o anillo amplio): no apliques antes de ver al menos un ciclo completo de parches.
6. Reduce los principales hits de auditoría: corrige empaquetado, reemplaza software, añade reglas por editor acotadas.
7. Define el flujo de excepciones: quién aprueba, cuánto dura, qué evidencia se requiere (info de firma, propietario del negocio).
8. Anillo canario para aplicación: anillo pequeño con soporte rápido y acceso de reversión. Valida flujos críticos, no solo “se abren las apps”.
9. Anillos progresivos: expande la aplicación a anillos más amplios. Espera diferentes dolores: apps financieras, herramientas de call center, drivers de manufactura.
10. Disciplina de actualización de política: control de cambios, versionado, despliegue en fases y revisión de logs posterior al cambio.
11. Mide resultados: cuenta ejecuciones no aprobadas bloqueadas, excepciones de emergencia, tiempo para mitigar bloqueos.
12. Mantén operativo el escape hatch: una reversión probada y un plan de recuperación de endpoint break‑glass.

Checklist de preparación antes de aplicar

• Los logs de auditoría están centralizados y son buscables.
• Los binarios bloqueados principales están entendidos (qué son, quién los posee, por qué se ejecutan).
• Los flujos críticos están probados de extremo a extremo (VPN, impresión, soporte remoto, instalación de software, apps de negocio).
• Los artefactos de política están versionados; puedes identificar qué está desplegado en un endpoint.
• El procedimiento de reversión está probado en un dispositivo real, no solo escrito en un wiki.
• El personal de soporte sabe cómo recolectar evidencia de eventos CI y escalar con datos útiles.

Checklist de emergencia “algo está roto”

• Identificar si el dispositivo afectado está en auditoría o en aplicación.
• Capturar el evento Operacional CI que referencia el binario bloqueado.
• Comprobar el estado de firma del binario y si proviene de una ubicación sensata.
• Si es crítico para el negocio, aplicar la solución temporal más estrecha (regla por hash con expiración) mientras buscas una regla por editor durable o la corrección del empaquetado.
• Actualizar la política en canario primero, luego desplegar.

Preguntas frecuentes

1) ¿“WDAC Lite” ofrece menos seguridad?

Es una estrategia distinta: despliegue por fases, confianza mínima necesaria y supervivencia operativa. Una política algo menos estricta pero realmente aplicada supera a una política perfecta que vive en PowerPoint.

2) ¿Debería usar AppLocker en su lugar?

AppLocker puede ser más sencillo para ciertos escenarios basados en rutas y usuarios, pero la aplicación a nivel kernel de WDAC es más difícil de eludir. En 2026, si empiezas de cero para endpoints empresariales, WDAC suele ser la mejor apuesta a largo plazo.

3) ¿Por qué no permitir todo lo firmado?

Porque “firmado” significa “auténtico”, no “aprobado”. Muchas herramientas legítimas firmadas son excelentes para atacantes. Permite solo los editores/productos que pretendes y trata al resto como no confiable.

4) ¿Cuál es la forma más rápida de reducir excepciones?

Instalador gestionado más distribución estándar de software. Convierte “EXE aleatorio desde correo” en “solicita software en el catálogo”, y la política se estabiliza.

5) ¿Las reglas por hash alguna vez están bien?

Sí, como parche temporal o para binarios estáticos raros. Pero si usas hashes para Chrome/Teams/cliente VPN, te has puesto en una cinta de correr y tú eres el hámster.

6) ¿Cómo manejar proveedores que envían componentes sin firmar?

Primero, exige builds firmados. Segundo, considera reempaquetar y controlar dónde viven los componentes y quién puede escribir allí. Tercero, si debes permitir sin firmar, acótalo y trátalo como deuda técnica con propietario y expiración.

7) ¿Qué hago cuando rota un certificado y empiezan a bloquearse cosas?

Confirma con inspección Authenticode y eventos CI. Añade el nuevo firmante/editor a la política en auditoría, valida en canario y luego despliega. No “permitas todo lo firmado temporalmente” a menos que disfrutes eliminando permisos temporales después (nadie lo disfruta).

8) ¿WDAC reemplaza al EDR/AV?

No. WDAC es un control preventivo para ejecución. EDR ofrece detección, investigación, respuesta y telemetría. Quieres ambos: WDAC reduce lo que puede ejecutarse; EDR te ayuda a entender lo que lo intentó.

9) ¿Cómo evito bloquear herramientas internas de desarrolladores?

Separa políticas por clase de dispositivo (desarrollador vs usuario estándar). Para endpoints de dev, permite toolchains firmados y orígenes de instalación gestionados, pero sigue bloqueando binarios desconocidos desde rutas modificables por usuarios. Además: firma tus herramientas internas. Es 2026.

10) ¿Cuál es la parte más subestimada de las operaciones WDAC?

La higiene de logs y la propiedad. Si nadie posee “los eventos bloqueados principales”, la política se convierte lentamente en sopa de excepciones, y empezarás a negociar con tu propia línea base de seguridad.

Siguientes pasos prácticos

Si no haces nada más, haz estas tres cosas en este orden:

1. Activa Modo Auditoría para un anillo significativo y recopila eventos de Integridad de código centralmente.
2. Arregla los 10 bloqueos principales cambiando empaquetado y modelo de confianza (reglas por editor, instalación gestionada), no bendiciendo Temp.
3. Aplica en un anillo canario con un artefacto de reversión probado y una persona de guardia que pueda realmente desplegar una actualización de política.

WDAC Lite no es ser tímido. Es ser deliberado. Estás construyendo un sistema que dice “no” en el límite del kernel.
Eso es poderoso, y el poder se usa mejor con un runbook, no con corazonadas.