Trusted Ownership : comment Ivanti Application Control va au-delà des listes d’autorisation

Le contrôle des applications fait partie de ces sujets de sécurité sur lesquels de nombreuses personnes conservent d’anciennes idées reçues. Les listes d’autorisation traditionnelles semblent rassurantes, mais deviennent rapidement difficiles à maintenir. Les listes de blocage paraissent réactives et incomplètes. Et si des outils comme Microsoft AppLocker ont conduit beaucoup d’organisations à penser que les listes d’autorisation strictes étaient la référence, les attaques modernes ont démontré le contraire. Les attaquants s’appuient de plus en plus sur des outils légitimes et signés — utilisés dans le mauvais contexte — pour contourner entièrement les contrôles fondés sur des listes.

Ainsi, lorsque les organisations évaluent Ivanti Application Control ou Ivanti Neurons for App Control et découvrent Trusted Ownership, celui-ci peut d’abord ressembler à une liste de blocage, car des blocages explicites sont possibles. En réalité, Trusted Ownership est un modèle d’application des règles beaucoup plus large et bien plus léger sur le plan opérationnel, qui contrôle l’exécution selon l’origine, et pas seulement selon l’identité.

Au lieu de gérer des listes toujours plus nombreuses, il applique la sécurité en fonction de la personne ou du processus qui a placé le logiciel sur le système, en cohérence avec les pratiques modernes de distribution logicielle et les principes du zero trust. Il faut le comprendre non comme un autre mécanisme de liste, mais comme un modèle d’application des règles inspiré de la provenance, qui contrôle l’exécution selon l’origine, et pas seulement selon l’identité.

Ce changement de perspective conduit à une meilleure question pour le contrôle moderne des applications : non seulement ce qu’un fichier est, mais comment il est arrivé là.

Au-delà des listes : pourquoi le contrôle de provenance compte désormais

La question de savoir comment un fichier est arrivé sur le système est au cœur du contrôle de provenance. Au lieu de faire confiance aux fichiers uniquement sur la base de l’éditeur, du chemin ou du hachage, le contrôle de provenance évalue l’origine et le processus qui les ont introduits. Qui a écrit le fichier sur le disque ? Par quel mécanisme ? L’installation a-t-elle suivi un workflow IT contrôlé ? Cette évaluation fait passer le contrôle des applications d’une confiance accordée aux objets à une confiance accordée aux processus, créant ainsi une frontière de sécurité bien plus solide.

Dans Ivanti Application Control, le contrôle de provenance est mis en œuvre sous la forme de Trusted Ownership. Tout fichier placé par un propriétaire de confiance est autorisé ; tout élément introduit par un utilisateur est refusé par défaut. Cela s’applique de manière cohérente aux exécutables, DLL, programmes d’installation et scripts. Comme des identités telles que SYSTEM, TrustedInstaller et Administrators sont approuvées par défaut, les logiciels livrés via des canaux de déploiement standard comme MS Intune, MECM, Ivanti Endpoint Manager (EPM) ou d’autres outils d’entreprise s’exécutent immédiatement, sans maintenance des règles ni exceptions.

Cela marque une rupture fondamentale avec les listes d’autorisation classiques. Les règles AppLocker dépendent de définitions exactes d’éditeur, de chemin ou de hachage. AppLocker n’évalue pas l’origine de l’installation et ne fait pas automatiquement confiance à vos mécanismes de déploiement. Les logiciels livrés par Intune nécessitent toujours une règle d’autorisation préexistante, souvent fondée sur des paramètres par défaut larges qui autorisent les répertoires Program Files ou Windows.

Cette distinction est importante, car les attaques modernes détournent de plus en plus des outils légitimes dans des contextes inappropriés. Le contrôle de provenance neutralise une grande partie de ce risque en appliquant la confiance à la manière dont le logiciel arrive, et pas seulement à comment le logiciel arrive, et pas seulement à ce qu’il est. Il s’aligne sur les principes du zero trust, réduit l’exposition de la chaîne d’approvisionnement et limite fortement, par défaut, les possibilités d’abus de type Living off the Land (LotL).

Une fois l’importance de l’origine comprise, la question suivante devient : comment l’appliquer à grande échelle ?

La réponse : appliquer la provenance de manière cohérente à toutes les façons dont les logiciels s’exécutent et à toutes les façons dont ils sont livrés.

Au-delà des listes de blocage : une couverture étendue conçue pour le déploiement logiciel moderne

