Un proveedor necesita cuatro intentos para desplegar con ThreatLocker activo
Relata que el cliente aprobaba excepciones a mano desde el móvil y que las instalaciones seguían fallando, con los ingenieros esperando en sitio.
Un técnico de un fabricante de software ha contado cómo fue desplegar un servidor de impresión en un cliente que acababa de adoptar un modelo de confianza cero con ThreatLocker. Necesitó cuatro intentos. Entre uno y otro hubo que desinstalar la aplicación varias veces porque la instalación quedaba corrupta, y el gestor de TI del cliente se sentaba a su lado aprobando excepciones desde el móvil.
El detalle que explica el fracaso no es el bloqueo, sino el tiempo. Según este relato, los subcomponentes del instalador tardan alrededor de un minuto en poder ejecutarse, así que la aprobación llega y el instalador ya ha muerto. Aprobación concedida, instalación fallida, a empezar de nuevo. El proveedor da por hecho que tendrá que repetir el proceso entero cada vez que publique una actualización.
El cuello de botella no es el bloqueo, es la cola
El propio autor del relato lo plantea: en un servidor de impresión, que es infraestructura crítica para quien imprime, no tiene claro qué aporta tener allowlisting por delante de cada binario. Lo que describe es un problema de operación, no de producto. Aprobar excepciones sin saber qué se está aprobando es una firma a ciegas, y quien firma acaba desarrollando fatiga: pulsa el botón porque hay que pulsarlo, no porque haya evaluado nada.
El resultado, según su experiencia, es que la puesta en marcha y el soporte de esos sistemas les llevan el doble de tiempo. Los ingenieros se quedan parados en la sede esperando una aprobación, con el usuario encima porque su aplicación legítima no arranca. Y hay una consecuencia comercial explícita: la empresa planea dejar en segundo lugar a los clientes que tengan ThreatLocker desplegado, porque no le compensa mandar gente a una instalación donde el cuello de botella está fuera de su control.
Conviene tomarse el texto por lo que es: la versión de una de las partes, sin cifras de cuántas sedes ni de cuántas horas se han perdido, y sin respuesta del cliente ni del fabricante de la herramienta. Nada de esto es nuevo para quien haya montado allowlisting en producción. La lección de fondo es que cualquier modelo de confianza cero se juega su viabilidad en el diseño del flujo de aprobación, no en la lista de bloqueo. Si cada binario legítimo necesita un humano con un móvil para pasar, el sistema se cae por donde menos se espera: por el tiempo de espera.