Le contrôle de provenance fait évoluer la sécurité des applications : il ne s’agit plus de gérer des listes interminables, mais de valider le processus par lequel le logiciel arrive sur le système. Une fois cette perspective adoptée, il devient clair que Trusted Ownership n’est pas une approche de type liste de blocage. C’est une frontière de confiance fondée sur l’origine, dont le fonctionnement diffère nettement des listes d’autorisation traditionnelles.

Une idée reçue courante consiste à penser que Trusted Ownership ressemble à une liste de blocage parce que les administrateurs ajoutent parfois des règles de refus ciblées pour des outils Windows bien connus. En pratique, ces règles de refus sont des mesures de renforcement défensif contre les techniques Living off the Land. Toute méthode sérieuse de contrôle des applications utilise ce type de restrictions ciblées. Le cœur de Trusted Ownership est l’inverse d’une liste de blocage. Les logiciels livrés via un processus contrôlé et approuvé sont autorisés par défaut, tandis que le contenu introduit par l’utilisateur est refusé par défaut.

Un facteur de différenciation plus important encore est la couverture. De nombreuses organisations qui s’appuient sur des listes d’autorisation classiques finissent par se concentrer presque exclusivement sur les fichiers exécutables. Elles évitent souvent d’appliquer le même niveau de contrôle aux DLL, scripts et packages MSI, car ces types de fichiers rendent la maintenance des règles beaucoup plus complexe. Cela crée des failles que les attaquants modernes exploitent fréquemment.

Trusted Ownership évite ces failles en appliquant le même contrôle fondé sur l’origine à l’ensemble de la chaîne d’exécution. Les exécutables, DLL, scripts, programmes d’installation MSI et composants associés sont évalués selon le même modèle de confiance. Comme la confiance est déterminée par l’entité qui a introduit le fichier, vous n’avez pas besoin de politiques distinctes pour chaque type de fichier. Un script dans le dossier Téléchargements, une DLL créée dans un répertoire de build temporaire ou un EXE exécuté depuis un profil utilisateur reçoivent tous le même traitement de refus par défaut lorsqu’ils proviennent d’un processus d’installation non contrôlé.

Ce modèle de confiance s’aligne également naturellement sur la façon dont les plateformes modernes de gestion des terminaux livrent les logiciels. Des solutions telles qu’Intune, MECM, Ivanti Neurons for MDM, Ivanti Endpoint Manager et des systèmes similaires installent généralement les applications en utilisant l’identité SYSTEM ou un autre compte de service approuvé.

Comme ces identités sont déjà des propriétaires de confiance, les logiciels déployés via ces canaux s’exécutent immédiatement, sans créer de règles d’autorisation, maintenir des chemins de fichiers ni mettre à jour des politiques. Ce n’est que lorsque vous utilisez volontairement d’autres comptes d’installation, comme des agents DevOps personnalisés ou des installations scriptées en contexte utilisateur, que vous devez identifier cette identité comme propriétaire de confiance.

Le résultat est un modèle offrant une couverture étendue et cohérente sur tous les types de fichiers pertinents. Il fonctionne de manière fluide avec les distributions logicielles modernes et évite la charge opérationnelle associée aux listes d’autorisation classiques, qui se concentrent principalement sur les fichiers exécutables.

Trusted Ownership place la confiance non pas dans des objets individuels, mais dans les processus contrôlés par lesquels les logiciels sont livrés, créant ainsi une approche plus évolutive et plus sûre du contrôle des applications.

Quelle place pour WDAC (App Control for Business) ?

Microsoft maintient deux technologies de contrôle des applications : AppLocker et App Control for Business (anciennement WDAC). Bien que les deux existent encore, Microsoft est clair quant à leurs rôles. AppLocker aide à empêcher les utilisateurs d’exécuter des applications non approuvées, mais ne répond pas aux critères de maintenance des fonctionnalités de sécurité modernes et est donc catégorisé comme un mécanisme de défense en profondeur plutôt que comme un contrôle de sécurité stratégique.

La trajectoire recommandée par Microsoft pour le contrôle des applications est App Control for Business, et l’éditeur indique explicitement qu’AppLocker est complet sur le plan fonctionnel et ne fait plus l’objet d’un développement actif, en dehors des mises à jour de sécurité essentielles. Cela signifie que toutes les nouvelles capacités sont livrées uniquement dans WDAC, et non dans AppLocker.

App Control for Business introduit le concept de Managed Installer. Celui-ci permet à Windows de faire automatiquement confiance aux applications installées via des plateformes de déploiement désignées, telles qu’Intune ou MECM. La confiance provient du canal de distribution plutôt que des fichiers individuels, ce qui réduit considérablement la maintenance des règles.

Cela s’aligne étroitement sur le modèle Trusted Ownership d’Ivanti Application Control. Les deux approches font confiance au logiciel en fonction du processus contrôlé qui l’a installé, plutôt que d’attributs de fichiers distincts. Toutefois, Trusted Ownership applique ce concept de manière plus simple et plus accessible sur le plan opérationnel. Ivanti fait confiance à des identités telles que SYSTEM et à des comptes de service désignés, sans exiger de couches de politiques complexes, de définitions XML ni d’expertise approfondie de WDAC.

Ivanti entend de nombreuses organisations expliquer qu’elles peinent à rendre WDAC opérationnel. Les politiques WDAC exigent une conception rigoureuse, de longs tests en mode audit, la gestion des exceptions de pilotes et de noyau, ainsi qu’une maintenance continue de plusieurs ensembles de politiques. Cela conduit souvent les organisations à associer WDAC à AppLocker pour couvrir à la fois l’application de règles de bas niveau et le contrôle quotidien de l’espace utilisateur, avec à la clé une charge administrative supplémentaire.

Ivanti Application Control offre une alternative unifiée. Grâce à Trusted Ownership, Trusted Vendors et à la validation des signatures numériques, il fournit un modèle de refus par défaut fondé sur la provenance, avec une couverture cohérente des exécutables, DLL, scripts et packages MSI.

Au lieu de maintenir deux plans de contrôle Microsoft aux périmètres différents, les organisations gèrent une politique unique et rationalisée qui applique la confiance en fonction de la manière dont le logiciel est introduit dans le système. Cela répond à de nombreux objectifs pratiques que les clients cherchent à atteindre avec un déploiement combinant WDAC et AppLocker, mais avec une complexité opérationnelle moindre et un modèle de confiance cohérent.

LOLBins et contrôle au niveau des arguments

Une fois cette large couverture établie, la question devient alors de savoir comment gérer les outils légitimes déjà présents sur chaque machine, que les attaquants aiment détourner.

Les attaquants modernes évitent souvent d’utiliser des malwares traditionnels et s’appuient plutôt sur les outils déjà présents sur chaque appareil Windows. Ces outils Living off the Land (LOLBins) sont légitimes et nécessaires aux opérations courantes, ce qui les rend difficiles à bloquer sans nuire à la productivité. Les listes d’autorisation traditionnelles atteignent ici leurs limites : un blocage trop large perturbe les workflows, tandis qu’une autorisation trop large laisse des failles dangereuses.

Un modèle fondé sur la provenance, tel que Trusted Ownership, change cette dynamique. Même si un attaquant tente d’utiliser un outil intégré, le contenu qu’il essaie d’exécuter ne provient généralement pas d’un processus d’installation approuvé. Comme Ivanti évalue l’origine de ce contenu, la plupart des tentatives d’utilisation abusive échouent automatiquement. L’outil peut être légitime, mais le contenu qu’on lui demande d’exécuter ne l’est pas, et Trusted Ownership l’arrête avant son exécution.

Il est également important de comprendre non seulement quels outils s’exécutent, mais aussi ce qu’on leur demande de faire. De nombreux interpréteurs et environnements d’exécution, tels que PowerShell, Python ou Java, peuvent être parfaitement sûrs dans un contexte et risqués dans un autre. Une application métier peut s’appuyer sur Java pour lancer un processus spécifique et approuvé, tandis qu’un fichier JAR téléchargé par un utilisateur correspond à un scénario entièrement différent.

Ivanti gère cela au moyen d’une approche en couches. Un fichier JAR est d’abord évalué à l’aide de Trusted Ownership, qui le bloque immédiatement s’il a été introduit par un utilisateur plutôt que par un processus de déploiement contrôlé. Au-delà de cela, les administrateurs peuvent créer des règles d’autorisation simples qui précisent exactement quelles commandes Java sont permises, afin que seules les applications légitimes fondées sur Java s’exécutent, tandis que les tentatives de lancement de fichiers JAR non approuvés sont refusées discrètement.

Le même principe s’applique également à d’autres outils. Les politiques peuvent approuver le comportement exact dont votre organisation a besoin, tout en bloquant les activités qui sortent de ces limites. Cela évite les règles larges et fragiles, tout en maintenant la fluidité du travail quotidien.

Le résultat est une approche moderne et équilibrée. Trusted Ownership bloque par défaut le contenu non approuvé. Un renforcement ciblé s’aligne sur les bonnes pratiques gouvernementales et communautaires visant à réduire les abus de type Living off the Land, tandis que les contrôles tenant compte de l’intention garantissent que les processus légitimes continuent de fonctionner sans ouvrir de portes aux attaquants.

Cette approche s’aligne étroitement sur les recommandations actuelles des communautés et des organismes publics concernant l’atténuation des techniques Living off the Land. Des agences telles que la CISA, la NSA, le FBI et l’Australian Cyber Security Centre soulignent l’importance de réduire les possibilités offertes aux attaquants d’utiliser des outils intégrés, en contrôlant leur utilisation et en limitant le contenu non approuvé sur lequel ils agissent. Leurs recommandations conjointes mettent en évidence que les attaques LOTL reposent sur le détournement d’outils natifs et insistent sur la nécessité de contrôles qui limitent ces abus sans bloquer les processus système légitimes.

Le modèle d’Ivanti reflète ces recommandations. Trusted Ownership bloque automatiquement le contenu non approuvé sur lequel les attaquants s’appuient, tandis qu’un petit nombre de restrictions ciblées couvre le petit ensemble d’outils nécessitant une attention supplémentaire.

Trusted Ownership en action : scénarios concrets

Voici quelques exemples opérationnels illustrant le fonctionnement d’Ivanti Application Control et de Trusted Ownership en pratique.

1. Une application portable est copiée dans le profil utilisateur. Ivanti la bloque parce qu’elle appartient à l’utilisateur. AppLocker ne bloque que si des règles correspondantes existent. Sans les bonnes règles de chemin ou d’éditeur, le comportement peut varier.
2. Une pièce jointe à un e-mail lance un script PowerShell depuis le dossier Téléchargements. Ivanti le refuse en raison de la propriété utilisateur. AppLocker dépend des règles de script et, lors des événements de blocage, force PowerShell à passer en mode Constrained Language Mode, ce qui exécutera tout de même le script.
3. Détournement d’outils du système d’exploitation tels que rundll32 ou mshta. Les deux modèles nécessitent un renforcement ciblé par règles de refus. Ivanti l’associe au contrôle de provenance, ce qui réduit généralement le nombre d’exceptions nécessaires. AppLocker s’appuie sur des ensembles de refus organisés et nécessite des ajustements périodiques.
4. Une mise à jour fournisseur livre de nouveaux fichiers signés. Ivanti autorise la mise à jour lorsqu’elle arrive via le canal de déploiement approuvé, grâce à Trusted Ownership. AppLocker peut prendre cela en charge avec des règles d’éditeur, mais la réutilisation de signatures sur plusieurs produits ou des chemins d’installation inhabituels entraînent souvent une maintenance supplémentaire et une confiance plus large que prévu.
5. Un utilisateur télécharge un fichier JAR et essaie de l’exécuter avec Java. Ivanti bloque la tentative parce que le JAR a été introduit par l’utilisateur et échoue au contrôle Trusted Ownership. Si nécessaire, les administrateurs peuvent autoriser uniquement l’invocation approuvée exacte en faisant correspondre la ligne de commande complète. AppLocker ne peut pas faire correspondre les arguments et s’appuie sur des règles d’éditeur, de chemin ou de hachage.

Conclusion

Le contrôle de provenance fait passer le contrôle des applications d’un problème de gestion à un modèle de confiance. Au lieu de faire confiance à des fichiers individuels, il fait confiance au processus par lequel les logiciels arrivent sur un système, rendant la sécurité à la fois évolutive et exploitable.

Trusted Ownership s’inscrit pleinement dans cette approche. Il ne s’agit ni d’une liste de blocage ni d’une liste d’autorisation classique, mais d’un modèle dans lequel les logiciels arrivant via un processus IT contrôlé sont autorisés par défaut, tandis que tout ce qui se trouve en dehors de ce processus est refusé par défaut. En appliquant le contrôle à l’origine et à la propriété plutôt qu’à des fichiers définis au cas par cas, Ivanti Application Control et Ivanti Neurons for App Control s’alignent bien mieux sur les techniques d’attaque modernes et les pratiques actuelles de distribution logicielle.

Si vous continuez à considérer le contrôle des applications comme un exercice de gestion de listes, vous en ressentirez la charge administrative. Si vous le considérez comme une frontière de confiance, vous gagnez en évolutivité, en sécurité et en efficacité opérationnelle.